Mapping other Digits to 0-9

[Eric Brunner-Williams]

Yeah, I looked at that and wondered "Who's that 'we' and what are we 
'fixing'?"

As the IM bug discussions have pointed out, a couple of implementers 
have chosen to map code points NOT in the range U+0030..U+0039 to code 
points in that range, and possibly rely upon some mechanism, like a 
POSIX locale, to reverse the map. Having once had to write a tty driver 
that was capable of knowing in what direction, and how far, to back 
space in a string that was (a) bidi, and (b) multi-locale, I personally 
consider that class of choices amusing.

I don't get it if it is a suggestion for a bidi rule, or anywhere else 
in a globally scoped rule set that starts with things that aren't LDH 
and ends with things that are, with the canonical "xn--" prefix.

If it is a suggestion for registry policy, or how a zonefile editor 
should handle code points other than 0x30 to 0x39, it isn't one I'd 
recommend or implement.

I'm fine with leaving IMs and other UI portions of applications "as 
found", as this is out of our collective competence. No surprise there.

Eric

Andrew Sullivan wrote:
> On Fri, Dec 05, 2008 at 10:56:31AM -0800, Shawn Steele wrote:
>
>   
>> It isn't just the Arabic script.  We can replace 0-9 with "native
>> digits" during rendering for any set of native digits, depending on
>> user settings.
>>     
>
> I thought we'd decided that, as a matter of principle, we were not
> going to do mappings in the protocol?  If the above is advice for
> implementers of user interfaces, then I think we're getting well into
> territory beyond the competence of the IETF.  If the above is advice
> for what the protocol should do, in order to enable those user agents,
> I think it runs contrary to our earlier plans.  Or have I misunderstood?
>
> A
>
>