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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 22 November 2010 05:14 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 6D09D3A69FA for <dnsop@core3.amsl.com>; Sun, 21 Nov 2010 21:14:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.87
X-Spam-Level: *
X-Spam-Status: No, score=1.87 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 3NlOg-ZBVG0k for <dnsop@core3.amsl.com>; Sun, 21 Nov 2010 21:14:06 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 3A0213A6A00 for <dnsop@ietf.org>; Sun, 21 Nov 2010 21:14:06 -0800 (PST)
Received: (qmail 70108 invoked from network); 22 Nov 2010 05:50:03 -0000
Received: from bmdk8173.bmobile.ne.jp (HELO ?220.156.133.173?) (220.156.133.173) by necom830.hpcl.titech.ac.jp with SMTP; 22 Nov 2010 05:50:03 -0000
Message-ID: <4CE9FC18.4040705@necom830.hpcl.titech.ac.jp>
Date: Mon, 22 Nov 2010 14:14:00 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20101115213532.GD322@shinkuro.com> <04856F66-598D-43CC-8164-90178A6F2952@virtualized.org> <4CE283DA.5080606@abenaki.wabanaki.net> <20101116145308.GG1389@shinkuro.com> <alpine.LSU.2.00.1011161601450.14239@hermes-2.csi.cam.ac.uk> <20101116164818.GN1389@shinkuro.com> <alpine.LSU.2.00.1011171101250.14239@hermes-2.csi.cam.ac.uk> <20101117121906.GC3773@shinkuro.com> <8CEF048B9EC83748B1517DC64EA130FB43C309F821@off-win2003-01.ausregistrygroup.local> <4CE52226.70502@necom830.hpcl.titech.ac.jp> <20101118140728.GB5795@shinkuro.com> <4CE5523A.7090407@abenaki.wabanaki.net> <4CE5B12E.8020502@necom830.hpcl.titech.ac.jp> <4CE5C667.8010106@abenaki.wabanaki.net> <4CE62AB2.1020604@necom830.hpcl.titech.ac.jp> <4CE66ECF.3060901@abenaki.wabanaki.net>
In-Reply-To: <4CE66ECF.3060901@abenaki.wabanaki.net>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
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, 22 Nov 2010 05:14:07 -0000

Eric Brunner-Williams wrote:

With the original subject, let's discuss examples with Latin
characters only.

> i think the fundamental issue here is not to accept meaningless, or
> meaning-loosing reasonings by imagined similarity.

Unless the reasonings are formerly described, it is impossible
to operate international zones, especially root zones.

Note also that, just as a meaningless label

	aaaaaaaaaaaaaaaaaaaa

is accepted today, a label with 20 characters of 'y' with dieaeresis
will be acceptable, which causes exponential explosion.

> case is not a
> property of han script(s). when non-specialists imagine that han
> script(s) have a case-like property and then try to reason about han
> script(s), error arises.

Beyond simple case but still within ASCII, how about Dutch
example where "IJ" and 'Y' are equivalent?

Is a label

	YYY

equivalent to

	IJIJIJ

?

This case should be resolved in a way compatible to the current
rules for ASCII-only labels.

But, we do need precise definitions on character/string
equivalences.

>> And, the definition used for TLDs must be international one.
>
> while this sounds nice, in practice it means that the operators
> of the two constellations of name servers that support two
> mostly identical views of "." must agree,

Not necessarily.

An international definition could be a transitive closure of
equivalences of all the possible locales.

> and from november
> 2001 to the very recent present, there was a substantial
> area of disagreement between these two operator communities
> over a charset issue.

I don't know what is the disagreement but I know it is not
an issued to be resolved here.

						Masataka Ohta