Two technical notes, and a suggestion concerning single letter/digit names
Steve is correct that the dotted quad syntax of inet_addr() permits dotted decimals of the forms d.d.d.d, d.d.d, d.d, and d, hence that labels of the form considered here will have unintended semantic outcomes when processed on POSIX 1003.1 (and its anteceedents) conformant implementations. I know this wasn't covered in the suite of tests X/Open made available to Unix vendors in the XPG 4.2 timeframe (I conducted conformance for Hitachi, Sun and HP for XPG 4.2), and I doubt the coverage now includes d.d.d, d.d, or d syntax. Steve's original note is referenced in Danny Younger's note in this fora of 16 October, msg00005.html. The issues John addresses, also referenced in Danny Younger's note in this fora the same day, msg00002.html, were discussed when RFC 2929, Domain Name System (DNS) IANA Considerations, was in draft. A very small portion of the discussion of labels is present in the final version, e.g., Text labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]. With that somewhat cryptically noted, I want to point out a potential which has existed since the SRS BOF at IETF-49. The reservation of single octet labels allows for the future possibility of implementing a shared registry system which uses single octet labels to distinguish instances of a shared registry. Of course, other mechanisms than a second-level single-octet lable-space can be used to implement a shared registry, but this particular mechanism, allowing a.com to refer to the A .COM registry instance, and b.com to the B .COM registry instance, etc, would allow user-visible policy to be associated with a mechanism for a shared registry. While this may seem far fetched to the jaded ICANNistas, particularly those who may jump to the conclusion that a shared registry is necessarily inconsistent, or that such sequences of labels must designate multiple namespaces, or that the C/N/O franchises to unitary operators is as fundamental as POSIX 1003.1, there is a stability and security nuance to the elimination of a user-visible choice (policy) allowing selection of an instance of a (mechanism) shared registry system that is the successor to a (potentially failed) single registry system. Allocation of labels previously reserved for non-infrastructural purposes precludes their use for infrastructure. Finally, if Overstock or Oprah and Yahoo and ... really are willing to move heaven and earth to get single character NAMEs, we need only recycle the IDNA syntax to create label semantics which encode single characters outside the two-or-more-ASCII-character space currently used for non-IDN NAMEs. Single character domain names are possible, we simply need to ensure these are not implemented as single octet labels, and that single octet labels do not appear in the root, or in second level domains. Eric (wearing the XPG/1 and XPG/4.2 (aka "Single Unix Specification") co-author hat for para 1, the rfc2929 co-author hat for para 3, the IETF-49 SRS BoF scribe hat for para 5, and the "at last, a use for IDNA hat" for para 7), and otherwise contributing to ICANN as a disinterested individual. |