[OASIS Issue Tracker] (MQTT-595) Publish QoS -1 has no protocol version indication

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

     [ https://issues.oasis-open.org/browse/MQTT-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simon Johnson updated MQTT-595:
-------------------------------
      Proposal: Add a new message type which will be used for PUBLISH -1 messages and will include a protocol field.
    Resolution: See WD 25

> Publish QoS -1 has no protocol version indication
> -------------------------------------------------
>
>                 Key: MQTT-595
>                 URL: https://issues.oasis-open.org/browse/MQTT-595
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MQTT-SN
>    Affects Versions: MQTT-SN-1.2
>            Reporter: Ian Craggs
>            Assignee: Simon Johnson
>            Priority: Major
>
> From Simon Johnson:
> I have been working with PUBLISH -1 in v2. I have found a flaw with the new packet type layouts. Presently you can PUBLISH -1 without a session, and it is the SESSION that determines the protocol version you have decidedÂto use. Without a session, the GATEWAY has no mechanism to determine the version of the PUBLISH packet to use to decode it. So to maintain the ability for a GW to support both protocol versions, we must haveÂa mechanism in the PUBLISH packet to note protocol version WITHOUT adding any further bytes.
> I was looking, the packet type field seems to be a great chance to squeeze some more space out of - in a similar fashion to tt5, so we coolocate a generic flags field in bits 1 & 0, using 6 bits of space (7-2) for packet type (64 available types - we currently use ~30) so plenty of growing room - then the 2 new flags can be used for flags on the message without needing a new flags field. In the case of PUBLISH this can be protocol version, but also it could be used for a few other types specifying and using only 1 or 2 flags saving space elsewhere. I feel this is a fundamental enough issue to warrantÂthis change - and give us further flexibility for saving space elsewhere.



--
This message was sent by Atlassian Jira
(v8.3.3#803004)