view Side-By-Side changes
Lightweight Directory Access Protocol:
Standard and Pilot Attribute Definitions
<draft-ietf-asid-ldapv3-attributes-01.txt>
<draft-ietf-asid-ldapv3-attributes-02.txt>
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
2. Abstract
The Lightweight Directory Access Protocol (LDAP) [1] requires that the
contents of AttributeValue fields in protocol elements be octet
strings. This document defines the requirements that must be
satisfied by encoding rules used to render X.500 directory attribute
syntaxes into a form suitable for use in the LDAP, then goes on to
define the encoding rules for the standard set of attribute syntaxes
of [2],[3] and [4].
3. Table of It also identifies all the attribute types, object
classes and matching rules for LDAP Attributes
This version 3.
3. Overview
Section 4 states the general requirements and notations for attribute
types, object classes, syntax and matching rule definitions.
The core definitions are given in section lists all 5, those which are based on
X.500(1993) in section 6, and other optional definitions in section 7.
Page 1
INTERNET DRAFT LDAP Standard and Pilot Attribute Type names defined Definitions August 1996
4. General Issues
4.1. Attribute Types
The attribute types are described by sample values for the subschema
"attributeTypes" attribute, which is written in the
AttributeTypeDescription syntax. While lines have been folded for
readability, the values transferred in protocol would not contain
newlines.
The AttributeTypeDescription is encoded according to the following BNF,
and the productions for <oid>, <DirectoryStrings> and <DirectoryString>
are given in sections 4.2.1.
<AttributeTypeDescription> ::= "("
<oid> -- AttributeType identifier
[ "NAME" <DirectoryStrings> ] -- name used in AttributeType
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
[ "SUP" <oid> ] -- derived from this version other AttributeType
[ "EQUALITY" <oid> ] -- Matching Rule name
[ "ORDERING" <oid> ] -- Matching Rule name
[ "SUBSTR" <oid> ] -- Matching Rule name
[ "SYNTAX" <DirectoryString> ] -- see section 4.2
[ "SINGLE-VALUE" ] -- default multi-valued
[ "COLLECTIVE" ] -- default not collective
[ "DYNAMIC" ] -- default not dynamic
[ "NO-USER-MODIFICATION" ] -- default user modifiable
[ "USAGE" <AttributeUsage> ] -- default user applications
")"
<AttributeUsage> ::=
"userApplications"
| "directoryOperation"
| "distributedOperation" -- DSA-shared
| "dSAOperation" -- DSA-specific, value depends on server
Some of
LDAP. these samples contain a brief definition of the attribute in
the DESC field; servers are not required to provide the same or any text
in the description part of the subschema values they maintain.
Servers should implement all the attribute types in section 5.1, and
may also implement the types listed in sections 6.1 and 7.1.
Servers may support additional names and attributes not listed
here. in this
document. Later documents may define additional types.
3.1 Standard User Attributes
The attributes
Servers may implement additional attribute types not listed in this section are those defined in X.520(1993),
likely to be present
document, and if they do so, should publish the definitions of the types
in user entries. Servers must recognize all the
attributes attributeTypes attribute of this section.
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
Attribute Type Name X.500 OID Syntax
==================== =============== ================
objectClass 2.5.4.0 OID
aliasedObjectName 2.5.4.1 DN
knowledgeInformation 2.5.4.2 DirectoryString
cn 2.5.4.3 DirectoryString
sn 2.5.4.4 DirectoryString
serialNumber 2.5.4.5 PrintableString
c 2.5.4.6 CountryString
l 2.5.4.7 DirectoryString
st 2.5.4.8 DirectoryString
o 2.5.4.10 DirectoryString
ou 2.5.4.11 DirectoryString
title 2.5.4.12 DirectoryString
description 2.5.4.13 DirectoryString
searchGuide 2.5.4.14 Guide
businessCategory 2.5.4.15 DirectoryString
postalAddress 2.5.4.16 PostalAddress
postalCode 2.5.4.17 DirectoryString
postOfficeBox 2.5.4.18 DirectoryString
physicalDeliveryOfficeName 2.5.4.19 DirectoryString
telephoneNumber 2.5.4.20 TelephoneNumber
telexNumber 2.5.4.21 TelexNumber
teletexTerminalIdentifier 2.5.4.22 TeletexTerminalIdentifier
facsimileTelephoneNumber 2.5.4.23 FacsimileTelephoneNumber
x121Address 2.5.4.24 NumericString
internationaliSDNNumber 2.5.4.25 NumericString
registeredAddress 2.5.4.26 PostalAddress
destinationIndicator 2.5.4.27 PrintableString
preferredDeliveryMethod 2.5.4.28 DeliveryMethod
presentationAddress 2.5.4.29 PresentationAddress
supportedApplicationContext 2.5.4.30 OID
member 2.5.4.31 DN
owner 2.5.4.32 DN
roleOccupant 2.5.4.33 DN
seeAlso 2.5.4.34 DN
userPassword 2.5.4.35 Password
userCertificate 2.5.4.36 Certificate
cACertificate 2.5.4.37 Certificate
authorityRevocationList 2.5.4.38 CertificateList
certificateRevocationList 2.5.4.39 CertificateList
crossCertificatePair 2.5.4.40 CertificatePair
name 2.5.4.41 DirectoryString
givenName 2.5.4.42 DirectoryString
initials 2.5.4.43 DirectoryString
generationQualifier 2.5.4.44 DirectoryString
x500UniqueIdentifier 2.5.4.45 BitString
dnQualifier 2.5.4.46 PrintableString
enhancedSearchGuide 2.5.4.47 EnhancedGuide
protocolInformation 2.5.4.48 ProtocolInformation
distinguishedName 2.5.4.49 DN
uniqueMember 2.5.4.50 NameAndOptionalUID
houseIdentifier 2.5.4.51 DirectoryString
INTERNET-DRAFT LDAPv3 their subschema subentries.
4.2. Syntaxes
This section defines general requirements for LDAP attribute value
syntax encodings. All documents defining attribute syntax encodings for
use with LDAP are expected to conform to these requirements.
Page 2
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
3.2. Pilot User Attributes
These attributes are
The encoding rules defined in RFC 1274.
Attribute Type Name OID Syntax
==================== =========================== ================
uid 0.9.2342.19200300.100.1.1 CaseIgnoreString
textEncodedORaddress 0.9.2342.19200300.100.1.2 CaseIgnoreString
mail 0.9.2342.19200300.100.1.3 CaseIgnoreIA5String
info 0.9.2342.19200300.100.1.4 CaseIgnoreString
drink 0.9.2342.19200300.100.1.5 CaseIgnoreString
roomNumber 0.9.2342.19200300.100.1.6 CaseIgnoreString
photo 0.9.2342.19200300.100.1.7 Fax
userClass 0.9.2342.19200300.100.1.8 CaseIgnoreString
host 0.9.2342.19200300.100.1.9 CaseIgnoreString
manager 0.9.2342.19200300.100.1.10 DN
documentIdentifier 0.9.2342.19200300.100.1.11 CaseIgnoreString
documentTitle 0.9.2342.19200300.100.1.12 CaseIgnoreString
documentVersion 0.9.2342.19200300.100.1.13 CaseIgnoreString
documentAuthor 0.9.2342.19200300.100.1.14 DN
documentLocation 0.9.2342.19200300.100.1.15 CaseIgnoreString
homePhone 0.9.2342.19200300.100.1.20 TelephoneNumber
secretary 0.9.2342.19200300.100.1.21 DN
otherMailbox 0.9.2342.19200300.100.1.22 OtherMailbox
lastModifiedTime 0.9.2342.19200300.100.1.23 UTCTime
lastModifiedBy 0.9.2342.19200300.100.1.24 DN
dc 0.9.2342.19200300.100.1.25 CaseIgnoreIA5String
dNSRecord 0.9.2342.19200300.100.1.26 IA5String
mXRecord 0.9.2342.19200300.100.1.28 IA5String
nSRecord 0.9.2342.19200300.100.1.29 IA5String
sOARecord 0.9.2342.19200300.100.1.30 IA5String
cNAMERecord 0.9.2342.19200300.100.1.31 IA5String
associatedDomain 0.9.2342.19200300.100.1.37 CaseIgnoreIA5String
associatedName 0.9.2342.19200300.100.1.38 DN
homePostalAddress 0.9.2342.19200300.100.1.39 PostalAddress
personalTitle 0.9.2342.19200300.100.1.40 CaseIgnoreString
mobile 0.9.2342.19200300.100.1.41 TelephoneNumber
pager 0.9.2342.19200300.100.1.42 TelephoneNumber
co 0.9.2342.19200300.100.1.43 CaseIgnoreString
pilotUniqueIdentifier 0.9.2342.19200300.100.1.44 CaseIgnoreString
organizationalStatus 0.9.2342.19200300.100.1.45 CaseIgnoreString
janetMailbox 0.9.2342.19200300.100.1.46 CaseIgnoreIA5String
mailPreferenceOption 0.9.2342.19200300.100.1.47 MailPreference
buildingName 0.9.2342.19200300.100.1.48 CaseIgnoreString
dSAQuality 0.9.2342.19200300.100.1.49 DSAQualitySyntax
singleLevelQuality 0.9.2342.19200300.100.1.50 DataQualitySyntax
subtreeMinimumQuality 0.9.2342.19200300.100.1.51 DataQualitySyntax
subtreeMaximumQuality 0.9.2342.19200300.100.1.52 DataQualitySyntax
personalSignature 0.9.2342.19200300.100.1.53 Fax
dITRedirect 0.9.2342.19200300.100.1.54 DN
audio 0.9.2342.19200300.100.1.55 Audio
documentPublisher 0.9.2342.19200300.100.1.56 CaseIgnoreString
jpegPhoto 0.9.2342.19200300.100.1.60 JPEG
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
3.3. Collective Attributes
These attributes are stored in collective for a given attribute subentries, but may syntax must produce
octet strings. To the greatest extent possible, encoded octet
strings should be visible usable in user entries if requested. Servers which do not support
the X.500 protocols their native encoded form for display
purposes. In particular, encoding rules for attribute syntaxes
defining non-binary values should produce strings that can be
displayed with little or no translation by clients implementing
LDAP. There are a few cases (e.g. Audio) however, when it is not required sensible
to recognize these attributes, produce a printable representation, and
non-management clients should must not assume they are recognized by that
an unrecognized syntax is a string representation.
4.2.1. Common Encoding Aspects
In these encodings where an arbitrary string is used as part of a larger
production (other than a Distinguished Name), a backslash quoting mechanism
is used to encode the
server.
Attribute Type Name OID Syntax
==================== ========== ================
collectiveLocalityName 2.5.4.7.1 DirectoryString
collectiveStateOrProvinceName 2.5.4.8.1 DirectoryString
collectiveStreetAddress 2.5.4.9.1 DirectoryString
collectiveOrganizationName 2.5.4.10.1 DirectoryString
collectiveOrganizationalUnitName 2.5.4.11.1 DirectoryString
collectivePostalAddress 2.5.4.16.1 PostalAddress
collectivePostalCode 2.5.4.17.1 DirectoryString
collectivePostOfficeBox 2.5.4.18.1 DirectoryString
collectivePhysicalDeliveryOfficeName 2.5.4.19.1 DirectoryString
collectiveTelephoneNumber 2.5.4.20.1 TelephoneNumber
collectiveTelexNumber 2.5.4.21.1 TelexNumber
collectiveTeletexTerminalIdentifier 2.5.4.22.1 TeletexTerminalIdentifier
collectiveFacsimileTelephoneNumber 2.5.4.23.1 FacsimileTelephoneNumber
collectiveInternationaliSDNNumber 2.5.4.25.1 NumericString
3.4. Standard Operational Attributes
These attributes are defined following separator symbol character (such as ''',
'$' or '#') if it should occur in X.501(1993) Annexes B through E. All
servers must recognize the attributes "createTimestamp",
"modifyTimestamp", "creatorsName", "modifiersName", "attributeTypes",
"objectClasses" and "subschemaSubentry". Servers implementing X.500
protocols must recognize all that string. The backslash is followed
by a pair of hexadecimal digits representing the attributes listed here.
Attribute Type Name OID Syntax
==================== ============ ================
createTimestamp 2.5.18.1 GeneralizedTime
modifyTimestamp 2.5.18.2 GeneralizedTime
creatorsName 2.5.18.3 DN
modifiersName 2.5.18.4 DN
administrativeRole 2.5.18.5 OID
subtreeSpecification 2.5.18.6 SubtreeSpecification
collectiveExclusions 2.5.18.7 OID
subschemaSubentry 2.5.18.10 DN
dITStructureRules 2.5.21.1 DITStructureRuleDescription
dITContentRules 2.5.21.2 DITContentRuleDescription
matchingRules 2.5.21.4 MatchingRuleDescription
attributeTypes 2.5.21.5 AttributeTypeDescription
objectClasses 2.5.21.6 ObjectClassDescription
nameForms 2.5.21.7 NameFormDescription
matchingRuleUse 2.5.21.8 MatchingRuleUseDescription
structuralObjectClass 2.5.21.9 OID
governingStructureRule 2.5.21.10 INTEGER
accessControlScheme 2.5.24.1 OID
prescriptiveACI 2.5.24.4 ACIItem
entryACI 2.5.24.5 ACIItem
subentryACI 2.5.24.6 ACIItem
dseType 2.5.12.0 DSEType
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
myAccessPoint 2.5.12.1 AccessPoint93
superiorKnowledge 2.5.12.2 AccessPoint93
specificKnowledge 2.5.12.3 MasterAndShadowAccessPoints
nonSpecificKnowledge 2.5.12.4 MasterAndShadowAccessPoints
supplierKnowledge 2.5.12.5 SupplierInformation
consumerKnowledge 2.5.12.6 SupplierOrConsumer
secondaryShadows 2.5.12.7 SupplierAndConsumers
3.5 LDAP-defined attributes
These attributes are defined next character. A
backslash itself in [1].
Attribute Type Name Syntax
==================== ============
entryName DN
administratorAddress IA5String
currentTime GeneralizedTime
serverName DN
certificationPath CertificationPath
namingContexts DN
altLdapServer IA5String
altX500Server AccessPoint93
supportedExtension OID
4. Attribute Syntax Encoding Requirements
This section defines general requirements for LDAP attribute value the string which forms part of a larger syntax encodings. All documents is
always transmitted as '\5C' or '\5c'.
For the purposes of defining attribute syntax encodings for
use with LDAP are expected to conform to these requirements.
The the encoding rules defined for a given attribute syntax must produce
octet strings. To syntaxes,
the greatest extent possible, encoded octet
strings should be usable in their native encoded form for display
purposes. In particular, encoding rules for attribute syntaxes
defining non-binary values should produce strings that can be
displayed with little or no translation by clients implementing
LDAP.
In these examples where a user-specified string is used as part of a
larger production (other than a Distinguished Name), a backslash quoting
mechanism is used to permit encoding the following separator symbol
character (such as ''' or '$'). The backslash is followed by a pair of
hexidecimal digits representing the next character. A backslash itself
in the string is transmitted as '\5C' or '\5c'.
4.1. Common BNF
For the purposes of defining the encoding rules for attribute syntaxes,
the following auxiliary BNF definitions will following auxiliary BNF definitions will be used:
<a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
<d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
<hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
'A' | 'B' | 'C' | 'D' | 'E' | 'F'
<k> ::= <a> | <d> | '-'
<p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
'/' | ':' | '?' | ' '
<CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
<letterstring> ::= <a> | <a> <letterstring>
<numericstring> ::= <d> | <d> <numericstring>
<keystring> ::= <a> | <a> <anhstring>
<anhstring> ::= <k> | <k> <anhstring>
<printablestring> ::= <p> | <p> <printablestring>
<space> ::= ' ' | ' ' <space>
<whsp> ::= <space> | empty
<utf8> ::= any sequence of octets formed from the UTF-8 [11]
transformation of a BMP character from ISO 10646 [12]
Page 3
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
<dstring> ::= <utf8> | <utf8> <dstring>
4.2. Undefined and Binary
Values of types not described
<DirectoryStrings> ::= <DirectoryString> | '(' <DirectoryStringList> ')'
<DirectoryStringList> ::= <DirectoryStringList> <DirectoryString> | ""
<DirectoryString> ::= ''' <dstring> '''
<oids> ::= <oid> | '(' <oidlist> ')'
<oidlist> ::= <oidlist> '$' <oid> | <oid>
-- <oid> is defined in this document or not supported by
servers are by default encoded as if they were values of type Octet
String, with the string value being the BER-encoded transfer
representation 5.2.1.15
4.2.2 Binary Transfer of the value. Values
This encoding format is also used if the binary encoding is requested by the
client for an attribute. The value, an instance of the ASN.1
AttributeValue type, is DER-encoded, and this sequence of octets is used
as the value.
DER, a subset of BER, is defined in [13].
All servers must be capable of supporting this form for both generating
Search results and parsing Add Add, Compare and Modify requests.
5. Standard User Attribute Syntax Encodings
Servers must recognize all the syntaxes described Clients
should be prepared for receiving values in this section.
5.1. BitString
The encoding binary (e.g. userCertificate),
and should not display them directly to users.
4.2.3. Syntax Names
Names of a value with BitString syntax is according to the
following BNF:
<bitstring> ::= ''' <binary-digits> ''B'
<binary-digits> ::= '0' <binary-digits> | '1' <binary-digits> |
empty
INTERNET-DRAFT syntaxes for use with LDAPv3 Standard are ASCII strings which either
begin with a letter and Pilot Attribute Definitions June 1996
5.2. PrintableString contain only letters or digits.
The encoding of a value with PrintableString syntax is the string
value itself.
5.3. DirectoryString
A string with DirectoryString syntax is encoded in the UTF-8 form of
Unicode. For characters in the PrintableString form, the value is
encoded as the string value itself.
If it is of the TeletexString form, then characters which correspond
to the IA5 subset of TeletexString names are mapped directly, those which case insensitive. Historically since syntaxes correspond to ISO-8859-1 are transliterated, and those for which there
is no direct mapping are replaced by
ASN.1 types, they have been named starting with a IA5 description capital letter.
Syntax names do not have global scope: two clients or servers may
know of different syntaxes with the glyph.
If it is same name.
The definition of the UniversalString or BMPString form, UTF-8 additional arbitrary syntaxes is used to
encode them.
5.4. Certificate
Because of the changes from X.509(1988) and X.509(1993) strongly depreciated
since it will hinder interoperability: today's client and additional
planned changes to server
implementations generally do not have the syntax ability to support certificate extensions, no
string representation is defined, and values dynamically recognize
new syntaxes. In most cases attributes should be defined with Certificate the
DirectoryString syntax.
The following syntax
(userCertificate and caCertificate) names are only transferred using
a binary encoding. The BNF notation in RFC 1778 used for "User Certificate"
is not permitted.
5.5. CertificateList
Because of the incompatibility of attributes in this document.
Servers should recognize all the X.509(1988) and X.509(1993)
definitions of revocation lists, values with CertificateList syntax
(certificateRevocationList and authorityRevocationList) names in this section, but are
only
transferred using a binary encoding. The BNF notation required to implement the syntaxes in RFC 1778
for "Authority Revocation List" is not permitted.
5.6. CertificatePair
Because the section 5.2. Later documents
may define additional syntaxes.
AccessPoint ACIItem
AttributeTypeDescription Audio
Binary BitString
Certificate is being carried in binary, values with CertificateList
CertificatePair syntax (crossCertificatePair) are only transferred
using a binary encoding. The BNF notation in RFC 1778 for
"Certificate Pair" is not permitted.
5.7. CountryString
A value of CountryString syntax is encoded the same as a value of DataQualitySyntax
DeliveryMethod DirectoryString syntax.
5.8. DN
Values with
DITContentRuleDescription DN (Distinguished Name) syntax are encoded to have the
representation defined in [5]. Note that this representation is not
reversible to the original ASN.1 encoding as the CHOICE of any
DirectoryString element in an RDN is no longer known.
INTERNET-DRAFT LDAPv3
DSAQualitySyntax DSEType
EnhancedGuide FacsimileTelephoneNumber
Page 4
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
5.9. DeliveryMethod
Values with DeliveryMethod syntax
Fax GeneralizedTime
Guide IA5String
INTEGER JPEG
MailPreference MasterAndShadowAccessPoints
MatchingRuleDescription MatchingRuleUseDescription
ModifyRight NameAndOptionalUID
NameFormDescription NumericString
ObjectClassDescription OID
OtherMailbox Password
PostalAddress PresentationAddress
PrintableString ProtocolInformation
SubtreeSpecification SupplierAndConsumers
SupplierInformation SupplierOrConsumer
TelephoneNumber TeletexTerminalIdentifier
TelexNumber UTCTime
4.3. Object Classes
These are encoded according to described as sample values for the
following BNF:
<delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
<pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
5.10. EnhancedGuide
Values with subschema "objectClasses"
attribute for a server which implements the EnhancedGuide syntax are encoded according to LDAPv3 schema.
While lines have been folded for readability, the
following BNF:
<EnhancedGuide> ::= <objectclass> '#' <criteria> '#' <subset>
<subset> ::= "baseobject" | "oneLevel" | "wholeSubtree"
The <criteria> production is defined values transferred in the Guide syntax below.
5.11. FacsimileTelephoneNumber
Values with the FacsimileTelephoneNumber syntax
protocol would not contain newlines.
Object class descriptions are encoded written according to the following BNF:
<fax-number>
<ObjectClassDescription> ::= <printablestring> "("
<oid> -- ObjectClass identifier
[ '$' <faxparameters> "NAME" <DirectoryStrings> ]
<faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
<faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
In the above, the first <printablestring> is the actual fax number,
and the <faxparm> tokens represent fax parameters.
5.12. Guide
Values with the Guide syntax are encoded according to the following
BNF:
<guide-value> ::= [ <object-class> '#' ] <criteria>
<object-class> ::= an encoded value with OID syntax
<criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
<criteria-set> ::=
[ '(' "DESC" <DirectoryString> ] <criteria> '&' <criteria-set>
[ ')' "OBSOLETE" ] |
[ '(' "SUP" <oids> ] <criteria> '|' <criteria-set> -- Superior ObjectClasses
[ ')' ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ]
<criteria-item> ::= -- default structural
[ '(' "MUST" <oids> ] <attributetype> '$' <match-type> -- AttributeTypes
[ ')' "MAY" <oids> ]
<match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
INTERNET-DRAFT LDAPv3 -- AttributeTypes
")"
Servers should implement all the object classes in section 5.3:
account alias
applicationEntity applicationProcess
certificationAuthority country
dNSDomain dSA
device document
documentSeries domain
domainRelatedObject friendlyCountry
groupOfNames groupOfUniqueNames
locality newPilotPerson
organization organizationalPerson
organizationalRole organizationalUnit
person pilotDSA
pilotObject pilotOrganization
qualityLabelledData rFC822localPart
residentialPerson room
simpleSecurityObject strongAuthenticationUser
top
and may also implement the object classes of 6.3 and 7.3.
Page 5
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
5.13. NameAndOptionalUID
The encoding
Servers may implement additional object classes not listed in this
document, and if they do so, should publish the definitions of a value with the NameAndOptionalUID syntax is classes
in the objectClasses attribute of their subschema subentries. Later
documents may define additional object classes.
4.4. Matching Rules
Matching rules are used by servers to compare attribute values against
assertion values when performing search and comparision operations.
Most of the attributes given in this document will have an equality
matching rule defined.
Matching rule descriptions are written according to the following BNF:
<NameAndOptionalUID>
<MatchingRuleDescription> ::=
<DistinguishedName> "("
<oid> -- MatchingRule identifier
[ '#' <BitString> "NAME" <DirectoryStrings> ]
5.14. NumericString
The encoding of a string with the NumericString syntax is the string
value itself.
5.15. OID
Values with OID (Object Identifier) syntax are encoded according to the
following BNF:
<oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
<descr> ::= <keystring>
<numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
In
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
"SYNTAX" <DirectoryString>
")"
Servers should implement all the above BNF, <descr> is matching rules in section 5.4:
bitStringMatch caseExactIA5Match
caseIgnoreIA5Match caseIgnoreListMatch
caseIgnoreMatch distinguishedNameMatch
generalizedTimeMatch integerMatch
numericStringMatch objectIdentifierMatch
octetStringMatch telephoneNumberMatch
and may also implement the syntactic representation of an
object descriptor, which must consist matching rules of letters 6.4 and digits, starting
with a letter. When encoding values with OID syntax, the first encoding
option 7.4.
Servers may implement additional matching rules not listed in this
document, and if they do so, should be used publish the definitions of the
matching rules in preference to the second, matchingRules attribute of their
subschema subentries.
5. Core Definitions
Section 5 contains definitions which should be used
in preference to the third wherever possible. That is, in encoding
object identifiers, object descriptors (where assigned and known implemented by all servers
and clients.
5.1. Attribute Types
Servers must recognize all the implementation) should be used attributes of this section.
5.1.1. Standard User Attributes
The attributes listed in preference to numeric oids to
the greatest extent possible. For example, this section are those defined in encoding the object
identifier representing an organizationName, the descriptor
"organizationName" is preferable X.520(1993),
likely to "ds.4.10", which is be present in turn
preferable to user entries. Servers must recognize all the string "2.5.4.10". A list
attributes of descriptors is given
in Appendix B.
5.16. Password
Values with Password syntax are encoded as octet strings.
5.17. PostalAddress
Values with the PostalAddress syntax are encoded according to the
following BNF:
<postal-address> ::= <dstring> | <dstring> '$' <postal-address>
In the above, each <dstring> component this section. The semantics of a postal address value is
encoded as a value of type DirectoryString syntax.
5.18. PresentationAddress
Values with the PresentationAddress syntax are encoded to have the
representation described in [6].
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
5.19. ProtocolInformation
A value with the ProtocolInformation syntax is encoded according to the
following BNF:
<ProtocolInformation> ::= <NetworkAddress> <space> '#'
<SetOfProtocolIdentifier>
<NetworkAddress> ::= As appears in PresentationAddress
<SetOfProtocolIdentifiers> ::= <ProtocolIdentifier> |
'(' <ProtocolIdentifiers> ')'
<ProtoccolIdentifiers> ::= <ProtocolIdentifier> |
<ProtocolIdentifier> '$' <ProtocolIdentifiers>
<ProtocolIdentifier> ::= <oid>
For example,
NS+12345678 # 1.2.3.4.5
5.20. TelephoneNumber
Values with the TelephoneNumber syntax are encoded as if they were
Printable String types. Telephone numbers attributes 2.5.4.0 through
2.5.4.40 are recommended in X.520 to
be summarized in international form, e.g. "+1 512 305 0280".
5.21. TeletexTerminalIdentifier
Values with the TeletexTerminalIdentifier syntax are encoded according
to the following BNF:
<teletex-id> ::= <ttex-param> 0*('$' <ttx-param>)
<ttx-param> ::= <ttx-key> ':' <ttx-value>
<ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
<ttx-value> ::= <octetstring>
In the above, the first <printablestring> is the encoding of the
first portion of the teletex terminal identifier to be encoded, and
the subsequent 0 or more <printablestrings> are subsequent portions
of the teletex terminal identifier.
5.22. TelexNumber
Values with the TelexNumber syntax are encoded according to the
following BNF:
<telex-number> ::= <actual-number> '$' <country> '$' <answerback>
<actual-number> ::= <printablestring>
<country> ::= <printablestring>
INTERNET-DRAFT LDAPv3 RFC 1274.
( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch SYNTAX 'OID' )
Page 6
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
<answerback> ::= <printablestring>
In the above, <actual-number> is the syntactic representation of the
number portion of the TELEX number being encoded, <country> is the
TELEX country code, and <answerback> is the answerback code of a
( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
SYNTAX 'DN' SINGLE-VALUE )
( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch
SYNTAX 'DirectoryString' )
( 2.5.4.3 NAME 'cn' SUP name )
( 2.5.4.4 NAME 'sn' SUP name )
( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'PrintableString' )
( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
( 2.5.4.7 NAME 'l' SUP name )
( 2.5.4.8 NAME 'st' SUP name )
( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 2.5.4.10 NAME 'o' SUP name )
( 2.5.4.11 NAME 'ou' SUP name )
( 2.5.4.12 NAME 'title' SUP name )
( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 2.5.4.14 NAME 'searchGuide' SYNTAX 'Guide' )
( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
SUBSTRINGS caseIgnoreListSubstringsMatch SYNTAX 'PostalAddress' )
( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch
SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber' )
( 2.5.4.21 NAME 'telexNumber' SYNTAX 'TelexNumber' )
( 2.5.4.22 NAME 'teletexTerminalIdentifier'
SYNTAX 'TeletexTerminalIdentifier' )
( 2.5.4.23 NAME 'facsimileTelephoneNumber'
SYNTAX 'FacsimileTelephoneNumber' )
Page 7
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch
SUBSTRINGS numericStringSubstringsMatch SYNTAX 'NumericString' )
( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch
SUBSTRINGS numericStringSubstringsMatch SYNTAX 'NumericString' )
( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress
SYNTAX 'PostalAddress' )
( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'PrintableString' )
( 2.5.4.28 NAME 'preferredDeliveryMethod' SYNTAX 'DeliveryMethod'
SINGLE-VALUE )
( 2.5.4.29 NAME 'presentationAddress' EQUALITY presentationAddressMatch
SYNTAX 'PresentationAddress' SINGLE-VALUE )
( 2.5.4.30 NAME 'supportedApplicationContext'
EQUALITY objectIdentifierMatch SYNTAX 'OID' )
( 2.5.4.31 NAME 'member' SUP distinguishedName )
( 2.5.4.32 NAME 'owner' SUP distinguishedName )
( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )
( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )
( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
SYNTAX 'Password' )
( 2.5.4.36 NAME 'userCertificate' SYNTAX 'Certificate' )
( 2.5.4.37 NAME 'cACertificate' SYNTAX 'Certificate' )
( 2.5.4.38 NAME 'authorityRevocationList' SYNTAX 'CertificateList' )
( 2.5.4.39 NAME 'certificateRevocationList' SYNTAX 'CertificateList' )
( 2.5.4.40 NAME 'crossCertificatePair' SYNTAX 'CertificatePair' )
( 2.5.4.41 NAME 'name'
DESC 'The name attribute type is the attribute supertype from which
string attribute types typically used for naming may be formed.'
EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 2.5.4.42 NAME 'givenName' SUP name )
( 2.5.4.43 NAME 'initials'
DESC 'The initials attribute type contains the initials of some or all
of an individuals names, but not the surname(s).'
SUP name )
( 2.5.4.44 NAME 'generationQualifier'
DESC 'e.g. Jr or II.'
SUP name )
Page 8
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 2.5.4.45 NAME 'x500UniqueIdentifier'
DESC 'used to distinguish between objects when a distinguished name has
been reused.'
EQUALITY bitStringMatch SYNTAX 'BitString' )
( 2.5.4.46 NAME 'dnQualifier'
DESC 'The dnQualifier attribute type specifies disambiguating
information to add to the relative distinguished name of an
entry. It is intended to be used for entries held in multiple
DSAs which would otherwise have the same name, and that its
value be the same in a given DSA for all entries to which this
information has been added.'
EQUALITY caseIgnoreMatch
ORDERING caseIgnoreOrderingMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'PrintableString' )
( 2.5.4.47 NAME 'enhancedSearchGuide' SYNTAX 'EnhancedGuide' )
( 2.5.4.48 NAME 'protocolInformation' EQUALITY protocolInformationMatch
SYNTAX 'ProtocolInformation' )
( 2.5.4.49 NAME 'distinguishedName'
DESC 'This is not the name of the object itself, but a base type
from which attributes with DN syntax inherit.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN' )
( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
SYNTAX 'NameAndOptionalUID' )
( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
5.1.2. Pilot User Attributes
These attributes are defined in RFC 1274. Servers must recognize all the
attributes of this section.
( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORaddress'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.3 NAME 'mail' EQUALITY caseIgnoreIA5Match
SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' )
( 0.9.2342.19200300.100.1.4 NAME 'info' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.5 NAME 'drink' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
Page 9
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 0.9.2342.19200300.100.1.7 NAME 'photo' SYNTAX 'Fax' )
( 0.9.2342.19200300.100.1.8 NAME 'userClass' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.9 NAME 'host' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.10 NAME 'manager'
EQUALITY distinguishedNameMatch SYNTAX 'DN' )
( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
EQUALITY distinguishedNameMatch SYNTAX 'DN' )
( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.20 NAME 'homePhone' EQUALITY telephoneNumberMatch
SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber' )
( 0.9.2342.19200300.100.1.21 NAME 'secretary'
EQUALITY distinguishedNameMatch SYNTAX 'DN' )
( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNTAX 'OtherMailbox' )
( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' )
( 0.9.2342.19200300.100.1.26 NAME 'dNSRecord'
EQUALITY caseExactIA5Match SYNTAX 'IA5String' )
( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch
SYNTAX 'IA5String' )
( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
EQUALITY distinguishedNameMatch SYNTAX 'DN' )
( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
EQUALITY caseIgnoreListMatch
SUBSTRINGS caseIgnoreListSubstringsMatch SYNTAX 'PostalAddress' )
( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
Page 10
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 0.9.2342.19200300.100.1.41 NAME 'mobile' EQUALITY telephoneNumberMatch
SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber' )
( 0.9.2342.19200300.100.1.42 NAME 'pager' EQUALITY telephoneNumberMatch
SUBSTRINGS telephoneNumberSubstringsMatch SYNTAX 'TelephoneNumber' )
( 0.9.2342.19200300.100.1.43 NAME 'co' EQUALITY caseIgnoreMatch
SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.44 NAME 'pilotUniqueIdentifier'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox'
EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch
SYNTAX 'IA5String' )
( 0.9.2342.19200300.100.1.47 NAME 'mailPreferenceOption'
SYNTAX 'INTEGER' SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.49 NAME 'dSAQuality'
SYNTAX 'DSAQualitySyntax' SINGLE-VALUE )
( 0.9.2342.19200300.100.1.50 NAME 'singleLevelQuality'
SYNTAX 'DataQualitySyntax' SINGLE-VALUE )
( 0.9.2342.19200300.100.1.51 NAME 'subtreeMinimumQuality'
SYNTAX 'DataQualitySyntax' SINGLE-VALUE )
( 0.9.2342.19200300.100.1.52 NAME 'subtreeMaximumQuality'
SYNTAX 'DataQualitySyntax' SINGLE-VALUE )
( 0.9.2342.19200300.100.1.53 NAME 'personalSignature'
SYNTAX 'Fax' )
( 0.9.2342.19200300.100.1.54 NAME 'dITRedirect'
EQUALITY distinguishedNameMatch SYNTAX 'DN' )
( 0.9.2342.19200300.100.1.55 NAME 'audio' SYNTAX 'Audio' )
( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch
SYNTAX 'DirectoryString' )
( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' SYNTAX 'JPEG' )
Page 11
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
5.1.3. Standard Operational Attributes
All servers must recognize the the attribute types defined in this
section.
( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime'
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch SYNTAX 'GeneralizedTime'
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch SYNTAX 'DN'
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch SYNTAX 'DN'
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
( 2.5.18.10 NAME 'subschemaSubentry'
DESC 'The value of this attribute is the name of a subschema subentry,
an entry in which the server makes available attributes specifying
the schema.'
EQUALITY distinguishedNameMatch SYNTAX 'DN' NO-USER-MODIFICATION
SINGLE-VALUE USAGE directoryOperation )
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 'AttributeTypeDescription' USAGE directoryOperation )
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 'ObjectClassDescription' USAGE directoryOperation )
5.1.3. LDAP Operational Attributes
All servers must recognize and implement the attribute types defined in
this section. (Of course, it is not required that the server provide
values for these attributes, when the attribute corresponds to a feature
which the server does not implement.)
( 1.3.6.1.4.1.1466.101.120.1 NAME 'administratorsAddress'
DESC 'This attribute\27s values are string containing the addresses of
the LDAP server\27s human administrator. This information may
be of use when tracking down problems in an Internet distributed
directory. For simplicity the syntax of the values are limited to
being URLs of the mailto form with an RFC 822 address:
"mailto:user@domain". Future versions of this protocol may permit
other forms of addresses.'
SYNTAX 'IA5String' USAGE dSAOperation )
Page 12
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 1.3.6.1.4.1.1466.101.120.2 NAME 'currentTime'
DESC 'This attribute has a single value, a string containing a
GeneralizedTime character string. This attribute need only
be present if the server supports LDAP strong or protected
simple authentication. Otherwise if the server does not know
the current time, or does not choose to present it to clients,
this attribute need not be present. The client may wish to
use this value to detect whether a strong or protected bind
is failing because the client and server clocks are not
sufficiently synchronized. Clients should not use this time
field for setting their own system clock.'
SYNTAX 'GeneralizedTime' SINGLE-VALUE USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.120.3 NAME 'serverName'
DESC 'This attribute\27s value is the server\27s Distinguished Name.
If the server does not have a Distinguished Name it will not
be able to accept X.509-style strong authentication, and this
attribute should be absent. However the presence of this
attribute does not guarantee that the server will be able to
perform strong authentication. If the server acts as a
gateway to more than one X.500 DSA capable of strong
authentication, there may be multiple values of this
attribute, one per DSA. (Note: this attribute is distinct
from myAccessPoint, for it is not required that a server
have a presentation address in order to perform strong
authentication.) (Note: it is likely that clients will
retrieve this attribute in binary.)'
SYNTAX 'DN' USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.120.4 NAME 'certificationPath'
DESC 'This attribute contains a binary DER encoding of an
AF.CertificatePath data type, which is the certificate
path for a server. If the server does not have a certificate
path this attribute should be absent. (Note: this attribute
may only be retrieved in binary.)'
SYNTAX 'CertificatePath' USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
DESC 'The values of this attribute correspond to naming contexts
which this server masters or shadows. If the server does
not master any information (e.g. it is an LDAP gateway to a
public X.500 directory) this attribute should be absent. If
the server believes it contains the entire directory, the
attribute should have a single value, and that value should
be the empty string (indicating the null DN of the root).
This attribute will allow clients to choose suitable base
objects for searching when it has contacted a server.'
SYNTAX 'DN' USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
DESC 'The values of this attribute are URLs of other servers which
may be contacted when this server becomes unavailable. If
the server does not know of any other servers which could be
used this attribute should be absent. Clients should cache this
information in case their preferred LDAP server later becomes
unavailable.'
SYNTAX 'IA5String' USAGE dSAOperation )
Page 13
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
DESC 'The values of this attribute are OBJECT IDENTIFIERs,
the names of supported extensions
which the server supports. If the server does not support
any extensions this attribute should be absent.'
SYNTAX 'OID' USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.120.8 NAME 'entryName'
SYNTAX 'DN' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
( 1.3.6.1.4.1.1466.101.120.9 NAME 'modifyRights'
SYNTAX 'ModifyRight' NO-USER-MODIFICATION USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.120.10 NAME 'incompleteEntry'
SYNTAX 'BOOLEAN' NO-USER-MODIFICATION USAGE dSAOperation )
( 1.3.6.1.4.1.1466.101.120.11 NAME 'fromEntry'
SYNTAX 'BOOLEAN' NO-USER-MODIFICATION USAGE dSAOperation )
5.1.4 LDAP User Attributes
The following attributes may be of use in naming entries, or as
descriptive attributes in entries.
( 1.3.6.1.4.1.1466.101.121.1 NAME 'url'
DESC 'Uniform Resource Locator'
EQUALITY caseExactIA5Match SYNTAX 'IA5String' )
Note that the associatedDomain attribute may be used to hold a DNS name.
5.2. Syntaxes
5.2.1. Standard User Syntaxes
Servers must recognize all the syntaxes described in this section.
5.2.1.1. BitString
The encoding of a value with BitString syntax is according to the
following BNF:
<bitstring> ::= ''' <binary-digits> ''B'
<binary-digits> ::= '0' <binary-digits> | '1' <binary-digits> |
empty
5.2.1.2. PrintableString
The encoding of a value with PrintableString syntax is the string
value itself. PrintableString is limited to the characters in
production <p> of section 4.1.
Page 14
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
5.2.1.3. DirectoryString
A string with DirectoryString syntax is encoded in the UTF-8 form of
Unicode.
For characters in the PrintableString form, the value is encoded as the
string value itself.
If it is of the TeletexString form, then the characters are transliterated
to their equivalents in UniversalString, and encoded in UTF-8 [11].
If it is of the UniversalString or BMPString forms [12], UTF-8 is used to
encode them.
Note: the form of DirectoryString is not indicated in protocol. Servers
which convert to DAP should choose an appropriate form.
5.2.1.4. Certificate
Because of the changes from X.509(1988) and X.509(1993) and additional
changes to the ASN.1 definition to support certificate extensions, no
string representation is defined, and values with Certificate syntax
should only be transferred using the binary encoding, by requesting or
returning the attributes with descriptions "userCertificate;binary" or
"caCertificate;binary". The BNF notation in RFC 1778 for
"User Certificate" is not recommended to be used.
5.2.1.5. CertificateList
Because of the incompatibility of the X.509(1988) and X.509(1993)
definitions of revocation lists, values with CertificateList syntax
must only be transferred using a binary encoding, by requesting or
returning the attributes with descriptions
"certificateRevocationList;binary" or "authorityRevocationList;binary".
The BNF notation in RFC 1778 for "Authority Revocation List" is not
recommended to be used.
5.2.1.6. CertificatePair
Because the Certificate is being carried in binary, values with
CertificatePair syntax must only be transferred using a binary encoding,
by requesting or returning the attribute description
"crossCertificatePair;binary". The BNF notation in RFC 1778 for
"Certificate Pair" is not recommended to be used.
5.2.1.7. CountryString
A value of CountryString syntax is encoded the same as a value of
DirectoryString syntax. Note that this syntax is limited to values of
exactly two printable string characters.
<CountryString> ::= <p> <p>
Page 15
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
5.2.1.8. DN
Values with DN (Distinguished Name) syntax are encoded to have the
representation defined in [5]. Note that this representation is not
reversible to the original ASN.1 encoding as the CHOICE of any
DirectoryString element in an RDN is no longer known.
5.2.1.9. DeliveryMethod
Values with DeliveryMethod syntax are encoded according to the
following BNF:
<delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
<pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
5.2.1.10. EnhancedGuide
Values with the EnhancedGuide syntax are encoded according to the
following BNF:
<EnhancedGuide> ::= <objectclass> '#' <criteria> '#' <subset>
<subset> ::= "baseobject" | "oneLevel" | "wholeSubtree"
The <criteria> production is defined in the Guide syntax below.
This syntax has been added subseqent to RFC 1779.
5.2.1.11. FacsimileTelephoneNumber
Values with the FacsimileTelephoneNumber syntax are encoded according
to the following BNF:
<fax-number> ::= <printablestring> [ '$' <faxparameters> ]
<faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
<faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
In the above, the first <printablestring> is the actual fax number,
and the <faxparm> tokens represent fax parameters.
5.2.1.12. Guide
Values with the Guide syntax are encoded according to the following
BNF:
<guide-value> ::= [ <object-class> '#' ] <criteria>
<object-class> ::= an encoded value with OID syntax
<criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
Page 16
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
<criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
[ '(' ] <criteria> '|' <criteria-set> [ ')' ]
<criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
<match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
5.2.1.13. NameAndOptionalUID
The encoding of a value with the NameAndOptionalUID syntax is according
to the following BNF:
<NameAndOptionalUID> ::=
<DistinguishedName> [ '#' <BitString> ]
Although the '#' character may occur in a string representation of a
distinguished name, no additional special quoting is done in the
distinguished name other than that of [5].
This syntax has been added subseqent to RFC 1779.
5.2.1.14. NumericString
The encoding of a string with the NumericString syntax is the string
value itself.
5.2.1.15. OID
Values with OID (Object Identifier) syntax are encoded according to the
following BNF:
<oid> ::= <descr> | <numericoid>
<descr> ::= <keystring>
<numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
In the above BNF, <descr> is the syntactic representation of an
object descriptor, which must consist of letters and digits, starting
with a letter. When encoding values with OID syntax, the first encoding
option should be used in preference to the second. That is, in encoding
object identifiers, object descriptors (where assigned and known by
the implementation) should be used in preference to numeric oids to
the greatest extent possible. All permitted object descriptors for use
in LDAP are given in Appendix A, B and C. No other object descriptors
should be used. (Note that clients can expect that LDAPv2 implementations
may return object descriptors other than those listed.)
5.2.1.16. Password
Values with Password syntax are encoded as octet strings.
Page 17
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
5.2.1.17. PostalAddress
Values with the PostalAddress syntax are encoded according to the
following BNF:
<postal-address> ::= <dstring> | <dstring> '$' <postal-address>
In the above, each <dstring> component of a postal address value is
encoded as a value of type DirectoryString syntax. Backslashes and
dollar characters, if they occur in the component, are quoted as
described in section 4.2.
5.2.1.18. PresentationAddress
Values with the PresentationAddress syntax are encoded to have the
representation described in [6].
5.2.1.20. TelephoneNumber
Values with the TelephoneNumber syntax are encoded as if they were
Printable String types. Telephone numbers are recommended in X.520 to
be in international form, e.g. "+1 512 305 0280".
5.2.1.21. TeletexTerminalIdentifier
Values with the TeletexTerminalIdentifier syntax are encoded according
to the following BNF:
<teletex-id> ::= <ttx-term> 0*('$' <ttx-param>)
<ttx-term> ::= <printablestring>
<ttx-param> ::= <ttx-key> ':' <ttx-value>
<ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
<ttx-value> ::= <octetstring>
In the above, the first <printablestring> is the encoding of the
first portion of the teletex terminal identifier to be encoded, and
the subsequent 0 or more <octetstrings> are subsequent portions
of the teletex terminal identifier.
5.2.1.22. TelexNumber
Values with the TelexNumber syntax are encoded according to the
following BNF:
<telex-number> ::= <actual-number> '$' <country> '$' <answerback>
<actual-number> ::= <printablestring>
<country> ::= <printablestring>
<answerback> ::= <printablestring>
Page 18
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
In the above, <actual-number> is the syntactic representation of the
number portion of the TELEX number being encoded, <country> is the
TELEX country code, and <answerback> is the answerback code of a
TELEX terminal.
5.23.
5.2.1.23. UTCTime
Values with UTCTime syntax are encoded as if they were printable
strings with the strings containing a UTCTime value.
5.2.1.24. Boolean
Values with Boolean syntax are encoded according to the following
BNF:
<boolean> ::= "TRUE" | "FALSE"
Boolean values have an encoding of "TRUE" if they are logically true,
and have an encoding of "FALSE" otherwise.
5.2.2. Pilot Syntaxes
Servers must recognize all the syntaxes described in this section.
5.2.2.1. Audio
The encoding of a value with Audio syntax is the octets of the value
itself, an 8KHz uncompressed encoding compatible with the SunOS
4.1.3 'play' utility.
5.2.2.2. DSAQualitySyntax
Values with this syntax are encoded according to the following BNF:
<DsaQualitySyntax> ::= <DSAKeyword> [ '#' <description> ]
<DSAKeyword> ::= 'DEFUNCT' | 'EXPERIMENTAL' | 'BEST-EFFORT' |
'PILOT-SERVICE' | 'FULL-SERVICE'
<description> ::= encoded as a PrintableString
5.2.2.3. DataQualitySyntax
Values with this syntax are encoded according to the following BNF:
<DataQualitySyntax> ::= <compKeyword> '#' <attrQuality> '#'
<listQuality> [ '#' <description> ]
<attrQuality> ::= <levelKeyword> '+' <compKeyword>
<listQuality> ::= <list> '$' <list><listQuality>
<list> ::= <attribute> '+' <attrQuality>
<compKeyword> ::= 'NONE' | 'SAMPLE' | 'SELECTED' |
'SUBSTANTIAL' | 'FULL'
Page 19
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
<levelKeyword> ::= 'UNKNOWN' | 'EXTERNAL' | 'SYSTEM-MAINTAINED' |
'USER-SUPPLIED'
5.2.2.4. IA5String
The encoding of a value with IA5String syntax is the string value
itself.
5.2.2.5. JPEG
Values with UTCTime JPEG syntax are encoded as if they were printable octet strings
containing JPEG images in the JPEG File Interchange Format (JFIF), as
described in [8].
5.2.2.6. MailPreference
Values with MailPreference syntax are encoded according to the
following BNF:
<mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
5.2.2.7. OtherMailbox
Values of the OtherMailbox syntax are encoded according to the
following BNF:
<otherMailbox> ::= <mailbox-type> '$' <mailbox>
<mailbox-type> ::= an encoded Printable String
<mailbox> ::= an encoded IA5 String
In the above, <mailbox-type> represents the type of mail system in
which the mailbox resides, for example "MCIMail"; and <mailbox> is the
actual mailbox in the mail system defined by <mailbox-type>.
5.2.2.8. Fax
Values with Fax syntax are encoded as if they were octet strings
containing Group 3 Fax images as defined in [7].
5.2.3. Operational Syntaxes
Servers must recognize all the syntaxes described in this section.
5.2.3.1. AttributeTypeDescription
Values with this syntax are encoded according to the BNF given at the
start of section 4.1. For example,
( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' )
Page 20
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
5.2.3.2. GeneralizedTime
Values of this syntax are encoded as printable strings, represented
as specified in X.208. Note that the time zone must be specified.
For example,
199412161032Z
5.2.3.3. INTEGER
Values with INTEGER syntax are encoded as the decimal representation
of their values, with each decimal digit represented by the its
character equivalent. So the strings containing a UTCTime value.
5.24. Boolean number 1321 is represented by the character
string "1321".
5.2.3.4. ObjectClassDescription
Values with Boolean of this syntax are encoded according to the following
BNF:
<boolean> ::= "TRUE" | "FALSE"
Boolean BNF in section 4.3.
5.3. Object Classes
5.3.1. Standard Classes
Servers must recognize the object classes listed here as values have an encoding of "TRUE" if
the objectClass attribute. With the exception of groupOfUniqueNames,
they are logically true, described in RFC 1274.
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) )
( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
( 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 ) )
( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description ) )
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
Page 21
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 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 ) )
( 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 ) )
( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
( 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 ) )
( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn
MAY ( seeAlso $ ou $ l $ description ) )
( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL
MUST ( presentationAddress $ cn )
MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
description ) )
( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL
MAY knowledgeInformation )
( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn
MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top STRUCTURAL
MUST userCertificate )
( 2.5.6.16 NAME 'certificationAuthority' SUP top STRUCTURAL
MUST ( authorityRevocationList $ certificateRevocationList $
cACertificate ) MAY crossCertificatePair )
( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
MUST ( uniqueMember $ cn )
MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
Page 22
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
5.3.2. Pilot Classes
These object classes are defined in RFC 1274. All servers must recognize
these object class names.
( 0.9.2342.19200300.100.4.3 NAME 'pilotObject' SUP top STRUCTURAL
MAY ( jpegPhoto $ audio $ dITRedirect $ lastModifiedBy $
lastModifiedTime $ pilotUniqueIdentifier $ manager $ photo $ info ) )
( 0.9.2342.19200300.100.4.4 NAME 'newPilotPerson' SUP person
STRUCTURAL MAY ( personalSignature $ mailPreferenceOption $
organizationalStatus $ pagerTelephoneNumber $ mobileTelephoneNumber $
otherMailbox $ janetMailbox $ businessCategory $
preferredDeliveryMethod $ personalTitle $ secretary $
homePostalAddress $ homePhone $ userClass $ roomNumber $
favouriteDrink $ rfc822Mailbox $ textEncodedORaddress $ userid ) )
( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL
MUST userid MAY ( host $ ou $ o $ l $ seeAlso $ description ) )
( 0.9.2342.19200300.100.4.6 NAME 'document' SUP ( top $ pilotObject )
STRUCTURAL MUST documentIdentifier
MAY ( documentPublisher $ documentStore $ documentAuthorSurName $
documentAuthorCommonName $ abstract $ subject $ keywords $
updatedByDocument $ updatesDocument $ obsoletedByDocument $
obsoletesDocument $ documentLocation $ documentAuthor $
documentVersion $ documentTitle $ ou $ o $ l $ seeAlso $ description $
cn ) )
( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL MUST cn
MAY ( telephoneNumber $ seeAlso $ description $ roomNumber ) )
( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top STRUCTURAL
MUST cn MAY ( ou $ o $ l $ telephoneNumber $ seeAlso $ description ) )
( 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 ) )
( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart' SUP domain
STRUCTURAL
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
streetAddress $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ telephoneNumber $ seeAlso $ description $
sn $ cn ) )
( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL
MAY dNSRecord )
Page 23
INTERNET DRAFT LDAP Standard and have an encoding of "FALSE" otherwise.
6. Pilot Attribute Syntax Encodings Definitions August 1996
( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' SUP top
STRUCTURAL MUST associatedDomain )
( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country
STRUCTURAL MUST co )
( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' SUP top
STRUCTURAL MUST userPassword )
( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
SUP ( organization $ organizationalUnit ) STRUCTURAL
MAY buildingName )
( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA' SUP dSA STRUCTURAL
MUST dSAQuality )
( 0.9.2342.19200300.100.4.23 NAME 'qualityLabelledData' SUP top
STRUCTURAL MUST singleLevelQuality
MAY ( subtreeMaximumQuality $ subtreeMinimumQuality ) )
5.4. Matching Rules
Servers must recognize all the syntaxes described in this section.
6.1. Audio
The encoding of a value with Audio syntax is the octets following matching rules, used for equality
matching, and must be capable of performing the value
itself, an 8KHz uncompressed encoding compatible with the SunOS
4.1.3 'play' utility.
6.2. CaseIgnoreIA5String
The encoding of a value with CaseIgnoreIA5String syntax is matching rules.
For all these rules, the string
value itself.
6.3. CaseIgnoreString
The encoding of a value with CaseIgnoreString assertion syntax is the same as the
encoding of a value with DirectoryString syntax.
6.4. DSAQualitySyntax
Values with this syntax
( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 'OID' )
( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 'DN' )
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 'DirectoryString' )
( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 'NumericString' )
( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 'PostalAddress' )
( 2.5.13.14 NAME 'integerMatch' SYNTAX 'INTEGER' )
( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 'BitString' )
( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 'Password' )
( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 'TelephoneNumber' )
( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 'GeneralizedTime' )
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 'IA5String' )
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 'IA5String' )
When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are encoded according to treated the following BNF:
<DsaQualitySyntax> ::= <DSAKeyword> [ '#' <description> ]
<DSAKeyword> ::= 'DEFUNCT' | 'EXPERIMENTAL' | 'BEST-EFFORT' |
'PILOT-SERVICE' | 'FULL-SERVICE'
<description> ::= encoded same as a PrintableString
INTERNET-DRAFT LDAPv3
an individual space, and leading and trailing whitespace is ignored.
6. X.500 Definitions
Servers which support the X.500(1993) protocols are required to recognize
these attributes types, syntaxes, object classes and matching rules. All
other servers are not required to implement any definitions in section 6,
although they may do so.
Non-management clients should not assume they are recognized by servers.
6.1. Attribute Types
Page 24
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
6.5. DataQualitySyntax
Values with this syntax are encoded according to the following BNF:
<DataQualitySyntax> ::= <compKeyword> '#' <attrQuality> '#'
<listQuality> [ '#' <description> ]
<attrQuality> ::= <levelKeyword> '+' <compKeyword>
<listQuality> ::= <list> '$' <list><listQuality>
<list> ::= <attribute> '+' <attrQuality>
<compKeyword> ::= 'NONE' | 'SAMPLE' | 'SELECTED' |
'SUBSTANTIAL' | 'FULL'
<levelKeyword> ::= 'UNKNOWN' | 'EXTERNAL' | 'SYSTEM-MAINTAINED' |
'USER-SUPPLIED'
6.6. IA5String
The encoding
6.1.1. User Attributes
All user attributes of a value with IA5String syntax is the string value
itself.
6.7. JPEG
Values with JPEG syntax X.500 are encoded as if they were octet strings
containing JPEG images in the JPEG File Interchange Format (JFIF), as
described listed in [8].
6.8. MailPreference
Values with MailPreference syntax section 5.1.1.
6.1.2. Collective Attributes
These attributes are encoded according to the
following BNF:
<mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
6.9. OtherMailbox
Values stored in collective attribute subentries, but may
be visible in user entries if requested.
Each of the OtherMailbox syntax are encoded according to the
following BNF:
<otherMailbox> ::= <mailbox-type> '$' <mailbox>
<mailbox-type> ::= an encoded Printable String
<mailbox> ::= an encoded IA5 String
In the above, <mailbox-type> represents the type these collective attributes is a subtype of mail system in
which the mailbox resides, for example "MCIMail"; and <mailbox> is attribute which
has the
actual mailbox in OID without the mail system defined by <mailbox-type>.
6.10. Fax
Values with Fax syntax final ".1", e.g. "collectivePostalCode" is a
subtype of "postalCode".
( 2.5.4.7.1 NAME 'collectiveLocalityName' SUP l COLLECTIVE )
( 2.5.4.8.1 NAME 'collectiveStateOrProvinceName' SUP st COLLECTIVE )
( 2.5.4.9.1 NAME 'collectiveStreetAddress' SUP street COLLECTIVE )
( 2.5.4.10.1 NAME 'collectiveOrganizationName' SUP o COLLECTIVE )
( 2.5.4.11.1 NAME 'collectiveOrganizationalUnitName' SUP ou COLLECTIVE )
( 2.5.4.16.1 NAME 'collectivePostalAddress' SUP postalAddress COLLECTIVE )
( 2.5.4.17.1 NAME 'collectivePostalCode' SUP postalCode COLLECTIVE )
( 2.5.4.18.1 NAME 'collectivePostOfficeBox' SUP postOfficeBox COLLECTIVE )
( 2.5.4.19.1 NAME 'collectivePhysicalDeliveryOfficeName'
SUP physicalDeliveryOfficeName COLLECTIVE )
( 2.5.4.20.1 NAME 'collectiveTelephoneNumber' SUP telephoneNumber
COLLECTIVE )
( 2.5.4.21.1 NAME 'collectiveTelexNumber' SUP 'TelexNumber' COLLECTIVE )
( 2.5.4.22.1 NAME 'collectiveTeletexTerminalIdentifier'
SUP teletexTerminalIdentifier COLLECTIVE )
( 2.5.4.23.1 NAME 'collectiveFacsimileTelephoneNumber'
SUP facsimileTelephoneNumber COLLECTIVE )
( 2.5.4.25.1 NAME 'collectiveInternationaliSDNNumber'
SUP internationaliSDNNumber COLLECTIVE )
6.1.3. Standard Operational Attributes
These attributes are encoded as if they were octet strings
containing Group 3 Fax images as defined in [7].
INTERNET-DRAFT LDAPv3 X.501(1993) Annexes B through E.
( 2.5.18.5 NAME 'administrativeRole' EQUALITY objectIdentifierMatch
SYNTAX 'OID' USAGE directoryOperation )
( 2.5.18.6 NAME 'subtreeSpecification' SYNTAX 'SubtreeSpecification'
SINGLE-VALUE USAGE directoryOperation )
Page 25
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
6.11. CaseIgnoreList
Values with CaseIgnoreList syntax are encoded according
( 2.5.18.7 NAME 'collectiveExclusions' EQUALITY objectIdentifierMatch
SYNTAX 'OID' USAGE directoryOperation )
( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
SYNTAX 'DITStructureRuleDescription' USAGE directoryOperation )
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 'DITContentRuleDescription' USAGE directoryOperation )
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 'MatchingRuleDescription' USAGE directoryOperation )
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 'NameFormDescription' USAGE directoryOperation )
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 'MatchingRuleUseDescription' USAGE directoryOperation )
( 2.5.21.9 NAME 'structuralObjectClass' EQUALITY objectIdentifierMatch
SYNTAX 'OID' SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
( 2.5.21.10 NAME 'governingStructuralRule' EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
( 2.5.24.1 NAME 'accessControlScheme' EQUALITY objectIdentifierMatch
SYNTAX 'OID' SINGLE-VALUE USAGE directoryOperation )
( 2.5.24.4 NAME 'prescriptiveACI'
EQUALITY directoryStringFirstComponentMatch SYNTAX 'ACIItem'
USAGE directoryOperation )
( 2.5.24.5 NAME 'entryACI'
EQUALITY directoryStringFirstComponentMatch SYNTAX 'ACIItem'
USAGE directoryOperation )
( 2.5.24.6 NAME 'subentryACI'
EQUALITY directoryStringFirstComponentMatch SYNTAX 'ACIItem'
USAGE directoryOperation )
( 2.5.12.0 NAME 'dseType' EQUALITY bitStringMatch SYNTAX 'DSEType'
SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
( 2.5.12.1 NAME 'myAccessPoint' EQUALITY accessPointMatch
SYNTAX 'AccessPoint' SINGLE-VALUE NO-USER-MODIFICATION
USAGE dSAOperation )
( 2.5.12.2 NAME 'superiorKnowledge' EQUALITY accessPointMatch
SYNTAX 'AccessPoint' SINGLE-VALUE NO-USER-MODIFICATION
USAGE dSAOperation )
Page 26
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
( 2.5.12.3 NAME 'specificKnowledge'
EQUALITY masterAndShadowAccessPointsMatch
SYNTAX 'MasterAndShadowAccessPoints'
SINGLE-VALUE NO-USER-MODIFICATION USAGE distributedOperation )
( 2.5.12.4 NAME 'nonSpecificKnowledge'
EQUALITY masterAndShadowAccessPointsMatch
SYNTAX 'MasterAndShadowAccessPoints' NO-USER-MODIFICATION
USAGE distributedOperation )
( 2.5.12.5 NAME 'supplierKnowledge'
EQUALITY supplierOrConsumerInformationMatch
SYNTAX 'SupplierInformation'
NO-USER-MODIFICATION USAGE dSAOperation )
( 2.5.12.6 NAME 'consumerKnowledge'
EQUALITY supplierOrConsumerInformationMatch
SYNTAX 'SupplierOrConsumer'
NO-USER-MODIFICATION USAGE dSAOperation )
( 2.5.12.7 NAME 'secondaryShadows'
EQUALITY supplierAndConsumersMatch
SYNTAX 'SupplierAndConsumers'
NO-USER-MODIFICATION USAGE dSAOperation )
6.1.4. LDAP-defined Operational Attributes
6.1.4.1. targetSystem
( 1.3.6.1.4.1.1466.101.120.10 NAME 'targetSystem'
SYNTAX 'AccessPoint' SINGLE-VALUE NO-USER-MODIFICATION
USAGE distributedOperation )
The value of this attribute may be supplied in an AddEntry operation
to inform the
following BNF:
<caseignorelist> ::= <caseignorestring> |
<caseignorestring> '$' <caseignorelist>
<caseignorestring> ::= a string encoded according to Directory of the rules for
DirectoryString as above.
6.12. CaseExactList
Values with CaseExactList syntax are encoded according to target server on which the
following BNF:
<caseexactlist> ::= <caseexactstring> |
<caseexactstring> '$' <caseexactlist>
<caseexactstring> ::= a string encoded according entry is to
be held. This is used to create a new naming context in the rules for
DirectoryString as above.
7. Standard Operational Attribute Syntax Encodings
All servers must recognize directory
tree. A server which does not permit the syntaxes use of AttributeTypeDescription,
GeneralizedTime, INTEGER, and ObjectClassDescription.
In these syntax definitions the following productions this attribute should
return an appropriate error code if it is present in the attribute list.
This attribute will generally not be used:
<DirectoryStrings> ::= <DirectoryString> | '(' <DirectoryStringList> ')'
<DirectoryStringList> ::= <DirectoryStringList> <DirectoryString> | ""
<DirectoryString> ::= ''' <dstring> '''
<oids> ::= <oid> | '(' <oidlist> ')'
<oidlist> ::= <oidlist> '$' <oid> | <oid>
7.1. present in the entry after the add
is completed.
6.2. Syntaxes
6.2.1. Standard Syntaxes
6.2.1.1. ACIItem
This syntax appears too complicated for a compact string representation
to be useful. Thus syntax will Clients should only request and servers should only return
values which use the the binary encoding, which
contains a BER DER encoding of the value. value, e.g.
"entryACI;binary".
It is recommended that clients that wish to only determine whether they
have been granted permission to modify an entry use the modifyRightsReq field in the SearchRequest, "modifyRights"
attribute rather than attempt to parse this syntax.
7.2. AccessPoint93
Values with AccessPoint93 syntax are encoded according to the
following BNF:
INTERNET-DRAFT LDAPv3
Page 27
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
<AccessPoint93> ::= ( '(' <DistinguishedName> '#'
<PresentationAddress> ')' ) |
-- Optional protocol info absent, parenthesis required
( '(' <DistinguishedName> '#'
<PresentationAddress> '#'
<SetOfProtocolInformation ')' )
<SetOfProtocolInformation> ::= <ProtocolInformation> |
'(' <ProtocolInformationList> ')'
<ProtocolInformationList> ::= <ProtocolInformation> |
<ProtocolInformation> '$'
<ProtocolInformationList>
7.3. AttributeTypeDescription
6.2.1.2. AccessPoint
Values with this AccessPoint syntax are encoded according to the
following BNF:
<AttributeTypeDescription> ::= "("
<oid> -- AttributeType identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
[ "SUP" <oid> ] -- derived from this AttributeType
[ "EQUALITY" <oid> ] -- MatchingRule
[ "ORDERING" <oid> ] -- MatchingRule
[ "SUBSTR" <oid> ] -- MatchingRule
[ "SYNTAX" <DirectoryString> ]
[ "SINGLE-VALUE" ] -- default multi-valued
[ "COLLECTIVE" ] -- default not collective
[ "NO-USER-MODIFICATION" ] -- default user modifiable
[ "USAGE" <AttributeUsage> ] -- default user applications
")"
<AttributeUsage>
<AccessPoint> ::=
"userApplications"
| "directoryOperation"
| "distributedOperation" -- DSA-shared ( '(' <DistinguishedName> '#'
<PresentationAddress> ')' ) | "dSAOperation"
-- DSA-specific
For example, Optional protocol info absent, parenthesis required
( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' '(' <DistinguishedName> '#'
<PresentationAddress> '#'
<SetOfProtocolInformation ')' )
7.4.
<SetOfProtocolInformation> ::= <ProtocolInformation> |
'(' <ProtocolInformationList> ')'
<ProtocolInformationList> ::= <ProtocolInformation> |
<ProtocolInformation> '$'
<ProtocolInformationList>
6.2.1.3. DITContentRuleDescription
Values with this syntax are encoded according to the following BNF:
<DITContentRuleDescription> ::= "("
<oid> -- Structural ObjectClass identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
[ "AUX" <oids> ] -- Auxiliary ObjectClasses
[ "MUST" <oids> ] -- AttributeType identifiers
[ "MAY" <oids> ] -- AttributeType identifiers
[ "NOT" <oids> ] -- AttributeType identifiers
")"
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
7.5.
6.2.1.4. DITStructureRuleDescription
Values with this syntax are encoded according to the following BNF:
<DITStructureRuleDescription> ::= "("
<RuleIdentifier> -- DITStructureRule identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
"FORM" <oid> -- NameForm
[ "SUP" <RuleIdentifiers> ] -- superior DITStructureRules
")"
<RuleIdentifier> ::= <integer>
<RuleIdentifiers> ::=
<RuleIdentifier>
|
"(" <RuleIdentifierList> ")"
Page 28
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
<RuleIdentifierList> ::=
<RuleIdentifierList> <RuleIdentifier>
|
-- empty list
7.6.
6.2.1.5. DSEType
Values with DSEType syntax are encoded according to the following BNF:
<DSEType> ::= '(' <DSEBitList> ')'
<DSEBitList> ::= <DSEBit> | <DSEBit> '$' <DSEBitList>
<DSEBit> ::= 'root' | 'glue' | 'cp' | 'entry' | 'alias' | 'subr' |
'nssr' | 'supr' | 'xr' | 'admPoint' | 'subentry' |
'shadow' | 'zombie' | 'immSupr' 'immSupr' | 'rhob' | 'sa'
6.2.1.6. MasterAndShadowAccessPoints
Values of this syntax are encoded according to the following BNF:
<MasterAndShadowAccessPoints> ::= <MasterOrShadowAccessPoint> |
'(' <MasterAndShadowAccessPointList ')'
<MasterAndShadowAccessPointList> ::= <MasterOrShadowAccessPoint> |
<MasterOrShadowAccessPoint> '$' <MasterAndShadowAccessPointList>
<MasterOrShadowAccessPoint> ::= <category> '#' <AccessPoint>
<category> ::= 'master' | 'shadow'
6.2.1.7. MatchingRuleDescription
Values of this syntax are encoded according to the BNF of section 4.4.
6.2.1.8. MatchingRuleUseDescription
Values of this syntax are encoded according to the following BNF:
<MatchingRuleUseDescription> ::= "("
<oid> -- MatchingRule identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
"APPLIES" <oids> -- AttributeType identifiers
")"
Page 29
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
6.2.1.9. NameFormDescription
Values of this syntax are encoded according to the following BNF:
<NameFormDescription> ::= "("
<oid> -- NameForm identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
"OC" <oid> -- Structural ObjectClass
"MUST" <oids> -- AttributeTypes
[ "MAY" <oids> ] -- AttributeTypes
")"
6.2.1.10. SubtreeSpecification
Values of this syntax are encoded according to the following BNF:
<SubtreeSpecification> ::= '(' [<localname>] '#'
[<exclusionlist>] '#'
[<minimum>] '#' [<maximum>] '#'
[<refinement>] ')'
<localname> ::= <DistinguishedName>
<exclusionlist> ::= '(' <exclusions> ')'
<exclusions> ::= <exclusion> | <exclusion> '$' <exclusionlist>
<exclusion> ::= ( 'before ' <DistinguishedName> ) |
( 'after ' <DistinguishedName> )
<minimum> ::= <numericstring>
<maximum> ::= <numericstring>
<refinement> ::= <oid> | '!' <refinement> | 'rhob'
'( &' <refinements> ')' | 'sa'
'( |' <refinements> ')'
<refinements> ::= <refinement> |
'dsSubentry'
7.7. GeneralizedTime <refinement> '$' <refinements>
6.2.1.11. SupplierInformation
Values of this syntax are encoded as printable strings, represented
as specified in X.208. Note that the time zone must be specified.
For example,
199412161032Z
7.8. INTEGER
Values with INTEGER syntax are encoded as the decimal representation
of their values, with each decimal digit represented by the its
character equivalent. So according to the digit 1 following BNF:
<SupplierInformation> ::=
-- supplier is represented by the character
"1".
INTERNET-DRAFT LDAPv3 master --
'(' 'master' '#' <SupplierOrConsumer> ')' |
-- supplier is not master, master unspecified --
'(' 'shadow' '#' <SupplierOrConsumer> ')' |
-- supplier not master, master specified --
['('] 'shadow' '#' <SupplierOrConsumer> '#' <AccessPoint> [')']
Page 30
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
7.9. MasterAndShadowAccessPoints
6.2.1.12. SupplierOrConsumer
Values of this syntax are encoded according to the following BNF:
<MasterAndShadowAccessPoints>
<SupplierOrConsumer> ::= <MasterOrShadowAccessPoint> |
'(' <MasterAndShadowAccessPointList ')'
<MasterAndShadowAccessPointList> <Agreement> '#' <AccessPoint>
<Agreement> ::= <MasterOrShadowAccessPoint> |
<MasterOrShadowAccessPoint> '$' <MasterAndShadowAccessPointList>
<MasterOrShadowAccessPoint> <bindingid> '.' <bindingversion>
<bindingid> ::= <category> '#' <AccessPoint93>
<category> <numericstring>
<bindingversion> ::= 'master' | 'shadow'
7.10. MatchingRuleDescription <numericstring>
6.2.1.13. SupplierAndConsumers
Values of this syntax are encoded according to the following BNF:
<MatchingRuleDescription>
<SupplierAndConsumers> ::= <Supplier> '#' <Consumers>
<Suppliers> ::= <AccessPoint>
<Consumers> ::= <AccessPoint> | '(' <AccessPointList> ')'
<AccessPointList> ::= <AccessPoint> |
<AccessPoint> '$' <AccessPointList>
6.2.1.14. ProtocolInformation
A value with the ProtocolInformation syntax is encoded according to the
following BNF:
<ProtocolInformation> ::= <NetworkAddress> <space> '#'
<SetOfProtocolIdentifier>
<NetworkAddress> ::= As appears in PresentationAddress
<SetOfProtocolIdentifiers> ::= <ProtocolIdentifier> |
'(' <ProtocolIdentifiers> ')'
<ProtocolIdentifiers> ::= <ProtocolIdentifier> |
<ProtocolIdentifier> '$' <ProtocolIdentifiers>
<ProtocolIdentifier> ::= "(" <oid> -- MatchingRule identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
"SYNTAX" <DirectoryString>
")"
7.11. MatchingRuleUseDescription
Values
For example,
NS+12345678 # 1.2.3.4.5
6.2.2. LDAP-defined Syntaxes
There is currently one syntax defined here.
Page 31
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
6.2.2.1 ModifyRight
This syntax is a printable encoding of this the following ASN.1 data type:
ModifyRight ::= SEQUENCE {
item CHOICE {
entry [0] NULL,
attribute [1] AttributeType,
value [2] AttributeValueAssertion },
permission [3] BIT STRING { add(0), remove(1), rename(2), move(3) } }
The syntax are is encoded according to the following BNF:
<MatchingRuleUseDescription>
<ModifyRight> ::= "("
<oid> [<perm-list>] <octo> <item>
-- MatchingRule identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
"APPLIES" <oids> perm list is absent when none of the bits set in permission
<item> ::= <entry> | <attribute> | <value>
<entry> ::= 'entry'
<attribute> ::= 'attribute' <dollar> <attributetype>
<value> ::= 'value' <dollar> <attributetype> <dollar> <strvalue>
-- AttributeType identifiers
")"
7.12. NameFormDescription
Values <strvalue> is the string encoding of this syntax are encoded according to the following BNF:
<NameFormDescription> value
<perm-list> ::= "("
<oid> <perm> | <perm> <dollar> <perm-list>
-- NameForm identifier one or more of the bits in permission, if set
<perm> ::= 'add' | 'remove' | 'rename' | 'move'
<octo> ::= [ "NAME" <DirectoryStrings> <whsp> ] '#' [ "DESC" <DirectoryString> <whsp> ]
<dollar> ::= [ "OBSOLETE" <whsp> ]
"OC" <oid> -- Structural ObjectClass
"MUST" <oids> -- AttributeTypes '$' [ "MAY" <oids> <whsp> ] -- AttributeTypes
")"
7.13. ObjectClassDescription
Values of this syntax are encoded according to the
For example,
# entry
add $ remove # attribute $ cn
add $ remove # attribute $ sn
remove # value $ memberName $ CN=Babs, O=Michigan, C=US
6.3. Object Classes
The following BNF:
INTERNET-DRAFT LDAPv3 object classes should be recognized.
( 2.5.17.0 NAME 'subentry' SUP top STRUCTURAL
MUST ( cn $ subtreeSpecification ) )
( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) )
Page 32
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
<ObjectClassDescription> ::= "("
<oid> -- ObjectClass identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
[ "SUP" <oids> ] -- Superior ObjectClasses
[
6.4. Matching Rules
Only servers which implement the attribute types which reference these
matching rules in their definition are required to implement these rules.
The definitions of the rules can be found in [2] and [3].
Name OID
===================================== ===========
caseIgnoreOrderingMatch 2.5.13.3
caseIgnoreSubstringsMatch 2.5.13.4
caseExactMatch 2.5.13.5
caseExactOrderingMatch 2.5.13.6
caseExactSubstringsMatch 2.5.13.7
numericStringOrderingMatch 2.5.13.9
numericStringSubstringsMatch 2.5.13.10
caseIgnoreListSubstringsMatch 2.5.13.12
booleanMatch 2.5.13.13
integerOrderingMatch 2.5.13.15
octetStringOrderingMatch 2.5.13.18
octetStringSubstringsMatch 2.5.13.19
telephoneNumberSubstringsMatch 2.5.13.21
presentationAddressMatch 2.5.13.22
uniqueMemberMatch 2.5.13.23
protocolInformationMatch 2.5.13.24
uTCTimeMatch 2.5.13.25
uTCTimeOrderingMatch 2.5.13.26
generalizedTimeOrderingMatch 2.5.13.28
integerFirstComponentMatch 2.5.13.29
objectIdentifierFirstComponentMatch 2.5.13.30
directoryStringFirstComponentMatch 2.5.13.31
wordMatch 2.5.13.32
keywordMatch 2.5.13.33
accessPointMatch 2.5.14.0
masterAndShadowAccessPointsMatch 2.5.14.1
supplierOrConsumerInformationMatch 2.5.14.2
supplierAndConsumersMatch 2.5.14.3
6.5. Other
The string 'excludeAllCollectiveAttributes' is defined as a synonym
for the OID 2.5.18.0. It would typically be used as a value of the
collectiveExclusions attribute.
7. Optional Definitions
7.1. Attribute Types
7.1.1. Obsolete Attributes
Implementors should use modifyTimestamp and modifiersName instead.
( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime' OBSOLETE
SYNTAX 'UTCTime' ) ] -- default structural
[ "MUST" <oids> ] -- AttributeTypes
[ "MAY" <oids> ] -- AttributeTypes
")"
7.14. SubtreeSpecification
( 0.9.2342.19200300.100.1.24 NAME 'lastModifiedBy' OBSOLETE
EQUALITY distinguishedNameMatch SYNTAX 'DN' )
Page 33
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions August 1996
7.2. Syntaxes
7.2.1 MHSORAddress
Values of this syntax type MHSORAddress are encoded as strings, according to
the format defined in [10].
7.2.2 DLSubmitPermission
Values of type DLSubmitPermission are encoded as strings, according
to the following BNF:
<SubtreeSpecification> ::= '(' [<localname>] '#'
[<exclusionlist>] '#'
[<minimum>] '#' [<maximum>] '#'
[<refinement>] ')'
<localname> ::= <DistinguishedName>
<exclusionlist> ::= '(' <exclusions> ')'
<exclusions>
<dlsubmit-perm> ::= <exclusion> <dlgroup_label> ':' <dlgroup-value>
| <exclusion> '$' <exclusionlist>
<exclusion> <dl-label> ':' <dl-value>
<dlgroup-label> ::= ( 'before ' <DistinguishedName> ) |
( 'after ' <DistinguishedName> )
<minimum> 'group_member'
<dlgroup-value> ::= <numericstring>
<maximum> <name>
<name> ::= <numericstring>
<refinement> an encoded Distinguished Name
<dl-label> ::= <oid> | '!' <refinement> 'individual' |
'( &' <refinements> ')' 'dl_member' |
'( |' <refinements> ')'
<refinements> 'pattern'
<dl-value> ::= <refinement> | <refinement> '$' <refinements>
7.15. SupplierInformation
Values of this syntax are encoded according to the following BNF:
<SupplierInformation> <orname>
<orname> ::=
-- supplier is master --
'(' 'master' <address> '#' <SupplierOrConsumer> ')' <dn>
|
-- supplier <address>
<address> ::= <add-label> ':' <oraddress>
<dn> ::= <dn-label> ':' <name>
<add-label> = 'X400'
<dn-label> = 'X500'
where <oraddress> is as defined in RFC 1327.
7.3. Object Classes
7.3.1. Obsolete Classes
( 0.9.2342.19200300.100.4.22 NAME 'oldQualityLabelledData' SUP top
STRUCTURAL MUST dSAQuality
MAY ( subtreeMaximumQuality $ subtreeMinimumQuality ) )
The oldQualityLabelledData object class is historical and should not master, master unspecified --
'(' 'shadow' '#' <SupplierOrConsumer> ')' |
-- supplier not master, master specified --
['('] 'shadow' '#' <SupplierOrConsumer> '#' <AccessPoint93> [')']
INTERNET-DRAFT LDAPv3 be
used for defining new objects.
7.3.2. extensibleObject
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
Page 34
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
7.16. SupplierOrConsumer
Values
This class, if present in an entry, permits that entry to optionally
hold any attribute. The MAY attribute list of this syntax are encoded according class is implicitly
the set of all attributes known to the following BNF:
<SupplierOrConsumer> ::= <Agreement> '#' <AccessPoint93>
<Agreement> ::= <bindingid> '.' <bindingversion>
<bindingid> ::= <numericstring>
<bindingversion> ::= <numericstring>
7.17. SupplierAndConsumers
Values server. The mandatory attributes
of the other object classes of this syntax entry are encoded according still required to the following BNF:
<SupplierAndConsumers> ::= <Supplier> '#' <Consumers>
<Suppliers> ::= <AccessPoint93>
<Consumers> ::= <AccessPoint93> | '(' <AccessPointList> ')'
<AccessPointList> ::= <AccessPoint93> |
<AccessPoint93> '$' <AccessPointList> be
present.
Note that not all servers will implement this object class, and those
which do not will reject requests to add entries which contain this
object class, or modify an entry to add this object class.
7.4. Matching Rules
7.4.1. caseIgnoreIA5SubstringsMatch
( 1.3.6.1.4.1.1466.109.114.3
NAME 'caseIgnoreIA5SubstringsMatch' SYNTAX 'IA5String' )
This matching rule may be used to compare components of an IA5 string
against an attribute whose values have IA5 string syntax.
8. Security Considerations
Security issues are not discussed in this memo.
9. Acknowledgements
This document is based heavily substantially on RFC 1778, written by Tim Howes,
Steve Kille, Wengyik Yeong and Colin Robbins.
Many of the attribute syntax encodings defined in this document are
adapted from those used in the QUIPU and the IC R3 X.500
implementations. The contributions of the authors of both these
implementations in the specification of syntaxes in this document are
gratefully acknowledged.
10. Authors Addresses
Mark Wahl
ISODE Consortium
Critical Angle Inc.
3925
4815 West Braker Lane, Suite 333 Lane #502-385
Austin, TX 78759
USA
Phone: +1 512-305-0280
EMail: M.Wahl@isode.com M.Wahl@critical-angle.com
Andy Coulbeck
ISODE Consortium
The Dome, The Square
Richmond TW9 1DT
United Kingdom
INTERNET-DRAFT LDAPv3
Phone: +44 181-332-9091
EMail: A.Coulbeck@isode.com
Page 35
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
Phone: +44 181-332-9091
EMail: A.Coulbeck@isode.com
Tim Howes
Netscape Communications Corp.
685
501 E. Middlefield Rd
Mountain View, CA 94043
USA
Phone: +1 415 254-1900
EMail: howes@netscape.com
Steve Kille
ISODE Consortium
The Dome, The Square
Richmond
TW9 1DT
UK
Phone: +44-181-332-9091
EMail: S.Kille@isode.com
11. Bibliography
[1] M.Wahl, W. Yeong, M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
(Version 3)". <draft-ietf-asid-ldapv3-protocol-03.txt> 3)", INTERNET DRAFT <draft-ietf-asid-ldapv3-protocol-02.txt>,
August 1996.
[2] The Directory: Selected Attribute Types. ITU-T Recommendation
X.520, 1993.
[3] The Directory: Models. ITU-T Recommendation X.501, 1993.
[4] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
1274, November 1991.
[5] M. Wahl, S. Kille, S., "A UTF-8 String Representation of Distinguished
Names", RFC
1779, ISODE Consortium, March 1995. INTERNET DRAFT <draft-ietf-asid-ldapv3-dn-00.txt>, August 1996.
[6] S. Kille, S., "A String Representation for Presentation Addresses",
RFC 1278, University College London, November 1991.
[7] Terminal Equipment and Protocols for Telematic Services -
Standardization of Group 3 facsimile apparatus for document
transmission. CCITT, Recommendation T.4.
[8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-
Cube
C-Cube Microsystems, Milpitas, CA, September 1, 1992.
INTERNET-DRAFT LDAPv3
[9] The Directory: Selected Object Classes. ITU-T Recommendation
X.521, 1993.
[10] H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson,
"Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
August 1993.
[11] M. Davis, UTF-8, (WG2 N1036) DAM for ISO/IEC 10646-1.
[12] Universal Multiple-Octet Coded Character Set (UCS) - Architecture
and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993.
Page 36
INTERNET DRAFT LDAP Standard and Pilot Attribute Definitions June August 1996
Appendix A- Object Classes
Descriptor X.500 OID Value
============================== ===========================
top 2.5.6.0
alias 2.5.6.1
country 2.5.6.2
locality 2.5.6.3
organization 2.5.6.4
organizationalUnit 2.5.6.5
person 2.5.6.6
organizationalPerson 2.5.6.7
organizationalRole 2.5.6.8
groupOfNames 2.5.6.9
residentialPerson 2.5.6.10
applicationProcess 2.5.6.11
applicationEntity 2.5.6.12
dSA 2.5.6.13
device 2.5.6.14
strongAuthenticationUser 2.5.6.15
certificationAuthority 2.5.6.16
groupOfUniqueNames 2.5.6.17
pilotObject 0.9.2342.19200300.100.4.3
newPilotPerson 0.9.2342.19200300.100.4.4
account 0.9.2342.19200300.100.4.5
document 0.9.2342.19200300.100.4.6
room 0.9.2342.19200300.100.4.7
documentSeries 0.9.2342.19200300.100.4.9
domain 0.9.2342.19200300.100.4.13
rFC822localPart 0.9.2342.19200300.100.4.14
dNSDomain 0.9.2342.19200300.100.4.15
domainRelatedObject 0.9.2342.19200300.100.4.17
friendlyCountry 0.9.2342.19200300.100.4.18
simpleSecurityObject 0.9.2342.19200300.100.4.19
pilotOrganization 0.9.2342.19200300.100.4.20
pilotDSA 0.9.2342.19200300.100.4.21
qualityLabelledData 0.9.2342.19200300.100.4.23
Appendix B.
[13] The Directory: Authentication Framework. ITU-T Recommendation
X.509 (1993).
[14] Abstract Syntax Notation One (ASN.1) - Other OID descriptors
In addition, servers should recognize at the minimum the following
descriptors as prefixes of other OIDs, e.g. "enterprises.453.13.3".
Clients should attempt to ensure that any OIDs they transmit are in
terms Specification of only these descriptors, with additional components in numeric
form.
Descriptor Value
============================== ===========================
ccitt 0
iso 1
joint 2
identifiedOrganization 1.3
dod 1.3.6
internet 1.3.6.1
private 1.3.6.1.4
enterprises 1.3.6.1.4.1
<draft-ietf-asid-ldapv3-attributes-01.txt> Basic
Notation. ITU-T Recommendation X.680, 1994.
<draft-ietf-asid-ldapv3-attributes-02.txt>
Expires: December 5, 1996
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996 March 2, 1997
Page 37
----