[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] 'client/session information' control
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" <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?
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
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext