[Standards-JIG] rfc3920bis: Stanza Acknowledgements

[Michal 'vorner' Vaner]

Hello,

On Mon, Nov 06, 2006 at 04:41:03PM +0000, Dave Cridland wrote:
> Thanks, this looks like a great start.
> 
> On Sun Nov  5 02:12:41 2006, Justin Karneges wrote:
> >  7. When a stanza is received, containing an 'r' attribute 
> >("request ack")
> >     with a value of "true", the recipient MUST acknowledge the 
> >stanza by
> >     sending an <a/> element qualified by the
> >     'urn:ietf:params:xml:ns:xmpp-ack' namespace back to the sender.
> >     Stanzas not containing an 'r' attribute MUST NOT be 
> >acknowledged.
> >     Several stanzas MAY be acknowledged at one time by including 
> >an 'n'
> >     attribute in the <a/> element, set to the integer value of the 
> >number
> >     of stanzas.  An ack indicates stanza acceptance, in that the 
> >stanza is
> >     now safe in the receiver's hands and that the receiver will 
> >take care
> >     of it from that point.  Acks do not indicate successful 
> >delivery to a
> >     remote entity beyond the receiver.  The sender does not have 
> >to wait
> >     for an ack to continue sending stanzas.  Acks SHOULD be sent 
> >as soon as
> >     possible, and MUST NOT be withheld for any condition other 
> >than a
> >     timeout. For example, a client with a slow connection might 
> >want to
> >     collect many stanzas over a period of time before acking, and 
> >a server
> >     might want to throttle incoming stanzas. As acks indicate 
> >stanza
> >     acceptance, a server that is throttling stanzas MUST defer the 
> >acks
> >     until the client is no longer being penalized.
> 
> Okay, here I diverge more... I would say that a receiver MAY send an 
> ack even if not requested, if it is also sending other stanzas. I'm 
> not wedded to this by any means, but it might be nice. The intention 
> here is to allow a receiver to plonk an <a/> onto the end of a packet 
> if it's sending. An alternate here would be to give several possible 
> values for 'r', indicating whether you want an ack at all, and if you 
> do, whether "sometime" or "immediate". I'm not wedded to that either, 
> but I'd love to see some discussion.
> 
> 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.

-- 
This email has not been checked by an antivirus system.
No virus found.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20061106/4334c517/attachment.pgp