Subject: RE: objectclass matching rule

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 26 Jul 2001 11:03:55 +1000

Kurt,

I would be interested is seeing where it is stated that an attribute with
directory string syntax MUST have the exact value that was presented in the
update. Do you have a reference?

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Thursday, 26 July 2001 4:13
To: Steve Miller
Cc: [email-masked]
Subject: Re: objectclass matching rule

At 10:51 AM 7/25/2001, Steve Miller wrote:
>Thanks.
>
>Also, do any of the current/bis specs say whether original case MUST or
>SHOULD be preserved.

Or MAY?

If the syntax was DirectoryString, the value MUST be preserved.  But
the syntax is ObjectIdentifier which allows both descr and numericoid
forms.  While the descr form is preferred on the wire, a server
MUST be allowed to convert it to numericoid for storage (as would
be required when implementing a LDAP->DAP gateway).  When this
value is requested, the server is obligated to return a descr
form.  It obviously could chose a different descr representation
(and not just be case) of the OID than that provided upon entry
creation.

Note that this issue is not limited to OIDs.  Consider the value
of member attribute, a DN.  The server may store the DN using
XER encoding for all we know.  When returned, it may not be the
same RFC2253 string, but it is the same DN.

The general rule is that values should be preserved but that
there is no requirement to preserve the representation of that
value.  That likely needs to be stated somewhere in the data
model specification.

Kurt

>E.g., if I add an entry with 'objectclass: Country' am I
>guaranteed to get search results with 'objectclass: Country' or is it ok to
>get back 'objectclass: country' instead?
>Is there any general statement of case-preservation of attribute values
whose
>matching rules are case-insensitive?
>
>Steve
>
>"Kurt D. Zeilenga" wrote:
>
>> At 08:15 AM 7/25/2001, Steve Miller wrote:
>> >The equality matching rule for 'objectclass' is 'objectIdentifierMatch'.
>> >However, when using a name for the objectclass, instead of the OID,
>> >should the matching be case-sensitive or case-insensitive? For example,
>> >using an objectclass name in a search filter?
>>
>> Based upon prior discussion, I believe consensus is that
>> the descr form of an OID is case insensitive.
>>
>> >I looked through RFC2251, RFC2252, and RFC2256 and didn't see this issue
>> >clearly addressed. Maybe I missed it, or maybe it is somewhere else or
>> >maybe it needs to be somewhere.
>>
>> RFC2252bis will clarify this.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Jul 2001 18:42:19 -0700

>update. Do you have a reference?

Even with directory string there are likely issues due
to different charset choice and transliteration, such
when the server is an LDAPv3->LDAPv2 gateway.
My MUST assumed no transliteration was involved.  I
should have used octetString to remove transliteration
issues from entering into this.

I think the general rule, however, still holds true.
This comes from X.501, 8.1.2:
  user attribute: An attribute representing user information.

where user information is "placed in the Directory by, or on
behalf of, users; and subsequently administered by, or on
behalf of, users" (as opposed to administrative and operational
information which is "held by the Directory to meet various
administrative and operational requirements").

Kurt