[Standards-JIG] rfc3920bis: Stanza Acknowledgements
Michal 'vorner' Vaner
michal.vaner at kdemail.net
Mon Nov 6 20:20:44 UTC 2006
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
> > Several stanzas MAY be acknowledged at one time by including
> >an 'n'
> > attribute in the <a/> element, set to the integer value of the
> > 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
> > acceptance, a server that is throttling stanzas MUST defer the
> > 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
> 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
Size: 189 bytes
Desc: not available
More information about the Standards