[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments on draft-ietf-ldapbis-syntaxes-00.txt
Kathy,
Here are some lengthy comments on draft-ietf-ldapbis-syntaxes-00.txt .
> 2. General Issues
> 2.1 Notation
> k = a / d / "-" / ";"
>
> p = a / d / """ / "(" / ")" / "+" / "," / "-" / "." /
> "/" / ":" / "?" / " "
The equals sign, "=", and apostophe, "'", are legal PrintableString
characters missing from the above list. The double quote character, """,
isn't a legal PrintableString character and should be removed.
>
> letterstring = 1*a
The letterstring rule can be dropped. It isn't referenced by anything.
>
> numericstring = 1*d
>
> anhstring = 1*k
>
> keystring = a [ anhstring ]
>
> printablestring = 1*p
>
> space = 1*" "
> whsp = [ space ]
>
> utf8 = <any sequence of octets formed from the UTF-8 [9]
> transformation of a character from ISO10646 [10]>
>
> dstring = 1*utf8
The question of escaping quotes that appear in a <dstring> was discussed
on the mailing list (see
http://www.openldap.org/lists/ietf-ldapbis/200102/msg00036.html ).
Kurt proposed the following wording, which I'm happy with, and which no
one objected to:
Kurt Zeilenga wrote:
>> utf8 = <any sequence of octets formed from the UTF-8 [9]
>> transformation of a character from ISO10646 [10]
>> except "'">
>> dstring = 1*( utf8 / "''" ) ; escaped utf8 string, each "'"
>> ; appearing in the value to be encoded is
>> ; escaped by a proceeding "'"
^^^^^^^^^^ preceding
> qdstring = whsp "'" dstring "'" whsp
>
> qdstringlist = [ qdstring *( qdstring ) ]
>
> qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp )
The optional spaces in the current BNF in RFC 2252 make it very
difficult to write a general parser for the schema syntaxes.
Kurt initiated a discussion of this on the mailing list (see
http://www.openldap.org/lists/ietf-ldapbis/200102/msg00013.html )
and proposed these revisions as part of a cleanup of the whitespace:
>> qdstring = "'" dstring "'"
>> qdstringlist = [ qdstring *( space qdstring ) ]
>> qdstrings = qdstring / ( "(" whsp qdstring whsp ")" )
Should be qdstringlist ^^^^^^^^
There are associated changes throughout the BNF for the schema syntaxes.
I'll flag these changes as I get to them.
> In the following BNF for the string representation of OBJECT
> IDENTIFIERs, descr is the syntactic representation of an object
> descriptor, which consists of letters and digits, starting with a
> letter.
The BNF for <descr> permits hyphens in addition to letters and digits.
It also permits semicolons, but I argue below for this to be removed.
> oid = descr / numericoid
>
> descr = keystring
>
> numericoid = numericstring *( "." numericstring ) [ "{" len "}" ]
The optional length in brackets doesn't belong here. It only applies to a
numericoid in the SYNTAX field of an AttributeTypeDescription value. It is
meaningless elsewhere. The above BNF allows it to be added to any OID.
The <noidlen> rule from RFC 2252 should continue to be used for syntax
object identifiers.
>
> len = numericstring
>
> woid = whsp oid whsp
The <woid> rule is dropped under Kurt's whitespace revisions (each
instance of its use in the schema element BNFs is replaced by
"space oid").
>
> oids = woid / ( "(" oidlist ")" ) ; set of oids of either form
>
> oidlist = woid *( "$" woid )
>
> qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp ) ; object
> ; descriptors used as schema element names
>
> qdescrlist = [ qdescr *( qdescr ) ]
>
> qdescr = whsp "'" descr "'" whsp
More of Kurt's whitespace revisions apply here:
>> oids = oid / ( "(" whsp oidlist whsp ")" )
>> oidlist = oid * ( whsp "$" whsp oid )
>>
>> qdescrs = qdescr / ( "(" whsp qdescrlist whsp ")" )
>> qdescrlist = [ qdescr *( whsp qdescr ) ]
>>
>> qdescr = "'" descr "'"
> Servers are not required to provide the same or any text in the
> description part of the subschema values they maintain.
The same should apply to the NAME and OBSOLETE fields of all the subschema
operational attribute values. In X.500, the information which is required
to be invariant with respect to an associated object identifier is that
which is given in the ATTRIBUTE, MATCHING-RULE, OBJECT-CLASS and NAME-FORM
information objects. These information objects map into subcomponents of
the AttributeTypeDescription, MatchingRuleDescription,
ObjectClassDescription,
and NameFormDescription ASN.1 types (respectively) with the component
identifier "information". The components of the above ASN.1 types
corresponding to the NAME, DESC and OBSOLETE fields in the LDAP
representation are all outside the "information" component (it just isn't
evident from the BNF).
> 2.2 Syntaxes
> In an LDAP schema, an Object Identifier (OID) is assigned to a
> syntax definition when the syntax is named. The syntaxes defined
> for LDAP, are listed in paragraph 2.2.3. A syntax definition should
> not be changed without having a new OID assigned to it.
Syntaxes in X.500 can be, and have been, extended. The LDAP representations
of schema attribute syntaxes alert readers to the possibility of future
extensions. I don't think syntaxes should come under the general rule
that a change to the definition requires a new object identifier.
I suggest the sentence be removed.
> 2.2.1 Syntaxes Implementation Status
>
> The syntaxes that have been identified for LDAP are listed in
> section 2.2.3. The specifications of the syntaxes that are further
> defined this document are given in section 3.
^ by ?
> Clients MUST NOT assume that an unrecognized syntax is a string
> representation.
This sentence highlights a number of areas where I think the precision of
the document can be improved.
Firstly, the term "string" is hopelessly overloaded. Regardless of what
encoding is used, every value in the LDAP protocol is at least an *octet*
string, some of them are human readable *character* strings, and some of
them belong to syntaxes defined by ASN.1 string types. I suggest we be
more careful when using the term "string" and qualify its use appropriately.
The term "syntax" tends to be used to mean the LDAP string representation
of values of the syntax and therefore such usage fails to consider or even
acknowledge the binary representation (i.e. the wording used in this
document
often makes it sound like there is only one possible representation).
A syntax isn't a single representation, it is an abstract data type, the
values of which can have multiple representations. The LDAP core documents
define two of these representations. We need some consistent terminology
to distinguish these representations, and wording that makes it clear
which representation(s) a particular requirement applies to.
We often talk about the LDAP string encoding/representation as the
counterpart of the binary encoding/representation but given the overloading
of the term "string" I suggest a more neutral term. I propose the term
"native LDAP encoding" to mean the default representation of values of a
syntax when no transfer encoding attribute option has been specified. The
other representation defined by the core documents should then be
consistently referred to as the "binary encoding". RFC2251bis is the place
to formally introduce both terms, but this document would benefit from
using them consistently. Substituting "representation" for "encoding" would
also work.
Taking all these points into account I suggest the following rewording
of the original offending sentence:
"Clients MUST NOT assume that the native LDAP encoding of a value
of an unrecognized syntax is a human-readable character string."
Hopefully, proper separation of concepts, consistent use of terminology,
and more careful wording will avoid the sort of confusion that makes users
think they can use caseIgnoreSubstringsMatch on Attribute Type Description
values because the latter are "strings".
I suggest similar rewordings throughout the remainder of this message as
quoted text without introduction.
>
> 2.2.2 Binary Transfer of Values
>
> The binary encoding format specified in draft-ietf-ldapbis-
"The binary encoding specified" ...
> protocol-xx [1] is used,for returning an attribute value, if binary
> format is requested by the client or if the attribute syntax is
... "if the binary encoding is requested by the client or if the attribute
syntax is the Binary syntax, i.e." ...
> "binary", i.e., "1.3.6.1.4.1.1466.115.121.1.5". [EDITOR'S NOTE:
> The remainder of this paragraph plus the next paragraph should be
> moved to the draft-ietf-ldapbis-protocol-xx I-D. END.] The contents
> of the LDAP AttributeValue or AssertionValue field is a BER-encoded
> instance of the attribute value or a matching rule assertion value
> ASN.1 data type as defined for use with X.500. (The first byte
> inside the OCTET STRING wrapper is a tag octet. However, the OCTET
> STRING is still encoded in primitive form.)
>
> All servers MUST implement this form for both generating attribute
> values in search responses, and parsing attribute values in add,
> compare, and modify requests, if the attribute type is recognized
Search requests contain assertion values, for which the same requirement
applies.
> and the attribute syntax name is that of Binary. Clients which
> request that all attributes be returned from entries MUST be prepared
> to receive values in binary (e.g. userCertificate;binary), and SHOULD
... "to receive values in the binary encoding" ...
> NOT simply display binary or unrecognized values to users.
... "display binary encoded values or values of unrecognized syntaxes
to users."
>
> 2.2.3 Syntax Object Identifiers
>
> Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which
> are dotted-decimal strings. These are not intended to be displayed
> to users.
>
> The following table lists the syntaxes that have been defined for
> LDAP, thus far. The H-R column suggests whether a value of that
> syntax is likely to be a human readable string.
The H-R column is only meaningful when we are talking about the native
LDAP encoding, and it isn't a question of probabilities. I suggest
this rewording:
"The H-R column indicates whether the native LDAP encoding of a value
of that syntax is a human readable character string."
> 2.2.4 Syntax Description
>
> The following BNF is used in this document to associate a short
> description (e.g., a name) with a syntax OBJECT IDENTIFIER. The
> productions for whsp, numericoid, qdescrs and qdstring are given in
> paragraph 2.1. Implementors should note that future versions of this
> document may expand this definition to include additional terms.
> Terms whose identifier begins with "X-" are reserved for private
> experiments, and MUST be followed by a <qdstrings> token.
Kurt provided revised wording for the above sentence as part of the
proposal for cleaning up the white space issues.
Kurt Zeilenga wrote:
>> Terms whose identifier begins with "X-" are reserved for
>> private experiments, and MUST be followed by a <space> and
>> a <qdstrings> encodings.
The legal characters for extension and experiment identifiers ought to
be nailed down. Kurt's suggestion below seems reasonable to me.
Kurt Zeilenga wrote:
>> xstring = "X-" 1*( a / "-" / "_" )
...
N.B.
>> I note that 2252 didn't specify what the characters can be used
>> in a xstring, I just picked this a reasonable set which I hope
>> includes all current private experiments.
The extensions really should be explicitly allowed for in the BNF for
the schema operational attributes.
Kurt suggested adding the following line into the BNF for each of the
extensible schema elements.
>> *[ space xstring space qdstrings ] ; extensions
I suggest introducing a convenience name like so:
extensions = *( space xstring space qdstrings )
Should we be explicitly allowing for future standard extensions as well
as private extensions ? For example, with BNF like this:
extensions = *( space extension-identifier space qdstrings )
extension-identifier = private-identifier / standard-identifier
private-identifier = "X-" 1*( a / "-" / "_" )
standard-identifier = 1*( a / "-" / "_" )
>
> SyntaxDescription = "(" whsp
> numericoid whsp
> ["NAME" qdescrs ]
Adding new fields is out-of-scope.
> [ "DESC" qdstring ]
extensions
Plus the optional extensions.
This assumes all extensions appear at the end of the Description.
Do we want to allow them to appear between any of the fields ?
> whsp ")"
Following the style of Kurt's whitespace proposal the BNF becomes:
SyntaxDescription = "(" whsp
numericoid
[ space "DESC" space qdstring ]
extensions
whsp ")"
>
> Note that the SyntaxDescription BNF is also the BNF that defines the
> LDAP Syntax Description syntax.
... "the BNF that defines the native LDAP encoding of values of the
LDAP Syntax Description syntax."
> 2.2.5 Example
>
> For example, the INTEGER syntax for whole number values could be
> written as:
>
> ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
Change the "could be" to an "is". Let's not give anyone funny ideas
about the malleability of syntax definitions.
> 2.3.1 Matching Rules Implementation Status
>
> Servers which support matching rules and the extensibleMatch SHOULD
> implement all the matching rules in section 4.
>
> Servers MAY implement additional matching rules not listed in this
> document, and if they do so, MUST publish the definitions of the
> matching rules in the matchingRules attribute of their subschema
> entries.
This requirement to publish all the matching rules that a directory server
implements is both onerous and inappropriate. Our directory server supports
72 different matching rules while the typical schema only needs about 20
or so. If we followed this requirement then we would be clogging up our
subschema subentries with 50+ unnecessary matching rule definitions that
have no significance to the particular schema.
If the intent of this requirement is to advertise what matching rules a
server supports then the mechanism is flawed since a subschema area can
be replicated or distributed across multiple servers with different
capabilities. A list of supported matching rules is specific to servers,
not specific to subschema areas in the DIT.
I think the requirement should be that servers "MUST publish in the
matchingRules attribute, the definitions of matching rules referenced
by values of the attributeTypes and matchingRuleUse attributes in the same
subschema entry. Other unreferenced matching rules MAY be published in the
matchingRules attribute."
> If the server supports the extensibleMatch, then the
> server MUST publish the relationship between the matching rules and
> attributes using the matchingRuleUse attribute.
X.500 has never really been clear about how the matchingRuleUse attribute
is supposed to be interpreted, but it certainly doesn't tie it to whether
a DSA supports extensibleMatch. Again, because a subschema area can be
replicated or distributed, it is inappropriate to use this attribute to
advertise a capability of the server. My best guess is that the
matchingRuleUse attribute allows the schema designer to indicate appropriate
combinations of matching rule and attribute types in extensible matches,
but doesn't imply any sort of policy for the server to enforce. Given that
searches can span subschema areas, enforcement would be a non-trivial
implementation problem.
The 4th edition draft of X.501 says that "The applicability of defined
matching rules to the attributes contained in a subschema specification
(over and above the matching rules used in the definition of these
attribute types) is indicated through the subschema specification
operational attribute matchingRuleUse".
At the very least there is no requirement in X.500 to publish the
combinations already implied by the attribute definitions. Not that the
reduction would help me very much. The Adacel directory server supports
the extensible match and has some matching rules with wide applicability.
The *lower* bound on the number of supported combinations of matching rule
and attribute type, i.e. the number of "APPLIES" oids spread across 72
values of the matchingRuleUse attribute, is 9 times the number of attributes
defined in the subschema subentry. When I finish implementing the component
matching rules it will be 12 times. I don't want to be forced to publish
all those combinations in every subschema entry.
I think the requirement should become:
"A server MAY use the matchingRuleUse attribute to indicate the
applicability of selected matching rules to nominated attribute
types in an extensibleMatch."
>
> Clients MUST NOT assume that servers are capable of transliteration
> of Unicode values.
Transliteration to or from what ? This statement has lost any context that
might have given it meaning, and appears to be in contradiction of the
description of the Directory String syntax.
>
> 2.3.2 Matching Rule Description
>
> Matching rule descriptions are written according to the following
> BNF. The productions for numericoid, qdescrs, qdstring, oid, and
> whsp are given in paragraph 2.1. Implementors should note that
> future versions of this document may expand this BNF to include
> additional terms. Terms whose identifier begins with "X-" are
> reserved for private experiments, and MUST be followed by a
> <qdstrings> token.
... "followed by a <space> and a <qdstrings> encoding.
> MatchingRuleDescription = "(" whsp
> numericoid whsp ; MatchingRule identifier
> [ "NAME" qdescrs ]
> [ "DESC" qdstring ]
> [ "OBSOLETE" whsp ]
> "SYNTAX" oid
> whsp ")"
Using the <oid> rule for the SYNTAX field allows object descriptor names
as well as numeric oids (and attribute options - ugh!). I agree with Kurt
that this constitutes a "new" feature and should be ruled out-of-scope.
RFC 2252 has <numericoid> but it probably should have been <noidlen>.
I'm not fussed if the group wants to leave it as <numericoid>.
With the whitespace revisions the BNF becomes:
MatchingRuleDescription = "(" whsp
numericoid ; MatchingRule identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "SYNTAX" space noidlen
extensions
whsp ")"
>
> Note that the MatchingRuleDescription BNF is also the BNF that
> defines the Matching Rule Description syntax.
... "the BNF that defines the native LDAP encoding of values of the
Matching Rule Description syntax."
>
> 2.3.3 Matching Rule Use Description
The LDAP core specifications don't have any Matching Rule Use Descriptions.
Are there any RFCs defining LDAP schemas that do ? This sub-section can be
moved into section 3.
>
> Matching Rule Use Descriptions list the attributes which are
> suitable for use in an extensibleMatch that employs the associated
> matching rule. See paragraph xxx of [1]. The following BNF is used
> when writing Matching Rule Use Descriptions:
>
> MatchingRuleUseDescription = "(" whsp
> numericoid whsp ; MatchingRule identifier
> [ "NAME" qdescrs ]
> [ "DESC" qdstring ]
> [ "OBSOLETE" ]
> "APPLIES" oids ; AttributeType identifiers
> whsp ")"
With the whitespace revisions the BNF becomes:
MatchingRuleUseDescription = "(" whsp
numericoid ; MatchingRule identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "APPLIES" space oids ; AttributeType identifiers
extensions
whsp ")"
> Note that the MatchingRuleUseDescription BNF is also the BNF that
> defines the Matching Rule Use Description syntax.
... "the BNF that defines the native LDAP encoding of values of the
Matching Rule Use Description syntax."
The whole statement can be dropped if this section moves into section 3.
> 2.3.4 Example
>
> For example, in specifying a server which implements a privately-
> defined matching rule for performing sound-alike matches on
> Directory String-valued attributes, the matching rule could be
> written as (1.2.3.4.5 is an example, the OID of an actual matching
> rule would be different):
>
> matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
>
> This description could be the one included in the subschema entry in
> the server. If this matching rule could be used with the attributes
> 2.5.4.41 and 2.5.4.15, the following could be the use description
> present in the subschema entry:
>
> matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
> A client could then make use of this matching rule by sending a
> search operation in which the filter is of the extensibleMatch
> choice, the matchingRule field is "soundAlikeMatch", and the type
> field is "2.5.4.41" or "2.5.4.15".
Section 2.1 says that object descriptors "SHOULD be used in preference
to numeric oids to the greatest extent possible" (not that I necessarily
agree). I don't think this example has exhausted the realm of possibilities
:-).
> 2.4.1 Attributes Implementation Status
> Servers MAY recognize additional attribute types not listed in this
> document, and if they do so, MUST publish the definitions of the
> types in the attributeTypes attribute of their subschema entries.
This requirement to publish all the attribute types that a directory server
recognizes is as inappropriate as the requirement on publishing all the
supported matching rules. Our directory server recognizes 180 predefined
attribute definitions even before schema designers start adding to the list
with their own definitions. [Implying at least 9 x 180 = 1620 oids across
72 values of the matchingRuleUse attribute.]
A sufficient requirement is that servers "MUST publish in the attributeTypes
attribute of the same subschema entry, the definitions of attribute types
referenced by values of the objectClasses, nameForms, matchingRuleUse and
dITContentRules attributes, and attribute types referenced by the SUP field
in values of the attributeTypes attribute itself. Other unreferenced
attribute types MAY be published in the attributeTypes attribute."
> Schema developers MUST NOT create attribute definitions whose names
> conflict with attributes defined for use with LDAP in existing
> standards-track RFCs.
Should this requirement be extended to:
"Schema developers MUST NOT create attribute definitions whose names
conflict with matching rules, attribute types, object classes or
name forms defined for use with LDAP in existing standards-track RFCs." ?
The kind of OID that a <descr> corresponds to is usually constrained by
the context of its use, but for an arbitrary attribute of the OID syntax
overloaded names would be ambiguous.
A similar statement appears in section 2.5.1 for object classes.
A statement to the same effect should be added for matching rules and
name forms.
> 2.4.2 Attribute Description
For consistency, this section should be titled "Attribute Type Description",
which would also make it less likely to be confused with
AttributeDescription
from RFC 2251.
>
> Attribute types are expressed according to the following BNF.
"Attribute type descriptions are" ...
> The productions for whsp, numericoid, qdescrs, qdstring, woid, and
> noidlen are given in paragraph 2.1. Implementors should note that
> future versions of this document may expand this BNF to include
> additional terms. Terms which begin with the characters "X-" are
> reserved for private experiments, and MUST be followed by a
> <qdstrings> token.
... "followed by a <space> and a <qdstrings> encoding.
>
> AttributeTypeDescription = "(" whsp
> numericoid whsp ; AttributeType identifier
> [ "NAME" qdescrs ] ; name used in AttributeType
> [ "DESC" qdstring ] ; description
> [ "OBSOLETE" whsp ]
> [ "SUP" woid ] ; derived from this other
> ; AttributeType
The <woid> (i.e. <oid>) rule allows attribute options after the attribute
type object descriptor (but inconsistently, not after an attribute type
numericoid). The ASN.1 type of the corresponding component in the BER
encoding of a value of AttributeTypeDescription is an OBJECT IDENTIFIER.
If any options are used in the native LDAP encoding of a value
of the Attribute Type Description syntax then these options are
automatically lost in the translation to the binary encoding.
A SUP field with an attribute object descriptor followed by an option has
to be referring to the same attribute type description value that the
attribute object descriptor alone would refer to, since it isn't possible to
have multiple attribute type description values for the same attribute type
where each one has a different attribute option in the NAME field. The
objectIdentifierFirstComponentMatch rule prevents it. Therefore qualifying
the SUP field with an attribute option has little practical use.
If we choose to define a meaning to such a practice in LDAPbis that would
constitute a "new" feature and new features are out of scope. We would also
still be left with the problem that the meaning cannot be conveyed by the
binary encoding.
The <woid> rule is also a placeholder for matching rule, object class and
name form object identifiers, for which attribute options are completely
meaningless and cannot be conveyed in the binary encoding anyway.
The BNF should at least be structured to disallow trailing options for
these cases. My preferred solution is to revise the <oid> rule so that it is
only an object descriptor or a numeric oid, without any trailing options,
even for the cases where the oid refers to an attribute type. Removing ";"
from the <k> rule in section 2.1 is all that is needed to make the change.
> [ "EQUALITY" woid ] ; Matching Rule name
This is a case where the <woid> rule refers to a matching rule object
identifier. A trailing attribute option is meaningless here though it
is allowed by the current BNF.
> [ "ORDERING" woid ] ; Matching Rule name
> [ "SUBSTR" woid ] ; Matching Rule name
> [ "SYNTAX" whsp noidlen whsp ] ; see section 2.3
> [ "SINGLE-VALUE" whsp ] ; default multi-valued
> [ "COLLECTIVE" whsp ] ; default not collective
> [ "NO-USER-MODIFICATION" whsp ] ; default user modifiable
> [ "USAGE" whsp AttributeUsage ] ; default userApplications
> whsp ")"
This is the whitespace-revised BNF suggested by Kurt:
>> AttributeTypeDescription = "(" whsp
>> numericoid ; AttributeType identifier
>> [ space "NAME" space qdescrs ] ; name used in AttributeType
>> [ space "DESC" space qdstring ] ; description
>> [ space "OBSOLETE" ]
>> [ space "SUP" space oid ] ; derived from this other
>> ; AttributeType
[ space "EQUALITY" space oid ] ; Matching Rule name
[ space "ORDERING" space oid ] ; Matching Rule name
>> [ space "SUBSTR" space oid ] ; Matching Rule name
>> [ space "SYNTAX" space noidlen ] ; see section 4.3
>> [ space "SINGLE-VALUE" ] ; default multi-valued
>> [ space "COLLECTIVE" ] ; default not collective
>> [ space "NO-USER-MODIFICATION" ] ; default user modifiable
>> [ space "USAGE" space AttributeUsage ] ; default userApplications
extensions
>> whsp ")"
> An AttributeDescription (i.e., the means of referring to an attribute
> in the protocol [1]) can be used as the value in a NAME part of
> an AttributeTypeDescription. Note that these are case insensitive.
> [Editor's Note: The preceding paragraph seems to be circular in
> nature, especially when looking at the AttributeType explanation in
> [1]. What is the fix? End of Editor's Note]
Disallowing attribute options in a <qdescr> would break the cycle !
Each <descr> in the NAME field of an AttributeTypeDescription could
then be described as defining a textual name of the attribute for use in
the protocol.
In this case there isn't a discrepancy between the native LDAP encoding
and the binary encoding since a <qdescr> in the NAME field corresponds to
a DirectoryString component. However it is also true that the meaning
of an attribute option in a NAME field hasn't been defined by the core
LDAP documents. Giving the practice a specific meaning would constitute
a "new" feature, putting it out-of-scope.
I can see how someone might try to use attribute options in a <qdescr> as a
surrupticious way to nominate what transfer encodings and attribute
subtyping
options are permitted to be used with a particular attribute type but there
are other ways such things could be more explicitly defined by future RFCs.
The <qdescrs> rule is also used to define the NAME fields of
SyntaxDescription, MatchingRuleDescription, MatchingRuleUseDescription,
ObjectClassDescription, DITContentRuleDescription,
DITStructureRuleDescription and NameFormDescription. In every one of
these cases a trailing attribute option is meaningless and shouldn't
be allowed by the BNF.
I propose that attribute options be disallowed in the <qdescr> rule.
Removing ";" from the <k> rule in section 2.1 has this effect anyway.
> 2.5 Object Classes
>
> Object classes are the components of an entry.
I would have thought that attributes qualify as the components of an entry.
I suggest the following as a more meaningful introduction:
"Object classes are used to categorize the kinds of entries stored
in the directory and to determine what attributes are contained in
those entries."
> 2.5.1 Object Classes Implementation Status
>
> Servers SHOULD implement the subschema object class.
>
> Implementing the extensibleObject object class is optional.
>
> Servers MAY implement additional object classes not listed in this
> document, and if they do so, MUST publish the definitions of the
> classes in the objectClasses attribute of their subschema entries.
This requirement is inappropriate for reasons already presented above.
> 2.5.2 Object Class Description
> ObjectClassDescription = "(" whsp
> numericoid whsp ; ObjectClass identifier
> [ "NAME" qdescrs ]
> [ "DESC" qdstring ]
> [ "OBSOLETE" whsp ]
> [ "SUP" oids ] ; Superior ObjectClasses
> [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
> ; default structural
> [ "MUST" oids ] ; AttributeTypes
> [ "MAY" oids ] ; AttributeTypes
> whsp ")"
With the whitespace revisions the BNF becomes:
ObjectClassDescription = "(" whsp
numericoid ; ObjectClass identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
[ space "SUP" space oids ] ; Superior ObjectClasses
[ space ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) ]
; default STRUCTURAL
[ space "MUST" space oids ] ; AttributeTypes
[ space "MAY" space oids ] ; AttributeTypes
extensions
whsp ")"
> 3. Syntaxes
>
> 3.1 Attribute Type Description
>
> A value in this syntax is a character string which expresses the
> definition of an attribute type according to the BNF given in
> paragraph 2.4.2. This syntax is the form in which schema attribute
> types are published in the directory. The following string states
> the OID assigned to this syntax:
The above paragraph can be improved somewhat.
"A value in this syntax publishes the definition of an attribute type.
This syntax corresponds to the AttributeTypeDescription ASN.1 type from
X.501 [3]. The native LDAP encoding for a value of this syntax is given
by the <AttributeTypeDescription> rule in Section 2.4.2. The following
Syntax Description nominates the OID assigned to this syntax:"
I suggest this as the general pattern to follow for all the schema syntax
descriptions.
>
> ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
>
> For example, this character string specifies the objectClass
> attribute, whose values are OIDs:
>
> ( 2.5.4.0 NAME 'objectClass'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
There is plenty of potential for readers to become confused between
objectClass and objectClasses. I suggest that this example be replaced
by an attribute with a DirectoryString syntax.
>
> 3.2 Binary
>
> A value in this syntax is a series of 0's and 1's. The length of
> the series is octet-aligned (i.e., evenly divisible by eight). The
> series is expressed as described in paragraph 2.2.2. The following
> string states the OID assigned to this syntax:
Yoicks! Try this instead:
"This syntax does not correspond to a specific ASN.1 type. The native LDAP
encoding for a value of this syntax is defined to be its binary encoding
according to some assumed, but unspecified, ASN.1 type. Although a value
of an attribute defined with the Binary syntax can potentially be of any
ASN.1 type, a particular ASN.1 type MAY be implied by the associated
attribute type. The means by which the actual ASN.1 type of the values
can be determined is outside the scope of this specification. The following
Syntax Description nominates the OID assigned to this syntax:"
Maybe we should rename this syntax to the ANY syntax so that we mimimise
confusion with the binary encoding, and with attributes containing arbitrary
binary data, i.e. values of the Octet String syntax. Maybe we should also
say "the BER encoding" instead of "the binary encoding" even though the
transfer encoding attribute option would still be ";binary".
>
> ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
>
> The interpretation of a value is part of the definition of the
> attribute which contains the value.
>
> 3.3 Bit String
>
> A value in this syntax is a value of the BIT STRING data type from
> ASN.1 [5].
To someone who understands ASN.1 this could be taken to mean that the
values of this syntax are always BER encoded. I support the idea of
explicitly associating the LDAP syntaxes with their ASN.1 data types but
I suggest a less misleading wording, e.g.
"This syntax corresponds to the BIT STRING ASN.1 type from [5]. The
following Syntax Description nominates the OID assigned to this syntax:"
> The following string states the OID assigned to
> this syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
>
> Values in this syntax are expressed according to the following BNF:
"The native LDAP encoding for values of this syntax is defined
by the following BNF:"
Likewise for all the remaining syntaxes.
>
> bitstring = "'" *binary-digit "'B"
>
> binary-digit = "0" / "1"
>
> Example: '0101111101'B
> 3.5 Certificate
The Certificate, Certificate List, Certificate Pair and Supported Algorithm
syntaxes are candidates to be removed from the LDAP core specification, in
which case David Chadwick and I will put them into the LDAP schema for PKIX.
In the meantime, the descriptions can be improved.
> A value in this syntax is the binary string that results from
> BER/DER-encoding an X.509 [6] public key certificate. The following
> string states the OID assigned to this syntax:
"A value of this syntax is a public key certificate. This syntax
corresponds to the Certificate ASN.1 type from X.509 [6]. The following
Syntax Description nominates the OID assigned to this syntax:"
>
> ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
>
> Due to the changes from X.509(1988) to X.509(1993) and subsequent
> changes to the ASN.1 definition to support certificate extensions,
> no string representation is defined, and values in this syntax MUST
... "no native LDAP encoding is defined here,"
I'd like to leave open the possibility of encodings other than BER being
used in the future.
... "and values of this syntax have to be transferred using the binary
encoding," ...
> only be transferred using the binary encoding, by requesting or
> returning the attributes with descriptions "userCertificate;binary"
> or "caCertificate;binary".
"Other encodings, including a native LDAP encoding, may be defined
in the future."
Likewise for sections 3.6, 3.7 and 3.37.
> 3.7 Certificate Pair
>
> A value in this syntax is the binary string that results from
> BER/DER-encoding an X.509 [6] public key certificate pair. The
> following string states the OID assigned to this syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
>
> Due to the Certificate Pair being carried in binary, values in
> this syntax MUST only be transferred using a binary encoding, by
A circular argument :-)! Paraphrase the new wording for section 3.5.
> requesting or returning the attribute description
> "crossCertificatePair;binary". The BNF notation in RFC 1778 [7] for
> "Certificate Pair" is not recommended to be used.
> 3.8 Country String
>
> A value in this syntax is two printable string characters
> representing a country.
Refering to a corresponding ASN.1 type for this syntax is a little
tricky because although there is a convenient ASN.1 type name (i.e.
CountryName) in the 4th edition of X.520, there isn't one in the
2nd edition. So either we don't reference the corresponding ASN.1
type for this syntax, or we say something like this:
"This syntax corresponds to the following ASN.1 type definition
from X.520 [9]:
PrintableString (SIZE(2)) -- ISO 3166 codes only"
> 3.9 Delivery Method
> A value in this syntax is expressed according to the following BNF:
>
> delivery-value = pdm / ( pdm whsp "$" whsp delivery-value )
A more compact and neater way of saying this in BNF is the following rule:
delivery-value = pdm *( whsp "$" whsp pdm )
A more consistent name for the rule would be <DeliveryMethod>.
> 3.10 Directory String
>
> A value in Directory String syntax is a string of Unicode
They are ISO 10646 characters rather than UNICODE. Using either term
might suggest a particular (wrong) encoding. I think it is sufficient
to just say "string of characters" and leave it to the BNF to detail
the encoding.
> characters. See [ ??? ]. The following string states the OID
> assigned to this syntax:
"A value of this syntax is a string of characters. This syntax
corresponds to the DirectoryString ASN.1 parameterized type from X.520 [9].
The following Syntax Description nominates the OID assigned to this syntax:"
>
> ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
>
> In X.520 [9], a directory string is defined to be in one of
> these forms: PrintableString, TeletexString, UniversalString, or
> BMPString. (All of the forms are data types from ASN.1 [5].)
>
> [Editor's note: What should the BNF be for this syntax? End of
> Editor's note].
We could use the old definition for the <utf8> rule (renamed of course).
"The native LDAP encoding for values of this syntax is defined
by the following BNF:
DirectoryString = 1*UTF8Character
UTF8Character = <any sequence of octets formed from the UTF-8 [9]
transformation of a character from ISO10646 [10]> "
BTW, X.500 requires that DirectoryString values be at least one character.
> Note: The form of DirectoryString is not indicated in protocol
> unless the attribute value is carried in binary. Servers
> which convert to DAP MUST choose an appropriate form. Servers
> MUST NOT reject values merely because they contain legal
> Unicode characters outside of the range of printable ASCII.
>
> Servers and clients MUST be prepared to receive arbitrary Unicode
... "arbitrary ISO10646 characters" ...
> characters, including characters not presently assigned to
> any character set.
>
> Example: This is a string of DirectoryString containing #!%#@.
>
> [Editor's note: the following three paragraphs should be moved
> to [1] (paragraph ???). End of Editor's note]
I disagree. This document is the place to be defining the relationship
between the native LDAP encoding and the binary encoding for a syntax
(for those cases where it isn't obvious).
>
> 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 [10], UTF-8 is
> used to encode them.
>
> 3.11 DIT Content Rule Description
> DITContentRuleDescription = "("
> numericoid ; Structural ObjectClass identifier
> [ "NAME" qdescrs ]
> [ "DESC" qdstring ]
> [ "OBSOLETE" ]
> [ "AUX" oids ] ; Auxiliary ObjectClasses
> [ "MUST" oids ] ; AttributeType identifiers
> [ "MAY" oids ] ; AttributeType identifiers
> [ "NOT" oids ] ; AttributeType identifiers
> ")"
With the whitespace revisions the BNF becomes:
DITContentRuleDescription = "(" whsp
numericoid ; Structural ObjectClass identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
[ space "AUX" space oids ] ; Auxiliary ObjectClasses
[ space "MUST" space oids ] ; AttributeType identifiers
[ space "MAY" space oids ] ; AttributeType identifiers
[ space "NOT" space oids ] ; AttributeType identifiers
extensions
whsp ")"
> 3.12 DIT Structure Rule Description
> DITStructureRuleDescription = "(" whsp
> ruleidentifier whsp ; DITStructureRule identifier
> [ "NAME" qdescrs ]
> [ "DESC" qdstring ]
> [ "OBSOLETE" whsp ]
> "FORM" woid whsp ; NameForm
> [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
> ")"
With the whitespace revisions the BNF becomes:
DITStructureRuleDescription = "(" whsp
ruleidentifier ; DITStructureRule identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "FORM" space oid ; NameForm
[ space "SUP" space ruleidentifiers ] ; superior DITStructureRules
extensions
whsp ")"
> ruleidentifierlist = [ ruleidentifier *( whsp "$" whsp
> ruleidentifier ) ]
This is a bigger change than is necessary to fix the <ruleidentifiers>
encoding. A minimal correction is this:
ruleidentifierlist = [ ruleidentifier *( space ruleidentifier ) ]
I note that the BNF in both this revision and RFC 2252 allows "SUP ()".
Given that the SUP field is optional permitting an empty ruleidentifierlist
isn't adding anything useful.
> 3.13 DN
>
> A value in the Distinguished Name syntax is the sequence of
> name values that traverse the DIT to the named entry. The following
> string states the OID assigned to this syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
>
> Values in the Distinguished Name syntax are expressed by the
> representation defined in [12]. Note that this representation is not
> reversible to an ASN.1 encoding used in X.500 for Distinguished
... "is not reversible to the original BER encoding used in" ...
> Names, as the CHOICE of any DirectoryString element in an RDN is no
> longer known.
... "in an RDN is not evident in the native LDAP encoding."
> 3.14 Enhanced Guide
> Values in this syntax are expressed according to the following BNF:
>
> EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset
>
> subset = "baseobject" / "oneLevel" / "wholeSubtree"
>
> criteria = criteria-item / criteria-set / ( "!" criteria )
>
> criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) /
> ( [ "(" ] criteria "|" criteria-set [ ")" ] )
>
> criteria-item = [ "(" ] attributetype "$" match-type [ ")" ]
This BNF allows a value in the native LDAP encoding to be interpreted
in a number of ways, doesn't require the parentheses to match up, and
doesn't allow for an empty list of "and" or "or" terms (the ASN.1 type
does).
The following BNF accepts the old format but imposes an unambiguous
precedence on the operators.
criteria = or-term /
"(" or-term ")"
or-term = and-term *( "|" and-term )
and-term = not-term *( "&" not-term )
not-term = "!" not-term /
attributetype "$" match-type /
"(" or-term ")" /
"?true" / ; an empty "and" in the Criteria ASN.1 type
"?false" ; an empty "or" in the Criteria ASN.1 type
>
> match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
>
> This syntax has been added subsequent to RFC 1778 [7].
Do we need to say this ?
> 3.15 Facsimile Telephone Number
> Values in this syntax are expressed according to the following BNF:
>
> fax-number = printablestring [ "$" faxparameters ]
>
> faxparameters = faxparm / ( faxparm "$" faxparameters )
faxparameters = faxparm *( "$" faxparm )
> 3.17 Generalized Time
>
> A value in the Generalized Time syntax is a date and time indicating
> accuracy to second or tenth of a second.
Generalized time allows arbitrary precision (not just tenths).
> 3.19 IA5 String
>
> A value in the IA5 String syntax is a string of characters from the
> International Alphabet 5 [15] (international version of ASCII)
> character set. The following string states the OID assigned to this
> syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
>
> The written representation of a value in this syntax is the string
"The native LDAP encoding of" ...
> value itself. Also, IA5String is an ASN.1 data type from X.680 [5].
> 3.22 LDAP Syntax Description
> Note that, in X.520 [9], syntaxes are not labeled distinctly with
> respect to attributes.
"Note that in X.520 [9], syntaxes are indicated by ASN.1 type definitions
rather than by syntax OIDs."
> 3.23 Matching Rule Description
>
> A value in the Matching Rule Description syntax is a string that
> expresses the definition of a schema Matching Rule. This syntax is
> the form in which schema matching rules are published in the
> directory. The following string states the OID assigned to this
> syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
>
> Values of type matchingRules are written as strings according to the
> BNF given in section 2.3.2.
Specific named attribute types are to be avoided in defining the encodings
for a syntax. A syntax is more general than a single attribute type.
> 3.26 Name and Optional UID
> Values in this syntax are expressed according to the following BNF:
> NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
>
> The bitstring production is defined in [Editor's note: Where is
> bitstring?? End of Editor note].
Section 3.3 of this document, Section 6.3 of RFC 2252.
>
> Although the '#' character may occur in a string representation of a
> distinguished name, no additional special quoting is done. This
> syntax has been added subsequent to RFC 1778 [7].
If the '#' character is not escaped in the DN then the <NameAndOptionalUID>
encoding is ambiguous. A trailing #<bitstring> might be part of the right
most RDN or it might be the UID. The two cases can't be reliably
distinguished. Not escaping the '#' characters also makes it difficult to
parse values of this syntax in a single forward pass.
I think the usual escaping should apply.
>
> Example: 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
>
> 3.27 Name Form Description
> NameFormDescription = "(" whsp
> numericoid whsp ; NameForm identifier
> [ "NAME" qdescrs ]
> [ "DESC" qdstring ]
> [ "OBSOLETE" whsp ]
> "OC" woid ; Structural ObjectClass
> "MUST" oids ; AttributeTypes
> [ "MAY" oids ] ; AttributeTypes
> whsp ")"
The NameFormDescription ASN.1 type permits an empty list of
namingMandatories,
i.e. the MUST field. The MUST field should be made optional (making the
following <oids> part optional would make the BNF ambiguous).
With the whitespace revisions the BNF becomes:
NameFormDescription = "(" whsp
numericoid ; NameForm identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "OC" space oid ; Structural ObjectClass
[ space "MUST" space oids ] ; AttributeTypes
[ space "MAY" space oids ] ; AttributeTypes
extensions
whsp ")"
> 3.30 Octet String
>
> A value in the Octet String syntax is a value of the OCTET STRING
> data type from ASN.1 [5]. The following string states the OID
> assigned to this syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
>
> Values in this syntax are written as a series of 8-bit values,
> according to the octet string value notation specified in [5].
This is misleading. I suggest:
"A value of this syntax is a string of octets representing arbitrary
8-bit data values. This syntax corresponds to the OCTET STRING ASN.1 type
from [5]. The following Syntax Description nominates the OID assigned
to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
The native LDAP encoding for a value of this syntax is the string of
octets without any conversion. Hence values in the native LDAP encoding
for this syntax are generally not human-readable character strings."
> In
> the case of character strings, the characters themselves may be
> written.
I don't think an example helps in the understanding of the Octet String
syntax. We should drop it. Talking about character strings here will
just confuse matters.
>
> Example:
>
> secret
> 3.33 Postal Address
>
> A value in the Postal Address syntax is a series of strings which
> form an address in a physical mail system. The following string
> states the OID assigned to this syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
>
> Values in this syntax are written according to the following BNF:
>
> postal-address = dstring *( "$" dstring )
The <dstring> rule is no longer appropriate to use here because of
the escaping of quote characters in the string. Use the <DirectoryString>
rule instead.
>
> In the above, each dstring component of a postal address value is
> written as a value of type Directory String syntax. Backslashes and
> dollar characters, if they occur in the component, are quoted as
> described in paragraph 2.1. Many servers limit the postal address to
> six lines of up to thirty characters.
> 3.36 Substring Assertion Syntax
>
> The Substring Assertion syntax is used only as the syntax of
> assertion values in the extensible match. It is not used as the
> syntax of attributes, or in the substring filter.
"The Substring Assertion syntax is used by some substring matching rules
as their assertion syntax. It is not used as an attribute syntax.
Note that assertion values of the Substring Assertion syntax only
appear in an extensible match. The assertion values in a substring filter
always use the assertion syntax of the equality matching rule for the
associated attribute type."
>
> ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
>
> The Substring Assertion is expressed according to the following BNF:
>
> substring = [initial] any [final]
>
> initial = value
>
> any = "*" *(value "*")
>
> final = value
Replace <value> with <DirectoryString>.
>
> The <value> production is UTF-8 string. Should the backslash or
> asterix characters be present in a production of <value>, they are
> quoted as described in section 2.1.
> 3.39 Teletex Terminal Identifier
>
> A value in this syntax is a string of characters that express the
... "is a teletex terminal identifier with optional parameters".
> identifier value assigned to a teletex service subscriber. The
> following string states the OID assigned to this syntax:
>
> ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal
> Identifier' )
>
> Values in this syntax are written according to the following BNF:
>
> teletex-id = ttx-term 0*("$" ttx-param)
The 0 is unnecessary.
>
> 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.
>
> The production for printablestring is defined in paragraph 2.1.
>
> [Editor's note: There is no production for octetstring in
> paragraph 2.1. How should it be defined? End of Editor's note]
The easiest thing to do is to define <octetstring> as a hexadecimal
character string, though, according to the TeletexTerminalIdentifier
ASN.1 type, only the values of the "page" and "private" parameters are
OCTET STRINGs. The others are TeletexString.
The 4th edition of X.500 has deprecated teletexTerminalIdentifier even
to the point of removing it from the object class definitions for
organization, organizationalUnit, dMD, organizationalPerson,
organizationalRole and residentialPerson.
I suspect no one would care if the native LDAP encoding was discarded
completely and the Teletex Terminal Identifier syntax was made ";binary"
only.
> 3.41 UTC Time
> [EditorÆs note: The convention for interpretation of 2-digit year
> values should be here (at least by reference), but where is the LDAP
> convention specified? Is LDAP referring to X.500 for this? If so,
> where? End of Editor's note]
The interpretation of the 2-digit year only really matters for comparisons,
thus it is an issue for the uTCTimeOrderingMatch matching rule. The fourth
edition of X.520 has something to say about it. Since the LDAP core
documents don't reference uTCTimeOrderingMatch and discourage the use
of UTCTime syntax I don't think you need to say anything about the
interpretation of 2 digit years.
4. Matching Rules
> 4.1 bitStringMatch
>
> The following BNF associates the bitStringMatch rule with the Bit
> String syntax:
What follows is not BNF!
What these sections should be doing is providing a meaningful description
the semantics of each matching rule. We can do better than just associating
a rule with an assertion syntax.
Look to X.520 for inspiration.
>
> ( 2.5.13.16 NAME 'bitStringMatch'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ; Bit String
>
> This matching rule is used to test equality.
> 4.4 caseIgnoreListMatch
>
> The BNF below associates the caseIgnoreListMatch rule with the
> Postal Address syntax. The X.520 [] syntax for this matching rule
> is a SEQUENCE Of DirectoryString. Since the Postal Address syntax
> is such a sequence, it is used in defining the matching rule for
> LDAPv3, although the matching rule can be used with any SEQUENCE OF
> DirectoryString syntax/assertion.
In X.500 terms the attribute syntax of the postalAddress attribute and
the assertion syntax of the caseIgnoreListMatch are different syntaxes,
i.e. different ASN.1 types. Having two different X.500 syntaxes
corresponding to the same LDAP syntax causes discrepancies to creep in
when mapping back and forth between the native LDAP encoding and the
binary encoding of Matching Rule Descriptions and Attribute Type
Descriptions.
I would like to see a distinct Case Ignore List syntax defined to be used
as the assertion syntax for the caseIgnoreListMatch rule so that there
is a one-to-one mapping between LDAP syntaxes and X.500 syntaxes.
Aside: there are other cases of many-to-one syntax mappings in the
user schema definitions.
>
> ( 2.5.13.11 NAME 'caseIgnoreListMatch'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ; Postal Address
> 4.7 caseIgnoreSubstringsMatch
>
> The following BNF associates the caseIgnoreSubstringsMatch rule with
> the Substring Assertion:
>
> ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion
>
> This matching rule is used to test substrings equality.
"substrings equality" seems like a contradiction to me.
> 4.11 integerFirstComponentMatch
>
> Implementors should note that the assertion syntax of this matching
> rule, an INTEGER, is different from the value syntax of attributes
> for which this is the equality matching rule.
>
> ( 2.5.13.29 NAME 'integerFirstComponentMatch'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER
>
> This matching rule is used to test equality with the first component
> in a compound syntax.
The following paragraph is a repeat of the first paragraph in this section.
> Implementors should note that the assertion syntax of this matching
> rule, an INTEGER, is different from the value syntax of attributes
> for which this is the equality matching rule.
> 4.16 objectIdentifierMatch
> Implementors should note that the assertion syntax of this matching
> rule, an OID, is different from the value syntax of attributes for
> which this is the equality matching rule.
The above paragraph doesn't belong. The statement is true for
objectIdentifierFirstComponentMatch but not for objectIdentifierMatch.
> 5. Attribute Types
> 5.14 objectClasses
Because of the potential for confusion between the objectClass attribute
and this attribute I think a descriptive paragraph is needed here.
>
> This attribute is typically located in the subschema entry.
>
> ( 2.5.21.6 NAME 'objectClasses'
> EQUALITY objectIdentifierFirstComponentMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 ; Object Class
> ; Description
> USAGE directoryOperation )
> 6. Object Classes
> 6.2 subschema
>
> This object class contains a description of the schema that is
> applied in the server and is used in the subschema entry.
>
> ( 2.5.20.1 NAME 'subschema'
> AUXILIARY
> MAY ( dITStructureRules $
> nameForms $
> ditContentRules $
> objectClasses $
> attributeTypes $
> matchingRules $
> matchingRuleUse ) )
>
> The ldapSyntaxes operational attribute may also be present in
> subschema entries. [Editor's Proposal: add "A Content Rule could be
> used to enable this." End of Editor's Proposal]
Since ldapSyntaxes is an operational attribute it doesn't necessarily
have to be permitted by an object class definition or content rule
to be present in an entry. The rules about when and where an operational
attribute may appear are part of its specification. It is enough for us
to say that it may be present in subschema entries.
> 7.2 Use of Attribute Values in Security Applications
>
> The transformations of an AttributeValue value from its X.501 form
> to an LDAP string representation are not always reversible back to
"The transformation of an attribute value from its binary encoding to
its native LDAP encoding is not always reversible back to exactly the
same binary encoding."
> the same BER or DER form. An example of a situation which requires
> the DER form of a distinguished name is the verification of an X.509
> certificate.
>
> For example, a distinguished name consisting of one RDN with one AVA,
> in which the type is commonName and the value is of the
> TeletexString choice with the letters 'Sam' would be represented in
> LDAP as the string CN=Sam.
... "represented in the native LDAP encoding as" ...
> Another distinguished name in which the
> value is still 'Sam' but of the PrintableString choice would have the
> same representation CN=Sam.
>
> Applications which require the reconstruction of the DER form of the
> value SHOULD NOT use the string representation of attribute syntaxes
> when converting a value to LDAP format.
... "SHOULD NOT use the native LDAP encoding for attribute syntaxes."
> Instead it SHOULD use the
> Binary syntax.
Not the Binary syntax but the binary transfer attribute option (or whatever
RFC 2251bis ends up calling it).
Regards,
Steven