[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=63079#comment-63079 ] 

Ed Briggs commented on MQTT-286:
--------------------------------

This is an interesting approach, but the only way we have to report asynchronous errors is with DISCONNECT(err) which closes the connection and does not contain a packet Id (useful for diagnostics)   We had previously agreed that in the case of nak, the message would be treated as though it were acknowledged (for the purpose of retiring the PID), and that transmission would continue with the next message. (If we had disconnected at this point, a publish message to (say) an invalid topic) would cause an infinite retry loop. (with cleansession=0).

(BTW, I'm not sure that reporting the specified packet ID is not known is useful;  it the case of the loss of a PUBCOMP and the retransmission of the PUBREL, this receive side would have already retired the packet id, in other words, expected behavior.  Perhaps I misunderstand what you are saying.)

But returning to the base topic, since both method A and B are permitted today, do we really *need* to clarify this aspect if we decide to use only method B?

> 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
>
> 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)