[Standards] XEP-0198: Stream Management - Clarifications
dave at cridland.net
Mon Sep 19 08:20:33 UTC 2011
On Sat Sep 17 18:44:28 2011, Alexander Holler wrote:
> Am 16.09.2011 21:24, schrieb Dave Cridland:
>> On Fri Sep 16 17:58:17 2011, Kim Alvefur wrote:
>>> 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
>> No, that would be bad. I do not wish to second guess why I'm not
>> an <a/>, I just want to get one.
>>> 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/>.
>> I don't want to optimize the protocol for poorly written
>> implementations. If the other end is asking for lots of
>> acknowledgements, either send them or go talk to a different peer.
>> Send as many <a/> as you like, but at least one per <r/> received.
> I don't see any reason why there should be an error defined for.
> It's just like if you never get an return for an iq stanza. If the
> sender for an <r/> doesn't get an <a/> in whatever time he wants
> one, it's the sender of the <r/> decision what to do. It's extremly
> unlikely that a receiver of an <r/> is interested in an error, if
> he doesn't send an <a/> and through that clearly violates the MUST
> (send <a/>) in the XEP.
> And defining some arbitrary (response) time doesn't make sense
You don't appear to be disagreeing with me, but instead arguing about
something I've never mentioned.
I'm saying that receivers of an <r/> MUST send an <a/>. Receivers of
two <r/>'s MUST send one <a/> for each. If receivers of an <r/>
withhold an <a/>, that indicates some problem with the connection
(including application-level congestion).
If no </a> at all is sent, then the peer that's missing the <a/>
response might do all sorts of things to try to recover, up to and
including sending a timeout error, or simply dropping the connection
- and that seems entirely fine; either the connection or the other
peer is broken.
If a peer is sending lots of <r/>'s, then this is a poor
implementation, but you still MUST reply to each individually. Could
be there's been a period of congestion and you're actually seeing one
<r/> per minute coming through in a big bunch.
Introducing variance in whether or not to respond to an <r/> or not
simply breaks the protocol.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards