Protocol-08 (and status of Defs-04 and Rationale-06)
Vint Cerf
vint at google.com
Mon Dec 8 08:11:20 CET 2008
mark,
appreciate the precision!
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
On Dec 7, 2008, at 9:14 PM, Mark Davis wrote:
> Just to make sure we are all on the same page, the digits in
> question are the following.
>
> (European) U+0030 DIGIT ZERO...
> 0 1 2 3 4 5 6 7 8 9
>
> Arabic-Indic digits: U+0660 ARABIC-INDIC DIGIT ZERO...
> ٠ ١ ٢ ٣ ٤ ٥ ٦ ٧ ٨ ٩
>
> Extended Arabic-Indic digits: U+06F0 EXTENDED ARABIC-INDIC DIGIT
> ZERO...
> ۰ ۱ ۲ ۳ ۴ ۵ ۶ ۷ ۸ ۹
>
> Various Indic digits: U+0966 DEVANAGARI DIGIT ZERO... (Devanagari,
> Gujarati, Tamil, ...)
> ० १ २ ३ ४ ५ ६ ७ ८ ९
>
> Unfortunately, Europeans often refer to European digits as
> "Arabic" (indicating their source), and Arabs often refer to Arabic
> digits as "Indic" (indicating their source). For that reason, the
> Unicode names for the Arabic digits use "Arabic-Indic" instead of
> simply "Arabic". Importantly, the Arabic digits should not be
> confused with true Indic digits, like those for Devanagari, etc. So
> use of the above Unicode names is recommended to avoid confusion.
>
> So I believe what was meant was the following. (I added one more
> possible option, #4, and added examples, pairing 'a' with European
> 9, 'b' with Arabic-Indic 9, and 'c' with Extended Arabic-Indic 9.
> Thus "b٩" below is using the U+0669 ARABIC-INDIC DIGIT NINE while
> "c۹" is using the U+06F9 EXTENDED ARABIC-INDIC DIGIT NINE.)
> forbid at protocol level using context rules the mixing of Arabic-
> Indic, Extended-Arabic-Indic and European digits in any combination.
> forbid {a9b٩, a9c۹, b٩c۹}
> forbid at protocol level using context rules the mixing of Arabic-
> Indic with European and separately forbid mixing Extended-Arabic-
> Indic with European (but allow mixing Arabic-Indic and Extended-
> Arabic-Indic).
> forbid {a9b٩, a9c۹}, but allow {b٩c۹}
> do not forbid use of digits at protocol level but use registry
> filters implemented by each registry.
> forbid at protocol level using context rules the mixing of Arabic-
> Indic with Extended-Arabic-Indic (but allow the mixing of either
> one alone with European digits).
> forbid {b٩c۹}, but allow {a9b٩, a9c۹}
> Mark
>
>
> On Sun, Dec 7, 2008 at 17:14, Vint Cerf <vint at google.com> wrote:
> Alireza,
>
> an update would be called for if we can figure out what consensus
> there is on the matter of the eastern-indic and western-indic
> numbers and their relationship to the western/european numbers.
>
> My impression is that there are some participants who would find it
> preferable to make all restrictions on the mixing the these number
> codes a matter for registry decision. One hazard with this is that
> the issue arises at every level in the DNS hierarchy and operators
> (registries) of lower level zone files may be less likely to
> enforce constraints than, e.g., second level registries.
>
> We can:
>
> 1. forbid at protocol level the mixing of Eastern -Indic, Western-
> Indic and European digits in any combination.
>
> the benefit of this rather strong rule is that it deals the the
> apparent potential hazard that all input digits are mapped into
> European digits by some widely uses operating system software and
> thus will be information lossy.
>
> OR
>
>
> 2. forbid at protocol level the mixing of Eastern-Indic with
> European and separately forbid mixing European with Western-Indic
> using context rules.
>
> OR
>
> 3. Do not forbid use of digits at protocol level but use registry
> filters implemented by each registry.
>
> Are there additional useful options?
>
>
>
> 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 Dec 7, 2008, at 8:01 PM, Alireza Saleh wrote:
>
>> Vint, Harald,
>>
>>
>> Besides, I would like to know if there will be any updates
>> regarding the -BIDI ?
>>
>>
>> Alireza
>>
>>
>> Vint Cerf wrote:
>>
>>> John,
>>>
>>> many thanks for your patience and persistence. I hope this
>>> version can bring us to consensus.
>>>
>>> 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 <mailto:vint at google.com>
>>>
>>>
>>>
>>>
>>> On Dec 7, 2008, at 7:27 PM, John C Klensin wrote:
>>>
>>>> Hi.
>>>>
>>>> A new version of Protocol, draft-ietf-idnabis-protocol-08, is in
>>>> the posting queue.� Versions of Defs (-04) and Rationale (06)
>>>> will follow soon, but not necessarily today. � I may or may not
>>>> post separate comments / announcements about these drafts when
>>>> they appear.
>>>>
>>>> For each of these documents, if you have raised an issue and not
>>>> gotten an explicit response to the note in which it was raised,
>>>> please check to be sure that your comments were reflected
>>>> somehow and inquire if they were not.� I've tried to be careful,
>>>> but would not be surprised if one or two notes accidentally fell
>>>> through the cracks.
>>>>
>>>> Three general observations:
>>>>
>>>> * Several of the bits of Defs (definitions and surrounding
>>>> material) have been reworked and an illustration has been added
>>>> about the relationships among the various terms.� There are some
>>>> dependencies in Protocol on those new definitions so, if
>>>> something in Protocol-08 seems both new and strange, you might
>>>> want to wait until you've seen Defs-04 before commenting.
>>>>
>>>> * These documents do not reflect the recent extensive "digits"
>>>> discussion. � Definitions and Protocol are not affected by it
>>>> one way or the other (from a protocol standpoint, the
>>>> consequences are entirely in Bidi and Tables).� Rationale is
>>>> affected, but I believe that the opportunity for the WG to
>>>> comment, and the editor's sanity, are better served by seeing if
>>>> we can move closer to a base document on which we can agree and
>>>> then add that material, rather than trying to add both sets of
>>>> changes at once. � That implies that, assuming the WG can reach
>>>> some sort of rough consensus, you can expect to see Rationale-07
>>>> before the end of the calendar year.
>>>>
>>>> * As noted separately, I have not reorganized any Security
>>>> Consideration material pending comments from the Security ADs.
>>>>
>>>> �� � john
>>>>
>>>> _______________________________________________
>>>> Idna-update mailing list
>>>> Idna-update at alvestrand.no <mailto:Idna-update at alvestrand.no>
>>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>
>>> --------------------------------------------------------------------
>>> ----
>>>
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>
>>
>
>
> _______________________________________________
> Idna-update mailing list
> 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/20081208/b505ca1a/attachment-0001.htm
More information about the Idna-update
mailing list