Subject: Re: WG Last Call: draft-ietf-ldapbis-protocol-17.txt [corrected]

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 22 Oct 2003 09:21:15 -0600

Bah.
 
Yeah, after reading these reasons I also agree. I still think it's
appropriate for a control to exist that can be used by the client to
override this behavior. But in that case, the control definition updates
the spec, right?
 
Jim

>>> Steven Legg <[email-masked]> 10/22/03 1:02:41 AM >>>

I agree completely with Kurt.

Kurt D. Zeilenga wrote:
> At 08:46 PM 10/21/2003, Jim Sermersheim wrote:
> 
>>>>>"Steven Legg" < [email-masked] > 10/5/03 11:50:20 PM
>>>
>>>>
>>>>4.6. Modify Operation 
>>>
>>>> Parameters of the Modify Request are: 
>>>> 
>>>> - object: The object to be modified. The value of this field 
>>>> contains the DN of the entry to be modified. The server will
>>
>>not 
>>
>>> 
>>
>>^^^^^^^^
>>
>>>SHALL NOT ?
>>
>>These are all on many operations. I think SHALL NOT is too strong. I
>>suspect there are implementations that allow the alias to be
>>dereferenced (whether by control, local policy, or both).
>>
>>Do you think there is an interoperability issue here? If so, would
>>SHOULD NOT suffice?
> 
> 
> I think, no. A server which deferences the alias not only
> prevents modification of the the alias object, it might
> (quite inappropriately) modify the aliased object. A
> SHALL NOT here is appropriate as without it one could
> not administrate alias objects in an interoperable fashion.
> This applies to all other update operations as well.
> 
> Kurt 
> 
> 
>

---

From: Steven Legg <[email-masked]>
Date: Thu, 23 Oct 2003 11:11:27 +1100

Jim,

> override this behavior. But in that case, the control definition updates 

Yes. I see nothing that would prevent such a control being defined
(outside LDAPbis, of course).

Regards,
Steven

>  >>>>>"Steven Legg" <_ [email-masked] 
> <mailto:[email-masked]>_ > 10/5/03 11:50:20 PM >>>
>  >>>>
>  >>>>4.6. Modify Operation
>  >>>
>  >>suspect there are implementations tha! t allow the alias to be