draft-klensin-idnabis-protocol-04 section 4.5

[Martin Duerst]

For the record, I very much share Mark's concerns.
Not only may different applications differ slightly or not so
slightly in what they map how, but even more of a concern,
differnt applications may make differnt assumptions about
who is responsible for doing such mapping.

The number of cases that may indeed need locale-varying
preprocessing (the main case would be the Turkish I/i) is,
relatively seen, extremely small. It seems that Mark think
that even this kind of variation may be too much. In my
opinion, I think we may have something backwards big time
if we leave mapping completely open just to address the
very few cases such as the Turkish I/i.

But I'm happy to discuss this in more detail once we have
finished the charter.

Regards,    Martin.

At 01:03 08/03/28, Mark Davis wrote:

>On Thu, Mar 27, 2008 at 8:26 AM, Simon Josefsson <<mailto:simon at josefsson.org>simon at josefsson.org> wrote:
>>"Erik van der Poel" <<mailto:erikv at google.com>erikv at google.com> writes:
>>
>>...
> 
>>
>>> So the bottom line is that the current four IDNA200X drafts only
>>> specify what is allowed at the lowest level(s). The higher levels,
>>> such as HTML, UI and so on, are to be specified in separate specs.
>>
>>Doesn't this approach lead to, for example, that the outcome of X.509
>>certificate chain validation will depend on the locale in which the
>>application is running in?
>
>I think that locale-specific preprocessing would be a disaster for compatibility. People will expect that what they type in an address bar in one location will work in another, or can be pasted into email and work for the recipient, and so on. They will get burned by it not working, or even worse, that it works but points to somewhere unexpected.
>
>Moreover, for compatibility in environments where IDNA2003 is now used, a successful deployment of IDNA200x really also requires a standard, locale-invariant, preprocessing specification -- one that maintains as much compatibility with IDNA2003 mapping as possible. (Reasons discussed earlier on this list.) I don't know if that applies in the case of X.509 or not.
>
>A number of people feel that it is important to get the main IDNA200x spec done (or at least well underway) before such a preprocessing specification is developed, and that it should thus not be part of the charter. My fear is that without such a standard specification being available at the same time or shortly thereafter, every implementation will develop its preprocessing -- something just a little different from others -- causing a compatibility mess.
>
>
>
>-- 
>Mark 
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp