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

From: "Salter, Thomas A" <[email-masked]>
Date: Fri, 11 Feb 2000 09:37:01 -0500

I agree that clients need to determine what server they are talking to.  It
wasn't that long ago that servers didn't even agree on the character set.
In V2 you could find servers using UTF8, T.61 and Latin-1.  Granted that
problem should be solved by now, but there are still many ambiguities in the
RFCs and probably a number of "a server MAY ... " clauses that are not
otherwise resolvable.

These attributes are easy to implement and allow client writers to solve
real world problems.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 Feb 2000 09:00:53 -0800

>These attributes are easy to implement and allow client writers to solve

If clients are allowed to derive their behavior from these
attributes than servers must be allowed to spoof their
values to obtain desired behavior.

	Kurt

---

From: "Salter, Thomas A" <[email-masked]>
Date: Mon, 14 Feb 2000 17:19:58 -0500

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.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 14 Feb 2000 18:54:56 -0700

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" <[email-masked]> 2/14/00 3:20:21 PM >>>

What happened to:

---

From: "Mark Meredith" <[email-masked]>
Date: Tue, 15 Feb 2000 11:44:57 -0700

I will make the EQUALITY be a caseIgnoreMatch, 
I had looked for caseExact but did not find it, so I used the caseExactIA5Match. After thinking about it, it would probably be better to 
use the caseIgnoreMatch.

-Mark

>>> "Jim Sermersheim" <[email-masked]> 02/14/00 06:55PM >>>

Jim

What happened to: