[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] 'client/session information' control
Jim Sermersheim writes:
> One problem with this approach (controls that affect the session) is the
> language in RFC 2251 "Controls which are sent as part of a request apply
> only to that request and are not saved."
True. I hoped to avoid a request/response roundtrip before the client
can send its first Bind/StartTLS, but perhaps not. Besides, there might
be setup options which one does not wish an unprotected connection to be
able to set up for a protected connection, so maybe Start TLS and SASL
Bind should discard some of this information and revert to the default
state.
OTOH, it would be nice to specify e.g. preferred language for error
messages from the first Bind or StartTLS. Maybe both a control and an
extended operation could be defined, with the same syntax:-)
> For the third example below (refer vs. chain), there is an I-D
> (draft-sermersheim-ldap-chaining-02.txt) that deals with it (but on a
> per-operation basis).
I'll have a look at that. At first glance, a session default seems more
convenient to me, though it would be nice to be able to set it per
operation too.
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/22/04 12:38:46 AM >>>
>At 02:52 PM 4/21/2004, Hallvard B Furuseth wrote:
>
>> It might be useful to define a request control which describes aspects
>> of the client or the session to the server, e.g.
>
> How does that differ from using separate request controls
> (or other existing form of solicitation) where each which
> identifies a particular aspect of the client?
Mostly it doesn't. Except if we make it an extended operation and not a
control: then it will be an advantage to be able to send - and wait for
the response to - one operation instead of a whole series of them.
But the thing is, people don't seem to define extensions to announce
client aspects, or at least not much. Maybe the threshold for defining
such extensions is too high, I don't know. An existing framework for
announcing client aspects would make that easier, and it might encourage
developers to make use of it, instead of just blindly expecting a client
to support some extension.
Also, such a document would work out e.g. security considerations for
setting up sessions defaults, so it would later be easier to get this
right when defining some specific session default. For example, a
setting should normally be reset after StartTLS. The design of this
extension might also encourage other extensions to not be too badly
designed, if they try to fit into the framework for this one.
--
Hallvard
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext