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

[Eric Brunner-Williams]

Sure.

Vint Cerf wrote:
> Eric, et al,
>
> I think it wise to move the discussion to dnsops and to remove from  
> idna-update, please, as has been suggested earlier. IDNAbis does not  
> deal with labels in a way that distinguishes TLDs from any other label  
> position in a domain name.
>
>
> Vint
>
>
>
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
>
>
>
>
> On Mar 11, 2009, at 1:13 PM, Eric Brunner-Williams wrote:
>
>   
>> 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
>>
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>     
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
>