[Date Prev][Date Next]
RE: "LDAP exchange" (was: Misuse of the term "association"in[Protocol])
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!
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, 26 October 2004 14:38
To: Ramsay, Ron
Cc: Jim Sermersheim; Roger Harrison; ietf-ldapbis@OpenLDAP.org;
Subject: RE: "LDAP exchange" (was: Misuse of the term
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.
>From: Jim Sermersheim [mailto:firstname.lastname@example.org]
>Sent: Tuesday, 26 October 2004 00:39
>To: Ramsay, Ron; Roger Harrison
>Cc: ietf-ldapbis@OpenLDAP.org; email@example.com
>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" <Ron.Ramsay@ca.com> 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.
>From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Roger Harrison
>Sent: Monday, 25 October 2004 13:47
>To: Jim Sermersheim; firstname.lastname@example.org
>Cc: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org
>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.
>>>>Hallvard B Furuseth <email@example.com> 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.