Wwhich RFCs the new work would obsolete, vs update or leave alone

[Harald Tveit Alvestrand]

Simon,

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
> 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.

                  Harald