+1 Deprecating a code point is very different from deallocating it which implies that it is going to be given out again in the future. Last thing I want is a used code point. I agree that avoiding multiple allocations is also a function of IANA, but this is also something that argues for not being overly strict. If it is too hard to get an allocation then there will be multiple unofficial versions. Eventually there may be an attempt to pick one of them as 'official'. On Wed, Apr 25, 2012 at 1:46 PM, Ned Freed <ned.freed@xxxxxxxxxxx> wrote: >> I see no value in deallocating code point spaces and a huge amount of >> potential harm. > > It depends on the size of the space. I completely agree that if the space is > large - and that's almost always the case - then deallocating is going to be > somewhere between silly and very damaging. > > Deprecacting the use of a code point, OTOH, may make sense even if the space is > large. > > The takeaway here, I think, is that if you're going to "conclude" experiments, > you need to examine these allocations and do something sensible with them, > where "sensible" is rarely going to mean "deallocate". > >> Except at the very lowest levels of the protocol stack (IP and BGP) >> there is really no technical need for a namespace that is limited. We >> do have some protocols that will come to a crisis some day but there >> are plenty of ways that the code space for DNS, TLS etc can be >> expanded if we ever need to. > > There may not be any technical need, but there are a number of legacy designs > that were done ... poorly. > >> The Internet is driven by innovation and experiment. There are >> certainly people who think that the role of this organization is to >> protect the Internet from the meddling of people who might not get it >> but they are wrong. > > +1 > >> Even more wrong is the idea that IANA can actually act as suggested. >> IANA only exists by mutual consent. I am happy to register a code >> point if there is a reasonable procedure to do so. But if the idea is >> to force me to kiss someone's ring then I'll pick a number and ship >> the code and let other folk work out the problems later. > >> This already happens on a significant scale in the wild. SRV code >> points being a prime example. There are far more unofficial code >> points than recognized ones. Some of them are in standards I wrote at >> W3C and OASIS. It would be best if IANA tracked these but I think it >> rather unlikely anyone is going to accidentally overwrite the SAML or >> the XKMS SRV code points. > > Media types are an excellent example of this. The original registration > procedures were too restrictive so people simply picked names to use. We fixed > that for "vendor" assignments (fill in a web form) and the registrations > starting rolling in. (We're now trying to do the same for "standard" > assignments.) But of course we now have a legacy of unassigned material > to deal with. > >> It has happened with other registries too. Back in the day there was >> an attempt to stop the storage manufacturers using ethernet IDs on >> their drives. So the drive manufacturers simply declared a block of >> space (Cxxxxxx) as theirs and the IEEE has since been forced to accept >> this as a fait accompli. It has happened in UPC codes as well, when >> the Europeans decided that the US authority was charging them >> ridiculous fees they just extended the code by an octet and set >> themselves up as a meta-registry. > >> The only role of IANA is to help people avoid treading on each other >> by accident. If it starts issuing code points that have been 'lightly >> used', the value of IANA is degraded. I certainly don't want my >> protocol to have to deal with issues that are caused by someone's >> 'experiment' that has not completely shut down. The only value of >> going to IANA rather than choosing one myself is to avoid >> contamination with earlier efforts. > > No, not quite. The other important role is (hopefully) to keep people from > having multiple allocations for the same thing. > >> The only area where I can see the benefits of re-allocation >> outweighing the risks is in IP port assignments but even there I think >> the real solution has to be to simply ditch the whole notion of port >> numbers and use SRV type approaches for new protocols. > > +1 > >> IANA is not a control point for the Internet. A fact that people need >> to keep in mind when the ITU attempts to grab control in Dubai later >> on this year. > >> Weakness is strength: The registries are not the control points people >> imagine because they only have authority as long as people consent. > > Good point. > > Ned -- Website: http://hallambaker.com/