[Standards] XEP-0124: terminate

Mridul Muralidharan mridul at sun.com
Tue May 29 22:27:36 UTC 2007

Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> Peter Saint-Andre wrote:
>>> Someone just pinged me via IM about session termination in XEP-0124:
>>> http://www.xmpp.org/extensions/xep-0124.html#terminate
>>> In particular, the spec doesn't say what a CM should return to the 
>>> client if there are outstanding requests (e.g., the client could 
>>> include things in the terminate request and the CM might receive a 
>>> response from the server or network but have nowhere to send them). 
>> It seems that I misunderstood the person I was chatting with. He meant 
>> that there are outstanding HTTP requests, not that there are 
>> outstanding XMPP requests (this is at the BOSH level, not the level of 
>> XMPP). So let's say that in the current session the BOSH client is 
>> limited to two simultaneous requests (requests=2) and one held request 
>> (hold=1). Now assume that there is already one request on hold. The 
>> client sends a terminate request. Two questions arise:
>> 1. Does the CM accept the terminate request (rather than returning an 
>> error because the client is over its number of held requests) or does 
>> it return an error?
> Well we already have an answer to that question, there is an exception 
> for type='terminate' requests here:
> http://www.xmpp.org/extensions/xep-0124.html#overactive
> (It's cool that we have this stuff spec'd out, now I just need to read 
> the specs before posting to the list... ;-)
> So the remaining question is what to do with the outstanding held request:
>> 2. If the CM accepts the terminate request, what does it do with the 
>> outstanding held request? Send it to /dev/null?
> /psa

In our implementation, as soon as a subsequent request with next rid 
comes in, we try to 'free' the current request.
This is done since typically webapps have very limited number of 
connections they can make to the backend and even if hold > 1, it tends 
to be practical to assume it is 1 (since they would be part of a larger 
So to answer your question - a subsequent (terminate) request will 
'free' the previous request and make it respond to client (possibly with 
empty body). And the latest request would finally close the session.

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).


More information about the Standards mailing list