W3C home > Mailing lists > Public > www-qa-wg@w3.org > April 2003

rfc2119 & LC-67 [was: Re: Proposed text for Section 3.1]

From: Lofton Henderson <lofton@rockynet.com>
Date: Sat, 19 Apr 2003 10:10:39 -0600
Message-Id: <5.1.0.14.2.20030419100033.01e0f560@terminal.rockynet.com>
To: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Cc: www-qa-wg@w3.org

Upon thinking about this a little more:

** I'm convinced that we should NOT, in SpecGL, try to legislate how to 
properly use the 2119 keywords;

** "how to use 'em" -- it sounds like a Technique, no?

So, a constructive proposal...

I think it would be interesting for someone to develop a Note about this -- 
application and appropriate use of RFC2119 keywords across the diverse 
spectrum of W3C standards.  As I said (below), I think RFC2119 is written 
with a particular mind set about the scope of things to which it would be 
applied.  At the fringes or outside of that implicit scope, some creative 
interpretation is required.

Such a Note could be linked from ExTech.

Who is the "someone" to write it?  A collaboration between us (QAWG) and 
Comm comes to mind.

Proposed resolution of #67:

1.) SpecGL should not try to legislate how to properly use the 2119 keywords;
2.) "how to use" would fall in the domain of SpecET, and should be 
implemented by developing a W3C Note about it (perhaps as QAWG/Comm 
collaboration).

-Lofton.

At 03:02 PM 4/18/03 -0600, Lofton Henderson wrote:

>At 03:37 PM 4/18/03 -0400, Lynne Rosenthal wrote:
>[...]
>>In a side note, I'm also concerned about how we will resolve LC67, Susan 
>>Lesch's caution about using RFC 219.  "Imperatives of the type defined in 
>>RFC2119 nust be used with care and sparingly.  In particular, they MUST 
>>only be used where it is actually required for interoperability or to 
>>limit behavior which has potential for causing harm."
>>Do we believe that our requirements are necessary for 
>>interoperability?  I guess we must.
>
>I consider this a non-issue.  When we say MUST, then it is absolutely 
>required for conformance to SpecGL.  Is conformance to SpecGL required for 
>interoperability?  I guess we think so, but I'm not gonna' get into that 
>argument.
>
>Btw, I consider that the text in RFC2119, ""6. Guidance in the use of 
>these Imperatives", is somewhat myopic about the scope of applications 
>that use RFC2119 keywords (go read it).  The authors really had a mind-set 
>for protocols and communications, and the definitions reflect those 
>mindsets.  However they are being applied in a much wider domain 
>throughout W3C now, and the way that some of the definitions and 
>guidelines are stated seem ... quaint.  (The definition/guidance of SHOULD 
>is interesting -- it uses all sorts of superlative qualifiers that add up, 
>"really, really, recommended", as if that adds some testability to the 
>untestable concept of conformance to SHOULD.)
>
>Susan's proposal on #67 is to include some wording in SpecGL 
>like:   "Imperatives of the type defined in this memo must be used with 
>care and sparingly. They MUST only be used where it is actually required 
>for interoperation or to limit behavior which has potential for causing 
>harm (e.g., limiting retransmisssions) For example, they must not be used 
>to try to impose a particular method on implementors where the method is 
>not required for interoperability."
>
>Are those "must" supposed to be "MUST"?  In other words, the proposal is 
>to add language to SpecGL to give guidance to other spec writers about 
>proper use of RFC2119 keywords.  Ugh!
>
>Bottom line.  Dodge the issue.  We I think we are using the keywords 
>appropriately.  It requires a little context-specific interpretation of 
>what RFC2119 says.  I don't think that any text should be added to 
>SpecGL.  (Alternative.  Request that Comm produce a W3C version of 
>RFC2119, where definitions have been genericized and neutralized a little 
>better.  A definite bad choice is -- putting qualifying language about the 
>keywords into each and every TR.)
>
>-Lofton.
>
>
>>regards
>>Lynne
>>
>>
>>
>>At 03:08 PM 4/18/2003, Patrick Curran wrote:
>>
>>>I'm still uncomfortable that we're trying to define what's normative by 
>>>identifying sections of the spec rather than by the language that we 
>>>actually use in the spec. I'd prefer a reference to the RFC 2119 
>>>terminology, as we had in an earlier draft. I don't have a problem with 
>>>defining sections as non-normative (informative), but I think that 
>>>unless we say this, all sections should be considered potentially 
>>>normative, with the actual determination being the language used.
>>>
>>>Can someone explain to me why they think this approach won't work?
>>>
>>>Thanks...
>>>
>>>
>>>Lynne Rosenthal wrote:
>>>
>>>>The following is proposed new text for Section 3.1, addressing 
>>>>LC-36,65,106, 108
>>>>Please comment if you do not agree with this proposal.
>>>>
>>>>Section 3.1 Normative Parts
>>>>
>>>>The following parts of this document are normative.        Statements 
>>>>prefaced by the keywords, /Conformance Requirements
>>>>/       The priority level associated with each checkpoint statement 
>>>>(title)
>>>>       Section 3, Conformance
>>>>
>>>>Text that is designated as /normative/ (@@ink to definition) is 
>>>>directly applicable to achieving conformance to this document.
>>>>Informative parts of this document consist of examples, extended 
>>>>explanations, terminology, and other matter that contains information 
>>>>that should be understood for proper implementation of this document.
>>
>
>
Received on Saturday, 19 April 2003 12:08:45 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:13 GMT