Protocol Action: 'LDAP & X.500 Component Matching Rules' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved following document:

- 'LDAP & X.500 Component Matching Rules'
   <draft-legg-ldapext-component-matching-11.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an IETF Working Group.

The IESG contact persons are Ted Hardie and Ned Freed.

Technical Summary

The structure or data type of data held in an attribute of an LDAP
or X.500 directory is described by the attribute's
syntax. Attribute syntaxes range from simple data types, such as
text string, integer, or boolean, to complex data types, for example,
the syntaxes of the directory schema operational attributes.
In LDAP, the attribute syntaxes are usually described by ABNF
though there is an implied association between the LDAP attribute
syntaxes and the X.500 ASN.1 types. To a large extent, the data
types of attribute values in either an LDAP or X.500 directory are
described by ASN.1 types. This formal description can be exploited
to identify component parts of an attribute value for a variety of
purposes. This document addresses attribute value matching.

Working Group Summary

Though this work was brought to the LDAPEXT working group
during the group's lifetime, the draft was not forwarded by
the working group before it shut down. The author continued
to work on it as an individual submission.

Protocol Quality

This document was reviewed by the LDAP directorate; there were
also significant last call comments, resulting in a revision of the
document.

Dear RFC Editor,

Please update the document as noted below.

Thanks,
           Ted Hardie

Section 2.

OLD

the specifications in sections 4 to 7 of this document make it
possible to fully and precisely define, the LDAP-specific encoding,
the LDAP and X.500 binary encoding


NEW

the specifications in sections 4 to 7 of this document make it
possible to fully and precisely define the LDAP-specific encoding,
the LDAP and X.500 binary encoding


Section 4

OLD

MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
rule. MATCHING-RULE.&AssertionType is an open type (formally known
as the ANY type).

NEW

MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
rule. MATCHING-RULE.&AssertionType is an open type (formerly known
as the ANY type).


Section 9

OLD

       component matching rules are applicable to any attribute syntax,
       support for them in a directory server may allow searching of
       attributes that were previously unsearchable by virtue of there 
not
       being a suitable matching rule. Such attribute types ought to be
       properly protected with appropriate access controls.

NEW

       component matching rules are applicable to any attribute syntax,
       support for them in a directory server may allow searching of
       attributes that were previously unsearchable by virtue of there 
not
       being a suitable matching rule. Such attribute types ought to be
       properly protected with appropriate access controls.  A generic,
       interoperable ACL mechanism has not yet been developed, however,
       and implementors should be aware of the interaction of that lack
       with the increased risk of exposure described above.