Follow-up to Monday's discussion of digits

[Vint Cerf]

Eric,

in the various email exchanges from Arabic working group(s), I came away
with the impression that a safer and apparently acceptable policy would be
to prohibit mixing of any of these three in the same label. That is plainly
more stringent than your proposal but I did not get the sense that the
working groups whose email exchanges I was privileged to see felt they
needed to mix any of these together.

Vint



2008/11/18 Eric Brunner-Williams <ebw at abenaki.wabanaki.net>

> 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.
>
> I think that allowing all three ranges is correct if a mechanism for
> equivalency exists.
>
> 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.
>
> 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.
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081125/8632e924/attachment.htm