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

Ken Borgendale commented on MQTT-321:
-------------------------------------

As there has been a request for some middle ground on this I will propose this.  However, my preferred position is to not add user properties to ACKs at all,

1. An ACK should be defined as CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, and AUTH.   These are the packets with Return code fields.

2. Allow 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. 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.

4. We should allow a client to ignore all properties sent to it on any packet other than PUBLISH.  If the client is free to simply skip over the property bytes without parsing them in any way if it does not use the information in any way.  I would still require the server to parse and check the properties even if it makes no other use of them.  If the client wishes to use any property, it must parse and check all properties.  I know that simple clients will do this anyway, but at least in this case they can do it while still conforming to the spec.

Once you define that ACKs can contain user properties, I do not think that we can in normative text say what user properties can be used for.  You might want them for extra problem determination.  Others might want them to instruct the application what to do next.  As they are not defined by the spec, how do we limit how they are used?

Having added user properties to 11 of the 15 packets, it is not clear why we would not go all the way and allow them on all packets.  There are certainly some useful cases of user properties on SUBSCRIBE and UNSUBSCRIBE.  Many protocols also allow the ping and pong to carry data as well (the MQTT PINGREQ and PINGRESP).   

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