Re: [dnsext] How DNAME solves the aliasing problem in Unicode for ITU-T/ISO OIDs

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Thu, 23 September 2010 00:07 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630633A69E9; Wed, 22 Sep 2010 17:07:48 -0700 (PDT)
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 GDxAIGSzk-5s; Wed, 22 Sep 2010 17:07:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FB6F3A6998; Wed, 22 Sep 2010 17:07:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OyZEy-0007HQ-Db for namedroppers-data0@psg.com; Thu, 23 Sep 2010 00:00:44 +0000
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from <mohta@necom830.hpcl.titech.ac.jp>) id 1OyZEv-0007H2-FX for namedroppers@ops.ietf.org; Thu, 23 Sep 2010 00:00:41 +0000
Received: (qmail 32236 invoked from network); 23 Sep 2010 00:17:56 -0000
Received: from 28.red-80-25-72.staticip.rima-tde.net (HELO ?192.168.100.2?) (80.25.72.28) by necom830.hpcl.titech.ac.jp with SMTP; 23 Sep 2010 00:17:56 -0000
Message-ID: <4C9A96C4.6050307@necom830.hpcl.titech.ac.jp>
Date: Thu, 23 Sep 2010 08:52:36 +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.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
Subject: Re: [dnsext] How DNAME solves the aliasing problem in Unicode for ITU-T/ISO OIDs
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

Alfred wrote:

> > For the benefit of users (and the cash flow of OID registration
> > authorities?), the 'new' OID system allows unlimited registering
> > of aliases at each level of the tree (not even restricted to
> > 'sibling' OIDs in the OID tree).

Do you mean that labels with 20 Greek characters will have 1M
aliases just for case insensitive domain names, optionally with
DNSSEC, for free?

Or, do you mean customers must pay 1M times more to make domain
names with a label of 20 Greek characters case insensitive?

Neither ares very practical, I'm afraid.

Or, do you mean that they just think DNSSEC impractical.

> > Therefore, it is interesting to observe how the ITU-T and ISO/IEC
> > deal with the aliasing problem in the OID system and in the ORS.

I'm afraid aliasing problem is unsolvable internationally even for
case insensitivity,

For example, how should 'y' with diaeresis can be case insensitive
when 'Y' with diaeresis dose not exist in ISO-8859/1, which assumes
'Y' with diaeresis never appear, but dose exist in Unicode.

						Masataka Ohta