[OASIS Issue Tracker] (MQTT-412) Consolidated error handling.

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

Andrew Banks created MQTT-412:
---------------------------------

             Summary: Consolidated error handling.
                 Key: MQTT-412
                 URL: https://issues.oasis-open.org/browse/MQTT-412
             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
          Issue Type: Bug
          Components: core
    Affects Versions: 5
            Reporter: Andrew Banks
            Assignee: Andrew Banks
             Fix For: wd11


The V5 specification defines Malformed Packet and 
Protocol Error in the terminology section.

Malformed packets are mentioned explicitly about 15 times
and protocol errors about 50 times throughout the specification.
Sometimes Section 4.13 is referred to and sometimes the handling of the error
is described in line. There are more occasions where the server is required
to check and handle a malformed packet or protocol error than when the client is.

In some places eg. 3.4.1 Fixed Header (PUBACK) there is no explicit
mention of any error checking.

Some types of protocol error have their own return code eg.

147	0x93	Receive Maximum exceeded	DISCONNECT
149	0x95	Packet too large	CONNACK, DISCONNECT

Others use the generic return codes 

eg: 3.3.5 Actions (PUBLISH)

a)	If the packet has a zero length Topic Name field it is a 
Protocol Error and the receiver SHOULD send a DISCONNECT packet 
with a Return Code of 0x82 (Protocol Error)
and then MUST close the Network Connection.


Section 4.13 Handling errors describes how Malformed Packet, 
Protocol Error and other errors are handled. 

- It is desirable to have all error situations described individually
  and have the handling of these error described in each case. This removes
  ambiguity.

- If any error is not described explicitly then there is an implication 
  that it must not be handled.
  
- If a lightweight implementation wants to avoid doing rigorous error 
  checking and omits to do it, then it does not comply with the specification. 

- It is desirable to permit implementations to handle errors not explicitly
  called out in the specification.

- It is desirable to permit implementations to disregard protocol errors
  and malformed packets that cause them no problem.



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