Further Ack return codes.

Follow on issue for MQTT-236 Consolidate Acks, enable negative acknowledgements.

Ed Briggs added a comment - 20/Sep/16 12:16 PM
The following return codes are missing from WD04. I am adding the missing entries here as this JIRA has not been closed.

CONNACK

139 0x8B Message too large (big strings, metadata etc.)
140 0x8C Banned. You are banned from connecting. Please contact the administrator.
141 0x8D Exceeded Reconnect Rate Limit. Please try again, later.

PUBACK
130 0x82 Message Refused, publication not authorized.
131 0x83 Message Refused, implementation specific, e.g. client quota reached.
132 0x84 Not Authorized
133 0x85 Invalid topic name
134 0x86 Packet Identifier in use (possible session state issue)
135 0x87 QoS Level not supported
136 0x88 Retain not supported
137 0x89 Message too large. (probably needs and admin fix)
138 0x8A Message rate too high (wait and retry might work)
139 0x8B Server Quota Exceeded (might be temporary)
140 0x8C Receiver capacity reached
141 0x8D Invalid meta data tag
142 0x8E Invalid reply topic
143 0x8F Message Rate too High.

PUBREC
-----------

129 0x81 Message Refused, reason unspecified.
130 0x82 Message Refused, publication not authorized.
131 0x83 Message Refused, implementation specific, eg. client quota reached.
132 0x84 Not Authorized
133 0x85 Invalid topic name
134 0x86 Packet Identifier in use (possible session state issue)
135 0x87 QoS Level not supported
136 0x88 Retain not supported
137 0x89 Message too large. (probably needs and admin fix)
138 0x8A Message rate too high (wait and retry might work)
139 0x8B Server Quota Exceeded (might be temporary)
140 0x8C Receiver capacity reached
141 0x8D Invalid metadata tag
142 0x8E Invalid reply topic
143 0x8F Message Rate Too High

SUBACK
---------------
134 0x86 Client Quota Exceeded

DISCONNECT
------------------

Message too large should not be a DISCONNECT reason (IMO). There are return codes for PUBACK and PUBREC to handle this. By using these, the 'nak' implicitly acknowledges the oversize message so that it will not be retransmitted, and other messages (of appropriate size) can be delivered. By using Disconnect, we create a problem - If persistent sessions and QoS > 0 are used, an endless re-connect/retry cycle will occur and no forward progress can be made.
Ken Borgendale added a comment - 20/Sep/16 2:04 PM
A number of possible return codes were not included in the draft of MQTT-236 as they pertained to function in JIRAs which are not yet approved. In general we should add the return codes when we define the function they pertain to. For instance for "message too large" we need to define what a message is (application message?, packet?). The same is true for things like "QoS not supported" and "Retain not supported". When we define the basic concepts of optional part of the implementation we should define these return codes.

PUBACK, PUBREC:

• The "Not authorized", "Unspecified error", and "implementation specific error" do show in the list.
• The "invalid topic name", "Packet ID in use", Invalid metadata and invalid replyto are all protocol errors and should cause the connection to close (and therefore are on disconnect). It does not really work to send a PUBACK saying a packetID is already in use for instance (which one does the ACK apply to?). We could have a return code for "the topic name is valid but not acceptable to this sever or client". This would be breaking out the "implementation specific error" and we would want to define some semantics for it.
• I agree we probably want some return codes for capacity limits, but this should probably be a separate JIRA discussion

SUBACK

• Same discussion about capacity limits. It seems we should either describe the semantics of these limits in the spec, or say servers should use the "implementation specific error".

DISCONNECT:
The "message too large" probably should have been left out until we discuss the concept of max message size. For QoS=0 there is no place other than DISCONNECT to return this error. A client which gets a disconnect with a return code of "message too large" should not reconnect and retry the publish. However, it seems better if this size limit is declared in CONNNECT and CONNACK.

In any case, we should have a discussion at the face to face in Hursley and go thru the set of return codes.