One of the points that I should have made in response to Jari is that a major limitation in his thinking is that he sets out the function of IANA as an IETF support service rather than an Internet support service.
The distinction is important as there is no reason that IANA should only be used by the IETF. The IETF is not the only Internet standards making organization and I hope to see many, many more. There is a natural limit to the size of organizations and the IETF is at that point. So are OASIS and W3C. We cannot attempt to scale the development of cool Internet uses by increasing the size of the IETF and it is counterproductive to try.
If we look at the wider context, there are now communities focused on single applications that are roughly the size of IETF areas. The Linux plumbers is the size of the IETF at a similar stage in IETF growth. They will soon grow to about the same size.
We can't scale organizations but we CAN scale the IANA. The function of the protocol registries is simply to avoid ambiguous name assignments. Why limit scope to just protocol?
--
Website: http://hallambaker.com/
On Sun, Jan 5, 2014 at 3:06 AM, Patrik Fältström <paf@xxxxxxxxxx> wrote:
Bill, it was not Jari, it was Phillip Hallam-Baker that said "unlimited", which I objected to.
On 5 jan 2014, at 07:16, manning bill <bmanning@xxxxxxx> wrote:
> Jari, you can’t be serious. unlimited means -without- limit, not just the limits of your imagination.
And I excluded the very protocols you used as examples in your counter argument. So complaining about Bill mistaking attribution is a bit rich.
And I said 'effectively' unlimited which means without effective limit, i.e. sufficiently large that there is no conceivable circumstance in which we would need more. So suggesting that the identifiers need to be infinitely long is yet another straw man.
RFC822 header tags are not in fact unlimited, I can't remember the limit offhand but for practical purposes it is 20 bytes. But that is still enough space to encode a 100bit random identifier in base32 which is certainly 'effectively unlimited'.
The test is whether the risk of code point exhaustion is justification for limiting registrations. If someone can make the argument that 'we might run out' then obviously the number of code points is not effectively unlimited.
What I am trying to get away from here is the expectation that every protocol is going to have a separate registry for every item that might need to be identified.
Shaving a few bytes should not be an excuse to create a new ongoing maintenance requirement for IANA and creating an extensibility nightmare which is what short fixed length codes do.
Now what we could do that would achieve most goals for most people would be to have a single registry of text labels. Each entry would have four pieces of information:
1) The label itself
2) A unique numeric code
3) The purpose for which the label is defined
4) References
So "AES" would have the entry
"AES" 4242 Algorithm/Encryption FIPS-yada-yada
There might then be additional information in the Algorithm/Encryption registry which would continue to provide additional information (e.g. the OID assignment, modes etc).
Signup would be by simply entering filling out a web form, similar to the allocation of OID arcs.
The advantage of this approach is that if someone wants to simply reserve a label to prevent a conflicting use, this is easily done. It is not even necessary to specify the use.
The numeric codes can be used for the handful of protocols where byte shaving is a real concern. A new protocol using the technique would have to make provision for allowing 64 bit codes but it is unlikely the registrations would exceed a 4 byte space any time soon.
Another use for the codes would be to define an OID assignment and a URI form of the same label. Since some codes already have OID and URI forms, these need to be tracked but that would be best done separately.
I would do this with two registries, one for OIDs, the other for URIs which would list the code points that are synonyms for codes listed in the text label table and whether they are canonical.
The current situation suffers from the hierarchical fallacy which is the mistaken belief that it is useful to separate identifiers by category. The prime example of this failed notion being the .com, .net and .org registries in DNS which do nothing but confuse.
Separating the registration of encryption algorithms from other crypto algorithms does not help because it should be obvious that if FOO is a symmetric encryption algorithm identifier, it cant be a digest algorithm either. It is also the case but somewhat less obvious that the FOO label can't then be a RFC821 command or a RFC822 header either. At least not unless the use of FOO in the other context is completely specified and constrained by the symmetric encryption spec.
If we rationalize the operation of IANA we can reduce the amount of work required in both the IETF space and the IANA. More importantly we can encourage all the other standards organizations to rely on IANA to register code points.
Website: http://hallambaker.com/