Arabic digits

John C Klensin klensin at jck.com
Thu Dec 4 21:58:30 CET 2008



--On Thursday, 04 December, 2008 09:29 -0500 Eric
Brunner-Williams <ebw at abenaki.wabanaki.net> wrote:

> John,
> 
> John C Klensin wrote:
>> --On Thursday, 04 December, 2008 17:55 +0900 Martin Duerst
>> <duerst at it.aoyama.ac.jp> wrote:
>>   
> 
>> ...
>> Those concerns, especially the former, lead me to believe that
>> imposing a protocol restriction to ensure homogeneous digits
>> in combination with Arabic script is probably a good idea,
> 
> Just to be clear, you're arguing the "bugs in IMs" case for a
> restriction on a range of code points in a label, and for the
> restriction to be in the protocol, correct?

No.  I do not believe these are bugs.  I think they are
different design choices which sensible people can advocate
based on different assumptions about what they are trying to
optimize.  I happen to like some of the design decisions more
than others.  I suspect that you and I might have the same
preferences.   But that doesn't make the other choices "bugs",
it just makes them other choices.

And that is the point I was trying to make.  I'm coming to the
conclusion that both design  choices --to assign digits, based
on their numerical values/properties to the same set of ten
codepoints or to make assignments on the basis of glyph
distinctions and script relationships (in some sense using their
characteristics as characters, rather than as numerals) -- are
rational. 

If they are rational choices and difference folks have chosen
different ones of them and are likely to stick with those
choices, then we aren't really talking about bugs, but about
operational realities that it behooves us to recognize and,
where possible, adjust for or help registries do so.   And, IMO,
it is in the best interest of the Internet that we force zones
to make choices, rather than trusting that all registries will
behave well or putting things that "some people might want to
do" ahead of having stable and predictable identifiers.

Just my opinion, of course.

     john



More information about the Idna-update mailing list