[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: control combination was: Re: protocol-22 comments)

To: John McMeeking <jmcmeek@us.ibm.com>
Subject: Re: control combination was: Re: protocol-22 comments)
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Sun, 09 May 2004 10:40:26 -0700
Cc: ietf-ldapbis@OpenLDAP.org
In-reply-to: <OFAB1BAB8C.7874D45B-ON86256E8D.0063CAD5-86256E8D.006739BA@ us.ibm.com>
References: <s09b759f.039@sinclair.provo.novell.com> <OFAB1BAB8C.7874D45B-ON86256E8D.0063CAD5-86256E8D.006739BA@us.ibm.com>
At 11:47 AM 5/7/2004, John McMeeking wrote:
>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
>protocol error.
><end of text>

I dislike use of "supported" here and, in particular,  I do not consider
it appropriate for an implementation to treat a well-defined combination
as a protocol error. 

>If the implementation supports the combination, honor the controls.  If the
>implementation does not support the combination, return protocolError.

unwillingToPerform would be more appropriate in this case.

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

I disagree.  In the former case, unwillingToPeform is more appropriate
as the semantics of the combination are well defined (as you note below).

>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
>protocolError.
>
>
>John  McMeeking
>
>
>"Jim Sermersheim" <jimse@novell.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.
>>
>> Jim
>>
>> >>> "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
>> >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
>>
>>
References:
- Re: control combination was: Re: protocol-22 comments)
  - From: "Jim Sermersheim" <jimse@novell.com>
- Re: control combination was: Re: protocol-22 comments)
  - From: John McMeeking <jmcmeek@us.ibm.com>
Prev by Date: Re: Active Directory question
Next by Date: Re: control combination was: Re: protocol-22 comments)
Index(es):
- Chronological
- Thread