RE: Last Call Comment: LDAP & X.500 Component Matching Rules

["Steven Legg" <steven.legg@adacel.com.au>]

Kurt,

Kurt D. Zeilenga wrote:
> >Date: Mon, 12 May 2003 11:20:41 -0700
> >To: iesg@ietf.org
> >From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
> >Subject: Last Call Comment: LDAP & X.500 Component Matching Rules
> >
> >I have reviewed draft-legg-ldapext-component-matching-10.txt and,
> >aside from a few nits (see attachment), find the I-D suitable for
> >publication as a Proposed Standard.

My comments on the nits follow.

-----------------------------------------

> >INTERNET-DRAFT                                                   S. Legg
> >draft-legg-ldapext-component-matching-10.txt         Adacel Technologies
> >Intended Category: Standard Track                          April 2, 2003
> >
> >
> >                 LDAP & X.500 Component Matching Rules

> >   9. Security Considerations ....................................... 36
> >   10. Acknowledgements ............................................. 37
> >   11. Normative References ......................................... 37
> >   12. Informative References ....................................... 38
> >   13. Copyright Notice ............................................. 38
> >   14. Author's Address ............................................. 39
> 
> Add an IPR statement from RFC 2026.

I was once told by a former IESG member that the IESG didn't bother with
IPR sections, so I stopped putting them into my drafts. Recent RFCs don't
seem to have them either, so I assume an IPR statement is still not needed.

> Needs an IANA Considerations Section.

Yes. I'll cover that in a separate message.


> >2. Introduction
> >
> >   The structure or data type of data held in an attribute of an LDAP
> 
> Spell LDAP out on first use in body.  Also ABNF, ASN.1, BER, XER, XML,
> RDN, DN.

Okay.

> >   [RFC3377] or X.500 [18] directory is described by the attribute's
> 
> Reference style is not self consistent.

I'm aware of this. I use the reference in the way that befits the context.
Unless there is another comment on this I don't propose making any change.


> >3. Conventions

> >   Attribute type and matching rule definitions in this document are
> >   provided in both the X.500 [8] and LDAP [4] description formats. Note
> >   that the LDAP descriptions have been rendered with additional
> >   white-space and line breaks for the sake of readability.
> 
> Note this for string representations for LDAP filters used in
> examples.

The first paragraph of Section 8 already notes this (plus other
deviations from the norm for filters). Section 8 is the only
section that uses LDAP filters.


> >4.1 Component Reference
> >
> >   The component field in a ComponentAssertion is a UTF8 character
> >   string [6] whose textual content is a component reference,
> 
> s/UTF8 character/UTF-8 [6] encoded character from the Universal
> Character Set (UCS) [ISO 10646-1]/

It's a character string, not a single character, so your suggested
substitution doesn't parse.

I'll change UTF8 to UTF-8 since that is what [6] uses, but there is
no need for component matching to include the redundant reference
to ISO 10646-1.


> >   The LDAP-specific encoding for the ComponentFilter assertion syntax
> >   is specified by the Generic String Encoding Rules in [7].
> 
> add (GSER) after Rules.

Okay.


> >   The directoryComponentsMatch rule MAY be used as the defined equality
> >   matching rule for an attribute.
> 
> s/MAY/may/ as this does not state an implementation imperative.
> 
> Might scan other "MUST", "SHOULD", "MAY" to see if they are
> implementation imperatives and, if not, change them to lowercase.

Okay.


> >8. Component Matching Examples

> >   This section contains examples of search filters using the
> >   componentFilterMatch matching rule.  The filters are described using
> >   the string representation of LDAP search filters from [17].  Note
> >   that [17] requires asterisks to be escaped in assertion values (in
> >   these examples the assertion values are all <ComponentAssertion>
> >   encodings).  The asterisks have not been escaped in these examples
> >   for the sake of clarity, and to avoid confusing the LDAP protocol
> 
> s/protocol// (its redundant)

Not really - "protocol" is an adjective of "representation".
"LDAP representation" could be mistaken to mean the LDAP URL representation
of search filters. It is the protocol representation of search filters
that I'm referring to. I'll change the text to "the protocol representation
of LDAP search filter assertion values".

Regards,
Steven