INTERNET-DRAFT                                             Eric A. Hall
  Document: draft-hall-ldap-idn-00.txt                          June 2003
  Expires: January, 2004
  Category: Standards-Track
  
  
                         LDAP Schema Extensions for
                       Internationalized Domain Names
  
  
     Status of this Memo
  
     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC 2026.
  
     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.
  
  
     Copyright Notice
  
     Copyright (C) The Internet Society (2003).  All Rights Reserved.
  
  
     Abstract
  
     This document defines schema and behavioral rules which are
     necessary to fully accommodate the use of internationalized domain
     names as UTF-8 sequences in LDAP. Specifically, this document
     defines an internationalized domain component attribute, email
     address attribute, URI syntax, and several related object classes,
     and also discusses their usage considerations.
  
  
  
  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
  
     Table of Contents
  
     1.   Background and Overview...................................2
     2.   Prerequisites and Terminology.............................3
     3.   Validation and Conversion.................................3
       3.1.  Processing Junctures...................................3
       3.2.  Processing Algorithm...................................5
       3.3.  Escape Syntax..........................................6
       3.4.  Client Transformation Guidelines.......................8
     4.   Internationalized Domain Components.......................8
       4.1.  The idc (inetDomainComponent) Attribute................9
       4.2.  The inetIdcDomain Object Class........................10
       4.3.  The inetIdcObject Object Class........................11
     5.   Internationalized Email Addresses........................11
       5.1.  The inetEmail Attribute...............................11
       5.2.  The inetEmailObject Object Class......................12
     6.   The iLDAP URI Scheme.....................................13
     7.   Open Issues..............................................14
     8.   Security Considerations..................................14
     9.   IANA Considerations......................................14
     10.  Author's Addresses.......................................14
     11.  Normative References.....................................14
     12.  Acknowledgments..........................................15
     13.  Full Copyright Statement.................................16
  
  
  1.      Background and Overview
  
     Although the LDAPv3 [RFC3377] service is explicitly capable of
     transferring characters from the Universal Character Set (UCS)
     [ISO10646] which have been encoded into eight-bit sequences with
     UTF-8 [RFC2279], the core LDAP schema and service elements which
     explicitly carry domain names as structured data are syntactically
     restricted to a subset of seven-bit character codes.
  
     This restriction is due to historical limitations with the domain
     names themselves, although recent standards-track activity towards
     defining internationalized domain names and their usage has made
     these universal restrictions somewhat inappropriate and excessive,
     particularly in those cases where LDAP systems are required to use
     a UTF-8 form of the internationalized domain names directly.
  
     Although LDAP applications are free to define whichever attributes
     and syntaxes they may need for their own internal use (including
     any private attributes related to domain names), there is also a
  
  Hall                  I-D Expires: January 2004             [page 2]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     need for internationalized versions of the common domain-related
     schema and service elements to be made available for those
     applications. As such, this document defines internationalized
     versions of those common elements for the benefit of those
     applications, and also discusses their usage considerations.
  
     Specifically, this document defines internationalized forms of the
     domainComponent attribute and its associated object classes, the
     mail attribute and a related object class, and the LDAP URL.
     Through the judicious use of these elements, LDAP applications can
     take full advantage of the "native" representation of
     internationalized domain names, while also using the legacy
     attributes to ensure backwards-compatibility with applications
     that still require the legacy form of those domain names.
  
  2.      Prerequisites and Terminology
  
     Readers of this specification are expected to be familiar with
     LDAPv3 [RFC3377], IDNA [RFC3490], and UTF-8 [RFC2279].
  
     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 RFC 2119.
  
  3.      Validation and Conversion
  
     Internationalized domain names are expected to be validated before
     they are used, wherever this is possible. This section discusses
     where that validation should occur, and also defines the
     validation algorithm that should be used at those junctures.
  
  3.1.    Processing Junctures
  
     The specifications which currently govern internationalized domain
     names do not define specific syntax rules for those domain names,
     but instead define functions for encoding and decoding the domain
     names into ASCII [ASCII] compatible sequences. This effectively
     means that the contents of an internationalized domain name
     element cannot be validated with syntax rules, but instead must be
     validated through the use of local function calls.
  
     Since existing systems have historically relied upon syntax rules
     to determine validity, those systems cannot be readily expected to
     perform these function calls. In order to accommodate these
     systems and avoid problems which may otherwise occur, this
     specification does not imposes any formal syntax rules on the
  
  Hall                  I-D Expires: January 2004             [page 3]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     elements themselves, but instead requires that internationalized
     domain names be validated before the data is stored or
     transferred, if the opportunity presents itself. Essentially, this
     approach makes the internationalized domain name elements
     transparent, capable of carrying any eight-bit data, while
     requiring that the party which generates the data perform the
     necessary function calls.
  
     Specifically, internationalized domain names are expected to be
     validated at the following points:
  
        *   Operators of LDAP servers SHOULD validate the data before
            it is added to the server, if possible. For example, if the
            operator of a server creates a new naming context that uses
            the inetDomainComponent attribute, then that operator
            SHOULD ensure that the internationalized domain name labels
            contained therein are syntactically valid prior to creating
            the naming context. Similarly, if an application generates
            LDIF output which contains internationalized domain names,
            the script which generates that output SHOULD ensure that
            those domain names are syntactically valid.
  
        *   Client applications SHOULD validate the data whenever that
            data is originally created, if possible. For example, if an
            application allows the creation of inetMail attribute
            values with foreknowledge of that attribute's usage, the
            application SHOULD validate the attribute value prior to
            submitting the data to the server for storage.
  
        *   Client applications SHOULD validate any data they extract
            from LDAP prior to passing that data to an external
            application. For example, if an user-facing application
            will pass an inetMail attribute value to an email client,
            the LDAP application SHOULD validate the attribute value
            prior to sending it on, if possible.
  
        *   The client SHOULD use the most appropriate form of the data
            when passing that data to another application, either by
            using the most-appropriate of the attributes, or by down-
            converting the internationalized form if necessary. In
            those cases where the client has no a priori knowledge of
            the recipient application's capabilities, the ASCII
            compatible form MUST be used.
  
  
  Hall                  I-D Expires: January 2004             [page 4]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
  
  3.2.    Processing Algorithm
  
     Wherever an internationalized domain name is to be validated, the
     input domain name MUST use the conversion algorithm defined in
     this section. These rules apply to any domain name which is stored
     in any internationalized domain name element, regardless of the
     contents of the input. For example, these rules apply to domain
     names which only contain printable ASCII characters, domain names
     which appear to already be encoded into IDNA, and domain names
     which contain UCS character codes.
  
     In general terms, the validation process requires that every
     domain name which is to be stored in an internationalized domain
     name element undergo a two-part conversion, with the input first
     being reduced to its canonical IDNA-encoded form, and then being
     expanded into its UTF-8 encoded UCS form. This process ensures
     that the domain name has been validated as a semantically correct
     IDNA sequence, and that the resulting internationalized domain
     name has been properly normalized into its canonical form.
  
     The full process is as follows:
  
        a.  Unless otherwise explicitly defined, disable the
            UseSTD3ASCIIRules IDNA flag and enable the AllowUnassigned
            IDNA flag, thereby permitting the broadest range of
            character codes to be used.
  
        b.  If the input domain name terminates with a Full-Stop
            character (0x2E) but does not consist of a single Full-Stop
            character alone, remove the trailing Full-Stop character
            from the input.
  
        c.  Perform the "ToASCII" conversion operation specified in
            [RFC3490]. This step will reduce the input domain name to
            the canonical IDNA-compatible form, thus ensuring that the
            input data can be properly normalized when it is
            reconstructed, and also ensuring that any subsequent
            conversions back into the ASCII-compatible form will result
            in predictable and legitimate domain names.
  
        d.  Perform the "ToUnicode" conversion operation specified in
            [RFC3490] against the output from step 3.2.a above. This
            step will convert the ASCII-compatible sequence into a
            sequence of UCS code-point values.
  
  
  Hall                  I-D Expires: January 2004             [page 5]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
        e.  Encode the output from step 3.2.d into UTF-8.
  
     Note that the UseSTD3ASCIIRules and AllowUnassigned IDNA flags
     MUST be set to their most liberal settings by default, and are not
     to be used unless the underlying application-specific usage of a
     domain name is known to require usage to the contrary.
  
     By following these rules, the internationalized domain names which
     appear in the available elements will always be valid, and will
     always be usable by applications which specifically make use of
     the elements, while those systems which do not make explicit use
     of these elements but which may inadvertently pass the
     internationalized domain names to other applications will not be
     exposed to any potential risks which may have been otherwise
     caused from malformed data.
  
     Also note that these requirements are significantly more stringent
     than the requirements for validating legacy domain names in the
     legacy elements, and also apply to legacy-compatible domain names
     which are stored in the internationalized elements. For example,
     the existing domainComponent and mail attributes do not require
     data to be validated against the known syntax rules for domain
     names and email addresses, but instead simply limit the range of
     character codes to a relatively small subset, while the rules
     defined above will result in the same canonical input having a
     stricter actual syntax.
  
  3.3.     Escape Syntax
  
     Certain applications allow for the use of "unusual" characters or
     octet values which are not typically associated with traditional
     domain names, but which must be preserved in order for the
     associated applications to function properly. For example, an
     application-specific domain name may contain an Underscore
     character (0x5F) or a Space character (0x20), or may contain a
     "raw" octet value such as 0xC0 and which cannot be treated as a
     UCS character code during normalization routines (otherwise the
     corresponding UCS character code value would be interpreted and
     lowercased, thus destroying the actual octet value).
  
     In order to ensure that these kinds of values are properly
     preserved, a formal escape syntax is defined for their use. In
     general terms, this syntax requires problematic eight-bit values
     to be replaced with a Reverse-Solidus character (0x5C, "\"),
     followed by a three-digit decimal value (in the range of "000"
     through "255") that corresponds to the canonical octet value.
  
  Hall                  I-D Expires: January 2004             [page 6]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
  
     This escape syntax MUST be applied to any octet value which does
     not explicitly represent a printable character (0x00 through 0x20,
     0x7F through 0x9F, and 0xA0, inclusive), or which represents an
     embedded Reverse-Solidus character (0x5C, "\"). In those cases
     where a valid escape sequence already exists, that sequence
     (including its leading Reverse-Solidus character) MUST NOT be
     escaped again.
  
     This escape syntax MAY be applied to any other character code or
     octet value, although the unnecessary usage of this mechanism is
     strongly DISCOURAGED. Furthermore, the availability of this
     mechanism MUST NOT be interpreted to mean that this mechanism can
     be used with any domain name; instead, it is only to be used with
     application-specific domain names which explicitly allow the
     presence of these problematic characters.
  
     For example, if an application-specific domain name contains
     "weird name.example.com", the "weird name" portion of that domain
     name MUST be escaped as "weird\032name". Meanwhile, if an
     application-specific domain name contains "local\046postmaster",
     this sequence would be unmodified since the Reverse-Solidus
     character is already part of a valid escape sequence.
  
     This escape syntax MUST be applied to an input domain name before
     that domain name undergoes the conversion process described in
     section 3.2. Furthermore, the leaf-node applications which
     generate and use these domain names SHOULD escape the data before
     it is passed to an LDAP agent, since those agents cannot be
     expected to know all of the application-specific usages of a
     domain name. For example, an application which uses a domain name
     with an embedded Full-Stop character (0x2E, ".") SHOULD escape
     that character before storing or passing the domain name to an
     LDAP agent, thus eliminating the possibility of having that agent
     interpret the embedded Full-Stop character as a label separator.
  
     Note that any Reverse Solidus characters in the resulting domain
     name will be further escaped when these sequences are transferred
     in LDAP messages. For example, "weird\032name" will be further
     escaped as "weird\\032name" when it is passed in an LDAP message
     (this secondary escape will be stripped upon receipt, leaving the
     escaped domain name in its original form).
  
     Also note that Reverse-Solidus characters are frequently illegal
     as data in URIs, and these characters will probably end up being
     percent-escaped whenever they are provided in a URI as data.
  
  Hall                  I-D Expires: January 2004             [page 7]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
  
  3.4.    Client Transformation Guidelines
  
     This specification defines data elements for storing the rich
     representations of internationalized domain names, with the
     expectation that those domain names will be viewed and manipulated
     in their native form, and that ASCII compatible encodings of those
     domain names will be provided in the legacy elements.
  
     Therefore, in the general case, clients and servers SHOULD display
     and use internationalized domain name elements in the native form
     as offered by the elements in use, and SHOULD NOT transform the
     data into another representation for display purposes unless the
     user has specifically requested the client to provide an
     alternative representation of those elements.
  
     Specifically, IDNA encoded elements SHOULD NOT be transformed into
     UTF-8, and vice versa, unless the user explicitly requests this
     action to take place.
  
  4.      Internationalized Domain Components
  
     This section defines the idc (inetDomainComponent) attribute, the
     inetIdcObject object class, and the inetIdcDomain object class, as
     internationalized versions of the schema defined in [RFC2247].
  
     In the typical usage scenario, the inetDomainComponent attribute
     and related object classes will be used to define the naming
     context of a directory partition. For new installations which are
     limited to this simple usage, these elements can be deployed
     without any special considerations.
  
     In those cases which uses the domainComponent attribute already
     exists, but where applications do not perform any kind of active
     mapping between domain names and the domainComponent attributes,
     it may be feasible to simply migrate the existing data from the
     existing naming context, and to either update the clients to use
     the newer partition or use referrals to redirect the clients
     automatically.
  
     In those cases where agents perform some kind of active mapping
     between domain names and the legacy domainComponent attributes,
     the use of referrals may be sufficient to redirect LDAP clients
     away from the domainComponent naming context and towards the
     inetDomainComponent naming context.
  
  
  Hall                  I-D Expires: January 2004             [page 8]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     In those cases where referrals to another naming context are not
     feasible, organizations can continue to use the domainComponent
     naming, and simply apply the inetIdcObject auxiliary object class
     to the existing entries. Although this approach will not modernize
     the partition structure, it will allow both attribute sets to
     coexist simultaneously, and will also allow searches for the
     internationalized domain names to successfully match.
  
  4.1.    The idc (inetDomainComponent) Attribute
  
     The idc attribute is for internationalized domain names which are
     to be stored in LDAP as sequences of relative distinguished names,
     with each attribute being mapped to discrete labels from the
     associated DNS domain name.
  
     The idc attribute type is defined as follows:
  
          ( OID.TBD
            NAME ( 'idc' 'inetDomainComponent' )
            EQUALITY caseIgnoreMatch
            ORDERING caseIgnoreOrderingMatch
            SUBSTR caseIgnoreSubstringsMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )
  
     Servers MAY map the idc attribute name to a synonym of
     inetDomainComponent. Systems MUST NOT use inetDomainComponent as
     the attribute name in any messages they generate.
  
     The value of this attribute is a directory string holding one
     label component of an internationalized domain name, preferably as
     normalized and validated according to the process defined in
     section 3.
  
     In those cases where the input domain name specifically and solely
     refers to the root domain, the root domain MUST be represented as
     a single idc attribute containing a single Full-Stop character
     ("idc=."), and in this specific scenario, the Full-Stop character
     MUST NOT be escaped. If the input domain name contains any other
     sequence of labels, the root domain MUST NOT be specified in the
     resulting idc attribute sequence.
  
     idc attributes are typically mapped to zone names, and as such,
     the corresponding domain names are usually restricted to hostname
     rules. However, this restriction is not formally implied or
     mandated, and any domain name (containing any octet value) is
  
  Hall                  I-D Expires: January 2004             [page 9]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     explicitly permitted. As such, the UseSTD3ASCIIRules and
     AllowUnassigned IDNA flags MUST be set to their most liberal
     settings during conversion. However, subsequent application-
     specific uses of the idc attribute MAY apply stricter syntax
     checks if needed (this may be necessary with application-specific
     usages such as digital certificates, for example). In this regard,
     the ability to represent a domain name in an idc attribute does
     not guarantee that every application will be able to use the
     corresponding attribute value.
  
     Note that many characters in an internationalized domain name will
     be converted to lowercase as part of the normalization process.
     However, case MUST be ignored during comparison operations since
     the existence of legacy systems will mean that not all domain
     names will have been properly normalized.
  
  4.2.    The inetIdcDomain Object Class
  
     The inetIdcDomain object class is a structural object class, which
     uses idc as the mandatory naming attribute, and which provides
     several additional optional attributes that may be used to
     describe a particular organizational entity.
  
     The inetIdcDomain object class is defined as follows:
  
          ( OID.TBD
            NAME 'inetIdcDomain'
            SUP top
            STRUCTURAL
            MUST idc
            MAY ( userPassword $ searchGuide $ seeAlso $
            businessCategory $ x121Address $ registeredAddress $
            destinationIndicator $ preferredDeliveryMethod $
            telexNumber $ teletexTerminalIdentifier $ telephoneNumber $
            internationaliSDNNumber $ facsimileTelephoneNumber $ street
            $ postOfficeBox $ postalCode $ postalAddress $
            physicalDeliveryOfficeName $ st $ l $ description $ o $
            associatedName ) )
  
     The optional attributes of the inetIdcDomain object class are used
     for describing the object represented by this domain name, and may
     also be useful for searches.
  
     Note that the dcObject object class defined in [RFC2247] may be
     used to supplement the inetIdcDomain object class, allowing the
  
  Hall                  I-D Expires: January 2004            [page 10]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     legacy domainComponent attribute to be bound to an entry which
     uses the inetIdcDomain object class.
  
  4.3.    The inetIdcObject Object Class
  
     The inetIdcObject object class is an auxiliary object class which
     provides idc as an optional attribute. The inetIdcObject object
     class is intended to be used in conjunction with a structural
     object class such as organization, organizationalUnit, or
     locality, none of which provide the idc attribute.
  
     The inetIdcObject object class is defined as follows:
  
          ( OID.TBD
            NAME 'inetIdcObject'
            SUP top
            AUXILIARY
            MUST idc )
  
     Note that the structural object class in use with the entry will
     define the naming attribute for that entry. As such, the idc
     attribute will only be one of potentially many child attributes,
     with no relevance to the name of the entry.
  
  5.      Internationalized Email Addresses
  
     This section defines the inetEmail attribute and the auxiliary
     inetEmailObject object class, as internationalized versions of the
     mail attribute defined in RFC 1274 [RFC1274].
  
     In the typical usage scenario, the inetEmail attribute and related
     object class will be used to define an internationalized Internet
     email address attribute as additional data for a contact-related
     object class such as inetOrgPerson. The inetEmail attribute is not
     expected to be used as a naming attribute, and imposes no
     namespace considerations.
  
     The inetEmail and mail attributes can coexist in an entry without
     difficulty, with the mail attribute providing the mail domain name
     in the IDNA encoded form.
  
  5.1.    The inetEmail Attribute
  
     The inetEmail attribute is for internationalized Internet email
     addresses which are to be stored in LDAP as whole sequences.
  
  
  Hall                  I-D Expires: January 2004            [page 11]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     The inetEmail attribute type is defined as follows:
  
          ( OID.TBD
            NAME 'inetEmail'
            EQUALITY caseIgnoreMatch
            SUBSTR caseIgnoreSubstringsMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
  
     The inetEmail attribute is technically unstructured, although it
     ostensibly uses a three-part syntax consisting of a localpart
     element, a Commercial-At character (0x40, "@"), and an
     internationalized domain name.
  
     The localpart element is currently unspecified, pending ongoing
     effort to internationalize this element. In the meantime, agents
     SHOULD NOT prohibit any possible uses of this element. Note that
     subsequent versions of this specification may define specific
     rules for this element.
  
     The domain name portion of the email address SHOULD be treated as
     an internationalized domain name, and SHOULD be validated
     according to the procedure defined in section 3.2 wherever it is
     feasible and beneficial to do so.
  
     Due to the way that email routing uses domain names, the domain
     element of an inetEmail attributes has to be mapped to a domain
     name which satisfies strict naming requirements, and as such, the
     corresponding domain names have to be restricted to hostname
     rules. Since the more liberal forms cannot be used, the
     UseSTD3ASCIIRules and AllowUnassigned IDNA flags MUST be set to
     their strictest settings when the domain name element is validated
     and normalized.
  
  5.2.    The inetEmailObject Object Class
  
     The inetEmailObject object class is an auxiliary object class
     which provides inetEmail as an optional attribute. The
     inetEmailObject object class is intended to be used in conjunction
     with a structural object class such as person, inetOrgPerson, or
     organizationalPerson, none of which provide the inetEmail
     attribute.
  
  
  Hall                  I-D Expires: January 2004            [page 12]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
  
     The inetEmailObject object class is defined as follows:
  
          ( OID.TBD
            NAME 'inetEmailObject'
            SUP top
            AUXILIARY
            MUST inetEmail )
  
     Note that the structural object class in use with the entry will
     define the naming attribute for that entry. As such, the inetEmail
     attribute will only be one of potentially many child attributes,
     with no relevance to the name of the entry.
  
  6.      The iLDAP URI Scheme
  
     This section defines the iLDAP URI scheme as an internationalized
     version of the LDAP URL scheme defined in RFC 2255 [RFC2255], and
     clarifies its use with the labeledURI attribute defined in RFC
     2079 [RFC2079].
  
     The iLDAP URI scheme is designed as a UTF-8 URI scheme, capable of
     containing a fully internationalized sequence of elements.
     Specifically, the iLDAP URI scheme is syntactically identical to
     the LDAP URL scheme defined in [RFC2255], except that all of the
     elements in the iLDAP URI (including the hostname element) carry
     UTF-8 data, in an unencoded and unescaped form.
  
     The LDAP attributes designed to carry URIs are multi-valued, and
     an iLDAP URI can freely coexist with the legacy LDAP URL scheme as
     an equal sibling. In these kinds of scenarios, LDAP agents can
     freely choose among the URI schemes offered in an multi-valued
     array, and ignore those URI schemes that it does not support. As
     such, the presence of the iLDAP URI scheme in these arrays is not
     usually harmful.
  
     In order for that strategy to work properly, traditional LDAP URIs
     MUST be provided as an equal sibling wherever an iLDAP URI is also
     being provided. Otherwise, it is possible for a legacy agent to be
     presented with a URI that it does not support.
  
     Furthermore, in order to limit the potential for damage in
     secondary applications, LDAP agents which support the iLDAP URI
     syntax MUST ensure that they will perform any necessary encoding
     of the URI if that data is subsequently passed across a seven-bit
     medium. For example, if an LDAP agent expects to pass an iLDAP URI
  
  Hall                  I-D Expires: January 2004            [page 13]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     in a seven-bit email message, the contents of the URI must either
     be converted into a seven-bit compatible form, or the message body
     must be encoded as Base64 or Quoted-Printable, or some other steps
     must be taken to ensure that the iLDAP URI does not become
     corrupted by the seven-bit medium.
  
     In those cases where an iLDAP URI has to be converted into a
     seven-bit compatible form, the hostname in the "hostport" element
     MUST be IDNA encoded, and the remainder of the elements MUST be
     percent-escaped as described in [RFC2255].
  
     Note that the labeledURI attribute defined in [RFC2079] uses the
     directoryString syntax, although [RFC2079] explicitly states that
     the use of non-ASCII characters is discouraged. This specification
     overrides that recommendation when the iLDAP URI type is used.
  
  7.      Open Issues
  
     Should a structured domain name sequence be formally defined, with
     the inetDomainComponent and inetEmail attributes formally
     incorporating that sequence?
  
     Should the inetEmail attribute be formally defined as structured,
     with the appropriate ASN.1?
  
     Should there be extensible matching filters that accept non-
     normalized input, normalize it, and then search for matching
     elements and/or attributes?
  
  8.      Security Considerations
  
     TBD
  
  9.      IANA Considerations
  
     TBD
  
  10.     Author's Addresses
  
     Eric A. Hall
     ehall@ehsco.com
  
  11.     Normative References
  
          [ASCII]       Cerf, V. "ASCII format for Network
                        Interchange", RFC 20, October 1969.
  
  
  Hall                  I-D Expires: January 2004            [page 14]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
          [ISO10646]    "International Standard -- Information
                        technology -- Universal Multiple-Octet Coded
                        Character Set (UCS) -- Part 1: Architecture
                        and Basic Multilingual Plane", ISO/IEC
                        10646-1:2000.
  
          [RFC1274]     Barker, P., and S. Kille, "The COSINE and
                        Internet X.500 Schema", RFC 1274, November
                        1991.
  
          [RFC2079]     M. Smith, "Definition of an X.500 Attribute
                        Type and an Object Class to Hold Uniform
                        Resource Identifiers (URIs)", RFC 2079,
                        January 1997.
  
          [RFC2247]     Kille, S., Wahl, M., Grimstad, A., Huber, R.,
                        and Sataluri, S. "Using Domains in LDAP/X.500
                        DNs", RFC 2247, January 1998.
  
          [RFC2251]     Wahl, M., Howes, T., and Kille, S.
                        "Lightweight Directory Access Protocol (v3)",
                        RFC 2251, December 1997.
  
          [RFC2252]     Wahl, M., Coulbeck, A., Howes, T., and Kille,
                        S. "Lightweight Directory Access Protocol
                        (v3): Attribute Syntax Definitions", RFC 2252,
                        December 1997.
  
          [RFC2254]     Howes, T. "The String Representation of LDAP
                        Search Filters", RFC 2254, December 1997.
  
          [RFC2255]     Howes, T., and M. Smith, "The LDAP URL
                        Format", RFC 2255, December 1997.
  
          [RFC2279]     Yergeau, F. "UTF-8, a transformation format of
                        ISO 10646", RFC 2279, January 1998.
  
          [RFC3377]     Hodges, J., and Morgan, R. "Lightweight
                        Directory Access Protocol (v3): Technical
                        Specification", RFC 3377, September 2002.
  
          [RFC3490]     Faltstrom, P., Hoffman, P., and Costello, A.
                        "Internationalizing Domain Names in
                        Applications (IDNA)", RFC 3490, March 2003.
  
  12.     Acknowledgments
  
     Funding for the RFC editor function is currently provided by the
     Internet Society.
  
  
  Hall                  I-D Expires: January 2004            [page 15]


  Internet Draft        draft-hall-ldap-idn-00.txt            June 2003
  
  
     This document incorporates several elements from Internet Drafts
     written by Kurt Zeilenga, who also played an important part in the
     development of the concepts included herein.
  
  13.     Full Copyright Statement
  
     Copyright (C) The Internet Society (2003). All Rights Reserved.
  
     This document and translations of it may be copied and furnished
     to others, and derivative works that comment on or otherwise
     explain it or assist in its implementation may be prepared,
     copied, published and distributed, in whole or in part, without
     restriction of any kind, provided that the above copyright notice
     and this paragraph are included on all such copies and derivative
     works. However, this document itself may not be modified in any
     way, such as by removing the copyright notice or references to the
     Internet Society or other Internet organizations, except as needed
     for the purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards
     process must be followed, or as required to translate it into
     languages other than English.
  
     The limited permissions granted above are perpetual and will not
     be revoked by the Internet Society or its successors or assigns.
  
     This document and the information contained herein is provided on
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  
  
  Hall                  I-D Expires: January 2004            [page 16]