Subject: new internet draft - LDAP Extensions Style Guide

From: Bruce Greenblatt <[email-masked]>
Date: Fri, 11 Aug 2000 15:33:13 -0700

Please publish the attached personal submission.  This is my first time 
using the Word template.  Hopefully, it is in a suitable format...  Note 
that this draft is not a response to anything in particular.  It just 
contains some general observations from watching the traffic in the ldapext 
mailing list, the prior ldap mailing list, and participation in X.500 and 
the long lost X.400 standardization efforts.  Comments are welcomed.

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: Rich Salz <[email-masked]>
Date: Mon, 14 Aug 2000 11:48:39 -0400

>   The criticality field is only 
>   meaningful when the control is passed from the LDAP client to the 
>   LDAP server in the operation request.  LDAP clients ignore the 
>   criticality field in controls that appear in operation results. 

I didn't think we had consensus on whether or not this was the right
behavior. (We probably agree it's what currently happens.)

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Aug 2000 09:06:47 -0700

>behavior. (We probably agree it's what currently happens.)

Unless the server returns the response control without solicitation,
the criticality field is meaningless.  Unsolicited response
controls should be avoided (if not outright banded).

Kurt

---

From: Rich Salz <[email-masked]>
Date: Mon, 14 Aug 2000 12:20:09 -0400

I thought Harald and I had reasonable examples of unsolicited return
controls (e.g., "search results not legally binding" and "shift-JIS
encoded") that made sense.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Aug 2000 09:19:33 -0700

>encoded") that made sense.

I don't think they are reasonable at all.  A server should only
indicate such if the client indicated it supported such.

---

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 14 Aug 2000 14:19:04 -0700

>encoded") that made sense.

Hmmm... All that I got out of that was that if the client didn't understand 
the Japanese control then it would be gibberish.  Thus, the client could 
safely ignore the control... Perhaps we need a new control on the Bind 
operation that lists the Client's supported controls.  Then, the server is 
not allowed to send back any unsupported controls.

Bruce

---

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 14 Aug 2000 17:35:47 -0700

At 03:32 PM 8/14/2000 -0700, Kurt D. Zeilenga wrote:
>At 02:19 PM 8/14/00 -0700, Bruce Greenblatt wrote:
> >Hmmm... All that I got out of that was that if the client didn't 
> understand the Japanese control then it would be gibberish.  Thus, the 
> client could safely ignore the control... Perhaps we need a new control 
> on the Bind operation that lists the Client's supported controls.  Then, 
> the server is not allowed to send back any unsupported controls.
>
>Why not have the server list the controls in supports in the
>Root DSE and have the client solicit which controls it desires
>to be returned.

Isn't that almost the same?  What's the difference between having the 
client solicit the controls it desires, and listing the Client's supported 
controls on the Bind.  There's no real need for the Client to consult the 
Root DSE.  If the client just lists it's supported controls, the list can 
be canned rather than produced later on.  Also, this would allow controls 
to supplied and returned on the Bind, and other operations without having 
to retrieve the Root DSE entry... Bruce

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Aug 2000 15:32:14 -0700

At 02:19 PM 8/14/00 -0700, Bruce Greenblatt wrote:
>Hmmm... All that I got out of that was that if the client didn't understand the Japanese control then it would be gibberish.  Thus, the client could safely ignore the control... Perhaps we need a new control on the Bind operation that lists the Client's supported controls.  Then, the server is not allowed to send back any unsupported controls.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 14 Aug 2000 18:13:03 -0700

At 05:35 PM 8/14/00 -0700, Bruce Greenblatt wrote:
>Isn't that almost the same?  What's the difference between having the client solicit the controls it desires, and listing the Client's supported controls on the Bind.

We already have a requirement to list controls in the RootDSE.
We don't need a second mechanism.

> There's no real need for the Client to consult the Root DSE.  If the
> client just lists it's supported controls, the list can be canned
> rather than produced later on.

A control can only alter the behavior of the operation it is attached
to:
   RFC2251, 4.1.12: Controls which are sent as part of a request
   apply only to that request and are not saved.

Also, the list would not be protected by the bind negotiated security
layers.  And the client list of supported controls may depend
upon other session state information (for example the loss of
TLS may cause a number of controls to be no longer supported by
the client).

However, this issue aside, the primary reason that unsolicited controls
should be avoided is the simple fact that LDAP is suppose to be
a lightweight request/response based protocol.  Unsolicited control
require clients to deal with stuff they didn't request, this is
unnecessary and undue weight.

I note that the purpose of controls is to extend operations.  If
the client does not request extension, none should be provided.

I also note that if you want to enable some behavior over the whole
session, you likely need to define an extended operation.  For
example, you want requests/responses to use Shift-JIS instead
of UTF-8, define a Shift-JIS extended operation which changes
the encoding/decoding of future operations (allowing both
Shift-JIS DNs and error text) (yuk!).  Likewise for the other
contrived examples.

If I were (I'm not) to support Shift-JIS, I'd only support it in
attribute values and I'd use a ";shift-JIS" transfer option OR
extend directoryString to include Shift-JIS encoding and use
";binary".

Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 15 Aug 2000 17:43:58 +0100

I agree with Kurt that controls are there to modify individual 
operations and therefore putting them on the Bind is a nonsense. 
The client may perform some operations and not want the controls 
to take effect (e.g. duplicate entries) even though it supports them.

Thus a server should not send controls to the client if the client has 
not used them first on the operation. It follows from this that each 
operation request control needs to clearly specify which response 
controls may be applied by the server, but I guess we are already 
doing this in our extensions, although sometimes it might be implicit. 
This will need to be checked as the IDs move to proposed standard.

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: "David Chadwick" <[email-masked]>
Date: Tue, 15 Aug 2000 17:44:01 +0100

Date forwarded: 	Fri, 11 Aug 2000 15:38:27 -0700 (PDT)
Date sent:      	Fri, 11 Aug 2000 15:33:13 -0700
To:             	[email-masked]
From:           	Bruce Greenblatt <[email-masked]>
Subject:        	new internet draft - LDAP Extensions Style Guide
Copies to:      	[email-masked]
Forwarded by:   	[email-masked]

> Please publish the attached personal submission.  This is my first
> time using the Word template.  Hopefully, it is in a suitable
> format...  Note that this draft is not a response to anything in
> particular.  It just contains some general observations from watching
> the traffic in the ldapext mailing list, the prior ldap mailing list,
> and participation in X.500 and the long lost X.400 standardization
> efforts.  Comments are welcomed.

Bruce

one general and one specific comment regarding controls
On a general note, if the document is a style guide, it should give 
people general guidelines on how to produce IDs, but should not 
itself be defining new controls. i.e. the doc should only reference 
existing controls and not be defining new ones such as deferRoles 
and copySubtree. It should refer to other IDs in which these are 
defined.

A specific point is, can you add the sentence "when defining a 
control to be placed on an operation request, the specification must 
clearly specify which controls (if any) are allowed to be placed in 
the corresponding operation result"

David

David Chadwick

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 15 Aug 2000 13:10:49 -0700

>and copySubtree. It should refer to other IDs in which these are

David,

Thanks for the comments...

This draft does not define new controls or extended operations.  In some 
instances, in the absence of well written documents that create appropriate 
definitions, examples are given that use hypothetical controls, etc.  In a 
future version, I will clarify that fact.

>the corresponding operation result"

Good idea.  I will include verbiage to that effect in the next revision.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Aug 2000 13:18:27 -0700

>Good idea.  I will include verbiage to that effect in the next revision.

Just one comment on this comment... "when extending an operation though
definition of one or more controls, the specification SHOULD clearly
specify interactions with other, previously-defined, extensions
(using other controls).  The specification MAY NOT restrict further
extension of the operation by placement of additional, yet to
be defined, controls."

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 15 Aug 2000 13:29:45 -0700

>operations and therefore putting them on the Bind is a nonsense.

I would not say that it is "a nonsense".  As it stands now, the Bind 
Operation does have an affect on every succeeding operation.  For example, 
the identity and the authentication mechanism in the Bind will result in 
different privileges and levels of access to the directory information.  It 
seems natural to me to include at the time of the bind a list of Controls 
that the client is willing to accept from the server.  The alternatives are 
I see it are:

- don't ever let the client tell the server
- include a list of acceptable controls with each operation request, 
assuming that the server is really stupid, and
   can't remember the list from one operation to the next.
- define a new extended operation that allows the client to submit a list 
of acceptable controls

I seem to remember in one of the draft versions of RFC 2251 that there was 
a way to set client options/defaults.  I'd thought that it was in the Bind 
someplace, but was later dropped.  Maybe one of the Marks (Smith or Wahl) 
can remember better (not that history matters that much).  This gives a way 
of allowing for controls which are not specifically solicited to be 
returned by the server, without the client having to specifically request them.

Perhaps it doesn't matter too much (as you say below), if each control 
definition includes the list of valid other controls that may be returned 
in the response, and unsolicited, unsupported controls are always ignored 
by the client.   Hopefully, the interaction amongst controls will not 
become too complex in the future.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 15 Aug 2000 13:46:34 -0700

At 01:29 PM 8/15/00 -0700, Bruce Greenblatt wrote:
>... and unsolicited, unsupported controls are always ignored by the client.

The server MUST assume that an unsupported control received by
the client will cause undefined behavior as RFC2251 does not
define the behavior.  Hence, a server SHOULD NOT sent any
control to the client for which it does not known (via
whatever means) the client supports.

Kurt

---

From: "David Chadwick" <[email-masked]>
Date: Wed, 16 Aug 2000 15:04:32 +0100

> I would not say that it is "a nonsense".  

I thought I had given a good example of where it was not a sensible 
strategy to be adopted by a server, for example, using the duplicate 
entries control in a Search result when the client did not ask for it on 
the Search request, but had said on the Bind that it can support this 
control. It is completely inappropriate in my opinion for the Server to 
spontaneously change the behaviour of an operation without being 
asked to by the client.

My viewpoint is that a control is a "tweak" on an operation asked 
for by the client, and the server may be able to offer this "tweaked" 
service or not. But the server must always offer the standard 
service if no tweak is requested. 

> The alternatives are I see it are:
> 
> - define a new extended operation that allows the client to submit a
> list of acceptable controls

there is the obvious alternative missing from your list, which we 
have now, ie. the client specifies which control it wants on each 
individual operation :-)

David

David Chadwick

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Aug 2000 07:43:48 -0700

At 03:04 PM 8/16/00 +0100, David Chadwick wrote:

>control.

But please note that control upon on bind operation are
not protected by the privacy and integrity negotiated by
the bind operation itself.  This must be taken into
consideration.

Also, the Bind resultCode should be a clear indicate of authentication/authorization result and not overload with
extension negotiation.

Lastly, RFC2251 places specific restrictions upon the uses
of request controls which must be taken into consideration.

Controls upon the bind operation should be avoided.  Extended
operations is more suitable mechanism for extending "the session".
StartTLS is a good example of such.

Kurt

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 16 Aug 2000 11:23:09 -0700

>the bind operation itself.  This must be taken into

This is a good point.  I will add this to the Style Guide.  If controls are 
passed on the Bind that need privacy and/or integrity protection, a TLS 
session SHOULD be negotiated prior to the Bind.
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
See my new Book on Internet Directories: 
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Aug 2000 11:44:48 -0700

At 11:23 AM 8/16/00 -0700, Bruce Greenblatt wrote:
>This is a good point.  I will add this to the Style Guide.  If controls are passed on the Bind that need privacy and/or integrity protection, a TLS session SHOULD be negotiated prior to the Bind.

I suggest:
  Control information provided during a Bind or StartTLS
  operations are not protected by security services (e.g.
  privacy and/or integrity protection) negotiated by that
  operation.  If such services are desired (or required),
  they must be established prior to operation.

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 16 Aug 2000 12:36:30 -0700

>have now, ie. the client specifies which control it wants on each

But, that doesn't help the server in placing controls on notifications, and 
other controls not specifically solicited.  Of course, that may be a good 
thing...

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Aug 2000 13:43:39 -0700

At 12:36 PM 8/16/00 -0700, Bruce Greenblatt wrote:
>But, that doesn't help the server in placing controls on notifications,
>and other controls not specifically solicited.  Of course, that may be a good thing...

I think we need to refocus this thread on the Style Guide.
The Style Guide should impart our operational experience upon
the reader to help the reader design extensions.  I believe
the guide should state that unsolicited extensions (that is,
controls which client has not indicated support for)
are out of scope.  This should include notifications which
are returned without some prior indication of support by the
client.

We are gaining operational experience with notifications
which are returned only with prior indication of support.
In particular, my transaction/grouping I-Ds demonstrate the
use of notices; we hope to have operational experience soon.
There may other examples.

Note, however, we should be careful in regard to our operational
experience with the Notice of Disconnect in writing this guide.
Though Notice of Disconnect is an extended operation, it is not
an "extension".  That is, it is a integral part of LDAPv3.  And,
if anything, our operational experience has demonstrated that
returning this notice without indication of LDAP3 support can
be problematic. (In particular when the Notice is sent to an
LDAPv2 client before the bind request was received.  The client
often will report a protocol error, not a disconnect, to the
user.)

Kurt