[Standards] XEP-0198 1.3rc2 amendments

Matthew A. Miller linuxwolf at outer-planes.net
Mon Jun 20 16:18:25 UTC 2011


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110620/21a8c982/attachment.bin>


More information about the Standards mailing list