[OASIS Issue Tracker] (MQTT-282) Consider refactoring existing packets to express existing fields as metadata

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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