Backwards compatibility
Vint Cerf
vint at google.com
Tue Mar 18 20:41:37 CET 2008
Mark, I agree that we need to get the first four documents done but your preprocessing analysis will be of interest to explore. V
----- Original Message -----
From: idna-update-bounces at alvestrand.no <idna-update-bounces at alvestrand.no>
To: Simon Josefsson <simon at josefsson.org>
Cc: Paul Hoffman <phoffman at imc.org>; Harald Tveit Alvestrand <harald at alvestrand.no>; idna-update at alvestrand.no <idna-update at alvestrand.no>
Sent: Tue Mar 18 12:33:55 2008
Subject: Re: Backwards compatibility
I was going to do that -- and think it needs to be done for IDNA200x to be successful -- but was advised that it would be better to get the 4 docs out the door first.
Mark
On Tue, Mar 18, 2008 at 12:26 PM, Simon Josefsson <simon at josefsson.org> wrote:
"Mark Davis" <mark.davis at icu-project.org> writes:
> I agree. The main backward compatibility change is that without
> preprocessing a very number of strings break. If someone does do
^ I assume 'small' or similar
yes, wrote too quickly!
> preprocessing -- and we define a uniform mechanism for doing it -- then the
> differences can be quite small (depending on what the wg decides).
>
> For more information on possible preprocessing, see the rough draft at* **
> http://docs.google.com/Doc?id=dfqr8rd5_51c3nrskcx*<http://docs.google.com/Doc?id=dfqr8rd5_51c3nrskcx>
> *.
I think the pre-processing section contains some good ideas, and may
describe roughly what MSIE/Firefox actually implements, which is better
than what's in IDNA2003 today. Have you considered turning the section
into an IETF draft? To be able to offer MSIE/Firefox-compatibility in
libidn I would implement a draft like that.
/Simon
>
> Mark
> *
> On Tue, Mar 18, 2008 at 9:44 AM, Simon Josefsson <simon at josefsson.org>
> wrote:
>
>> Harald Tveit Alvestrand <harald at alvestrand.no> writes:
>>
>> >> I'm assuming IDNABIS won't be (fully) backwards compatible with
>> >> IDNA2003. That is the impression I have gotten from all discussions so
>> >> far.
>> > The only incompatibility so far proposed is that some names valid
>> > under IDNA2003 will not be valid under IDNA200x, and vice versa. For
>> > all names that are valid under both proposals, I don't believe any
>> > change has been proposed.
>>
>> When you upgrade the Unicode version, some strings that normalize to one
>> value under Unicode 3.2 NFKC will not normalize to the same value under
>> Unicode 5.0. See:
>>
>> http://www.gnu.org/software/libidn/manual/libidn.html#PR29-Functions
>> http://www.gnu.org/software/libidn/manual/libidn.html#PR29-discussion
>>
>> I have also noted the discussion around ß. If IDNABIS-ToASCII(ß) != ss
>> then another backwards incompatible change is made.
>>
>> In my comment on the IDNABIS WG charter I suggested that the charter
>> should say that the IDNABIS output needs to be strongly backwards
>> compatible. Both Lisa and Sam from the IESG disagreed. My conclusion
>> is that the WG is entitled to make backwards incompatible changes, and
>> given the discussions so far that involves using Unicode > 3.2 NFKC and
>> how ß will be handled, the WG will likely also make backwards
>> incompatible changes.
>>
>> I think a useful output from the WG would be to clarify which backwards
>> incompatible changes are being made.
>>
>> /Simon
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>
>
>
> --
> Mark
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
--
Mark
More information about the Idna-update
mailing list