Re: LDAP Enhancement Style Guide

[Rob Weltman <robw@coscend.com>]

Bruce Greenblatt wrote:
> 
> >   Interesting about control extensibility. My first draft on the proxy
> > auth control didn't include extensibility hooks. It only specified the
> > fields required by the control as conceived. A couple of people suggested
> > that perhaps in the future it could be extended to passing other
> > credential fields, so I changed its value contents to a SEQUENCE in the
> > second revision. Then other people (well-known within LDAPEXT) said no,
> > that's wrong. An extension should result in a new control, rather than
> > additional fields in an existing control. So a subsequent revision
> > reverted to just specifying a single non-extensible credentials field.
> 
> OK.  If you allow for new fields in the control, and the meaning of the
> control doesn't change, why should you have to get a new OID and a new
> control.  I think that it is appropriate to allow for future
> extensibility.  If the client puts a field in a control that the server
> doesn't know about, how is that any different than the client putting a
> control in an operation that the server doesn't know about?

  I agree in principle, but in practice I think it varies. How is a client to know if the server understands the additional field? A client can check if a server supports a particular control by OID by reading the root DSE, but there is no way to check for a version of a control. In some cases it's OK; for example the field might indicate that the client wants the server to return some additional information besides the response implied by the "base" control fields, it can check the response to see if the additional info is there, and it doesn't matter much if it's not there. But in other cases it would not be acceptable - e.g. the operation is useless or worse to the client if the server doesn't understand the new field, or the client can't tell from the response if the server took the additional field into account or not.

Rob