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.
s/stanza/element/
(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
--
Peter Saint-Andre
https://stpeter.im/
