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.

It is not true that it is already permissible to send user properties on the ACKs. It is allowed to send properties on the ACK so this proposal is to add user properties which are currently not allowed.

I would like a general statement that a client is not required to parse and check properties if that client does not use them in any way. I suspect that many clients will not do this checking anyway but I would like them to be conforming to the spec. I do not think we need to add this exemption for servers.

Opened per discussion on 12/1 TC call.

Resolved to editor per agreement on 12/1 TC call.

Issue included in MQTTv5.0 CS01 December 25, 2017