Here is an outline of capability negotiation and query messages, based
on Reinaldo's original design. I am working on adding these to the OCP
draft (the text below does not imply any encoding!). Please comment.
Thank you.
* Typical negotiation
P: negotiation-start id=1
P: offer feature-id=A [parameters]
P: offer feature-id=B [parameters]
P: offer feature-id=C [parameters]
P: offer feature-id=D [parameters]
S: ack feature-id=A // absolute agreement
S: ack feature-id=B [parameters] // selects param subranges
S: nack feature-id=C // absolute disagreement
S: donno feature-id=D // does not know about D
P: offer feature-id=E [parameters]
S: ack feature-id=E
P: negotiation-end status
* OPES processor MUST initiate negotiation when the connection
is open. After the first negotiation, either agent may initiate
negotiations (but see below for collision avoidance).
* Feature ID is a URI. OCP will probably document a few
features, such as support for data copying.
* Some features may include optional or mandatory parameters,
specific for each feature. Parameters may include ranges or sets of
values.
* No OCP messages other than capability negotiation offers/queries
or answers to them must be sent while negotiation is going on.
* Answers (ack, nack, donno) must follow offers order and must be
generated without waiting for more OCP messages.
* Do we want to repeat feature IDs in answers? Should we refer
to a question by message ID instead? Should we avoid any references
since, technically, the order determines the mapping in compliant
implementations?
* Since both OCP agents can initiate negotiations in the middle
of a transaction/connection, we must insure that only one agent is
in the offering role. If we allow concurrent offers from both sides,
the agents may deadlock waiting for each-other answer and/or will
have trouble generating answers (e.g., "I can enable copying but
only if you support encryption, and you did not answer me about
encryption yet").
The proposed solution is to give OPES processor a priority: the
processor will ignore concurrent offers from a callout server, and
the callout server will know that OPES processor is ignoring server
offers by comparing negotiation identifier, which is incremented
sequentially by the initiator.
* The status field of negotiation-end message will determine
success or failure of the entire negotiation blob
* The other agent can increment and start using negotiation ID once
negotiation-end message is received
* An example of capability Q&A (not negotiation!)
S: can-you feature-id=A [parameters]
P: i-can feature-id=A [parameters] // may select subranges
P: can-you feature-id=B
S: i-cannot feature-id=B // no support for B
P: can-you feature-id=C
S: i-donno feature-id=C // unknown feature C
P: can-you feature-id=D
S: no-comment feature-id=D // see comments below
* Capability queries can be submitted at any time and do not require
negotiation identifier/scope.
* Answers (i-can, i-cannot, i-donno, no-comment) must follow query
order and must be generated without waiting for more OCP messages.
* a no-comment response means that no definitive answer (i-can,
i-cannot, or i-donno) can be generated at this time;
perhaps this response should be named "ask-later" or "no-comment"?
* implementors and users are warned that capability query response
indicates current status and may differ for two queries with the
same feature-id. In other words, no commitment is assumed by
generating a query response. (If commitment is needed, negotiation
is required).
* Do we need a do-you query to get actual parameters in use
as opposed for supported parameters that i-can returns?
Thanks,
Alex.