On Jun 20, 2011, at 07:43 , Peter Saint-Andre wrote: > On 6/18/11 10:00 AM, Matthew Wild wrote: >> Hi, >> >> A few more small issues with XEP-0198 have come to my attention. >> >> The largest of them is that the XEP says the 'h' attribute is optional >> on <resume/>, I don't think this should be allowed because the server >> needs to know which stanzas the client received before its old session >> was disconnected so it can re-send them. After a resume is usually the >> only time stanzas can and should ever be re-sent. If 'h' is made >> optional at resume time then the server has to special-case the first >> <a> from a client after resumption, and also distinguish between >> stanzas it sent on the old connection(s) and on the new one. Many >> headaches lie this way, for a tiny convenience in the protocol. > > Having pondered it a bit, I think that's right. I suggest: > > ### > > To request resumption of the former stream, the initiating entity sends > a <resume/> element qualified by the 'urn:xmpp:sm:3' namespace. The > <resume/> element MUST include a 'previd' attribute whose value is the > SM-ID of the former stream and MUST include an 'h' attribute that > identifies the sequence number of the last handled stanza sent over the > former stream from the server to the client (in the unlikely case that > the client never received any stanzas, it would set 'h' to zero). > > Example 10. Stream resumption request > > C: <resume xmlns='urn:xmpp:sm:3' > h='some-sequence-number' > previd='some-long-sm-id'/> > > If the server can resume the former stream, it MUST return a <resumed/> > element, which MUST include a 'previd' attribute set to the SM-ID of the > former stream and MUST also include an 'h' attribute set to the sequence > number of the last handled stanza sent over the former stream from the > client to the server (in the unlikely case that the server never > received any stanzas, it would set 'h' to zero). > > Example 11. Stream resumed > > S: <resumed xmlns='urn:xmpp:sm:3' > h='another-sequence-number' > previd='some-long-sm-id'/> > > ### > >> Also in several places the XEP mentions Stream Management needing to >> be explicitly enabled in "both directions". I can't recall if this was >> the case in a previous version of the spec, but I don't believe it to >> be the case now - when enabled, both parties send and receive <r> and >> <a>. > > Correct.
After reading this rc3 draft twice, I think all of the "needs to be enabled in both directions" droppings are now gone. > >> Also some instances of "initiating entity" should be changed to >> "client" in the vein of the other recent edits to 1.3rc2. > > Done. > >> Additionally I think it might be worth adding a note at the very end >> of section 4, with words to the effect that there is no guarantee that >> an unacknowledged stanza was not in fact received by the peer - in >> other words, re-sending or otherwise dealing with unacknowledged >> stanzas has the potential to produce duplicates. > > How about this? > > ### > > Because unacknowledged stanzas might have been received by the other > party, resending them might result in duplicates; there is no way to > prevent such a result in this protocol, although use of the XMPP 'id' > attribute on all stanzas can at least assist the intended recipients in > weeding out duplicate stanzas. > > ### > >> Based on feedback I think we should add as the first item in the list >> at the end of section 5 something like: "The sequence values are >> carried over from the previous session and are not reset for the new >> stream.". > > Agreed. > >> The current first entry in that list (about retransmitting stanzas) >> may be deserve a little more explanation, e.g. with this text: >> >> [[ >> Upon receiving a <resume/> or <resumed/> element the client and server >> use the 'h' attribute to retransmit any stanzas lost by the >> disconnection. In effect, it should handle the element's 'h' attribute >> as it would handle it on an <a/> element (i.e. marking stanzas in its >> outgoing queue as handled), except that after processing it MUST >> re-send to the peer any stanzas that are still marked as unhandled. >> ]] (this also changes re-sending from SHOULD to MUST, which I believe >> is required to stop things going very wrong) > > That's better, thanks. > >> The final issue is that the schema needs updating - it says <r> can >> have a 'h' attribute, while the text (correctly) says it has none. > > Fixed. > > http://xmpp.org/extensions/tmp/xep-0198-1.3.html > > http://xmpp.org/extensions/diff/api/xep/0198/diff/1.3rc2/vs/1.3rc3 > > http://xmpp.org/extensions/diff/api/xep/0198/diff/1.2/vs/1.3rc3 > The changes look pretty good overall. I have the one nit from a different thread, which you've acknowledged already (-: - m&m
smime.p7s
Description: S/MIME cryptographic signature
