draft-ietf-asid-ldapv3-attributes-05.txt   draft-ietf-asid-ldapv3-attributes-06.txt 
Network Working Group M. Wahl Network Working Group M. Wahl
INTERNET-DRAFT Critical Angle Inc. INTERNET-DRAFT Critical Angle Inc.
Obsoletes: RFC 1778 A. Coulbeck Obsoletes: RFC 1778 A. Coulbeck
Isode Limited Isode Inc.
T. Howes T. Howes
Netscape Communications Corp. Netscape Communications Corp.
S. Kille S. Kille
Isode Limited Isode Limited
Lightweight Directory Access Protocol (v3): Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions Attribute Syntax Definitions
<draft-ietf-asid-ldapv3-attributes-05.txt> <draft-ietf-asid-ldapv3-attributes-06.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 70 skipping to change at line 70
objects as directory entries. objects as directory entries.
4. General Issues 4. General Issues
This document describes encodings used in an Internet protocol. This document describes encodings used in an Internet protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [4]. this document are to be interpreted as described in RFC 2119 [4].
Attribute Type and Object Class definitions are written in a
string representation of the AttributeTypeDescription and
ObjectClassDescription data types defined in X.501(93) [3].
Implementors are strongly advised to first read the description
of how schema is represented in X.500 before reading the rest of
this document.
4.1. Common Encoding Aspects 4.1. Common Encoding Aspects
For the purposes of defining the encoding rules for attribute For the purposes of defining the encoding rules for attribute
syntaxes, the following BNF definitions will be used. They are syntaxes, the following BNF definitions will be used. They are
based on the BNF styles of RFC 822 [13]. based on the BNF styles of RFC 822 [13].
a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
"j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
"s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
"B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
skipping to change at line 176 skipping to change at line 183
AttributeTypeDescription = "(" whsp AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType [ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description [ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ] [ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other [ "SUP" woid ] ; derived from this other
; AttributeType ; AttributeType
[ "EQUALITY" woid ; Matching Rule name [ "EQUALITY" woid ; Matching Rule name
[ "ORDERING" woid ; Matching Rule name [ "ORDERING" woid ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name [ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp numericoid whsp ] ; see section 4.2 [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
[ "SINGLE-VALUE" whsp ] ; default multi-valued [ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective [ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default user applications [ "USAGE" whsp AttributeUsage ]; default user applications
whsp ")" whsp ")"
AttributeUsage = AttributeUsage =
"userApplications" / "userApplications" /
"directoryOperation" / "directoryOperation" /
"distributedOperation" / ; DSA-shared "distributedOperation" / ; DSA-shared
skipping to change at line 205 skipping to change at line 212
section 5. Servers MUST be able to evaluate presence filters, section 5. Servers MUST be able to evaluate presence filters,
SHOULD be able to perform equality matching of values of all user SHOULD be able to perform equality matching of values of all user
attributes known to the server, and MAY be able to perform matching attributes known to the server, and MAY be able to perform matching
with the other kinds of filters. If a server allows values of an with the other kinds of filters. If a server allows values of an
attribute of a particular type to be added or removed over protocol, attribute of a particular type to be added or removed over protocol,
the server MUST be able to perform equality matching of values of the server MUST be able to perform equality matching of values of
that attribute, but need not perform any additional validity checks that attribute, but need not perform any additional validity checks
on attribute values. on attribute values.
Servers MAY recognize additional names and attributes not listed in Servers MAY recognize additional names and attributes not listed in
this document, and if they do so, SHOULD publish the definitions of this document, and if they do so, MUST publish the definitions of
the types in the attributeTypes attribute of their subschema the types in the attributeTypes attribute of their subschema
entries. entries.
Schema developers MUST NOT create attribute definitions whose names
conflict with attributes defined for use with LDAP in existing
standards-track RFCs.
AttributeDescriptions can be used as the value in a NAME part of an AttributeDescriptions can be used as the value in a NAME part of an
AttributeTypeDescription. Note that these are case insensitive. AttributeTypeDescription. Note that these are case insensitive.
Note that the AttributeTypeDescription does not list the matching Note that the AttributeTypeDescription does not list the matching
rules which can can be used with that attribute type in an rules which can can be used with that attribute type in an
extensibleMatch search filter. This is done using the matchingRuleUse extensibleMatch search filter. This is done using the matchingRuleUse
attribute described in section 4.4. attribute described in section 4.5.
4.2. Syntaxes This document refines the schema description of X.501 by requiring
that the syntax field in an AttributeTypeDescription be a string
representation of an OBJECT IDENTIFIER for the LDAP string syntax
definition, and an optional indication of the maximum length of
a value of this attribute.
4.3. Syntaxes
This section defines general requirements for LDAP attribute value This section defines general requirements for LDAP attribute value
syntax encodings. All documents defining attribute syntax encodings syntax encodings. All documents defining attribute syntax encodings
for use with LDAP are expected to conform to these requirements. for use with LDAP are expected to conform to these requirements.
The encoding rules defined for a given attribute syntax must produce The encoding rules defined for a given attribute syntax must produce
octet strings. To the greatest extent possible, encoded octet octet strings. To the greatest extent possible, encoded octet
strings should be usable in their native encoded form for display strings should be usable in their native encoded form for display
purposes. In particular, encoding rules for attribute syntaxes purposes. In particular, encoding rules for attribute syntaxes
defining non-binary values should produce strings that can be defining non-binary values should produce strings that can be
skipping to change at line 244 skipping to change at line 261
production (other than a Distinguished Name), a backslash quoting production (other than a Distinguished Name), a backslash quoting
mechanism is used to encode the following separator symbol character mechanism is used to encode the following separator symbol character
(such as "'", "$" or "#") if it should occur in that string. The (such as "'", "$" or "#") if it should occur in that string. The
backslash is followed by a pair of hexadecimal digits representing the backslash is followed by a pair of hexadecimal digits representing the
next character. A backslash itself in the string which forms part of next character. A backslash itself in the string which forms part of
a larger syntax is always transmitted as '\5C' or '\5c'. a larger syntax is always transmitted as '\5C' or '\5c'.
Syntaxes are also defined for matching rules whose assertion value Syntaxes are also defined for matching rules whose assertion value
syntax is different from the attribute value syntax. syntax is different from the attribute value syntax.
4.2.1 Binary Transfer of Values 4.3.1 Binary Transfer of Values
This encoding format is used if the binary encoding is requested by This encoding format is used if the binary encoding is requested by
the client for an attribute, or if the attribute syntax name is the client for an attribute, or if the attribute syntax name is
"1.3.6.1.4.1.1466.115.121.1.5". The value, an instance of the ASN.1 "1.3.6.1.4.1.1466.115.121.1.5". The value, an instance of the ASN.1
AttributeValue type, is BER-encoded, subject to the restrictions of AttributeValue type, is BER-encoded, subject to the restrictions of
section 5.1 of [1], and this sequence of octets is used as the value. section 5.1 of [1], and this sequence of octets is used as the value.
(E.g. the first byte inside the OCTET STRING wrapper is a tag byte. (E.g. the first byte inside the OCTET STRING wrapper is a tag byte.
However the OCTET STRING is still encoded in primitive form.) However the OCTET STRING is still encoded in primitive form.)
All servers MUST implement this form for both generating attribute All servers MUST implement this form for both generating attribute
values in search responses, and parsing attribute values in add, values in search responses, and parsing attribute values in add,
compare and modify requests, if the attribute type is recognized and compare and modify requests, if the attribute type is recognized and
the attribute syntax name is that of Binary. Clients which request the attribute syntax name is that of Binary. Clients which request
that all attributes be returned from entries MUST be prepared that all attributes be returned from entries MUST be prepared
to receive values in binary (e.g. userCertificate), and SHOULD NOT to receive values in binary (e.g. userCertificate), and SHOULD NOT
simply display binary or unrecognized values to users. simply display binary or unrecognized values to users.
4.2.2. Syntax Object Identifiers 4.3.2. Syntax Object Identifiers
Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which
are dotted-decimal strings. These are not intended to be displayed are dotted-decimal strings. These are not intended to be displayed
to users. to users.
noidlen = numericoid [ "{" len "}" ]
len = numericstring
The following table lists some of the syntaxes that have been defined The following table lists some of the syntaxes that have been defined
for LDAP thus far. The H-R column suggests whether a value in that for LDAP thus far. The H-R column suggests whether a value in that
syntax would likely be a human readable string. Clients and servers syntax would likely be a human readable string. Clients and servers
need not implement all the syntaxes listed here, and MAY implement need not implement all the syntaxes listed here, and MAY implement
other syntaxes. other syntaxes.
Other documents may define additional syntaxes. However, the Other documents may define additional syntaxes. However, the
definition of additional arbitrary syntaxes is strongly depreciated definition of additional arbitrary syntaxes is strongly depreciated
since it will hinder interoperability: today's client and server since it will hinder interoperability: today's client and server
implementations generally do not have the ability to dynamically implementations generally do not have the ability to dynamically
skipping to change at line 317 skipping to change at line 337
Guide Y 1.3.6.1.4.1.1466.115.121.1.25 Guide Y 1.3.6.1.4.1.1466.115.121.1.25
IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26 IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26
INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27 INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27
JPEG N 1.3.6.1.4.1.1466.115.121.1.28 JPEG N 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54
Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29 Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29
Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31
Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32 Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32
MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33 MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33
Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55
Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35
Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36 Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37
OID Y 1.3.6.1.4.1.1466.115.121.1.38 OID Y 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39
Password Y 1.3.6.1.4.1.1466.115.121.1.40 Password Y 1.3.6.1.4.1.1466.115.121.1.40
Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41 Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41
Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42 Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42
Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43 Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43
skipping to change at line 341 skipping to change at line 362
Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48 Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48
Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49 Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49
Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51
Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52 Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52
UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53 UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53
A suggested minimum upper bound on the number of characters in value A suggested minimum upper bound on the number of characters in value
with a string-based syntax, or the number of bytes in a value for all with a string-based syntax, or the number of bytes in a value for all
other syntaxes, may be indicated by appending this bound count inside other syntaxes, may be indicated by appending this bound count inside
of curly braces following the syntax name's OBJECT IDENTIFIER. This of curly braces following the syntax name's OBJECT IDENTIFIER in an
bound is not part of the syntax name itself. For instance, Attribute Type Description. This bound is not part of the syntax name
"1.3.6.4.1.1466.0{64}" suggests that server implementations should itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
allow the string to be 64 characters long, although they may allow implementations should allow a string to be 64 characters long,
longer strings. Note that a single character of the Directory String although they may allow longer strings. Note that a single character
syntax may be encoded in more than one byte since UTF-8 is a of the Directory String syntax may be encoded in more than one byte
variable-length encoding. since UTF-8 is a variable-length encoding.
4.2.3. Syntax Description 4.3.3. Syntax Description
The following BNF may be used to associate a short description with The following BNF may be used to associate a short description with
a syntax OBJECT IDENTIFIER. Implementors should note that future a syntax OBJECT IDENTIFIER. Implementors should note that future
versions of this document may expand this definition to include versions of this document may expand this definition to include
additional terms. additional terms.
SyntaxDescription = "(" whsp SyntaxDescription = "(" whsp
numericoid whsp numericoid whsp
[ "DESC" qdstring ] [ "DESC" qdstring ]
whsp ")" whsp ")"
4.3. Object Classes 4.4. Object Classes
The format for representation of object classes is defined in X.501 The format for representation of object classes is defined in X.501
[3]. In general every entry will contain an abstract class ("top" or [3]. In general every entry will contain an abstract class ("top" or
"alias"), at least one structural object class, and zero or more "alias"), at least one structural object class, and zero or more
auxiliary object classes. Whether an object class is abstract, auxiliary object classes. Whether an object class is abstract,
structural or auxiliary is defined when the object class identifier structural or auxiliary is defined when the object class identifier
is assigned. An object class definition should not be changed is assigned. An object class definition should not be changed
without having a new identifier assigned to it. without having a new identifier assigned to it.
Object class descriptions are written according to the following BNF. Object class descriptions are written according to the following BNF.
skipping to change at line 396 skipping to change at line 417
These are described as sample values for the subschema These are described as sample values for the subschema
"objectClasses" attribute for a server which implements the LDAP "objectClasses" attribute for a server which implements the LDAP
schema. While lines have been folded for readability, the values schema. While lines have been folded for readability, the values
transferred in protocol would not contain newlines. transferred in protocol would not contain newlines.
Servers SHOULD implement all the object classes referenced in Servers SHOULD implement all the object classes referenced in
section 7, except for extensibleObject, which is optional. section 7, except for extensibleObject, which is optional.
Servers MAY implement additional object classes not listed in this Servers MAY implement additional object classes not listed in this
document, and if they do so, SHOULD publish the definitions of the document, and if they do so, MUST publish the definitions of the
classes in the objectClasses attribute of their subschema entries. classes in the objectClasses attribute of their subschema entries.
Later documents may define additional object classes. Later documents may define additional object classes.
4.4. Matching Rules Schema developers MUST NOT create object class definitions whose
names conflict with attributes defined for use with LDAP in existing
standards-track RFCs.
4.5. Matching Rules
Matching rules are used by servers to compare attribute values Matching rules are used by servers to compare attribute values
against assertion values when performing Search and Compare against assertion values when performing Search and Compare
operations. They are also used to identify the value to be added operations. They are also used to identify the value to be added
or deleted when modifying entries, and are used when comparing a or deleted when modifying entries, and are used when comparing a
purported distinguished name with the name of an entry. purported distinguished name with the name of an entry.
Most of the attributes given in this document will have an equality Most of the attributes given in this document will have an equality
matching rule defined. matching rule defined.
skipping to change at line 438 skipping to change at line 463
[ "NAME" qdescrs ] [ "NAME" qdescrs ]
[ "DESC" qdstring ] [ "DESC" qdstring ]
[ "OBSOLETE" ] [ "OBSOLETE" ]
"APPLIES" oids ; AttributeType identifiers "APPLIES" oids ; AttributeType identifiers
whsp ")" whsp ")"
Servers which support matching rules and the extensibleMatch SHOULD Servers which support matching rules and the extensibleMatch SHOULD
implement all the matching rules in section 8. implement all the matching rules in section 8.
Servers MAY implement additional matching rules not listed in this Servers MAY implement additional matching rules not listed in this
document, and if they do so, SHOULD publish the definitions of the document, and if they do so, MUST publish the definitions of the
matching rules in the matchingRules attribute of their matching rules in the matchingRules attribute of their
subschema entries. If the server supports the extensibleMatch, then subschema entries. If the server supports the extensibleMatch, then
the server SHOULD publish the relationship between the matching rules the server MUST publish the relationship between the matching rules
and attributes in the matchingRuleUse attribute. and attributes in the matchingRuleUse attribute.
For example, a server which implements a privately-defined matching For example, a server which implements a privately-defined matching
rule for performing sound-alike matches on Directory String-valued rule for performing sound-alike matches on Directory String-valued
attributes would include the following in the subschema entry attributes would include the following in the subschema entry
(1.2.3.4.5 is an example, the OID of an actual matching rule would be (1.2.3.4.5 is an example, the OID of an actual matching rule would be
different): different):
matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch' matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
skipping to change at line 664 skipping to change at line 689
Values in this syntax are encoded according to the BNF given at the Values in this syntax are encoded according to the BNF given at the
start of section 4.2. For example, start of section 4.2. For example,
( 2.5.4.0 NAME 'objectClass' ( 2.5.4.0 NAME 'objectClass'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' )
6.2. Binary 6.2. Binary
( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
Values in this syntax are encoded as described in section 4.2.1. Values in this syntax are encoded as described in section 4.3.1.
6.3. Bit String 6.3. Bit String
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
Values in this syntax are encoded according to the following BNF: Values in this syntax are encoded according to the following BNF:
bitstring = "'" *binary-digit "'B" bitstring = "'" *binary-digit "'B"
binary-digit = "0" / "1" binary-digit = "0" / "1"
skipping to change at line 863 skipping to change at line 888
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
Values in this syntax are encoded as strings containing JPEG images in Values in this syntax are encoded as strings containing JPEG images in
the JPEG File Interchange Format (JFIF), as described in [8]. the JPEG File Interchange Format (JFIF), as described in [8].
6.18. Matching Rule Description 6.18. Matching Rule Description
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
Values of type matchingRules are encoded as strings according to Values of type matchingRules are encoded as strings according to
the BNF given in section 4.4. the BNF given in section 4.5.
6.19. Matching Rule Use Description 6.19. Matching Rule Use Description
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' ) ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' )
Values of type matchingRuleUse are encoded as strings according to Values of type matchingRuleUse are encoded as strings according to
the BNF given in section 4.4. the BNF given in section 4.5.
6.20. MHS OR Address 6.20. MHS OR Address
( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
Values in this syntax are encoded as strings, according to the format Values in this syntax are encoded as strings, according to the format
defined in [11]. defined in [11].
6.21. Name And Optional UID 6.21. Name And Optional UID
skipping to change at line 927 skipping to change at line 952
The encoding of a string in this syntax is the string value itself. The encoding of a string in this syntax is the string value itself.
Example: Example:
1997 1997
6.24. Object Class Description 6.24. Object Class Description
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
Values in this syntax are encoded according to the BNF in section 4.3. Values in this syntax are encoded according to the BNF in section 4.4.
6.25. OID 6.25. OID
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
Values in the Object Identifier syntax are encoded according to Values in the Object Identifier syntax are encoded according to
the BNF in section 4.1 for "oid". the BNF in section 4.1 for "oid".
Example: Example:
skipping to change at line 968 skipping to change at line 993
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
Values in this syntax are encoded according to the following BNF: Values in this syntax are encoded according to the following BNF:
postal-address = dstring *( "$" dstring ) postal-address = dstring *( "$" dstring )
In the above, each dstring component of a postal address value is In the above, each dstring component of a postal address value is
encoded as a value of type Directory String syntax. Backslashes and encoded as a value of type Directory String syntax. Backslashes and
dollar characters, if they occur in the component, are quoted as dollar characters, if they occur in the component, are quoted as
described in section 4.2. described in section 4.
Example: Example:
1234 Main St.$Anytown, CA 12345$USA 1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
6.28. Presentation Address 6.28. Presentation Address
( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
skipping to change at line 1020 skipping to change at line 1045
Values in this syntax are encoded as if they were printable Values in this syntax are encoded as if they were printable
strings with the strings containing a UTCTime value. This is strings with the strings containing a UTCTime value. This is
historical; new attribute definitions SHOULD use GeneralizedTime historical; new attribute definitions SHOULD use GeneralizedTime
instead. instead.
6.32. LDAP Syntax Description 6.32. LDAP Syntax Description
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
Values in this syntax are encoded according to the BNF in section Values in this syntax are encoded according to the BNF in section
4.2.3. 4.3.3.
7. Object Classes 7. Object Classes
Servers SHOULD recognize all the names of standard classes from Servers SHOULD recognize all the names of standard classes from
section 7 of [12]. section 7 of [12].
7.1. Extensible Object Class 7.1. Extensible Object Class
The extensibleObject object class, if present in an entry, permits The extensibleObject object class, if present in an entry, permits
that entry to optionally hold any attribute. The MAY attribute list that entry to optionally hold any attribute. The MAY attribute list
skipping to change at line 1064 skipping to change at line 1089
8.1. Matching Rules used in Equality Filters 8.1. Matching Rules used in Equality Filters
Servers SHOULD be capable of performing the following matching rules. Servers SHOULD be capable of performing the following matching rules.
For all these rules, the assertion syntax is the same as the value For all these rules, the assertion syntax is the same as the value
syntax. syntax.
( 2.5.13.0 NAME 'objectIdentifierMatch' ( 2.5.13.0 NAME 'objectIdentifierMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' )
If the client supplies a filter using an objectIdentifierMatch whose
matchValue oid is in the "descr" form, and the oid is not recognized
by the server, then the filter is Undefined.
( 2.5.13.1 NAME 'distinguishedNameMatch' ( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
( 2.5.13.2 NAME 'caseIgnoreMatch' ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
( 2.5.13.8 NAME 'numericStringMatch' ( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.36' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.36' )
( 2.5.13.11 NAME 'caseIgnoreListMatch' ( 2.5.13.11 NAME 'caseIgnoreListMatch'
skipping to change at line 1107 skipping to change at line 1136
SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' )
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' )
When performing the caseIgnoreMatch, caseIgnoreListMatch, When performing the caseIgnoreMatch, caseIgnoreListMatch,
telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match, telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
multiple adjoining whitespace characters are treated the same as an multiple adjoining whitespace characters are treated the same as an
individual space, and leading and trailing whitespace is ignored. individual space, and leading and trailing whitespace is ignored.
Clients MUST NOT assume that servers are capable of transliteration
of Unicode values.
8.2. Matching Rules used in Inequality Filters 8.2. Matching Rules used in Inequality Filters
Servers SHOULD be capable of performing the following matching rules, Servers SHOULD be capable of performing the following matching rules,
which are used in greaterOrEqual and lessOrEqual filters. which are used in greaterOrEqual and lessOrEqual filters.
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.24' )
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
The sort ordering for a caseIgnoreOrderingMatch is
implementation-dependent.
8.3. Matching Rules for Subschema Attributes 8.3. Matching Rules for Subschema Attributes
Servers which allow subschema entries to be modified by clients MUST Servers which allow subschema entries to be modified by clients MUST
support the following matching rule, as it is the equality matching support the following matching rule, as it is the equality matching
rule for several of the subschema attributes. rule for several of the subschema attributes.
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' ) SYNTAX '1.3.6.1.4.1.1466.115.121.1.38' )
Implementors should note that the assertion syntax of this matching Implementors should note that the assertion syntax of this matching
rule, an OID, is different from the value syntax of attributes for rule, an OID, is different from the value syntax of attributes for
which this is the equality matching rule. which this is the equality matching rule.
If the client supplies a filter using an
objectIdentifierFirstComponentMatch whose matchValue oid is in the
"descr" form, and the oid is not recognized by the server, then the
filter is Undefined.
9. Security Considerations 9. Security Considerations
9.1. Disclosure 9.1. Disclosure
Attributes of directory entries are used to provide descriptive Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can information about the real-world objects they represent, which can
be people, organizations or devices. Most countries have privacy be people, organizations or devices. Most countries have privacy
laws regarding the publication of information about people. laws regarding the publication of information about people.
9.2. Use of Attribute Values in Security Applications 9.2. Use of Attribute Values in Security Applications
skipping to change at line 1179 skipping to change at line 1219
acknowledged. acknowledged.
11. Authors Addresses 11. Authors Addresses
Mark Wahl Mark Wahl
Critical Angle Inc. Critical Angle Inc.
4815 West Braker Lane #502-385 4815 West Braker Lane #502-385
Austin, TX 78759 Austin, TX 78759
USA USA
Phone: +1 512 372-3160
EMail: M.Wahl@critical-angle.com EMail: M.Wahl@critical-angle.com
Andy Coulbeck Andy Coulbeck
Isode Limited Isode Inc.
The Dome, The Square 3925 West Braker Lane #333
Richmond TW9 1DT Austin, TX 78759
United Kingdom USA
Phone: +44 181-332-9091 Phone: +1 512 305-0280
EMail: A.Coulbeck@isode.com EMail: A.Coulbeck@isode.com
Tim Howes Tim Howes
Netscape Communications Corp. Netscape Communications Corp.
501 E. Middlefield Rd 501 E. Middlefield Rd
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Phone: +1 415 254-1900 Phone: +1 415 254-1900
EMail: howes@netscape.com EMail: howes@netscape.com
skipping to change at line 1212 skipping to change at line 1253
TW9 1DT TW9 1DT
UK UK
Phone: +44-181-332-9091 Phone: +44-181-332-9091
EMail: S.Kille@isode.com EMail: S.Kille@isode.com
12. Bibliography 12. Bibliography
[1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (Version 3)", INTERNET-DRAFT Protocol (Version 3)", INTERNET-DRAFT
<draft-ietf-asid-ldapv3-protocol-05.txt>, June 1997. <draft-ietf-asid-ldapv3-protocol-06.txt>, July 1997.
[2] The Directory: Selected Attribute Types. ITU-T Recommendation [2] The Directory: Selected Attribute Types. ITU-T Recommendation
X.520, 1993. X.520, 1993.
[3] The Directory: Models. ITU-T Recommendation X.501, 1993. [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119. Levels", RFC 2119.
[5] M. Wahl, S. Kille, "A UTF-8 String Representation of [5] M. Wahl, S. Kille, "A UTF-8 String Representation of
skipping to change at line 1246 skipping to change at line 1287
[9] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO [9] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996. 10646", RFC 2044, October 1996.
[10] Universal Multiple-Octet Coded Character Set (UCS) - [10] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
1993 (With amendments). 1993 (With amendments).
[11] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021 [11] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327, May 1992. and RFC 822", RFC 1327, May 1992.
[12] M. Wahl, "X.500(93) User Schema for use with LDAP", [12] M. Wahl, "X.500(96) User Schema for use with LDAP",
INTERNET-DRAFT <draft-ietf-asid-ldapv3schema-x500-01.txt>, INTERNET-DRAFT <draft-ietf-asid-ldapv3schema-x500-01.txt>,
June 1997. July 1997.
[13] D. Crocker, "Standard of the Format of ARPA-Internet Text [13] D. Crocker, "Standard of the Format of ARPA-Internet Text
Messages", STD 11, RFC 822, August 1982. Messages", STD 11, RFC 822, August 1982.
<draft-ietf-asid-ldapv3-attributes-05.txt> Expires: November 1997 <draft-ietf-asid-ldapv3-attributes-06.txt> Expires: December 1997
 End of changes. 38 change blocks. 
37 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/