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

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

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

Ken Borgendale commented on MQTT-412:
-------------------------------------

It is a major step to change the MUST close the network connection to a SHOULD.  It seems better to leave the MUST and to leave the specific exemption for clients that they do not need to validate data they do not use.  I would support extending this to things like reserved bits for such clients but making this a general exemption and specifically allowing servers to not do such checking seems like a major step backwards.

If all servers and some clients do full validation the result is pretty clean protocol usage.

I do not think it is possible to enumerate all possible errors.  We also have a number of errors in the MAY validate category. 

> 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)