[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-300) Metadata: CONNACK Maximum QoS
[ https://issues.oasis-open.org/browse/MQTT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63590#comment-63590 ]
Peter Niblett commented on MQTT-300:
------------------------------------
I have no issue with the principles in this proposal that we agreed earlier today, but have some comments on the wording.
In 3.1.1 we changed the descriptions of the the Fixed Header byte 1, so that bits 1 and 2 are only described as QoS bits for the PUBLISH packet. The idea behind this was to let the bits in the other packets be used for something else in future versions of MQTT. I think it will confuse people to start talking about other packets having a QoS.
Readers might be puzzled why you say "MUST accept and process SUBSCRIBE, UNSUBSCRIBE and PUBREL messages regardless of the Maximum QoS Level it supports." but don't mention PING.
Also
1. there are two places where you say that no advertisement => all three QoS are supported.
2. In the rest of the spec we tried to standardise on the word "packet" to for an MQTT protocol data unit. This proposal uses "command", "event" and "message" in different places
Here's my suggested rewording:
------------------------------
A Server is NOT REQUIRED to support QoS 1 or QoS 2 PUBLISH packets. If this is the case it MUST include a Maximum QoS Advertisement in the CONNACK packet. A server that doesn't support QoS 1 or Qos2 PUBLISH packets MUST still accept SUBSCRIBE packets containing a Requested QoS of 0, 1 or 2.
If a Server does not support QoS 1 or QoS 2 PUBLISH packets, it MUST send a Maximum QoS Advertisement containing the highest QoS it supports and MUST support all lower QoS Levels in addition to the value contained in the advertisement. If the Server does not send a Maximum QoS Advertisement, it MUST support QoS 0, 1, and 2.
If a Client receives a Maximum QoS Advertisement from a Server, it MUST NOT send PUBLISH packets at a QoS level exceeding the Maximum QoS level specified.
If a Server receives a CONNECT message containing a Will QoS that exceeds its capabilities, it MUST reject the connection. It MAY send a CONNACK with a return code QoS-NOT-SUPPORTED and MUST close the transport connection.
If a Server receives a QoS > 0 PUBLISH packet and that QoS level exceeds its capabilities it MUST reply with a PUBACK or PUBREC with the return code QoS-NOT-SUPPORTED. In the case of QoS 2 messages, the server MUST also process the subsequent PUBREL packet and issue a PUBCOMP to complete the protocol flow.
> Metadata: CONNACK Maximum QoS
> ------------------------------
>
> Key: MQTT-300
> URL: https://issues.oasis-open.org/browse/MQTT-300
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: New Feature
> Components: core
> Affects Versions: 5
> Reporter: Brian Raymor
> Assignee: Ed Briggs
> Labels: Proposed
>
> This was discussed in MQTT-276 with notes from the F2F meetings and has been tracked in MQTT-256.
> I'm opening a separate, specific issue per Ken's comments - https://issues.oasis-open.org/browse/MQTT-256?focusedCommentId=62192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62192:
> "All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values."
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]