[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] comment control, dummy request, no-response request

At 02:30 PM 2/22/2005, Hallvard B Furuseth wrote:
>"Comment" control:
>
>It can be useful to attach a comment to an LDAP request.

For what purpose?  Tracing or other?

>The intent would be to log the comment with the request in
>the server log, to help analyze the logs.

Sounds like tracing to me.

(The point of me asking the above question is to have you
narrow the purpose of the control to one thing.)

>Does a spec for such a control exist?  If not I'd like to
>define and implement it.

I'm not aware of such.  I suggest you call it the "trace"
control (a control which provides "trace information).
I can see providing trace information useful in a number
of applications, namely in testing.

>I'm not sure how to define the controlValue, though.

I would suggest the controlValue as holding an LDAPString
providing arbitrary trace information.

>Usually an
>LDAPString would be natural, but sometimes one may want to attach data
>with no defined or known character set.

Hmmm... if more information than a character string is desirable,
I'd argue that the application being served likely should use
a different control specifically designed for its needs. 

>So a plain OCTET STRING might
>be better, to be interpreted at the server admin's discretion.

I rather say that the information provided is to only be used
for trace purposes and is not to be otherwise interpreted or
used.


>Or one could mix both to make pretty logging a bit simpler in the
>case it is an UTF-8 string:
>
>   CHOICE {
>     text    [0] LDAPString,
>     octets  OCTET STRING,
>     ...
>   }
>
>
>"Dummy" extended operation:
>
>Has anyone defined a dummy extended operation, which does nothing except
>whatever the attached extensions say? If not, would anyone else like to
>see it defined?

I am not sure this makes sense, which I will illustrate below.

>A client can want do issue a request solely for the sake of the attached
>controls.  To enter a note in the log with the "comment" control.  To
>test if the currently bound user can proxy for a given authorization ID
>with the Proxy Authorization Control (draft-weltman-ldapv3-proxy-12.txt).

Well, say there was an operation which did nothing.  A server
might allow anyone to do nothing, and allow anyone to proxy as
anyone as long as nothing was being done.  That is, the authorization
model may only have an impact when something is being done,
or some piece of information is being accessed.

And, in particular, the user cannot assume simply because:
        nothing+proxied(u:foo)
was successful that:
        something+proxied(u:foo)
will not fail (with any error specific to the proxied authorization
control, or otherwise).  That is, one cannot (in general)
reliably use the results of one operation to predicate the outcome
of another operation.  A notable exception (with limitations and
caveats) is an operation with noop v. that operation less no-op.

>To use the "assert" control (draft-zeilenga-ldap-assert-05.txt) if one
>wants to check an entry against a filter and the compare operation is
>insufficient.  Using "assert" instead of baseobject search avoids one
>returned PDU.  I suppose such an operation could at times also be useful
>to keep the server from timing out the LDAP connection.
>
>ExtendedRequest.requestValue, if present, would be an LDAPDN packed in
>the requestValue OCTET STRING, so that controls that act on a DN will
>know which DN to act on.

Why not just use a compare(dn,ObjectClass,"top")?

But note that compare+proxied(authzid) success does not imply
that some other operation (including other compares) +proxied(authzid)
will not fail with a proxy authorization failure.

>"No-response, dummy" operation:
>
>This one is pretty marginal.  I could define such an operation too if
>anyone feels a need for it, but otherwise I won't bother.
>
>For use with the comment control, it could be convenient with a dummy
>operation which did not return a response.  I can't think of other
>instances to desire a dummy no-response operation at the moment.
>
>ExtendedRequest does not support no-response operations.

A specification is free to utilize ExtendedRequest in design
of a no-response operation.  It would not be an "Extended Operation"
as defined in [Protocol], as that described as having a response.
But there is no text in [Protocol] that precludes the use of
ExtendedRequest in design of response-less operations.

To put it another way, the LDAP TS does not limit the scope
and/or nature of extensions to LDAP.

>One could
>define a new request type, or fake it with abandon of an unused message
>ID (e.g. msgID 0), or define a critical control which cancels the effect
>of Abandon.  Kurt's "noop" control could be extended to be used with
>Abandon, but that would probably only be useful with no-effect controls
>like "comment".  So that usage seems even more marginal.

I think it generally unwise to attach semantics onto
operations created through use of controls which are not
consistent with the base operation.   Seem you'd need a
new operation here.


>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