Dynamic binding

The most general case for binding is to use a dynamic binding protocol. The warrant contains one or more binding server definitions, each of which contains:

• A list of URLs
• A set of key/value binding parameters

Multiple binding protocols are supported. The base API specifies that every node must support a simple HTTP based binding protocol over normal and SSL based connections.

Binding protocols involve the following steps:

1. The node connects to the binding server with the specified URL.

   The binding parameters associated with the URL are transferred, along with the accounting type if present in the warrant.

2. The node may make available any signed certificates with which it is associated, if the protocol supports it.
3. The binding server may determine the host's capabilities (see Section )
4. The binding server may negotiate a hosting contract if the protocol supports it.

   Payment information and signatures may be exchanged as part of this process. This step may not be performed if the warrant specified an internal netlet.

5. The binding server determines the descriptor and unsigned argument to be used.
6. The descriptor and arguments are transferred to the node.

The simple HTTP binding protocol does not support contract negotation. If the service provider netlet is to pay for its own accounting a standard contract is used with a pay-as-you-go model. Payment must be arranged at binding time, and involves the transfer of a special warrant to a payment service. See Section  for more details of the wallet mechanism.

Node certificates are not transferred unless the SSL transport is being used, in which case the certificates are sent during the SSL negotiation phase.