[Standards] Proposed XMPP Extension: Quality of Service

Peter Waher peterwaher at hotmail.com
Thu Dec 10 10:40:45 UTC 2015

Hello Matthew.
Thanks for your comments. Please see my responses below.
> > 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. As I mentioned to Dave, it does not imply it is highly unreliable, just that it is somewhat unreliable, as are all asynchronous message protocols, even more so, if network connections no the client side is intermittent. If the propability of failure of transmitting a message is small, given suffient message, the probability of it occurring becomes high.
> 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). It's an interoperable way of performing reliable messaging, which is available in many other protocols, such as MQTT, but also several other queueing protocols, and added ontop of other (such as HTTP/Web services).
> 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. Correct. The servers involved are not involved, so to say :) (Unless the server publishes say a a queueing-component supporting QoS, but then it would be the component that would support the XEP.)
> 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. XMPP would work as normal. It would only affect clients that need to specify QoS levels.
> 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. In this case, its the feature of reliable messaging that is important. MQTT is a publish/subscribe protocol that uses reliable messaging. It's not a queueing protocol, like other MQ protocols, MSMQ or AMQP, etc. In this case, I need reliable messaging for, among other things, assuring that transactions are managed properly. In transactions there must be no unknown states, and they must be delivered exactly once. Another use case, if for building multi-client FIFO queues. I've built the proposal in such a way as to become a generic tool and reusable in many different cases. Inspiration comes from queueing protocols and IoT protocols. I hope you reconsider and approve of moving the proposal to Experimental. Best regards,Peter Waher  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151210/b2ac50e9/attachment-0001.html>

More information about the Standards mailing list