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

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

I recommend we reject this issue for several reasons

1) The user properties on an ACK are by definition private communications from the server to the client which are not defined by the spec.  This anticipates that the client will take action based on the value of these user properties.  This creates a major interoperability exposure and makes it very probably that any clients or servers which use this facility will not interoperate with other clients and servers.  This is a major problem in the AMQP world where you need to get matching clients and servers to get things to work.  This is somewhat a problem even with user properties on CONNECT, but in that case we can hope that these simply reflect configuration being passed on to the server and not operational logic.

2. Adding user properties increases the complexity for the client.  Currently the client needs to deal with user properties only on PUBLISH, and these would normally simply be accumulated and passed on to the client application.  This would add such properties to 7 additional packets which are processed by the client.

3. This adds complexity to the handling of maximum packet size.  The spec for the Reason string which is currently a property on the ACKs is that if there is not room it must not be send.  Thus the ACK is sent without the Reason string if there is not space for it.  Having multiple user properties brings up the possibility that some but not all of them will fit within the maximum packet size.  We will need to fully specify the semantics of this.

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