Subject: Re: draft-ietf-ldapbis-protocol - controls

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 30 Mar 2005 07:07:03 -0700

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.

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

---

From: Howard Chu <[email-masked]>
Date: Thu, 31 Mar 2005 19:01:01 -0800

Jim Sermersheim wrote:
> 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 <_ [email-masked] <mailto:[email-masked]>_ > 
> 3/29/05 6:11:00 PM >>>
>  >
>  >> _http://www.openldap.org/lists/ietf-ldapbis/200403/msg00055.html_
>  >>
>  >>
>  >>
>  >>>>> "Jim Sermersheim" < [email-masked] <mailto:[email-masked]>_ 
>  > 3/29/05 5:08:37 PM >>>
>  >>>>>
>  >>
>  >>

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

---

From: Mark Ennis <[email-masked]>
Date: Fri, 01 Apr 2005 13:21:43 +1000

While I agree that the idea of testing the capabilities of the servers 
is not practical, I do think the idea of defining procedures for 
distributed operations which force controls to be critical and then 
process the results of distributed requests to form an appropriate 
response to the clients original request is potentially viable. This 
assumes that a control specification is not permitted to mandate that a 
control MUST be non-critical.

That said, I do agree that non-critical controls should be ignored 
rather then result in an error code for the operation. And this would 
simplify procedures for distributed operations for LDAP.

- Mark.

Howard Chu wrote:
>> 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.
> 
> 
>>  >>>>> "Jim Sermersheim" < [email-masked] 
>> <mailto:[email-masked]>_  > 3/29/05 5:08:37 PM >>>
>>  >>>>>
>>  >>
>>  >>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 31 Mar 2005 20:09:46 -0800

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>

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:
>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 <_ [email-masked] <mailto:[email-masked]>_ > 3/29/05 6:11:00 PM >>>
>> >
>> >>>>> "Jim Sermersheim" < [email-masked] <mailto:[email-masked]>_  > 3/29/05 5:08:37 PM >>>
>> >>>>>
>> >>
>> >>