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 >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
