Re: I-D Action:draft-liman-tld-names-00.txt
Vint Cerf <vint@google.com> Wed, 11 March 2009 19:42 UTC
Return-Path: <vint@google.com>
X-Original-To: idna-update@alvestrand.no
Delivered-To: idna-update@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D334139E2D4 for <idna-update@alvestrand.no>; Wed, 11 Mar 2009 20:42:14 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsQbPbDkWpbX for <idna-update@alvestrand.no>; Wed, 11 Mar 2009 20:42:13 +0100 (CET)
X-Greylist: domain auto-whitelisted by SQLgrey-1.6.8
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 64B8C39E0BB for <idna-update@alvestrand.no>; Wed, 11 Mar 2009 20:42:12 +0100 (CET)
Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n2BJg91J013322 for <idna-update@alvestrand.no>; Wed, 11 Mar 2009 12:42:10 -0700
Received: from an-out-0708.google.com (ancc2.prod.google.com [10.100.29.2]) by zps18.corp.google.com with ESMTP id n2BJg0MZ024150 for <idna-update@alvestrand.no>; Wed, 11 Mar 2009 12:42:07 -0700
Received: by an-out-0708.google.com with SMTP id c2so104312anc.22 for <idna-update@alvestrand.no>; Wed, 11 Mar 2009 12:42:05 -0700 (PDT)
Received: by 10.220.81.5 with SMTP id v5mr3623637vck.103.1236800525103; Wed, 11 Mar 2009 12:42:05 -0700 (PDT)
Received: from dhcp-172-29-47-42.her.corp.google.com ([208.253.108.65]) by mx.google.com with ESMTPS id 4sm616288yxj.51.2009.03.11.12.42.03 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 12:42:04 -0700 (PDT)
Message-Id: <B4A0D225-B279-4F8C-9897-8F6B612597E5@google.com>
From: Vint Cerf <vint@google.com>
To: Eric Brunner-Williams <brunner@nic-naa.net>
In-Reply-To: <49B7F130.2040202@nic-naa.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: I-D Action:draft-liman-tld-names-00.txt
Date: Wed, 11 Mar 2009 15:42:02 -0400
References: <20090304010001.D285A3A68CF@core3.amsl.com> <49B7F130.2040202@nic-naa.net>
X-Mailer: Apple Mail (2.930.3)
X-System-Of-Record: true
Cc: "idna-update@alvestrand.no" <idna-update@alvestrand.no>, "dnsop@ietf.org" <dnsop@ietf.org>, liman@autonomica.se
X-BeenThere: idna-update@alvestrand.no
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IDNA update work <idna-update.alvestrand.no>
List-Unsubscribe: <http://www.alvestrand.no/mailman/listinfo/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=unsubscribe>
List-Archive: <http://www.alvestrand.no/pipermail/idna-update>
List-Post: <mailto:idna-update@alvestrand.no>
List-Help: <mailto:idna-update-request@alvestrand.no?subject=help>
List-Subscribe: <http://www.alvestrand.no/mailman/listinfo/idna-update>, <mailto:idna-update-request@alvestrand.no?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 19:42:15 -0000
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@google.com On Mar 11, 2009, at 1:13 PM, Eric Brunner-Williams wrote: > Internet-Drafts@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@alvestrand.no > http://www.alvestrand.no/mailman/listinfo/idna-update
- Re: I-D Action:draft-liman-tld-names-00.txt Eric Brunner-Williams
- Re: I-D Action:draft-liman-tld-names-00.txt Vint Cerf
- Re: I-D Action:draft-liman-tld-names-00.txt Eric Brunner-Williams