- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Thu, 06 May 2004 21:29:49 +0100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: Mark Skall <mark.skall@nist.gov>, www-qa@w3.org
Alex Rousskov wrote: > > On Wed, 5 May 2004, Mark Skall wrote: > > >>>>I think the word *additional* is crucial - an extension which >>>>negates the base specification is not an extension but a change. >>>>Of course, quite what constitutes "negating" is domain dependent. >>> >>>I don't think so, changes make something ambiguous, you can infer >>>different things from the same thing prior and after the change, >>>even though the input remains the same. With an extension you have >>>different things where you naturally infer different things from. >> >>I agree with Jeremy. When we write specs and include the concept of >>extensions we say something like " the additional feature/function >>cannot contradict or cause the non-conformance to other >>features/functions in the spec." > > > FWIW, here is what seems like a counter-example from OCP Core protocol > specs that IETF OPES WG is working on: > > 1.3 Terminology > ... > OCP extension: A specification extending or adjusting this document > for adaptation of an application protocol (a.k.a., application > profile, e.g., [I-D.ietf-opes-http]), new OCP functionality (e.g., > transport encryption and authentication), and/or new OCP Core > version. > ... > > 15.1 Extending OCP Core > > OCP extensions MUST NOT change OCP Core message format, as defined by > ABNF and accompanying normative rules in Section 3.1. The intent of > this requirement is to allow OCP message viewers, validators, and > "intermediary" software to at least isolate and decompose any OCP > message, even a message with unknown to them (i.e., extended) > semantics. > > 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. > ... > > > This information is outside of the scope identified in the Subject > line, but I hope you find it useful. > > Alex. > That text is clever ... it allows extensions to negate the original spec but only after a negotiation which meets Mark's criteria of not "break[ing]" the other parts of the spec. Jeremy
Received on Thursday, 6 May 2004 16:30:31 UTC