[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: draft-ietf-ldapbis-protocol - controls
At 08:49 PM 3/31/2005, Jim Sermersheim wrote:
>I believe the broad interpretation of "appropriate" leads to far more interoperability problems than the narrow view.
>
>I'm glad to see that you don't believe a control can be partially applied.
This, I think, needs to be made crystal clear.
>The fact is, every implementation is going to behave quite differently when it is allowed to either fail-over to ignoring a control or return an error which was caused by the application of that control.
The specification don't prescribe same behavior. The
specification prescribes syntaxes and semantics aimed
at allowing implementations to communicate requests
and responses allowing clients to receive service from
the server. If the client communicates that portions of
the request are not critical, the server should not only
be free to ignore those portions when responding, but
the server should be encouraged to ignore those portions
would lead to responses that deny service to the client.
Deny service will certainly lead to interoperability
problems as the protocol provides no mechanism allowing
the server to communicate which portions of the request it
couldn't deal with. Fallbacking is problematic as the
protocol has no mechanism to express how far to fallback,
or whether fallbacking would allow service to be provided.
>It will be extremely difficult to evaluate all error paths in code to determine whether the error could be allieviated by ignoring any non-critical controls that might be present. If one cooses not to do that, one could instead, upon encountering any error condition, ignore one non-critical control. If the operation still fails, one could ignore another non-critical error (and probably should un-ignore that first one). One could keep doing this until one has ignored enough non-critical controls (rolling back the transaction each time), until one determines that the operation is just going to fail no matter what, or until the the operation succeeds (one hopes one hasn't accidentally ignored a few non-critical controls that really wouldn't have caused the error)
>
>If the implementation instead, just performs some arbitrary pre-checks to make sure it's fairly certain that the control won't cause the operation to fail, it will never perform the same as another implementation.
The issue is not whether the operation will perform the same
on another implementation. The issue is whether the service
provided is within the prescribed possibilities. If the
client requested an operation with two non-critical controls
X and Y, then the service provided should be consistent with one
of the following prescribed semantics:
a) operation
b) operation+X
c) operation+Y
d) operation+X+Y
I would hope that servers recognizing both X and Y would try
to provide the "best" service possible. If they know that
they cannot provide operation+X+Y in a particular scenario,
and are able to detect that scenario up front, they should
by all means ignore one or both of the controls if by doing
so they can provide service. Since the client did not mark
X or Y critical, the server should assume that service
with a) semantics is better than service with b) or c) than
no d) service.
>Maybe I'm over-complicating or over-simplifying or over-thinking this?
>
>I rather doubt anyone is confused as to whether a control may be partially applied ? that's just silly, so I don't think we need to add language to that effect.
>
>I think the confusion has to do with what "appropriate" means.
>If the WG wants it to be more precicely defined, then let's come up with some wording. As it is, it just says appropriate. My only fear is that it will ultimately lead to worse interoperability.
I think s/appropriate/appropriate in the server's determination/
would be appropriately vague.
Now, maybe what we need is to clarify is servers should,
where feasible and consistent with semantics choices
of the request (e.g., no partial application of controls),
favor providing some service over providing no service.
>Jim
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 3/31/05 9:09:46 PM >>>
>I find this comment from Steve Kille interesting:
>Some extensions can safely be ignored without loss of service.
>Others will simply not work if they are not understood and
>need to be rejected. The criticality mechanism allows this
>to be communicated. This is particularly important in a
>store and forward messaging environment, or where
>directory requests are chained.
>< <http://www.openldap.org/lists/ietf-ldapext/199802/msg00088.html>http://www.openldap.org/lists/ietf-ldapext/199802/msg00088.html >
>
>I think the key point I and Howard are making is that by not
>ignoring a recognized and applicable (per the specification)
>non-critical control one cannot service, one causes an
>unnecessary and inappropriate loss of service.
>
>The language in RFC 2251 was:
>If the server recognizes the control type and it is appropriate for
>the operation, the server will make use of the control when
>performing the operation.
>
>I think it natural for implementors interpret "appropriate
>for the operation" in a broad manner, and I think it clear that
>many client and server implementors have interpreted "appropriate
>for the operation" in a broad manner. Narrow interpretations,
>such as viewing the language as a mandatory requirement
>for servers to "make use" of applicable controls they recognize
>leads to idiotic behavior.
>
>For instance, I could code an LDAP server to "recognize"
>every known request control but not support any of them.
>Under the narrow interpretation taken by the WG, my server would
>be obligated to turn unwillingToPerform (or some other
>appropriate result code). I do not believe this is what was
>intended by designers of LDAP. But regardless of their intent,
>the interpretation taken by the WG will lead to significant
>interoperability problems and hinder development/deployment
>of distributed directory services.
>
>What I think needs to be clarified is the above text is that
>the server is to perform the operation, the whole operation,
>as extended by the control. It cannot perform only part of
>the operation as extended by the control. This, of course,
>has some implications on distributed systems, but I argue
>that the server ability to ignore applicable non-critical
>controls is key to making such systems work in face of
>extensions... which is what I think Steve was hinting at
>in is 1998 ASID/LDAPEXT post.
>
>-- Kurt
>
>
>
>At 07:01 PM 3/31/2005, Howard Chu wrote:
>>Jim Sermersheim wrote:
>>>Sorry, if the operation is chained before being applied locally, don't change criticality.
>>>
>>>And yes, other options are to test the capabilities of the other agents/backends, and to perform the behavior locally when not supported (a server or frontend could do this with the sorting or vlv control, but would have to gather all entries first.
>>
>>The idea of testing the capabilities of the other servers/backends in advance really doesn't scale well. If you have a large distributed set of directory servers, where any server may be the frontend for yet another arbitrarily large set of servers, you may spend more time querying the capabilities (and getting unreliable answers) than actually processing the client's original request. Nor is this sort of thing properly cachable, since different servers with different capabilities may enter and leave the network at arbitrary times.
>>
>>Following this line of attack is futile. It imposes additional overhead on the servers to collect a type of information in which the client has absolutely no interest.
>>
>>There is nothing in RFC2251 that suggests the current LDAPbis interpretation is either intended or correct. Call me crazy, but I'd say a behavior that is fundamentally useless doesn't belong in the spec.
>>
>>> >>> Mark Ennis < <mailto:mark.ennis@eb2bcom.com>mark.ennis@eb2bcom.com > 3/30/05 12:13:20 AM >>>
>>>Jim Sermersheim wrote:
>>> > I believe this is what our chaining server does as well, though we
>>> > have talked about changing chained controls to be critical in the
>>> > past.
>>> >
>>> > I think your work around could be implemented and render (somewhat)
>>> > expected effects:
>>> >
>>> > Say a search operation has attached to it a non-critical control
>>> > (which the DSA supports). When the local DSA chains, it forces it to
>>> > be critical.
>>> >
>>> > If the operation was chained before the control was used in
>>> > processing the operation, then any resultCode returned from the
>>> > chained-to DSA would be preserved.
>>>Such as an unavailableCriticalExtension resultCode when the original
>>>request had no critical controls?
>>> >
>>> > If the operation was chained during operation evaluation after being
>>> > partially supported by the local DSA, and if the chained-to DSA
>>> > returned unavailableCriticalExtension, the operation could return a
>>> > different error (which would indicate that the operation could not be
>>> > completed as specified).
>>>Might work, although this strategy would lead to a difference in the
>>>results obtained depending on whether the server handles the chaining
>>>versus returning referrals and the client handling followup of the
>>>referrals.
>>>Possibly the question of "what result would a client get if it handled
>>>requests to each individual context?" is worth exploring. I would be
>>>inclined to think a client would send the same request to each context
>>>with the control marked non-critical (or not bother to send it to the
>>>contexts which do not advertise support for the control). This leads me
>>>to be inclined to have a server replicate this behaviour rather than
>>>return errors for non-critical controls.
>>> >
>>> >
>>> >
>>> >
>>> >>>> Mark Ennis <_ <mailto:mark.ennis@acm.org>mark.ennis@acm.org < mailto:mark.ennis@acm.org >_ > 3/29/05 6:11:00 PM >>>
>>> >
>>> > As indicated in the message Jim referenced, our server will ignore
>>> > the criticality flag of a control it recognises. However, this does
>>> > not entirely address the issue Howard raised.
>>> >
>>> > In a distributed environment, a server receiving a request may need
>>> > to chain this request to a number of other servers, where the support
>>> > of various controls in the different servers may be different. Where
>>> > a given server receiving a chained request does not support a
>>> > control, it will base its processing decision on the criticality of
>>> > the control. So even if the server which received the request from
>>> > the client can support a given control, the control will potentially
>>> > be ignored for some part of the result set. This results in the
>>> > effective behaviour of the server, which received the original
>>> > request from the client, ignoring the non-critical control for some
>>> > contexts, even though it does support the control. This is the way
>>> > our server effectively behaves.
>>> >
>>> > The only way around this, at present, would seem to be to force all
>>> > the controls in a chained request to be critical, which would seem to
>>> > be counter to the client's request that the processing of a
>>> > non-critical control is optional.
>>> >
>>> > Our policy is to handle controls, in general, in the way John
>>> > McMeeking described, which is to ignore unsupported and inapropriate
>>> > non-critical controls.
>>> >
>>> > - Mark.
>>> >
>>> > Jim Sermersheim wrote:
>>> >
>>> >>> From another vendor:
>>> >> _http://www.openldap.org/lists/ietf-ldapbis/200403/msg00055.html_
>>> >>
>>> >>
>>> >>
>>> >>>>> "Jim Sermersheim" < <mailto:_jimse@novell.com>_jimse@novell.com < <mailto:jimse@novell.com>mailto:jimse@novell.com >_ > 3/29/05 5:08:37 PM >>>
>>> >>>>>
>>> >>
>>> >>
>>> >> Our implementations do this:
>>> >>
>>> >> Is the control recognized and appropriate (as specified) for the
>>> >> operation? Yes, process the operation No, Is it marked critical?
>>> >> Yes, fail with unavailable critical extension No, Ignore the
>>> >> control and process the operation
>>> >>
>>> >> This has been discussed at length in the past, and consensus was
>>> >> that this was the original intent and that this is what should be
>>> >> conveyed in the new document.
>>> >>
>>> >> IIRC, there were interoperability side effects of allowing
>>> >> "appropriate" to mean anything the server wishes it to mean.
>>> >>
>>> >> Jim
>>
>>--
>> -- Howard Chu
>> Chief Architect, Symas Corp. Director, Highland Sun
>> <http://www.symas.com/>http://www.symas.com http://highlandsun.com/hyc
>> Symas: Premier OpenSource Development and Support