[OASIS Issue Tracker] (MQTT-286) Make Qos 2 Delivery Method 'B' Normative

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63555#comment-63555 ] 

Peter Niblett commented on MQTT-286:
------------------------------------

I am happy with the changes to Diagram in Figure 4.3 and the deletion of the paragraph following it (Figure 4.3 shows that there are two methods by which QoS 2 can be handled by the receiver. They differ in the point within the flow at which the message is made available for onward delivery. The choice of Method A or Method B is implementation specific. As long as an implementation chooses exactly one of these approaches, this does not affect the guarantees of a QoS 2 flow.)

I don't see the need to replace that paragraph with any new normative text. We should minimise normative statements about how the server implements QoS 2, unless they directly affect the protocol between it and the clients or unless  they are needed to ensure end-end exactly once delivery through the server.  

However if it is felt that further normative statements are needed, they should be added to the normative statements in [MQTT-4.3.3-2] as otherwise the reader has to look in two different places.

Looking at the proposed replacement text to justify why I don't think we need to include it:

1. "Upon receiving a QoS 2 PUBLISH message which is both valid and not a duplicate, the receiver SHOULD immediately initiate onward delivery and send a PUBREC"

This is only a SHOULD, so it's not fully Normative.  I would have thought that it's implied by Figure 4.3 so there's no need to mention it explicitly here. That way we don't have to worry about how "immediate" this has to be, what "initiate" means if there aren't any subscribers, etc. 

2. "The receiver MAY send a PUBREC before the onward delivery is complete. "
This is already covered by footnote 1, and the wording in that avoids the problematic use of MAY (RFC 2119)

3.  "If the forwarding operation fails, the receiver MUST send an appropriate error response, or terminate the transport as specified in section {TBD part of MQTT-236 }. "
Up to now, we've taken the view that the publisher->server and server->subscriber hops are independent. This sentence implies that they are in some way linked. This is going beyond simply switching to Method B. It is changing what Method B is. If this is what you meant, it should be a separate JIRA.  Also I don't see how you mean it to work anyway, since the first sentence wants the server to send the PUBREC immediately then it can't use it to send an error response.

4. "The receiver MUST NOT send more than one PUBREC for the a single message arrival". If you think this point needs re-inforcing it could be added to the first bullet of [MQTT-4.3.3-2]  e.g. 

MUST respond with a PUBREC containing the Packet Identifier from the incoming PUBLISH Packet, having accepted ownership of the Application Message. It MUST NOT send any subsequent PUBREC packets in response to this PUBLISH





> Make Qos 2 Delivery Method 'B' Normative
> ----------------------------------------
>
>                 Key: MQTT-286
>                 URL: https://issues.oasis-open.org/browse/MQTT-286
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>    Affects Versions: 5
>            Reporter: Ed Briggs
>            Assignee: Ed Briggs
>              Labels: Proposed
>
> I propose QoS 2 Delivery Method B should become the only forwarding method, and Method A be eliminated in future MQTT versions.
> This can reduce delivery delays for PUBLISH messages over QoS 2 flows when the network propagation delay is substantial. In addition, Method B eliminates temporary storage required by Method A.  Both methods are described in MQTT 3.1.1 Section 4.3.3 in non-normative text accompanying diagram 4.3.
> This change may also be beneficial for the following MQTT isses:
> MQTT-197  Support Request Reply
> MQTT-236  Consolidate ACKs, Enable NAKs
> MQTT-271  Describe Small Device Limitations aka The Arduino problem.
> I propose the existing non-normative text in section 4.3.3 : 
>  "...there are two methods by which QoS 2 can be handled by the receiver. They differ in the point within the flow at which the message is made available for onward delivery. The choice of Method A or Method B is implementation specific. As long as an implementation chooses exactly one of these approaches, this does not affect the guarantees of a QoS 2 flow."
> Be replaced by normative text along the lines of the following:
> "Upon receiving a QoS 2 PUBLISH message which is both valid and not a duplicate, the receiver SHOULD immediately initiate onward delivery and send a PUBREC. The receiver MAY send a PUBREC before the onward delivery is complete.  If the forwarding operation fails, the receiver MUST send an appropriate error response, or terminate the transport as specified in section {TBD part of MQTT-236 }. The receiver MUST NOT send more than one PUBREC for the a single message arrival."
> A brief containing additional details can be found here:
> https://www.oasis-open.org/apps/org/workgroup/mqtt/download.php/58364/Mqtt-286-MqttQoS2DeliveryProposal.pdf



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)