[Standards] XEP-0198: Stream Management - Clarifications
Matthew A. Miller
linuxwolf at outer-planes.net
Fri Sep 16 18:58:39 UTC 2011
On Sep 16, 2011, at 10:58, Kim Alvefur wrote:
> On Fri, 2011-09-16 at 10:33 -0600, Peter Saint-Andre wrote:
>> On 8/29/11 11:35 AM, Stephen Hill wrote:
>>> 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
>>> 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.
I can see the one sending multiple <r/>s willing to continue if it only got one <a/> back within it's allowable time. As long as it's still acceptable for the other side to still send an <a/> per received <r/> even if they received multiple <r/>s before sending their first <a/>.
Also, I think we might want to think about providing some (non-normative?) guidance on durations before erroring out here. In essence, what a sensible "annoying large" might be.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2238 bytes
Desc: not available
More information about the Standards