Re: Proposed text for Section 3.1

Good discussion going on.....thanks, this is helpful.  I accept Patrick's 
and Lofton's suggestions and will add the following bullet item to the list 
"all the statements using a capitalized keyword from RFC 2119"

This is basically what was there before.  It is also (as Lofton points out) 
redundant with the bullet about Conformance Requirements, but I also think 
that it is O.K. to have the more general item and then follow it with the 
more specific RFC item.

As for Susan's RFC keywords only used for interoperability - yes, she did 
bring this up as an issue a year ago, but also agree that we 'dance around' 
it.  Indirectly, I believe that it does enhance interoperability, since the 
ultimate goal is to make specs better and more testable so that they can be 
interoperable.  The key will be if we can get her to accept our resolution.
--
lynne


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

>At 03:37 PM 4/18/03 -0400, Lynne Rosenthal wrote:
>
>>Patrick.
>>
>>Thanks for commenting and helping to clarify this.
>>
>>Can you propose specific text to include?
>>Do you mean, include the bullet item that is currently in the text: "all 
>>the sentences using a capitalized keyword from RFC 2119"
>>Would this also mean that only sentences with RFC 2119 keywords are 
>>normative, and not other things?
>
>If you decide to go this way (and I mildly favor it), I wouldn't use 
>"sentences", which has been rightly criticized.  Use "statements", as you 
>currently use in one of your three new bullets.  (And lets *not* argue 
>about the boundaries of "statements".)
>
>
>>Typically, I've seen sections of text identified as Normative or 
>>Non-normative, and not just the sentences containing RFC 2119 
>>terminology.  LC-65 asked, "Is a sentence containing an RFC 2119 keyword 
>>a unit of being normative, or do you mean that the paragraph containing 
>>such a sentence is or can be the unit?.
>
>"Statements" -- can be a short phrase, a sentence, a collection of 
>sentences or phrases, etc.  (A statement is more or less a "unit of 
>meaning", but ... let's not go there.)
>
>>So, if a Conformance Requirement contains several sentences, but only one 
>>of those sentences have a MUST (or whatever), then what about the rest of 
>>the sentences in the Conformance Requirement?
>
>Why not include both a RFC bullet and your current "ConfReqs" 
>bullet?  Okay, they're redundant.  But so what?  It allows the possibility 
>to put normative statements (using RFC2119 keywords) in other places in 
>the specification.
>
>
>>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 Friday, 18 April 2003 20:38:38 UTC