Skip to main content

Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,,,,
Subject: Protocol Action: 'Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations' to Proposed Standard (draft-klensin-idna-rfc5891bis-04.txt)

The IESG has approved the following document:
- 'Internationalized Domain Names in Applications (IDNA): Registry
   Restrictions and Recommendations'
  (draft-klensin-idna-rfc5891bis-04.txt) as Proposed Standard

This document has been reviewed in the IETF but is not the product of an IETF
Working Group.

The IESG contact person is Barry Leiba.

A URL of this Internet Draft is:

Ballot Text

Technical Summary
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 responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFC
5980 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the

Working Group Summary
This document has not been formally reviewed on any IETF list, including
on the i18ndir list, though a few key directorate participants have read
and commented on the document.  The document was mentioned on the
idna-update list, and some comments came from there. That said, this is a
document regarding recommendations to the registry and registrar
community that could only be developed by experts on IDNA, of which the
IETF has very few. A 4-week IETF-wide Last Call (as required for
individual submissions) is more than enough time for the i18ndir list to
remind experts to take a final look and confirm that there is community
consensus, insofar as that ever exists for these kinds of documents.

Document Quality
As a matter of style, there is a lot of repetitive text in the first 4
sections. However, I'm well aware of the target audience of this
document, and so this level of explication is probably reasonable.

Pete Resnick is the document shepherd. Barry Leiba is the responsible AD.

RFC Editor Note