Message-Id: <200007281329.JAA02267@astro.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Charles Lindsey <chl@clw.cs.man.ac.uk>
cc: drums@cs.utk.edu
Subject: Re: 2nd suggested revision for MUST/SHOULD 
In-reply-to: Your message of "Fri, 28 Jul 2000 09:39:22 BST."
             <200007280839.JAA07092@clw.cs.man.ac.uk> 
Date: Fri, 28 Jul 2000 09:29:23 -0400
Sender: moore@cs.utk.edu

> But I see little point in repeating the 2119 text in full.

as Dan pointed out, there is language in 2119 (specifically 
section 6) that over-constrains use of 2119.  since 2119
was published it is apparent that there are valid reasons
to use 2119 keywords that  are not "actually required for 
interoperation or to limit behavior which has potential 
for causing harm" ... especially when we base try to define
conformance to the specification strictly in terms of 
these keywords.

the normal workaround (until 2119 is revised) is for a
document to provide its own definitions of MUST/SHOULD/etc.
I suppose we could try referencing 2119 with a disclaimer
that section 6 does not apply...and see if that gets by IESG.
if we wanted to try this I'd strongly recommend that someone 
approach the author of 2119 first and ask him in person about it.

one thing that worries me about defining conformance in this way:
do we have confidence that adhering to the MUSTs SHOULDs etc
is sufficient to call an implementation conforming, in the
sense that we believe that the implementation will function
properly and interoperate with other implementations?
or are there enough things in the document that are not specified
in this way?

somehow I don't like the idea that "if the document doesn't
say MUST or SHOULD about a particular thing, it's not needed
for conformance, so we can disregard it"

Keith