[Standards] Stream Management and Acks (XEP-0198)
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
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
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
as to how you interpreted / handled this scenario.
More information about the Standards