Subject: Persistence of controls

From: "Steve Miller" <[email-masked]>
Date: Tue, 7 Sep 1999 12:39:48 -0400

Dear Authors,

RFC2251 says:

   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.

draft-ietf-ldapext-acl-model-03.txt says:

          7.2  specifyCredentials Control

          7.2.1  Request Control

             This control is included in  the ldap_bind  message as
             part of the controls  field  of the  LDAPMessage, as
             defined in  Section  4.1.12 of [LDAPv3].

		 ...

             The credential specifies the credential (e.g. groups,
             roles, etc) that the client is requesting be associated
             with the bind DN for access control determination in
             subsequent ldap operations.
		   ^^^^^^

There appears to be a contradiction here, since the acl-model wants to make
the control persistent at the server, while the RFC seems to disallow this.

Please advise. We would much prefer the acl-model persistence, at least for
bind operations, which are already maintain persistent state at the server.

Thanks,

Steve

Steve Miller                    Software.com, Inc.
[email-masked]       91 Hartwell Ave.
Phone: 781-274-7000x386         Lexington, MA 02173
Fax:   781 674-1080             http://www.software.com

---

From: "Roger Harrison" <[email-masked]>
Date: Wed, 22 Sep 1999 10:59:13 -0600

In the interest of generating some discussion on this, I'll propose the following:

It seems that one could argue that the Request  Control applies only to the bind request since the bind request is designed to set the identity of the connection. Its *effect*  applies to all subsequent requests on that connection once its identity has been established.  This would skirt the RFC2251 requirement.

Opinions?

Roger

>>> "Steve Miller" <[email-masked]> 09/07/99 10:41AM >>>
Dear Authors,

RFC2251 says:

   4.1.12. Controls

          7.2.1  Request Control

		 ...

Thanks,

Steve