Re: [Standards] XEP-198 when to start counting?

[Jefry Lagrange]

Thanks, I can't believe I missed that. It is clear now.

On Fri, Jun 17, 2011 at 2:00 PM,  standards-requ...@xmpp.org wrote:
 Send Standards mailing list submissions to
        standards@xmpp.org

 To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.jabber.org/mailman/listinfo/standards
 or, via email, send a message with subject or body 'help' to
        standards-requ...@xmpp.org

 You can reach the person managing the list at
        standards-ow...@xmpp.org

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of Standards digest...


 Today's Topics:

   1. XEP-198 when to start counting? (Jefry Lagrange)
   2. Re: XEP-198 when to start counting? (Matthew Wild)
   3. Re: XEP-198 when to start counting? (Peter Saint-Andre)
   4. Re: XEP-198 when to start counting? (Matthew Wild)
   5. Re: XEP-198 when to start counting? (Peter Saint-Andre)


 --

 Message: 1
 Date: Fri, 17 Jun 2011 13:25:18 -0400
 From: Jefry Lagrange jefry.re...@gmail.com
 Subject: [Standards] XEP-198 when to start counting?
 To: standards@xmpp.org
 Message-ID: BANLkTi=rc_ey+kcnwxrt14yho-pllmj...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1

 When I test stream management with a prosody server, this happens:

 !-- Out --
 enable xmlns=urn:xmpp:sm:2 resume=true /

 !-- Out --
 iq type=set id=2
 session xmlns=urn:ietf:params:xml:ns:xmpp-session /
 /iq

 !-- In --
 enabled id='a8110118-42ec-485c-b386-85b2d12a02a1' resume='true'
 xmlns='urn:xmpp:sm:2'/

 !-- Out --
 r xmlns=urn:xmpp:sm:2 /

 !-- In --
 iq id='2' type='result'
 to='jt...@thiessen.im/919aece2-21f2-4fc4-9e02-ac522509_'/
 r xmlns='urn:xmpp:sm:2'/

 !-- Out --
 a xmlns=urn:xmpp:sm:2 h=1 /



 The client sent an IQ stanza before it received confirmation for SM
 negotiation enabled /. When should I start counting? When I send
 enable / or when I receive enabled /?

 Also in the XEP document, section 11.3 Stream Features. It says that
 The XMPP Registrar includes 'urn:xmpp:sm:3' in its registry of stream
 features at http://xmpp.org/registrar/stream-features.html. But at
 that URL you can't find 'urn:xmpp:sm:3', only 'urn:xmpp:sm:2' is
 there.



 --
 Jefry Lagrange


 --

 Message: 2
 Date: Fri, 17 Jun 2011 18:37:15 +0100
 From: Matthew Wild mwi...@gmail.com
 Subject: Re: [Standards] XEP-198 when to start counting?
 To: XMPP Standards standards@xmpp.org
 Message-ID: BANLkTi=jj4wwxm9cn_i2zfwlvth2utb...@mail.gmail.com
 Content-Type: text/plain; charset=UTF-8

 On 17 June 2011 18:25, Jefry Lagrange jefry.re...@gmail.com wrote:
 When I test stream management with a prosody server, this happens:

 !-- Out --
 enable xmlns=urn:xmpp:sm:2 resume=true /

 !-- Out --
 iq type=set id=2
 session xmlns=urn:ietf:params:xml:ns:xmpp-session /
 /iq

 !-- In --
 enabled id='a8110118-42ec-485c-b386-85b2d12a02a1' resume='true'
 xmlns='urn:xmpp:sm:2'/

 !-- Out --
 r xmlns=urn:xmpp:sm:2 /

 !-- In --
 iq id='2' type='result'
 to='jt...@thiessen.im/919aece2-21f2-4fc4-9e02-ac522509_'/
 r xmlns='urn:xmpp:sm:2'/

 !-- Out --
 a xmlns=urn:xmpp:sm:2 h=1 /



 The client sent an IQ stanza before it received confirmation for SM
 negotiation enabled /. When should I start counting? When I send
 enable / or when I receive enabled /?


 When you send enable/, if you're going to send stanzas before you
 receive enabled/.

 The XEP says this:

 
 The value of 'h' starts at zero at the point stream management is
 enabled or requested to be enabled, is incremented to one for the
 first stanza handled, and is incremented by one again with each
 subsequent stanza handled.
 

 ...which isn't too decisive, to say the least :)

 You should definitely start counting from when you send enable/,
 because it is from receiving that that the server starts counting on
 its end and because it has no idea at what time you, the client,
 receive the enabled/.

 Also in the XEP document, section 11.3 Stream Features. It says that
 The XMPP Registrar includes 'urn:xmpp:sm:3' in its registry of stream
 features at http://xmpp.org/registrar/stream-features.html. But at
 that URL you can't find 'urn:xmpp:sm:3', only 'urn:xmpp:sm:2' is
 there.


 Probably a communications failure between the XEP Editor and the XMPP
 Registrar :)

 Regards,
 Matthew


 --

 Message: 3
 Date: Fri, 17 Jun 2011 11:40:41 -0600
 From: Peter Saint-Andre stpe...@stpeter.im
 Subject: Re: [Standards] XEP-198 when to start counting?
 To: XMPP Standards standards@xmpp.org
 Message-ID: 4dfb9199.7050...@stpeter.im
 Content-Type: text/plain; charset=utf-8

 On 6/17/11 11:37 AM, Matthew Wild wrote:
 On 17 June 2011 18:25, Jefry Lagrange jefry.re...@gmail.com wrote:
 When I test stream management with a prosody server, this happens:

 !-- Out --
 enable xmlns=urn:xmpp:sm:2 resume=true /

 !-- Out --
 iq type=set id=2
 session 

[Standards] XEP-0198 1.3rc2 amendments

[Matthew Wild]

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