[Standards] XEP-0198: Stream Management - Clarifications

Dave Cridland 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
>>> MUST.
>> No, that would be bad. I do not wish to second guess why I'm not  
>> getting
>> 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  
> (imho).

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
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list