Protocol-08 (and status of Defs-04 and Rationale-06)
Mark Davis
mark at macchiato.com
Mon Dec 8 03:14:03 CET 2008
Just to make sure we are all on the same page, the digits in question are
the following.
(European) U+0030 DIGIT
ZERO...<http://demo.icu-project.org/icu-bin/ubrowse?ch=0030#here>
0 1 2 3 4 5 6 7 8 9
Arabic-Indic digits: U+0660 ARABIC-INDIC DIGIT
ZERO...<http://demo.icu-project.org/icu-bin/ubrowse?ch=0660#here>
٠ ١ ٢ ٣ ٤ ٥ ٦ ٧ ٨ ٩
Extended Arabic-Indic digits: U+06F0 EXTENDED ARABIC-INDIC DIGIT
ZERO...<http://demo.icu-project.org/icu-bin/ubrowse?ch=06F0#here>
۰ ۱ ۲ ۳ ۴ ۵ ۶ ۷ ۸ ۹
Various Indic digits: U+0966 DEVANAGARI DIGIT
ZERO...<http://demo.icu-project.org/icu-bin/ubrowse?k1=0966#here>
(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<http://demo.icu-project.org/icu-bin/ubrowse?k1=0669#here> while
"c۹" is using the U+06F9 EXTENDED ARABIC-INDIC DIGIT
NINE<http://demo.icu-project.org/icu-bin/ubrowse?k1=06F9#here>
.)
1. 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۹}
2. 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۹}
3. do not forbid use of digits at protocol level but use registry
filters implemented by each registry.
4. 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 <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<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/20081207/975be27f/attachment-0001.htm
More information about the Idna-update
mailing list