[OASIS Issue Tracker] (MQTT-564) MQTT 5.0 behaviour for Request Problem Information

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

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

Peter Niblett commented on MQTT-564:
------------------------------------

You might be able to argue that the text in the current spec isn't actually wrong, but I agree that this is confusing.

Â

I think the intent of the spec is as follows:

1. Reason String is a property that can be included in any packet that has a Reason Code. These 9 packets are listed in Table 2-4. They are the ACKS, the QoS2 responses, DISCONNECT and AUTH. The Reason String can be used to provide a string explaining the failure in cases where Reason Code is non zero.

2. User Properties can appear in any packet except for PINGxxx. The purpose of them is intentionally vague, but the spec suggests that in the 9 packets that have a Reason Code they can be used to provide additional diagnostic information if the packet has a non-zero Reason Code (i.e. is indicating a failure)

3. A client can set Request Problem Indication = 0 in order to stop the server from sending it Reason Strings or diagnostic User Properties

4. This last point only applies to the 9 packets that can have Reason Strings. but it seems that we decided to exempt CONNACK and DISCONNECT, so a server is allowed to send Reason Strings and diagnostic User Properties in these packets, regardless of the value of RPI.

5. There's one more packet that a client can receive that can contain User Properties, and that's PUBLISH. The PUBLISH packet has no Reason Code or Reason String, so I assume that any User Properties that it contains are there for other purposes, so you would not expect them to be controlled by the client's RPI setting.

The current text doesn't distinguish between diagnostic User Properties and other User Properties. In fact it doesn't explicitly use the term "diagnostic User Properties", since we didn't want to start describing what a User Property is. To avoid doing this, there's a simplifying assumption that User Properties in the 9 packets are diagnostic ones, and User Properties in the other packets (including Publish) are non-diagnostic ones.

With that understanding, the text is actually correct:

i) If RPI = 1 the Server MAY return a Reason String or User Properties on any packet where it is allowed. [This is correct]

ii) If RPI = 0 {color:#000000}the Server MAY return a Reason String or User Properties on a CONNACK or DISCONNECT packet. {color}Â[This is the exception in I mentioned in 4]

iii) If RPI = 0 the Server {color:#000000}MUST NOT send a Reason String or User Properties on any packetÂ{color}{color:#000000}other than PUBLISH, CONNACK, or DISCONNECT{color} [The only other packets that a Server is allowed to send are ones that contain Reason Codes and we can therefore assume any User Properties in them are diagnostic ones, which aren't allowed with RPI=0]

What's confusing about iii) is that a server isn't allowed to send a Reason String in a PUBLISH packet, and it also looks odd as PUBLISH doesn't appear in ii).

Â

If I were able to re-write the paragraph, I would suggest

Â

If the value of Request Problem Information is 0, the Server MAY send a Reason String or User Properties relating to a failure on a CONNACK or DISCONNECT packet. It can also include User Properties in a PUBLISH packet but MUST NOT send a Reason String or User Properties on any packetÂother than PUBLISH, CONNACK, or DISCONNECTÂ[MQTT-3.1.2-29].ÂÂÂ If the value is 0 and the Client receives a Reason String or User Properties in a packet other than PUBLISH, CONNACK, or DISCONNECT, it uses a DISCONNECT packet with Reason Code 0x82 (Protocol Error) as described inÂ[section 4.13|https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#S4_13_Errors]ÂHandling errors.

Â

> MQTT 5.0 behaviour for Request Problem Information
> --------------------------------------------------
>
>                 Key: MQTT-564
>                 URL: https://issues.oasis-open.org/browse/MQTT-564
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core, edits
>    Affects Versions: 5
>            Reporter: Richard Coppen
>            Priority: Major
>
> Question fromÂTakatoshi on MQTT Comments list
> Â
> I have a comment about the following part of MQTT Version 5.0 document:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.oasis-2Dopen.org_mqtt_mqtt_v5.0_os_mqtt-2Dv5.0-2Dos.html-23-5FToc3901053&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=HFOYf-FWdPMlPq2g5pc8M7HUYiSp2sC9P2hDoZdjdRo&m=jvexqqlWqfyLENYV-w-vdlZeZVUY9XTEHIAJKvZXxwo&s=GaNM7rm25khF8RtMPACWSQWGDvA7Mw4xE1MTuoQ28Xo&e= 
> ÂIf the value of Request Problem Information is 0, the Server MAY return a Reason String or User Properties on a CONNACK or DISCONNECT packet, but MUST NOT send a Reason String or User Properties on any packet other than PUBLISH, CONNACK, or DISCONNECT [MQTT-3.1.2-29]. If the value is 0 and the Client receives a Reason String or User Properties in a packet other than PUBLISH, CONNACK, or DISCONNECT, it uses a DISCONNECT packet with Reason Code 0x82 (Protocol Error) as described in section 4.13 Handling errors.
> At first, the spec refer to CONNACK and DISCONNECT. But from theÂmiddle, PUBLISH is mixed.
> Which MQTT control packets can use Reason String and/or User
> Properties if Request Problem Information is 0 ?
> Thanks,
> Takatoshi



--
This message was sent by Atlassian Jira
(v8.3.3#803004)