[Standards] XEP-0198: Stream Management - Clarifications

Kim Alvefur zash at zash.se
Fri Sep 16 16:58:17 UTC 2011

On Fri, 2011-09-16 at 10:33 -0600, Peter Saint-Andre wrote:
> 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.

I think it shouldn't hurt if <r/> meant "I'd really like you to send an
<a/> now, please", and the other party SHOULD reply with <a/>, but not
MUST. If an implementation for whatever reason sends a whole bunch of
<r/>s at the same time, then why reply with more than one <a/>. Also, if
you have a long inbound queue, rate limiting or just a slow connection,
the other end might misinterpret that as a failure to ack. A new error
condition seems overkill to me. But if an implementation doesn't send
any <a/>s at all, causing the unacked queue to become annoyingly large,
policy-violation might make sense.

Kim Alvefur <zash at zash.se>

More information about the Standards mailing list