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

Edmon Chung edmon at registry.asia
Sun Mar 12 06:11:20 UTC 2017

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] On
> Behalf Of Mark Svancarek via UA-discuss
> Sent: Sunday, 12 March 2017 12:58 PM
> To: UA-discuss at icann.org
> Cc: Shawn Steele <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
> Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
> 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 ----------
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

More information about the UA-discuss mailing list