RE: When to not deref aliases

["Volpers, Helmut" <helmut.volpers@icn.siemens.de>]

Hi all,

In our implementation it is as X.500 1993 describes it.

Never dereference in a "bind"
if you want to dereference in update operations you have to 
set a special extension control.(default: don't dereference)
If you don't want to dereference for retrieval operations
you have to set a service control (default: dereference)

Helmut

> -----Original Message-----
> From: Jim Sermersheim [mailto:JIMSE@novell.com]
> Sent: Mittwoch, 17. Januar 2001 00:45
> To: Kurt@OpenLDAP.org
> Cc: Ron.Ramsay@ca.com; ietf-ldapbis@OpenLDAP.org
> Subject: RE: When to not deref aliases
> 
> 
> >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 1/16/01 10:02:19 AM >>>
> >At 09:02 AM 1/16/01 -0700, Jim Sermersheim wrote:
> >>I don't think it's it's implied across the board.
> >>It's explicit for some operations.
> >
> >Which is why I believe dereferencing is disallowed otherwise...
> >
> >However, I agree that both interpretations are reasonable and
> >we need to got down to one interpretation.
> >
> >When choosing one over the other, besides looking at the
> >technical merits of each, we should consider which interpretations
> >have been implemented and demonstrated interoperability.
> >
> >In this case, I believe that aliases should not be dereferenced
> >in absence of a operation field (or control) specify the behavior
> >is a reasonable interpretation, a sound technical approach, is
> >widely implemented, and has demonstrated interoperability.
> 
> When we fall back on operational experience, I think it's 
> important that we hear from more than two vendors. I know 
> Novell's behavior is to not dereference anything except when 
> told to do so in the search operation. I assume the same is 
> true for OpenLDAP. I don't know about any other implementations.
> 
> It'd be nice to have a group of representatives (one from 
> each vendor that wishes to participate) that can give a 
> canonical yes/no/otherwise when polling the implemented 
> behavior of these types of things. Those representatives 
> should be able to research and respond to questions within a 
> reasonable time frame (under 1 week I would hope). I'll leave 
> it up to the chairs as to whether or not they want to 
> formalize such a thing.
> 
> Until then, I'm uncomfortable in making an editorial change 
> based on the knowledge that Novell and OpenLDAP have 
> implemented this particular behavior the same. I haven't 
> heard anything from X.500 vendors as to what their 
> interpretation is either.
> 
> Jim
>