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.
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).
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" <Ron.Ramsay@ca.com> 10/25/04
11:04:03 PM >>>
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:Kurt@OpenLDAP.org]
Sent: Tuesday, 26 October 2004 14:38
To: Ramsay, Ron
Cc: Jim
Sermersheim; Roger Harrison;
ietf-ldapbis@OpenLDAP.org
;
h.b.furuseth@usit.uio.no
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:jimse@novell.com]
>Sent: Tuesday, 26 October 2004 00:39
>To: Ramsay, Ron; Roger
Harrison
>Cc:
ietf-ldapbis@OpenLDAP.org ;
h.b.furuseth@usit.uio.no
>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.
>-----Original Message-----
>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;
h.b.furuseth@usit.uio.no
>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.
>
>Roger
>
>>>>Hallvard B Furuseth <
h.b.furuseth@usit.uio.no >
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