Internet Draft                                D. Crocker
     draft-crocker-idn-idn-00.txt Brandenburg InternetWorking
     Expires in six months                       23 June 2002




            Internationalized Domain Names (IDN)


     Status of this Memo

     This document is an Internet-Draft and is in full
     conformance with all provisions of Section 10 of
     RFC2026.

     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.


     Abstract

     Globalization of the Internet requires that domain names
     be able use characters outside the ASCII repertoire.
     This document specifies internationalized domain names
     (IDNs) and defines initial domain name constructs in
     which IDNs can be used.  IDNs use characters drawn from
     a large repertoire (Unicode).



0.   Document Change Notes --

     This is a revision to draft-ietf-idn-idna-09.txt.  It is
     being distributed independently to facilitate
     discussion.

     The goal is to gain consensus about revisions to the IDN
     working group document, specifically for the following
     changes:

        a. Split the document into two, one for defining
           Internationalized Domain Names (IDN) and the other for
           defining an encoding method of IDNs, namely IDNA using ACE.

        b. Distinguish general IDN from its specific use for host
           names (IDN-Host).  Use for host names is specified more
           precisely, in terms of a specific syntax BNF rule from the
           relevant existing DNS specification, so that IDN-Host will
           apply precisely to all DNS record fields and protocol units
           conforming to that BNF.



1.   Introduction

     Until now, there has been no standard method for domain
     names to use characters outside the ASCII repertoire.
     This document defines enhancements to the definition of
     domain names, to support internationalized domain names
     (IDN).  The details for doing protocol encoding of IDNs
     are specified separately.



2.   Terminology

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

     "ASCII"

          means US-ASCII [USASCII], a coded character set
          containing 128 characters associated with code
          points in the range 0..7F. Unicode is an extension
          of ASCII: it includes all the ASCII characters and
          associates them with the same code points.

     Code point

          refers to an integral value associated with a
          character in a coded character set.

     Domain name

          is used as a general term for strings conforming to
          [STD13].  [STD13] talks about "domain names" and
          "host names", but many people use the terms
          interchangeably. Further, because [STD13] was not
          terribly clear, many people who are sure they know
          the exact definitions of each of these terms
          disagree on the definitions. This document uses the
          terms separately.

     Domain name slot

          refers to a protocol element or a function argument
          or a return value (and so on) explicitly designated
          for carrying a domain name. Examples of domain name
          slots include: the QNAME field of a DNS query; the
          name argument of the gethostbyname() library
          function; the part of an email address following
          the at-sign (@) in the From: field of an email
          message header; and the host portion of the URI in
          the src attribute of an HTML <IMG> tag.  General
          text that just happens to contain a domain name is
          not a domain name slot; for example, a domain name
          appearing in the plain text body of an email
          message is not occupying a domain name slot.

     Host name

          is a domain name conforming to STD13, with the
          naming character set limited to LDH.

     Internationalized host name (IDN-Host)

          is an IDN conforming to the STD13, except that it
          also supports non-ASCII characters from Unicode.

     Internationalized domain name" (IDN)

          is a domain name that has characters drawn from the
          restricted set of Unicode defined in <<???>>

     Internationalized label

          is a label composed of characters from the Unicode
          character set; note, however, that not every string
          of Unicode characters can be an internationalized
          label.

     IDN-native

          is a domain name slot specified to hold an
          internationalized domain name. The designation may
          be static (for example, in the specification of the
          protocol or interface) or dynamic (for example, as
          a result of negotiation in an interactive session).

     Label

          is an individual part of a domain name. Labels are
          usually shown separated by dots; for example, the
          domain name "www.example.com" is composed of three
          labels: "www", "example", and "com". (The zero-
          length root label described in [STD13], which can
          be explicit as in "www.example.com." or implicit as
          in "www.example.com", is not considered a label in
          this specification.) Throughout this document the
          term "label" is shorthand for "text label", and
          "every label" means "every text label". In IDNA,
          not all text strings can be labels.

     LDH code points

          is defined to mean the codepoints associated with
          ASCII letters, digits, and the hyphen-minus; that
          is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
          abbreviation for "letters, digits, hyphen".

     Unicode

          is a coded character set [UNICODE] containing tens
          of thousands of characters. A single Unicode code
          point is denoted by "U+" followed by four to six
          hexadecimal digits, while a range of Unicode code
          points is denoted by two hexadecimal numbers
          separated by "..", with no prefixes.



