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

Andrew Sullivan <ajs@shinkuro.com> Tue, 16 November 2010 14:41 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 C79F43A6C99 for <dnsop@core3.amsl.com>; Tue, 16 Nov 2010 06:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.514
X-Spam-Level:
X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 Yj11VintRlf1 for <dnsop@core3.amsl.com>; Tue, 16 Nov 2010 06:41:58 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 75DD33A6C6E for <dnsop@ietf.org>; Tue, 16 Nov 2010 06:41:58 -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 AB4921ECB442 for <dnsop@ietf.org>; Tue, 16 Nov 2010 14:42:41 +0000 (UTC)
Date: Tue, 16 Nov 2010 09:42:40 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsop@ietf.org
Message-ID: <20101116144238.GF1389@shinkuro.com>
References: <4CDE6D2D.40805@necom830.hpcl.titech.ac.jp> <4819246C-FF1F-456D-9732-51510F0537A1@frobbit.se> <4CE0F829.1010605@necom830.hpcl.titech.ac.jp> <7F03C666-16F8-49E4-BC56-F5DD441DD970@frobbit.se> <4CE1A110.1060403@necom830.hpcl.titech.ac.jp> <20101115213532.GD322@shinkuro.com> <4CE1AAEC.80906@necom830.hpcl.titech.ac.jp> <20101115221534.GE322@shinkuro.com> <4CE1B830.5040804@necom830.hpcl.titech.ac.jp> <GblCgSCaed4MFAqZ@highwayman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <GblCgSCaed4MFAqZ@highwayman.com>
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: Tue, 16 Nov 2010 14:41:59 -0000

On Tue, Nov 16, 2010 at 01:00:10AM +0000, Richard Clayton wrote:

> Anyway... since we're meant to be discussing the document, I admit to
> being entirely puzzled by this section:
> 
>    A Restricted-A-Label is a DNS-Label which satisfies all the following
>    conditions:
> 
>    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 }.
> 
> The reason I'm puzzled is that RFC5890 doesn't discuss what "property"
> is and PVALID seems to be in a table in a different document (and so
> doesn't appear in RFC5890 at all). ie: I think the reference to RFC5890
> in #2 may be a typo.

Yeah, I was afraid of this when I saw it before.  You've confirmed my
fear.  The references to IDNA2008 in section 1 of the draft should be
to the entire document set (RFC 5890, RFC 5891, RFC 5892, and RFC
5893).  Also, the text should undoubtedly refer specifically to
IDNA2008 rather than just "IDNs"; and the spelling of
"Internationalized" should revert to its American version, no matter
how one feels that is wrong, because the reference is usually to the
title of the document set and it's spelled with the "z" there.  The
reference in item 2 needs to be changed, because the derived property
value is defined by RFC 5892:

   This document reviews and classifies the collections of code points
   in the Unicode character set by examining various properties of the
   code points.  It then defines an algorithm for determining a derived
   property value.  It specifies a procedure, and not a table, of code
   points so that the algorithm can be used to determine code point sets
   independent of the version of Unicode that is in use.

As an aside, I'll note that this sort of picky editorial issue is, to
me, yet another indication that the document is actually basically
ready to ship.

> I would also like to know where I'd go to look up what a category is ...

The category is a property of each Unicode code point.  I think you
can probably get enough to understand the current draft by reading all
of the IDNA2008 documents (if you go to the RFC Editor search page and
just use "IDNA2008" as your search string, you'll get them all.  But
they're RFCs 5890 through 5894, with the latter being non-normative
informational material.  You might want to have a look at 5895 too.
But if that's not enough, you'll need to read the Unicode
specification.  The whole thing is available from unicode.org.  

> ... I think what this is intending to say is that you can have a TLD of
> ".2go" but only if there's an xn-- at the front of the whole thing :)

I think what you mean is that xn--2go would be a valid U-label, and
therefore would be a possible label under the rules in the draft, but
that "2go" itself is not a label permitted under these rules because
it fails the traditional "will be alphabetic" restriction in the
discussion in RFC 1123 (and it is not a possible U-label because it is
all ASCII).  If so, then yes, exactly right.

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