Re: Issues regarding LDAP Control

["Jim Sermersheim" <JIMSE@novell.com>]

I thought we had agreed in LDAPEXT, that both request and response type
controls are to be advertised in the supportedControls attribute of the
rootDSE. This may be useful in the event there is a set of controls,
where one of n controls may be returned in the response message. The
server would only advertise those response controls that it supports.
I'm not sure if there were more compelling reasons to advertise both.

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 03/13/02 10:11AM >>>
Here are a few issues I've found in review 4.12 of [Protocol]
and past discussions (many on LDAPext) regarding controls.


>4.1.12. Controls
>
>   A control is a way to specify extension information. Controls
which
>   are sent as part of a request apply only to that request and are
not
>   saved.

This likely should be generalized to apply to both request
and response controls.  Maybe something like:
   Controls which are sent as part of a LDAP PDU apply
   only to that PDU and are not saved.

>   
>        Controls ::= SEQUENCE OF Control
>   
>        Control ::= SEQUENCE {
>                controlType             LDAPOID,
>                criticality             BOOLEAN DEFAULT FALSE,
>                controlValue            OCTET STRING OPTIONAL }
>   
>   The controlType field MUST be a UTF-8 encoded dotted-decimal
>   representation of an OBJECT IDENTIFIER which uniquely identifies
the
>   control. This prevents conflicts between control names.
>   
>   The criticality field is either TRUE or FALSE and is only used when
a
>   control accompanies one of the following requests: bindRequest,
>   searchRequest, modifyRequest, addRequest, delRequest,
modDNRequest,
>   compareRequest, or extendedReq. The use of the criticality field
for
>   a control that is part of any other operation is ignored and
treated
>   as FALSE.

I think an alternative wording here might be appropriate.

    The criticality field is either TRUE or FALSE.  When the
    control is attached to a request which has a corresponding
    response, this field indicates whether the control is
    critical to the processing of the operation and is to
    be processed as follows: ...
        <insert with intention the pps describing this processing>


    For all other requests (such as abandonRequest and unbindRequest)
    and for all responses, the control is to be treated as
    non-critical regardless of the value of its criticality
    field.

>   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.
>   
>   If the server does not recognize the control type or it is not
>   appropriate for the operation, and the criticality field is TRUE,
the
>   server MUST NOT perform the operation, and MUST instead return the
>   resultCode unavailableCriticalExtension.
>   
>   If the control is unrecognized or inappropriate but the
criticality
>   field is FALSE, the server MUST ignore the control.
>   
>   The controlValue contains any information associated with the
>   control, and its format is defined for the control.
Implementations
>   MUST be prepared to handle arbitrary contents of the controlValue
>   octet string, including zero bytes. It is absent only if there is
no
>   value information which is associated with a control of its type.

>   This document does not define any controls. Controls may be
defined
>   in other documents. The definition of a control consists of:
>   
>   - the OBJECT IDENTIFIER assigned to the control,
>   
>   - whether the control is always noncritical, always critical, or
>     critical at the client's option,
>   
>   - the format of the controlValue contents of the control.
>   
    - the semantics imparted by the control.

>   Servers list the controlType of all recognized controls in the
>   supportedControl attribute in the root DSE.

I suggest this be reworded:
    Servers list the controlType of all controls they recognize
    in the supportedControl attribute [Models] in the root DSE.

The 'all controls' could be further clarified to 'all request
controls'
as servers only recongize request controls (they generate response
controls).

Additionally, we likely should note:
  Controls should not be combined unless the semantics of the
  combination has been specified.  The semantics of control
  combinations, if specified, are generally defined is the
  control specification most recently published.  In the
  absence of such a specification, the behavior of the operation
  is not defined.  Additionally, the order of a combination of
  controls in the SEQUENCE only matters to the processing of the
  operation if specification of this combination explicitly states
  ordering matters.
l