[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: new internet draft - LDAP Extensions Style Guide
At 12:36 PM 8/16/00 -0700, Bruce Greenblatt wrote:
>At 03:04 PM 8/16/2000 +0100, David Chadwick wrote:
>>>
>>> - 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
>>
>>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 :-)
>
>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