Backwards compatibility

Vint Cerf vint at
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 <idna-update-bounces at>
To: Simon Josefsson <simon at>
Cc: Paul Hoffman <phoffman at>; Harald Tveit Alvestrand <harald at>; idna-update at <idna-update at>
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.


On Tue, Mar 18, 2008 at 12:26 PM, Simon Josefsson <simon at> wrote:

	"Mark Davis" <mark.davis at> 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* **
	> *.
	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.
	> Mark
	> *
	> On Tue, Mar 18, 2008 at 9:44 AM, Simon Josefsson <simon at>
	> wrote:
	>> Harald Tveit Alvestrand <harald at> 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:
	>> 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
	> --
	> Mark
	> _______________________________________________
	> Idna-update mailing list
	> Idna-update at


More information about the Idna-update mailing list