Subject: RE: When to not deref aliases

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 16 Jan 2001 09:02:50 -0700

I don't think it's it's implied across the board. It's explicit for some operations. For the rest we need to follow X.511 behavior. When you look there, it seems to be clear that all operations other than bind allow for CommonArguments.ServiceControls.options.dontDereferenceAliases. It's kind of implied in LDAP that due to the lack of this option, we don't dereference. 

My worry is that since X.511 doesn't provide an option for bind, there's some default or prescribed behavior that I'm not aware of. If so, LDAP should follow that behavior, right?

From my experience, I know we don't currently dereference on a bind, though we have requests to do such a thing 
from end-users. I haven't tested any other servers (LDAP or DAP), though my guess is that most also don't.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/12/01 11:49:27 AM >>>
IMO, aliases should only be dereferenced when there is a field
enabling the behavior (such as provided in the search request
or by a control).  I believe this is implicit in the specification.
This can be made explicit if necessary.

At 10:38 AM 1/12/01 -0700, Jim Sermersheim wrote:
>My copy of X.511 (93) doesn't include a CommonArguments in the bind operation, thus you can't specify "dontDereferenceAliases". Also, the bind operation doesn't talk about alias dereferencing. I don't know if this is to be read as:
>1) since you can't specify behavior, don't deref while binding or,
>2) since you can't specify behavior, do deref while binding (since the implied default is to deref).
>
>I feel like I'm overlooking something.
>
>Jim
>
>>>> "Jim Sermersheim" <[email-masked]> 1/12/01 10:08:25 AM >>>
>So it sounds like we should state that Compare and ModDN do not deref the alias. Does X.500 deref the bind name (or equiv) if it's an alias?
>
>Jim
>
>>>> "Ramsay, Ron" <[email-masked]> 11/16/00 7:24:03 PM >>>
>You're right, Compare should not dereference (as it has no way of saying not
>to dereference).
>
>As regards X.500, CommonArguments, ServiceControls contains
>options:dontDereferenceAliases, and this is available to all operations
>(where Bind is not an operation). Of course, it is ignored in update
>operations.
>
>Ron.
>
>-----Original Message-----
>From: Kurt D. Zeilenga [mailto:[email-masked]] 
>Sent: Friday, 17 November 2000 13:05
>To: Jim Sermersheim
>Cc: [email-masked]; [email-masked] 
>Subject: RE: When to not deref aliases
>
>
>At 06:39 PM 11/16/00 -0700, Jim Sermersheim wrote:
>>Well, I don't think we can do that for v3. I'm just trying to get
>clarification on whether we should explicitly state that alias dereferencing
>does not happen for those three op's.
>
>I assume this is in X.500 somewhere, but I believe aliases
>should be dereferenced during processing of the search operation.
>Other operations should act upon the alias, not the aliased object.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Jan 2001 09:02:19 -0800

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.

Kurt