Subject: RE: controls

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 2 Oct 2002 10:40:31 +1000

I agree with the view expressed here.

Actually, I think the stand should be that order is not important. Instead
of using order to force semantics, you should use a different control. In
the example of matched-values with sorting, the two interpretations should
be defined with two controls.

Each control document should specify which controls it interacts with and
how it interacts (not just the last published document). If the sorting
document is updated, it shouldn't have to specify how it interacts with
matched-values, because it is 'generic', though it has to be aware of the
other control. Matched-values,being 'specific', should specify its behaviour
in the presence of the sorting control.

If two controls appear in a request, and neither defines its behaviour in
the presence of the other, they should be regarded as independent. The
server may, in this case, refuse to process the request or may process it in
its own way. If matched-values and sorting did not refer to each other (in a
parallel universe), the server should be at liberty to perform the sorting
at the place in its procedures where sorting is normally performed.

Ron.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Wednesday, 2 October 2002 6:52 AM
To: [email-masked]; [email-masked]
Subject: Re: controls

The wording in my latest (yet-to-be-submitted) draft says this:

"Controls should not be combined unless the semantics of the
combination has been specified. The semantics of control combinations,
if specified, are generally found in the control definition most
recently published. In the absence of such a definition, the behavior of
the operation is undefined.  
Additionally, the order of a combination of controls in the SEQUENCE is
ignored unless the control definition explicitly states that ordering
affects the operation."

In other words, we can't say that it matters unless we can say how it
matters. Therefore, we acknowledge that it may matter, but leave it up
to the control definitions to specify if and how it matters.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 10/01/02 12:50PM >>>
Likely something needs to be said about whether the order
of controls in the control SEQUENCE matters to processing
of the operation or not.  It's my personal opinion that the
order should matter.

For example, consider MatchedValues and Duplicate Entries.
Match then Duplicate and Duplicate then Match are two different
operations.

Where control processing may only make sense if the controls
are processed in a certain order, only those orders should
be allowed.

For example, if sorting a page of results (as opposed to
returning a page of sorted results) makes no sense, then
specifying the sort control after the paging control should
not be allowed.

Where control processing of two or more controls doesn't
matter, those controls can be provided in any order.  For
example, order of ManageDSAit and Subentries controls are
independent of each other and hence can be specified in
either order.

Comments?

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 02 Oct 2002 19:13:58 -0700

At 05:40 PM 2002-10-01, Ramsay, Ron wrote:
>Actually, I think the stand should be that order is not important.

I don't see any reason why we should take a stand here,
especially given that any future extension specification
can override any stand we might take. 

We should, however, clarify whether the default ordering
semantics is "set" or "sequence" so that authors and readers
of control extension specifications don't have to guess
as to what semantics apply in absence of an explicit
statement as to what semantics apply.

Kurt