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