[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=63584#comment-63584 ]
Ed Briggs commented on MQTT-300:
--------------------------------
Updated normative text to indicate Server MAY return the error in CONNACK for Will Message with QoS to high, and MUST thereafter DISCONNECT as per TC decision today (26-Sep-2016)
{This text is to be added in a new section of the specification}
{This text is to be added in the CONNACK payload description}
Maximum QoS Advertisement Format and Values
-------------------------
Identifier value 35 (0x23) followed by a one byte integer containing highest QoS level that a server will accept. Permissible values are 0 or 1. A Server MUST NOT send any other value, and it is an error to send the Maximum QoS advertisement more than once in a CONNACK.
{This text is to be added in a new section of the specification}
Maximum QoS Advertisement Processing
------------------------------------
If a Server supports all QoS Levels, it MUST NOT send a Maximum QoS Advertisement. This signifies it supports all three QoS levels. At a minimum, a Server MUST support the reception and transmission of QoS 0 PUBLISH commands, AND MUST accept and process SUBSCRIBE, UNSUBSCRIBE and PUBREL messages regardless of the Maximum QoS Level it supports. In addition, the server MUST accept SUBSCRIBE commands containing QoS 0, 1, or 2, and it MUST return the Maximum QoS level it supports in the SUBACK.
If a Server does not support QoS 1 or QoS 2 PUBLISH commands, 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 commands 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 an error code QoS-Not-Supported and MUST close the transport connection.
If a Server receives a QoS > 0 PUBLISH message at and that QoS level exceeds its capabilities it MUST reply with a PUBACK or PUBREC with the error status QoS-NOT-SUPPORTED. In the case of QoS 2 messages, the server MUST also process the subsequent PUBREL event though it is encoded as a QoS 1 message and issue a PUBCOMP to complete the packet processing.
{End Normative Text}
> 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]