Subject: RE: RFC2251: unbind

From: "Salter, Thomas A" <[email-masked]>
Date: Tue, 15 Feb 2000 09:17:05 -0500

I'd prefer a protocol where only one side could initiate the normal
shutdown.  In this case the server should do that as a response to the
unbind.  The client should close in response to server-initiated close.
This would eliminate the various race conditions that exist otherwise and
make it easier to tell normal conditions from error conditions.

 > -----Original Message-----
 > From: Kurt D. Zeilenga [mailto:[email-masked]]
 > Sent: Monday, February 14, 2000 5:41 PM
 > To: [email-masked]
 > Subject: Re: RFC2251: unbind
 > 
 > 
 > At 08:41 AM 2/14/00 -0800, Kurt D. Zeilenga wrote:
 > >It seems that some folks are confused about the function of
 > >unbind.  We've likely have all heard the "don't I need to unbind
 > >before rebinding" enquiry.   Some have even noted that the
 > >disconnection requirements are MAY, not MUSTs.  Some have any
 > >stated that some servers do not terminate the connection upon
 > >receipt of an unbind request.
 > >
 > >It seems that some implementors don't take "The function of the
 > >Unbind Operation is to terminate a protocol session" as an absolute.
 > >
 > >I would suggest that the paragraph following this sentence
 > >for clarification:
 > >	A client SHALL NOT submit further requests after
 > >	sending an unbind request.  A client SHOULD terminate
 > >	the underlying TCP session after making the unbind
 > >	request.
 > >	A server SHALL NOT process nor respond to further
 > >	requests received after an unbind requests.  A
 > >	server SHOULD terminate the underlying TCP session
 > >	after receiving the unbind request.
 > 
 > Note that the existing paragraph allows the client to wait
 > for the server to initiate the TCP shutdown AND allows the
 > server to wait for the client to initiate the TCP shutdown.
 > There really should be at least one SHALL detailing who
 > must shutdown the connection and when. 
 > 
 > I revise my suggestion:
 > 	The client SHALL terminate the underlying connection
 > 	after submitting an unbind request.
 > 
 > 	The server SHALL terminate the underlying connection
 > 	upon receipt of an unbind request.
 > 
 > Comments?
 >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 16 Feb 2000 10:06:20 -0800

At 09:17 AM 2/15/00 -0500, Salter, Thomas A wrote:
>shutdown.

From the LDAP perspective, this is what we have.  The client
initiates normal shutdown by issuing an unbind request.  The
problem is that specification doesn't not mandate a particular
action after sending or receiving an unbind request.

>In this case the server should do that as a response to the
>unbind.

That response, IMO, should be to terminate the underlying TCP
session.

>The client should close in response to server-initiated close.

I believe it appropriate for the client to close the connection
as well.  The server can determine if the shutdown was ordered
or not by receipt of the unbind request.

>make it easier to tell normal conditions from error conditions.

I believe the race conditions that were noted have to do with
handling of outstanding requests on the server side.  Shutdown
when multiple outstanding operations are being processed is a
bit tricky but quite managable.

I believe the basic protocol is fine.  I think the problem is
just a matter of specification.  The specification should
describe an "LDAP Session" and how it relates to the underlying
transport protocol.  The document should describe how a
LDAP Session is initiated (by establishment of the underlying
transport protocol) and how an LDAP Session is terminated (by
shutdown of the underlying transport protocol). 

It should be careful not to imply that bind initiates a protocol
session and that unbind does not un-do a bind.