Re: Proposed text for Section 3.1

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 17:00:56 UTC