Subject: objectIdentifierMatch on ambiguous name

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 2 Jan 2003 13:10:13 +0100

What does filter component (oid=foo) applied to attribute oid=bar
evaluate to if the schema defines the following?
  object class   ( ... NAME  'foo'        ... )
  object class   ( ... NAME  'bar'        ... )
  attribute type ( ... NAME ('foo' 'bar') ... )
  attribute type ( ... NAME 'oid'
                   EQUALITY objectIdentifierMatch
                   SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 02 Jan 2003 08:55:16 -0800

>  attribute type ( ... NAME ('foo' 'bar') ... )

It likely needs to be clarified that the meaning of 'foo' and
'bar' are context sensitive and MUST NOT be used where the
context is not provided.

>                   SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID

If this attribute is intended to hold OIDs referring to any
kind of object, then short names cannot be used with it.  That
is, the assertion (oid=foo) is Undefined.

I note that if the attribute is intended to hold OIDs referring
to a specific kind of object (e.g., attribute types, object
classes, matching rules), the server needs also to be aware of
this intent in order to map "foo" to the appropriate (numeric)
OID.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 3 Jan 2003 14:55:13 +0100

> this intent in order to map "foo" to the appropriate (numeric)

That seems a bit strict to me.  I think the filter (oid=foo)
should match an oid attribute with value "foo", at least.

Otherwise, if the admin wants to define an attribute which holds
the names (descriptors) of attribute names, and the server doesn't
provide an extension which lets him tell it which OID namespace
the attribute uses, he must use Printable String syntax and
caseIgnoreMatch instead of OID syntax and objectIdentifierMatch.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Jan 2003 07:33:35 -0800

>should match an oid attribute with value "foo", at least.

I don't think "foo" should be allowed as a value of 'oid'.
Because allowing "foo" allows "bar" and that requires there
to be a way for the server to determine whether "foo" and
"bar" are equal or not.  However, the implementation has
no knowledge of which mapping table, or which subset of
a table, of short names to numeric oids applies; the question
of whether "foo" is equal to "bar" is, without context,
Undefined.

Nor could "foo" and 1.2.3 be added to "oid" without whether
"foo" and 1.2.3 are equal.  The assertion (oid=1.2.3) is
likewise Undefined if "oid" contains the value "foo".

>caseIgnoreMatch instead of OID syntax and objectIdentifierMatch.

Yes.  That's exactly what the admin should do if he wants to
hold NAMEs.  Names in X.500 and, generally in LDAP, are just
printable stings which have no meaning except in a few limited
contexts.

Kurt

---

From: Mark Wahl <[email-masked]>
Date: Fri, 03 Jan 2003 13:44:07 -0600

> should match an oid attribute with value "foo", at least.

I'd tend to side with Kurt on this one though.  The 'at least' part is 
worrying.  I'd prefer to say that the server MUST support matching with 
a numericoid assertion value.  Perhaps it could be a server feature to 
have OID matching with short names.

> caseIgnoreMatch instead of OID syntax and objectIdentifierMatch.

Or the admin could use an extensible matching rule with the OID syntax.

A similar issue is the objectIdentifierFirstComponentMatch MR for the 
attributes attributeTypes and objectClasses.  Should only 
numericoid be permitted in the search filter assertion value?  
If not, then it runs into the same difficulty as here.

Mark Wahl
Sun Microsystems Inc.

---

From: Mark Wahl <[email-masked]>
Date: Fri, 03 Jan 2003 13:49:12 -0600

> of whether "foo" is equal to "bar" is, without context,

Common practice for LDAPv3 servers though is to support queries of 
the form (objectClass=person), and many clients today use objectClass
equality matching with non-numeric OIDs.  2252 section 8.1 
only said the match was Undefined if the server did not recognize
the OID.  

Mark Wahl
Sun Microsystems Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Jan 2003 12:48:26 -0800

At 11:49 AM 1/3/2003, Mark Wahl wrote:
>the form (objectClass=person),

Of course, this is "with context".  objectClass is part of
the system schema (despite being of usage userApplications)
hence the server knows its values refer to object classes.

If non-standard object classes are used,  there is some
ambiguity as to which subschema should be used to map value
to an OID.  I assume most implementations use the subschema
controlling the entry named by the baseObject and don't
allow the same name to kind of element (object class, attribute
type, matching rule) to appear in a subschema.

>and many clients today use objectClass equality matching with non-numeric OIDs.

I prefer to use the term 'OID in <descr> form'.  The key is that
matching is done on abstract value, in this case, OIDs. 

>2252 section 8.1 only said the match was Undefined if the server did not recognize the OID.

This statement:
   If the client supplies a filter using an objectIdentifierMatch whose
   matchValue oid is in the "descr" form, and the oid is not recognized
   by the server, then the filter is Undefined.

is somewhat problematic (because <descr> are ambigious).  I think
a server should be free to treat the match as Undefined when there
is insufficient context to determine whether the assertion value
matches an entry (per RFC 2251, 4.5.1).

In short, I think we need to be clear as when <descr> form SHOULD
be used and when it SHOULD NOT be used.  I think we all agree that,
in LDAP, they SHOULD be used for AttributeTypes appearing in the
protocol, values (and assertion values) of the objectClass attribute,
and in <oid> productions appearing in schema descriptions.

How about?
        MatchingRuleIDs appearing in extensible filters?
        assertion values of attributeTypes, objectClasses, etc.?

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 3 Jan 2003 23:41:25 +0100

>         assertion values of attributeTypes, objectClasses, etc.?

I think a general statement is better than listing instances.
Something like

4.3.26 (OID):
  Since a short name can refer to different OIDs in different
  contexts (e.g. there might be an object class 'x-fubar' and an
  attribute type 'x-fubar' in a subschema), a server SHOULD NOT
  allow short names in the OID syntax in contexts where it does
  not know which <numericoid> the short name represents.

5.2.17 (objectIdentifierMatch):
  If the asserted value or attribute value is a short name of an OID,
  and the server does not know which <numericoid> the short name
  represents but allows such values as attribute values, the match
  evaluates to Undefiend, even if the asserted value and the attribute
  value are equal.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Jan 2003 16:31:09 -0800

>I think a general statement is better than listing instances.

While I certainly would prefer a general statement, I'm afraid
that different statements might be needed for different instances.

>  not know which <numericoid> the short name represents.

Doesn't this contradict [Models, 1.3]?

>  evaluates to Undefiend, even if the asserted value and the attribute

I'm thinking 4.3.26 of [Syntaxes] should say something like:

        Servers SHOULD prevent values in <descr> form from be
        stored in the directory for which the server is not
        able to unambiguously determine which OID the <descr>
        represents.

and 5.1.17:
        If the assertion value is presented in <descr> form and
        the implementation is not able to determine which OID
        the <descr> represents, the server SHOULD treat the
        assertion as being Undefined.

That is, if the server cannot determine which OID the <descr>
refers to, the <descr> should be viewed as invalid.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 4 Jan 2003 16:49:00 +0100

> that different statements might be needed for different instances.

Eh?  Then why did you too suggest a general statement further down?

> Doesn't this contradict [Models, 1.3]?

I guess so, but so does your suggestion.  Doesn't it say the same thing
(except that yours is shorter and better:-)?

> refers to, the <descr> should be viewed as invalid.

Fine.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 04 Jan 2003 08:30:41 -0800

>Eh?  Then why did you too suggest a general statement further down?

Because I prefer general statements as well...  but,
as I noted, we may have to note some exceptions to them.

>I guess so, but so does your suggestion.

Yes.  So, the next question is, how do we resolve this contradiction?
(I'm going to chew on this a bit before attempting to offer a
suggestion.)

>Doesn't it say the same thing?

Basically, yes.

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 6 Jan 2003 16:04:01 +1100

Kurt,

> refers to, the <descr> should be viewed as invalid.

This is basically what my server implementation does. It always
tries to convert a <descr> into a numeric oid, using the context
(if available), and throws an "invalid syntax" error if unable to
do so. The error will fail an update request, or will cause an
assertion to evaluate to undefined.

Regards,
Steven

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 6 Jan 2003 16:52:53 +0100

> (I'm going to chew on this a bit before attempting to offer a

I think this statement in [Models] 1.3

>  (...) the
>  <descr> encoding option SHOULD be used instead of the <numericoid>
>  encoding option

could get the addition

   except in contexts where the server cannot unambiguously determine
   which <numericoid> the <descr> represents.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 18 Jan 2003 11:04:50 +0100

I'd like to note, for the purposes of the WG Last Call on [Models],
that some clarification to [Models] is needed in this area.
        Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 20 Jan 2003 15:02:39 +0100

> that different statements might be needed for different instances.

I forgot to ask - why?  All syntaxes that use OIDs that I can see come
with a definition which says which OID name space they apply to, except
the OID syntax itself - and the core schema only uses that for the
objectClass attribute, which itself provides the namespace.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 20 Jan 2003 17:00:28 +0100

At 03:02 PM 1/20/2003, Hallvard B Furuseth wrote:
>I forgot to ask - why?

Because the existing specification stated a number of special cases...

>All syntaxes that use OIDs that I can see come
>with a definition which says which OID name space they apply to,

Really?  I think that most of the definitions of name space are actually
quite ambiguous.  Consider the assertion (objectClass=foo) in a subtree search
where different parts of the subtree are controlled by different
subschemas, each with a different definition for foo.  (Let's assume
the server holds the whole subtree for now.) Is the server to map foo
on a per entry basis, or once for the whole operation? 

>except

I think that an attribute type used in an attribute of a particular entry
may actually be insufficient to clear specify a namespace.  Consider DNs.
Are all names of attribute types appearing in a DN in the same name space,
or could each RDN be in a separate name space?

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 20 Jan 2003 17:09:51 +0100

Kurt D. Zeilenga writes:
> Really?  I think that most of the definitions of name space are
> actually quite ambiguous.  Consider the assertion (objectClass=foo) in
> a subtree search where different parts of the subtree are controlled
> by different subschemas, each with a different definition for foo.
> (Let's assume the server holds the whole subtree for now.) Is the
> server to map foo on a per entry basis, or once for the whole
> operation?

per entry, I think.

> or could each RDN be in a separate name space?

Doesn't matter.  If the attribute names are not in the registry or the
table of short names or whatever in [DN], short names are not used.

The RDN 'objectClass=foo' could be a problem, though.

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 24 Jan 2003 19:27:06 +0100

>> server to map foo on a per entry basis, or once for the whole

...though I wish I didn't:-)
In any case, I think the answer to that question belongs in
4.5. Search Operation in [Protocol], not in [Models].

-- 
Hallvard