On 6/20/11 10:18 AM, Matthew A. Miller wrote: > 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 (-:
Fixed: http://xmpp.org/extensions/tmp/xep-0198-1.3.html http://xmpp.org/extensions/diff/api/xep/0198/diff/1.3rc3/vs/1.3rc4 http://xmpp.org/extensions/diff/api/xep/0198/diff/1.2/vs/1.3rc4 /psa
smime.p7s
Description: S/MIME Cryptographic Signature
