[Standards] XEP-0198 1.3rc2 amendments

Matthew Wild mwild1 at gmail.com
Sat Jun 18 16:00:59 UTC 2011


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



More information about the Standards mailing list