MVALID (was Re: M-Label or MVALID, and dangers with mappings?)

Mark Davis mark at macchiato.com
Tue Apr 14 16:52:50 CEST 2009


I have had a number of things come up, and can't pay attention to IDNA this
week, but I don't think this direction is positive at all.

I had thought that we were making some progress towards having a uniform
single mapping handling at least case and width, which users really want (Cf
the CJK presentation at the latest IETF meeting). Mapping is not just a UI
issue. Having arbitrary mappings, subject to "application context" just
makes a messy situation worse: if program 1 sees
href="http://ÖBB.at<http://%c3%96bb.at/>"
and goes to  http://öbb.at <http://%c3%b6bb.at/>, but program 2 goes to the
different http://oebb.at, we have a horrible interoperability problem.

In HTML5, for example, href="http://ÖBB.at <http://%c3%96bb.at/>" is valid
and interpreted according to IDNA2003. Because of that, there is no
ambiguity in IDNA2003, it goes to  http://öbb.at <http://%c3%b6bb.at/>. End
of story, no ambiguity.

Luckily, HTML5 is designed around compatibility, and I strongly suspect it
would contine to support IDNA2003 mappings (cc'ing Ian to get his take)
under IDNA2003. It would have to glue these together in some fashion with
IDNA2008 support (such as by using http://www.unicode.org/reports/tr46). But
communicating with a different program that takes a different tack on
resolving the domain name would cause a severe interoperability problem. Why
on earth do people think this kind of fragmentation of the Internet is a
good thing?

Re some thoughts on compatibility:
http://www.alvestrand.no/pipermail/idna-update/2009-April/004400.html

Mark


On Tue, Apr 14, 2009 at 07:16, Vint Cerf <vint at google.com> wrote:

> This exchanges has been very helpful in outlining what I think are two
> views and maybe even a compromise position for the WG to consider.
>
> Plainly we have agreed that mapping should be available to ease the
> introduction of IDNA2008. We have also agreed that the canonical forms of
> IDN labels (U-label and A-label that are equivalent under the punycode and
> reverse-punycode mappings) are extremely valuable fixed points in the
> protocol.
>
> The dialogue among Paul Hoffman, Andrew Sullivan, Pete Resnick and Patrik
> Faltstrom suggests to me that a definition of Mapping (prior to lookup)
> should be undertaken by the WG but that its use might  be determined by
> application context. If that compromise is adopted, the Mapping would be
> recommended in cases where IDNA2003 compatibility is desired/needed but that
> mapping on lookup is not absolutely required under all circumstances.
>
> If we take that path, it will be very helpful to have not only the
> definition of the mapping but also advice about conditions underwhich it
> seems strongly advisable to apply.
>
> vint
>
>
> On 4/14/09, Andrew Sullivan <ajs at shinkuro.com> wrote:
>>
>> On Mon, Apr 13, 2009 at 09:03:48PM -0500, Pete Resnick wrote:
>>
>> > IDNA 2003 can be found in [MAPPING]." What I think is not fine is for
>> > the protocol document to say, "You MUST map user input with
>> > [MAPPING]." That will codify a particular version of [MAPPING] that
>> > may not be suitable for some cases and makes one particular user
>> > input method a requirement for protocol conformance. That I don't
>> > like.
>>
>>
>> Pete's outline was so close to what I'd say that any additional
>> comment from me would be gilding the lily.  So, what he said.
>>
>>
>> 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
>>
>
>
> _______________________________________________
> 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/20090414/4e36fd0c/attachment.htm 


More information about the Idna-update mailing list