[OASIS Issue Tracker] (MQTT-215) Summary of mqtt-comment issues CSPRD02

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

     [ https://tools.oasis-open.org/issues/browse/MQTT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Coppen updated MQTT-215:
--------------------------------

    Proposal: 
UTF-8 comment (TC Call 8th May)
Peter Niblett proposes that we leave UTF-8 text as is, but raise a 'futures' Jira to evaluate in a future spec rev. Seconded Andrew Banks. No Objections. TC approve.

Overlapping subscriptions comment (TC call 8th May)
Andrew Banks proposes we resolve the issue related to overlapping subscriptions with using the note to implementers approach and leave current text as is. Seconded Peter Niblett. No Objections. TC Approve.

Ping Response comment (TC call 8th May)
James Bulter proposes we leave text as is on PINGRESPONSE comment. Seconded Peter Niblett. No Objections TC approve.

> Summary of mqtt-comment issues CSPRD02
> --------------------------------------
>
>                 Key: MQTT-215
>                 URL: https://tools.oasis-open.org/issues/browse/MQTT-215
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Richard Coppen
>             Fix For: 3.1.1
>
>
> >>>
> mqtt-comment from Paolo Patierno
> “If a Client does not receive a PINGRESP Packet within a reasonable amount of
> time after it has sent a PINGREQ, it SHOULD close the Network Connection to the
> Server.”
> How much is “reasonable” amount of time ?
> In the actual spec 3.1 the clients has a timeout equals to keep alive period to wait PINGRESP message. 
> <<<
> >>>
> mqtt-comment from David Kemper
> 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? 
> <<<
> >>>
> mqtt-comment from David Kemper
> According to the current draft:
> “The character data in a UTF-8 encoded string MUST be well-formed UTF-8 as defined by the Unicode specification [Unicode] and restated in RFC 3629 [RFC3629]. In particular this data MUST NOT include encodings of code points between U+D800 and U+DFFF. If a Server or Client receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection [MQTT-1.4.0-1].”
> “A UTF-8 encoded string MUST NOT include an encoding of the null character U+0000. If a receiver (Server or Client) receives a Control Packet containing U+0000 it MUST close the Network Connection [MQTT-1.4.0-2].”
> This requires the server to scan the UTF-8 content of all strings in all
> packets. Since the strings themselves are bounded by a length prefix, can this be “downgraded” to “SHOULD” and “SHOULD NOT” for lower-latency solutions? 
> <<<



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