[Standards] XEP-0198: Stream Management - Clarifications

Peter Saint-Andre stpeter at stpeter.im
Fri Sep 16 16:33:27 UTC 2011

On 8/29/11 11:35 AM, Stephen Hill wrote:
> Hello,
> While reviewing XEP-0198 it was noticed an area in Section 4. Acks that
> may need some more clarification.  It states the following:
> "When an <r /> element ("request") is recieved, the recipient MUST
> acknowledge it by sending an <a /> element to the sender containing a
> value 'h' that is equal to the number of stanzas handled by the
> recipient of the <r /> element."
> The paragraph continues explaining under what circumstances an <a /> may
> be withheld, timeout only, but does not go into what the sender of the
> <r /> should do if it does not receive an <a /> for the sent <r />. 
> Since this is stream level protocol, it has been assumed that at some
> point the sender of the <r /> should send a <stream:error> to the
> recipient of the <r /> and close the stream.  This leaves the question
> of which stream error should be sent.  The stream error
> 'policy-violation'
> (http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-policy-violation)
> seems to be the most logical, as the recipient of the <r /> has violated
> the negotiated policies of the stream.  It would also allow for
> inserting an application-specific condition element signaling the
> violator to either attempt to resume the session, or abandon resumption
> and start anew.
> Proposed update to the section:
> If a recipient of an <r /> element does not send an <a /> response, the
> sender of the <r /> MUST send a stream error of type policy-violation
> and close the stream.  The sender SHOULD send an application-specific
> condition element of <request-not-acked />.

Seems fine. We'll need to define that application-specific condition in
XEP-0198, too.

> If stream resumption was enabled when enabling stream management, then
> the recipient MAY attempt to resume the stream.
> The sender SHOULD NOT error the stream if the next stanza is not an <a
> />.  The recipient side may have stanzas queued up for delivery and so
> may be in the process of delivering them when it receives and processes
> the <r /> stanza.  


(XEP-0198 elements are not stanzas.)

> It is RECOMMENDED that the sending side wait for some
> timeout period before sending the stream:error.  The timeout SHOULD be
> long enough for a given client time to clean out any queues.  Since this
> extension is to help establish continuity of communication, especially
> for clients that have inconsistent connections, providing some leeway in
> the form of time, and not immediately kicking due to delivery of stanzas
> other than an <a />, for a client to respond to an <r /> with an <a />
> is important to help with the spirit of the purpose of Stream Management.

Something along those lines seems fine to me.


Peter Saint-Andre

More information about the Standards mailing list