Wwhich RFCs the new work would obsolete,
vs update or leave alone
Harald Tveit Alvestrand
harald at alvestrand.no
Tue Mar 18 03:02:05 CET 2008
Simon Josefsson skrev:
> I note that using a new prefix instead of xn-- would avoid this problem.
> Specifications and implementations that use IDNA2003 continue to use
> xn-- and will work fine within its limitations. New specifications and
> implementations that support IDNABIS will use another prefix and also
> work fine.
> I'm not suggesting we adopt this approach, but I haven't
> seen the disadvantages of changing the prefix clearly expressed yet.
> There is a cost in maintaining both IDNA2003 and IDNABIS encodings of
> strings during a transition-period. Whether that cost is higher or
> lower than the complexity in re-using the old prefix for something that
> won't be fully backwards compatible is not clear to me.
section 9.3.3 of draft-klensin-idnabis-issues-07 tries to describe (in
just a few sentences) the cost drivers that (I think) makes a prefix
change a very expensive proposition, both in terms of work for the DNS
operators and in terms of ongoing execution-time costs of application.
That argument convinced me; if you find any part of that unclear, or
disagree with the conclusions, feedback on the text would be welcome.
> I'm assuming IDNABIS won't be (fully) backwards compatible with
> IDNA2003. That is the impression I have gotten from all discussions so
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
More information about the Idna-update