> > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf