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-433) Return codes not tied to MUST statements

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

Ken Borgendale commented on MQTT-433:

The problem with having a MUST about the return code is that sending the CONNACK or DISCONNECT it itself only a SHOULD or MAY.

The other issue is that in any case where there are multiple errors, we say that the implementation gets to choose which to use as the return code.  We also allow implementations to send errors in otherwise valid case for exceeding some authorization or implementation constraint.

The only MUST which we have in this area is that the client or server MUST use one of the return codes documented for the control packet they are sending.

> Return codes not tied to MUST statements
> ----------------------------------------
>                 Key: MQTT-433
>                 URL: https://issues.oasis-open.org/browse/MQTT-433
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 5, wd13
>            Reporter: Richard Coppen
> There are a number of places in the spec where we associate return codes to error conditions but don't go as far as to make it a MUST condition. 
> For example:
> A Topic Alias value of 0 or greater than the Maximum Topic Alias is a protocol error, the receiver uses DISCONNECT with Return Code of 0x94 (Topic Alias invalid) as described in section 4.13.
> It's not clear what would happen if the receiver didn't use 0x94, would that still be a conformant implementation ?
> In other places we define an appropriate return code around the boundary of 128 (pick a code ...less than or greater than). 
> Some of the codes listed in the tables are not referenced in the narrative. As such it's up to the implementer to evaluate and pick the best the code and for a given condition. One concern is that this could lead to implementers making different decisions and, as a result, writing code to handle certain conditions may or may not get triggered depending on the client:server pairing.
> One approach is to view the codes more generally e.g., <128 is OK >=128 is bad, but this doesn't seem to improve much on what's gone before.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]