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

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




Jim,

Jim Sermersheim wrote:
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?

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

Regards,
Steven

Jim

 >>> Steven Legg <steven.legg@adacel.com.au> 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" <_ steven.legg@adacel.com.au <mailto:steven.legg@adacel.com.au>_ > 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 tha! t 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
>
>
>