RE: please publish draft-mmeredith-rootdse-vendor-info-01.txt

[Jim Sermersheim <JIMSE@novell.com>]

I think Mark's intention was to change the EQUALITY matching rule to caseIgnoreMatch when he changed the syntax but it slipped by.

OTOH, if he *did* want caseExactMatch, I think it would be confusing to reference it without it being formally defined somewhere (in LDAP land). I also think it would be a little funky to define it in this document. It seems like it should be grouped with the others you mention in some other place.

Jim

>>> "Salter, Thomas A" <Thomas.Salter@unisys.com> 2/14/00 3:20:21 PM >>>

I just noticed that the EQUALITY matching rule for these attributes in
caseExactIA5Match, but the syntaxes are now DirectoryString.

This led me back to RFC2252 which includes the definition for
caseIgnoreMatch (borrowed from X.520), but not caseExactMatch.

What happened to:
    ( 2.5.13.5 NAME 'caseExactMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

And now that I've started down this path, what about:
caseExactOrderingMatch, caseExactSubstringsMatch,
numericStringOrderingMatch, telephoneNumberOrderingMatch, and a whole lot
more that X.520 defines?  Are these assumed to be inherited from X.520, but
not included in the "Servers SHOULD be capable ... " clause?  Or is this the
complete list that other RFCs may reference?

To get back to the subject, can vendor info draft include "EQUALITY
2.5.13.5" in the attribute definitions, or must it also define
caseExactMatch.