[UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

Mark Svancarek marksv at microsoft.com
Mon Mar 13 12:14:31 UTC 2017

At igf this year John basically argued that no one should use EAI because it's confusing for non-ascii users, and people in other zones might as well just get on the bus and use ascii for their email addresses, too. It was odd, though educational.

So I am not especially surprised to see John proposing more restrictions.

Sent from my Windows Phone
From: Shawn Steele<mailto:Shawn.Steele at microsoft.com>
Sent: ‎3/‎12/‎2017 7:33 PM
To: Richard Merdinger<mailto:rmerdinger at godaddy.com>; Edmon Chung<mailto:edmon at registry.asia>; Mark Svancarek<mailto:marksv at microsoft.com>; UA-discuss at icann.org<mailto:UA-discuss at icann.org>
Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

My concern is John’s emphasis on creating very restrictive character rule sets.

The most restrictive rules created by IDNA2008 have been ignored because of user demand and backwards compatibility.  Eg: no-emoji in labels.  People want emoji, but IDNA2008 doesn’t permit it.  Part of that is compatibility with the permitted IDNA2003 emoji, however there has also been demand for emoji characters newly added to Unicode.

I think that it is appropriate to remind registrars that they are responsible for creating sane rules for their spaces, but it is clear that users do not want to be tied to the most restrictive demands of IDNA2008.  Implementations appear to be settling on the Unicode provided idna data and I would much prefer to see the IETF standards point to the IDNA character sets provided by Unicode (while still encouraging registrars to do sane things that make sense for their domains).

A good example of something a registrar might want to consider could be something like ü.  Some spaces may allow ü without much restriction, however for .de, .ch, .at, etc. it might make sense to recognize that ü has an alternate ue spelling and to provide bundling or blocking of domains like müller.ch and mueller.ch.  That kind of rule is very domain/language specific.  Though it is not called out as some of the bidi rules are, the RFCs allow registrars to implement such a policy if it fits their purposes.  Of course many other behaviors are called out by the IDNA2008 rules.

Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that might confuse their users.  Or if they bundled those registrations.


From: Richard Merdinger [mailto:rmerdinger at godaddy.com]
Sent: Saturday, March 11, 2017 11:35 PM
To: Edmon Chung <edmon at registry.asia>; Mark Svancarek <marksv at microsoft.com>; UA-discuss at icann.org
Cc: Shawn Steele <Shawn.Steele at microsoft.com>
Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

Agree, thanks for forwarding Mark  This was a very cogent statement of affairs relative to the closing out of known IDN issues (or our current inability to do so).

I agree with Edmon in that I think the UA effort should strive to be a catalyst here.


From: <ua-discuss-bounces at icann.org<mailto:ua-discuss-bounces at icann.org>> on behalf of Edmon Chung <edmon at registry.asia<mailto:edmon at registry.asia>>
Date: Sunday, March 12, 2017 at 7:11 AM
To: 'Mark Svancarek' <marksv at microsoft.com<mailto:marksv at microsoft.com>>, "UA-discuss at icann.org<mailto:UA-discuss at icann.org>" <UA-discuss at icann.org<mailto:UA-discuss at icann.org>>
Cc: 'Shawn Steele' <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>>
Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt

Thanks for forwarding this Mark,
This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support.

-----Original Message-----
From: ua-discuss-bounces at icann.org<mailto:ua-discuss-bounces at icann.org> [mailto:ua-discuss-bounces at icann.org] On
Behalf Of Mark Svancarek via UA-discuss
Sent: Sunday, 12 March 2017 12:58 PM
To: UA-discuss at icann.org<mailto:UA-discuss at icann.org>
Cc: Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>>
Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
FYI, too much stuff from John for me to dig into this a.m.
-----Original Message-----
From: Idna-update [mailto:idna-update-bounces at alvestrand.no] On Behalf Of John
C Klensin
Sent: Saturday, March 11, 2017 8:25 AM
To: idna-update at alvestrand.no<mailto:idna-update at alvestrand.no>
Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
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
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
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.
---------- Forwarded Message ----------
Date: Saturday, March 11, 2017 07:22 -0800
From: internet-drafts at ietf.org<mailto:internet-drafts at ietf.org>
To: i-d-announce at ietf.org<mailto: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
    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:
There's also a htmlized version available at:
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:
I-D-Announce mailing list
I-D-Announce at ietf.org<mailto:I-D-Announce at ietf.org>
Internet-Draft directories: http://www.ietf.org/shadow.html or
---------- End Forwarded Message ----------
Idna-update mailing list
Idna-update at alvestrand.no<mailto:Idna-update at alvestrand.no>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170313/5b2d3c61/attachment.html>

More information about the UA-discuss mailing list