Clarified IANA Considerations for IDNA
draft-klensin-idna-registry-00a.txt

Abstract

As part of the IDNA package, the IANA Considerations Section of RFC 5892 specified an "IDNA Derived Properties" registry. Experience with that specification demonstrated it to be insufficiently clear on several details. This document respecifies that registry to eliminate any confusion.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 11, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Reasons for this Specification
• 2. Explanation of the Updating Model
• 3. Specific Updates to RFC 5892
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgments
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

1.1. Reasons for this Specification

As part of the IDNA package [RFC5890], the IANA Considerations Section of RFC 5892 [RFC5892] specified an "IDNA Derived Properties" registry. Experience with that specification demonstrated it to be insufficiently clear on several details. This document respecifies that registry to eliminate any confusion. In particular, clarifications are required for the following:

Preservation of tables

The registry actually consists of one table per Unicode version starting with the Unicode 5.2 table that was included in RFC 5892.

Identification of tables

Each table in the registry will be identified with a reference to the particular Unicode version from which it was generated and the date on which it was installed.

Timing and Mechanism for Generating Tables

The text in RFC 5982 is not clear about who is responsible for generating tables and when new tables are to be installed and this requires clarification.

2. Explanation of the Updating Model

[[RFC Editor, please remove this section -- Note in Draft only]]

As of the time of posting the first draft of this document, there had been no real discussion in the community of the mechanisms and timing for getting new versions posted. The suggestion made below is very tentative and intended to encourage discussion. It tries to preserve the intent and discussions leading up to RFC 5892 to the extent possible by putting the burden of deciding when new table versions are appropriate on the expert reviewer. Itj also makes IANA responsible for the actual work of producing and installing new tables, but identifies mechanisms by which they can get help with tables and with identifying the existence of new versions of Unicode as needed.

The procedure outlined below delays any posting of a table by IANA until either (i) the expert reviews signs off that no changes to RFC 5892 rules are needed or (ii) IESG, after being notified by the expert reviewer that there is a problem, figures out how to handle things in terms of documentation and community consensus, and approves the result. If the community would prefer posting of a table for comparison or checking purposes as soon as possible after a new Unicode version is completed, it would be possible to devise a model for "Preliminary" (just after Unicode gets through) and "Final" (after IETF is sure it is through) versions of a table with procedures for getting from one to the other..

3. Specific Updates to RFC 5892

The following subsections are added to the specification of RFC 5892 Section 5.1 "IDNA-Derived Property Value Registry". The numbers in parentheses are the subsection numbers the paragraphs would have if actually inserted in RFC 8582.

(5.1.1 )

The registry consists of a set of tables, one table per version of Unicode starting with Unicode 5.2 and continuing with each new version of Unicode as specified below.

(5.1.2 )

Each table in the registry shall be identified with the Unicode version, a reference to the specification of that version, and the date the table was last updated.

(5.1.3 )

As soon as feasible after a new version of Unicode is finalized and published, IANA or the expert reviewer (as they mutually agree) will generate a new version of the table. The expert reviewer will then conduct a review. If issues are found, they are brought to IESG attention as discussed in RFC 5892. If not, the expert reviewer will advise IANA to install the new table version in the registry, identifying it as described above.

Members of the community are encouraged to call new versions of Unicode to the attention of IANA and the expert reviewer. IANA is encouraged to call on the expert reviewer or others for assistance in compiling and verifying Preliminary tables as needed.

4. Security Considerations

This document clarifies the management, content, and organization of an IANA registry. It does not introduce any security issues not already covered in RFC 5890 and 5892.

5. IANA Considerations

This document is a specification of the requirements for an IANA registry. Details appear in Section 3.

6. Acknowledgments

This specification was motivated by issues with the clarity of the RFC 5892 "IANA Considerations" section identified by Roni Even, Paul Hoffman, Russ Housley, and others.

7. References

7.1. Normative References

7.2. Informative References

Author's Address