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

Konstantin Dotchkoff commented on MQTT-321:
-------------------------------------------

There are many scenarios, where independent of the reason string or in addition to it, further information needs to be provided. A few very specific examples are: (error) tracking_id, error category, severity or sub error code, retry after period. Retry-after http response header is a good example of that (which is a custom one, but de-facto adopted by the industry and we also have native support in our libraries to perform retries after the specified back-off period). I see a huge value in having the facility to transform more structured information to avoid parsing every reason string for some specific info. Parsing a free form string is error prone and can be avoided if the implementation can transport custom properties on the ACK - this is primarily for NACK, where we might want to limit the custom properties to NACKs only, although I personally don't see any reason to restrict this, because the custom properties are optional anyways and a typical implementation would choose to use them only if needed (and primarily on NACKs), On the TC call, when we discussed a potential overlap, my understanding was that we decided to include the reason string as named / spec defined property, because a) it will be the most common one, b) to avoid giving it a string name, which is longer than an id and c) because it makes sense different implementation to process the same property. However, my understanding was that we just decided to go with a spec defined/named property for that, not that we are not going to allow custom properties in addition.

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