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. 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>. In light of both of the above, I propose changing: [[ 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 MAY include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the initiating entity (if stream management was being used in both directions); if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included. ]] to: [[ 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 also 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. ]] and the following paragraph (after the example) to: [[ 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. The <resumed/> element 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. ]] Also some instances of "initiating entity" should be changed to "client" in the vein of the other recent edits to 1.3rc2. 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. 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.". 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) 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. If there is nothing contentious in any of these changes and the Editor doesn't beat me to it, I'll try and submit a patch for the XEP. Regards, Matthew
