Basic RFC rule: informational specs are published.
In fact, that's not the rule. The rule is closer to:
The RFC Editor decides, unless the document is approved by IESG.
Because the RFC Editor has always exercised some degree of
editorial control, and has never published any random document
that someone submitted.
oh? that contradicts actual history, Keith, as well as the premise behind
the RFC series.
This is what Jon told both me personally and IESG, and I heard him
say it on multiple occasions. I don't believe the current policy is
significantly different. And the RFC series today isn't quite the
same as originally envisioned.
And, by the way, there is no empirical basis for claiming that all that
IETF review produces a useful effect.
No, there's not - because you can't do a controlled experiment.
"empirical" does not require a controlled experiment. however your
response does demonstrate the problem with our making strong statements
about human behavior. namely it demonstrates that we do not have the tools
for making such statements about future occurrences involving subtleties of
human choice.
We cannot make absolutely accurate predictions. We can, however,
exercise judgement based on experience.
But the IETF's role (for better or worse) is to try to determine
the sense of a broad community about which proposals are good
Again you are confusing IETF review and approval with IANA registration.
IANA registration of message header fields would essentially be an extension
mechanism for IETF protocols that use 822-style headers. IANA follows IETF
policy for registration of protocol extensions. Such policies vary from one
protocol to another. In particular, the ease of creating extensions varies
according to the a judgement of the benefit vs. harm that will ensue from
making extensions easy or difficult.
Keith