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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:04 AM 4/22/2004, Hallvard B Furuseth wrote:
>But the thing is, people don't seem to define extensions to announce
>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.

>Also, such a document would work out e.g. security considerations for
>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
>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.

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


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext