My first reaction was that the entire topic is a bike shed. The goal is clear
and understandable specifications and 2119 is just a tool we use to make the
process of producing and reading specifications more efficient.
What I'm getting from this is that there are a significant number of drafts
being submitted to the IESG for publication that are not sufficiently precise
in their use of language.
Deciding to revise 2119 seems - at first blush - an interesting reaction to
this problem. But it's become evident that we don't share a common
understanding of the language, nor are we consistent in its application.
Formalizing usage patterns (c.f. server MUST/client MAY, MUST...UNLESS...) does
help, if only because you've made it easier to do the right thing in more
cases. If the problem is that authors and editors don't have the tools they
need, then maybe a revision is the right approach.
However, I'd still like to see more RFCs that describe something without
resorting to using these crude implements.
On 2011-08-31 at 05:08:15, Adam Roach wrote:
There is no reason to tie authors' hands by restricting them from
using perfectly good English words just because they happen to be the
same symbols used by RFC 2119. If we're going down this path, let's
scrap using MUST/SHOULD/MAY/etc, and formalize our conformance terms
with symbols that aren't English words.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf