[Standards-JIG] rfc3920bis: Stanza Acknowledgements

Dave Cridland dave at cridland.net
Mon Nov 6 20:32:17 UTC 2006


On Mon Nov  6 20:20:44 2006, Michal 'vorner' Vaner wrote:
> > Also, I would replace "Acks SHOULD be sent as soon as possible 
> [...]" > with something like:
> > > Acks SHOULD be sent in a timely manner, however receivers MAY 
> delay > sending an ack for a short period in order to increase 
> efficiency. > Receivers MUST NOT delay sending an ack for more than 
> 15 seconds, > allowing the requesting peer to timeout the 
> connection after 30 > seconds.
> > > Rationale is that you want mandatory timeouts here, and I too 
> was a > little confused by what you meant there. Feel free to 
> adjust the > mandatory timeout figures. The idea is that a client 
> gets to be > assured that if it asks for an ack, if it hasn't had 
> one for 30 > seconds (in this case) the connection is dead.
> 
> IMHO, this should be configurable. I agree it is plenty of time for 
> most
> people. However, I would set it to some 3 minutes for myself. It 
> happens
> sometime I have a short (~1 minute) internet break. Now, I just get 
> all
> the messages after the internet starts again. This way, I would 
> need to
> reconnect and everyone would see I disconnected.

Good point. Okay, so supposing that 'r' took a number of seconds to 
send an ack within.

So, your client is configured to make that, say, 120. After three 
minutes, if you've still not seen anything, it's probably time to 
assume something has gone wrong. The other party might decide to ack 
immediately, if it wanted to.

This presents the question of what 0 means - does it mean "right 
now!", or should it be a special value meaning "whenever you like"? 
Do we have a minimal ack time, too?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - 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