3.   International Domain Names (IDN)


3.1. Data representation

     This specification enhances the set of values for valid
     domain name labels from the restricted ASCII specified
     in [STD3], to include [Unicode].

     Mechanisms for encoding Unicode values in Domain Names
     is specified separately.  Hence this specification
     provides no detail for IDNs in "native" binary form (IDN-
     Native) or for "encoded" Unicode-based IDNs.


3.2. Dot as label separator

     For systems supporting IDN, wherever dot is permitted as
     a label separator, the following characters MUST be
     recognized as dots: U+002E (full stop), U+3002
     (ideographic full stop), U+FF0E (fullwidth full stop),
     U+FF61 (halfwidth ideographic full stop).


          << // Are there also multiple Unicode characters
          permitted for at-sign?  What about for slash ("/")?

          If not, then why is the domain name lexical
          analyzer now required to look for 4 characters
          rather than only one?

          This appears to be a case of putting into the
          protocol something that is, in fact, entirely a
          user-interface issue.  That some user interfaces
          will choose to map U+3002 to ASCII dot does not
          mean that it needs to be in the protocol.  // /Dave
          >>



4.   References


4.1. Normative references

     [STD3] Bob Braden, "Requirements for Internet Hosts --
     Communication Layers" (RFC 1122) and "Requirements for
     Internet Hosts -- Application and Support" (RFC 1123),
     STD 3, October 1989.

     [STD13] Paul Mockapetris, "Domain names - concepts and
     facilities" (RFC 1034) and "Domain names -
     implementation and specification" (RFC 1035), STD 13,
     November 1987.


4.2. Informative references

     [DNSSEC] Don Eastlake, "Domain Name System Security
     Extensions", RFC 2535, March 1999.

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

     [UAX9] Unicode Standard Annex #9, The Bidirectional
     Algorithm,
     <http://www.unicode.org/unicode/reports/tr9/>.

     [UNICODE] The Unicode Standard, Version 3.1.0: The
     Unicode Consortium. The Unicode Standard, Version 3.0.
     Reading, MA, Addison-Wesley Developers Press, 2000. ISBN
     0-201-61633-5, as amended by: Unicode Standard Annex
     #27: Unicode 3.1,
     <http://www.unicode.org/unicode/reports/tr27/tr27-
     4.html>.

     [USASCII] Vint Cerf, "ASCII format for Network
     Interchange", October 1969, RFC 20.



5.   Security Considerations

     Security on the Internet partly relies on the DNS. Thus,
     any change to the characteristics of the DNS can change
     the security of much of the Internet.

     This memo describes an algorithm that encodes characters
     that are not valid according to STD3 and STD13 into
     octet values that are valid. No security issues such as
     string length increases or new allowed values are
     introduced by the encoding process or the use of these
     encoded values, apart from those introduced by the ACE
     encoding itself.

     Domain names are used by users to connect to Internet
     servers. The security of the Internet would be
     compromised if a user entering a single
     internationalized name could be connected to different
     servers based on different interpretations of the
     internationalized domain name.



6.   Authors' Addresses

     Patrik Faltstrom
     Cisco Systems
     Arstaangsvagen 31 J
     S-117 43 Stockholm  Sweden
     paf@cisco.com

     Paul Hoffman
     Internet Mail Consortium and VPN Consortium
     127 Segre Place
     Santa Cruz, CA  95060  USA
     phoffman@imc.org

     Adam M. Costello
     University of California, Berkeley
     idna-spec.amc @ nicemice.net