idnits 2.17.1 draft-ietf-ldapext-lang-00.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 12 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 (8 January 1998) is 9603 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 328 looks like a reference -- Missing reference section? '2' on line 331 looks like a reference -- Missing reference section? '3' on line 335 looks like a reference -- Missing reference section? '4' on line 338 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 Critical Angle Inc. 3 T. Howes 4 Netscape Communications Corp. 5 Expires in six months from 8 January 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 ds.internic.net (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. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC 2119 [4]. 51 draft-ietf-ldapext-lang-00.txt January 1998 53 3. Language Codes 55 Section 2 of RFC 1766 [3] describes the language code format which is 56 used in LDAP. Briefly, it is a string of ASCII alphabetic characters 57 and hyphens. Examples include "fr", "en-US" and "ja-JP". 59 Language codes are case insensitive. For example, the language code 60 "en-us" is the same as "EN-US" and "en-US". 62 Implementations MUST NOT otherwise interpret the structure of the 63 code when comparing two codes, and MUST treat them as simply 64 strings of characters. Client and server implementations MUST allow 65 any arbitrary string which follows the patterns given in RFC 1766 to 66 be used as a language code. 68 4. Use of Language Codes in LDAP 70 This section describes how LDAP implementations MUST interpret 71 language codes in performing operations. 73 In general, an attribute with a language code is to be treated as a 74 subtype of the attribute without a language code. If a server does 75 not support storing language codes with attribute values in the DIT, 76 then it MUST always treat an attribute with a language code as an 77 unrecognized attribute. 79 4.1. Attribute Description 81 An attribute consists of a type, a list of options for that type, and 82 a set of one or more values. In LDAP, the type and the options are 83 combined into the AttributeDescription, defined in section 4.1.5 of 84 [1]. This is represented as an attribute type name and a 85 possibly-empty list of options. One of these options associates a 86 natural language with values for that attribute. 88 language-option = "lang-" lang-code 90 lang-code = printable-ascii ; a code as defined in RFC 1766 92 There can be at most one language option present in an 93 AttributeDescription. 95 The language code has no effect on the character set encoding for 96 string representations of DirectoryString syntax values; the UTF-8 97 representation of UniversalString (ISO 10646) is always used. 99 Examples of valid AttributeDescription: 100 givenName;lang-en-US 101 CN;lang-ja 102 draft-ietf-ldapext-lang-00.txt January 1998 104 In LDAP and in examples in this document, a directory attribute is 105 represented as an AttributeDescription with a list of values. Note 106 that the data could be stored in the LDAP server in a different 107 representation. 109 4.2. Distinguished Names and Relative Distinguished Names 111 No attribute description options are permitted in Distinguished Names 112 or Relative Distinguished Names. Thus language codes MUST NOT be 113 used in forming DNs. 115 4.3. Search Filter 117 If a language code is present in an AttributeDescription in a search 118 filter, then only attribute values in the directory which match the 119 base attribute type or its subtype, the language code and the 120 assertion value match this filter. 122 Thus for example a filter of an equality match of type 123 "name;lang-en-US" and assertion value "Billy Ray", against the 124 following directory entry 126 objectclass: top DOES NOT MATCH (wrong type) 127 objectclass: person DOES NOT MATCH (wrong type) 128 name;lang-EN-US: Billy Ray MATCHES 129 name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value) 130 CN;lang-en-us: Billy Ray MATCHES 131 CN;lang-EN-US;dynamic: Billy Ray MATCHES 132 CN;lang-en;dynamic: Billy Ray DOES NOT MATCH (differing lang-) 133 name: Billy Ray DOES NOT MATCH (no lang-) 134 SN: Ray DOES NOT MATCH (wrong value) 136 (Note that "CN" and "SN" are subtypes of "name".) 138 Client implementors should however note that providing a language code 139 in a search filter AttributeDescription will often filter out 140 desirable values where the language code does not match exactly. For 141 example, the filter (name;lang-en=Billy Ray) does NOT match the 142 attribute "name;lang-en-US: Billy Ray". 144 If the server does not support storing language codes with attribute 145 values in the DIT, then any filter which includes a language code 146 will always fail to match, as it is an unrecognized attribute type. 147 No error would be returned because of this; a presence filter would 148 evaluate to FALSE and all other forms to Undefined. 150 If no language code is specified in the search filter, then only the 151 base attribute type and the assertion value need match the value in 152 the directory. 154 draft-ietf-ldapext-lang-00.txt January 1998 156 Thus for example a filter of an equality match of type "name" and 157 assertion value "Billy Ray", against the following directory entry 159 objectclass: top DOES NOT MATCH (wrong type) 160 objectclass: person DOES NOT MATCH (wrong type) 161 name;lang-EN-US: Billy Ray MATCHES 162 name;lang-EN-US: Billy Bob DOES NOT MATCH (wrong value) 163 CN;lang-EN-US;dynamic: Billy Ray MATCHES 164 CN;lang-en;dynamic: Billy Ray MATCHES 165 name: Billy Ray MATCHES 166 SN: Ray DOES NOT MATCH (wrong value) 168 Thus in general, clients SHOULD NOT use the language code option in 169 AttributeDescription fields in search filters. 171 4.4. Compare 173 A language code can be present in an AttributeDescription used in a 174 compare request AttributeValueAssertion. This is to be treated 175 by servers the same as the use of language codes in a search filter 176 with an equality match, as described in the previous section. If 177 there is no attribute in the entry with the same subtype and language 178 code, the noSuchAttributeType error will be returned. 180 Thus for example a compare request of type "name" and assertion value 181 "Johann", against an entry with all the following directory entry 183 objectclass: top 184 objectclass: person 185 givenName;lang-de-DE: Johann 186 CN: Johann Sibelius 187 SN: Sibelius 189 will cause the server to return compareTrue. 191 However, if the client issued a compare request of type "name;lang-de" 192 and assertion value "Johann" against the above entry, the request 193 would fail with the noSuchAttributeType error. 195 If the server does not support storing language codes with attribute 196 values in the DIT, then any comparison which includes a language code 197 will always fail to locate an attribute type, and noSuchAttributeType 198 will be returned. 200 Thus in general, clients SHOULD NOT use the language code option in 201 AttributeDescription fields in the compare request. 203 4.5. Requested Attributes in Search 205 Clients MAY provide language codes in AttributeDescription in the 206 requested attribute list in a search request. 208 draft-ietf-ldapext-lang-00.txt January 1998 210 If a language code is provided in an attribute description, then only 211 attribute values in a directory entry which have the same language 212 code as that provided are to be returned. Thus if a client requests an 213 attribute "description;lang-en", the server MUST NOT return values of 214 an attribute "description" or "description;lang-fr". 216 Clients MAY provide in the attribute list multiple 217 AttributeDescription which have the same base attribute type but 218 different options. For example a client MAY provide both 219 "name;lang-en" and "name;lang-fr", and this would permit an attribute 220 with either language code to be returned. Note there would be no 221 need to provide both "name" and "name;lang-en" since all subtypes of 222 name would match "name". 224 If a server does not support storing language codes with attribute 225 values in the DIT, then any attribute descriptions in the list which 226 include language codes are to be ignored, just as if they were 227 unknown attribute types. 229 If a request is made specifying all attributes or an attribute is 230 requested without providing a language code, then all attribute values 231 regardless of their language code are returned. 233 For example, if the client requests a "description" attribute, and a 234 matching entry contains 236 objectclass: top 237 objectclass: organization 238 O: Software GmbH 239 description: software 240 description;lang-en: software products 241 description;lang-de: Softwareprodukte 242 postalAddress: Berlin 8001 Germany 243 postalAddress;lang-de: Berlin 8001 Deutschland 245 The server will return: 247 description: software 248 description;lang-en: software products 249 description;lang-de: Softwareprodukte 251 4.6. Add Operation 253 Clients MAY provide language codes in AttributeDescription in 254 attributes of a new entry to be created, subject to the limitation 255 that the client MUST NOT use language codes in the attribute value or 256 values which form the RDN of the entry. 258 A client MAY provide multiple attributes with the same attribute type 259 and value, so long as each attribute has a different language code, 260 and at most one attribute does not have a language code option. 262 draft-ietf-ldapext-lang-00.txt January 1998 264 Servers which support storing language codes in the DIT MUST allow any 265 attribute it recognizes that has the Directory String syntax to have a 266 language option associated with it. Servers SHOULD allow language 267 options to be associated with other attributes. 269 For example, the following is a legal request. 271 objectclass: top 272 objectclass: person 273 objectclass: residentialPerson 274 name: John Smith 275 CN: John Smith 276 CN;lang-en: John Smith 277 SN: Smith 278 streetAddress: 1 University Street 279 streetAddress;lang-en: 1 University Street 280 streetAddress;lang-fr: 1 rue Universite 281 houseIdentifier;lang-fr: 9e etage 283 If a server does not support storing language codes with attribute 284 values in the DIT, then it MUST treat an AttributeDescription with a 285 language code as an unrecognized attribute. If the server forbids the 286 addition of unrecognized attributes then it MUST fail the add request 287 with the appropriate result code. 289 4.7. Modify Operation 291 A client MAY provide a language code in an AttributeDescription as 292 part of a modification element in the modify operation. 294 Attribute types and language codes MUST match exactly against values 295 stored in the directory. For example, if the modification is a 296 "delete", then if the stored values to be deleted have a language 297 code, the language code MUST be provided in the modify operation, and 298 if the stored values to be deleted do not have a language code, then 299 no language code is to be provided. 301 If the server does not support storing language codes with attribute 302 values in the DIT, then it MUST treat an AttributeDescription with a 303 language code as an unrecognized attribute, and MUST fail the request 304 with an appropriate result code. 306 4.8. Diagnostic Messages 308 Servers SHOULD use only printable ASCII characters in the errorMessage 309 field, as not all clients will be able to display the full range of 310 Unicode. 312 5. Security Considerations 314 There are no known security considerations for this document. See 315 the security considerations sections of [1] and [2] for security 316 considerations of LDAP in general. 318 draft-ietf-ldapext-lang-00.txt January 1998 320 6. Acknowledgements 322 This document is a product of the IETF ASID and LDAPEXT working groups. 323 Martin Duerst provided many valuable comments on an earlier version of 324 this document. 326 7. Bibliography 328 [1] M.Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 329 (v3)", RFC 2251. 331 [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500 332 Directory Access Protocol Attribute Syntax Definitions", 333 RFC 2252. 335 [3] H. Alvestrand, "Tags for the Identification of Languages", 336 RFC 1766. 338 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 339 Levels", RFC 2119. 341 8. Authors Addresses 343 Mark Wahl 344 Critical Angle Inc. 345 4815 W Braker Lane #502-385 346 Austin, TX 78759 347 USA 349 EMail: M.Wahl@critical-angle.com 351 Tim Howes 352 Netscape Communications Corp. 353 501 E. Middlefield Rd 354 Mountain View, CA 94043 355 USA 357 Phone: +1 650 937-3419 358 EMail: howes@netscape.com 359 draft-ietf-ldapext-lang-00.txt January 1998 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.