On Wed, 5 May 2004, The Purple Streak, Hilarie Orman wrote:
OCP extensions are allowed to change normative OCP Core requirements
for OPES processors and callout servers. However, OCP extensions
SHOULD NOT make such changes and MUST require on a "MUST"-level that
such changes are negotiated prior to taking effect. Informally, this
specification defines compliant OCP agent behavior until changes to
this specifications (if any) are successfully negotiated.
Is "negotiated" used to mean a protocol operation in the second
sentence, and as a action within a standards body in the third
sentence.
The meaning of negotiation does not change from the second sentence to
the third. If something implies that it does, please be specific what
that something is or suggest a different wording. Note that the third
sentence is not normative. Basic OCP negotiations mechanisms are
defined in Section 6 "Negotiation".
I think that the IESG concern about negotiation is that if the state
machine for the core negotiaion changes as a result of negotiation
(in the protocol sense),
The state always changes as a result of a successful negotiation.
Otherwise, we did not negotiated anything!
you can easily get a resulting state machine that is unmanageable.
Infinite loops, deadlocks, etc. Can you add verbiage that indicates
why those bad things are not possibilities?
I cannot prove protocol correctness; it is possible that OCP Core
negotiation is flawed.
Unknown bugs notwithstanding, Section 6 "Negotiation", Section 11.18
"Negotiation Offer (NO)", and Section 11.19 "Negotiation Response
(NR)" contain specific rules/requirements that are meant to avoid
wrong state as a result of a negotiation. Note that specific feature
definitions (OCP Core does not define any features) may contain
additional requirements.
The section you quoted from above is about OCP extensions that may use
OCP Core negotiation mechanisms to adjust some OCP Core rules to
better fit their needs. The section has one example to illustrate the
need.
Thanks,
Alex.