Follow-up to Monday's discussion of digits

[Harald Alvestrand]

Eric Brunner-Williams wrote:
> Vint, John, Paf, All,
>
> On the question of what to do about the code points in the ranges
>
> U+0030..U+0039,
> U+0660..U+0669,
> U+06F0..U+06F9,
>
> I think that allowing only the first range is incorrect.
>   
Agreed, this has not been proposed.
> I think that allowing all three ranges is correct if a mechanism for 
> equivalency exists.
>   
There exists no server-side mechanism, since IDNA is a client-side protocol.
> Assuming that no equivalence mechanism exists, for whatever rational, I 
> think that allowing the first range, and only one of the second two 
> ranges, is sufficient.
>   
If you mean allowing only one range in a given label, this is the 
proposal we discussed yesterday (modulo the handling of European numbers).

If you mean allowing only one range globally, this means that we are 
incorrectly displaying the numbers in either Arabic or Farsi/Urdu.

Which did you mean?
> Outside of the protocol, registries are free to implement a 
> registry-local policy, which may restrict code points in a label to one 
> range only, or one of two ranges, where one is in the U+0030..U+0039 
> range, but not both of the ranges U+0660..U+0669 and U+06F0..U+06F9.
>
> As I mentioned yesterday, and as the jabber scribe correctly summarized:
>
> ajsaf at jabber.org Eric: reject latin-only
> ajsaf at jabber.org accept proposal for no mix between extended and 
> non-extended
> ajsaf at jabber.org but overboard to go further
>
> There are, as John rebutted, buggy input methods, but that can't be 
> controlling.
There is also the matter of the combinatorial explosion of a bundling 
approach: if mixing is not allowed, the label "a12345" (in Arabic) 
results in a bundle of 2 names; if mixing is allowed, the label "a12345" 
results in a bundle of 32 names.

                              Harald