[Standards] Stream Management and Acks (XEP-0198)

Nate Leon n8leon at gmail.com
Mon Nov 14 22:20:41 UTC 2011

In XEP-0198 / Section 4, we see this comment:

"When an <r/> element ("request") is received, the recipient MUST 
acknowledge it by sending an <a/> element to the sender containing a 
value of 'h' that is equal to the number of stanzas handled by the 
recipient of the <r/> element. The response SHOULD be sent as soon as 
possible after receiving the <r/> element"

One might ask, what happens if my side sends a request but never gets an 
ack in response?

Or maybe it's only been several minutes, but my sender continues to 
receive other stanzas on this session.

So first, we have the problem of putting limits around "as soon as 

i.e. how long should we wait until we decide to give up on the ack?

Assuming we do finally give up on receiving the ack, what should my side 
do about it?

It seems to be a clear violation of protocol given "the recipient MUST 
acknowledge..." clause,

but shutting down this connection seems overly harsh in this case.  (bad 

Furthermore, how do I know the other side even received my request?

Alternatively, my side could silently disable Stream Management for this 

since I don't have any way to communicate my unhappy state to the other 

While in this state, do I respond to request stanzas from the other side?

Or for a twist of irony, I can start to withhold my ack to see how they 
like it? ;-)

Of course, if the connection was interrupted in the future, and the 
other side attempts to resume,

my side can fail the request with an error, and things should proceed 
just fine.

The third option is to just ignore the case when we do not receive an ack.

We can just continue to send request stanzas, and respond to their requests.

This case seems the most reasonable, but kinda' takes the legs out from 
under the "MUST" in that section.

I'd appreciate hearing thoughts from others (especially those 
implementing XEP-0198)
as to how you interpreted / handled this scenario.


More information about the Standards mailing list