[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
additional ldapbis-user-schema comments
See attachment.
Kurt
> LDAP: User Schema
> <draft-ietf-ldapbis-user-schema-05>
>
>Abstract
>
> This document is a integral part of the LDAP technical specification
> [ROADMAP]. It provides an overview of attribute types and object
> classes intended for use by LDAP directory clients for many
> directory services, such as, White Pages.
s/overview/technical specification/
> Originally specified the
> ISO/IEC 9594 and 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.
Delete citation in Abstract.
Spell out LDAP on first use in abstract.
>1. Introduction
>
> This document provides an overview of attribute types and object
> classes intended for use by LDAP directory clients for many
> directory services, such as, White Pages.
Spell out LDAP on first use in body.
> Originally specified in
> the ISO/IEC 9594 and X.500 documents, these objects are widely used
> as a basis for the schema in many LDAP directories.
Add references to these documents.
> 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 Situation
>
> This document is a integral part of the LDAP technical specification
> [ROADMAP] which obsoletes the previously defined LDAP technical
> specification [RFC3377] in its entirety. In terms of RFC 2256,
> Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes].
> Sections 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models].
> The remainder of RFC 2256 is obsoleted by this document. Sections
> 3.4 and 4.4 of this document supercede the technical specifications
> for the 'dc' attribute type and 'domain' object class found in
> RFC 2247. The remainder of RFC 2247 remains in force.
Though fine for now, I note that RFC 2247 should be obsoleted by
a revision at the same time this I-D is published.
> A number of schema elements which 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
> [LDAP-PKI]. Unless reintroduced in future technical specifications,
> the remainder are to be considered Historic.
>
>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 given in Section 3 of [Syntaxes]
> and Matching Rules specified in Section 4 of [Syntaxes].
>
> The definitions of Attribute Types and Object Classes are written
> using the ABNF form of AttributeTypeDescription and
> ObjectClassDescription given in [Models]. Lines have been folded
> for readability.
>
>1.4 Source
>
> The schema definitions in this document are based on those found in
> the X.500-series [X.520] and [X.521] and RFC 2247 [RFC2247],
> specifically:
>
> Sections Source
> ============ ==================
> 2.1 - 2.3 X.520 [X.520]
> 2.4 RFC 2247 [RFC2247]
> 2.5 - 2.42 X.520 [X.520]
> 3.1 - 3.3 X.521 [X.521]
> 3.4 RFC 2247 [RFC2247]
> 3.5 - 3.13 X.521 [X.521]
Add:
However, the descriptions in this document SHALL be considered
definitive for use in LDAP.
>2. Attribute Types
>
> The Attribute Types contained in this section hold user information.
>
> There is no requirement that servers implement the following
> Attribute Types:
>
> searchGuide
> teletexTerminalIdentifier
>
> In fact, their use is greatly discouraged.
>
> An LDAP server implementation SHOULD recognize the rest of the
> Attribute Types described in this section.
>
>2.1 businessCategory
>
> This Attribute Type describes the kind of business performed by
> an organization.
s/kind/kinds/ as the attribute is multi-valued.
Add an example. (These comments applies generally to most other
attribute types specified in this section).
> ( 2.5.4.15 NAME 'businessCategory'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
>
> The SYNTAX oid indicates the Directory String syntax.
I find this wording odd, especially with "oid" being in lower case.
If referring to <oid> production, then that problematic as
the production to the right of SYNTAX is a <numericoid> not an
<oid>. Or one might think that SYNTAX is an <oid>. I suggest
this be re-written
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax.
Or, like [models], say:
The 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' matching
rules and the Directory String (1.3.6.1.4.1.1466.115.121.1.15)
syntax are defined in [Syntaxes].
>2.2 c
>
> This is the X.520 [X.520] countryName Attribute Type, which contains
> a two-letter ISO 3166 [ISO3166]country code.
This wording is I find ackward as this specification is
specifying LDAP attribute types, many of which are derived
from X.520 attribute types and implies the implementor must
read X.520 in order to support this attribute type. Hence,
I believe this would be better worded:
The c (countryName) attribute type contains a two-letter
ISO 3166 [ISO3166] country code (e.g., "DE"). (Source:
X.520)
(This comment applies generally to many other attribute types
defined in this section.)
> ( 2.5.4.6 NAME 'c'
> SUP name
> SINGLE-VALUE )
>
>2.3 cn
>
> This is the X.520 [X.520] commonName Attribute Type, which contains
> a name of an object. If the object corresponds to a person, it is
> typically the person's full name.
>
> ( 2.5.4.3 NAME 'cn'
> SUP name )
>
>2.4 dc
>
> The dc (short for domainComponent) attribute type is defined as
> follows:
>
> ( 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 )
>
> The value of this attribute is a string holding one component of a
> DNS domain name, e.g. "example" or "com" (but not "example.com").
s/component/component, a <label> [RFC1034],
(and add normative reference below)
> The encoding of IA5String for use in LDAP is simply
> the characters of the string itself. The equality matching rule is
> case insensitive, as is today's DNS.
Add:
It is noted that the directory will not ensure that values of
this attribute conform to the label production [RFC1034]. It
is the application responsibility to ensure domains it stores
in this attribute are appropriately represented.
It is also noted that applications supporting Internationalized
Domain Names SHALL use the ToASCII method [RFC3490] to produce
<label> components of the <domain> production.
(and list the normative references below)
>2.5 description
>
> This Attribute Type contains a human-readable description of
> the object.
>
> ( 2.5.4.13 NAME 'description'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
>
> The SYNTAX oid indicates the Directory String syntax.
>
>2.6 destinationIndicator
>
> This attribute is used for the telegram service.
How is it used? Suggest you paraphase the X.520 description.
The Destination Indicator attribute type specifies (according to
ITU-T Rec. F.1 and CCITT Rec. F.31) the country and city associated
with the object (the addressee) needed to provide the Public
Telegram Service. (Source: X.520)
> ( 2.5.4.27 NAME 'destinationIndicator'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
>
> The SYNTAX oid indicates the Printable String syntax.
>
>
>2.7 distinguishedName
>
> This Attribute Type is not used as the name of the object itself,
> but it is instead a base type from which attributes with DN syntax
> inherit.
>
> It is unlikely that values of this type itself will occur in an
> entry. LDAP server implementations which 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.
>
> ( 2.5.4.49 NAME 'distinguishedName'
> EQUALITY distinguishedNameMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
>
> The SYNTAX oid indicates the DN syntax.
>
>2.8 dnQualifier
>
> The dnQualifier Attribute Type specifies disambiguating information
> to add to the relative distinguished name of an entry. It is
> intended for use when merging data from multiple sources in order to
> prevent conflicts between entries which would otherwise have the same
> name. It is recommended that the value of the dnQualifier attribute
> be the same for all entries from a particular source.
>
> ( 2.5.4.46 NAME 'dnQualifier'
> EQUALITY caseIgnoreMatch
> ORDERING caseIgnoreOrderingMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
>
> The SYNTAX oid indicates the Printable String syntax.
>
>2.9 enhancedSearchGuide
>
> This attribute is for use by X.500 clients in constructing search
> filters.
delete "X.500" or replace with "directory"
> ( 2.5.4.47 NAME 'enhancedSearchGuide'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
>
> The SYNTAX oid indicates the Enhanced Guide syntax.
>
>2.10 facsimileTelephoneNumber
>
> A value of this Attribute Type is a telephone number for a facsimile
> terminal (and, optionally, its parameters).
>
> ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
>
> The SYNTAX oid indicates the Facsimile Telephone Number syntax.
>
>2.11 generationQualifier
>
> The generationQualifier Attribute Type contains the part of a
> person's name which typically is the suffix, as in "IIIrd".
>
> ( 2.5.4.44 NAME 'generationQualifier'
> SUP name )
>
>2.12 givenName
>
> The givenName Attribute Type is used to hold the part of a person's
> name which is not their surname nor middle name.
This definition is inconsisent with X.520 givenName which doesn't
exclude middle name from being considered a given name.
> ( 2.5.4.42 NAME 'givenName'
> SUP name )
>
>2.13 houseIdentifier
>
> This Attribute Type is used to identify a building within a location.
>
> ( 2.5.4.51 NAME 'houseIdentifier'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
>
> The SYNTAX oid indicates the Directory String syntax.
>
>2.14 initials
>
> The initials Attribute Type contains the initials of some or all of
> an individuals names, except the surname(s).
>
> ( 2.5.4.43 NAME 'initials'
> SUP name )
>
>2.15 internationalISDNNumber
>
> A value of this Attribute Type is an ISDN address, as defined in
> ITU Recommendation E.164 [E.164].
>
> ( 2.5.4.25 NAME 'internationalISDNNumber'
> EQUALITY numericStringMatch
> SUBSTR numericStringSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) i
>
> The SYNTAX oid indicates the Numeric String syntax.
>
>2.16 l
>
> This is the X.520 [X.520] localityName Attribute Type, which
> contains the name of a locality or place, such as a city, county or
> other geographic region.
>
> ( 2.5.4.7 NAME 'l'
> SUP name )
>
>2.17 member
>
> A value of this Attribute Type is the Distinguished Name of an
> object that is on a list or in a group.
>
> ( 2.5.4.31 NAME 'member'
> SUP distinguishedName )
>
>2.18 name
>
> The name Attribute Type is the attribute supertype from which string
> Attribute Types typically used for naming may be formed. It is
> unlikely that values of this type itself will occur in an entry.
> LDAP server implementations which 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.
>
> ( 2.5.4.41 NAME 'name'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
>
> The SYNTAX oid indicates the Directory String syntax.
>
>2.19 o
>
> This is the X.520 [X.520] organizationName Attribute Type, which
> contains the name of an organization.
>
> ( 2.5.4.10 NAME 'o'
> SUP name )
>
>2.20 ou
>
> This is the X.520 [X.520] organizationalUnitName Attribute Type,
> which contains the name of an organizational unit.
>
> ( 2.5.4.11 NAME 'ou'
> SUP name )
>
>2.21 owner
>
> A value of this Attribute Type is the Distinguished Name of an
> object that has an ownership responsibility for the object that
> is owned.
>
> ( 2.5.4.32 NAME 'owner'
> SUP distinguishedName )
>
>2.22 physicalDeliveryOfficeName
>
> This attribute contains the name that a Postal Service uses to
> identify a post office.
>
> ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
>
> The SYNTAX oid indicates the Directory String syntax.
>
>2.23 postalAddress
>
> This attribute contains an address used by a Postal Service to
> perform services for the object.
>
> ( 2.5.4.16 NAME 'postalAddress'
> EQUALITY caseIgnoreListMatch
> SUBSTR caseIgnoreListSubstringsMatch
> SYNTAX 1.5.6.1.4.1.1466.115.121.1.41 )
>
> The SYNTAX oid indicates the Postal Address syntax.
>
>2.24 postalCode
>
> This attribute contains a code used by a Postal Service to identify
> a postal service zone, such as the southern quadrant of a city.
>
> ( 2.5.4.17 NAME 'postalCode'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
>
> The SYNTAX oid indicates the Directory String syntax.
>
>2.25 postOfficeBox
>
> This attribute contains the number that a Postal Service uses when a
> customer arranges to receive mail at a box on premises of the Postal
> Service.
>
> ( 2.5.4.18 NAME 'postOfficeBox'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
>
> The SYNTAX oid indicates the Directory String syntax.
>
>2.26 preferredDeliveryMethod
>
> This attribute contains an indication of the preferred method of
> getting a message to the object.
>
> ( 2.5.4.28 NAME 'preferredDeliveryMethod'
> SYNTAX 1.5.6.1.4.1.1466.115.121.1.14
> SINGLE-VALUE )
>
> The SYNTAX oid indicates the Delivery Method syntax.
>
>2.27 registeredAddress
>
> This attribute holds a postal address suitable for reception of
> telegrams or expedited documents, where it is necessary to have the
> recipient accept delivery.
>
> ( 2.5.4.26 NAME 'registeredAddress'
> SUP postalAddress
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
>
> The SYNTAX oid indicates the Postal Address syntax.
>
>2.28 roleOccupant
>
> A value of this Attribute Type is the Distinguished Name of an
> object (normally a person) that fulfills the responsibilities of a
> role object.
>
> ( 2.5.4.33 NAME 'roleOccupant'
> SUP distinguishedName )
>
>2.29 searchGuide
>
> This Attribute Type is for use by clients in constructing search
> filters. It is superseded by enhancedSearchGuide, described above
> in section 2.9.
>
> ( 2.5.4.14 NAME 'searchGuide'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) ; Guide
>
>The SYNTAX oid indicates the Guide syntax.
>
>2.30 seeAlso
>
> A value of this Attribute Type is the Distinguished Name of an
> object that is related to the subject object.
>
> ( 2.5.4.34 NAME 'seeAlso'
> SUP distinguishedName )
>
>2.31 serialNumber
>
> This attribute contains the serial number of a device.
>
> ( 2.5.4.5 NAME 'serialNumber'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
>
> The SYNTAX oid indicates the Printable String syntax.
>
>2.32 sn
>
> This is the X.520 [X.520] surname Attribute Type, which contains the
> family name of a person.
>
> ( 2.5.4.4 NAME 'sn'
> SUP name )
>
>2.33 st
>
> This is the X.520 [X.520] stateOrProvinceName attribute, which
> contains the full name of a state or province.
>
> ( 2.5.4.8 NAME 'st'
> SUP name )
>
>2.34 street
>
> This is the X.520 [X.520] streetAddress attribute, which contains the
> physical address of the object to which the entry corresponds, such
> as an address for package delivery.
>
> ( 2.5.4.9 NAME 'street'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
>
> The SYNTAX oid indicates the Directory String syntax.
>
>2.35 telephoneNumber
>
> A value of this Attribute Type is a telephone number complying with
> ITU Recommendation E.123 [E.123].
>
> ( 2.5.4.20 NAME 'telephoneNumber'
> EQUALITY telephoneNumberMatch
> SUBSTR telephoneNumberSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
>
> The SYNTAX oid indicates the Telephone Number syntax.
>
>2.36 teletexTerminalIdentifier
>
> The withdrawal of Rec. F.200 has resulted in the withdrawal of this
> attribute.
>
> ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
>
> The SYNTAX oid indicates the Teletex Terminal Identifier syntax.
>
>2.37 telexNumber
>
> A value of this Attribute Type is a telex number, country code, and
> answerback code of a telex terminal.
>
> ( 2.5.4.21 NAME 'telexNumber'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
>
> The SYNTAX oid indicates the Telex Number syntax.
>
>2.38 title
>
> This attribute contains the title, such as "Vice President", of a
> person in their organizational context. The "personalTitle"
> attribute would be used for a person's title independent of their
> job function.
>
> ( 2.5.4.12 NAME 'title'
> SUP name )
>
>2.39 uniqueMember
>
> A value of this Attribute Type is the Distinguished Name of an
> object that is on a list or in a group, where the Relative
> Distinguished Name of the object includes a value that distinguishs
> between objects when a distinguished name has been reused.
>
> ( 2.5.4.50 NAME 'uniqueMember'
> EQUALITY uniqueMemberMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
>
>The SYNTAX oid indicates the Name and Optional UID syntax.
>
>2.40 userPassword
>
> A value of this Attribute Type is a character string that is known
> only to the user and the system to which the user has access.
>
> ( 2.5.4.35 NAME 'userPassword'
> EQUALITY octetStringMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
>
> The SYNTAX oid indicates the Octet String syntax.
>
> 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.
>
>2.41 x121Address
>
> A value of this Attribute Type is a data network address as defined
> by ITU Recommendation X.121 [X.121].
>
> ( 2.5.4.24 NAME 'x121Address'
> EQUALITY numericStringMatch
> SUBSTR numericStringSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
>
> The SYNTAX oid indicates the Numeric String syntax.
>
>2.42 x500UniqueIdentifier
>
> The x500UniqueIdentifier Attribute Type is used to distinguish
> between objects when a distinguished name has been reused. In X.520
> [X.520], this Attribute Type is called uniqueIdentifier. This is a
> different Attribute Type from both the "uid" and "uniqueIdentifier"
> Attribute Types.
>
> ( 2.5.4.45 NAME 'x500UniqueIdentifier'
> EQUALITY bitStringMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
>
> The SYNTAX oid indicates the Bit String syntax.
>
>
>3. Object Classes
>
> LDAP servers SHOULD recognize all the Object Classes listed here as
> values of the objectClass attribute.
>
>3.1 applicationProcess
>
> The applicationProcess Object Class definition is the basis of an
> entry which represents an application executing in a computer system.
>
> ( 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 which
> represents a country.
>
> ( 2.5.6.2 NAME 'country'
> SUP top
> STRUCTURAL
> MUST c
> MAY ( searchGuide $
> description ) )
>
>3.3 device
>
> The device Object Class is the basis of an entry which represents
> an appliance or computer or network element.
>
> ( 2.5.6.14 NAME 'device'
> SUP top
> STRUCTURAL
> MUST cn
> MAY ( serialNumber $
> seeAlso $
> owner $
> ou $
> o $
> l $
> description ) )
>
>3.4 domain
>
> The domain Object Class is the basis of an entry which represents a
> portion of a network, as organized by DNS.
>
> ( 0.9.2342.19200300.100.4.13 NAME 'domain'
> SUP top
> STRUCTURAL
> MUST dc
> MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
> x121Address $ registeredAddress $ destinationIndicator $
> preferredDeliveryMethod $ telexNumber $
> teletexTerminalIdentifier $ telephoneNumber $
> internationaliSDNNumber $ facsimileTelephoneNumber $ street $
> postOfficeBox $ postalCode $ postalAddress $
> physicalDeliveryOfficeName $ st $ l $ description $ o $
> associatedName ) )
>
> An example entry would be:
>
> dn: dc=tcp,dc=critical-angle,dc=com
> objectClass: top
> objectClass: domain
> dc: tcp
> description: a placeholder entry used with SRV records
This should be left to RFC 2247 (and RFC 2247bis).
>3.5 groupOfNames
>
> The groupOfNames Object Class is the basis of an entry which
> represents a set of named objects including information related to
> the purpose or maintenance of the set.
>
> ( 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.
>
> ( 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 which
> represents a place in the physical world.
>
> ( 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 which
> represents a structured group of people.
>
> ( 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 ) )
>
>3.9 organizationalPerson
>
> The organizationalPerson Object Class is the basis of an entry which
> represents a person in relation to an organization.
>
> ( 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 which
> represents a job or function or position in an organization.
>
> ( 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 which
> represents a piece of an organization.
>
> ( 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 which represents a
> human being.
>
> ( 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 which
> includes a person's residence in the representation of the person.
>
> ( 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 ) )
>
>
>4. IANA Considerations
>
> It is requested that the Internet Assigned Numbers Authority (IANA)
> update the LDAP descriptors registry as indicated in the following
> template:
>
> Subject: Request for LDAP Descriptor Registration Update
> Descriptor (short name): see comment
> Object Identifier: see comment
> Person & email address to contact for further information:
> Kathy Dally <kdally@mitre.org>
> Usage: (A = Attribute Type, O = Object Class) see comment
> Specification: RFC XXXX
> Author/Change Controller: IESG
>
> Comments:
> The following descriptors (short names) should be updated to
> refer to RFC XXXX.
>
> 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
> country O 2.5.6.2
> dc A 0.9.2342.19200300.100.1.25
> description A 2.5.4.13
> destinationIndicator A 2.5.4.27
> device O 2.5.6.14
> distinguishedName A 2.5.4.49
> dnQualifier A 2.5.4.46
> domain O 0.9.2342.19200300.100.4.13
> enhancedSearchGuide A 2.5.4.47
> facsimileTelephoneNumber A 2.5.4.23
> generationQualifier A 2.5.4.44
> givenName A 2.5.4.42
> 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
> member A 2.5.4.31
> name A 2.5.4.41
> o A 2.5.4.10
> organization O 2.5.6.4
> organizationalPerson O 2.5.6.7
> organizationalRole O 2.5.6.8
> organizationalUnit O 2.5.6.5
> 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
> telephoneNumber A 2.5.4.20
> teletexTerminalIdentifier A 2.5.4.22
> telexNumber A 2.5.4.21
> title A 2.5.4.12
> uniqueMember A 2.5.4.50
> 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 may
> result in disclosure of the password to unauthorized parties.
>
> It is required that strong authentication be performed in order to
> modify directory entries using LDAP.
Add: Use of integrity protection is encouraged to prevent session
hijacking.
>
>
>6. Acknowledgements
>
> The definitions, on which this document is based, have been developed
> by committees for telecommunications and international standards.
> No new attribute definitions have been added.
Since we've added 'dc' and 'domain', I don't believe this is precisely
true any more. I would attribute 'dc' and 'domain' to the authors
RFC 1274 and the LDAP-specific definition to the authors of RFC 2247.
> This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
> product of the IETF ASID Working Group.
>
> 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.
>
>
>7. References
>
>7.1 Normative
>
> [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
>
> [ISO3166] ISO 3166, "Codes for the representation of names of
> countries".
>
> [LDAP-PKI] Chadwick, D. W., Legg S., "LDAP Schema and Syntaxes for
> PKIs", draft-ietf-pkix-ldap-pki-schema-xx (a work in
> progress)
Informative.
> [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
> models-xx (a work in progress)
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", RFC 2119, March 1997
>
> [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
> Protocol (v3): Technical Specification", RFC 3377,
> September 2002
Informative.
>...[ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
> draft-ietf-ldapbis-roadmap-xx (a work in progress)
>
> [Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
> draft-ietf-ldapbis-syntaxes-xx (a work in progress)
>
> [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
>
> [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
> Sataluri, S., "Using Domains in LDAP/X.500 Distinguished Names",
> RFC 2247, January 1998
>
>
>
>8. Author's Address
>
> Kathy Dally
> The MITRE Corp.
> 1575 Colshire Dr., H300
> McLean VA 22102
> USA
>
> Phone: +1 703 883 6058
> Email: kdally@mitre.org
>
>
>
> Appendix A Changes RFC 2256
>
> This appendix lists the changes that have been made from RFC 2256 to
> this I-D.
>
> 1. Revised the Status of this Memo.
Can be dropped (purely editorial).
> 2. Removed the IESG Note.
>
> 3. Dependencies on RFC 1274 have been eliminated.
>
> 4. Added a Security Considerations section, requiring strong
> authentication in order to modify directory entries.
>
> 5. Deleted the conformance requirement for subschema object
> classes in favor of a statement in [Syntaxes].
>
> 6. Added a Table of Contents.
Editorial.
> 7. Added explanations to many attributes.
>
> 8. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
> (moved to [Syntaxes]).
>
> 9. Reordered Section 3, Attributes, and Section 4, Object
> Classes, alphabetically.
See note below.
> 10. Added an explanation for each object class.
Can be combined with item 7.
>
> 11. 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
>
> Noted that they are covered in PKIX WG documents.
I suggest the last sentence be replaced with:
LDAP PKI is now discussed in [LDAP-PKI].
>
> 12. Removed the dmdName Attribute Type and dmd Object Class
> because they are not in the version of X.500 which
> is referenced.
As none of the items have "because" statements, I suggest this
be trimmed and 12 be combined with 17. Alternative, add *terse*
some of the "because" statements items (16, 17, 18).
>......13. Deleted the 'aliasedObjectName' and 'objectClass' attribute
> type definitions. They are included in [Models].
^^^^^^ ?
>
> 14. Deleted the 'alias' and 'top' object class definitions. They
> are included in [Models].
Items 13 and 14 can be combined.
> 15. Replaced the document title.
Suggest this be made item 1.
> 16. Added the 'dc' attribute and the 'domain' object class from
> RFC 2247.
>
> 17. Deleted the 'knowledgeInformation', 'presentationAddress',
> 'protocolInformation', and 'supportedApplicationContext'
> attributes.
>
> 18. Deleted the 'applicationEntity' and 'dSA' object classes.
Can be combined with 17.
> 19. Added an IANA Considerations section.
Suggest adding
20. Numerous edititorial changes.
and then dropping 6 and 9.