Subject: RE: "LDAP exchange" (was: Misuse of the term "association"in[Protocol])

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 26 Oct 2004 15:04:03 +1000

Come on Kurt, ante up. What line, exactly, in RFC 2251 prohibits a bind after an unbind on the same connection. For myself, I don't like it, but in order to interoperate with web single-signon applications, I have had to write code I was not proud of.

So , please, chapter and verse!

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 26 October 2004 14:38
To: Ramsay, Ron
Cc: Jim Sermersheim; Roger Harrison; [email-masked];
[email-masked]
Subject: RE: "LDAP exchange" (was: Misuse of the term
"association"in[Protocol])

At 08:31 PM 10/25/2004, Ramsay, Ron wrote:
>I would, except that unbind doesn't mean disconnect.

Earlier this month, in a thread titled "Unbind (Was: Lifetime of associations)" I stated (in response to your previous posts):
    In a couple of recent posts you implied it was okay for
    LDAP PDUs to be transmit by the client after sending an
    Unbind request and by the server after performing
    an Unbind operation.  Such behavior is prohibited in
    [Protocol] (as it was in RFC 2251).

Your response was:
    No, I wasn't. Nor would I.

    What I was thinking was that, an unbind can be sent at any
    time. It is possible that responses would have been sent
    by the server before it received the unbind request, so
    that the client could possibly receive (in a sense, legally)
    responses after sending an unbind. This comes down to the
    fact that the unbind is not acknowledged (yuck!).

How do you reconcile your response there to your response here?
Or are you merely noting that some clients do not adhere to
the LDAP TS here?

>There are (famous) LDAP clients which send an unbind and then reuse the connection to establish a new association. (Here, 'connection' means the underlying TCP/IP connection.) That's why I think 'association' is such a valuable term.
> 
>Ron
>-----Original Message-----
>From: Jim Sermersheim [mailto:[email-masked]]
>Sent: Tuesday, 26 October 2004 00:39
>To: Ramsay, Ron; Roger Harrison
>Cc: [email-masked]; [email-masked]
>Subject: RE: "LDAP exchange" (was: Misuse of the term "association"in[Protocol])
>
>I don't see Roger mentioning unbind. Remember that unbind is a misnomer and it really means 'disconnect'. Thus if an association has the same lifetime as a connection (as stated by Roger), then you are agreeing with Roger's statement.
>
>>>> "Ramsay, Ron" <[email-masked]> 10/24/04 11:39:08 PM >>>
>I don't think you can have an association after an unbind. Not if you are going to draw on X.500 for support.
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of Roger Harrison
>Sent: Monday, 25 October 2004 13:47
>To: Jim Sermersheim; [email-masked]
>Cc: Ramsay, Ron; [email-masked]
>Subject: RE: "LDAP exchange" (was: Misuse of the term "association" in[Protocol])
>
>After reviewing the current usage of the term "association" in protocol-27 and then reading and considering the various opinions expressed on the proper usage of the term, I have decided that every connection has an association that has the same lifetime as the connection. The association may pass through a number of states during that lifetime, and the bind operation is the way that a client can change that state. I have attempted to reflect this usage throughout authmeth-13, although I suspect that my effort may need a bit more work before it's as clear as it can and should be in this regard. 
> 
>Roger
>
>>>>Hallvard B Furuseth <[email-masked]> 10/05/04 10:08 am >>>
>Jim Sermersheim writes:
>>Then there is (or at least there was) the thought that we need to
>>provide a term which describes the association of the authN and authZ
>>state as it relates to Layer 4. Kurt's suggestion is that we don't need
>>to define (nor name) this. But that we instead update the doc in the
>>places he described. I agree with most of the changes, but the change to
>>Section 6 makes me feel like the term was useful, and we're rewording
>>just so we can drop the use of the term.
>
>My vote is to drop "association".  It doesn't seem very useful to define
>a term which is only needed once, and apparently this is the only place
>in [Protocol] which does need it.  I do like the current wording better
>than Kurt's, but I also dislike to require readers to remember more
>definitions than necessary.
>
>--
>Hallvard

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 26 Oct 2004 16:13:37 +1000

Hi Jim,
 
No, I'm pleased with the resolution. If an unbind closes the underlying connection then that is good news to me. (Sort of, we still have to support popular applications which expect different behaviour. I guess the N*S* server used to leave it to the client to close the connection.)
 
Sorry, Kurt, for the misunderstanding. I have been speaking from experience and not from the specifications.
 
Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Tuesday, 26 October 2004 15:50
To: Ramsay, Ron; [email-masked]
Cc: Roger Harrison; [email-masked]; [email-masked]
Subject: RE: "LDAP exchange" (was: Misuse of the term "association"in[Protocol])

I have to say, after reading RFC 2251, I don't see where an unbind requires that the connection be torn down either. So I took a look at RFC 1777 for a history lesson.
 
RFC 1777 uses the term "protocol session" they way [protocol] uses the term "LDAP association"
RFC 1777 says: "The function of the Bind Operation is to initiate a protocol session between a client and a server..."
RFC 1777 says: "The function of the Unbind Operation is to terminate a protocol session."
(see p.s. note)
 
RFC 2251 also uses the term "protocol session" the way [protocol] uses the term "LDAP association"
RFC 2251 dropped the language from the Bind Operation (obviously because Bind can be resent to 'change the state of the session' as Roger puts it.
 
The rub is:
 
RFC 2251 added: "Upon receipt of an UnbindRequest, a protocol server may assume that the requesting client has terminated the session and that all outstanding requests may be discarded, and may close the connection."
 
I don't know why this was added, but if the server may close the connection, is it reasonable for a client to attempt a bind after an unbund? How many LDAP v3 servers leave the connection intact after an Unbind?
 
[protocol] is more explicit than "may close the connection", and says "The function of the Unbind Operation is to terminate an LDAP exchange and close the connection". This does remove ambiguity and resolves some interoperability issues (i.e. RFC 2251 failed to specify the AuthN state of a protocol session post Unbind).
 
Ron, are you asserting that we should go back to RFC 2251 semantics, or RFC 1777 semantics. If we go back to RFC 2251 semantics (which are underspecified), we'll need to solve the problem I mentioned above, and likely some others (having to do with what behavior a client is to expect).
 
Jim
 
P.S. I have a hunch that v2 clients perfomes a connect and bind at the same time (in the same API). I also suspect that they performed an unbind and disconnect in the same API (I have no emperical evidence, I'm just guessing). I'm guessing that this behavior spilled over into v3 clients, except the v3 clients had to split bind and connect (or at least not attempt to connect if the connection was intact). But I assume they retained the unbind/disconnect behavior.
Obviously there are exceptions to my theory, I'm interested, which (famous) clients unbind and re-use the connection?

>>> "Ramsay, Ron" <[email-masked]> 10/25/04 11:04:03 PM >>>

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Tuesday, 26 October 2004 14:38
To: Ramsay, Ron
Cc: Jim Sermersheim; Roger Harrison; [email-masked] ;
[email-masked] 

Your response was:

>Cc: [email-masked] ; [email-masked] 
>>>> "Ramsay, Ron" < [email-masked] > 10/24/04 11:39:08 PM >>>
>>>>Hallvard B Furuseth < [email-masked] > 10/05/04 10:08 am >>>
>Jim Sermersheim writes: