[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Additional <filter> in referrals (Was: Help with a referral)

On Jun 3, 2010, at 2:02 PM, masarati@aero.polimi.it wrote:

>>> 
>>> Referrals don't work like that.  Read RFC4511: the <attrs> field is not
>>> mentioned.  It mentions, indeed, the <filter> field, but OpenLDAP does
>>> not
>>> handle this.  The behavior you possibly expect is not strictly
>>> specified,
>>> AFAIK.
>>> 
>>> I think you have a couple of options:
>>> 
>>> 1) use ACLs to hide that entry to some specific clients
>>> 
>>> 2) use a dummy proxy instead of a referral; the dummy proxy could
>>> massage
>>> the request/response DNs, and the original server could use ACLs to hide
>>> that entry from the results returned to the proxy.
>>> 
>> 
>> I tought OpenLDAP could support that kind of referrals. Now I think
>> the best option is the best for my scenario.
> 
> The <attrs> issue makes little sense.  The <filter> issue may be worth,
> although clear semantics need to be defined.

For a named subordinate referral object, a filter makes no sense.  Either the DIT has been delegated from one context to another subordinate context or it hasn't been.

> I note that rfc 3296 appears
> to explicitly prohibit a filter in the LDAP URL,

RFC 3296 language (ref SHOULD NOT have a filter, server SHOULD trim filter if present) is intended not to preclude a subsequent specification from define additional kinds of referral objects (which likely would be distinguished named subordinate referral objects by use a different object class or something).

In absence of a subsequent specification, the semantics of ref value with filters should be regarded as undefined.

I also note that RFC 3296 referral objects discussion centers on what referrals/search continuations a server should return to a client when named objects are in scope of the operation.  The document doesn't discuss how a server might use referral objects in chaining between servers.   One could surmise that a client which well supports chasing would basically have the same interaction with the DIT whether the server(s) chained or not and hence could fairly well derive the semantics from RFC 3296.   (Of course, the set of clients which well supports chasing is near empty, one likely needs to consider a theoretical client not an actual client here. :-)

Regards, Kurt