On Thu, Mar 19, 2009 at 04:35:17PM -0700, Justin Karneges wrote: > On Thursday 19 March 2009 16:08:00 Robin Redeker wrote: > > On Thu, Mar 19, 2009 at 01:49:31PM -0500, XMPP Extensions Editor wrote: > > > Version 0.6 of XEP-0198 (Stream Management) has been released. > > > > My main problem is to understand the purpose of being able to > > include u _and_ h in a <r> or <a> element. If each <r> has to be > > answered with an <a> OR <r> it seems a bit redundant to me to make > > two different elements. > > The reason there are two elements is because you may not want to request an > ack every time you bump the counter. For example, on an otherwise idle > connection, you could send <message> followed by <a>, and that's it, and the > other side has no obligation to ack anytime soon. Maybe after sending 50 > messages you'd throw an <r> out there just so you can finally cross off the > messages in your outbound queue. This is more optimized than having the > other side ack every message.
Well, if you don't want to request, just not send a new u attribute with the <s> element I proposed: C: <message/> C: <message/> C: <message/> C: <message/> C: <s u='4'/> S: <s h='4'/> Thats the same as this IMO: C: <message/> C: <message/> C: <message/> C: <message/> C: <r u='4'/> S: <a h='4'/> As the RFC says, an <r> can be acked by <a> or an <r> element with an 'h' attribute. So the real difference is only whether either an 'u' or an 'h' value is present in the <r> or <a> element. The receiving side of an u attribute knows that it has to tell the sender (with an h attribute) that it received that sequence number. Or do I miss something? Greetings, Robin -- Robin Redeker | Deliantra, the free code+content MORPG [email protected] / [email protected] | http://www.deliantra.net http://www.ta-sa.org/ |
