One document matched: draft-ietf-asid-ldapv3-attributes-01.txt
Differences from draft-ietf-asid-ldapv3-attributes-00.txt
Network Working Group M. Wahl
INTERNET-DRAFT ISODE Consortium
Obsoletes: RFC 1778 A. Coulbeck
ISODE Consortium
T. Howes
Netscape Communications Corp.
S. Kille
ISODE Consortium
Expires in six months from 5 June 1996
Intended Category: Standards Track
Lightweight Directory Access Protocol:
Standard and Pilot Attribute Definitions
<draft-ietf-asid-ldapv3-attributes-01.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 LDAP Attributes
This section lists all Attribute Type names defined for this version of
LDAP. Servers may support additional names and attributes not listed
here. Later documents may define additional types.
3.1 Standard User Attributes
The attributes listed in this section are those defined in X.520(1993),
likely to be present in user entries. Servers must recognize all the
attributes 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 Standard and Pilot Attribute Definitions June 1996
3.2. Pilot User Attributes
These attributes are 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 attribute subentries, but may
be visible in user entries if requested. Servers which do not support
the X.500 protocols are not required to recognize these attributes, and
non-management clients should not assume they are recognized by 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 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 of 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 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
syntax encodings. All documents defining attribute syntax encodings for
use with LDAP are expected to conform to these requirements.
The encoding rules defined for a given attribute syntax must produce
octet strings. To 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 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>
<utf8> ::= any sequence of octets formed from the UTF-8 transformation
of a BMP character
<dstring> ::= <utf8> | <utf8> <dstring>
4.2. Undefined and Binary
Values of types not described 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 of the value. This encoding format is also used if the
binary encoding is requested by the client for an attribute.
All servers must be capable of supporting this form for both generating
Search results and parsing Add and Modify requests.
5. Standard User Attribute Syntax Encodings
Servers must recognize all the syntaxes described in this section.
5.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
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
5.2. PrintableString
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 are mapped directly, those which
correspond to ISO-8859-1 are transliterated, and those for which there
is no direct mapping are replaced by a IA5 description of the glyph.
If it is of the UniversalString or BMPString form, UTF-8 is used to
encode them.
5.4. Certificate
Because of the changes from X.509(1988) and X.509(1993) and additional
planned changes to the syntax to support certificate extensions, no
string representation is defined, and values with Certificate syntax
(userCertificate and caCertificate) are only transferred using
a binary encoding. The BNF notation in RFC 1778 for "User Certificate"
is not permitted.
5.5. CertificateList
Because of the incompatibility of the X.509(1988) and X.509(1993)
definitions of revocation lists, values with CertificateList syntax
(certificateRevocationList and authorityRevocationList) are only
transferred using a binary encoding. The BNF notation in RFC 1778
for "Authority Revocation List" is not permitted.
5.6. CertificatePair
Because the Certificate is being carried in binary, values with
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
DirectoryString syntax.
5.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.
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
5.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.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.
5.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.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> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
[ '(' ] <criteria> '|' <criteria-set> [ ')' ]
<criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
<match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
5.13. NameAndOptionalUID
The encoding of a value with the NameAndOptionalUID syntax is according
to the following BNF:
<NameAndOptionalUID> ::=
<DistinguishedName> [ '#' <BitString> ]
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 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, which should be used
in preference to the third wherever possible. 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. For example, in encoding the object
identifier representing an organizationName, the descriptor
"organizationName" is preferable to "ds.4.10", which is in turn
preferable to the string "2.5.4.10". A list 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 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 are recommended in X.520 to
be 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 Standard and Pilot Attribute Definitions June 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
TELEX terminal.
5.23. UTCTime
Values with UTCTime syntax are encoded as if they were printable
strings with the strings containing a UTCTime value.
5.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.
6. Pilot Attribute Syntax Encodings
Servers must recognize all the syntaxes described in this section.
6.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.
6.2. CaseIgnoreIA5String
The encoding of a value with CaseIgnoreIA5String syntax is the string
value itself.
6.3. CaseIgnoreString
The encoding of a value with CaseIgnoreString syntax is the same as the
encoding of a value with DirectoryString syntax.
6.4. 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
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 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 of a value with IA5String syntax is the string value
itself.
6.7. JPEG
Values with JPEG syntax are encoded as if they were octet strings
containing JPEG images in the JPEG File Interchange Format (JFIF), as
described in [8].
6.8. MailPreference
Values with MailPreference syntax are encoded according to the
following BNF:
<mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
6.9. 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>.
6.10. Fax
Values with Fax syntax are encoded as if they were octet strings
containing Group 3 Fax images as defined in [7].
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
6.11. CaseIgnoreList
Values with CaseIgnoreList syntax are encoded according to the
following BNF:
<caseignorelist> ::= <caseignorestring> |
<caseignorestring> '$' <caseignorelist>
<caseignorestring> ::= a string encoded according to the rules for
DirectoryString as above.
6.12. CaseExactList
Values with CaseExactList syntax are encoded according to the
following BNF:
<caseexactlist> ::= <caseexactstring> |
<caseexactstring> '$' <caseexactlist>
<caseexactstring> ::= a string encoded according to the rules for
DirectoryString as above.
7. Standard Operational Attribute Syntax Encodings
All servers must recognize the syntaxes of AttributeTypeDescription,
GeneralizedTime, INTEGER, and ObjectClassDescription.
In these syntax definitions the following productions should be used:
<DirectoryStrings> ::= <DirectoryString> | '(' <DirectoryStringList> ')'
<DirectoryStringList> ::= <DirectoryStringList> <DirectoryString> | ""
<DirectoryString> ::= ''' <dstring> '''
<oids> ::= <oid> | '(' <oidlist> ')'
<oidlist> ::= <oidlist> '$' <oid> | <oid>
7.1. ACIItem
This syntax appears too complicated for a compact string representation
be useful. Thus syntax will use the the binary encoding, which
contains a BER encoding of the value. 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,
rather than attempt to parse this syntax.
7.2. AccessPoint93
Values with AccessPoint93 syntax are encoded according to the
following BNF:
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
<AccessPoint93> ::= ( '(' <DistinguishedName> '#'
<PresentationAddress> ')' ) |
-- Optional protocol info absent, parenthesis required
( '(' <DistinguishedName> '#'
<PresentationAddress> '#'
<SetOfProtocolInformation ')' )
<SetOfProtocolInformation> ::= <ProtocolInformation> |
'(' <ProtocolInformationList> ')'
<ProtocolInformationList> ::= <ProtocolInformation> |
<ProtocolInformation> '$'
<ProtocolInformationList>
7.3. AttributeTypeDescription
Values with this 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> ::=
"userApplications"
| "directoryOperation"
| "distributedOperation" -- DSA-shared
| "dSAOperation" -- DSA-specific
For example,
( 2.5.4.0 NAME 'objectClass' SYNTAX 'OID' )
7.4. 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. 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> ")"
<RuleIdentifierList> ::=
<RuleIdentifierList> <RuleIdentifier>
|
-- empty list
7.6. 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' | 'rhob' | 'sa' |
'dsSubentry'
7.7. 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
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 the digit 1 is represented by the character
"1".
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
7.9. MasterAndShadowAccessPoints
Values of this syntax are encoded according to the following BNF:
<MasterAndShadowAccessPoints> ::= <MasterOrShadowAccessPoint> |
'(' <MasterAndShadowAccessPointList ')'
<MasterAndShadowAccessPointList> ::= <MasterOrShadowAccessPoint> |
<MasterOrShadowAccessPoint> '$' <MasterAndShadowAccessPointList>
<MasterOrShadowAccessPoint> ::= <category> '#' <AccessPoint93>
<category> ::= 'master' | 'shadow'
7.10. MatchingRuleDescription
Values of this syntax are encoded according to the following BNF:
<MatchingRuleDescription> ::= "("
<oid> -- MatchingRule identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
"SYNTAX" <DirectoryString>
")"
7.11. 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
")"
7.12. 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
")"
7.13. ObjectClassDescription
Values of this syntax are encoded according to the following BNF:
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
<ObjectClassDescription> ::= "("
<oid> -- ObjectClass identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
[ "SUP" <oids> ] -- Superior ObjectClasses
[ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] -- default structural
[ "MUST" <oids> ] -- AttributeTypes
[ "MAY" <oids> ] -- AttributeTypes
")"
7.14. 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> |
'( &' <refinements> ')' |
'( |' <refinements> ')'
<refinements> ::= <refinement> | <refinement> '$' <refinements>
7.15. SupplierInformation
Values of this syntax are encoded according to the following BNF:
<SupplierInformation> ::=
-- supplier is master --
'(' 'master' '#' <SupplierOrConsumer> ')' |
-- supplier is not master, master unspecified --
'(' 'shadow' '#' <SupplierOrConsumer> ')' |
-- supplier not master, master specified --
['('] 'shadow' '#' <SupplierOrConsumer> '#' <AccessPoint93> [')']
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
7.16. SupplierOrConsumer
Values of this syntax are encoded according to the following BNF:
<SupplierOrConsumer> ::= <Agreement> '#' <AccessPoint93>
<Agreement> ::= <bindingid> '.' <bindingversion>
<bindingid> ::= <numericstring>
<bindingversion> ::= <numericstring>
7.17. SupplierAndConsumers
Values of this syntax are encoded according to the following BNF:
<SupplierAndConsumers> ::= <Supplier> '#' <Consumers>
<Suppliers> ::= <AccessPoint93>
<Consumers> ::= <AccessPoint93> | '(' <AccessPointList> ')'
<AccessPointList> ::= <AccessPoint93> |
<AccessPoint93> '$' <AccessPointList>
8. Security Considerations
Security issues are not discussed in this memo.
9. Acknowledgements
This document is based heavily 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 Inc.
3925 West Braker Lane, Suite 333
Austin, TX 78759
USA
Phone: +1 512-305-0280
EMail: M.Wahl@isode.com
Andy Coulbeck
ISODE Consortium
The Dome, The Square
Richmond TW9 1DT
United Kingdom
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
Phone: +44 181-332-9091
EMail: A.Coulbeck@isode.com
Tim Howes
Netscape Communications Corp.
685 Middlefield
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, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (Version 3)". <draft-ietf-asid-ldapv3-protocol-03.txt>
[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] Kille, S., "A String Representation of Distinguished Names", RFC
1779, ISODE Consortium, March 1995.
[6] 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 Microsystems, Milpitas, CA, September 1, 1992.
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 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. - 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 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> Expires: December 5, 1996
INTERNET-DRAFT LDAPv3 Standard and Pilot Attribute Definitions June 1996
| PAFTECH AB 2003-2026 | 2026-04-22 23:26:35 |