idnits 2.17.1 draft-zeilenga-ldap-idn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2119], [RFC2252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 273 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be interpreted as described in BCP 14 [RFC2119]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 November 2001) is 8164 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NAMEREF' is mentioned on line 91, but not defined ** Obsolete normative reference: RFC 1274 (Obsoleted by RFC 4524) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- No information found for draft-ietf-idn-idna-xx - is the name correct? -- No information found for draft-ietf-ldapext-locate-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- No information found for draft-masinter-url-i18n-xx - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental OpenLDAP Foundation 4 Expires: 20 May 2002 20 November 2001 6 International Domain Names and LDAP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as an Experimental document. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF LDAP Extensions Working Group 18 mailing list . Please send editorial 19 comments directly to the author . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright 2001, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Abstract 41 This document explores how the Lightweight Directory Access Protocol 42 (LDAP) can be extended to support International Domain Names. 44 Conventions 46 Schema definitions are provided using LDAPv3 description formats 48 [RFC2252]. Definitions provided here are formatted (line wrapped) for 49 readability. 51 The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD", 52 "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be 53 interpreted as described in BCP 14 [RFC2119]. 55 1. Background and Intended Use 57 Experimental internationalized domain name systems exist. The IETF is 58 actively engineering standards in this area [IDN]. Though this work 59 is in progress, enough is known [IDNA] to experiment with 60 international domain names in applications and application level 61 protocols such as LDAP [RFC2251]. 63 This document describes schema and mechanisms extending LDAP to 64 support [IDN] based upon guidelines for the internationalizing host 65 names in applications [IDNA]. 67 This document does not consider domain names which are embedded in 68 authentication and security layers (e.g. SASL [RFC2222] and TLS 69 [RFC2246]) used by LDAP. The document also does not consider the 70 potential use of Internationalized Resource Identifiers [IRI] in LDAP. 72 2. Domain use in LDAP 74 Excepting user application data transferred by the protocol (see 75 section 3), domain names only appear within URLs [RFC2396] returned as 76 part of Referral or Search Continuation. As the protocol provides no 77 means for the server to determine if the client is able to recognize 78 and utilize internationalized domain names, an ASCII Compatible 79 Encoding (ACE) of the domain name SHALL be used for within hostpart of 80 these URLs. 82 Internationalized clients which display these URLs to users, such as 83 to obtain permission to chase the referral, SHOULD convert the ACE 84 domain name to an international domain name by applying the ToUnicode 85 operation [IDNA] to each domain component. 87 2.1 Managing Referral Information 89 Referral knowledge information can be stored in the directory and is 90 managed by directory users using general purpose or specialized 91 clients. When [NAMEREF] is used, the referral knowledge is in the 92 form of URIs which are used by the server in generating referrals and 93 search continuations. To avoid unnecessary (and possibly unsupported) 94 conversion of the domain name within the hostpart of the URL by the 95 server, the client SHALL provide an ACE domain name. 97 Internationalized clients which display these URLs to users SHOULD 98 convert the ACE domain name to an international domain name by 99 applying the ToUnicode operation [IDNA] to each component of the name. 100 Internationalized clients SHALL convert International domain names 101 provided by users to ACE domain name by applying the ToASCII operation 102 [IDNA] to each domain component. 104 3. Domains in User Application Data 106 In general, user application data defined (previous to the the 107 publication of this document) such that domain names in values are 108 restricted to IA5 (ASCII). This includes attributes such as 109 domainComponent (DC), associatedDomain, rfc822mailbox (mail) and 110 labeledURI. LDAP applications expect values to be valid according to 111 the syntax defined for the attribute. Where the defined syntax 112 requires the domain to be restricted to IA5 (ASCII), ACE domain names 113 MUST be used. 115 Internationalized clients which display these domain names to users 116 SHOULD convert the ACE domain name to an international domain name by 117 applying the ToUnicode operation [IDNA] to each component of the name. 118 Internationalized clients SHALL convert International domain names 119 provided by users to ACE domain name by applying the ToASCII operation 120 [IDNA] to each domain component before transferring the value in the 121 protocol. 123 4. International Domain Schema 125 The schema described in this section is intended to be used similar to 126 the schema described in [RFC2247] excepting that it is used 127 conjunction with a Internationalized Domain Names. Hence domain 128 components are restricted to UTF-8 not IA5. Section 4 discusses 129 locating directory services using the International Domain Name 130 System. 132 This section defined internationalized versions of the domain related 133 schema elements introduced in [RFC1274] and subsequently adapted for 134 use with LDAP [RFC2247]. 136 Editor's Note: object identifiers (OIDs) will be assigned before this 137 document is published as an RFC. 139 4.1. International Domain Component 141 The IDC (short for International Domain Component) attribute type is 142 defined as follows: 144 ( OID.TBD NAME 'IDC' 145 EQUALITY caseIgnoreMatch 146 ORDERING caseIgnoreOrderingMatch 147 SUBSTR caseIgnoreSubstringsMatch 148 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 149 SINGLE-VALUE ) 151 The value of this attribute is a DirectoryString holding one component 152 of an international domain name. The encoding of DirectoryString for 153 use in LDAP is normally simply the characters, represented in UTF-8, 154 of the string itself. 156 The matchings rule are case insensitive, as is today's IDN. 158 Values of this attribute can be accessed and maintained using general 159 purpose LDAP clients as such clients are capable of handling any 160 attribute of DirectoryString syntax. 162 4.2. International Domain Component Object 164 The idcObject object class permits the IDC attribute to be present in 165 an entry. This object class is defined as auxiliary, as it would 166 typically be used in conjunction with an existing structural object 167 class, such as organization, organizationalUnit or locality. 169 The following object class, along with the IDC attribute, can be added 170 to any entry. 172 ( OID.TBD NAME 'idcObject' 173 AUXILIARY MUST IDC ) 175 An example entry would be: 177 dn: IDC=example,IDC=com 178 objectClass: top 179 objectClass: organization 180 objectClass: idcObject 181 IDC: example 182 o: Example Organization 184 5. Locating LDAP services using IDNA 185 To locate services associated with a DN using IDC based naming (as 186 described above), the application converts the DN to a domain name as 187 described in Section 2 of [LOCATE] treating IDC found in the DN the 188 same as DCs. The application then converts the resulting 189 internationalized domain name to the appropriate ACE domain name 190 applying the ToASCII operation [IDNA] to each component. The 191 application then proceeds with the location process described in 192 Section 3 of [LOCATE]. 194 6. Security Considerations 196 This document describes how attributes of objects may be discovered 197 and retrieved. Servers should ensure that an appropriate security 198 policy is maintained. 200 An enterprise is not restricted in the information which it may store 201 in DNS or LDAP servers. A client which contacts an untrusted server 202 may have incorrect or misleading information returned (e.g. an 203 organization's server may claim to hold naming contexts representing 204 domain names which have not been delegated to that organization). 206 7. Acknowledgment 208 The author would like thank the thoughtful comments of members of the 209 IETF IDN, LDAPbis, and LDAPext working groups. 211 This document borrows heavily from a number of IETF documents. 213 8. Author's Address 215 Kurt D. Zeilenga 216 OpenLDAP Foundation 217 219 9. Normative References 221 [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 222 Schema", November 1991. 224 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 225 Requirement Levels", RFC 2119, March 1997. 227 [RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 228 "Using Domains in LDAP/X.500 Distinguished Names", RFC 229 2247, January 1998. 231 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 232 Protocol (v3)", RFC 2251, December 1997. 234 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 235 Directory Access Protocol (v3): Attribute Syntax 236 Definitions", RFC 2252, December 1997. 238 [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 239 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 241 [IDNA] P. Faltstrom, P. Hoffman, A. Costello "Internationalizing 242 Host Names In Applications," draft-ietf-idn-idna-xx.txt (a 243 work in progress). 245 [LOCATE] IETF LDAPext WG, "Discovering LDAP Services with DNS", 246 draft-ietf-ldapext-locate-xx.txt (work in progress). 248 10. Informative References 250 [RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)", 251 RFC 2222, October 1997. 253 [RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 254 2246, January 1999. 256 [IDN] IETF International Domain Name (IDN) Working Group, 257 http://www.ietf.org/html.charters/idn-charter.html. 259 [IRI] L. Masinter, M. Duerst, "Internationalized Resource 260 Identifiers (IRI)", draft-masinter-url-i18n-xx.txt (a work in 261 progress). 263 Copyright 2001, The Internet Society. All Rights Reserved. 265 This document and translations of it may be copied and furnished to 266 others, and derivative works that comment on or otherwise explain it 267 or assist in its implementation may be prepared, copied, published and 268 distributed, in whole or in part, without restriction of any kind, 269 provided that the above copyright notice and this paragraph are 270 included on all such copies and derivative works. However, this 271 document itself may not be modified in any way, such as by removing 272 the copyright notice or references to the Internet Society or other 273 Internet organizations, except as needed for the purpose of 274 developing Internet standards in which case the procedures for 275 copyrights defined in the Internet Standards process must be followed, 276 or as required to translate it into languages other than English. 278 The limited permissions granted above are perpetual and will not be 279 revoked by the Internet Society or its successors or assigns. 281 This document and the information contained herein is provided on an 282 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 283 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.