Mapping other Digits to 0-9

[Mark Davis]

The original motivation for the mapping (in IDNA2003) was to make IDNs work
like regular domain names, regarding case (and similar kinds of variants
when extended to Unicode). It has nothing to do with "localization".
That is, with regular domain names, it doesn't matter which of the following
are used:

   - http://bruder.de
   - http://Bruder.de

The goal was to duplicate that behavior with IDNs, so that it wouldn't
matter which of the following was used:

   - http://brüder.de <http://xn--brder-lva.de>
   - http://Brüder.de <http://xn--brder-lva.de>

Note that this is not a UI matter: IRIs appear not only in browser address
bars, but also in email bodies, IMs, and so on. It is generally understood
at the W3C, for example, that all attributes that take URLs should take full
IRIs, not punycoded-URIs, so for example SVG, MathML, XLink, XML, etc, all
take IRIs now, as does HTML5.

I think the motivation for "local mapping" in IDNA2008 is two-fold. Some of
us need to maintain compatibility with IDNA2003. Others want to have special
mappings for Turkish. (Personally, I think the latter makes for a nasty
security and interoperability problem). I haven't heard any case but Turkish
cited as an example of why someone would want a "localization" mapping.

Mark


On Mon, Dec 8, 2008 at 07:02, Andrew Sullivan <ajs at shinkuro.com> wrote:

> On Sun, Dec 07, 2008 at 04:27:09PM +0900, Martin Duerst wrote:
> > input conversions. For input conversions, the appopriate solution,
> > if any, is to add mapping to the protocol, but we (or whoever)
> > decided earlier on that mapping wouldn't be part of the protocol.
>
> My impression of why we decided to take mapping out of the protocol,
> however, is that mapping is basically about localization.  Since it is
> impossible to do localization at a global level, it should not be done
> at the protocol level but should instead be handled as close to the
> end as possible.  At least, that's my impression of the reasoning
> behind the change.
>
> Now, one important premise in favour of the contextual rule is, I
> think, that this digit case is a really unusual one.  If we accept
> that this is a very unusual case, and therefore that we're willing to
> put warts on the protocol that we otherwise aren't willing to add (all
> the while chanting, "No precedent, no precedent," I guess) then is
> this a case where we ought to add mapping to the protocol even though
> we otherwise have a principle that no mapping is allowed/required?  (I
> have no opinion about this at the moment.  I'm just asking.)
>
> A
> --
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> 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/4c30f413/attachment.htm