Backwards compatibility

[Mark Davis]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080318/524f2aa5/attachment.html