[Standards] Proposed XMPP Extension: Quality of Service

Dave Cridland dave at cridland.net
Wed Dec 9 10:56:28 UTC 2015

My initial reaction to this is that it's not providing anything beyond the
state of the art, and it implies that <message/> delivery is highly
unreliable (and suited to flood messaging), which is rather worrying.

I think XEP-0198 provides sufficient reliability to traffic that the
additional overhead here is redundant, and we have XEP-0184 message
acknowledgements to provide end-to-end acknowledgement, too.

If <iq/> is used, you'll always get at-least-once, no matter the support
for 198 along the route.

To get exactly-once semantics, the protoXEP recommends the receiver has an
infinite-sized store of previously received message identifiers - if the
store ever expires old message ids, then it's potentially allowing multiple
copies of the request to come through, which is (presumably) highly

This could be avoided by having an if-not-modified-since semantic, which is
very useful in other cases beyond simple 1:1 QoS.

Overall, considering the above, I'm inclined to push back until I've
understood why existing methods are not suitable for the semantics this
specification seeks to provide.

On 8 December 2015 at 17:40, XMPP Extensions Editor <editor at xmpp.org> wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
> Title: Quality of Service
> Abstract: This specification describes a generic method whereby messages
> can be sent between clients using a predefined Quality of Service level.
> URL: http://xmpp.org/extensions/inbox/qos.html
> The XMPP Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151209/5b333644/attachment.html>

More information about the Standards mailing list