[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: new internet draft - LDAP Extensions Style Guide
At 05:35 PM 8/14/00 -0700, Bruce Greenblatt wrote:
>At 03:32 PM 8/14/2000 -0700, Kurt D. Zeilenga wrote:
>>At 02:19 PM 8/14/00 -0700, Bruce Greenblatt wrote:
>>>At 12:20 PM 8/14/2000 -0400, Rich Salz wrote:
>>>>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.
>>>
>>>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.
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