Re: A request for formal registration of "ucode" as URN

Peter Saint-Andre <stpeter@stpeter.im> Tue, 17 January 2012 17:20 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F1B21F861B for <urn-nid@ietfa.amsl.com>; Tue, 17 Jan 2012 09:20:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.269
X-Spam-Level:
X-Spam-Status: No, score=-103.269 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XffC-fJXx6Oh for <urn-nid@ietfa.amsl.com>; Tue, 17 Jan 2012 09:20:34 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7513E21F8579 for <urn-nid@apps.ietf.org>; Tue, 17 Jan 2012 09:20:34 -0800 (PST)
Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D863040058; Tue, 17 Jan 2012 10:29:53 -0700 (MST)
Message-ID: <4F15ADE6.3070101@stpeter.im>
Date: Tue, 17 Jan 2012 10:20:38 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: ishikawa <chiaki.ishikawa@ubin.jp>
Subject: Re: A request for formal registration of "ucode" as URN
References: <4EF2C203.4010205@ubin.jp> <4EF30BB5.90002@ubin.jp> <4EF7E1B0.8000504@ubin.jp> <4F0D14F7.9000506@ubin.jp> <CA+9kkMBLRXETpE5P-AKVj+TkvS-zib6FGo0hsbyWWJPfmtmS_g@mail.gmail.com> <4F0E0CBA.1020806@stpeter.im> <CA+9kkMB5jy-VbCvO0BCc0a0Wwzz5EctxBN6BB5zp9BVLBMSJDw@mail.gmail.com> <4F0FE671.6070709@ubin.jp> <CA+9kkMDjGRt3f-EAXsYO_Yfmpr2uvffYiLzYZqcBbBUS9k860g@mail.gmail.com> <4F1065E1.7080208@stpeter.im> <4F14FE53.5000807@ubin.jp>
In-Reply-To: <4F14FE53.5000807@ubin.jp>
X-Enigmail-Version: 1.3.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: urn-nid@apps.ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2012 17:20:35 -0000

Thank you, Ishikawa-san. I have requested an IETF Last Call.

Peter

On 1/16/12 9:51 PM, ishikawa wrote:
> Dear Peter,Ted, and readers of the mailing list,
> 
> I have uploaded a revised version of "draft-ishikawa-yrpunl-ucode-urn"
> to correct the mention of outdated
> RFC for URI syntax (from RFC 2396 to RFC 3986), and
> removed the use of "<", ">" from the non-terminal symbols
> in ABNF description of ucode urn name. This makes it easier to read the
> ABNF. (Per Peter's suggestion.)
> 
> The newly submitted modified document is available at the following.
> 
> https://datatracker.ietf.org/doc/draft-ishikawa-yrpunl-ucode-urn/
> 
> Thank you in advance for your attention.
> 
> Sincerely,
> Chiaki Ishikawa
> 
> On (2012年01月14日 02:12), Peter Saint-Andre wrote:
>> Yes, I agree.
>>
>> I shall initiate IETF Last Call on this specification, so that the IESG
>> can consider it before the end of my term at IETF 83.
>>
>> On 1/13/12 10:07 AM, Ted Hardie wrote:
>>> Dear Ishikawa-san,
>>>
>>> Thank you for your careful consideration of the message.  With this
>>> data, I believe that this registration is ready to proceed.
>>>
>>> regards,
>>>
>>> Ted
>>>
>>> 2012/1/13 ishikawa<chiaki.ishikawa@ubin.jp>:
>>>> Dear Ted and Peter,
>>>>
>>>> This is Chiaki Ishikawa.
>>>>
>>>> Thank you for your comments.
>>>>
>>>> I take the suggestion from TED seriously, and
>>>> I checked with the original developer of the specification for the
>>>> intention behind the "case-sensitive" nature.
>>>>
>>>> It turns out that the hexadecimal string that represents ucode in urn
>>>> would be directly translated into XML tags in some of
>>>> the intended applications. (Some of them anyway.)
>>>>
>>>> XML tags are case-sensitive and that is why the capital letters only are
>>>> allowed for hexadecimal "A", "B", "C", "D", "E" and "F" for keeping the
>>>> uniqueness issue of XML tag names under control.
>>>>
>>>> (So I take that conversion to numeric value is less of an issue
>>>> for this particular class of applications. XML is processed in character
>>>> string space more or less.)
>>>>
>>>> So because of the nature of some planned applications (and some of them are
>>>> large-scale deployment), this case-sensitivity dictating the use of  capital
>>>> letters only for hexadecimal string must be there. That is the comment from
>>>> the ucode designers and ucode application developers.
>>>>
>>>> Thank you for your valuable time.
>>>>
>>>> Sincerely,
>>>> Chiaki Ishikawa
>>>>
>>>> On (2012年01月12日 07:32), Ted Hardie wrote:
>>>>> On Wed, Jan 11, 2012 at 2:27 PM, Peter Saint-Andre<stpeter@stpeter.im>   wrote:
>>>>>>
>>>>>>> I would suggest that it permit the use of lower case la-f as well,
>>>>>>> even if the preferred presentation format of the name uses the upper
>>>>>>> case.  There are many hexadecimal representations which do not
>>>>>>> distinguish between the two, so I believe it would be better practice
>>>>>>> to permit them.
>>>>>>
>>>>>> Hi Ted,
>>>>>>
>>>>>> That would be inconsistent with this sentence in Section 2 of
>>>>>> draft-ishikawa-yrpunl-ucode-urn:
>>>>>>
>>>>>>     The entire UCODE-URN is case-sensitive.
>>>>>>
>>>>>
>>>>> I understand.  From a registration perspective, this is clear.  But
>>>>> from a practice perspective, it is my personal advice that this will
>>>>> likely lead to problems, because many hexadecimal parsers would treat
>>>>> a and A as equivalent.  The authors are, of course, free to discard
>>>>> this suggestion if the constraints on their system are such that this
>>>>> will not arise.
>>>>>
>>>>> Ted
>>>>>
>>>>>
>>>>>> Peter
>>>>>>
>>>>>> --
>>>>>> Peter Saint-Andre
>>>>>> http://stpeter.im/