|
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 <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 > 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 > > > |