OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[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=65211#comment-65211 ] 

Andrew Banks commented on MQTT-412:
-----------------------------------

Starting point for continued discussions on Wednesday February 8th.

   Classes of Protocol or Malformed packet error.
             The sender is non compliant in all cases.

   Class 1)  Both Client and Server MUST validate on receipt.
             Explicitly mentioned in the specification with a return code.

             Example: Qos=3 received on PUBLISH packet.

             Client: SHOULD SEND DISCONNECT, and MUST Close the network.
             Server: MAY Send CONNACK, or SHOULD SEND DISCONNECT, and MUST Close the network.

   Class 2)  Server MUST validate on receipt, Client SHOULD validate on receipt.
             Explicitly mentioned in the specification with a return code.

             Example: Bit 3 not zero in PINGRESP or PINGREQ.

             Client: SHOULD** SEND DISCONNECT, SHOULD Close the network.
             Server: SHOULD** SEND DISCONNECT, and MUST Close the network.

   Class 3)  Client and Server MAY validate on receipt.
             Correct working is described in the specification, 
             but enforcement behaviour may not be explicitly mentioned.
             Only Malformed Packet and Protocol Error return codes are allowed.

             Example: PUBACKs not sent in the same order as PUBLISHs are received.
             Example: PUBLISH Payload format is String but Payload is not UTF-8.

             Client: MAY** SEND DISCONNECT, MAY Close the network.
             Server: MAY** SEND DISCONNECT, MAY Close the network.

** If DISCONNECT is sent the network connection MUST be closed.

             

   


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