Re: control combination was: Re: protocol-22 comments)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:51 AM 5/7/2004, Jim Sermersheim wrote:
>So it seems there are three cases for a combination of controls:

I think there are only two cases relevant to protocol semantics:
  Are the semantics of the combination of controls defined or not?

The issue of where those semantics, when defined, are or should be
specified is orthonogal.

I think looking at it from the cases you outline may
be problematic, for instance:

>1) the combination is documented in a specification
  A specification can document that a combination of controls
  doesn't have a defined semantic.


>For #3, I think we are saying an error is returned.

I think we also need to state more clearly that the
combinations of undefined (or otherwise ambiguous) semantics
are not to be provided and, if provided, treated as a
protocol error.

>For #2, I think we need to state that behavior is undefined. This is
>because the lack of a specification can cause two implementations to act
>differently.

Here we're stating more what specifications of controls should
provide and how those specifications are to be interpreted if
they fail to provide it.  I think we need to separate this
issue from the above issue.

>If this is true, then we can use something like the following:
>
>"When a combination of controls is encountered whose semantics are not
>defined (or not known), the operation SHOULD fail with protocolError,
>otherwise the results are undefined."
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/7/04 9:24:44 AM >>>
>There is a subtle difference in the suggested text from the
>current text that might be, well, a bit too subtle.
>
>The current text talks about avoiding combinations whose
>semantics are not SPECFIED while the suggested talks about
>avoiding combinations which are not DEFINED.  While defined
>and specified are synonyms of each other, the latter can
>be viewed as implying there is a specification (e.g., document)
>where the semantics are defined, the former only can be viewed
>only as implying the semantics are defined (without regard
>to where they are specified).
>
>In the example of Sort+SignedOp, I think it can be argued that
>the semantics are defined even though they are not explicitly
>specified.  The intent of the text is not to prohibit such
>combinations.
>
>The text is intended to disallow use of combinations where the
>semantics are undefined, such as a combination of PagedResults
>[RFC2696] and VLV [draft-ietf-ldapext-ldapv3-vlv-08.txt].
>
>If I reading everyone's comment well, I think we have consensus
>on what we want to say but just haven't found the words that say
>it well enough.  Specific suggestions welcomed.
>
>Kurt
>
>At 06:02 AM 5/7/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>At 08:55 PM 5/5/2004, Jim Sermersheim wrote:
>>>
>>>> "server MUST NOT make use of a combination of controls whose
>semantics
>>>> are not defined (or not known to it). When such a combination of
>>>> controls is encountered, it is RECOMMENDED that the server return
>>>> protocolError. Otherwise behavior is undefined.
>>> 
>>> I dislike the wording as it could be taken as allowing the server
>>> not to return an error (as opposed to suggesting which code to
>>> return in this case). 
>>
>>I thought that was the intent, which looked reasonable to me.
>>
>>> How about?
>>>   Controls are not to be combined (with other controls
>>>   of same or different types) unless the semantics of the
>>>   combination have been defined.  When an implementation
>>>   (client or server) encounters a combination of controls
>>>   whose semantics are not defined (or not known to that
>>>   implementation), the implementation MUST treat the
>>>   request as a protocol error.
>>
>>Sounds too strict to me.  Or at least, it can be interpreted too
>strict.
>>For example, does that forbid the combination of the rfc2649
>Operation
>>Signature control with e.g. the rfc2891 Server Side Sorting control?
>>Neither document explicitly states how the combination should work,
>but
>>rfc2649 does say how to apply that control to LDAPMessages in
>general,
>>and the combination seems to make sense to me.
>>
>>Also, I wonder about the combination of controls defined in different
>>"standards repositories" or whatever one should call it.  If all
>>controls were RFCs, one control spec could list all previously
>defined
>>controls.  However, in the previous discussions of controls, people
>were
>>referring to controls that I could not find RFCs for.
>>
>>Finally, one detail: If we stick to RFC controls, each control author
>>will need to check all previous RFC controls.  It might be easy to
>miss
>>one, and make a control combination with an obvious semantics
>invalid.
>>We could fix that with a requirement that all LDAP control RFCs must
>>have the phrase "LDAP control" in its title.  Or someone (IANA?) 
>could
>>maintain an official list of published controls.  However, it seems
>>simpler to me to allow controls that obviously do not interfere with
>>each other, to be combined even if their specs do not say so.
>>
>>> (Note: I generalized this for both clients and servers,
>>> and for requests which don't have responses.)
>>
>>-- 
>>Hallvard