[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: appropriateness of combination of controls (new suggestion)
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, <ietf-ldapbis@OpenLDAP.org>
- Subject: RE: appropriateness of combination of controls (new suggestion)
- From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
- Date: Tue, 11 May 2004 11:20:15 +1000
- Content-class: urn:content-classes:message
- Thread-index: AcQ220e6VNdHBw19SNOom8UXznTrDQAGTCiA
- Thread-topic: appropriateness of combination of controls (new suggestion)
Hi Kurt,
I disagree with this because you have changed the control semantics from:
- If you recognise this control you must honour it
to
- You may choose to ignore this control.
In general, I agree with Jim's remarks. Certain control combinations can be specified in RFCs.
However, where a novel combination of controls is received by a server, I think it would be OK for the server to process it, rather than respond in a technical way with an error result. Note that once you specify the a server MUST respond with an error, there is no way to subsequently legitimise the control choice.
On a personal note, I found the whole discussion of 'defined' very silly. Behaviour is either 'specified' in the usual places, or it remains unspecified. It cannot be 'defined' locally. That simply makes each server self-documenting, in a way.
Ron
-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
Sent: Tuesday, 11 May 2004 07:45
To: ietf-ldapbis@OpenLDAP.org
Subject: appropriateness of combination of controls (new suggestion)
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.