Re: objectIdentifierMatch on ambiguous name

[John McMeeking <jmcmeek@us.ibm.com>]

Beats me -- now that my brain is functioning a little better.  And I ought
to get this thread back to the mailing list.

An obvious instance of this type of filter is (objectclass=person).  And it
is fairly clear what a client would expect to the server to do in that
case: (objectclass=person) and (objectclass=2.5.6.6) ought to be
equivalent.  The existence of an attributetype also named person
(discouraged, but legal) should not affect this filter.  Two objectclasses
with the same name (within a given subschema) would be a problem, but I'd
be suprised if a server allowed it.

For any other attribute with objectIdentifierMatch, I, as a user, would be
suprised if the server did any <descr> to <numericoid> conversion.  Reading
the specs, I would expect a server to allow me to create an entry with
values like 1.2.3.4 or foo, and do something like a case insensitive match
(FOO = foo) but I wouldn't expect "foo" to match a numeric oid.  Given that
OIDs can be used for anything, it seems unreasonable to expect that there
would be a one-to-one <descr> to <numericoid> mapping outside of a given
application realm.

At best, any <descr> to <numericoid> mapping would be depend on the
attribute being used and would either be server defined, or be defined by
some other standard.  For example, a standard could define names for widget
types, where each widget type also has a registered OID.  Then, maybe, it
would make sense to expect (widgetType=foo) to match widgetType=6.6.6; but
it wouldn't make sense to expect (myOidAttr=foo) to match the value
myOidAttr=6.6.6.

Maybe [SYNTAXES] should try to clarify this.  Or maybe [SYNTAXES] should
remove reference to values assertions using <descr> form of OIDs in the
spirit of "liberal in what you accept, strict in what you send."


John  McMeeking



                                                                                                                               
                      Hallvard B                                                                                               
                      Furuseth                 To:       John McMeeking/Rochester/IBM@IBMUS                                    
                      <h.b.furuseth@usi        cc:                                                                             
                      t.uio.no>                Subject:  Re: objectIdentifierMatch on ambiguous name                           
                                                                                                                               
                      01/02/2003 08:43                                                                                         
                      AM                                                                                                       
                                                                                                                               
                                                                                                                               




John McMeeking writes:
> Going back to your example:
>
>   object class   ( ... NAME  'foo'        ... )
>   object class   ( ... NAME  'bar'        ... )
>   attribute type ( ... NAME ('foo' 'bar') ... )
>
> the filter (oid=foo) has nothing to do with these.  It only matches
entries
> that have an "oid" attribute with the value "foo".

I don't think so. [Syntaxes] 5.2.17 (objectIdentifierMatch) says:

   The rule evaluates to TRUE if and only if the assertion value and the
   attribute value represent the same object identifier, that is, the
                   ^^^^^^^^^                                      ^^^
   same sequence of integers, whether represented explicitly in the
   ^^^^^^^^^^^^^^^^^^^^^^^^^
   <numericoid> form of <oid> or implicitly in the <descr> form (see
   [MODELS]).

So as far as I can tell, objectIdentifierMatch should convert the name
'foo' to a sequence of integers and then try to match.

--
Hallvard