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

[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/
>