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

[ishikawa <[e-mail]>]

Dear all,

I have uploaded a very minor change to
draft-ishikawa-yrpunl-ucode-urn-01.txt

The change is that the use of "<" and ">" was not deleted
in a couple of places. The two usages in main text part were missed when the
usage was removed in ABNF description.

E.g.

<ucode-number> vs ucode-number

I noticed them and deleted the usage and
now uploaded the "-02" version.
(I am not sure if it is customary to update the submission and expiration
date on the document, presumably it is, so I did.)

The document is available at
http://datatracker.ietf.org/doc/draft-ishikawa-yrpunl-ucode-urn/history/

Thank you in advance for your attention.

Regards,
Chiaki Ishikawa

On (2012年01月18日 02:20), Peter Saint-Andre wrote:
> 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<[e-mail]>:
>>>>> 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<[e-mail]>    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/
>