[Standards-JIG] rfc3920bis: Stanza Acknowledgements
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
> people. However, I would set it to some 3 minutes for myself. It
> sometime I have a short (~1 minute) internet break. Now, I just get
> 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 Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards