[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: objectIdentifierMatch on ambiguous name
I agree with John.
I think the most Servers allow objectIdentifierMatch only on
attributes with OID syntax (not on a String syntax).
Objectclass is a special Attribute where the most Servers support
OID matching as well as String matching,
but for all other attributes with an OID syntax it is okay if
the Server supports objectIdentifierMatch.
Regards
Helmut
> -----Original Message-----
> From: John McMeeking [mailto:jmcmeek@us.ibm.com]
> Sent: Donnerstag, 2. Januar 2003 17:15
> To: Hallvard B Furuseth
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: Re: objectIdentifierMatch on ambiguous name
>
>
>
>
>
>
>
>
>
>
> 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
>
>
>