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

Andrew Sullivan <ajs@shinkuro.com> Tue, 16 November 2010 14:52 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 08DEA3A6B73 for <dnsop@core3.amsl.com>; Tue, 16 Nov 2010 06:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level:
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 zG4qgfnEoJGJ for <dnsop@core3.amsl.com>; Tue, 16 Nov 2010 06:52:27 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9C97B3A69EF for <dnsop@ietf.org>; Tue, 16 Nov 2010 06:52:27 -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 D52EC1ECB442 for <dnsop@ietf.org>; Tue, 16 Nov 2010 14:53:10 +0000 (UTC)
Date: Tue, 16 Nov 2010 09:53:08 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsop@ietf.org
Message-ID: <20101116145308.GG1389@shinkuro.com>
References: <4CDDD642.8080108@necom830.hpcl.titech.ac.jp> <FB73AEDC-2B5E-48F9-BCA5-2637CAF6B6A4@frobbit.se> <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> <04856F66-598D-43CC-8164-90178A6F2952@virtualized.org> <4CE283DA.5080606@abenaki.wabanaki.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4CE283DA.5080606@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: Tue, 16 Nov 2010 14:52:29 -0000

On Tue, Nov 16, 2010 at 08:15:06AM -0500, Eric Brunner-Williams wrote:

> well, there are issues that the original idn, and the later idnabis  
> working groups didn't examine as exhaustively as others, and to assume  
> that every issue related to i18n and/or l10n on or off the wire was  
> adequately addressed by one or both is very, very generous.

I don't think that anyone was supposing that.  I was simply arguing
that we can't re-open the entire protocol every time someone wants to
write something that depends on it.  If one thinks that IDNA2008 is
broken or otherwise wrong, the right thing to do is to go write the
IDNA2008 Considered Harmful draft, not to try to sneak those
criticisms in through the back door of a pure clean-up document
designed only to permit the use of IDNA2008 in the top level.  If
there is such a Considered Harmful draft floating about, then ICANN
has the obligation to make decisions about whether to form its policy
in light of that document.  The IETF is about protocol, and all this
document is trying to do -- and it is explicit about this -- is to
relax (carefully) a restriction that may or may not have been
understood somewhere as a protocol restriction.

> That one was surfaced at the Mexico ICANN, with some bright young thing 
> dreaming of ".4u", presenting at least two problems in presumed policy 
> land.

Note that .4u is still simply not allowed by RFC 1123 or by this
draft.  That is an all-ASCII label, not a U-label, and it is not
alphabetic.  Therefore, not allowed.  If someone at ICANN wants to
change that, s/he will need to write a draft.  Or, of course, ignore
the RFCs published by the IETF.  I'm sure the people at the ITU would be
happy with that latter outcome.

A

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