draft-klensin-idnabis-protocol-04 section 4.5
simon at josefsson.org
Thu Mar 27 17:24:02 CET 2008
"Mark Davis" <mark.davis at icu-project.org> 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
Now that I understand the situation, I would completely agree with you.
This discussions makes me unsure whether the core 4 specifications can
obsolete RFC 3490. Some aspects of what's provided by RFC 3490
(guidelines for applications) will not be provided by the new RFC's, it
seems. I think the WG charter sends a rather different message.
Given that this is a -bis effort, I would prefer having a standard
mapping that is compatible with IDNA2003, to bridge old implementations
to new ones.
More information about the Idna-update