idnits 2.17.1 draft-hall-ldap-idn-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in ' Category: Standards-Track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (June 2003) is 7613 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2251' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 661, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' ** 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 2254 (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2255 (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Eric A. Hall 3 Document: draft-hall-ldap-idn-00.txt June 2003 4 Expires: January, 2004 5 Category: Standards-Track 7 LDAP Schema Extensions for 8 Internationalized Domain Names 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document defines schema and behavioral rules which are 39 necessary to fully accommodate the use of internationalized domain 40 names as UTF-8 sequences in LDAP. Specifically, this document 41 defines an internationalized domain component attribute, email 42 address attribute, URI syntax, and several related object classes, 43 and also discusses their usage considerations. 45 Table of Contents 47 1. Background and Overview...................................2 48 2. Prerequisites and Terminology.............................3 49 3. Validation and Conversion.................................3 50 3.1. Processing Junctures...................................3 51 3.2. Processing Algorithm...................................5 52 3.3. Escape Syntax..........................................6 53 3.4. Client Transformation Guidelines.......................8 54 4. Internationalized Domain Components.......................8 55 4.1. The idc (inetDomainComponent) Attribute................9 56 4.2. The inetIdcDomain Object Class........................10 57 4.3. The inetIdcObject Object Class........................11 58 5. Internationalized Email Addresses........................11 59 5.1. The inetEmail Attribute...............................11 60 5.2. The inetEmailObject Object Class......................12 61 6. The iLDAP URI Scheme.....................................13 62 7. Open Issues..............................................14 63 8. Security Considerations..................................14 64 9. IANA Considerations......................................14 65 10. Author's Addresses.......................................14 66 11. Normative References.....................................14 67 12. Acknowledgments..........................................15 68 13. Full Copyright Statement.................................16 70 1. Background and Overview 72 Although the LDAPv3 [RFC3377] service is explicitly capable of 73 transferring characters from the Universal Character Set (UCS) 74 [ISO10646] which have been encoded into eight-bit sequences with 75 UTF-8 [RFC2279], the core LDAP schema and service elements which 76 explicitly carry domain names as structured data are syntactically 77 restricted to a subset of seven-bit character codes. 79 This restriction is due to historical limitations with the domain 80 names themselves, although recent standards-track activity towards 81 defining internationalized domain names and their usage has made 82 these universal restrictions somewhat inappropriate and excessive, 83 particularly in those cases where LDAP systems are required to use 84 a UTF-8 form of the internationalized domain names directly. 86 Although LDAP applications are free to define whichever attributes 87 and syntaxes they may need for their own internal use (including 88 any private attributes related to domain names), there is also a 89 need for internationalized versions of the common domain-related 90 schema and service elements to be made available for those 91 applications. As such, this document defines internationalized 92 versions of those common elements for the benefit of those 93 applications, and also discusses their usage considerations. 95 Specifically, this document defines internationalized forms of the 96 domainComponent attribute and its associated object classes, the 97 mail attribute and a related object class, and the LDAP URL. 98 Through the judicious use of these elements, LDAP applications can 99 take full advantage of the "native" representation of 100 internationalized domain names, while also using the legacy 101 attributes to ensure backwards-compatibility with applications 102 that still require the legacy form of those domain names. 104 2. Prerequisites and Terminology 106 Readers of this specification are expected to be familiar with 107 LDAPv3 [RFC3377], IDNA [RFC3490], and UTF-8 [RFC2279]. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 110 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 111 in this document are to be interpreted as described in RFC 2119. 113 3. Validation and Conversion 115 Internationalized domain names are expected to be validated before 116 they are used, wherever this is possible. This section discusses 117 where that validation should occur, and also defines the 118 validation algorithm that should be used at those junctures. 120 3.1. Processing Junctures 122 The specifications which currently govern internationalized domain 123 names do not define specific syntax rules for those domain names, 124 but instead define functions for encoding and decoding the domain 125 names into ASCII [ASCII] compatible sequences. This effectively 126 means that the contents of an internationalized domain name 127 element cannot be validated with syntax rules, but instead must be 128 validated through the use of local function calls. 130 Since existing systems have historically relied upon syntax rules 131 to determine validity, those systems cannot be readily expected to 132 perform these function calls. In order to accommodate these 133 systems and avoid problems which may otherwise occur, this 134 specification does not imposes any formal syntax rules on the 135 elements themselves, but instead requires that internationalized 136 domain names be validated before the data is stored or 137 transferred, if the opportunity presents itself. Essentially, this 138 approach makes the internationalized domain name elements 139 transparent, capable of carrying any eight-bit data, while 140 requiring that the party which generates the data perform the 141 necessary function calls. 143 Specifically, internationalized domain names are expected to be 144 validated at the following points: 146 * Operators of LDAP servers SHOULD validate the data before 147 it is added to the server, if possible. For example, if the 148 operator of a server creates a new naming context that uses 149 the inetDomainComponent attribute, then that operator 150 SHOULD ensure that the internationalized domain name labels 151 contained therein are syntactically valid prior to creating 152 the naming context. Similarly, if an application generates 153 LDIF output which contains internationalized domain names, 154 the script which generates that output SHOULD ensure that 155 those domain names are syntactically valid. 157 * Client applications SHOULD validate the data whenever that 158 data is originally created, if possible. For example, if an 159 application allows the creation of inetMail attribute 160 values with foreknowledge of that attribute's usage, the 161 application SHOULD validate the attribute value prior to 162 submitting the data to the server for storage. 164 * Client applications SHOULD validate any data they extract 165 from LDAP prior to passing that data to an external 166 application. For example, if an user-facing application 167 will pass an inetMail attribute value to an email client, 168 the LDAP application SHOULD validate the attribute value 169 prior to sending it on, if possible. 171 * The client SHOULD use the most appropriate form of the data 172 when passing that data to another application, either by 173 using the most-appropriate of the attributes, or by down- 174 converting the internationalized form if necessary. In 175 those cases where the client has no a priori knowledge of 176 the recipient application's capabilities, the ASCII 177 compatible form MUST be used. 179 3.2. Processing Algorithm 181 Wherever an internationalized domain name is to be validated, the 182 input domain name MUST use the conversion algorithm defined in 183 this section. These rules apply to any domain name which is stored 184 in any internationalized domain name element, regardless of the 185 contents of the input. For example, these rules apply to domain 186 names which only contain printable ASCII characters, domain names 187 which appear to already be encoded into IDNA, and domain names 188 which contain UCS character codes. 190 In general terms, the validation process requires that every 191 domain name which is to be stored in an internationalized domain 192 name element undergo a two-part conversion, with the input first 193 being reduced to its canonical IDNA-encoded form, and then being 194 expanded into its UTF-8 encoded UCS form. This process ensures 195 that the domain name has been validated as a semantically correct 196 IDNA sequence, and that the resulting internationalized domain 197 name has been properly normalized into its canonical form. 199 The full process is as follows: 201 a. Unless otherwise explicitly defined, disable the 202 UseSTD3ASCIIRules IDNA flag and enable the AllowUnassigned 203 IDNA flag, thereby permitting the broadest range of 204 character codes to be used. 206 b. If the input domain name terminates with a Full-Stop 207 character (0x2E) but does not consist of a single Full-Stop 208 character alone, remove the trailing Full-Stop character 209 from the input. 211 c. Perform the "ToASCII" conversion operation specified in 212 [RFC3490]. This step will reduce the input domain name to 213 the canonical IDNA-compatible form, thus ensuring that the 214 input data can be properly normalized when it is 215 reconstructed, and also ensuring that any subsequent 216 conversions back into the ASCII-compatible form will result 217 in predictable and legitimate domain names. 219 d. Perform the "ToUnicode" conversion operation specified in 220 [RFC3490] against the output from step 3.2.a above. This 221 step will convert the ASCII-compatible sequence into a 222 sequence of UCS code-point values. 224 e. Encode the output from step 3.2.d into UTF-8. 226 Note that the UseSTD3ASCIIRules and AllowUnassigned IDNA flags 227 MUST be set to their most liberal settings by default, and are not 228 to be used unless the underlying application-specific usage of a 229 domain name is known to require usage to the contrary. 231 By following these rules, the internationalized domain names which 232 appear in the available elements will always be valid, and will 233 always be usable by applications which specifically make use of 234 the elements, while those systems which do not make explicit use 235 of these elements but which may inadvertently pass the 236 internationalized domain names to other applications will not be 237 exposed to any potential risks which may have been otherwise 238 caused from malformed data. 240 Also note that these requirements are significantly more stringent 241 than the requirements for validating legacy domain names in the 242 legacy elements, and also apply to legacy-compatible domain names 243 which are stored in the internationalized elements. For example, 244 the existing domainComponent and mail attributes do not require 245 data to be validated against the known syntax rules for domain 246 names and email addresses, but instead simply limit the range of 247 character codes to a relatively small subset, while the rules 248 defined above will result in the same canonical input having a 249 stricter actual syntax. 251 3.3. Escape Syntax 253 Certain applications allow for the use of "unusual" characters or 254 octet values which are not typically associated with traditional 255 domain names, but which must be preserved in order for the 256 associated applications to function properly. For example, an 257 application-specific domain name may contain an Underscore 258 character (0x5F) or a Space character (0x20), or may contain a 259 "raw" octet value such as 0xC0 and which cannot be treated as a 260 UCS character code during normalization routines (otherwise the 261 corresponding UCS character code value would be interpreted and 262 lowercased, thus destroying the actual octet value). 264 In order to ensure that these kinds of values are properly 265 preserved, a formal escape syntax is defined for their use. In 266 general terms, this syntax requires problematic eight-bit values 267 to be replaced with a Reverse-Solidus character (0x5C, "\"), 268 followed by a three-digit decimal value (in the range of "000" 269 through "255") that corresponds to the canonical octet value. 271 This escape syntax MUST be applied to any octet value which does 272 not explicitly represent a printable character (0x00 through 0x20, 273 0x7F through 0x9F, and 0xA0, inclusive), or which represents an 274 embedded Reverse-Solidus character (0x5C, "\"). In those cases 275 where a valid escape sequence already exists, that sequence 276 (including its leading Reverse-Solidus character) MUST NOT be 277 escaped again. 279 This escape syntax MAY be applied to any other character code or 280 octet value, although the unnecessary usage of this mechanism is 281 strongly DISCOURAGED. Furthermore, the availability of this 282 mechanism MUST NOT be interpreted to mean that this mechanism can 283 be used with any domain name; instead, it is only to be used with 284 application-specific domain names which explicitly allow the 285 presence of these problematic characters. 287 For example, if an application-specific domain name contains 288 "weird name.example.com", the "weird name" portion of that domain 289 name MUST be escaped as "weird\032name". Meanwhile, if an 290 application-specific domain name contains "local\046postmaster", 291 this sequence would be unmodified since the Reverse-Solidus 292 character is already part of a valid escape sequence. 294 This escape syntax MUST be applied to an input domain name before 295 that domain name undergoes the conversion process described in 296 section 3.2. Furthermore, the leaf-node applications which 297 generate and use these domain names SHOULD escape the data before 298 it is passed to an LDAP agent, since those agents cannot be 299 expected to know all of the application-specific usages of a 300 domain name. For example, an application which uses a domain name 301 with an embedded Full-Stop character (0x2E, ".") SHOULD escape 302 that character before storing or passing the domain name to an 303 LDAP agent, thus eliminating the possibility of having that agent 304 interpret the embedded Full-Stop character as a label separator. 306 Note that any Reverse Solidus characters in the resulting domain 307 name will be further escaped when these sequences are transferred 308 in LDAP messages. For example, "weird\032name" will be further 309 escaped as "weird\\032name" when it is passed in an LDAP message 310 (this secondary escape will be stripped upon receipt, leaving the 311 escaped domain name in its original form). 313 Also note that Reverse-Solidus characters are frequently illegal 314 as data in URIs, and these characters will probably end up being 315 percent-escaped whenever they are provided in a URI as data. 317 3.4. Client Transformation Guidelines 319 This specification defines data elements for storing the rich 320 representations of internationalized domain names, with the 321 expectation that those domain names will be viewed and manipulated 322 in their native form, and that ASCII compatible encodings of those 323 domain names will be provided in the legacy elements. 325 Therefore, in the general case, clients and servers SHOULD display 326 and use internationalized domain name elements in the native form 327 as offered by the elements in use, and SHOULD NOT transform the 328 data into another representation for display purposes unless the 329 user has specifically requested the client to provide an 330 alternative representation of those elements. 332 Specifically, IDNA encoded elements SHOULD NOT be transformed into 333 UTF-8, and vice versa, unless the user explicitly requests this 334 action to take place. 336 4. Internationalized Domain Components 338 This section defines the idc (inetDomainComponent) attribute, the 339 inetIdcObject object class, and the inetIdcDomain object class, as 340 internationalized versions of the schema defined in [RFC2247]. 342 In the typical usage scenario, the inetDomainComponent attribute 343 and related object classes will be used to define the naming 344 context of a directory partition. For new installations which are 345 limited to this simple usage, these elements can be deployed 346 without any special considerations. 348 In those cases which uses the domainComponent attribute already 349 exists, but where applications do not perform any kind of active 350 mapping between domain names and the domainComponent attributes, 351 it may be feasible to simply migrate the existing data from the 352 existing naming context, and to either update the clients to use 353 the newer partition or use referrals to redirect the clients 354 automatically. 356 In those cases where agents perform some kind of active mapping 357 between domain names and the legacy domainComponent attributes, 358 the use of referrals may be sufficient to redirect LDAP clients 359 away from the domainComponent naming context and towards the 360 inetDomainComponent naming context. 362 In those cases where referrals to another naming context are not 363 feasible, organizations can continue to use the domainComponent 364 naming, and simply apply the inetIdcObject auxiliary object class 365 to the existing entries. Although this approach will not modernize 366 the partition structure, it will allow both attribute sets to 367 coexist simultaneously, and will also allow searches for the 368 internationalized domain names to successfully match. 370 4.1. The idc (inetDomainComponent) Attribute 372 The idc attribute is for internationalized domain names which are 373 to be stored in LDAP as sequences of relative distinguished names, 374 with each attribute being mapped to discrete labels from the 375 associated DNS domain name. 377 The idc attribute type is defined as follows: 379 ( OID.TBD 380 NAME ( 'idc' 'inetDomainComponent' ) 381 EQUALITY caseIgnoreMatch 382 ORDERING caseIgnoreOrderingMatch 383 SUBSTR caseIgnoreSubstringsMatch 384 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 385 SINGLE-VALUE ) 387 Servers MAY map the idc attribute name to a synonym of 388 inetDomainComponent. Systems MUST NOT use inetDomainComponent as 389 the attribute name in any messages they generate. 391 The value of this attribute is a directory string holding one 392 label component of an internationalized domain name, preferably as 393 normalized and validated according to the process defined in 394 section 3. 396 In those cases where the input domain name specifically and solely 397 refers to the root domain, the root domain MUST be represented as 398 a single idc attribute containing a single Full-Stop character 399 ("idc=."), and in this specific scenario, the Full-Stop character 400 MUST NOT be escaped. If the input domain name contains any other 401 sequence of labels, the root domain MUST NOT be specified in the 402 resulting idc attribute sequence. 404 idc attributes are typically mapped to zone names, and as such, 405 the corresponding domain names are usually restricted to hostname 406 rules. However, this restriction is not formally implied or 407 mandated, and any domain name (containing any octet value) is 408 explicitly permitted. As such, the UseSTD3ASCIIRules and 409 AllowUnassigned IDNA flags MUST be set to their most liberal 410 settings during conversion. However, subsequent application- 411 specific uses of the idc attribute MAY apply stricter syntax 412 checks if needed (this may be necessary with application-specific 413 usages such as digital certificates, for example). In this regard, 414 the ability to represent a domain name in an idc attribute does 415 not guarantee that every application will be able to use the 416 corresponding attribute value. 418 Note that many characters in an internationalized domain name will 419 be converted to lowercase as part of the normalization process. 420 However, case MUST be ignored during comparison operations since 421 the existence of legacy systems will mean that not all domain 422 names will have been properly normalized. 424 4.2. The inetIdcDomain Object Class 426 The inetIdcDomain object class is a structural object class, which 427 uses idc as the mandatory naming attribute, and which provides 428 several additional optional attributes that may be used to 429 describe a particular organizational entity. 431 The inetIdcDomain object class is defined as follows: 433 ( OID.TBD 434 NAME 'inetIdcDomain' 435 SUP top 436 STRUCTURAL 437 MUST idc 438 MAY ( userPassword $ searchGuide $ seeAlso $ 439 businessCategory $ x121Address $ registeredAddress $ 440 destinationIndicator $ preferredDeliveryMethod $ 441 telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ 442 internationaliSDNNumber $ facsimileTelephoneNumber $ street 443 $ postOfficeBox $ postalCode $ postalAddress $ 444 physicalDeliveryOfficeName $ st $ l $ description $ o $ 445 associatedName ) ) 447 The optional attributes of the inetIdcDomain object class are used 448 for describing the object represented by this domain name, and may 449 also be useful for searches. 451 Note that the dcObject object class defined in [RFC2247] may be 452 used to supplement the inetIdcDomain object class, allowing the 453 legacy domainComponent attribute to be bound to an entry which 454 uses the inetIdcDomain object class. 456 4.3. The inetIdcObject Object Class 458 The inetIdcObject object class is an auxiliary object class which 459 provides idc as an optional attribute. The inetIdcObject object 460 class is intended to be used in conjunction with a structural 461 object class such as organization, organizationalUnit, or 462 locality, none of which provide the idc attribute. 464 The inetIdcObject object class is defined as follows: 466 ( OID.TBD 467 NAME 'inetIdcObject' 468 SUP top 469 AUXILIARY 470 MUST idc ) 472 Note that the structural object class in use with the entry will 473 define the naming attribute for that entry. As such, the idc 474 attribute will only be one of potentially many child attributes, 475 with no relevance to the name of the entry. 477 5. Internationalized Email Addresses 479 This section defines the inetEmail attribute and the auxiliary 480 inetEmailObject object class, as internationalized versions of the 481 mail attribute defined in RFC 1274 [RFC1274]. 483 In the typical usage scenario, the inetEmail attribute and related 484 object class will be used to define an internationalized Internet 485 email address attribute as additional data for a contact-related 486 object class such as inetOrgPerson. The inetEmail attribute is not 487 expected to be used as a naming attribute, and imposes no 488 namespace considerations. 490 The inetEmail and mail attributes can coexist in an entry without 491 difficulty, with the mail attribute providing the mail domain name 492 in the IDNA encoded form. 494 5.1. The inetEmail Attribute 496 The inetEmail attribute is for internationalized Internet email 497 addresses which are to be stored in LDAP as whole sequences. 499 The inetEmail attribute type is defined as follows: 501 ( OID.TBD 502 NAME 'inetEmail' 503 EQUALITY caseIgnoreMatch 504 SUBSTR caseIgnoreSubstringsMatch 505 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 507 The inetEmail attribute is technically unstructured, although it 508 ostensibly uses a three-part syntax consisting of a localpart 509 element, a Commercial-At character (0x40, "@"), and an 510 internationalized domain name. 512 The localpart element is currently unspecified, pending ongoing 513 effort to internationalize this element. In the meantime, agents 514 SHOULD NOT prohibit any possible uses of this element. Note that 515 subsequent versions of this specification may define specific 516 rules for this element. 518 The domain name portion of the email address SHOULD be treated as 519 an internationalized domain name, and SHOULD be validated 520 according to the procedure defined in section 3.2 wherever it is 521 feasible and beneficial to do so. 523 Due to the way that email routing uses domain names, the domain 524 element of an inetEmail attributes has to be mapped to a domain 525 name which satisfies strict naming requirements, and as such, the 526 corresponding domain names have to be restricted to hostname 527 rules. Since the more liberal forms cannot be used, the 528 UseSTD3ASCIIRules and AllowUnassigned IDNA flags MUST be set to 529 their strictest settings when the domain name element is validated 530 and normalized. 532 5.2. The inetEmailObject Object Class 534 The inetEmailObject object class is an auxiliary object class 535 which provides inetEmail as an optional attribute. The 536 inetEmailObject object class is intended to be used in conjunction 537 with a structural object class such as person, inetOrgPerson, or 538 organizationalPerson, none of which provide the inetEmail 539 attribute. 541 The inetEmailObject object class is defined as follows: 543 ( OID.TBD 544 NAME 'inetEmailObject' 545 SUP top 546 AUXILIARY 547 MUST inetEmail ) 549 Note that the structural object class in use with the entry will 550 define the naming attribute for that entry. As such, the inetEmail 551 attribute will only be one of potentially many child attributes, 552 with no relevance to the name of the entry. 554 6. The iLDAP URI Scheme 556 This section defines the iLDAP URI scheme as an internationalized 557 version of the LDAP URL scheme defined in RFC 2255 [RFC2255], and 558 clarifies its use with the labeledURI attribute defined in RFC 559 2079 [RFC2079]. 561 The iLDAP URI scheme is designed as a UTF-8 URI scheme, capable of 562 containing a fully internationalized sequence of elements. 563 Specifically, the iLDAP URI scheme is syntactically identical to 564 the LDAP URL scheme defined in [RFC2255], except that all of the 565 elements in the iLDAP URI (including the hostname element) carry 566 UTF-8 data, in an unencoded and unescaped form. 568 The LDAP attributes designed to carry URIs are multi-valued, and 569 an iLDAP URI can freely coexist with the legacy LDAP URL scheme as 570 an equal sibling. In these kinds of scenarios, LDAP agents can 571 freely choose among the URI schemes offered in an multi-valued 572 array, and ignore those URI schemes that it does not support. As 573 such, the presence of the iLDAP URI scheme in these arrays is not 574 usually harmful. 576 In order for that strategy to work properly, traditional LDAP URIs 577 MUST be provided as an equal sibling wherever an iLDAP URI is also 578 being provided. Otherwise, it is possible for a legacy agent to be 579 presented with a URI that it does not support. 581 Furthermore, in order to limit the potential for damage in 582 secondary applications, LDAP agents which support the iLDAP URI 583 syntax MUST ensure that they will perform any necessary encoding 584 of the URI if that data is subsequently passed across a seven-bit 585 medium. For example, if an LDAP agent expects to pass an iLDAP URI 586 in a seven-bit email message, the contents of the URI must either 587 be converted into a seven-bit compatible form, or the message body 588 must be encoded as Base64 or Quoted-Printable, or some other steps 589 must be taken to ensure that the iLDAP URI does not become 590 corrupted by the seven-bit medium. 592 In those cases where an iLDAP URI has to be converted into a 593 seven-bit compatible form, the hostname in the "hostport" element 594 MUST be IDNA encoded, and the remainder of the elements MUST be 595 percent-escaped as described in [RFC2255]. 597 Note that the labeledURI attribute defined in [RFC2079] uses the 598 directoryString syntax, although [RFC2079] explicitly states that 599 the use of non-ASCII characters is discouraged. This specification 600 overrides that recommendation when the iLDAP URI type is used. 602 7. Open Issues 604 Should a structured domain name sequence be formally defined, with 605 the inetDomainComponent and inetEmail attributes formally 606 incorporating that sequence? 608 Should the inetEmail attribute be formally defined as structured, 609 with the appropriate ASN.1? 611 Should there be extensible matching filters that accept non- 612 normalized input, normalize it, and then search for matching 613 elements and/or attributes? 615 8. Security Considerations 617 TBD 619 9. IANA Considerations 621 TBD 623 10. Author's Addresses 625 Eric A. Hall 626 ehall@ehsco.com 628 11. Normative References 630 [ASCII] Cerf, V. "ASCII format for Network 631 Interchange", RFC 20, October 1969. 633 [ISO10646] "International Standard -- Information 634 technology -- Universal Multiple-Octet Coded 635 Character Set (UCS) -- Part 1: Architecture 636 and Basic Multilingual Plane", ISO/IEC 637 10646-1:2000. 639 [RFC1274] Barker, P., and S. Kille, "The COSINE and 640 Internet X.500 Schema", RFC 1274, November 641 1991. 643 [RFC2079] M. Smith, "Definition of an X.500 Attribute 644 Type and an Object Class to Hold Uniform 645 Resource Identifiers (URIs)", RFC 2079, 646 January 1997. 648 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 649 and Sataluri, S. "Using Domains in LDAP/X.500 650 DNs", RFC 2247, January 1998. 652 [RFC2251] Wahl, M., Howes, T., and Kille, S. 653 "Lightweight Directory Access Protocol (v3)", 654 RFC 2251, December 1997. 656 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 657 S. "Lightweight Directory Access Protocol 658 (v3): Attribute Syntax Definitions", RFC 2252, 659 December 1997. 661 [RFC2254] Howes, T. "The String Representation of LDAP 662 Search Filters", RFC 2254, December 1997. 664 [RFC2255] Howes, T., and M. Smith, "The LDAP URL 665 Format", RFC 2255, December 1997. 667 [RFC2279] Yergeau, F. "UTF-8, a transformation format of 668 ISO 10646", RFC 2279, January 1998. 670 [RFC3377] Hodges, J., and Morgan, R. "Lightweight 671 Directory Access Protocol (v3): Technical 672 Specification", RFC 3377, September 2002. 674 [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. 675 "Internationalizing Domain Names in 676 Applications (IDNA)", RFC 3490, March 2003. 678 12. Acknowledgments 680 Funding for the RFC editor function is currently provided by the 681 Internet Society. 683 This document incorporates several elements from Internet Drafts 684 written by Kurt Zeilenga, who also played an important part in the 685 development of the concepts included herein. 687 13. Full Copyright Statement 689 Copyright (C) The Internet Society (2003). All Rights Reserved. 691 This document and translations of it may be copied and furnished 692 to others, and derivative works that comment on or otherwise 693 explain it or assist in its implementation may be prepared, 694 copied, published and distributed, in whole or in part, without 695 restriction of any kind, provided that the above copyright notice 696 and this paragraph are included on all such copies and derivative 697 works. However, this document itself may not be modified in any 698 way, such as by removing the copyright notice or references to the 699 Internet Society or other Internet organizations, except as needed 700 for the purpose of developing Internet standards in which case the 701 procedures for copyrights defined in the Internet Standards 702 process must be followed, or as required to translate it into 703 languages other than English. 705 The limited permissions granted above are perpetual and will not 706 be revoked by the Internet Society or its successors or assigns. 708 This document and the information contained herein is provided on 709 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 710 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 711 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 712 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 713 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.