Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
Vint Cerf <vint@google.com> Wed, 11 March 2009 19:41 UTC
Return-Path: <vint@google.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C4128C0E6 for <dnsop@core3.amsl.com>; Wed, 11 Mar 2009 12:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.299
X-Spam-Level:
X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TEXT=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaZ-X+o4tUbu for <dnsop@core3.amsl.com>; Wed, 11 Mar 2009 12:41:36 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id B86FD28C158 for <dnsop@ietf.org>; Wed, 11 Mar 2009 12:41:35 -0700 (PDT)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n2BJgAEo002602 for <dnsop@ietf.org>; Wed, 11 Mar 2009 19:42:10 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1236800530; bh=t0Kg2maggcRg3HChqXOJ1ld+xxs=; h=DomainKey-Signature:Cc:Message-Id:From:To:In-Reply-To: Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date: References:X-Mailer:X-System-Of-Record; b=QfuCxE/OJAssWOj5CSAgXzUC GXRbUBvo1sz9uF/ghIED2UzSWdhQ0S6bTuRvJ6opq95/agqtEAcYrNkYCa+EWA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=cc:message-id:from:to:in-reply-to:content-type: content-transfer-encoding:mime-version:subject:date:references:x-mailer:x-system-of-record; b=UXRYbL+OIzYyDym9nm2+gs7HKSODK9Ggf3E/fz+s7lgWk+rPnxCfz9CWtB4Gs7lFN opved+yPJQK3TnQVPpxlA==
Received: from yx-out-1718.google.com (yxf34.prod.google.com [10.190.2.98]) by wpaz13.hot.corp.google.com with ESMTP id n2BJg5xg031300 for <dnsop@ietf.org>; Wed, 11 Mar 2009 12:42:06 -0700
Received: by yx-out-1718.google.com with SMTP id 34so116705yxf.58 for <dnsop@ietf.org>; 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)
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
X-Mailman-Approved-At: Wed, 11 Mar 2009 13:07:38 -0700
Cc: "idna-update@alvestrand.no" <idna-update@alvestrand.no>, "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 19:41:37 -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: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Lars-Johan Liman
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Alexander Mayrhofer
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Andrew Sullivan
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Edward Lewis
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Mark Andrews
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Mark Andrews
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Andrew Sullivan
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Edward Lewis
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Andrew Sullivan
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Edward Lewis
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Andrew Sullivan
- [DNSOP] numeric labels Jaap Akkerhuis
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Mark Andrews
- [DNSOP] draft-liman-tld-names-00.txt SM
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… bmanning
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… bmanning
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] draft-liman-tld-names-00.txt Andrew Sullivan
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… David Conrad
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Jaap Akkerhuis
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… David Conrad
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Paul Hoffman
- Re: [DNSOP] draft-liman-tld-names-00.txt SM
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… David Conrad
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] draft-liman-tld-names-00.txt Peter Koch
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Måns Nilsson
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… David Conrad
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Måns Nilsson
- Re: [DNSOP] draft-liman-tld-names-00.txt SM
- [DNSOP] IDNs and ccTLDs Jim Reid
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Jaap Akkerhuis
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Måns Nilsson
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Andrew Sullivan
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Florian Weimer
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Matt Larson
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Patrik Fältström
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Eric Brunner-Williams
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Eric Brunner-Williams
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Vint Cerf
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Andrew Sullivan
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Stephane Bortzmeyer
- Re: [DNSOP] I-D Action:draft-liman-tld-names-00.t… Todd Glassey CISM CIFI