FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

[John C Klensin]

Hi.

For the information of those who may be watching this list but
not the IETF announcement one...

Asmus Freytag and I have started to put together a draft that
addresses a problem with the IDNA2008 specs, specifically that
we failed to make the responsibility of registries to define
code point and label acceptability rules that were considerably
more narrow (and better understood by them) than the full set of
labels allowed by RFC 5891-5893.  It doesn't actually change
anything because that requirement is in the existing specs; it
just makes (or tries to make) the requirements painfully clear
to those who have been missing or misreading them.

It also provides an explicit link between IDNA2008 requirements
and ICANN work on repertoires and label generation rules without
endorsing that work as more than one thoughtful approach that
might be examined for either reference or inspiration.

Comments (obviously) welcome.

For anyone who might wonder, this document avoids the more
controversial IDNA2008 issues including:

* Multiple suggestions that we should add emoji, a subset of
code points with General Category "So", to the list of code
points allowed by IDNA.   There are many reasons to not do that
but it seems clear that, at some point, the IETF will need to
either document those reasons or make the change.  Volunteers to
put together or work on a document would be welcome.

* The non-decomposing code point problem, formerly (and
incorrectly) known as the Hamza problem.   There has been no
discernable activity on this since the IAB Statement and LUCID
BOF almost exactly two years ago.  I've further updated the
working copy of draft-klensin-idna-5892upd-unicode70 to cover
additional cases and issues, but, in part because it is clearly
inappropriate for a quick-patch individual submission, have been
advised to not post it until we have a plan to make progress.
So far, there is no such plan.

* The (IMO, growing) problem of multiple and inconsistent
specifications for IDNs and IDN handling, with different ones
being used in different higher-level protocols and areas of the
Internet.  The use of different specifications and definitions
creates opportunities for user and implementer confusion,
interoperability difficulties, domain names that cannot be
resolved under some circumstances, and various sorts of attacks.
The specifications involved include IDNA2008, IDNA2003, assorted
local "updates" to IDNA2003 that use versions of Stringprep
locally updated to assorted versions of Unicode, and the various
versions of UTR#46.  The latest version of the latter explicitly
allows emoji along with other symbols.    A few months ago, I
suggested to the IAB I18N program that a document be produced
that at least pointed out the problems associated with multiple
divergent specifications, but the idea got no traction.

It appears to me that, although almost everyone agrees that
IDNs, and well- and clearly-functional IDNs, are important,
virtually no one is willing to do the hard work, at least unless
they are being supported by ICANN (disclosure: I am not) or
organizations whose interests lie in selling names, preferably
as many of them as possible (I have no support from any of them
either).  Until and unless that changes, I don't see much
prospect for getting those other issues addressed in a way that
might lead to consensus documents.

     john



---------- Forwarded Message ----------
Date: Saturday, March 11, 2017 07:22 -0800
From: internet-drafts at ietf.org
To: i-d-announce at ietf.org
Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.


        Title           : Internationalized Domain Names in
Applications (IDNA): Registry Restrictions and Recommendations
Authors         : John C Klensin
                          Asmus Freytag
	Filename        : draft-klensin-idna-rfc5891bis-00.txt
	Pages           : 10
	Date            : 2017-03-11

Abstract:
   The IDNA specifications for internationalized domain names
combine    rules that determine the labels that are allowed in
the DNS without    violating the protocol itself and an
assignment of responsibility,    consistent with earlier
specifications, for determining the labels    that are allowed
in particular zones.  Conformance to IDNA by    registries and
other implementations requires both parts.  Experience
strongly suggests that the language describing those
responsibility    was insufficiently clear to promote safe and
interoperable use of the    specifications and that more details
and some specific examples would    have been helpful.  This
specification updates the earlier ones to    provide that
guidance and to correct some technical errors in the
descriptions.  It does not alter the protocols and rules
themselves    in any way.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00


Please note that it may take a couple of minutes from the time
of submission until the htmlized version and diff are available
at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---------- End Forwarded Message ----------