[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         P. Hoffman
Internet-Draft                                             March 4, 2009
Updates: RFC 3454, 3490, 3491
(if approved)
Intended status: Standards Track
Expires: September 5, 2009


    Internationalizing Domain Names in Applications (IDNA) version 2
                       draft-hoffman-idna2-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 5, 2009.

Copyright Notice

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



Hoffman                 Expires September 5, 2009               [Page 1]


Internet-Draft                    IDNA2                       March 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   IDNA has been a world-wide success since it was introduced over five
   years ago.  However, it has some notable deficiencies, including
   being tied to an old version of the Unicode standard and needless
   restrictions that prevented some languages from being used.  This
   document describes IDNA version 2, which rectifies those problems
   while making the fewest changes necessary to the original protocol.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 4
     1.2.  Conventions Used In This Document . . . . . . . . . . . . . 4
   2.  Changes to RFC 3490 (IDNA v.1)  . . . . . . . . . . . . . . . . 4
   3.  Changes to RFC 3454 (Stringprep)  . . . . . . . . . . . . . . . 4
   4.  Changes to RFC 3491 (Nameprep)  . . . . . . . . . . . . . . . . 6
   5.  Changes to RFC 3492 (Punycode)  . . . . . . . . . . . . . . . . 7
   6.  Suggestions for Registries  . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Work Still to be Done  . . . . . . . . . . . . . . . . 8
   Appendix B.  Changes between versions . . . . . . . . . . . . . . . 8
     B.1.  Changes between the -00 and -01 drafts  . . . . . . . . . . 8
     B.2.  Changes between the -01 and -02 drafts  . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9















Hoffman                 Expires September 5, 2009               [Page 2]


Internet-Draft                    IDNA2                       March 2009


1.  Introduction

   This document describes Internationalizing Domain Names in
   Applications (IDNA) version 2 (hereafter called "IDNAv2"), a direct
   update to IDNA (hereafter called "IDNAv1").  IDNAv1 consists of four
   RFCs:
   o  [RFC3490], "Internationalizing Domain Names in Applications
      (IDNA)", is the main definition of IDNAv1.  This defines the
      processing rules for IDNA and gives the background for how IDNA
      works.
   o  [RFC3454], "Preparation of Internationalized Strings
      ("stringprep")", defines the general framework for processing non-
      ASCII strings that are used in IDNA.
   o  [RFC3491], "Nameprep: A Stringprep Profile for Internationalized
      Domain Names (IDN)", is a short profile of the rules from the
      stringprep framework.
   o  [RFC3492], "Punycode: A Bootstring encoding of Unicode for
      Internationalized Domain Names in Applications (IDNA)", defines
      the encoding used in IDNAv1 labels.

   IDNAv2 is backwards-compatible with IDNv1, meaning that any DNS label
   that was legal in IDNAv1 has exactly the same representation in
   IDNAv2.  New labels are allowed in IDNAv2 that were not allowed in
   IDNAv1.

   IDNA needs to be updated for many reasons, some of which are covered
   in [RFC4690].  If for no other reason, many characters that could
   appear in domain names have been added since Unicode version 3.2
   [UNICODE32], which is the version of the Unicode Standard on which
   IDNAv1 is based.

   One explicit goal of this update is to allow labels with characters
   that have been added since Unicode version 3.2 to be used in IDNA.
   To that end, IDNAv2 is based on Unicode 5.1 [UNICODE51].  The tables
   in stringprep and Nameprep are updated to reflect this change.

   Another explicit goal of this update is to not change the encoding of
   any label that is legal in IDNAv1.  If an internationalized label in
   IDNAv1 produces an ACE label, IDNAv2 must produce the same ACE label.
   If an internationalized label in IDNAv1 produces an ASCII label,
   IDNAv2 must produce the same ASCII label.

   A third explicit goal is to update the bidirectional ("bidi")
   algorithm used by IDNAv1 to cover more languages such as Dhivehi and
   Yiddish.  This is done to cover an oversight in IDNAv1 that was
   discovered after the work was finished.

   This document updates IDNAv1 to reflect Unicode version 5.1.  Of



Hoffman                 Expires September 5, 2009               [Page 3]


Internet-Draft                    IDNA2                       March 2009


   course, the Unicode Consortium will not stop at Unicode version 5.1.
   Because of that, IDNAv2 will probably later need to be updated to
   reflect newer versions of Unicode.

1.1.  Acknowledgements

   The first serious work on updating IDNAv1 was undertaken by John
   Klensin, Patrik Faltstrom, Harald Alvestrand, and Cary Karp.  It led
   to the formation of the IDNAbis Working Group in the IETF, and they
   produced many revisions of their documents in that WG.  Some of the
   ideas in this IDNAv2 document (most notably, the update to the bidi
   algorithm) is derived from their efforts.

   Many, many people worked on IDNAv1.  In addition to the authors of
   the standards (Marc Blanchet, Adam Costello, Patrik Faltstrom, and
   me), there were literally dozens of active participants in the
   original IDN Working Group in the IETF that began in 2000.  Their
   tireless effort led to IDNAv1.

1.2.  Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   In sections of this document where changes are made to RFCs, those
   changes are shown with a vertical line character ("|") in the first
   column.


2.  Changes to RFC 3490 (IDNA v.1)

   All references to the Unicode Standard are updated to refer to
   [UNICODE51].

   All references to Nameprep are updated to refer to the Nameprep in
   this document.  Similarly, all references to stringprep are updated
   to refer to the stringprep in this document.

   In section 3.1, the first bullet point ("1) Whenever dots are
   used...") is changed to add the following at the end of the sentence:
   "U+2CFE (Coptic full stop)".


3.  Changes to RFC 3454 (Stringprep)

   [[[ ============================================================




Hoffman                 Expires September 5, 2009               [Page 4]


Internet-Draft                    IDNA2                       March 2009


   NOTE FOR EARLY VERSIONS OF THIS DRAFT

   This section is intentionally incomplete.  The tables in Stringprep
   need to be added to based on the characters added to the repertoire
   after Unicode 3.2 up to and including Unicode 5.1.

   Probably the best way for this to be done is a few dedicated
   individuals go through the new characters one-by-one, and also to go
   through them programmatically, and see which tables need to be added
   to.  I have done a first pass of doing this one-by-one, but I felt
   that publishing my results in the first draft would cause others to
   get lazy about this important task.  Future versions of this document
   will reflect the results of that work.

   The character review will be similar to what we did in IDNAv1, except
   that we don't have to create any new buckets.  Basically, we have to
   see whether a particular new character should be mapped to nothing,
   or whether it should be prohibited for one of the reasons already
   listed in RFC 3454.  In my not-careful first pass, I found very few
   characters that will need to be added to sections 3 or 5.  The case-
   mapping will happen algorithmically, with a check that the new map
   does not change any value in the old map.

   ============================================================ ]]]

   This document is significantly revised to reflect the use of Unicode
   version 5.1.  All the substantiative changes are additions.  There
   has been no effort to "correct" perceived mistakes in RFC 3454.  (One
   can argue that the extending of the bidi rules in section 6 to allow
   more languages to be expressed is such a correction; however, the
   change lets more strings to be allowed, and doesn't cause any string
   that was allowed in RFC 3454 to not be allowed in the new version.)

   Most of the changes to RFC 3454 are to add characters to the tables
   in the document.  These characters come from Unicode version 5.1.
   Thus, the tables become valid for Unicode version 5.1.  However, the
   same tables are still valid for Unicode version 3.2 because a profile
   that is still using version 3.2 will not ever use the added rows in
   the updated tables.

   In all places other than Appendix A, references to "[Unicode3.2]" are
   updated to refer to [UNICODE51].  Similarly, all text references to
   "Unicode version 3.2" are updated to "Unicode version 5.1".

   Characters will be added to the tables in section 3.1 to reflect the
   differences between Unicode 3.2 and Unicode 5.1.  For example,
   U+E0100 to U+E01EF will be added to the second list in the section.




Hoffman                 Expires September 5, 2009               [Page 5]


Internet-Draft                    IDNA2                       March 2009


   In section 3.2, change "CaseFolding-3.txt" to "CaseFolding.txt".

   Characters will be added to the tables in subsections of section 5.
   An example is that U+2064 will be added to the list in section 5.2.

   In section 6, at the end of the fourth paragraph (which currently
   ends with "have bidirectional category "EN"."), the following
   sentence is added: "The Unicode Standard also defines a bidirectional
   category "NSM" for "non-spacing marks"."

   In section 6, the third requirement is changed to read:

   | 3) If a string contains any RandALCat character, the first
   |   character MUST be a RandALCat chacter, and the last
   |   characters of the string must be either a RandALCat
   |   character or a RandALCat character followed by one or
   |   more NSM charcters.

   In the references, update the reference for UAX15, and add a
   reference for [UNICODE51].

   Appendix A is changed to read:

   | The following is the only repertoire covered in this document:
   |
   | - Unicode 3.2, as defined in [UNICODE32]
   |
   | - Unicode 5.1, as defined in [UNICODE51]

   A new appendix, "A.2 Unassigned code points in Unicode 5.1", will be
   added.

   The tables in appendixes B, C, and D will be added to.


4.  Changes to RFC 3491 (Nameprep)

   All references to IDNA and stringprep are updated to refer to the
   stringprep in this document.

   In section 1 and 2, "Unicode 3.2" is changed to "Unicode 5.1".

   In section 10, change the last table entry to "This is the second
   version of Nameprep."







Hoffman                 Expires September 5, 2009               [Page 6]


Internet-Draft                    IDNA2                       March 2009


5.  Changes to RFC 3492 (Punycode)

   IDNAv2 does not change RFC 3492.


6.  Suggestions for Registries

   This is a placeholder for a short section that covers new advice for
   registries that was not included in IDNAv1.  It will include ideas
   about multi-script labels and possibly other advice.


7.  IANA Considerations

   IANA is requested to add the following to the stringprep profile
   registry (www.iana.org/assignments/stringprep-profiles).

   Name of this profile: Nameprep

   RFC in which the profile is defined: This document.

   Indicator whether or not this is the newest version of the profile:
   This is the second version of Nameprep.


8.  Security Considerations

   The security considerations from RFCs 3454, 3490, 3491, and 3492 all
   apply to this document.  The changes between IDNAv1 and IDNAv2 are
   not believed to add any new security considerations.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              December 2002.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3491]  Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep



