[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-412) Consolidated error handling.
[ 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]