mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
1964 lines
64 KiB
Plaintext
1964 lines
64 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group A. Sciberras, Ed.
|
||
Request for Comments: 4519 eB2Bcom
|
||
Obsoletes: 2256 June 2006
|
||
Updates: 2247, 2798, 2377
|
||
Category: Standards Track
|
||
|
||
|
||
Lightweight Directory Access Protocol (LDAP):
|
||
Schema for User Applications
|
||
|
||
Status of This Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
Abstract
|
||
|
||
This document is an integral part of the Lightweight Directory Access
|
||
Protocol (LDAP) technical specification. It provides a technical
|
||
specification of attribute types and object classes intended for use
|
||
by LDAP directory clients for many directory services, such as White
|
||
Pages. These objects are widely used as a basis for the schema in
|
||
many LDAP directories. This document does not cover attributes used
|
||
for the administration of directory servers, nor does it include
|
||
directory objects defined for specific uses in other documents.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 1]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction ....................................................3
|
||
1.1. Relationship with Other Specifications .....................3
|
||
1.2. Conventions ................................................4
|
||
1.3. General Issues .............................................4
|
||
2. Attribute Types .................................................4
|
||
2.1. 'businessCategory' .........................................5
|
||
2.2. 'c' ........................................................5
|
||
2.3. 'cn' .......................................................5
|
||
2.4. 'dc' .......................................................6
|
||
2.5. 'description' ..............................................6
|
||
2.6. 'destinationIndicator' .....................................7
|
||
2.7. 'distinguishedName' ........................................7
|
||
2.8. 'dnQualifier' ..............................................8
|
||
2.9. 'enhancedSearchGuide' ......................................8
|
||
2.10. 'facsimileTelephoneNumber' ................................9
|
||
2.11. 'generationQualifier' .....................................9
|
||
2.12. 'givenName' ...............................................9
|
||
2.13. 'houseIdentifier' .........................................9
|
||
2.14. 'initials' ...............................................10
|
||
2.15. 'internationalISDNNumber' ................................10
|
||
2.16. 'l' ......................................................10
|
||
2.17. 'member' .................................................11
|
||
2.18. 'name' ...................................................11
|
||
2.19. 'o' ......................................................11
|
||
2.20. 'ou' .....................................................12
|
||
2.21. 'owner' ..................................................12
|
||
2.22. 'physicalDeliveryOfficeName' .............................12
|
||
2.23. 'postalAddress' ..........................................13
|
||
2.24. 'postalCode' .............................................13
|
||
2.25. 'postOfficeBox' ..........................................14
|
||
2.26. 'preferredDeliveryMethod' ................................14
|
||
2.27. 'registeredAddress' ......................................14
|
||
2.28. 'roleOccupant' ...........................................15
|
||
2.29. 'searchGuide' ............................................15
|
||
2.30. 'seeAlso' ................................................15
|
||
2.31. 'serialNumber' ...........................................16
|
||
2.32. 'sn' .....................................................16
|
||
2.33. 'st' .....................................................16
|
||
2.34. 'street' .................................................17
|
||
2.35. 'telephoneNumber' ........................................17
|
||
2.36. 'teletexTerminalIdentifier' ..............................17
|
||
2.37. 'telexNumber' ............................................18
|
||
2.38. 'title' ..................................................18
|
||
2.39. 'uid' ....................................................18
|
||
2.40. 'uniqueMember' ...........................................19
|
||
2.41. 'userPassword' ...........................................19
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 2]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
2.42. 'x121Address' ............................................20
|
||
2.43. 'x500UniqueIdentifier' ...................................20
|
||
3. Object Classes .................................................20
|
||
3.1. 'applicationProcess' ......................................21
|
||
3.2. 'country' .................................................21
|
||
3.3. 'dcObject' ................................................21
|
||
3.4. 'device' ..................................................21
|
||
3.5. 'groupOfNames' ............................................22
|
||
3.6. 'groupOfUniqueNames' ......................................22
|
||
3.7. 'locality' ................................................23
|
||
3.8. 'organization' ............................................23
|
||
3.9. 'organizationalPerson' ....................................24
|
||
3.10. 'organizationalRole' .....................................24
|
||
3.11. 'organizationalUnit' .....................................24
|
||
3.12. 'person' .................................................25
|
||
3.13. 'residentialPerson' ......................................25
|
||
3.14. 'uidObject' ..............................................26
|
||
4. IANA Considerations ............................................26
|
||
5. Security Considerations ........................................28
|
||
6. Acknowledgements ...............................................28
|
||
7. References .....................................................29
|
||
7.1. Normative References ......................................29
|
||
7.2. Informative References ....................................30
|
||
Appendix A Changes Made Since RFC 2256 ...........................32
|
||
|
||
1. Introduction
|
||
|
||
This document provides an overview of attribute types and object
|
||
classes intended for use by Lightweight Directory Access Protocol
|
||
(LDAP) directory clients for many directory services, such as White
|
||
Pages. Originally specified in the X.500 [X.500] documents, these
|
||
objects are widely used as a basis for the schema in many LDAP
|
||
directories. This document does not cover attributes used for the
|
||
administration of directory servers, nor does it include directory
|
||
objects defined for specific uses in other documents.
|
||
|
||
1.1. Relationship with Other Specifications
|
||
|
||
This document is an integral part of the LDAP technical specification
|
||
[RFC4510], which obsoletes the previously defined LDAP technical
|
||
specification, RFC 3377, in its entirety. In terms of RFC 2256,
|
||
Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections
|
||
5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The
|
||
remainder of RFC 2256 is obsoleted by this document. The technical
|
||
specification for the 'dc' attribute type and 'dcObject' object class
|
||
found in RFC 2247 are superseded by sections 2.4 and 3.3 of this
|
||
document. The remainder of RFC 2247 remains in force.
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 3]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
This document updates RFC 2798 by replacing the informative
|
||
description of the 'uid' attribute type with the definitive
|
||
description provided in Section 2.39 of this document.
|
||
|
||
This document updates RFC 2377 by replacing the informative
|
||
description of the 'uidObject' object class with the definitive
|
||
description provided in Section 3.14 of this document.
|
||
|
||
A number of schema elements that were included in the previous
|
||
revision of the LDAP Technical Specification are not included in this
|
||
revision of LDAP. PKI-related schema elements are now specified in
|
||
[RFC4523]. Unless reintroduced in future technical specifications,
|
||
the remainder are to be considered Historic.
|
||
|
||
The descriptions in this document SHALL be considered definitive for
|
||
use in LDAP.
|
||
|
||
1.2. 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 RFC 2119 [RFC2119].
|
||
|
||
1.3. General Issues
|
||
|
||
This document references Syntaxes defined in Section 3 of [RFC4517]
|
||
and Matching Rules defined in Section 4 of [RFC4517].
|
||
|
||
The definitions of Attribute Types and Object Classes are written
|
||
using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
|
||
AttributeTypeDescription and ObjectClassDescription given in
|
||
[RFC4512]. Lines have been folded for readability. When such values
|
||
are transferred as attribute values in the LDAP Protocol, the values
|
||
will not contain line breaks.
|
||
|
||
2. Attribute Types
|
||
|
||
The attribute types contained in this section hold user information.
|
||
|
||
There is no requirement that servers implement the 'searchGuide' and
|
||
'teletexTerminalIdentifier' attribute types. In fact, their use is
|
||
greatly discouraged.
|
||
|
||
An LDAP server implementation SHOULD recognize the rest of the
|
||
attribute types described in this section.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 4]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
2.1. 'businessCategory'
|
||
|
||
The 'businessCategory' attribute type describes the kinds of business
|
||
performed by an organization. Each kind is one value of this
|
||
multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.15 NAME 'businessCategory'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "banking", "transportation", and "real estate".
|
||
|
||
2.2. 'c'
|
||
|
||
The 'c' ('countryName' in X.500) attribute type contains a two-letter
|
||
ISO 3166 [ISO3166] country code.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.6 NAME 'c'
|
||
SUP name
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
|
||
SINGLE-VALUE )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "DE", "AU" and "FR".
|
||
|
||
2.3. 'cn'
|
||
|
||
The 'cn' ('commonName' in X.500) attribute type contains names of an
|
||
object. Each name is one value of this multi-valued attribute. If
|
||
the object corresponds to a person, it is typically the person's full
|
||
name.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.3 NAME 'cn'
|
||
SUP name )
|
||
|
||
Examples: "Martin K Smith", "Marty Smith" and "printer12".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 5]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
2.4. 'dc'
|
||
|
||
The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
|
||
holding one component, a label, of a DNS domain name
|
||
[RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this
|
||
attribute is a string of ASCII characters adhering to the following
|
||
ABNF [RFC4234]:
|
||
|
||
label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
|
||
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
|
||
DIGIT = %x30-39 ; "0"-"9"
|
||
HYPHEN = %x2D ; hyphen ("-")
|
||
|
||
The encoding of IA5String for use in LDAP is simply the characters of
|
||
the ASCII label. The equality matching rule is case insensitive, as
|
||
is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
|
||
|
||
( 0.9.2342.19200300.100.1.25 NAME 'dc'
|
||
EQUALITY caseIgnoreIA5Match
|
||
SUBSTR caseIgnoreIA5SubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
|
||
SINGLE-VALUE )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
|
||
[RFC4517].
|
||
|
||
Examples: Valid values include "example" and "com" but not
|
||
"example.com". The latter is invalid as it contains multiple domain
|
||
components.
|
||
|
||
It is noted that the directory service will not ensure that values of
|
||
this attribute conform to the host label restrictions [RFC1123]
|
||
illustrated by the <label> production provided above. It is the
|
||
directory client's responsibility to ensure that the labels it stores
|
||
in this attribute are appropriately restricted.
|
||
|
||
Directory applications supporting International Domain Names SHALL
|
||
use the ToASCII method [RFC3490] to produce the domain component
|
||
label. The special considerations discussed in Section 4 of RFC 3490
|
||
[RFC3490] should be taken, depending on whether the domain component
|
||
is used for "stored" or "query" purposes.
|
||
|
||
2.5. 'description'
|
||
|
||
The 'description' attribute type contains human-readable descriptive
|
||
phrases about the object. Each description is one value of this
|
||
multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 6]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
( 2.5.4.13 NAME 'description'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "a color printer", "Maintenance is done every Monday, at
|
||
1pm.", and "distribution list for all technical staff".
|
||
|
||
2.6. 'destinationIndicator'
|
||
|
||
The 'destinationIndicator' attribute type contains country and city
|
||
strings associated with the object (the addressee) needed to provide
|
||
the Public Telegram Service. The strings are composed in accordance
|
||
with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is
|
||
one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.27 NAME 'destinationIndicator'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "AASD" as a destination indicator for Sydney, Australia.
|
||
"GBLD" as a destination indicator for London, United
|
||
Kingdom.
|
||
|
||
It is noted that the directory will not ensure that values of this
|
||
attribute conform to the F.1 and F.31 CCITT Recommendations. It is
|
||
the application's responsibility to ensure destination indicators
|
||
that it stores in this attribute are appropriately constructed.
|
||
|
||
2.7. 'distinguishedName'
|
||
|
||
The 'distinguishedName' attribute type is not used as the name of the
|
||
object itself, but it is instead a base type from which some user
|
||
attribute types with a DN syntax can inherit.
|
||
|
||
It is unlikely that values of this type itself will occur in an
|
||
entry. LDAP server implementations that do not support attribute
|
||
subtyping need not recognize this attribute in requests. Client
|
||
implementations MUST NOT assume that LDAP servers are capable of
|
||
performing attribute subtyping.
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 7]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.49 NAME 'distinguishedName'
|
||
EQUALITY distinguishedNameMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517].
|
||
|
||
2.8. 'dnQualifier'
|
||
|
||
The 'dnQualifier' attribute type contains disambiguating information
|
||
strings to add to the relative distinguished name of an entry. The
|
||
information is intended for use when merging data from multiple
|
||
sources in order to prevent conflicts between entries that would
|
||
otherwise have the same name. Each string is one value of this
|
||
multi-valued attribute. It is recommended that a value of the
|
||
'dnQualifier' attribute be the same for all entries from a particular
|
||
source.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.46 NAME 'dnQualifier'
|
||
EQUALITY caseIgnoreMatch
|
||
ORDERING caseIgnoreOrderingMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "20050322123345Z" - timestamps can be used to disambiguate
|
||
information.
|
||
"123456A" - serial numbers can be used to disambiguate
|
||
information.
|
||
|
||
2.9. 'enhancedSearchGuide'
|
||
|
||
The 'enhancedSearchGuide' attribute type contains sets of information
|
||
for use by directory clients in constructing search filters. Each
|
||
set is one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.47 NAME 'enhancedSearchGuide'
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
|
||
[RFC4517].
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 8]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
Examples: "person#(sn$APPROX)#wholeSubtree" and
|
||
"organizationalUnit#(ou$SUBSTR)#oneLevel".
|
||
|
||
2.10. 'facsimileTelephoneNumber'
|
||
|
||
The 'facsimileTelephoneNumber' attribute type contains telephone
|
||
numbers (and, optionally, the parameters) for facsimile terminals.
|
||
Each telephone number is one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.23 NAME 'facsimileTelephoneNumber'
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
|
||
Number syntax [RFC4517].
|
||
|
||
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
|
||
|
||
2.11. 'generationQualifier'
|
||
|
||
The 'generationQualifier' attribute type contains name strings that
|
||
are typically the suffix part of a person's name. Each string is one
|
||
value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.44 NAME 'generationQualifier'
|
||
SUP name )
|
||
|
||
Examples: "III", "3rd", and "Jr.".
|
||
|
||
2.12. 'givenName'
|
||
|
||
The 'givenName' attribute type contains name strings that are the
|
||
part of a person's name that is not their surname. Each string is
|
||
one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.42 NAME 'givenName'
|
||
SUP name )
|
||
|
||
Examples: "Andrew", "Charles", and "Joanne".
|
||
|
||
2.13. 'houseIdentifier'
|
||
|
||
The 'houseIdentifier' attribute type contains identifiers for a
|
||
building within a location. Each identifier is one value of this
|
||
multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 9]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
( 2.5.4.51 NAME 'houseIdentifier'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Example: "20" to represent the house number 20.
|
||
|
||
2.14. 'initials'
|
||
|
||
The 'initials' attribute type contains strings of initials of some or
|
||
all of an individual's names, except the surname(s). Each string is
|
||
one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.43 NAME 'initials'
|
||
SUP name )
|
||
|
||
Examples: "K. A." and "K".
|
||
|
||
2.15. 'internationalISDNNumber'
|
||
|
||
The 'internationalISDNNumber' attribute type contains Integrated
|
||
Services Digital Network (ISDN) addresses, as defined in the
|
||
International Telecommunication Union (ITU) Recommendation E.164
|
||
[E.164]. Each address is one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.25 NAME 'internationalISDNNumber'
|
||
EQUALITY numericStringMatch
|
||
SUBSTR numericStringSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
|
||
[RFC4517].
|
||
|
||
Example: "0198 333 333".
|
||
|
||
2.16. 'l'
|
||
|
||
The 'l' ('localityName' in X.500) attribute type contains names of a
|
||
locality or place, such as a city, county, or other geographic
|
||
region. Each name is one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 10]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
( 2.5.4.7 NAME 'l'
|
||
SUP name )
|
||
|
||
Examples: "Geneva", "Paris", and "Edinburgh".
|
||
|
||
2.17. 'member'
|
||
|
||
The 'member' attribute type contains the distinguished names of
|
||
objects that are on a list or in a group. Each name is one value of
|
||
this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.31 NAME 'member'
|
||
SUP distinguishedName )
|
||
|
||
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
|
||
"cn=John Xerri,ou=Finance,o=Widget\, Inc." may
|
||
be two members of the financial team (group) at Widget,
|
||
Inc., in which case, both of these distinguished names
|
||
would be present as individual values of the member
|
||
attribute.
|
||
|
||
2.18. 'name'
|
||
|
||
The 'name' attribute type is the attribute supertype from which user
|
||
attribute types with the name syntax inherit. Such attribute types
|
||
are typically used for naming. The attribute type is multi-valued.
|
||
|
||
It is unlikely that values of this type itself will occur in an
|
||
entry. LDAP server implementations that do not support attribute
|
||
subtyping need not recognize this attribute in requests. Client
|
||
implementations MUST NOT assume that LDAP servers are capable of
|
||
performing attribute subtyping.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.41 NAME 'name'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
2.19. 'o'
|
||
|
||
The 'o' ('organizationName' in X.500) attribute type contains the
|
||
names of an organization. Each name is one value of this
|
||
multi-valued attribute.
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 11]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.10 NAME 'o'
|
||
SUP name )
|
||
|
||
Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
|
||
|
||
2.20. 'ou'
|
||
|
||
The 'ou' ('organizationalUnitName' in X.500) attribute type contains
|
||
the names of an organizational unit. Each name is one value of this
|
||
multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.11 NAME 'ou'
|
||
SUP name )
|
||
|
||
Examples: "Finance", "Human Resources", and "Research and
|
||
Development".
|
||
|
||
2.21. 'owner'
|
||
|
||
The 'owner' attribute type contains the distinguished names of
|
||
objects that have an ownership responsibility for the object that is
|
||
owned. Each owner's name is one value of this multi-valued
|
||
attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.32 NAME 'owner'
|
||
SUP distinguishedName )
|
||
|
||
Example: The mailing list object, whose DN is "cn=All Employees,
|
||
ou=Mailing List,o=Widget\, Inc.", is owned by the Human
|
||
Resources Director.
|
||
|
||
Therefore, the value of the 'owner' attribute within the
|
||
mailing list object, would be the DN of the director (role):
|
||
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
|
||
|
||
2.22. 'physicalDeliveryOfficeName'
|
||
|
||
The 'physicalDeliveryOfficeName' attribute type contains names that a
|
||
Postal Service uses to identify a post office.
|
||
(Source: X.520 [X.520])
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 12]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
|
||
|
||
2.23. 'postalAddress'
|
||
|
||
The 'postalAddress' attribute type contains addresses used by a
|
||
Postal Service to perform services for the object. Each address is
|
||
one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.16 NAME 'postalAddress'
|
||
EQUALITY caseIgnoreListMatch
|
||
SUBSTR caseIgnoreListSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
|
||
[RFC4517].
|
||
|
||
Example: "15 Main St.$Ottawa$Canada".
|
||
|
||
2.24. 'postalCode'
|
||
|
||
The 'postalCode' attribute type contains codes used by a Postal
|
||
Service to identify postal service zones. Each code is one value of
|
||
this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.17 NAME 'postalCode'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Example: "22180", to identify Vienna, VA, in the USA.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 13]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
2.25. 'postOfficeBox'
|
||
|
||
The 'postOfficeBox' attribute type contains postal box identifiers
|
||
that a Postal Service uses when a customer arranges to receive mail
|
||
at a box on the premises of the Postal Service. Each postal box
|
||
identifier is a single value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.18 NAME 'postOfficeBox'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Example: "Box 45".
|
||
|
||
2.26. 'preferredDeliveryMethod'
|
||
|
||
The 'preferredDeliveryMethod' attribute type contains an indication
|
||
of the preferred method of getting a message to the object.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.28 NAME 'preferredDeliveryMethod'
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
|
||
SINGLE-VALUE )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
|
||
[RFC4517].
|
||
|
||
Example: If the mhs-delivery Delivery Method is preferred over
|
||
telephone-delivery, which is preferred over all other
|
||
methods, the value would be: "mhs $ telephone".
|
||
|
||
2.27. 'registeredAddress'
|
||
|
||
The 'registeredAddress' attribute type contains postal addresses
|
||
suitable for reception of telegrams or expedited documents, where it
|
||
is necessary to have the recipient accept delivery. Each address is
|
||
one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.26 NAME 'registeredAddress'
|
||
SUP postalAddress
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 14]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
|
||
[RFC4517].
|
||
|
||
Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
|
||
|
||
2.28. 'roleOccupant'
|
||
|
||
The 'roleOccupant' attribute type contains the distinguished names of
|
||
objects (normally people) that fulfill the responsibilities of a role
|
||
object. Each distinguished name is one value of this multi-valued
|
||
attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.33 NAME 'roleOccupant'
|
||
SUP distinguishedName )
|
||
|
||
Example: The role object, "cn=Human Resources
|
||
Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
|
||
people whose object names are "cn=Mary
|
||
Smith,ou=employee,o=Widget\, Inc." and "cn=James
|
||
Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
|
||
attribute will contain both of these distinguished names,
|
||
since they are the occupants of this role.
|
||
|
||
2.29. 'searchGuide'
|
||
|
||
The 'searchGuide' attribute type contains sets of information for use
|
||
by clients in constructing search filters. It is superseded by
|
||
'enhancedSearchGuide', described above in Section 2.9. Each set is
|
||
one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.14 NAME 'searchGuide'
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517].
|
||
|
||
Example: "person#sn$EQ".
|
||
|
||
2.30. 'seeAlso'
|
||
|
||
The 'seeAlso' attribute type contains the distinguished names of
|
||
objects that are related to the subject object. Each related object
|
||
name is one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.34 NAME 'seeAlso'
|
||
SUP distinguishedName )
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 15]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
Example: The person object "cn=James Brown,ou=employee,o=Widget\,
|
||
Inc." is related to the role objects "cn=Football Team
|
||
Captain,ou=sponsored activities,o=Widget\, Inc." and
|
||
"cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
|
||
Since the role objects are related to the person object, the
|
||
'seeAlso' attribute will contain the distinguished name of
|
||
each role object as separate values.
|
||
|
||
2.31. 'serialNumber'
|
||
|
||
The 'serialNumber' attribute type contains the serial numbers of
|
||
devices. Each serial number is one value of this multi-valued
|
||
attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.5 NAME 'serialNumber'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "WI-3005" and "XF551426".
|
||
|
||
2.32. 'sn'
|
||
|
||
The 'sn' ('surname' in X.500) attribute type contains name strings
|
||
for the family names of a person. Each string is one value of this
|
||
multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.4 NAME 'sn'
|
||
SUP name )
|
||
|
||
Example: "Smith".
|
||
|
||
2.33. 'st'
|
||
|
||
The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
|
||
full names of states or provinces. Each name is one value of this
|
||
multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.8 NAME 'st'
|
||
SUP name )
|
||
|
||
Example: "California".
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 16]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
2.34. 'street'
|
||
|
||
The 'street' ('streetAddress' in X.500) attribute type contains site
|
||
information from a postal address (i.e., the street name, place,
|
||
avenue, and the house number). Each street is one value of this
|
||
multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.9 NAME 'street'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Example: "15 Main St.".
|
||
|
||
2.35. 'telephoneNumber'
|
||
|
||
The 'telephoneNumber' attribute type contains telephone numbers that
|
||
comply with the ITU Recommendation E.123 [E.123]. Each number is one
|
||
value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.20 NAME 'telephoneNumber'
|
||
EQUALITY telephoneNumberMatch
|
||
SUBSTR telephoneNumberSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
|
||
[RFC4517].
|
||
|
||
Example: "+1 234 567 8901".
|
||
|
||
2.36. 'teletexTerminalIdentifier'
|
||
|
||
The withdrawal of Recommendation F.200 has resulted in the withdrawal
|
||
of this attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.22 NAME 'teletexTerminalIdentifier'
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
|
||
Identifier syntax [RFC4517].
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 17]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
2.37. 'telexNumber'
|
||
|
||
The 'telexNumber' attribute type contains sets of strings that are a
|
||
telex number, country code, and answerback code of a telex terminal.
|
||
Each set is one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.21 NAME 'telexNumber'
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
|
||
[RFC4517].
|
||
|
||
Example: "12345$023$ABCDE".
|
||
|
||
2.38. 'title'
|
||
|
||
The 'title' attribute type contains the title of a person in their
|
||
organizational context. Each title is one value of this multi-valued
|
||
attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.12 NAME 'title'
|
||
SUP name )
|
||
Examples: "Vice President", "Software Engineer", and "CEO".
|
||
|
||
2.39. 'uid'
|
||
|
||
The 'uid' ('userid' in RFC 1274) attribute type contains computer
|
||
system login names associated with the object. Each name is one
|
||
value of this multi-valued attribute.
|
||
(Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
|
||
|
||
( 0.9.2342.19200300.100.1.1 NAME 'uid'
|
||
EQUALITY caseIgnoreMatch
|
||
SUBSTR caseIgnoreSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
|
||
[RFC4517].
|
||
|
||
Examples: "s9709015", "admin", and "Administrator".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 18]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
2.40. 'uniqueMember'
|
||
|
||
The 'uniqueMember' attribute type contains the distinguished names of
|
||
an object that is on a list or in a group, where the relative
|
||
distinguished names of the object include a value that distinguishes
|
||
between objects when a distinguished name has been reused. Each
|
||
distinguished name is one value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.50 NAME 'uniqueMember'
|
||
EQUALITY uniqueMemberMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
|
||
syntax [RFC4517].
|
||
|
||
Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
|
||
disbanded, establishing a new battalion with the "same" name
|
||
would have a unique identifier value added, resulting in
|
||
"ou=1st Battalion, o=Defense,c=US#'010101'B".
|
||
|
||
2.41. 'userPassword'
|
||
|
||
The 'userPassword' attribute contains octet strings that are known
|
||
only to the user and the system to which the user has access. Each
|
||
string is one value of this multi-valued attribute.
|
||
|
||
The application SHOULD prepare textual strings used as passwords by
|
||
transcoding them to Unicode, applying SASLprep [RFC4013], and
|
||
encoding as UTF-8. The determination of whether a password is
|
||
textual is a local client matter.
|
||
(Source: X.509 [X.509])
|
||
|
||
( 2.5.4.35 NAME 'userPassword'
|
||
EQUALITY octetStringMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
|
||
[RFC4517].
|
||
|
||
Passwords are stored using an Octet String syntax and are not
|
||
encrypted. Transfer of cleartext passwords is strongly discouraged
|
||
where the underlying transport service cannot guarantee
|
||
confidentiality and may result in disclosure of the password to
|
||
unauthorized parties.
|
||
|
||
An example of a need for multiple values in the 'userPassword'
|
||
attribute is an environment where every month the user is expected to
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 19]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
use a different password generated by some automated system. During
|
||
transitional periods, like the last and first day of the periods, it
|
||
may be necessary to allow two passwords for the two consecutive
|
||
periods to be valid in the system.
|
||
|
||
2.42. 'x121Address'
|
||
|
||
The 'x121Address' attribute type contains data network addresses as
|
||
defined by ITU Recommendation X.121 [X.121]. Each address is one
|
||
value of this multi-valued attribute.
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.24 NAME 'x121Address'
|
||
EQUALITY numericStringMatch
|
||
SUBSTR numericStringSubstringsMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
|
||
[RFC4517].
|
||
|
||
Example: "36111222333444555".
|
||
|
||
2.43. 'x500UniqueIdentifier'
|
||
|
||
The 'x500UniqueIdentifier' attribute type contains binary strings
|
||
that are used to distinguish between objects when a distinguished
|
||
name has been reused. Each string is one value of this multi-valued
|
||
attribute.
|
||
|
||
In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
|
||
This is a different attribute type from both the 'uid' and
|
||
'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
|
||
attribute type is defined in [RFC4524].
|
||
(Source: X.520 [X.520])
|
||
|
||
( 2.5.4.45 NAME 'x500UniqueIdentifier'
|
||
EQUALITY bitStringMatch
|
||
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
|
||
|
||
1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
|
||
[RFC4517].
|
||
|
||
3. Object Classes
|
||
|
||
LDAP servers SHOULD recognize all the Object Classes listed here as
|
||
values of the 'objectClass' attribute (see [RFC4512]).
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 20]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
3.1. 'applicationProcess'
|
||
|
||
The 'applicationProcess' object class definition is the basis of an
|
||
entry that represents an application executing in a computer system.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.11 NAME 'applicationProcess'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST cn
|
||
MAY ( seeAlso $
|
||
ou $
|
||
l $
|
||
description ) )
|
||
|
||
3.2. 'country'
|
||
|
||
The 'country' object class definition is the basis of an entry that
|
||
represents a country.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.2 NAME 'country'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST c
|
||
MAY ( searchGuide $
|
||
description ) )
|
||
|
||
3.3. 'dcObject'
|
||
|
||
The 'dcObject' object class permits an entry to contains domain
|
||
component information. This object class is defined as auxiliary,
|
||
because it will be used in conjunction with an existing structural
|
||
object class.
|
||
(Source: RFC 2247 [RFC2247])
|
||
|
||
( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
|
||
SUP top
|
||
AUXILIARY
|
||
MUST dc )
|
||
|
||
3.4. 'device'
|
||
|
||
The 'device' object class is the basis of an entry that represents an
|
||
appliance, computer, or network element.
|
||
(Source: X.521 [X.521])
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 21]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
( 2.5.6.14 NAME 'device'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST cn
|
||
MAY ( serialNumber $
|
||
seeAlso $
|
||
owner $
|
||
ou $
|
||
o $
|
||
l $
|
||
description ) )
|
||
|
||
3.5. 'groupOfNames'
|
||
|
||
The 'groupOfNames' object class is the basis of an entry that
|
||
represents a set of named objects including information related to
|
||
the purpose or maintenance of the set.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.9 NAME 'groupOfNames'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST ( member $
|
||
cn )
|
||
MAY ( businessCategory $
|
||
seeAlso $
|
||
owner $
|
||
ou $
|
||
o $
|
||
description ) )
|
||
|
||
3.6. 'groupOfUniqueNames'
|
||
|
||
The 'groupOfUniqueNames' object class is the same as the
|
||
'groupOfNames' object class except that the object names are not
|
||
repeated or reassigned within a set scope.
|
||
(Source: X.521 [X.521])
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 22]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
( 2.5.6.17 NAME 'groupOfUniqueNames'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST ( uniqueMember $
|
||
cn )
|
||
MAY ( businessCategory $
|
||
seeAlso $
|
||
owner $
|
||
ou $
|
||
o $
|
||
description ) )
|
||
|
||
3.7. 'locality'
|
||
|
||
The 'locality' object class is the basis of an entry that represents
|
||
a place in the physical world.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.3 NAME 'locality'
|
||
SUP top
|
||
STRUCTURAL
|
||
MAY ( street $
|
||
seeAlso $
|
||
searchGuide $
|
||
st $
|
||
l $
|
||
description ) )
|
||
|
||
3.8. 'organization'
|
||
|
||
The 'organization' object class is the basis of an entry that
|
||
represents a structured group of people.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.4 NAME 'organization'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST o
|
||
MAY ( userPassword $ searchGuide $ seeAlso $
|
||
businessCategory $ x121Address $ registeredAddress $
|
||
destinationIndicator $ preferredDeliveryMethod $
|
||
telexNumber $ teletexTerminalIdentifier $
|
||
telephoneNumber $ internationalISDNNumber $
|
||
facsimileTelephoneNumber $ street $ postOfficeBox $
|
||
postalCode $ postalAddress $ physicalDeliveryOfficeName $
|
||
st $ l $ description ) )
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 23]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
3.9. 'organizationalPerson'
|
||
|
||
The 'organizationalPerson' object class is the basis of an entry that
|
||
represents a person in relation to an organization.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.7 NAME 'organizationalPerson'
|
||
SUP person
|
||
STRUCTURAL
|
||
MAY ( title $ x121Address $ registeredAddress $
|
||
destinationIndicator $ preferredDeliveryMethod $
|
||
telexNumber $ teletexTerminalIdentifier $
|
||
telephoneNumber $ internationalISDNNumber $
|
||
facsimileTelephoneNumber $ street $ postOfficeBox $
|
||
postalCode $ postalAddress $ physicalDeliveryOfficeName $
|
||
ou $ st $ l ) )
|
||
|
||
3.10. 'organizationalRole'
|
||
|
||
The 'organizationalRole' object class is the basis of an entry that
|
||
represents a job, function, or position in an organization.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.8 NAME 'organizationalRole'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST cn
|
||
MAY ( x121Address $ registeredAddress $ destinationIndicator $
|
||
preferredDeliveryMethod $ telexNumber $
|
||
teletexTerminalIdentifier $ telephoneNumber $
|
||
internationalISDNNumber $ facsimileTelephoneNumber $
|
||
seeAlso $ roleOccupant $ preferredDeliveryMethod $
|
||
street $ postOfficeBox $ postalCode $ postalAddress $
|
||
physicalDeliveryOfficeName $ ou $ st $ l $
|
||
description ) )
|
||
|
||
3.11. 'organizationalUnit'
|
||
|
||
The 'organizationalUnit' object class is the basis of an entry that
|
||
represents a piece of an organization.
|
||
(Source: X.521 [X.521])
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 24]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
( 2.5.6.5 NAME 'organizationalUnit'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST ou
|
||
MAY ( businessCategory $ description $ destinationIndicator $
|
||
facsimileTelephoneNumber $ internationalISDNNumber $ l $
|
||
physicalDeliveryOfficeName $ postalAddress $ postalCode $
|
||
postOfficeBox $ preferredDeliveryMethod $
|
||
registeredAddress $ searchGuide $ seeAlso $ st $ street $
|
||
telephoneNumber $ teletexTerminalIdentifier $
|
||
telexNumber $ userPassword $ x121Address ) )
|
||
|
||
3.12 'person'
|
||
|
||
The 'person' object class is the basis of an entry that represents a
|
||
human being.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.6 NAME 'person'
|
||
SUP top
|
||
STRUCTURAL
|
||
MUST ( sn $
|
||
cn )
|
||
MAY ( userPassword $
|
||
telephoneNumber $
|
||
seeAlso $ description ) )
|
||
|
||
3.13. 'residentialPerson'
|
||
|
||
The 'residentialPerson' object class is the basis of an entry that
|
||
includes a person's residence in the representation of the person.
|
||
(Source: X.521 [X.521])
|
||
|
||
( 2.5.6.10 NAME 'residentialPerson'
|
||
SUP person
|
||
STRUCTURAL
|
||
MUST l
|
||
MAY ( businessCategory $ x121Address $ registeredAddress $
|
||
destinationIndicator $ preferredDeliveryMethod $
|
||
telexNumber $ teletexTerminalIdentifier $
|
||
telephoneNumber $ internationalISDNNumber $
|
||
facsimileTelephoneNumber $ preferredDeliveryMethod $
|
||
street $ postOfficeBox $ postalCode $ postalAddress $
|
||
physicalDeliveryOfficeName $ st $ l ) )
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 25]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
3.14. 'uidObject'
|
||
|
||
The 'uidObject' object class permits an entry to contains user
|
||
identification information. This object class is defined as
|
||
auxiliary, because it will be used in conjunction with an existing
|
||
structural object class.
|
||
(Source: RFC 2377 [RFC2377])
|
||
|
||
( 1.3.6.1.1.3.1 NAME 'uidObject'
|
||
SUP top
|
||
AUXILIARY
|
||
MUST uid )
|
||
|
||
4. IANA Considerations
|
||
|
||
The Internet Assigned Numbers Authority (IANA) has updated the LDAP
|
||
descriptors registry as indicated in the following template:
|
||
|
||
Subject: Request for LDAP Descriptor Registration Update
|
||
Descriptor (short name): see comments
|
||
Object Identifier: see comments
|
||
Person & email address to contact for further information:
|
||
Andrew Sciberras <andrew.sciberras@eb2bcom.com>
|
||
Usage: (A = attribute type, O = Object Class) see comment
|
||
Specification: RFC 4519
|
||
Author/Change Controller: IESG
|
||
|
||
Comments
|
||
|
||
In the LDAP descriptors registry, the following descriptors (short
|
||
names) have been updated to refer to RFC 4519. Names that need to
|
||
be reserved, rather than assigned to an Object Identifier, will
|
||
contain an Object Identifier value of RESERVED.
|
||
|
||
NAME Type OID
|
||
------------------------ ---- ----------------------------
|
||
applicationProcess O 2.5.6.11
|
||
businessCategory A 2.5.4.15
|
||
c A 2.5.4.6
|
||
cn A 2.5.4.3
|
||
commonName A 2.5.4.3
|
||
country O 2.5.6.2
|
||
countryName A 2.5.4.6
|
||
dc A 0.9.2342.19200300.100.1.25
|
||
dcObject O 1.3.6.1.4.1.1466.344
|
||
description A 2.5.4.13
|
||
destinationIndicator A 2.5.4.27
|
||
device O 2.5.6.14
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 26]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
NAME Type OID
|
||
------------------------ ---- ----------------------------
|
||
distinguishedName A 2.5.4.49
|
||
dnQualifier A 2.5.4.46
|
||
domainComponent A 0.9.2342.19200300.100.1.25
|
||
enhancedSearchGuide A 2.5.4.47
|
||
facsimileTelephoneNumber A 2.5.4.23
|
||
generationQualifier A 2.5.4.44
|
||
givenName A 2.5.4.42
|
||
gn A RESERVED
|
||
groupOfNames O 2.5.6.9
|
||
groupOfUniqueNames O 2.5.6.17
|
||
houseIdentifier A 2.5.4.51
|
||
initials A 2.5.4.43
|
||
internationalISDNNumber A 2.5.4.25
|
||
l A 2.5.4.7
|
||
locality O 2.5.6.3
|
||
localityName A 2.5.4.7
|
||
member A 2.5.4.31
|
||
name A 2.5.4.41
|
||
o A 2.5.4.10
|
||
organization O 2.5.6.4
|
||
organizationName A 2.5.4.10
|
||
organizationalPerson O 2.5.6.7
|
||
organizationalRole O 2.5.6.8
|
||
organizationalUnit O 2.5.6.5
|
||
organizationalUnitName A 2.5.4.11
|
||
ou A 2.5.4.11
|
||
owner A 2.5.4.32
|
||
person O 2.5.6.6
|
||
physicalDeliveryOfficeName A 2.5.4.19
|
||
postalAddress A 2.5.4.16
|
||
postalCode A 2.5.4.17
|
||
postOfficeBox A 2.5.4.18
|
||
preferredDeliveryMethod A 2.5.4.28
|
||
registeredAddress A 2.5.4.26
|
||
residentialPerson O 2.5.6.10
|
||
roleOccupant A 2.5.4.33
|
||
searchGuide A 2.5.4.14
|
||
seeAlso A 2.5.4.34
|
||
serialNumber A 2.5.4.5
|
||
sn A 2.5.4.4
|
||
st A 2.5.4.8
|
||
street A 2.5.4.9
|
||
surname A 2.5.4.4
|
||
telephoneNumber A 2.5.4.20
|
||
teletexTerminalIdentifier A 2.5.4.22
|
||
telexNumber A 2.5.4.21
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 27]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
NAME Type OID
|
||
------------------------ ---- ----------------------------
|
||
title A 2.5.4.12
|
||
uid A 0.9.2342.19200300.100.1.1
|
||
uidObject O 1.3.6.1.1.3.1
|
||
uniqueMember A 2.5.4.50
|
||
userid A 0.9.2342.19200300.100.1.1
|
||
userPassword A 2.5.4.35
|
||
x121Address A 2.5.4.24
|
||
x500UniqueIdentifier A 2.5.4.45
|
||
|
||
5. Security Considerations
|
||
|
||
Attributes of directory entries are used to provide descriptive
|
||
information about the real-world objects they represent, which can be
|
||
people, organizations, or devices. Most countries have privacy laws
|
||
regarding the publication of information about people.
|
||
|
||
Transfer of cleartext passwords is strongly discouraged where the
|
||
underlying transport service cannot guarantee confidentiality and
|
||
integrity, since this may result in disclosure of the password to
|
||
unauthorized parties.
|
||
|
||
Multiple attribute values for the 'userPassword' attribute need to be
|
||
used with care. Especially reset/deletion of a password by an
|
||
administrator without knowing the old user password gets tricky or
|
||
impossible if multiple values for different applications are present.
|
||
|
||
Certainly, applications that intend to replace the 'userPassword'
|
||
value(s) with new value(s) should use modify/replaceValues (or
|
||
modify/deleteAttribute+addAttribute). In addition, server
|
||
implementations are encouraged to provide administrative controls
|
||
that, if enabled, restrict the 'userPassword' attribute to one value.
|
||
|
||
Note that when used for authentication purposes [RFC4513], the user
|
||
need only prove knowledge of one of the values, not all of the
|
||
values.
|
||
|
||
6. Acknowledgements
|
||
|
||
The definitions, on which this document is based, have been developed
|
||
by committees for telecommunications and international standards.
|
||
|
||
This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
|
||
product of the IETF ASID Working Group.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 28]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
The 'dc' attribute type definition and the 'dcObject' object class
|
||
definition in this document supersede the specification in RFC 2247
|
||
by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
|
||
|
||
The 'uid' attribute type definition in this document supersedes the
|
||
specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
|
||
and of the uid in RFC 2798 by M. Smith.
|
||
|
||
The 'uidObject' object class definition in this document supersedes
|
||
the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
|
||
Huber, S. Sataluri, and M. Wahl.
|
||
|
||
This document is based upon input of the IETF LDAPBIS working group.
|
||
The author wishes to thank S. Legg and K. Zeilenga for their
|
||
significant contribution to this update. The author would also like
|
||
to thank Kathy Dally, who edited early versions of this document.
|
||
|
||
7. References
|
||
|
||
7.1. Normative References
|
||
|
||
[E.123] Notation for national and international telephone numbers,
|
||
ITU-T Recommendation E.123, 1988
|
||
|
||
[E.164] The international public telecommunication numbering plan,
|
||
ITU-T Recommendation E.164, 1997
|
||
|
||
[F.1] Operational Provisions For The International Public
|
||
Telegram Service Transmission System, CCITT Recommendation
|
||
F.1, 1992
|
||
|
||
[F.31] Telegram Retransmission System, CCITT Recommendation F.31,
|
||
1988
|
||
|
||
[ISO3166] ISO 3166, "Codes for the representation of names of
|
||
countries".
|
||
|
||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
|
||
and Support", STD 3, RFC 1123, October 1989.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 29]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
|
||
"Internationalizing Domain Names in Applications (IDNA)",
|
||
RFC 3490, March 2003.
|
||
|
||
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
|
||
and Passwords", RFC 4013, February 2005.
|
||
|
||
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", RFC 4234, October 2005.
|
||
|
||
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
|
||
(LDAP): Technical Specification Road Map", RFC 4510, June
|
||
2006.
|
||
|
||
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
|
||
(LDAP): Directory Information Models", RFC 4512, June
|
||
2006.
|
||
|
||
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
|
||
(LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
|
||
|
||
[X.121] International numbering plan for public data networks,
|
||
ITU-T Recommendation X.121, 1996
|
||
|
||
[X.509] The Directory: Authentication Framework, ITU-T
|
||
Recommendation X.509, 1993
|
||
|
||
[X.520] The Directory: Selected Attribute Types, ITU-T
|
||
Recommendation X.520, 1993
|
||
|
||
[X.521] The Directory: Selected Object Classes. ITU-T
|
||
Recommendation X.521, 1993
|
||
|
||
7.2. Informative References
|
||
|
||
[RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
|
||
Schema", RFC 1274, November 1991.
|
||
|
||
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
|
||
Sataluri, "Using Domains in LDAP/X.500 Distinguished
|
||
Names", RFC 2247, January 1998.
|
||
|
||
[RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
|
||
"Naming Plan for Internet Directory-Enabled Applications",
|
||
RFC 2377, September 1998.
|
||
|
||
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
|
||
Class", RFC 2798, April 2000.
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 30]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
[RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol
|
||
(LDAP): Authentication Methods and Security Mechanisms",
|
||
RFC 4513, June 2006.
|
||
|
||
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
|
||
(LDAP) Schema Definitions for X.509 Certificates", RFC
|
||
4523, June 2006.
|
||
|
||
[RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
|
||
June 2006.
|
||
|
||
[X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
|
||
Information Technology - Open Systems Interconnection -
|
||
The Directory: Overview of concepts, models and services.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 31]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
Appendix A. Changes Made Since RFC 2256
|
||
|
||
This appendix lists the changes that have been made from RFC 2256 to
|
||
RFC 4519.
|
||
|
||
This appendix is not a normative part of this specification, which
|
||
has been provided for informational purposes only.
|
||
|
||
1. Replaced the document title.
|
||
|
||
2. Removed the IESG Note.
|
||
|
||
3. Dependencies on RFC 1274 have been eliminated.
|
||
|
||
4. Added a Security Considerations section and an IANA
|
||
Considerations section.
|
||
|
||
5. Deleted the conformance requirement for subschema object
|
||
classes in favor of a statement in [RFC4517].
|
||
|
||
6. Added explanation to attribute types and to each object class.
|
||
|
||
7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
|
||
(moved to [RFC4517]).
|
||
|
||
8. Removed the certificate-related attribute types:
|
||
authorityRevocationList, cACertificate,
|
||
certificateRevocationList, crossCertificatePair,
|
||
deltaRevocationList, supportedAlgorithms, and userCertificate.
|
||
|
||
Removed the certificate-related Object Classes:
|
||
certificationAuthority, certificationAuthority-V2,
|
||
cRLDistributionPoint, strongAuthenticationUser, and
|
||
userSecurityInformation
|
||
|
||
LDAP PKI is now discussed in [RFC4523].
|
||
|
||
9. Removed the dmdName, knowledgeInformation,
|
||
presentationAddress, protocolInformation, and
|
||
supportedApplicationContext attribute types and the dmd,
|
||
applicationEntity, and dSA object classes.
|
||
|
||
10. Deleted the aliasedObjectName and objectClass attribute type
|
||
definitions. Deleted the alias and top object class
|
||
definitions. They are included in [RFC4512].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 32]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
11. Added the 'dc' attribute type from RFC 2247, making the
|
||
distinction between 'stored' and 'query' values when preparing
|
||
IDN strings.
|
||
|
||
12. Numerous editorial changes.
|
||
|
||
13. Removed upper bound after the SYNTAX oid in all attribute
|
||
definitions where it appeared.
|
||
|
||
14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
|
||
userPassword.
|
||
|
||
15. Included definitions, comments and references for 'dcObject'
|
||
and 'uidObject'.
|
||
|
||
16. Replaced PKI schema references to use RFC 4523.
|
||
|
||
17. Spelt out and referenced ABNF on first usage.
|
||
|
||
18. Removed Section 2.4 (Source). Replaced the source table with
|
||
explicit references for each definition.
|
||
|
||
19. All references to an attribute type or object class are
|
||
enclosed in single quotes.
|
||
|
||
20. The layout of attribute type definitions has been changed to
|
||
provide consistency throughout the document:
|
||
> Section Heading
|
||
> Description of Attribute type
|
||
> Multivalued description
|
||
> Source Information
|
||
> Definition
|
||
> Example
|
||
> Additional Comments
|
||
|
||
Adding this consistent output included the addition of
|
||
examples to some definitions.
|
||
|
||
21. References to alternate names for attributes types are
|
||
provided with a reference to where they were originally
|
||
specified.
|
||
|
||
22. Clarification of the description of 'distinguishedName' and
|
||
'name', in regards to these attribute types being supertypes.
|
||
|
||
23. Spelt out ISDN on first usage.
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 33]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
24. Inserted a reference to [RFC4517] for the
|
||
'teletexTerminalIdentifier' definition's SYNTAX OID.
|
||
|
||
25. Additional names were added to the IANA Considerations. Names
|
||
include 'commonName', 'dcObject', 'domainComponent', 'GN',
|
||
'localityName', 'organizationName', 'organizationUnitName',
|
||
'surname', 'uidObject' and 'userid'.
|
||
|
||
26. Renamed all instances of supercede to supersede.
|
||
|
||
27. Moved [F.1], [F.31] and [RFC4013] from informative to
|
||
normative references.
|
||
|
||
28. Changed the 'c' definition to be consistent with X.500.
|
||
|
||
Author's Address
|
||
|
||
Andrew Sciberras
|
||
eB2Bcom
|
||
Suite 3, Woodhouse Corporate Centre,
|
||
935 Station Street,
|
||
Box Hill North, Victoria 3129
|
||
AUSTRALIA
|
||
|
||
Phone: +61 3 9896 7833
|
||
EMail: andrew.sciberras@eb2bcom.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 34]
|
||
|
||
RFC 4519 LDAP: Schema for User Applications June 2006
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is provided by the IETF
|
||
Administrative Support Activity (IASA).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Sciberras Standards Track [Page 35]
|
||
|