Re: [DNSOP] draft-liman-tld-names-04

Doug Barton <dougb@dougbarton.us> Fri, 26 November 2010 21:34 UTC

Return-Path: <dougb@dougbarton.us>
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 7244028C0FE for <dnsop@core3.amsl.com>; Fri, 26 Nov 2010 13:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.594
X-Spam-Level:
X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, GB_I_LETTER=-2]
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 9GPNCxTbDQy6 for <dnsop@core3.amsl.com>; Fri, 26 Nov 2010 13:34:34 -0800 (PST)
Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by core3.amsl.com (Postfix) with ESMTP id 10F9128C0F1 for <dnsop@ietf.org>; Fri, 26 Nov 2010 13:34:33 -0800 (PST)
Received: (qmail 6826 invoked by uid 399); 26 Nov 2010 21:35:36 -0000
Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 26 Nov 2010 21:35:36 -0000
X-Originating-IP: 127.0.0.1
X-Sender: dougb@dougbarton.us
Message-ID: <4CF02826.2000503@dougbarton.us>
Date: Fri, 26 Nov 2010 13:35:34 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
References: <20101117091928.GA30093@nic.fr> <4CE9E942.20906@dougbarton.us> <0E561274-43FE-4657-951E-74C8FF0FD307@hopcount.ca> <4CEC43DC.1060709@dougbarton.us> <E7796748-6880-4928-B96D-0024E27E98D5@hopcount.ca> <4CEC69C5.3040209@dougbarton.us> <7B9EF625-1E25-42BE-9546-61C5B7EFC6DA@hopcount.ca> <8CEF048B9EC83748B1517DC64EA130FB43E0037FD1@off-win2003-01.ausregistrygroup.local> <20101124142303.GB19441@shinkuro.com> <alpine.LSU.2.00.1011251734170.4075@hermes-2.csi.cam.ac.uk> <20101125175247.GH21047@shinkuro.com> <alpine.LSU.2.00.1011261558520.4075@hermes-2.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1011261558520.4075@hermes-2.csi.cam.ac.uk>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Andrew Sullivan <ajs@shinkuro.com>, dnsop@ietf.org
Subject: Re: [DNSOP] draft-liman-tld-names-04
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: Fri, 26 Nov 2010 21:34:35 -0000

Generally I like this, and it is a much more thorough treatment than 
what I was working on. I think it needs a little wordsmithing, and I'm 
not clear if Tony's intention in the last section is to indicate that 
there should be a protocol restriction on non-IDN labels (which 
obviously I oppose). Otherwise I think this is definitely a step in the 
right direction.


Doug


On 11/26/2010 08:53, Tony Finch wrote:
> On Thu, 25 Nov 2010, Andrew Sullivan wrote:
>
>> So what aside from [...] do you want?
>
> Something like this:
>
>
> Abstract
>
> This memo clarifies the syntax of top-level domain labels in the domain
> name system as specified in RFC 1123, and how this syntax relates to the
> allocationn policy for TLDs. It describes the current
>
> [...blah...]
>
> Background
>
> [RFC0952] defines a host name in the first paragraph under "ASSUMPTIONS",
> as follows:
>
>        A "name" ... is a text string up to 24 characters drawn from the
>        alphabet (A-Z), digits (0-9), minus sign (-), and period (.).
>        Note that periods are only allowed when they serve to delimit
>        components of "domain style names".  (See RFC-921, "Domain Name
>        System Implementation Schedule", for background).  No blank or
>        space characters are permitted as part of a name.  No distinction
>        is made between upper and lower case.  The first character must be
>        an alpha character.  The last character must not be a minus sign
>        or period.
>
> [RFC1123] section 2.1 reaffirms this definition, but makes one change
> to the syntax:
>
>        The syntax of a legal Internet host name was specified in RFC-952
>        [DNS:4].  One aspect of host name syntax is hereby changed: the
>        restriction on the first character is relaxed to allow either a
>        letter or a digit.  Host software MUST support this more liberal
>        syntax.
>
> In addition, the DISCUSSION in Section 2.1 says:
>
>        'However, a valid host name can never have the dotted-decimal form
>        #.#.#.#, since at least the highest-level component label will be
>        alphabetic.'  [Section 2.1]
>
> Some implementers may have understood the above phrase "will be
> alphabetic" to be a protocol restriction. This is incorrect. It is in fact
> a description of the TLD allocation policy at that time.
>
> The TLD allocation policy has since had two significant syntactic changes.
>
> On 16 November 2000 the first long TLD (.museum) was allocated, and it
> was added to the root zone in June 2001.
>
> In October 2007, the first IDNA test TLDs were added to the root zone.
> These were the first TLDs with non-alphabetic characters. ICANN approved a
> policy for allocating IDNA ccTLDs in October 2009 and the first production
> IDNA TLDs were added to the root zone in January 2010.
>
> Deployed software that checks DNS top-level labels for conformance with
> past allocation policy is likely to reject domain names allocated after a
> policy change.
>
>
> Syntax of TLD labels - protocol level
>
> All labels of a domain name have the same syntax. The syntax of TLDs is
> not specially restricted at the protocol level.
>
>     domain  = *(label ".") label ["."]
>
>     label   = let-dig [ldh-str]
>
>     let-dig = ALPHA / DIGIT
>
>     ldh-str = *( ALPHA / DIGIT / "-" ) let-dig
>
> A label can be up to 63 characters long. A domain name can be up to 255
> characters long.
>
> A domain name as a whole shall not match the dotted quad representation of
> an IPv4 address.
>
>     IPv4    = 3(digits ".")
>
>     digits  = 1*DIGIT
>
>
> Syntax of TLD labels - allocation policy
>
> The syntax of allocated TLDs is restricted in order to ensure that no
> domain name can match an IPv4 dotted quad, and for compatibility with past
> practice and deployed software. The policy is subject to change by ICANN.
> This section describes the syntax of domain names permitted by the current
> allocation policy.
>
> IDNS encodes Unicode strings within the syntax permitted for domain name
> labels. The Unicode string used by applications is known as a U-Label;
> its corresponding encoding in the DNS is known as an A-Label. The terms
> A-Label and U-Label are used in this document as defined in [RFC5890].
> Valid A-Labels always contain non-alphabetic characters.
>
> In order to accommodate the wish to express TLD names in scripts other
> than the ASCII subset of Latin, it is necessary to allow non-alphabetic
> characters in the corresponding TLD DNS-Labels.  Following past practice,
> the U-label form of a TLD name is restricted by applying rules analogous
> to those already imposed on ASCII TLD DNS-Labels.
>
> ASCII TLDs have the following syntax:
>
>     TLD = 1*63(ALPHA)
>
> IDNA TLDs obey the following requirements:
>
>     1.  the DNS-Label is a valid A-Label according to [RFC5890];
>
>     2.  the derived property value of all code points, as defined by
>         [RFC5890], is PVALID;
>
>     3.  the general category of all code points, is one of { Ll, Lo, Lm, Mn }.
>
>
> [... etc etc ...]
>
> Tony.



-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/