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

[Vint Cerf]

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