Subject: Issues regarding LDAP Control

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 13 Mar 2002 09:11:34 -0800

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 13 Mar 2002 21:43:26 -0800

[resend to fix a typo]

At 07:45 PM 2002-03-13, Timothy Hahn wrote:
><TJH>
>I guess I see this as "overly restrictive".  Why couldn't some control,
>specified as a part of one request, have "semantics" that made the
>effect of the control apply to other requests that come later in
>the connection stream?  If I'm reading the clarification right,
>it sounds like this would be DIS-allowed since the control that
>was sent as part of one LDAP PDU would "apply" to other PDUs.
></TJH>

Do you find the original text "overly restrictive" as well?

I don't think this or the original text was intended to
restrict the impact of an operation extended by zero or
more controls, but to restrict the impact of a control.

It can be said that a control only alters the semantics
of the message it is attached to.  This is not to say
that this operation cannot impact the processing of other
operations.

Maybe this sentence should be replaced with that, e.g.:
        A control only alters the semantics of the
        message it attached to.

Kurt

---

From: "Timothy Hahn" <[email-masked]>
Date: Thu, 14 Mar 2002 00:44:59 -0500

Kurt,

Your suggestion of using:

Looks OK to me.

Thanks,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

                      "Kurt D. Zeilenga"                                                                                                  
                      <[email-masked]>         To:       Timothy Hahn/Endicott/IBM@IBMUS                                               
                      Sent by:                    cc:       [email-masked]                                                     
                      owner-ietf-ldapbis@O        Subject:  Re: Issues regarding LDAP Control                                             
                      penLDAP.org                                                                                                         

                      03/14/2002 12:37 AM                                                                                                 

It can be said that a control only alters the semantics
of the message it is attached to.  This is not to say
that this operation may impact the processing of other
operations.

Kurt

---

From: "Jim Sermersheim" <[email-masked]>
Date: Sat, 16 Mar 2002 13:28:34 -0700

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" <[email-masked]> 03/13/02 10:11AM >>>

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