OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Public review comments for mqtt-v3.1.1-csprd02: 3.3.5 Actions


IMPORTANT NOTE: Please make sure that you are subscribed to the mqtt-comment@lists.oasis-open.org mailing list before submitting feedback with this form. For instructions on subscribing see https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=mqtt.

Comment type [editorial | technical] ? technical

Impact [major | minor] ? major

According to the current draft, starting at line 824:

“When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published message might match multiple filters. In this case the Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions [MQTT-3.3.5-1]. In addition, the Server MAY deliver further copies of the message, one for each additional matching subscription and respecting the subscription’s QoS in each case.”

Granted, the scope of the OASIS TC prohibits more extensive protocol changes to address the ambiguity of [MQTT-3.3.5-1], the explicit requirement of [MQTT-3.3.5-1] is at least well-defined.

However, the following sentence “In addition, the Server MAY deliver further copies of the message, one for each additional matching subscription and respecting the subscription’s QoS in each case.” leads to further ambiguity.

Consider the case of four overlapping subscriptions, and a publish that satisfies all. Let’s say one subscription is at QoS 0, one is at QoS 1, and the third and fourth are at QoS 2. As I understand it:

- The MUST clause covers delivery at QoS 2.

- The Server MAY additionally deliver the message at QoS 0, QoS 1, and again at QoS 2 (!).

- For each additional delivery with QoS > 0, the packet has a unique Packet Identifier. (It’s a unique Server->Client packet that must be ack’ed.)

- For each additional delivery with QoS > 0, the packet does NOT have the DUP flag set, unless this is during redelivery after reconnect. (DUP is not about the application message, but about the packet sent.)

I have read through the comments to https://tools.oasis-open.org/issues/browse/MQTT-58 (How many messages are received for overlapping subscriptions?). There are some counter-proposals, and the opinion that “a server cannot be allowed to choose the behaviour here. We need to decide one way or the other.” However it is marked TC Approve proposal - TC call 10.10.2013. Those minutes do not illuminate the discussion.

- Can this be reopened to remove the MAY clause? (I realize we are late to the party, but have to ask as this is open for community feedback.)

- If no changes are made, how is it envisioned that the Client deal with this ambiguity? (I’m hoping this goes beyond “don’t do this.”)

- If no changes are made, can you verify my understanding of the scenario outlined above, and the assumptions it makes?

- Should the behavior be clarified in non-normative text?

Regards,

/djk

David Kemper
Principal Architect
TIBCO Software Inc.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]