[Standards] XEP-0124: terminate

Ian Paterson ian.paterson at clientside.co.uk
Wed May 30 00:30:30 UTC 2007

Mridul Muralidharan wrote:
> In our implementation, as soon as a subsequent request with next rid 
> comes in, we try to 'free' the current request.

Yes. That is the intended behaviour.

> So to answer your question - a subsequent (terminate) request will 
> 'free' the previous request and make it respond to client (possibly 
> with empty body).

Not just possibly, certainly.

If there was already something to send back before the terminate arrived 
then the other request would already have been responded to.

> And the latest request would finally close the session.

Yes. And to answer Peter's question, to quote from the spec, after 
receiving a terminate from the client:
"The connection manager SHOULD return an HTTP 200 OK response with an 
empty <body/> element. Upon receiving the response, the client MUST 
consider the HTTP session to have been terminated."

> Now, the other interesting question would be :
> What happens for retransmit requests after session has been terminated.
> We hold it around for 'some time' before kicking them off (not really 
> dependent on wait/inactivity time).

That's really nice of you. :-)

I agree it's an interesting question. I'm not yet sure we should force 
all connection managers to be as kind as yours - especially since 
providing a successful reply to a retransmit request under any 
circumstances is only a SHOULD, not a MUST.

Does anyone strongly believe that CMs SHOULD respond even after the 
client has terminated the session? If not (only MAY respond) then IMHO 
we could even leave this behaviour unspecified. [But that might be 
because I'm more lazy in the small hours of the night.]

- Ian

More information about the Standards mailing list