Subject: appropriateness of combination of controls (new suggestion)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 May 2004 14:45:13 -0700

I offer the following for WG consideration:

0)  Add to end of the first paragraph of 4.1.11.
 Implementations SHOULD only attach controls which are
 appropriate for the operation (as discussed in applicable
 specifications).

1) Insert new paragraph above the one which starts with
"The controlValue may contain information":

 When considering whether a control is appropriate for the
 operation, the implementation is not only to consider whether the
 control is attached to a message it was intended to be used
 with, but whether the control is being used appropriately
 in combination with other controls (of same or different
 controlType).

 When a server is faced with a sequence
 of controls which are not appropriate for the operation,
 the server may attempt, by ignoring any number of
 non-critical controls (including controls whose criticality
 field is to be ignored as discussed above), a sequence which
 is appropriate for the operation.  If such a sequence is found,
 the server is to make use of it when performing the
 operation.  Otherwise, servers are to fail the operation
 and, and for operations which have a response, indicate so by
 returning unavailableCriticalExtension (if any of the controls
 were marked critical) or protocolError (if the message is
 considered not well structured) or other appropriate result
 code.

 When a client is faced with a sequence of controls which
 are not appropriate for the operation, the client may
 attempt, by ignoring any number of controls, in order
 to make use of the response in its processing.  Alternatively,
 the client may treat the response as not well structured.

2) Remove the existing paragraph which starts with "Controls SHOULD NOT
be combined".

3) Replace as last bullet with:
	- optionally, semantics regarding combination of the
       control with other controls (of same or different
	controlType).  These semantics may rely on ordering
       of the controls in the sequence of controls attached
       to the message.

  It is noted that semantics of a combination of controls
  is generally found in the control specification most
  recently published.  In absence of a specification of
  a control combination semantics, implementors should
  generally regard use of the control in combination
  with other controls  as not appropriate for use in the same
  operation.  In presence of a specification which does not
  detail any order dependent semantics, the implementor is
  to regard the semantics as being independent on the
  order of controls.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 May 2004 15:35:57 -0700

At 2:45 PM -0700 05/10/2004, Kurt D. Zeilenga wrote:
>  is appropriate for the operation.

What does it do if there is more than one potential result,
depending on which of the non-critical controls it ignores?
Does it then fail the operation as ambiguous?  And does this
impose a burden on servers for a combinatorial calculation?

			regards,
				Ted Hardie

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 May 2004 16:05:09 -0700

At 03:35 PM 5/10/2004, Ted Hardie wrote:
>Does it then fail the operation as ambiguous?

Server's choice.  It the client requests X+A+B (X being a base
request, the client is asking that either:
        X+A+B
        X+A
        X+B
        X
be performed.  Otherwise, it should have marked either A or
B or both as being critical.  As it didn't, it specifically
requested the server to ignore controls are not approrpriate.

As A and B being non-critical controls, the server which
doesn't view A+B as appropriate for X can perform
        X+A
        X+B
        X

or fail to perform.  Note that, from an interoperability stand point,
failing is likely worse response as it not any of the four behaviors
the client asked to be performed.

>And does this impose a burden on servers for a combinatorial calculation?

No.  The servers is not obligated to attempt to find such a
sequence, and if the server does choose to attempt to find such
a sequence, it can use any algorithm (which doesn't cause
critical controls to be ignored).  Existing servers use simple linear
algorithm.

        operation = base semantics
        foreach attached control
          if control is recognized and appropriate for operation
           then operation += control semantics
           else ignore control if non-critical
           otherwise fail.
        perform operation

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 May 2004 15:03:34 +0200

Kurt D. Zeilenga writes:
> (...)

I've been thinking more about inappropriate response controls, and I
think even that text is too limiting.  Maybe we should say nothing about
them at all.  rfc2251 has no such concept, it only has inappropriate
request controls.

The client should be free to ignore any response control, whether or not
it is appropriate.  It should certainly be free to ignore unsolicited
response controls, and presumably it knows what it wants to do about
solicited response controls.

We could RECOMMEND to not act on ambiguous, unspecified response control
combinations, and to instead ignore one or more of the controls.

If we keep 'inappropriate for the operation', I think that should be
'inappropriate for the response', since an operation can get several
responses.  Also, remember to distinguish between different intermediate
responses as well as different extended responses.  BTW, in this context
it does make a difference whether the 'kind' of IntermediateResponse is
determined only by the responseName or also by information in the
responseValue, as previously discussed about IntermediateResponse.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 12 May 2004 09:54:44 -0700

At 06:03 AM 5/12/2004, Hallvard B Furuseth wrote:
>it is appropriate.

Exactly, re-read the suggested text. It allows any number
(including zero) of response controls to be ignored and,
unlike the text for the server, there is no requirement the
resulting sequence to be "appropriate for the operation".

>It should certainly be free to ignore unsolicited

The text applies equally well to unsolicited notifications (as
they are messages belonging to an operation form).

>combinations, and to instead ignore one or more of the controls.

Act in regards to the protocol?  or act outside the protocol?

>responses.

A response is part of the operation.  The control alters the
extends the response in a manner appropriate for the operation.

>Also, remember to distinguish between different intermediate
>responses as well as different extended responses.

Why?  Aren't they all part of some kind of operation?
(Again, I think of unsolicited notifications as being part
of an operation, in particular a request-less operation.)