[Standards] Proposed XMPP Extension: Quality of Service

Florian Schmaus flo at geekplace.eu
Thu Dec 10 12:03:10 UTC 2015


On 10.12.2015 11:29, Peter Waher wrote:
>> ? 2.1 does not explain how "At most once" is enforced. I assume it
>> requires support by the involved routing entities. But this means that
>> you can't use it without ensuring that every involved routing entity
>> supports it. I highly doubt that this will every be practicable. Or,
>> using Matthew words: it opens a can of worms.
>  
> §2.1 describes "At most once" QoS level, which corresponds to a normal
> message. It's not different from any other message. You could say it's
> the default QoS level for messages in XMPP.

Do you have a reference where XMPP in the RFCs guarantees to provide "At
most once" delivery semantics? I've never encountered it, but it could
be possible that it's simply hidden somewhere in the RFCs. I know that
XMPP requires the stanza order to be stable, but I've never read that
stanzas must not be duplicated along the hops.

But even if the specification would require "At most once" delivery,
then you still have he problem that not every implementation would
follow it, or that the implementations of routing entities may be
flawed. With this in mind, I find it very dangerous that § 2.1 of the
QOS XEP assumes that "At most once" will just magically happen.

In my eyes an "At most once" specification needs to be similarly
designed to what the QOS XEP did in § 2.3: Involving only the two
endpoints, taking stanza duplication, loss and ideally also an unstable
stanza order into consideration and providing a mitigation.

>> $ 2.2 duplicates Message Delivery Receipts (XEP-184).
>  
> Not really. As I mentioned to Dave, it is fail-safe, i.e. there's no
> inbetween state where the message might be processed but the receipt
> request not understood, etc. By embedding it in an IQ you make sure the
> message is only delivered if the QoS level is understood and processed.

Well that seems like a valid point. Please not that there is a mechanism
to determine xep184 support. But not a clients will send a receipt even
if they announce support for it. For example Smack only sends receipts
to contacts which have a presence subscription in order to prevent
presence leaks.

>> ? 2.3 is AFAIK something no other XEP specifies and does *not* require
>> support by the routing entities.
>> Dave
>> already mentioned that you run into issues because you theoretically
>> need to keep the state forever
>  
> Dave was unfortunately wrong, see my response to his mail. You only need
> to remember the state of a message until you deliver it. That is the
> point using the double iq stanzas. The only thing an implementer needs
> to limit however, is storage capabilities and persistence of undelivered
> messages. That is left as an implementation specific detail, which does
> not concern the actual network communication.

Got you. I see now that you only need to remember the undelivered
messages. And § 5.2 seems to nicely discuss this wrt to security
considerations.

I just noticed that if the second IQ result gets lost, and the client
retries, it will receive an error response that the msgId is unknown,
which in turn indicates that the delivery was already triggered. That
was the point I was missing.


BTW: The QOS XEPs needs to qualify <message/> with the correct namespace
in the examples (assuming it's an message stanza).

Best

- Florian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151210/c381fea1/attachment.sig>


More information about the Standards mailing list