[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Comments on draft-ietf-ldapbis-syntaxes-00.txt
Hi Steven!
Thanks very much for doing such a thorough reading. Responses are
in-line.
Best Regards,
Kathy
Steven Legg wrote:
>
> 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.
kld: agree
>
> >
> > letterstring = 1*a
>
> The letterstring rule can be dropped. It isn't referenced by anything.
kld:
>
> >
> > 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 "'"
kld:
> ^^^^^^^^^^ 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 ^^^^^^^^
kld:
>
> 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.
kld:
>
> >
> > 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 "'"
kld:
>
> > 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).
kld:
>
> > 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.
kld:
>
> > 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 ?
kld:
>
> > 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."
kld:
>
> 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.
kld:
>
> > 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."
kld:
>
> >
> > 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."
kld: [means changes to the table?]
>
> > 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 / "-" / "_" )
kld: need numbers too, e.g., rfc822Mailbox??
>
> >
> > 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 ?
kld: doesn't say must be in order anywhere? doc is inconsistent in
other
elements, such as attribute descriptions
>
> > 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."
kld:
>
> > 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.
kld:
>
> > 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."
kld:
>
> > 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."
kld:
>
> >
> > 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.
kld:
>
> >
> > 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."
kld:
>
> >
> > 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.
kld: contradicts the proposal for 2.3.1???
>
> >
> > 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.
kld: don't move because this is the syntax of matching rule use
descriptions????
>
> > 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
> :-).
kld: ?????????
>
> > 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."
kld:
>
> > 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.
kld:
>
> > 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 ")"
kld:
>
> > 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.
kld:
>
> > 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."
kld:
>
> > 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.
kld:
>
> > 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 ")"
kld:
>
> > 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.
kld:
>
> >
> > ( 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.
kld:
>
> >
> > 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".
kld:
>
> >
> > ( 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.
kld:
>
> >
> > 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.
kld:
>
> > 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.
kld:
>
> > 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"
kld:
>
> > 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>.
kld:
>
> > 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:"
kld: does edition 2 use ASN.1 parameterized types?? which edition of
ASN.1
should be referenced?
>
> >
> > ( 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.
kld:
>
> > 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" ...
kld:
>
> > 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).
kld: considering that the binary encoding is specified in [1] I think
that's
the place for encoding and relationship discussions; agree with the
earlier
comment that syntaxes should be discussed in their abstract sense
>
> >
> > 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 ")"
kld:
>
> > 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.
kld:
>
> > 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."
kld:
>
> > 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 ?
kld: rewrite is ok? NO, it should be deleted
>
> > 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).
kld: ??? check the ISO standard (version cited by ASN.1??)
>
> > 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].
kld:
>
> > 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."
kld:
>
> > 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.
kld: i.e., not specific to matchingRuleDescription?
>
> > 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.
kld: No, i mean a production for bitstring!! like everything else in
BNF
>
> >
> > 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.
kld:
>
> >
> > 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,
kld: ??i.e., empty?? set of attribute??
> 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 ")"
kld: MUST is required in order to state the actual attribute(s); empty
set
is not intended and should be made illegal; change to X.500??
>
> > 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:
kld: nominates??
>
> ( 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
kld:
>
> > 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.
kld:
>
> >
> > 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."
kld:
>
> >
> > ( 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>.
kld:
>
> >
> > The <value> production is UTF-8 string. Should the backslash or
> > asterix characters be present in a production of <value>
kld: replace <value> with <DirectoryString>
> > , 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".
kld:
>
> > 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.
kld:
>
> >
> > 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.
kld:
>
> > 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.
kld: but they can still be received and we are not based on X.500 ed4
>
> 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.
kld:
>
> >
> > ( 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.
kld:
>
> >
> > ( 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.
kld:
>
> > 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.
kld:
>
> > 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.
kld:
>
> > 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.
kld:
>
> > 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."
kld: but the issue is the loss of information that the transform
causes,
i.e., directoryString
>
> > 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."
kld:
>
> > 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).
kld:
>
> Regards,
> Steven
Regards,
Kathy