UTS #46, Unicode IDNA Compatibility Processing, Version 6.1 Released

[John C Klensin]

Ted and Larry,

If the question is really about UTS #46, I'd encourage everyone
relevant to read RFC 5704, substituting IDNA and various Unicode
actions for MPLS and ITU-T as needed. The point is roughly the
same: the Unicode Consortium decided that a (somewhat
incompatible) "improvement" to IDNA was needed, could not get
consensus for that specification in the IETF, and so went off
and wrote their own.

john


--On Wednesday, February 01, 2012 16:54 -0800 Ted Hardie

On Wed, Feb 1, 2012 at 4:31 PM, Larry Masinter

Should the IRI spec explicitly follow Unicode updates?

I'm not sure I understand the question. Are you saying we
[UNIV6] The Unicode Consortium, "The Unicode Standard,
Version 6.0.0 (Mountain View, CA, The Unicode
Consortium, 2011, ISBN 978-1-936213-01-6)",
October 2010.
to the current 6.1? Or are you suggesting that the draft say
that reference should be to something that is functionally
"this thing or its successors"?
Ted

Sent: Wednesday, February 01, 2012 4:14 PM
Subject: UTS #46, Unicode IDNA Compatibility Processing,
Version 6.1 Released
Mountain View, CA, USA – February 1, 2010 – The new
version of Unicode Technical Standard #46, Unicode IDNA
Compatibility Processing has been released, updating to
Unicode Version 6.1. It adds support for 528 additional
characters in internationalized domain names (IDN).
The specification provides two main features for use with the
internationalized domain names specification released in
A comprehensive mapping to reflect user expectations for
casing and other variants of domain names. This mapping is
allowed by IDNA2008, and follows the same principles as in
the previous version of that specification (IDNA2003). It
thus provides users consistency between old and new versions.
A compatibility mechanism that supports internationalized
domain names valid under the IDNA2003 specification and the
IDNA2008 specification. This second feature allows browsers,
search engines, and other clients to handle both old and new
domain names during the transitional period until registries
update their rules to follow IDNA2008.
UTS #46 supplies normative data tables that are synchronized
with the latest version of the Unicode Standard, allowing
implementations to update without recalculation. This new
version also provides an "NV8" flag in the data files, making
it easier for implementations to disable the compatibility
mechanism.

[Mark Davis ☕]

That's a misrepresentation of what happened, and what resulted.

What the consortium members (many of whom have major browser or search
engine implementations) concluded is that because IDNA2008 breaks backwards
compatibility, many people could not move immediately to deployment. The
document, if you look at it, provides a transitional mechanism specifically
for the period when registries have not yet adopted IDNA2008, but people
want their browsers and search engines to still work.

The main change in the new version is that it adds a field specifically for
IDNA2008 conformance, to help people moving off of the transitional
mechanism.

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

Post by John C Klensin
If the question is really about UTS #46, I'd encourage everyone
relevant to read RFC 5704, substituting IDNA and various Unicode
actions for MPLS and ITU-T as needed. The point is roughly the
same: the Unicode Consortium decided that a (somewhat
incompatible) "improvement" to IDNA was needed, could not get
consensus for that specification in the IETF, and so went off
and wrote their own.