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

Andrew Sullivan <ajs@shinkuro.com> Mon, 29 November 2010 15:26 UTC

Return-Path: <ajs@shinkuro.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 AFED928C148 for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 07:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.629
X-Spam-Level:
X-Spam-Status: No, score=-103.629 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, GB_I_LETTER=-2, 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 aKbvNV6XhD9j for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 07:26:21 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 28C2B28C0E2 for <dnsop@ietf.org>; Mon, 29 Nov 2010 07:26:21 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1FB601ECB41D for <dnsop@ietf.org>; Mon, 29 Nov 2010 15:27:04 +0000 (UTC)
Date: Mon, 29 Nov 2010 10:27:02 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsop@ietf.org
Message-ID: <20101129152702.GI33199@shinkuro.com>
References: <20101125175247.GH21047@shinkuro.com> <alpine.LSU.2.00.1011261558520.4075@hermes-2.csi.cam.ac.uk> <D8E75C03-0322-4594-BB27-D825AB429EA6@hopcount.ca> <C4FB358F-53D1-4A2B-A3A4-1C07222C0B51@dotat.at> <1E1C9726-46B6-4891-A1A4-9D71A90EFE47@hopcount.ca> <20101127185010.GB56062@farside.isc.org> <79DC22E8-18BC-44B1-8874-D094844D9E94@dotat.at> <8CEF048B9EC83748B1517DC64EA130FB43E00387CC@off-win2003-01.ausregistrygroup.local> <20101129143919.GE33199@shinkuro.com> <4CF3C0BA.1050307@abenaki.wabanaki.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4CF3C0BA.1050307@abenaki.wabanaki.net>
User-Agent: Mutt/1.5.18 (2008-05-17)
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: Mon, 29 Nov 2010 15:26:49 -0000

On Mon, Nov 29, 2010 at 10:03:22AM -0500, Eric Brunner-Williams wrote:

> there exist rules, much earlier than 1123, about "-" as the initial, or 

Yes.  They're the hostname rules.  RFC 1035 has this to say about
them, in section 2.3.1:

  The DNS specifications attempt to be as general as possible in the
  rules for constructing domain names.  The idea is that the name of
  any existing object can be expressed as a domain name with minimal
  changes.

  However, when assigning a domain name for an object, the prudent
  user will select a name which satisfies both the rules of the domain
  system and any existing rules for the object, whether these rules
  are published or implied by existing programs.

  For example, when naming a mail domain, the user should satisfy both
  the rules of this memo and those in RFC-822.  When creating a new
  host name, the old rules for HOSTS.TXT should be followed.  This
  avoids problems when old software is converted to use domain names.

  The following syntax will result in fewer problems with many

  applications that use domain names (e.g., mail, TELNET).

[. . . ]

  The labels must follow the rules for ARPANET host names.  They must
  start with a letter, end with a letter or digit, and have as
  interior characters only letters, digits, and hyphen.  There are
  also some restrictions on the length.  Labels must be 63 characters
  or less.

Now, we have considerable discussion in the first part of that passage
that explains why the restrictions that are being introduced are so
introduced, despite the fact that the protocol itself happens not to
have such restrictions.  So, are those rules "merely" allocation
policy, or not?  I can't tell, and I say you can't either.  We don't
even have the proto-2119 lanuage here that we see in RFC 1123, so we
can't tell whether the "The labels must follow" in the last paragraph
is a protocol restriction or a consequence of following the "prudent
user" advice that immediately preceeds it.  It might be policy, and it
might not be.

One way to figure out whether this is "mere" policy or whether it is
in fact protocol is to ask people.  It turns out, however, that
different people have responded differently to this.  Some people have
responded by putting eight-bit labels in the public DNS.  

I claim, therefore, that regardless of whether the rule in RFC 1123 is
or is not clearly policy, we should document that we explicitly
permit, as a matter of protocol, certain characters in the top level.
The draft as written carefully points out that there are lots of
things that are policy and not the domain of the IETF.  This just
states that, in case anyone thinks there is a problem with top level
IDNA2008 labels, there isn't.

And I say again (for the last time, since I think I'm just repeating
myself now), if one thinks that the restriction in 1123 is clearly not
a protocol restriction, then there is nothing to say and we can be
quiet.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.