Hello Florian
Thanks for your comments. Please find my responses below:
>
> ? 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.
>
> $ 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.
Another difference is that the parsing of the QoS level is made at a lower
level in the stack, as compared to the the parsing of the message, which would
normally take place in the overlying application layer. The QoS level could
thus be made transparant to the overlying application, and more fault-tolerant
(also for applications which might become confused, depending on
implementation). Also, there might be cases where XEP-0184 is counterproductive
and in essence changes the meaning (semantics) of messages. Which might be
undesireable.
>
> ? 2.3 is AFAIK something no other XEP specifies and does *not* require
> support by the routing entities.
Correct. Routing entities are not involved in this, only the original
transmitter and final receiver that needs to understand the handshake.
> I would split the part off into a new
> XEP "Exactly Once Delivery" describing the double IQ process used.
This is the principal point of this QoS XEP. The Acknowledged and
Unacknowledged QoS services are available too. The unacknowledged service for
purely pedagogical reasons, and the acknowledged service, for reasons explained
above.
> 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.
> - the used ID and entity tuples to be
> precise - but I think something like that could be implemented in a
> sound and pragmatic way. The usefulness of "Exactly once" is, however, a
> different topic. Most distributed protocols rely on idempotent actions
> and therefore are happy with "At least once".
"Most" here, depends on use case. There's a reason why most bank transactions
are done using other protocols. So, (as my aim here, se coming XEPs) is
reliable messaging, queueing and transactions (including Micro transactions), a
reliable messaging mechanism needs to be available in XMPP as well. It could be
done in a proprietary fashion, but so can everything else too, and it would be
counterproductive and contrary to interoperability.
PS: There's a common type of operations performed within industrial automation
(and so IoT), that are not idempotent. They relate to counting (transactions)
in that the report consumption or delta-values, rather than absolute values.
Fine-grained control of a motor can often be done as "turn X degrees", where X
might be counted in fractions of a degree. Receiving multiple messages by
mistake would cause a state that the receiver cannot recover from.
In general, any type of event that needs to be counted, are not idempotent.
I hope you reconsider and allow the QoS proposal to pass to the experimental
stage.
Best regards,
Peter Waher
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
