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]