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.
----------