Re: returning to the previous state

G'day!

At 09:00 AM 5/19/97 -0700, Paul E. Hoffman wrote:
>At 8:41 AM -0700 5/19/97, Mark Wahl wrote:
>> . . . [lots of good description of the TLS setup and teardown] . . .
>
>>This appears to me to be a defect in the TLS specification. I would have
>>expected it to read something like:
>>
>>>   It _is_ required for the initiator of the close to wait for the
responding
>>>   close_notify alert before closing the read side of the connection.
>
>I agree with you that the TLS protocol should not let one side send a TLS
>message to another side that is no longer expecting it. My guess is that
>this crept in due to "separate port" thinking: after the client sent it's
>close_notify, it might immediately shut down the TCP connection. However,
>this seems to be the only place in the TLS spec (...I say hopefully...)
>that this kind of false assumption is made.
>
>>I wished to check with this mailing list on application use of TLS to see if
>>other protocol designers had encountered this same problem.
>
>Well, if we haven't yet, we certainly will, unless all the TLS 1.0 API
>designers take this into account and don't close the client side until
>they've heard the server's close_notify. I'd certainly like to see this
>change in TLS 1.1, if not in 1.0. TLS 1.0 is going to go into IESG last
>call soon, so we have time to bring this up and maybe get it fixed.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>

I guess, since my reading of that spec. is different, it needs clarification.
The way I read it is

  "The writer (i.e. client, sender) cannot consider the session successfully 
   closed until the reader (i.e. server, receiver) has acknowledged session-
   end with a close_notify reply.  If, however, the reader decides to close
   the connection prematurely for whatever reason, then it need not 
   necessarily wait for the writer's matching close_notify."

Regards,
Jim LW