Subject: Re: Capability Negotiation for OCP

From: Alex Rousskov <[email-masked]>
Date: Fri, 16 May 2003 11:28:25 -0600 (MDT)

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.