Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt
Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Wed, 11 March 2009 19:51 UTC
Return-Path: <ebw@abenaki.wabanaki.net>
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 9E3B43A6979 for <dnsop@core3.amsl.com>; Wed, 11 Mar 2009 12:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level:
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TEXT=2.3]
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 24I-WvjtK4Ry for <dnsop@core3.amsl.com>; Wed, 11 Mar 2009 12:50:59 -0700 (PDT)
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by core3.amsl.com (Postfix) with ESMTP id AE31E3A6AAE for <dnsop@ietf.org>; Wed, 11 Mar 2009 12:50:59 -0700 (PDT)
Received: from clam-local.local (host671420093250.direcway.com [67.142.250.93] (may be forged)) by abenaki.wabanaki.net (8.14.2/8.14.2) with ESMTP id n2BJJtsV032950; Wed, 11 Mar 2009 14:19:59 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net)
Message-ID: <49B81627.5090002@abenaki.wabanaki.net>
Date: Wed, 11 Mar 2009 15:51:03 -0400
From: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Vint Cerf <vint@google.com>
References: <20090304010001.D285A3A68CF@core3.amsl.com> <49B7F130.2040202@nic-naa.net> <B4A0D225-B279-4F8C-9897-8F6B612597E5@google.com>
In-Reply-To: <B4A0D225-B279-4F8C-9897-8F6B612597E5@google.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Eric Brunner-Williams <brunner@nic-naa.net>, "dnsop@ietf.org" <dnsop@ietf.org>, "idna-update@alvestrand.no" <idna-update@alvestrand.no>
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:51:05 -0000
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@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 >> > > _______________________________________________ > 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