[ https://issues.oasis-open.org/browse/MQTT-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62282#comment-62282 ]
Ken Borgendale commented on MQTT-282:
-------------------------------------
Having defined the concept of a optional field (nee metadata), it makes sense to encode many of the fields in the CONNECT packet payload as optional fields. This is especially true as we plan on adding a number of additional ones there, including most likely additional fields concerning security, and a additional field concerned with will.
- WillQoS int1 (default=0) replaces WillQoS connect flags
- WillRetain int1 (default=0) replaces WillRetain connect flag
- WillTopic string (default = no will) replaces Will connect flag and data in payload
- WillMsg string (default = "") replaces data in payload
- Username string - replaces Username connect flag and data in payload
- AuthData bytes - replaces Password connect flag and data in payload
The only thing left in CONNECT payload would be the ClientID
> Consider refactoring existing packets to express existing fields as metadata
> -----------------------------------------------------------------------------
>
> Key: MQTT-282
> URL: https://issues.oasis-open.org/browse/MQTT-282
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: edits
> Reporter: Richard Coppen
>
> Jira MQTT-256 (Message format indication) defines an encoding strategy for metadata. This Jira was opened at the April face-to-face to consider whether pre-existing fields in packets can be more consistently expressed as metadata.
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
