+++ /dev/null
-
- 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
- <draft-byrne-ldap-alias-00.txt>
-
- 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=<dn>, <rdn>, <rdn>..." 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
-
-
+++ /dev/null
-
-
-
-
-
-
-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 <ldapext@ietf.org>. Please send editorial
- comments directly to the document editor <Kurt@OpenLDAP.org>.
-
- 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
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 <kurt@openldap.org>
-
- Usage: Feature
-
- Specification: RFCxxxx
-
- Author/Change Controller: IESG
-
-
-
-Zeilenga Language Tags and Ranges in LDAP [Page 12]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / openldap / commitdiff