idnits 2.17.1 draft-ietf-ldapext-lang-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** 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 Introduction section. ** 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.) ** There are 11 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 24 has weird spacing: '...listing conta...' -- 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 (17 July 1998) is 9415 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) -- Missing reference section? '1' on line 331 looks like a reference -- Missing reference section? '2' on line 334 looks like a reference -- Missing reference section? '3' on line 338 looks like a reference -- Missing reference section? '4' on line 341 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT Innosoft International, Inc. 3 T. Howes 4 Netscape Communications Corp. 5 Expires in six months from 17 July 1998 6 Intended Category: Standards Track 8 Use of Language Codes in LDAP 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas,and 15 its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 26 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 Copyright Notice 30 Copyright (C) The Internet Society (1998). All Rights Reserved. 32 2. Abstract 34 The Lightweight Directory Access Protocol [1] provides a means for 35 clients to interrogate and modify information stored in a distributed 36 directory system. The information in the directory is maintained as 37 attributes [2] of entries. Most of these attributes have syntaxes 38 which are human-readable strings, and it is desirable to be able to 39 indicate the natural language associated with attribute values. 41 This document describes how language codes [3] are carried in LDAP 42 and are to be interpreted by LDAP servers. All implementations MUST 43 be prepared to accept language codes in the LDAP protocols. Servers 44 may or may not be capable of storing attributes with language codes 45 in the directory. This document does not specify how to determine 46 whether particular attributes can or cannot have language codes. 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 50 this document are to be interpreted as described in RFC 2119 [4]. 52 3. Language Codes 54 Section 2 of RFC 1766 [3] describes the language code format which is 55 used in LDAP. Briefly, it is a string of ASCII alphabetic characters 56 and hyphens. Examples include "fr", "en-US" and "ja-JP". 58 Language codes are case insensitive. For example, the language code 59 "en-us" is the same as "EN-US" and "en-US". 61 Implementations MUST NOT otherwise interpret the structure of the 62 code when comparing two codes, and MUST treat them as simply 63 strings of characters. Client and server implementations MUST allow 64 any arbitrary string which follows the patterns given in RFC 1766 to 65 be used as a language code. 67 4. Use of Language Codes in LDAP 69 This section describes how LDAP implementations MUST interpret 70 language codes in performing operations. 72 In general, an attribute with a language code is to be treated as a 73 subtype of the attribute without a language code. If a server does 74 not support storing language codes with attribute values in the DIT, 75 then it MUST always treat an attribute with a language code as an 76 unrecognized attribute. 78 4.1. Attribute Description 80 An attribute consists of a type, a list of options for that type, and 81 a set of one or more values. In LDAP, the type and the options are 82 combined into the AttributeDescription, defined in section 4.1.5 of 83 [1]. This is represented as an attribute type name and a 84 possibly-empty list of options. One of these options associates a 85 natural language with values for that attribute. 87 language-option = "lang-" lang-code 89 lang-code = printable-ascii ; a code as defined in RFC 1766 91 Multiple language options may be present on a particular value. 93 The language code has no effect on the character set encoding for 94 string representations of DirectoryString syntax values; the UTF-8 95 representation of UniversalString (ISO 10646) is always used. 97 Examples of valid AttributeDescription: 98 givenName;lang-en-US 99 CN;lang-ja 101 In LDAP and in examples in this document, a directory attribute is 102 represented as an AttributeDescription with a list of values. Note 103 that the data could be stored in the LDAP server in a different 104 representation. 106 4.2. Distinguished Names and Relative Distinguished Names 108 No attribute description options are permitted in Distinguished Names 109 or Relative Distinguished Names. Thus language codes MUST NOT be 110 used in forming DNs. 112 4.3. Search Filter 114 If a language code is present in an AttributeDescription in a search 115 filter, then only attribute values in the directory which match the 116 base attribute type or its subtype, the language code and the 117 assertion value match this filter. 119 Thus for example a filter of an equality match of type 120 "name;lang-en-US" and assertion value "Billy Ray", against the 121 following directory entry 123 objectclass: top DOES NOT MATCH (wrong type) 124 objectclass: person DOES NOT MATCH (wrong type) 125 name;lang-EN-US: Billy Ray MATCHES 126 name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value) 127 CN;lang-en-us: Billy Ray MATCHES 128 CN;lang-EN-US;dynamic: Billy Ray MATCHES 129 CN;lang-en;dynamic: Billy Ray DOES NOT MATCH (differing lang-) 130 name: Billy Ray DOES NOT MATCH (no lang-) 131 SN: Ray DOES NOT MATCH (wrong value) 133 (Note that "CN" and "SN" are subtypes of "name".) 135 Client implementors should however note that providing a language code 136 in a search filter AttributeDescription will often filter out 137 desirable values where the language code does not match exactly. For 138 example, the filter (name;lang-en=Billy Ray) does NOT match the 139 attribute "name;lang-en-US: Billy Ray". 141 If the server does not support storing language codes with attribute 142 values in the DIT, then any filter which includes a language code 143 will always fail to match, as it is an unrecognized attribute type. 144 No error would be returned because of this; a presence filter would 145 evaluate to FALSE and all other forms to Undefined. 147 If no language code is specified in the search filter, then only the 148 base attribute type and the assertion value need match the value in 149 the directory. 151 Thus for example a filter of an equality match of type "name" and 152 assertion value "Billy Ray", against the following directory entry 154 objectclass: top DOES NOT MATCH (wrong type) 155 objectclass: person DOES NOT MATCH (wrong type) 156 name;lang-EN-US: Billy Ray MATCHES 157 name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value) 158 CN;lang-EN-US;dynamic: Billy Ray MATCHES 159 CN;lang-en;dynamic: Billy Ray MATCHES 160 name: Billy Ray MATCHES 161 SN: Ray DOES NOT MATCH (wrong value) 163 Thus in general, clients SHOULD NOT use the language code option in 164 AttributeDescription fields in search filters. 166 4.4. Compare 168 A language code can be present in an AttributeDescription used in a 169 compare request AttributeValueAssertion. This is to be treated 170 by servers the same as the use of language codes in a search filter 171 with an equality match, as described in the previous section. If 172 there is no attribute in the entry with the same subtype and language 173 code, the noSuchAttributeType error will be returned. 175 Thus for example a compare request of type "name" and assertion value 176 "Johann", against an entry with all the following directory entry 178 objectclass: top 179 objectclass: person 180 givenName;lang-de-DE: Johann 181 CN: Johann Sibelius 182 SN: Sibelius 184 will cause the server to return compareTrue. 186 However, if the client issued a compare request of type "name;lang-de" 187 and assertion value "Johann" against the above entry, the request 188 would fail with the noSuchAttributeType error. 190 If the server does not support storing language codes with attribute 191 values in the DIT, then any comparison which includes a language code 192 will always fail to locate an attribute type, and noSuchAttributeType 193 will be returned. 195 Thus in general, clients SHOULD NOT use the language code option in 196 AttributeDescription fields in the compare request. 198 4.5. Requested Attributes in Search 200 Clients MAY provide language codes in AttributeDescription in the 201 requested attribute list in a search request. 203 If a language code is provided in an attribute description, then only 204 attribute values in a directory entry which have the same language 205 code as that provided are to be returned. Thus if a client requests an 206 attribute "description;lang-en", the server MUST NOT return values of 207 an attribute "description" or "description;lang-fr". 209 Clients MAY provide in the attribute list multiple 210 AttributeDescription which have the same base attribute type but 211 different options. For example a client MAY provide both 212 "name;lang-en" and "name;lang-fr", and this would permit an attribute 213 with either language code to be returned. Note there would be no 214 need to provide both "name" and "name;lang-en" since all subtypes of 215 name would match "name". 217 If a server does not support storing language codes with attribute 218 values in the DIT, then any attribute descriptions in the list which 219 include language codes are to be ignored, just as if they were 220 unknown attribute types. 222 If a request is made specifying all attributes or an attribute is 223 requested without providing a language code, then all attribute values 224 regardless of their language code are returned. 226 For example, if the client requests a "description" attribute, and a 227 matching entry contains 229 objectclass: top 230 objectclass: organization 231 O: Software GmbH 232 description: software 233 description;lang-en: software products 234 description;lang-de: Softwareprodukte 235 postalAddress: Berlin 8001 Germany 236 postalAddress;lang-de: Berlin 8001 Deutschland 238 The server will return: 240 description: software 241 description;lang-en: software products 242 description;lang-de: Softwareprodukte 244 4.6. Add Operation 246 Clients MAY provide language codes in AttributeDescription in 247 attributes of a new entry to be created, subject to the limitation 248 that the client MUST NOT use language codes in the attribute value or 249 values which form the RDN of the entry. 251 A client MAY provide multiple attributes with the same attribute type 252 and value, so long as each attribute has a different language code, 253 and at most one attribute does not have a language code option. 255 Servers which support storing language codes in the DIT MUST allow any 256 attribute it recognizes that has the Directory String syntax to have a 257 language option associated with it. Servers SHOULD allow language 258 options to be associated with other attributes. 260 For example, the following is a legal request. 262 objectclass: top 263 objectclass: person 264 objectclass: residentialPerson 265 name: John Smith 266 CN: John Smith 267 CN;lang-en: John Smith 268 SN: Smith 269 streetAddress: 1 University Street 270 streetAddress;lang-en: 1 University Street 271 streetAddress;lang-fr: 1 rue Universite 272 houseIdentifier;lang-fr: 9e etage 274 If a server does not support storing language codes with attribute 275 values in the DIT, then it MUST treat an AttributeDescription with a 276 language code as an unrecognized attribute. If the server forbids the 277 addition of unrecognized attributes then it MUST fail the add request 278 with the appropriate result code. 280 4.7. Modify Operation 282 A client MAY provide a language code in an AttributeDescription as 283 part of a modification element in the modify operation. 285 Attribute types and language codes MUST match exactly against values 286 stored in the directory. For example, if the modification is a 287 "delete", then if the stored values to be deleted have a language 288 code, the language code MUST be provided in the modify operation, and 289 if the stored values to be deleted do not have a language code, then 290 no language code is to be provided. 292 If the server does not support storing language codes with attribute 293 values in the DIT, then it MUST treat an AttributeDescription with a 294 language code as an unrecognized attribute, and MUST fail the request 295 with an appropriate result code. 297 4.8. Diagnostic Messages 299 Servers SHOULD use only printable ASCII characters in the errorMessage 300 field, as not all clients will be able to display the full range of 301 Unicode. 303 5. Differences from X.500(1997) 305 X.500(1997) defines a different mechanism, contexts, as the means of 306 representing language tags. This section summarizes the major 307 differences in approach. 309 a) An X.500 operation which has specified a language code on a 310 value matches a value in the directory without a language code. 311 b) LDAP references RFC 1766, which allows for IANA registration of 312 new tags. 313 c) LDAP does not allow language codes in distinguished names. 314 d) X.500 describes subschema administration procedures to allow 315 language codes to be associated with particular attributes types. 317 6. Security Considerations 319 There are no known security considerations for this document. See 320 the security considerations sections of [1] and [2] for security 321 considerations of LDAP in general. 323 7. Acknowledgements 325 This document is a product of the IETF ASID and LDAPEXT working groups. 326 Martin Duerst provided many valuable comments on an earlier version of 327 this document. 329 8. Bibliography 331 [1] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 332 (v3)", RFC 2251. 334 [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500 335 Directory Access Protocol Attribute Syntax Definitions", 336 RFC 2252. 338 [3] H. Alvestrand, "Tags for the Identification of Languages", 339 RFC 1766. 341 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 342 Levels", RFC 2119. 344 9. Authors Addresses 346 Mark Wahl 347 Innosoft International, Inc. 348 8911 Capital of Texas Hwy Suite 4140 349 Austin, TX 78759 USA 351 EMail: M.Wahl@innosoft.com 353 Tim Howes 354 Netscape Communications Corp. 355 501 E. Middlefield Rd 356 Mountain View, CA 94043 USA 358 Phone: +1 650 937-3419 359 EMail: howes@netscape.com 361 Full Copyright Statement 363 Copyright (C) The Internet Society (1998). All Rights Reserved. 365 This document and translations of it may be copied and furnished to 366 others, and derivative works that comment on or otherwise explain it 367 or assist in its implementation may be prepared, copied, published 368 and distributed, in whole or in part, without restriction of any 369 kind, provided that the above copyright notice and this paragraph are 370 included on all such copies and derivative works. However, this 371 document itself may not be modified in any way, such as by removing 372 the copyright notice or references to the Internet Society or other 373 Internet organizations, except as needed for the purpose of 374 developing Internet standards in which case the procedures for 375 copyrights defined in the Internet Standards process must be 376 followed, or as required to translate it into languages other than 377 English. 379 The limited permissions granted above are perpetual and will not be 380 revoked by the Internet Society or its successors or assigns. 382 This document and the information contained herein is provided on an 383 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 384 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 385 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 386 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 387 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.