> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Mark Nottingham > Sent: Monday, August 29, 2011 5:08 PM > To: Peter Saint-Andre > Cc: IETF discussion list > Subject: Re: 2119bis > > Thanks for starting this, Peter. A few comments / topics for > discussion: > > 1) I agree that the "SHOULD... UNLESS" pattern ought be documented. I had never thought of this before. I kind of like the idea, especially since SHOULD has always meant "MUST unless you really know what you're doing" but that last bit, though strong, is still pretty subjective. Having a tool to make it more explicit is a nice idea. > 2) I strongly believe that authors should be encouraged to enumerate > the potential subjects of conformance terms, and to use them in every > instance. > > For example, a requirement like this: > > """The Foo header MUST contain the "bar" directive""" > > is ambiguous; it doesn't specify who has to do what. Rather, > > """Senders MUST include the "bar" directive when producing the Foo > header; recipients that receive a Foo header without a "bar" directive > MUST ...""" > > is unambiguous (assuming that the spec defines the terms "sender" and > "recipient"). ...or at least say at the bottom of such a collection that fields/messages/pages/whatever that don't conform MUST be (default treatment here). > 4) WRT to the status of the document -- if people really feel that we > don't need to revise 2119, I'd define this as a superset of 2119 and > NOT obsolete it; i.e., have documents opt into it. However, I'd hope > that we can get consensus that it's time to build on what 2119 offers. I don't see a big deal with rendering RFC2119 obsolete. Or perhaps more accurately, I don't like the argument that we can't just because lots of outside SDOs reference it, or any similarly useful BCP we use could become set-in-stone as soon as others decide they like it. We have a mechanism for checking whether a given RFC has been replaced or not; we all have to learn to use it, so I think others should as well. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf