[Standards] XEP-0198 1.3rc2 amendments

Peter Saint-Andre stpeter at stpeter.im
Mon Jun 20 16:55:50 UTC 2011


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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110620/48b2f806/attachment.bin>


More information about the Standards mailing list