Hello Dave Thanks for your comments. I've responded to your concerns 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. Not > really. It's part of a mechanism called "reliable messaging", and is > available for all sorts of protocols, even HTTP. (MQTT is mentioned in the > proposal, but it definitely not limited to MQTT, it was just an example.) > Reliable messaging is available in most protocols supporting queueing, where > an item can only be delivered once, and exactly once (or, the sender receives > a notification that it was not possible to deliver). It is used in cases > where retries are not sufficient. This includes all non-idempotent actions, > such as counting (including bank transactions) or accumulation, as opposed to > absolute-valued information (such as set on/off, or set to N%) which are > idempotent. All asynchronous communication protocols are somewhat unreliable, > especially if clients have intermittent network connections. While its > improbable that a client disconnects while a message is being transmitted, it > can happen. And if many messages are sent, it finally will happen. > > 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. "sufficiently > reliability" depends on use case, it's completely subjective. For chatting > maybe. Not for monetary transactions. The proposal outlines a mechanism > (taken from reliable messaging) that makes sure a message is delivered > exactly once, or provides the client with information that it could not be > delivered at all. Message delivery receipts defined in XEP-0184 is not > sufficient either. First, it does not implement the "Exactly Once" level, > which is also the most important, and the principal reason for writing the > XEP. While it can be used for the acknowledged message case, It also has > several weaknesses: One is that an acknowledgement is only requested. There's > no mechanism the request is understood. So the message can be sent, parsed, > body of message processed, but no acknowledgement returned, generating new > requests, etc. To have a solution that either works or does not work, with no > in-between state of working partially, you need to embed the message in > another construct. If that construct is not understood, the entire message is > discarded. > > If <iq/> is used, you'll always get at-least-once, no matter the support > for 198 along the route. Correct. But it would be a proprietary, > non-interoperable solution. > > 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. No, it does not actually. See > ยง5.2http://xmpp.org/extensions/inbox/qos.html#memory The point here is that > if it cannot be received (at the moment) there's a clear error message > returned, so the client is alerted. The state is never unknown. Furthermore, > processed messages are forgotten, and the double request/response mechanism > still makes sure the message is only delivered to the application layer only > once. > > This could be avoided by having an if-not-modified-since semantic, which is > very useful in other cases beyond simple 1:1 QoS. No, it would not work, > since that would require the receiver to remember processed messages. The > two-step transmission/delivery process, which is standard in reliable > messaging, does not require the receiver to remember processed messages. > > 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. I ask you to reconsider. The pattern > described in this proposal conforms to common implementations of the reliable > messaging Communication pattern, and is very useful, especially if you want > to implement queueing and transaction support. (Reliable messaging comes with > many names. Other popular names are Assured service, or Exactly Once > delivery.) > > On 8 December 2015 at 17:40, XMPP Extensions Editor <edi...@xmpp.org> 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: standards-unsubscr...@xmpp.org _______________________________________________
