At 11:10 AM +1300 1/16/08, Brian E Carpenter wrote:
The careful approach needed for phasing crypto algorithms
in and out may justify such terminology. However, I think
there is experience that careless use, in particular of
SHOULD+, which has crept into some non-IETF documents such
as
Paul,
On 2008-01-22 09:55, Paul Hoffman wrote:
At 11:10 AM +1300 1/16/08, Brian E Carpenter wrote:
...
The concept supplements not only RFC 2119 but also the
discussion of requirement levels in RFC 2026 section 3.3.
I think that should be mentioned.
That section of RFC 2026 talks about
At 12:49 16/01/2008, Paul Hoffman wrote:
At 1:43 PM -0500 1/15/08, John C Klensin wrote:
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
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
John C Klensin wrote:
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
At 1:43 PM -0500 1/15/08, John C Klensin wrote:
Translation: this seems like an interesting idea, but the
concepts are, IMO, probably much better expressed in nuanced
text rather than in cute codes.
This document does not prohibit, or even suggest against, individual
documents coming up with
The careful approach needed for phasing crypto algorithms
in and out may justify such terminology. However, I think
there is experience that careless use, in particular of
SHOULD+, which has crept into some non-IETF documents such
as procurement specifications, has great potential for
confusion.
