From: Kurt Zeilenga Date: Sat, 28 Aug 2004 15:52:18 +0000 (+0000) Subject: deprecated X-Git-Tag: OPENLDAP_REL_ENG_2_3_0ALPHA~606 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=1abceb3020f4b807140af1caae98841b378e0675;p=openldap deprecated --- diff --git a/doc/drafts/draft-byrne-ldap-alias-xx.txt b/doc/drafts/draft-byrne-ldap-alias-xx.txt deleted file mode 100644 index 0595ecdfe0..0000000000 --- a/doc/drafts/draft-byrne-ldap-alias-xx.txt +++ /dev/null @@ -1,324 +0,0 @@ - - Internet-Draft D. Byrne, IBM - LDAP Extensions WG L. Poitou, Sun - Intended Category: Standards Track E. Stokes, IBM - Expires: 20 October 1998 - - 20 April 1998 - - Use of Aliases within LDAP - - - STATUS OF THIS MEMO - - This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted - by other documents at any time. It is not appropriate to use - Internet Drafts as reference material or to cite them other - than as a "working draft" or "work in progress." - - To view the entire list of current Internet-Drafts, please - check the "1id-abstracts.txt" listing contained in the - Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), - ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern - Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East - Coast), or ftp.isi.edu (US West Coast). - - Comments and suggestions on this document are encouraged. - Comments on this document should be sent to the LDAPEXT - working group discussion list: - - ietf-ldapext@netscape.com - - ABSTRACT - - This document describes the suggested behavior for aliases for - LDAPv3 and above to improve LDAP server interoperability . - - The key words "MUST", "SHOULD", and "MAY" used in this - document are to be interpreted as described in [Bradner97]. - - - 1. Objectives - - - Aliases may be used within LDAP to reference entries anywhere - within the directory tree. Conceptually, an alias is simply a - pointer to the DIT entry it represents. It does not contain - additional information about that entry; only the location of - the entry. - - The behavior of the alias object within LDAP is not well- - defined, both in creation of the alias object and the behavior - when dereferencing the alias. - - For successful interoperability, the expected behavior of - servers when encountering alias objects SHOULD be consistent. - - Additionally, it MUST be possible to use aliases without - changing the LDAPv3 schema as defined in [Wahl] and without - adding server-dependent data. - - - 2. Schema Definition - - - 2.1 Schema Expansion - - The alias objectclass definitions presented in the LDAPv3 - Schema [Wahl] are the basis for aliasing within ldap. The - alias objectclass is a Structural objectclass with a single - required attribute; the single valued aliasObjectName. - - This definition of the alias objectclass does not allow for - any attribute other than 'aliasedObjectName' to be used as the - naming attribute within the RDN. The resulting dn for the - alias object must therefore be of the form - "aliasedObjectName=, , ..." This is not a - user-friendly name for a directory entry, and quite possibly - corrupts the naming hierarchy within the directory tree. - - In order to remain true the concept of an alias; that it is - merely a pointer to another entry, an entry of objectclass - alias SHOULD NOT be combined with any other objectclass. If - multiple objectclasses are combined, it becomes possible to - add information to the alias entry without violating the - schema rules. - - While not explicitly specified as either a 'required' or - 'may', any naming attribute MUST be allowed to form the RDN of - the alias. Restricting the possible naming attributes would - potentially corrupt the hierarchy. For example, it would be - impossible to distinguish between a person alias and an - organisation alias. - - 2.2 AliasObject Objectclass - - In order to create an alias object which can be appropriately - named to that which it represents, the definition of the alias - object MUST be expanded. A new objectclass must be defined - which inherits from the current definition of alias but - extends the attributes allowed within the RDN. - - ( 1.3.6.1.4.1.42.2.27.1.2.1 - NAME 'aliasObject' - DESC objectclass for all alias objects - SUP 'ALIAS' - MAY * - ) - - The '*' allows any naming attribute to be used in forming the - RDN of the object. - - For example, the following is a correct LDIF: - dn: cn=John Doe, ou=myOrg, c=US - objectclass: alias - objectclass: aliasObject - aliasedObjectName: cn=President, ou=myOrg, c=US - cn: John Doe - - To prevent the alias from containing extra information about - the object, the naming attribute SHOULD contain only a single - value. - - For example, the following is not a correct LDIF: - dn: cn=John Doe, ou=myOrg, c=US - objectclass: alias - objectclass: aliasObject - aliasedObjectName: cn=President, ou=myOrg, c=US - cn: John Doe - cn: Doe - - Similarly, the following would not be a correct LDIF file - because it adds extra information to the alias object. - - dn: cn=John Doe, ou=myOrg, c=US - objectclass: alias - objectclass: aliasObject - aliasedObjectName: cn=President, ou=myOrg, c=US - cn: John Doe - title: President - - The naming attribute used to form the RDN of the object SHOULD - reflect the naming attribute of the referenced object. - However, there are some cases where the naming attribute MAY - be different. - - Within the X.501 [ITU-T], the attribute used to described the - aliased object is 'aliasedEntryName'. Since the OID for - 'aliasedEntryName' and 'aliasedObjectName' are the same for - both X.500 and LDAP, LDAP servers SHOULD treat the - 'aliasedEntryName' as a synonym for 'aliasedObjectName'. - - - 3. Alias Behavior - - In general alias objects SHOULD NOT be dereferenced during any - operation other than search unless requested to do so by the - client. - - Since an alias points to another section of the tree, it MUST - NOT be possible to add an object under an alias object; alias - objects MUST always be leaf nodes. - - During the dereferencing of aliases, a loop is detected if the - server visits the same alias entry more than once. In this - case a data integrity error has occurred and the server MUST - return an error of 'aliasProblem' - - If an alias is dereferenced, and the resulting directory entry - does not exists, a data integrity problem has occurred, and - the server MUST return an error code of - 'aliasDereferencingProblem' - - If the base entry for an ldapsearch is an alias, and alias - dereferencing is set to either derefFindBaseObj, or - derefAlways, the base entry MUST be dereferenced before the - search is performed. The new base for the search will become - the entry to which the alias resolves. The search is then - performed. - - If multiple aliases are chained, the alias for the first - object MUST resolve to the last entry in the chain. For - example, A, B, and C are alias objects. If A points to B which - points to C which points to D, A resolves to D when - dereferencing the alias. - - If an alias is dereferenced as part of a search, the alias - entry itself SHOULD NOT be returned as part of the search. - - If an alias matches the search filter, and dereferencing is - set to 'searching' or 'always', the dereferenced object SHOULD - be returned, even if it does not match the filter. - - If the alias is not dereferenced during the search, and it - matches the filter, then it SHOULD be returned within the - search result. - - Each directory object matching a filter SHOULD be returned - only once during a search. If an entry is found twice because - of aliases pointing to a part of the tree already searched, - the entry SHOULD NOT be returned to the client a second time. - - 4. Scenarios - - Using the following LDIF, the scenarios would return the - expected information as follows: - - dn: c=myCountry - c: myCountry - objectclass: country - - dn: ou=Area1, c=myCountry - ou: Area1 - aliasedObjectName: o=myCorporation, c=myCountry - objectclass: alias - objectclass:aliasObject - - dn: o=myCorporation, c=myCountry - ou: myCorporation - objectclass:organization - - dn: cn=President, o=myCorporation, c=myCountry - cn: President - aliasObjectName: cn=John Doe, o=myCorporation, c=myCountry - objectclass: alias - objectclass: aliasObject - - dn: cn=John Doe, o=myCorporation, c=myCountry - cn: John Doe - objectclass: person - - - c = myCountry - / | - ou = Area1 -----> o = myCorporation - | \ - cn=President ---> cn = John Doe - - Performing a base search of 'ou = Area1, c=myCountry' with a - filter of 'objectclass=aliasObject' - NeverDerefAlias would return 'ou=Area1, c=myCountry' - DerefFinding would return 'cn=President, o=myCorporation, - c=myCountry' - DerefSearching would return 'o=myCorporation, - c=myCountry' - DerefAlways would return 'cn=John Doe, o=myCorporation, - c=myCountry' - - Performing a one level search of 'c=myCountry' with a filter - of 'ou = * ' - NeverDerefAlias would return 'ou=Area1, c=myCountry' - DerefFinding would return 'ou=Area1, c=myCountry' - DerefSearching would return 'o=myCorporation, - c=myCountry' - DerefAlways would return ' o=myCorporation, c=myCountry' - - Performing a full tree search of 'c=myCountry' with a filter - of ' cn = President ' - NeverDerefAlias would return 'cn=President, o=myCorporation, - c=myCountry' - DerefFinding would return 'cn=President, o=myCorporation, - c=myCountry' - DerefSearching would return 'cn=John Doe, o=myCorporation, - c=myCountry' - DerefAlways would return 'cn=John Doe, o=myCorporation, - c=myCountry' - - - 6. Security Considerations - - Permissions to dereferencing an alias, adding, deleting or - returning alias entries are decided by the directory server's - ACL administration policy. - - - 7. References - - [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [Whal] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight - Directory Access Protocol (v3)": Attribute Syntax Definitions, - RFC 2252, December 1997. - - [Bradner97] Bradner, Scott, "Key Words for use in RFCs to - Indicate Requirement Levels", RFC 2119. - - [ITU-T] ITU-T Rec. X.501, "The Directory: Models", 1993 - - - AUTHOR(S) ADDRESS - - - Debbie Byrne - IBM - 11400 Burnet Rd - Austin, TX 78758 - USA - mail-to: djbyrne@us.ibm.com - phone: +1 512 838 1930 - - Ludovic Poitou - Sun Microsystems - 32, Chemin du vieux Chene - 38240 Meylan - France - Phone: +33.(0)4.76.41.42.12 - email: ludovic.poitou@france.sun.com - - Ellen Stokes - IBM - 11400 Burnet Rd - Austin, TX 78758 - USA - mail-to: stokes@austin.ibm.com - phone: +1 512 838 3725 - - diff --git a/doc/drafts/draft-zeilenga-ldap-rfc2596-xx.txt b/doc/drafts/draft-zeilenga-ldap-rfc2596-xx.txt deleted file mode 100644 index 9acaac55b2..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-rfc2596-xx.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -INTERNET-DRAFT Editor: Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires in six months 9 December 2002 -Obsoletes: RFC 2596 - - - Language Tags and Ranges in LDAP - draft-zeilenga-ldap-rfc2596-04.txt - - -Status of Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - This document is intended to be, after appropriate review and - revision, submitted to the RFC Editor as a Standard Track document. - Distribution of this memo is unlimited. Technical discussion of this - document will take place on the IETF LDAP Extensions Working Group - (LDAPext) mailing list . Please send editorial - comments directly to the document editor . - - 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 - . The list of - Internet-Draft Shadow Directories can be accessed at - . - - Copyright 2002, The Internet Society. All Rights Reserved. - - Please see the Copyright section near the end of this document for - more information. - -Abstract - - It is often desirable to to be able to indicate the natural language - associated with values held in a directory and to be able to query the - directory for values which fulfill the user's language needs. This - document details the use of Language Tags and Ranges in the - Lightweight Directory Access Protocol (LDAP). - - - - -Zeilenga Language Tags and Ranges in LDAP [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - -Conventions - - 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 BCP 14 [RFC2119]. - - -1. Background and Intended Use - - The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a - means for clients to interrogate and modify information stored in a - distributed directory system. The information in the directory is - maintained as attributes of entries. Most of these attributes have - syntaxes which are human-readable strings, and it is desirable to be - able to indicate the natural language associated with attribute - values. - - This document describes how language tags and ranges [RFC3066] are - carried in LDAP and are to be interpreted by LDAP implementations. - All LDAP implementations MUST be prepared to accept language tags and - ranges. - - This document replaces RFC 2596. Appendix A summaries changes made - since RFC 2596. - - Appendix B discusses differences from X.500(1997) "contexts" - mechanism. - - Appendix A and B are provided for informational purposes only. - - The remainder of this section provides a summary of Language Tags, - Language Ranges, and Attribute Descriptions. - - -1.1. Language Tags - - Section 2 of BCP 47 [RFC3066] describes the language tag format which - is used in LDAP. Briefly, it is a string of ASCII letters and - hyphens. Examples include "fr", "en-US" and "ja-JP". Language tags - are case insensitive. That is, the language tag "en-us" is the same - as "EN-US". - - Section 2 of this document details use of language tags in LDAP. - - -1.2. Language Ranges - - Section 2.5 of BCP 47 [RFC3066] describes the language ranges. - - - -Zeilenga Language Tags and Ranges in LDAP [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - Language ranges are used to specify sets of language tags. - - A language range matches a language tag if it is exactly equal to the - tag, or if it is exactly equal to a prefix of the tag such that the - first character following the prefix is "-". That is, the language - range "de" matches the language tags "de" and "de-CH" but not "den". - The special language range "*" matches all language tags. - - Due to attribute description option naming restrictions in LDAP, this - document defines a different language range syntax. However, the - semantics of language ranges in LDAP is consistent with BCP 47. - - Section 3 of this document details use of language ranges in LDAP. - - -1.3. Attribute Descriptions - - This section provides an overview of attribute descriptions in LDAP. - LDAP attributes and attribute descriptions are defined in [RFC2251]. - - An attribute consists of a type, a set of zero or more associated - tagging options, and a set of one or more values. The type and the - options are combined into the AttributeDescription. - AttributeDescriptions can also contain options which are not part of - the attribute, but indicate some other function (such as range - assertion or transfer encoding). - - An AttributeDescription with one or more tagging options is a direct - subtype of each AttributeDescription of the same type with all but one - of the tagging options. If the AttributeDescription's type is a - direct subtype of some other type, then the AttributeDescription is - also a direct subtype of the AttributeDescription which consists of - the supertype and all of the tagging options. That is, - "CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and - "name;x-bar;x-foo". Note that "CN" is a subtype of "name". - - -2. Use of Language Tags in LDAP - - This section describes how LDAP implementations MUST interpret - language tags in performing operations. - - Servers which support storing attributes with language tag options in - the Directory Information Tree (DIT) SHOULD allow any attribute type - it recognizes that has the Directory String, IA5 String, or other - textual string syntaxes to have language tag options associated with - it. Servers MAY allow language options to be associated with other - attributes types. - - - -Zeilenga Language Tags and Ranges in LDAP [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - Clients SHOULD NOT assume servers are capable of storing attributes - with language tags in the directory. - - Implementations MUST NOT otherwise interpret the structure of the tag - when comparing two tag, and MUST treat them simply as strings of - characters. Implementations MUST allow any arbitrary string which - conforms to the syntax defined in BCP 47 [RFC3066] to be used as a - language tag. - - -2.1. Language Tag Options - - A language tag option associates a natural language with values of an - attribute. An attribute description may contain multiple language tag - options. An entry may contain multiple attributes with same attribute - type but different combinations of language tag (and other) options. - - A language tag option conforms to the following ABNF [RFC2234]: - - language-tag-option = "lang-" Language-Tag - - where the Language-Tag production is as defined in BCP 47 [RFC3066]. - This production and those it imports from [RFC2234] are provided here - for convenience: - - Language-Tag = Primary-subtag *( "-" Subtag ) - - Primary-subtag = 1*8ALPHA - - Subtag = 1*8(ALPHA / DIGIT) - - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - - DIGIT = %x30-39 ; 0-9 - - A language tag option is a tagging option. A language tag option has - no effect on the syntax of the attribute's values nor their transfer - encoding. - - Examples of valid AttributeDescription: - - givenName;lang-en-US - CN;lang-ja - SN;lang-de;lang-gem-PFL - O;lang-i-klingon;x-foobar - description;x-foobar - CN - - - - -Zeilenga Language Tags and Ranges in LDAP [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - Notes: The last two have no language tag options. The x-foobar option - is fictious and used for example purposes. - - -2.2. Search Filter - - If language tag options are present in an AttributeDescription in an - assertion, then for each entry within scope, the values of each - attribute whose AttributeDescription consists of the same attribute - type or its subtypes and contains each of the presented (and possibly - other) options is to be matched. - - Thus, for example, a filter of an equality match of type - "name;lang-en-US" and assertion value "Billy Ray", against the - following directory entry: - - dn: SN=Ray,DC=example,DC=com - objectclass: person DOES NOT MATCH (wrong type) - objectclass: extensibleObject DOES NOT MATCH (wrong type) - name;lang-en-US: Billy Ray MATCHES - name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) - CN;lang-en-US: Billy Ray MATCHES - CN;lang-en-US;x-foobar: Billy Ray MATCHES - CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-) - CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-) - name: Billy Ray DOES NOT MATCH (no lang-) - SN;lang-en-GB;lang-en-US: Billy Ray MATCHES - SN: Ray DOES NOT MATCH (no lang-, - wrong value) - - Note that "CN" and "SN" are subtypes of "name". - - It is noted that providing a language tag option in a search filter - AttributeDescription will filter out desirable values where the tag - does not match exactly. For example, the filter (name;lang-en=Billy - Ray) does NOT match the attribute "name;lang-en-US: Billy Ray". - - If the server does not support storing attributes with language tag - options in the DIT, then any assertion which includes a language tag - option will not match as such it is an unrecognized attribute type. - No error would be returned because of this; a presence assertion would - evaluate to FALSE and all other assertions to Undefined. - - If no options are specified in the assertion, then only the base - attribute type and the assertion value need match the value in the - directory. - - Thus, for example, a filter of an equality match of type "name" and - - - -Zeilenga Language Tags and Ranges in LDAP [Page 5] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - assertion value "Billy Ray", against the following directory entry: - - dn: SN=Ray,DC=example,DC=com - objectclass: person DOES NOT MATCH (wrong type) - objectclass: extensibleObject DOES NOT MATCH (wrong type) - name;lang-en-US: Billy Ray MATCHES - name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) - CN;lang-en-US;x-foobar: Billy Ray MATCHES - CN;lang-en;x-foobar: Billy Ray MATCHES - CN;x-foobar: Billy Ray MATCHES - name: Billy Ray MATCHES - SN;lang-en-GB;lang-en-US: Billy Ray MATCHES - SN: Ray DOES NOT MATCH (wrong value) - - -2.3. Requested Attributes in Search - - Clients can provide language tag options in each AttributeDescription - in the requested attribute list in a search request. - - If language tag options are provided in an attribute description, then - only attributes in a directory entry whose attribute descriptions have - the same attribute type or its subtype and contains each of the - presented (and possibly other) language tag options are to be - returned. Thus if a client requests just the attribute - "name;lang-en", the server would return "name;lang-en" and - "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr". - - Clients can provide in the attribute list multiple - AttributeDescriptions which have the same base attribute type but - different options. For example, a client could provide both - "name;lang-en" and "name;lang-fr", and this would permit an attribute - with either language tag option to be returned. Note there would be - no need to provide both "name" and "name;lang-en" since all subtypes - of name would match "name". - - If a server does not support storing attributes with language tag - options in the DIT, then any attribute descriptions in the list which - include language tag options are to be ignored, just as if they were - unknown attribute types. - - If a request is made specifying all attributes or an attribute is - requested without providing a language tag option, then all attribute - values regardless of their language tag option are returned. - - For example, if the client requests a "description" attribute, and a - matching entry contains the following attributes: - - - - -Zeilenga Language Tags and Ranges in LDAP [Page 6] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - objectclass: top - objectclass: organization - O: Software GmbH - description: software products - description;lang-en: software products - description;lang-de: Softwareprodukte - - The server would return: - - description: software products - description;lang-en: software products - description;lang-de: Softwareprodukte - - -2.4. Compare - - Language tag options can be present in an AttributeDescription used in - a compare request AttributeValueAssertion. This is to be treated by - servers the same as the use of language tag options in a search filter - with an equality match, as described in Section 2.2. If there is no - attribute in the entry with the same attribute type or its subtype and - and contains each of the presented (or possibly other) language tag - options, the noSuchAttributeType error will be returned. - - Thus, for example, a compare request of type "name" and assertion - value "Johann", against an entry containing the following attributes: - - objectclass: top - objectclass: person - givenName;lang-de-DE: Johann - CN: Johann Sibelius - SN: Sibelius - - would cause the server to return compareTrue. - - However, if the client issued a compare request of type "name;lang-de" - and assertion value "Johann" against the above entry, the request - would fail with the noSuchAttributeType error. - - If the server does not support storing attributes with language tag - options in the DIT, then any comparison which includes a language tag - option will always fail to locate an attribute, and - noSuchAttributeType will be returned. - - - 2.5. Add Operation - - Clients can provide language options in AttributeDescription in - - - -Zeilenga Language Tags and Ranges in LDAP [Page 7] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - attributes of a new entry to be created. - - A client can provide multiple attributes with the same attribute type - and value, so long as each attribute has a different set of language - tag options. - - For example, the following is a valid request: - - dn: CN=John Smith,DC=example,DC=com - objectclass: residentialPerson - CN: John Smith - CN;lang-en: John Smith - SN: Smith - SN;lang-en: Smith - streetAddress: 1 University Street - streetAddress;lang-en-US: 1 University Street - streetAddress;lang-fr: 1 rue Universite - houseIdentifier;lang-fr: 9e etage - - If a server does not support storing language tag options with - attribute values in the DIT, then it MUST treat an - AttributeDescription with a language tag option as an unrecognized - attribute. If the server forbids the addition of unrecognized - attributes then it MUST fail the add request with an appropriate - result code. - - -2.6. Modify Operation - - A client can provide language tag options in an AttributeDescription - as part of a modification element in the modify operation. - - Attribute types and language tag options MUST match exactly against - values stored in the directory. For example, if the modification is a - "delete", then if the stored values to be deleted have language tag - options, then those language tag options MUST be provided in the - modify operation, and if the stored values to be deleted do not have - any language tag option, then no language tag option is to be - provided. - - If the server does not support storing language tag options with - attribute values in the DIT, then it MUST treat an - AttributeDescription with a language tag option as an unrecognized - attribute, and MUST fail the request with an appropriate result code. - - -3. Use of Language Ranges in LDAP - - - - -Zeilenga Language Tags and Ranges in LDAP [Page 8] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - Since the publication of RFC 2596, it has become apparent that there - is a need to provide a mechanism for a client to request attributes - based upon set of language tag options whose tags all begin with the - same sequence of language sub-tags. - - AttributeDescriptions containing language range options are intended - to be used in attribute value assertions, search attribute lists, and - other places where the client desires to provide an attribute - description matching of a range of language tags associated with - attributes. - - A language range option conforms to the following ABNF [RFC2234]: - - language-range-option = "lang-" [ Language-Tag "-" ] - - where the Language-Tag production is as defined in BCP 47 [RFC3066]. - This production and those it imports from [RFC2234] are provided in - Section 2.1 for convenience. - - A language range option matches a language tag option if the language - range option less the trailing "-" matches exactly the language tag or - if the language range option (including the trailing "-") matches a - prefix of the language tag option. Note that the language range - option "lang-" matches all language tag options. - - Examples of valid AttributeDescription containing language range - options: - - givenName;lang-en- - CN;lang- - SN;lang-de-;lang-gem- - O;lang-x-;x-foobar - - A language range option is not a tagging option. Attributes cannot be - stored with language range options. Any attempt to add or update an - attribute description with a language range option SHALL be treated as - an undefined attribute type and result in an error. - - A language range option has no effect on the transfer encoding nor on - the syntax of the attribute values. - - Servers SHOULD support assertion of language ranges for any attribute - type which they allow to be stored with language tags. - - -3.1. Search Filter - - If a language range option is present in an AttributeDescription in an - - - -Zeilenga Language Tags and Ranges in LDAP [Page 9] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - assertion, then for each entry within scope, the values of each - attribute whose AttributeDescription consists of the same attribute - type or its subtypes and contains a language tag option matching the - language range option are to be returned. - - Thus, for example, a filter of an equality match of type - "name;lang-en-" and assertion value "Billy Ray", against the following - directory entry: - - dn: SN=Ray,DC=example,DC=com - objectclass: person DOES NOT MATCH (wrong type) - objectclass: extensibleObject DOES NOT MATCH (wrong type) - name;lang-en-US: Billy Ray MATCHES - name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) - CN;lang-en-US: Billy Ray MATCHES - CN;lang-en-US;x-foobar: Billy Ray MATCHES - CN;lang-en;x-foobar: Billy Ray MATCHES - CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-) - name: Billy Ray DOES NOT MATCH (no lang-) - SN;lang-en-GB;lang-en-US: Billy Ray MATCHES - SN: Ray DOES NOT MATCH (no lang-, - wrong value) - - Note that "CN" and "SN" are subtypes of "name". - - If the server does not support storing attributes with language tag - options in the DIT, then any assertion which includes a language range - option will not match as it is an unrecognized attribute type. No - error would be returned because of this; a presence filter would - evaluate to FALSE and all other assertions to Undefined. - - -3.2. Requested Attributes in Search - - Clients can provide language range options in each - AttributeDescription in the requested attribute list in a search - request. - - If a language range option is provided in an attribute description, - then only attributes in a directory entry whose attribute descriptions - have the same attribute type or its subtype and a language tag option - matching the provided language range option are to be returned. Thus - if a client requests just the attribute "name;lang-en-", the server - would return "name;lang-en-US" and "CN;lang-en;lang-ja" but not "SN" - nor "name;lang-fr". - - Clients can provide in the attribute list multiple - AttributeDescriptions which have the same base attribute type but - - - -Zeilenga Language Tags and Ranges in LDAP [Page 10] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - different options. For example a client could provide both - "name;lang-en-" and "name;lang-fr-", and this would permit an - attribute whose type was name or subtype of name and with a language - tag option matching either language range option to be returned. - - If a server does not support storing attributes with language tag - options in the DIT, then any attribute descriptions in the list which - include language range options are to be ignored, just as if they were - unknown attribute types. - - -3.3. Compare - - Language range options can be present in an AttributeDescription used - in a compare request AttributeValueAssertion. This is to be treated - by servers the same as the use of language range options in a search - filter with an equality match, as described in Section 3.1. If there - is no attribute in the entry with the same subtype and a matching - language tag option, the noSuchAttributeType error will be returned. - - Thus, for example, a compare request of type "name;lang-" and - assertion value "Johann", against the entry with the following - attributes: - - objectclass: top - objectclass: person - givenName;lang-de-DE: Johann - CN: Johann Sibelius - SN: Sibelius - - will cause the server to return compareTrue. (Note that the language - range option "lang-" matches any language tag option.) - - However, if the client issued a compare request of type "name;lang-de" - and assertion value "Sibelius" against the above entry, the request - would fail with the noSuchAttributeType error. - - If the server does not support storing attributes with language tag - options in the DIT, then any comparison which includes a language - range option will always fail to locate an attribute, and - noSuchAttributeType will be returned. - - -4. Discovering Language Option Support - - A server SHOULD indicate that it supports storing attributes with - language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4 - as a value of the "supportedFeatures" [FEATURES] attribute in the root - - - -Zeilenga Language Tags and Ranges in LDAP [Page 11] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - DSE. - - A server SHOULD indicate that it supports language range matching of - attributes with language tag options stored in the DIT by publishing - 1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures" - [FEATURES] attribute in the root DSE. - - A server MAY restrict use of language tag options to a subset of the - attribute types it recognizes. This document does not define a - mechanism for determining which subset of attribute types can be used - with language tag options. - - -5. Security Considerations - - Language tags and range options are used solely to indicate the native - language of values and in querying the directory for values which - fulfill the user's language needed. These options are not known to - raise specific security considerations. However, the reader should - consider general directory security issues detailed in the LDAP - technical specification [RFC3377]. - - -6. IANA Considerations - - The OIDs 1.3.6.1.4.1.4203.1.5.4 and 1.3.6.1.4.1.4203.1.5.5 identify - the features described above. These OIDs were assigned [ASSIGN] by - OpenLDAP Foundation, under its IANA-assigned private enterprise - allocation [PRIVATE], for use in this specification. - - Registration of these protocol mechanisms [RFC3383] is requested. - - Subject: Request for LDAP Protocol Mechanism Registration - - Object Identifier: 1.3.6.1.4.1.4203.1.5.4 - Description: Language Tag Options - - Object Identifier: 1.3.6.1.4.1.4203.1.5.5 - Description: Language Range Options - - Person & email address to contact for further information: - Kurt Zeilenga - - Usage: Feature - - Specification: RFCxxxx - - Author/Change Controller: IESG - - - -Zeilenga Language Tags and Ranges in LDAP [Page 12] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - Comments: none - - -7. Acknowledgments - - This document is a revision of RFC 2596 by Mark Wahl and Tim Howes. - RFC 2596 was a product of the IETF ASID and LDAPEXT working groups. - This document also borrows from a number of IETF documents including - BCP 47 by H. Alvestrand. - - -8. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14 (also RFC 2119), March 1997. - - [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", - BCP 47 (also RFC 3066), January 2001. - - [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, - September 2002. - - [FEATURES] K. Zeilenga, "Feature Discovery in LDAP", - draft-zeilenga-ldap-features-xx.txt (a work in progress). - - -9. Informative References - - [X.501] ITU, "The Directory: Models", ITU-T Recommendation X.501, - 1997. - - [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also - RFC 3383), September 2002. - - [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", - http://www.openldap.org/foundation/oid-delegate.txt. - - [PRIVATE] IANA, "Private Enterprise Numbers", - http://www.iana.org/assignments/enterprise-numbers. - - - - - -Zeilenga Language Tags and Ranges in LDAP [Page 13] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - -Appendix A. Differences from RFC 2596 - - This document adds support for language ranges, provides a mechanism - that a client can use to discover whether a server supports language - tags and ranges, and clarifies how attributes with multiple language - tags are to be treated. This document is a significant rewrite of RFC - 2596. - - -Appendix B. Differences from X.500(1997) - - X.500(1997) [X.501] defines a different mechanism, contexts, as the - means of representing language tags (codes). This section summarizes - the major differences in approach. - - a) An X.500 operation which has specified a language code on a value - matches a value in the directory without a language code. - b) LDAP references BCP 47 [RFC3066], which allows for IANA - registration of new tags as well as unregistered tags. - c) LDAP supports language ranges (new in this revision). - d) LDAP does not allow language tags (and ranges) in distinguished - names. - e) X.500 describes subschema administration procedures to allow - language codes to be associated with particular attributes types. - - -Copyright 2002, The Internet Society. 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 AUTHORS, 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 - - - -Zeilenga Language Tags and Ranges in LDAP [Page 14] - -INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002 - - - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Language Tags and Ranges in LDAP [Page 15] -