Sorry, this dropped off the bottom of my inbox (you're lucky it's only been 10 days, thank stpeter for reviving it).
2011/3/7 Winfried Tilanus <[email protected]>: > On 03/04/2011 10:07 PM, Matthew Wild wrote: > > Hi, > >> I'm not sure what the current status is of the BOSH termination flow. >> It seems the XEP hasn't changed though, so I thought I'd throw in my >> latest experiences. > > Thank you for bringing this up, this is imho indeed something in the > BOSH protocol that needs fixing. But this problem doesn't only apply to > the BOSH termination flow, it also applies to all errors in the BOSH > layer. For consistency of the protocol, I think we should deal with both > of them in an integrated manner. > >> Prosody was replying to the eldest held request with a >> type='terminate'. The XEP technically doesn't specify *which* request >> the terminate response should go to, though I'll admit that on a >> surface reading it seems it would imply replying to the latest >> request. This leaves open the question of what to do with older >> requests, it also breaks the overall BOSH principle of replying to the >> eldest request first. > > I have some considerations on this: > > The BOSH principle of replying to the eldest request first certainly > applies to the payload carried by the BOSH connection. Applying that > principle to the layer of the BOSH connection itself doesn't necessarily > make sense. Error conditions on the BOSH level and the termination of > the BOSH connection itself are logically related to the most recent > request made. So it would be logical to reply to those on the most > recent request. > Agreed. > And indeed the protocol isn't very clear. But when surface reading > indicates there should be replied to the most recent request, then that > is the protocol right now. I don't know if changing this would be good. > As I mentioned, my new approach works with Strophe and JSJaC - anyone who wants to test how their implementation handles termination with Prosody's new behaviour is free to contact me for a test account. This is so under-specified right now though, I don't see we can harm interop much by tightening it up a bit. >> Prosody's behaviour didn't properly deal with the last request (which >> is the one that had type="terminate"). I've now changed it so we have >> the following behaviour, which seems to work nicely with both Strophe >> and JSJaC: > > To fix the protocol so it fits all its possible interpretations seems a > bit awkward to me. Lets work out how it should work first and then fix > the implementations. > I'm just choosing one interpretation that works in the most cases :) >> - After all processing has been done, close any requests that are >> still open (again with type='terminate'), and finally the request that >> initiated the termination, as in the XEP. > > There is no need to add the "type='terminate'" to all empty bodies when > closing the request, just add it to the request where the reply should > be send to. Sending it to all requests makes the protocol sensitive to > interoperability issues. > Do you have any example interop issues? I found it much simplified implementation, and satisfies interop with the clients I was testing with. > I believe the cleanest fix to XEP-0124 would be: > - Clarify that BOSH errors and BOSH termination should be send on the > most recent connection. > - Clarify that on termination (by request or by error), the eldest > connection should closed by sending just an empty body (without > 'terminate'). > - Clarify that if there is any payload included in the terminate > request, the payload should not need any response from the service. > Minus not sending 'terminate', I agree with your points. Though on the last one - I think it should be *allowed* to send stanzas that generate replies, I see no harm in including such replies in response to existing open requests or the terminate request. Of course if the stanza is to another entity than the user's server, a reply really can't be expected. Regards, Matthew
