Ned wrote:
In particular, I see very little evidence that all these
rules are helping us get things "right" in the only sense
that matters: Producing clear technical specifications
for the protocols people need.
For some RFCs I care about a few written or unwritten rules
helped to get it "right": It is just not allowed to ignore
IPv6, I18N, security, or IANA.
IMHO 2821bis is shorter and clearer since John replaced the
verbatim copies of 2119 definitions by a simple reference,
and his proposal to put that reference above the first use
of these key words would again improve 2821bis.
When somebody proposed to add new key words in a 2119bis to
indicate a SHOULD expected to become a MUST later I thought
"omigod, folks *just* agreed on using 2119, why can't they
stick to it now ?" (For a value of *just* = 2821bis-07 in
2008)
When 2821bis and 2822upd are STDs I hope that MIME can be
also advanced mostly "as is", updating the syntax to ABNF,
plus some on topic remarks in the security considerations.
Using the same STD 68 ABNF everywhere, as far as RFCs use
a form of syntax where that makes sense, is friendlier for
readers, especially implementors and operators. It's not
that the STD 68 style is especially nice, but it is good
enough, and a consistent style in related RFCs is a good
thing. E.g. the oddities of #-constructs almost guarantee
interoperability issues, and STD 68 doesn't offer this #-
"feature". In theory folks could reinvent it <shudder />
[about the "cut-off" ritual]
The painful reality is that another effect of all these
byzantine rules is that fewer and fewer people are
willing and able to navigate the treacherous waters we
have created.
Getting an RFC number for an Internet Draft is extremely
difficult for folks not familiar with those byzantine
rules. Now if your proposal boils down to "undocument"
some "de jure" rules while their "de facto" variants are
still used it would be worse. My approach (after MARID)
was "your only chance is to grok all their weird rules,
and then beat them in their own game". Quite literally,
IIRC I started to expriment with the "A. Mouse" xml2rfc
example days after that WG was terminated. At that time
Brian's marauder's map did not yet exist, unfortunately.
And I was determined that RFC 4408 will follow any comma
in any stylistic rules, I-D checklists, or BCPs, expired
or otherwise, that somebody could dig up in a Last Call.
[Various folks including me still missed the detail that
IETF Last Calls are not required for "IETF experiments"
in those byzantine rules. Today I'd know where to find
"IESG review" at the end of chapter 4.2.3 in RFC 2026.]
Unsurprisingly I'm now stunned when folks propose to use
say an IPv6 address not covered by RFC 3849 in examples,
or have syntax errors in their ABNF in an IETF Last Call.
Those "byzantine rules" can also protect folks, and they
might need protection from the PTB far more urgent than
the elimination of some (documented) questionable rules.
Frank