Subject: Re: protocol-22 comments

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 14:23:38 -0600

>>> Hallvard B Furuseth [email-masked]> 3/9/04 7:20:19 AM >>

>> 4.1.11. Controls
>
>> When an extension calls for a particular response control to be
sent
>> in response to a request control, the response and request controls
>> are termed to be "paired".
>> (...)
>> The controlType field is the dotted-decimal representation of an
>> OBJECT IDENTIFIER which uniquely identifies the control, or the
>> request control and its paired response control.
>
>These paragraphs seem to imply that a request control may only solicit
a
>response control with the same OID as the request control, 
>and it cannot
>solicit two response controls (with different OIDs). I think that's
>wrong.

You're right, it is often the case that a request is paired with a
single response which is identified by the same OID, but not the rule.
Also, there are a number of control specifications that return one type
of response control with search entries and a different one with the
search result done, thus I don't think the use of the term 'paired' is
helpful. I'll fix.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 14:40:21 -0600

>> Additionally, unless order-dependent semantics are given in a
>> specification, the order of a combination of controls in the
SEQUENCE
>> is ignored.
>
>This implies that controls (A, B) MUST behave identically with
controls
>(B, A). I think it should be, "the effect of the ordering of a
>combination of controls in the SEQUENCE is unspecified"?

When the control specification doesn't describe these ordering
semantics, interoperability problems arise where one server may
arbitrarily assign semantics to the order of two controls, and another
may not. Clients will come to expect behavior that is not specified.
 
Is there a reason for allowing order semantics as unspecified which
outweighs the interoperability problems that come with it?
 
Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 15:21:27 -0600

>>>> Hallvard B Furuseth <[email-masked]> 4/16/04 3:05:54 PM
>>>
>>Jim Sermersheim writes:
>>>>> Hallvard B Furuseth [email-masked] > 3/9/04 7:20:19 AM
>>
>>>> 4.1.11. Controls
SEQUENCE
controls
>Only a vague suspicion that it may put a burden on implementations. I
>wonder if the simplest way to be sure this requirement is obeyed
might
>be for the server to order request controls in ascending order by
Octet
>String Ordering Match, or something, before parsing them. Which seems
>a bit excessive to me.

If there are any two controls that in any way affect each other, and if
neither of the control specifications provide instructions on how they
are to interact with each other (and whether order matters when doing
so), then I think a server should fail the request as it has no idea how
to properly execute the operation.

>I'm thinking partly of controls that are executed one at a time
rather
>than setting a variable and acting on it later. 
 
Any given server implementation knows which controls it implements. It
also should be aware of any ways in which two controls on a single
operation might affect the operation's outcome (including whether
ordering changes the outcome). If the combination of controls is
underspecified, and ordering will affect the outcome, the server (if
following the rule in the current draft) should not process the
operation (at least that's my read of it).
 
>However, also consider
>what to do if the same control appears twice, but containing
different
>parameters, and the control is implemented by setting a variable for
the
>operation to that parameter. With the current text, the server is
>required to always pick e.g. the parameter with lowest value, instead
of
>just using the parameter in the last control. Or it could detect the
>situation and return unwillingToPerform, but then it will still need
>extra state info in order to notice the situation.

I think the text (though not explicitly) says the server should fail
this scenario (unless the control specification states what to do).
 
Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 15:08:35 -0600

I'll plan to update 4.1.10 to read:
 
>The referral result code indicates that the contacted server cannot or
will not perform the operation and that one or more other servers may be
able to. Reasons for this include:
>
>-	The target entry of the request is not held locally, but the
server has knowledge of its possible existence elsewhere.
>-	The operation is restricted on this server -- perhaps due to a
read-only copy of an entry to be modified.

I'll also update 4.5.3 and 4.5.3.1 (search result references) to
calrify that either referral or soSuchObject is returned depending on
the servers knowledge of the target object.

Finally, I'll remove the original referral instructions from Add since
it was the only other operation to mention returning referrals.

Jim

>>> Hallvard B Furuseth <[email-masked]> 3/15/04 12:54:19 PM
>>>
Kurt D. Zeilenga writes:
>At 03:40 AM 3/13/2004, Hallvard B Furuseth wrote:

>> I just noticed an error in 4.1.10 (Referral):
>> 
>>> The referral result code indicates that the contacted server does
not 
>>> hold the target entry of the request.
>> 
>> I suggest:
>> 
>> A referral indicates that the contacted server cannot perform the
>> operation, but one or more other servers can.
>
> Right, referrals are be returned when the server chooses to
> refer the operation to another server.

s/cannot/cannot or will not/ in my suggestion?
Then server A can refer to B and C, and the client chooses B which
refers to A and C, so the client detects a loop and gives up even
though
C might be willing to perform the operation. Whether we add "cannot or
will not" or not, maybe the text should alert implementors to this
possibility.

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 16:13:52 -0600

>>>> Hallvard B Furuseth <[email-masked]> 3/9/04 7:20:19 AM
>>>
>> 4.2. Bind Operation
>
>> Authorization is the use of this authentication information when
>> performing operations.
>
>No, authorization need not make use of the authentication
information.
>One could e.g. base it on IP addresses only (but only for read
>operations, I would hope:-)
>
>Nitpick: The word "use" is wrong. Putting the currently active
>authentication identity in LDAPResult.diagnosticMessage is "use" of
auth
>info, but not authorization. Not sure if this is worth bothering
with,
>though.
>
>> Authorization MAY be affected by factors
>> outside of the LDAP Bind Request, such as those provided by lower
>> layer security services.
>
>Here is a suggestion, though it's a bit long. Maybe the last sentence
>should be dropped.
>
>Authorization is the decision of which access an operation has to
>the directory. It may be affected by many factors, often including
>the association's authorization identity, which again was derived
>from or authorized via the authentication information.
>Authorization may be affected by factors outside of the LDAP Bind
>Request, such as those provided by lower layer security services.

I like the change but it still seems too specific. How about:
 
Authorization is the process of enforcing policy while performing
operations. Among other things, the process of authorization takes as
input authentication information obtained during the bind operation
and/or other acts of authentication (such as lower layer security
services).

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 17:59:03 -0600

>> 5.2. Transfer Protocols
>> This protocol is designed to run over connection-oriented, reliable
>> transports, with all 8 bits in an octet being significant in the
data
>> stream.
>
>That all bits in an octet are significant need not be stated; that's
>what anyone would assume unless the opposite was specified.

One would think so but...
 
We added this because some implementations are wrongly truncating
attribute values as they come off the wire, and subsequent client
complaints spurred many hours of discussion on the topic.