Re: Outstanding operations after TLS closure/renegotiation

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

I wrote:
>Kurt D. Zeilenga writes:
>>At 12:02 PM 3/6/2005, Hallvard B Furuseth wrote:
>>>Kurt D. Zeilenga writes:
>>>> I am not sure it reasonable to prescribe a particular
>>>> behavior in these cases, (...)
>>>
>>> Whether or not to send a response if the connection is kept open
>>> needs to be prescribed, and should not be changed for LDAPv3.  Which
>>> means I must withdraw my suggestion to "correct" that for
>>> renegotiation.  Otherwise an old client which expects a reponse after
>>> renegotiation will hang if the server does not send the response.
>>
>> But a server was not obligated, IMO, to complete the operation
>> and hence never required to return a response.  The
>> server is free to suspend the operation until (explicitly or
>> implicitly abandoned).  Obviously, clients which hang on a
>> response can hang indefinitely.
>
> Technically true if you mean "in practice suspend forever", but by that
> logic a client ought to wrap every LDAP call in a local timeout.  That
> does not seem reasonable to me.  Or if clients are not supposed to need
> that for every call but only in some situations (like after TLS
> closure), we'd still have to say something about in which cases it must
> expect such behaviour.

Sorry, I forgot we were talking about ciphersuite renegotiation and not
closure here, and old vs new clients too.  So old clients not expecting
to need timeouts would break anyway.

New clients -- I've just been trying to think of a clean way to write a
client which makes use of a response with may or may not arrive.  In
some cases one could of course just wait for a while and then exit with
an error message.  But if one wants to try anything more complex, the
code quickly gets ugly.  In particular handling error responses from the
operations, which might e.g. have been attempted in the opposite order
from how they were sent.

-- 
Hallvard