These are my ideas on capability negotiation. They are a mix of SDP's offer/answer, BGP and PPP. I wait for comments before I expand the sections.
-----------
* The requirements for the capability negotiation are:
- Small number of RTTs
- Simple but extensible
- Able to negotiate different capabilities for transaction, connection, channel and device level. (did I miss any layer?)
- Able to negotiate capabilities for a different processing layer (for example, inside a channel you can alter the capabilities for the device level, or inside a transaction you can alter the capabilities for the channel).
* Capabilities
Capabilities are expressed with a identifier and a value. Depending on the OCP protocol the WG chooses, this can be achieved by a TLV field or a text based <name:value> notation
The same capability can be included in a packet more than once if they are on different scopes (e.g., device vs. transaction).
* Packet Format
The capability negotiation packet is divided in several scopes (device, transaction, channel, etc). In each scope any number of capabilities and their respective values can be included.
The capability negotiation packets also includes a identifier so that the peers can match packets belonging to the same negotiation.
There are 4 different types of capability negotiation packets: <offer>, <answer>, <success> and <failure>
* Capability Negotiation
The capability negotiation starts with a <offer> packet in which the initiator (OPES processor or Callout server) lists the desired capabilities and their respectrive values in each scope.
To every <offer> sent by the initiator, the non-initiator (OCP peer) sends an <answer> packet listing the capabilities it would prefer a different value and the ones it does not understand at all.
Based on the answer of its peer, the initiator of the capability negotiation can send a <failure> packet and raise an event or try again with the changes proposed by its peer. When the OCP peers have reached an agreement the non-initiator will send an <success> packet which indicate the end of the capability negotiation process.
It is expected that no more than 4 messages will be required for the peers to reach a agreement: <offer>, <answer> with a different proposal, final <offer>, <success>.
If one of the peers does not want to carry the capability negotiation any further, it can send a <failure> packet. The <failure> packet should contain the reason for the failure. More specifically, the message must contain for each offending capability the offered value and the value proposed by the peer.
It is important to notice the capability negotiation process can occur anytime during the life of a OCP transport connection (for the lack of a better term), not necessarily when a connection/channel/transaction is established.
----------