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

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 07 May 2004 09:51:14 -0600

So it seems there are three cases for a combination of controls:
1) the combination is documented in a specification
2) the combination is not documented, but is defined to act in a
certain way in an implementation
3) is neither 1 or 2.

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

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.

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" <[email-masked]> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 May 2004 10:04:45 -0700

>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

>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.

>because the lack of a specification can cause two implementations to act

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 7 May 2004 19:03:51 +0200

> certain way in an implementation

What does (2) mean?  Someting like "the control specs do not document
the combination, but the implementation does"?

Will - and should - (2) cover the ManageDsaIT control from my later
post, and non-RFC controls like I mentioned?

> because the lack of a specification can cause two implementations to act

Yes, for (2) I think so... but I'll wait to hear what (2) means:-)
Similarly, I wonder what "not defined (or not known)" below means.

> otherwise the results are undefined."

If (2) is meant to be as liberal as my rewording above, we could add
something to the effect that operations also SHOULD fail if the
semantics of the combination of controls are ambiguous and not defined
in the control specs.  Or if you prefer, that implementations SHOULD NOT
define semantics for such combinations, which amounts to the same thing.

-- 
Hallvard