I-D Action:draft-liman-tld-names-00.txt

[Eric Brunner-Williams]

Internet-Drafts at ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Top Level Domain Name Specification
> 	Author(s)       : L. Liman
> 	Filename        : draft-liman-tld-names-00.txt
> 	Pages           : 9
> 	Date            : 2009-03-03
>
> RFC 1123 is ambiguous regarding the specification for top level
> domain (TLD) labels used in the domain name system.  This document
> clarifies the specification, and aligns it with current praxis,
> including the use of Internationalized Domain Name (IDN) Labels in
> TLD names.
>   
Lars-Johan,

Updating 1123, and 1122, is a good idea, and a lot of work went into 
them, not just by the editor, Bob Braden, but by dozens of people. So my 
first comment is a meta-comment to the effect that 1123 is not 
"ambiguous regarding the specification for top level domain (TLD) labels 
used in the domain name system". We didn't attempt to rigorously specify 
rlogin, telnet, ftp, smtp, or the dns, see the language in section 7 
"This section lists the primary references with which every implementer 
must be thoroughly familiar", the absence of "this obsoletes" language, 
and the stated purpose -- "incorporates by reference, amends, corrects, 
and supplements the primary protocol standards documents relating to 
hosts". What we attempted was to make some corrections, known to some of 
us, circa 1989. We did not exhaust the space of possible ambiguities in 
existing specifications, though none known were omitted to my knowledge 
by intent (and I don't have notes from that period anyway, so this is 
all personal memory), nor did we consider the possibility that the dns 
would ever cease to be policied by some public trust body, or that names 
would become trademarks (though we were all fond of memorable landmarks 
like sri-arpa), and many other fine, and not so fine things that would 
emerge in the next 20 years.

So either the text in section 2.1 of 1123 is low hanging fruit which is 
opportunistically picked in the momentary context of the third round of 
new gTLD activities by the Current New Entity (ICANN), or 1123 is 
perfect except for this one little bit which needs a little bit of 
editorial review and as a mater of convenience, is intended to be 
published as a separate RFC rather than as a revised version of 1123.

Restated more briefly, I suggest that rather than assert 1123 is 
ambiguous and you're going to fix it, a technically neutral act, you 
simply state what it is you're advocating, possibly in a disinterested 
fashion.

Next, it is a convention, which Donald, Bill, and I observed in 2929, 
that "[t]ext labels can, in fact, include any octet value including zero 
octets but most current uses involve only [US-ASCII]." The nuances I 
recall that Donald and I exchanged notes over during the drafting was 
that labels could indeed be one octet, or more, and could be any value, 
though the practice at the time was the printable range of 7-bit ASCII, 
and the LDH subset of that range. So the statement in your section 2 
would be that you'd like to assert a policy for a registry, the IANA 
root as it happens, and there's nothing wrong with writing registry 
policy, its something of a cottage industry in the ICANN g- and 
cc-playpens, but it isn't a protocol specification.

So you'd like two (or more) ASCII alphas, which the iso3166-1 MA may be 
comforted by, with the possibility of an infix digit or hyphen or 
sequence of infix digits (but not a sequence of infix hyphens) as the 
number of octets in the label increases to three or more.

That's fine registry policy. As reasonable, as registry policy, as the 
Arab League's insistence that domain names be real words, or the .cn 
registry's policy (circa 2001, it may have changed) not to allow the 
names of current or former prominent persons in the Chinese Communist 
Party to be allocated, or the .us registry's policy that authoritative 
nameservers be located in the United States. But it isn't a protocol 
specification.

There is no technical necessity to use only 7-bit ASCII. We (IDN-pre-A) 
could have chosen to make the lives of the 7-bit mailers, and others, 
harder. Whether the better possible choice was made was opinion then, 
and now, of a community of engineers with differing skills, and agendas, 
but the ASCII encoding form initially (and unilaterally deployed) by 
Verisign is what was chosen, but not because of any constraint integral 
to the DNS.

My suggestion is that you re-write this as a proposed registry policy to 
bind on the United States, and its contractors, in particular, Verisign 
and ICANN, and their subcontractors, the current and potential TLD 
operators, and of course, the root server operators. I don't think it is 
particularly good policy, but it is policy and if its what you want, 
write it as proposed policy and then sell the hell out of it.

At last I see why Andrew has been asking if anything when punycoded can 
end with a digit, but there is a policy consideration to entertain also 
when asserting a two-octet label may not contain a digit, independent of 
any encoding issue, which I've communicated privately to Tina Dam, and 
eventually I'll post to this, or the IDNAbis, or both, lists.

Section 3 is not useful, because whether you use BNF or not, there is no 
technical content to Section 2, just a policy statement.

Section 4 should be re-written using MUST and MUST NOT terms. You are 
proposing a policy that the IANA be required to implement, to the 
exclusion of all other policies. This is why we have the language from 
2119 and all those ugly upper-case ASCII characters shouting for attention.

Section 5 is simply wrong. Not because no implementations exist which 
are broken, but because we flat don't care. If we did care, we would 
have pulled back the .museum TLD because its length was greater than 3 
and the string wasn't "arpa".

Please don't take this hard, when I proposed that rfc954 be "historic" 
Bob Braden commented that the world would end (slight exaggeration) if 
whois wasn't around and running on port 43, and I'll buy you a beer in 
San Francisco.

Best,
Eric