Subject: Re: matched values 05

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 21 Dec 2000 14:49:13 -0700

>>>> "Kurt D. Zeilenga" <[email-masked]> 12/20/00 1:16:32 PM >>>
>At 12:29 PM 12/20/00 -0700, Jim Sermersheim wrote:
>>>It is perfectly reasonable
>>>for the MVO control to extend search operations extended by a sort
>>>control and to depend the semantics upon sequencing of controls
>>>(it is a sequence after all).
>>
>>The problem with this statement is that nothing in RFC 2251 ties the order in which controls are processed to the ordering of the controls in the controls sequence.

>Nor does RFC 2251 state how control interact, period.  This is
>left to the control specification.  However, as RFC 2251 uses
>a SEQUENCE OF controls instead of a SET OF controls, it is clear
>that RFC 2251 allows for behavior to be described not only be
>which controls are present but order in the sequence.
>
>>Thus, either 
>>1) 2251 needs to be fixed, 
>
>In regards to SEQUENCE OF, no.

Not what I meant. I was refering to a fix along the lines of specifying rules regarding how the controls are to interact (based on the order of the sequence)

>>2) every control spec needs to specify it's relationship with all other related controls (which is impossible), or

>Regardless of whether you believe there can or should be order
>dependent behavior, behavior of operations extended by multiple
>controls must be clearly defined.
>
>It's not impossible.  It's just difficult.  But the difficulty
>is not due to whether or not the controls are orderred or not,
>the difficulty comes from combining new controls with existing
>controls where the existing control TS could not possible
>invision the impact of all new controls.

The latter is what I considered impossible. Not knowing about future controls, one can never specify how a given control acts in conjunction with all other related controls.

>>3) we just settle for interoperability problems.
>
>If you the combination of controls has no specification, then
>there will be huge interoperability problems.
>
>However, I do believe RFC 2251 does need a clarification.
>  "Controls SHOULD NOT be combined unless the semantics of the
>  combination has been specified.  The semantics of control
>  combinations, if specified, are generally defined is the
>  control specification most recently published.  In the
>  absence of such a specification, the behavior of the operation
>  is not defined."

This may be the least evil thing to do, but it still offers nothing about the implicit, explicit, or simply default process-order of controls. It may be useful to say that controls are to be processed in the order that they appear in the sequence unless otherwise specified. OTOH, saying that much might cause immediate non-conformance of existing clients and servers.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Dec 2000 15:02:09 -0800

>The latter is what I considered impossible. Not knowing about future controls, one can never specify how a given control acts in conjunction with all other related controls.

Yes.  This is true whether or not semantics can be based upon
the ordering of controls in a sequence.

>This may be the least evil thing to do, but it still offers nothing about the implicit, explicit, or simply default process-order of controls.

Which, IMO, is a good thing.  The specification of control semantics,
including how controls may be combined and, if so, whether ordering
of controls within the sequence matters, is left to documents describing
the controls.

>It may be useful to say that controls are to be processed in the order that they appear in the sequence unless otherwise specified. OTOH, saying that much might cause immediate non-conformance of existing clients and servers.

I believe it best for RFC 2251 to provide only a syntax for
extensions but to defer specification of semantics to documents
detailing the extensions.