Hoffman                 Expires September 5, 2009               [Page 7]


Internet-Draft                    IDNA2                       March 2009


              Profile for Internationalized Domain Names (IDN)",
              RFC 3491, March 2003.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003.

   [UNICODE32]
              The Unicode Consortium, "The Unicode Standard, Version
              3.2", The Unicode Standard version 3.2.

   [UNICODE51]
              The Unicode Consortium, "The Unicode Standard, Version
              5.1", The Unicode Standard version 5.1.

9.2.  Informative References

   [RFC4690]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
              Recommendations for Internationalized Domain Names
              (IDNs)", RFC 4690, September 2006.


Appendix A.  Work Still to be Done

   Figure out exactly how we want the reference to Unicode 3.2 and
   Unicode 5.1 to look in the references section, then figure out how to
   wrestle xml2rfc to produce that.

   Fill in all the tables for the updates to stringprep.

   Decide if this entire document should be about Unicode 5.2, which is
   expected out by mid-2009.


Appendix B.  Changes between versions

   (This section is to be removed by the RFC Editor.)

B.1.  Changes between the -00 and -01 drafts

   In section 1, changed the target for backwards-compatibility to be
   for strings that have only visible characters.

   In section 3, removed the first paragraph.

   In section 3 (about Stringprep section 3.1), added the text about
   removing U+200C and U+200D from the mapped-to-nothing list.




Hoffman                 Expires September 5, 2009               [Page 8]


Internet-Draft                    IDNA2                       March 2009


   In section 3 (about Stringprep section 6), replaced:

   | 3) If a string contains any RandALCat character, a RandALCat
   |   character MUST be the first character of the string, and
   |   either a RandALCat character or NSM charcter MUST be the
   |   last character of the string.

   with

   | 3) If a string contains any RandALCat character, the first
   |   character MUST be a RandALCat chacter, and the last
   |   characters of the string must be either a RandALCat
   |   character or a RandALCat character followed by one or
   |   more NSM charcters.

   Added new placeholder section 6 on advice to registries.

   In Appendix A, added the thought about targeting Unicode 5.2 instead
   of Unicode 5.1.

B.2.  Changes between the -01 and -02 drafts

   Reversed the changes made in -01 with respect to U+200C and U+200D.

   Added paragraph at the end of section 1 acknowledging that IDNAv2
   will eventually need to be updated as well.


Author's Address

   Paul Hoffman

   Email: phoffman@imc.org


















Hoffman                 Expires September 5, 2009               [Page 9]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/