[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (MQTT-27) Handling of the Dup Flag (section 2.1.2.1)
[ http://tools.oasis-open.org/issues/browse/MQTT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Coppen updated MQTT-27:
-------------------------------
Proposal:
Update the non-normative comment in 2.2.2.1 (in WD08 this is at lines 307 - 310).
Current words:
If 1, the recipient might have previously received the Control Packet it should not treat this flag as an indication that it has previously received the MQTT Control Packet and should not use the DUP flag alone to guarantee to its application that a duplicate message is being redelivered to its application interface.
New words:
The recipient of a Control Packet that contains the DUP flag to 1 cannot assume that it has seen an earlier copy of this packet.
Also, in the case of a PUBLISH packet the DUP flag refers to the Control Packet itself, not to to the application message that it contains. When using QoS 1, it is possible for a client to receive a PUBLISH packet with DUP set to 0 that contains a repetition of an application message that it received earlier.
was:
Update the non-normative comment in 2.2.2.1 (in WD08 this is at lines 307 - 310).
Current words:
If 1, the recipient might have previously received the Control Packet it should not treat this flag as an indication that it has previously received the MQTT Control Packet and should not use the DUP flag alone to guarantee to its application that a duplicate message is being redelivered to its application interface.
New words:
The recipient of a Control Packet that contains the DUP flag to 1 cannot assume that it has seen an earlier copy of this packet.
Also, in the case of a PUBLISH packet, you should note that the DUP flag refers to the Control Packet itself, not to to the application message that it contains. When using QoS 1, it is possible for a client to receive a PUBLISH packet with DUP set to 0 that contains a repetition of an application message that it received earlier.
> Handling of the Dup Flag (section 2.1.2.1)
> ------------------------------------------
>
> Key: MQTT-27
> URL: http://tools.oasis-open.org/issues/browse/MQTT-27
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: core
> Reporter: Peter Niblett
> Assignee: Peter Niblett
>
> WD04, lines 295-297 contain a non-normative comment that says
> "If 1, the recipient might have previously received the message, it shuld not treat this flag as an indication that it has previously received the MQTT Command message and should not use the DUP flag alone to guarantee to its application that a duplicate message is being redelivered to its application interface."
> There is a typo "shuld", and the use of two different terms "message and MQTT Command message" which I think mean the same thing. However we haven't really defined the role of recipient or "its application" and in addition it made me notice that we don't say anything normatively about how the server should handle an incoming Control Packet that contains the DUP flag.
> I think what the current non-normative words are trying to say is that when a recipient receives a Control Packet with the DUP flag set to 1, it should not assume that it has previously seen that Control Packet, just because the DUP flag is set. It might not have received the original copy at all, or it might have received it but had failed before it had managed to do much processing of the message.
> Do we need further normative words?
> 1. The specification should not dictate how a receiving client library handles its relationship with its application, so no more words are needed here. A client library might choose to dedup its incoming PUBLISH messages, or might simply hand them off to the application with the DUP flag set.
> 2. Similarly we should not say exactly how the server handles incoming PUBLISH messages which have the DUP flag set to 1. However if it does decide to deliver the message to one or more subscribers, how does it set the DUP flag in those messages? Does it set it to 0 for the first attempt, or does it set it to 1 on all attempts? I think that's something which should be normatively specified.
> 3. Are there any special semantics relating to a SUBSCRIBE with DUP = 1?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]