On 9 December 2015 at 10:56, Dave Cridland <d...@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. Regards, Matthew _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
