wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec)

[Mark Davis ☕]

The third choice, of course, was to maintain backwards compatibility with
2003 for all characters in Unicode 3.2, and just extend the same principles
to new characters. That is a much easier migration path...

We've seen this before. XML 1.1 only had a small breaking-compatibility
changes, but those changes were enough to completely doom it.

But as you say, that was not the rough consensus of the WG.

Mark
*— Il meglio è l’inimico del bene —*
*
*
*
[https://plus.google.com/114199149796022210033]
*



On Sat, Oct 1, 2011 at 16:18, John C Klensin <klensin at jck.com> wrote:

>
>
> --On Friday, September 30, 2011 12:59 -0700 "=JeffH"
> <Jeff.Hodges at KingsMountain.com> wrote:
>
> > while investigating this stuff I heard that the "DNS world"
> > is moving to IDNA2008 -- not exactly sure what that means --
> > registry/registrars, resolver code, ... ?
> >
> > But given the deltas between IDNA2008, IDNA2008 + RFC5895,
> > IDNA2008 + UTS46, and IDNA2003, it seems to me that it'd be a
> > good thing if we can try to get more uniform IDNA2008 adoption
> > overall, i.e. bite the bullet now rather than later when it's
> > a lot bigger.
>
> That, of course, reflects the rough consensus of the WG.
> Otherwise, the best solution (no incompatibilities at all, no
> transition, etc.) might well have been "IDNA2003 forever" with
> an attitude toward those whose characters didn't appear in
> Unicode 3.2 or were badly handled in IDNA2003 of "to bad, get
> used to it".
>
>    john
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20111001/f7d2edad/attachment.html>