Subject: Re: [ldapext] 'client/session information' control

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 22 Apr 2004 01:03:05 -0600

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."
 
and the current ldap bis protocol document
"A control only affects the semantics of the message it is attached
to."

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).

Another way to affect these kinds of preferences on a longer-term basis
is to standardize schema for them, and allow clients to update their
preferences in the form of directory modifications. This gets tricky in
replicated environments and would probably be quite hard to get multiple
vendors to adopt in the same way. Forget I mentioned it.
 
Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 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?

Kurt

>- extensions which the client understands
> (e.g. the horrible ";range=0-999" attribute option recently
> discussed),
>
>- aspects of LDAP which the client prefers not to deal with, and
which
> a friendly server may omit or otherwise take care not to use
> (e.g. attributes with attribute options, or which cannot be
displayed
> as UTF-8),
>
>- whether the client will handle referrals or hopes the server
> will chain referrals,
>
>- preferred languages of error messages.
>
>One could stick anything in there, like time limits for non-search
>operations, or a command to convert all UTF-8 values to latin-3 and
>omit values that cannot be converted, but maybe it's better to stop
>somewhere.
>
>Besides, about things like the UTF-8->latin-3 conversion, it might be
>better to only specify what the server _may_ do, and not allow the
>control to say what the server _must_ do (so the control, if
supported,
>would never fail even when marked critical). Otherwise server
>implementors might feel free to only support clients which do support
>some extension which is incompatible with plain LDAP. Not that
>implementors don't do that anyway, but still...
>
>Comments?
>
>-- 
>Hallvard
>
>_______________________________________________
>Ldapext mailing list
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 22 Apr 2004 16:04:52 +0200

Jim Sermersheim writes:
> 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:-)

> (draft-sermersheim-ldap-chaining-02.txt) that deals with it (but on a

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.

>> It might be useful to define a request control which describes aspects

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Apr 2004 08:40:40 -0700

At 07:04 AM 4/22/2004, Hallvard B Furuseth wrote:
>client aspects, or at least not much.

I argue that all most extensions do announce client aspects.
For instance, a non-critical paged results control states the
client is willing to accept paged results.

>Maybe the threshold for defining
>such extensions is too high, I don't know.

I don't see defining a 'client aspects' control (or whatever) as lowering
the bar.  One would still need to 'specify' the aspect, and that will
involve much of the same steps as 'specifying' a control.  The only
difference, I think, is structure.

>setting up sessions defaults,

But combining the 'aspects' into one control is, aside from making
assumptions that each has like security considerations, also limits
how the 'aspects' can be used.  I would think 'aspects' would be
rather independent of each other, so having an mechanism to independently
specify them, like in controls, is good.

Of course, security considerations that your aspects control, as
well as separate 'aspect' controls, would share include those do to
the lack of data security protections whilst transferring it as part
of a StartTLS or Bind operation.

>so it would later be easier to get this

I see more cons than pros in introducing yet another framework.