[Standards] XEP-0198 1.3rc2 amendments
stpeter at stpeter.im
Mon Jun 20 13:43:06 UTC 2011
On 6/18/11 10:00 AM, Matthew Wild wrote:
> 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'
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'
> 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
> 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.
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards