Re: Minutes for 20030707 telecon

Following all of the discussion of LC-67 part 1 (before and at Crete, and 
email after Crete), the QAWG resolution needs to be minuted, for the 
record.  See below for my quick paraphrase of the result.

At 04:19 PM 7/7/03 -0400, you wrote:
>[...]
>LC-67 part 1 [5]
>
>(LH) We have three suggested alternatives for this issue. There is not a 
>single correct way that we can define or address all environments. The 
>alternatives capture the main ideas. We want to promote the RFC keywords. 
>Must all conformance requirements use RFC2119 keywords? There it could be 
>other alternatives, different variations. Not clear why Ian chose a hybrid 
>method.
>I will like Ian to help understand.
>
>(IJ) : The HTTP specification uses the RFC key words to reach two 
>conformance levels; the unconditionally compliant and the conditionally 
>compliant. We have more profiles than that, we have more granularity, RFC 
>key words enables
>only one conformance level; the must requirements. Also UAAG uses the 
>imperative voice to express the requirements, so the "MUST" is usually 
>implied, it was also easier to read.
>
>(MS) : When things are equally recognized as a requirement, by using the 
>keyword it will be easier to recognized, specially for people that are not 
>familiar with the specification.
>
>(IJ) : When I started writing, I was concerned about readability.
>
>(MS) : We are back to a philosophical argument.
>
>(IJ) : In UAAG, A/AA/AAA was not going to suffice. It should be a strong 
>recommendation to use the standard terms, but allowing leeway.
>
>(LH) : Alternative 3 proposes a rewording of the conformance requirements 
>with four requirements to capture the idea that you must use RFC keywords, 
>or some equally clear and unambiguous method and a requirement to also 
>find a relationship between the alternative method and the RFC keywords.
>The second bullet could be a "should". Also, the method chosen should be 
>documented and we can point to the UAAG in the Examples and Techniques.
>
>(IJ) : Adding a statement explaining the choice.
>
>(LH) : It is a judgment call where to put the justification for using an 
>alternative to RFC 2119. The alternative chosen (1, 2 or 3) could be in 
>the conformance clause or terminology sections.
>
>(LR) : It should be somewhere in the specification, the conformance clause 
>is a possible place.
>
>(MS) : It must be in the conformance clause.
>
>(IJ) : CP 13.2 focus is on the identification of requirements and the need 
>to be clearly identified and distinguished.
>
>(AR) : What is the difference between normative and conformance requirement?
>
>(LF) : You can have declarative text identified as normative.
>
>(AR) : If it affect conformance, it should use RFC keywords.
>
>(DM) : Alternative 3 propose that every specification must address the
>    use or not use of the RFC keywords.
>
>(LH) : The difference between alternative 2 and 3 is the requirement of
>    why using or not and the use of mapping.
>
>(MS) : - There is nothing about justifying in the alternatives.
>
>(LH) : My mistake for not reading the thread.

Pls add, "It was intended, but omitted."


>(MS) : Justifying why you are not using the keywords should be addressed.

Result should go here, which is the end of the minuted discussion of the 
issue...

Strawpoll showed that all, except for one dissenting opinion, supported 
Alt.2, where Alt.2 is understood (after some discussion) to include an 
essential point that was unclear earlier:  the specification must include 
(in Conformance Clause) rationale/justification if the specification uses a 
method other than or in addition to RFC2119 keywords to express conformance 
requirements.

The conceptual summary of the resolved alt.2 is:  SpecGL will strongly 
encourage RFC2119 keywords as the most widely applicable and usually the 
best method, but exemptions are allowed if they are clearly defined in the 
spec, and if the rationale for not using RFC2119 keywords is explained in 
the spec.

>LC-70, reformat checklists [2]

Regards,
-Lofton.

Received on Thursday, 10 July 2003 01:01:45 UTC