RE: Alias dereferencing in non-search operations

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

X.500 uses dont deref alaias in a List operation also by default  - so
that one can browse a tree (with a List) more efficiently and see an
entry's subordinates and its subordinate alias enties. LDAP however,
does not have a list and uses a one level search so when there is a one
level search in LDAP one has to make a choice if one wants to see the
alias entries or the ones they reference.
ie.  LDAP lets the user have two different results for the same thing.
Its a good job LDAP is less complex eh..:-)

regards alan

> -----Original Message-----
> From:	Jim Sermersheim 
> Sent:	Saturday, August 07, 1999 11:13 AM
> To:	ietf-ldapext@netscape.com
> Subject:	Alias dereferencing in non-search operations
> 
> It looks (to me) like X.500 directories dereference alias entries when
> resolving 'base' names unless the dontDereferenceAliases
> serviceControl option is set. In other words, the
> dontDereferenceAliases option is used like the "derefFindingBaseObj"
> LDAP search option.
> 
> In X.500 this applies to all operations, not just search. In LDAP,
> there doesn't seem to be a prescribed default behavior when resolving
> the name specified in operations like BindRequest, ModifyRequest,
> DelRequest, etc.
> 
> If there is a default behavior, how does one change it? In some cases
> it makes more sense to dereference and others it doesn't. For
> instance, if I name an alias during a delete, is the alias or the
> referenced entry deleted? I think most implementations delete the
> alias, which is probably desirable. On the other hand, Bind is an
> operation where dereferencing would make sense. Many times aliases are
> created as a shortcut so that a user's DN isn't so long. In this case,
> one would want to bind using the alias and have the server
> automatically dereference.
> 
>