[OASIS Issue Tracker] (MQTT-326) Consolidate Handling for NAKs, Protocol Errors and

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

    [ https://issues.oasis-open.org/browse/MQTT-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64628#comment-64628 ] 

Andrew Banks commented on MQTT-326:
-----------------------------------

I closed MQTT-235 Use disconnect RC 0x82 in place of protocol error so that it can be merged with this Jira. Last TC we agreed to reword the spec to describe protocol errors where we receive an out of sequence packet id as(potential) protocol errors but that the protocol continues 
having reported the (Potential) error in an Ack. I.E. we do not disconnect.

On Ken's point about giving a generic disconnect error for  Retain unavailable, Maximum QoS, and also for Maximum Packet Size exceeded, I  think that the more explicit the disconnect error return the better, so long as the meaning is unambiguous.

For the Subscription Identifier not supported, or Shared Subscription not supported return codes 
the current position is that we will be putting these in the Suback, and the network connection will continue. I believe it would be preferable to say they are not supported on connack and treat them as a protocol error if they are received. 

I would like to see all of the known limitations declared in connect/connack and the sender required not to violate them with a disconnect return code if it does. That should simplify the senders operation as it will not be reacting to asynchronous failures. 


> Consolidate Handling for NAKs, Protocol Errors and 
> ---------------------------------------------------
>
>                 Key: MQTT-326
>                 URL: https://issues.oasis-open.org/browse/MQTT-326
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Task
>          Components: edits
>    Affects Versions: 5
>            Reporter: Ed Briggs
>            Assignee: Ed Briggs
>              Labels: editorial
>
> The text regarding the handling of ACKs, NAKs, and protocol errors needs to be unified so that a single, consistent approach is used throughout (to the extent possible.)  There also needs to be consistency on the sending of DISCONNECT vs transport disconnection in cases of protocol errors (e.g. malformed header).
> This editorial process has already been approved and this issue is resolved from a procedural standpoint.



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