RE: new internet draft - LDAP Extensions Style Guide

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I agree with Kurt. The LDAP encoding of values (I thought) requires the use
of UTF-8. This is to avoid the need for negotiating the charset to be used.
If Shift-JIS is to be used then the encoding must be binary.

If Shift-JIS is to be allowed, the encoding of attribute values will have to
contain charset information. This would be good, for my next elaboration
would be to allow ASN.1 as an encoding of choice. Some work on the PDUs and,
voila!, DAP. (I'll help write the I-D!)

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 15 August 2000 11:13
To: Bruce Greenblatt
Cc: Rich Salz; ietf-ldapext@netscape.com
Subject: 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