Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Mon, 11 October 2010 20:55 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 D6F7B3A6B86; Mon, 11 Oct 2010 13:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.165
X-Spam-Level:
X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 TbRMZwHSBNZi; Mon, 11 Oct 2010 13:55:52 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D071A3A6B85; Mon, 11 Oct 2010 13:55:51 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1P5PKk-000I6G-8r for namedroppers-data0@psg.com; Mon, 11 Oct 2010 20:50:58 +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 1P5PKh-000I61-N2 for namedroppers@ops.ietf.org; Mon, 11 Oct 2010 20:50:55 +0000
Received: (qmail 34265 invoked from network); 11 Oct 2010 21:13:39 -0000
Received: from softbank219001188004.bbtec.net (HELO ?192.168.1.22?) (219.1.188.4) by necom830.hpcl.titech.ac.jp with SMTP; 11 Oct 2010 21:13:39 -0000
Message-ID: <4CB37853.20305@necom830.hpcl.titech.ac.jp>
Date: Tue, 12 Oct 2010 05:49:23 +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: paf@cisco.com
CC: Phillip Hallam-Baker <hallam@gmail.com>, Klaus Malorny <Klaus.Malorny@knipp.de>, namedroppers@ops.ietf.org
Subject: Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th
References: <20100725184119.GA42253@registro.br> <4C4C8FE8.8090305@knipp.de> <4C4CC6BB.7040003@necom830.hpcl.titech.ac.jp> <AANLkTinOAikAPH5JbZ1RJsEX2p536LOh+yOutWC_Oq2M@mail.gmail.com> <EA6B0466-B5B0-448C-9E61-78876D1F2762@cisco.com> <4CB328A4.2010304@necom830.hpcl.titech.ac.jp> <5E497D1C-94C1-4EAC-BAC9-94710C754536@cisco.com>
In-Reply-To: <5E497D1C-94C1-4EAC-BAC9-94710C754536@cisco.com>
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/>

Patrik wrote:

> The URI/IRI is in the RDATA part, and the new draft allows both
> IRI and URI, and furthermore require that the URI/IRI can be
> mapped to each other back and forth.

That's a meaningless statement as the conversion is not well
defined at all.

Here are excerpts from RFC3987 how LRIs do not work:

            a. If the IRI is written on paper, read aloud, or otherwise
               represented as a sequence of characters independent of
               any character encoding, represent the IRI as a sequence
               of characters from the UCS normalized according to
               Normalization Form C (NFC, [UTR15]).

As I said, you can do nothing on LRIs on a paper with Kanji.

   The ToASCII operation may fail, but this would mean that the IRI
   cannot be resolved.

and LRIs do not require that it can be resolved.

   Note: Internationalized Domain Names may be contained in parts of an
      IRI other than the ireg-name part.  It is the responsibility of
      scheme-specific implementations (if the Internationalized Domain
      Name is part of the scheme syntax) or of server-side
      implementations (if the Internationalized Domain Name is part of
      'iquery') to apply the necessary conversions at the appropriate
      point.

and the localization conversion is scheme OR server specific.

   However, the IRI resulting
   from this conversion may not be exactly the same as the original IRI
   (if there ever was one).

thus, it is not back and forth.

Please never bother us with broken localization attempts of Unicode.

						Masataka Ohta