[Standards] Proposed XMPP Extension: Quality of Service

Matthew Wild mwild1 at gmail.com
Wed Dec 9 13:15:04 UTC 2015

On 9 December 2015 at 10:56, Dave Cridland <dave at cridland.net> wrote:
> 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 the key here is whether the XEP is defining a change in
behaviour to XMPP's standard message delivery, or merely defining a
standard way of encapsulating properties that messages have in other
protocols (MQTT and some other systems have QoS in this same model).

That is, if I'm publishing to an MQTT gateway over XMPP, I'd like to
be able to set the QoS of the message in a standard way, but the XMPP
server itself should pay no heed to the value. I'd be in favour of
this approach.

However, introducing the concept of QoS to XMPP itself is
fundamentally changing the protocol to a different model, and opening
up a whole can of worms. I'm not in favour of that.

I understand the pain if you're trying to make a 1:1 mapping between
XMPP and MQTT or any other protocol, but honestly, there isn't always
going to be a sane 1:1 mapping between any two protocols. You're quite
likely to end up with something overly complex that just makes
implementers grumble or avoid implementing it.


More information about the Standards mailing list