draft-hoffman-additional-key-words-00.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This document doesn't identify a mailing list for discussion, so
I guess it goes here.

The abstract says...
> Some document authors want to express requirement levels using
> the traditional definitions of "MUST" and "SHOULD" from RFC
> 2119, but also want to express that there is an expectation
> that later versions of the document may change those
> requirements.  For example, they may want to express "this
> SHOULD be implemented now, but we expect that this will become
> a MUST requirement in a future update to this standard".
> This document defines three new keywords, "MUST-", "SHOULD+",
> and "SHOULD-" to facilitate such definitions.

This is repeated in more detail in Section 1.

Hmm.  How about 

"MAY-" to denote "you can do this if you like, but we
	really don't like it and may (sic) prohibit it in the
	future if we can find a good excuse.
	
"MAY+-" to denote "we aren't sure about this yet, but are
	likely to either require or prohibit it in the future".
	
"SHOULD+-" to denote "this is either a pretty good idea
	or a pretty bad one.  Once we get some experience, it
	will turn into either SHOULD or SHOULD NOT (or maybe
	MUST or MUST NOT)

Translation: this seems like an interesting idea, but the
concepts are, IMO, probably much better expressed in nuanced
text rather than in cute codes.   A different version of the
same thinking would suggest that any document needing these
extended keywords is not ready for standardization and should be
published as Experimental and left there until the community
makes up its collective mind.

    john




_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]