Re: [Gen-art] Gen-ART review of draft-cridland-acap-vendor-registry-01.txt

[Alexey Melnikov <[e-mail]>]

Hi Miguel,

Miguel A. Garcia wrote:

> Hi Dave:
>
> Some inline comments.
>
> On 19/10/2010 13:05, Dave Cridland wrote:
>
>> On Tue Oct 19 11:14:03 2010, Miguel A. Garcia wrote:
>>
>>> - I am surprised to see the reduction of characters to ASCII only.
>>> I don't know how this fits with the IETF Internationalization
>>> strategy for most protocols. Additionally, this issue touches me
>>> personally, as a Spanish citizen, where I would not be able to
>>> register strings containing certain characters due to the lack of
>>> their representation in ASCII.
>>>
>>> So, this draft is precluding international names be registered with
>>> IANA. I think this is a major issue that should be addressed.
>>
>> The original registry definition allowed UTF-8 registrations, but had
>> no canonicalization or comparison defined, which I think you'd agree
>> would be "interesting".
>
> I have several questions on the above statement. I hope you can 
> elaborate a bit more.
>
> - Is canonicalization or comparison required for the registry itself

Not under the current rules specified in ACAP (RFC 2244).

> or for the protocols which use the registry?

No.

> - Can you indicate what is the real need of canonicalization? I mean, 
> is it for avoiding duplication of vendor names in the registry, or for 
> usage by the protocols (but what for)?

If there is an accented character, there are multiple ways of encoding 
this in UTF-8. So one needs to have consistent rules for how to encode this.

>> I decided to avoid these registrations, but note that the actual
>> syntax of the registry remains UTF-8, it's only the registration
>> procedures that are restricted - and note that I've explicitly
>> suggested that a future revision might change that.
>
> This does not help me. If I want to register a vendor name that 
> includes non-ASCII characters, my registration will be rejected.

I think you have wrong expectations for how this registry is used. This 
might not be very clear in the document, but here is what Chris Newman 
(the original author of ACAP) wrote:

   The use of textual rather than numeric identifiers for vendors 
benefits engineers and
   operators who are diagnosing protocol problems by allowing them some 
possibility of
   identifying the origin of a vendor attribute without having to look 
it up in a registry
   (although that remains a necessary fallback). As such engineers and 
operators already
   have to be familiar with international technical English to diagnose 
textual protocol
   problems, the restriction to ASCII may help and is not believed to 
harm that intended
   use. Exposure of vendor attributes directly in end-user user 
interfaces was not an
   intended use of the registry.

So ACAP Ventor Tokens don't need to be human readable. They are similar 
to domain names (without IDN).