Follow-up to Monday's discussion of digits

[Vint Cerf]

Alireza,

surely it is apparent that this problem (letter I and number 1 or  
letter O and number zero) is of ancient origin and it is far too late  
to introduce repairs at protocol level. That would impact ACE  
encodings among other things.

On the other hand, the situation with multi-lingual use of the arabic  
script is a current matter and we have an opportunity to adopt  
practices that can learn from the past.

It appears that many of your colleagues find the ban on mixing of  
European, Arabic-Indic and Eastern Arabic-Indic either reasonable or  
even necessary.

Vint


NOTE NEW BUSINESS ADDRESS AND PHONE
Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Nov 25, 2008, at 10:16 PM, Alireza Saleh wrote:

> Dear Vint,
>
> Yes, in my opinion, the visual confusions and such stuffs are out  
> of the scope of IDNA.  I think If IDNA like to talk about these  
> things, then we may need to setup another working group called  
> DNSA, and start discussing about problems like resolving the mixing  
> of 'l' and '1' in ASCII domains**.
>
> Alireza
>
>
> Vint Cerf wrote:
>> Alireza,
>>
>> point taken. So the delicate issue is where to draw the line  
>> between protocol prohibition and dependence on registry filtering.
>>
>> v
>>
>> NOTE NEW BUSINESS ADDRESS AND PHONE
>> Vint Cerf
>> Google
>> 1818 Library Street, Suite 400
>> Reston, VA 20190
>> 202-370-5637
>> vint at google.com <mailto:vint at google.com>
>>
>>
>>
>>
>> On Nov 25, 2008, at 5:42 PM, Alireza Saleh wrote:
>>
>>> Dear Vint,
>>>
>>> Would you **please** consider that Arabic Language is not the  
>>> only language which  uses Arabic-Script. Some countries such as  
>>> Iran using both sets because 4-5-6 look different in two sets.
>>> A registry for the security reasons may prohibit the Digit- 
>>> Mixing , but the domain's owner  may want to mix it to attract  
>>> the market.
>>> For example : please visit   ش_/*۴٤*/_.تست.کام .   Is it  
>>> really fare to prohibit it ?
>>>
>>> alireza
>>>
>>> Vint Cerf wrote:
>>>> 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  
>>>> <mailto: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 <mailto:ajsaf at jabber.org> Eric: reject  
>>>> latin-only
>>>>     ajsaf at jabber.org <mailto:ajsaf at jabber.org> accept proposal  
>>>> for no
>>>>     mix between extended and non-extended
>>>>     ajsaf at jabber.org <mailto:ajsaf at jabber.org> but overboard to  
>>>> go further
>>>>
>>>>     There are, as John rebutted, buggy input methods, but that  
>>>> can't
>>>>     be controlling.
>>>>
>>>>     Eric
>>>>
>>>>
>>>> ------------------------------------------------------------------- 
>>>> -----
>>>>
>>>> _______________________________________________
>>>> Idna-update mailing list
>>>> Idna-update at alvestrand.no <mailto:Idna-update at alvestrand.no>
>>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081126/8a37b51c/attachment-0001.htm