While I agree (and strongly so), there is lots of precedent for
the IESG rejecting parameter registrations because of distaste
for a particular extension, presumably in the hope that "no
registered value" will imply "the unpopular extension idea goes
away".
There are indeed lots of precedents for this. And speaking as someone
who, as media types reviewer, has had had to clean up the mess as best I could
when we were overly restrictive with one of these things, there is also
precedent that doing this can be a REALLY bad idea.
I agree with Ned. The main purpose of the registry should be to document what
is out there, not to act as a gatekeeper. Even when a protocol is not a full
standard, having a public documentation is useful. Documentation enables
filtering, monitoring, even debugging.
By the way, other institutions have found ways to decouple number collision
avoidance and registration. IETF protocols use short fields for parameter
identifiers, small number spaces that effectively mandate registration in order
to avoid collisions. This is an engineering decision that trades administrative
hassles for shorter messages. It is not the only choice. Other design have used
Object Identifiers (SNMP, ASN.1), or Universal Resource Locators (most W3C
protocols). OID and URL requires some amount of registration, to obtain a node
in the hierarchy, but allow for decentralized allocation of identifiers in
these hierarchies. If you don't want to use a hierarchy, you can also use GUID,
essentially a 128 bit random number. Open extensibility with OID, URL or GUID
is, in my opinion, a better design than relying on registries for number
allocations.
-- Christian Huitema
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf