[OASIS Issue Tracker] (MQTT-321) Add User Defined Property to ACKs

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

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

Ed Briggs commented on MQTT-321:
--------------------------------

Ken, thank you for your analysis and feedback. Very much appreciated.  

With your feedback encorporated, the updated proposal is as follows:

In the current working draft, acknowledgements (including those acting as NAKS) are permitted to include Identifier Value pairs, including "User Properties" (formerly called user-defined key value string pairs).

"The CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBECOMP, SUBACK, UNSUBACK, DISCONNECT, and AUTH Packet variable headers ends with a set of Identifier/Value pairs." (S 2.2.3) . So it is already permissible to return user properties on these commands. 

I propose to add 

1. the normative text to explicitly permit user defined tags on CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, and AUTH.  The interpretation of these optional user properties is not the responsibility of MQTT.  It is up to the client to parse and check properties. The server will validate properties to insure they conform with correct UTF-8 restrictions.

2. (Per Ken's feedback)  The client to specify that it does not want user properties on any ACK other than CONNACK and DISCONNECT using an extension to the Request Problem Info property with the values:
    0 = do not send either spec defined properties or user properties
    1 = send the spec defined properties but not user properties
    2 = send the user properties but not the spec defined properties
    3 = send both the spec defined properties and user properties.
For now the only spec defined property on these ACKs is the Reason string. As today, the default is that the server gets to decide.

3.  (per Ken). A user property may not be put on an ACK Packet if it will cause that packet to exceed the maximum packet size. Thus the ACK must be sent even if that means leaving off a user property. This is the same as what we currently say for the Reason string. 

I ask the committee to vote on this proposal so it can be added to  the next working draft.




> Add User Defined Property to ACKs
> ---------------------------------
>
>                 Key: MQTT-321
>                 URL: https://issues.oasis-open.org/browse/MQTT-321
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 5
>         Environment: This was discussed in MQTT-276 with notes from the F2F meetings and has been tracked in MQTT-256. 
> I'm opening a separate, specific issue per Ken's comments - https://issues.oasis-open.org/browse/MQTT-256?focusedCommentId=62192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62192: 
> "All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values." 
>            Reporter: Ed Briggs
>            Assignee: Ed Briggs
>              Labels: Proposed
>
> The working drafts do not yet include the ability to return a user defined property (key value pair) on acknowledgements (CONNACK, PUBACK, PUBREC, SUBACK, UNSUBACK, and DISCONNECT).  This was part of the original requests.  The purpose of these properties is to allow the return of implementation specific information and hints (e.g. 'You exceeded your message quota, try again in 15 minutes'.)
> This field is not parsed by the MQTT implementation. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)