[Date Prev][Date Next]
Re: control combination was: Re: protocol-22 comments)
Is this any better? It still uses defined, but I'm hoping in a way that
the differences between defined, specified, and known that have been
discussed don't come into play. Maybe some examples should be included.
English leaves a lot to be desired as a precise language.
<start of text>
Controls are not to be combined (with other controls of same or different
types) unless the semantics of the combination have been defined and are
supported by the implementation. When an implementation (client or server)
encounters a combination of controls whose semantics are not supported by
that implementation, the implementation MUST treat the request as a
<end of text>
If the implementation supports the combination, honor the controls. If the
implementation does not support the combination, return protocolError.
A server could implement both the page control and the sort control, but in
such a way that they cannot be used in conjunction. The VLV + paged search
combination previously cited clearly makes no sense. In both cases, the
implementation should return protocolError.
The desired behavior of sort + paged search is well defined by RFC. Other
examples have been cited where the correct behavior seems clear but is not
explicitly defined (sort + signed op). If the implementation supports the
combination, it should honor the request.
Examples have been cited of control combinations that clearly make no sense
(VLV + paged). In these cases, the implementation should also return
"Jim Sermersheim" <email@example.com> wrote on 05/07/2004 12:39:49 PM:
> If there are only two cases (defined and undefined), then we need to
> state what 'defined' means.
> The whole point of this is to arrive at wording that promotes
> interoperability. So if one implementation twists 'defined' to mean
> one thing, and another twists it a different way, I think we failed.
> If 'defined' means that it is documented in one or more of the
> control specifications, that's good * it means the behavior is well
> documented. If it means something else (like it's defined in the
> implementor's mind), it's not so good.
> Futhermore, if 'defined' means that it is documented in one or more
> of the control specifications, then I think Hallvard hasa point * we
> need to allow for non-error behavior for combinations of controls
> that are not defined, but happen to make sense and likely work
> together in some current implementations. Otherwise, someone will
> need to update those control specifications to define combination
> semantics in order to make the combination valid.
> >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 5/7/04 11:04:45 AM >>>
> 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
> 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
> >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.
> >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
> >>>> 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
> >>For example, does that forbid the combination of the rfc2649
> >>Signature control with e.g. the rfc2891 Server Side Sorting control?
> >>Neither document explicitly states how the combination should work,
> >>rfc2649 does say how to apply that control to LDAPMessages in
> >>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
> >>controls. However, in the previous discussions of controls, people
> >>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
> >>one, and make a control combination with an obvious semantics
> >>We could fix that with a requirement that all LDAP control RFCs must
> >>have the phrase "LDAP control" in its title. Or someone (IANA?)
> >>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.)