[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (MQTT-29) Editorial comments on 2.1.3 (Remaining Length) and 2.1.4 (Multibyte Length)
[ http://tools.oasis-open.org/issues/browse/MQTT-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Banks updated MQTT-29:
-----------------------------
Proposal: Multibyte length removed and Remaining length section at Line 380 updated.
Resolution: Resolved in WD09
> Editorial comments on 2.1.3 (Remaining Length) and 2.1.4 (Multibyte Length)
> ----------------------------------------------------------------------------
>
> Key: MQTT-29
> URL: http://tools.oasis-open.org/issues/browse/MQTT-29
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: edits
> Reporter: Peter Niblett
> Assignee: Rahul Gupta
> Priority: Minor
>
> 1. In WD04, there's a short paragraph - 2.1.3 that describes the Remaining Length field. It contains only two important facts
> i) The remaining length doesn't include its own length
> ii) It is encoded as a "Multibyte Length"
> There's a much longer section 2.1.4, which describes the "Multibyte Length" encoding. However seeing as this encoding is only used for the Remaining Length field, there doesn't seem much point having two separate sections and the concept of a "Multibyte Length". . I suggest that we merge 2.1.3 and 2.1.4 and we stop talking about "Multibyte Lengths". This means that the references to 2.1.4 that appear throughout section 3 would then simply point you to 2.1.3 for all information about the Remaining Length field. If you really want to refer to the encoding format independently from its use for Remaining Length it should be something like "Multi Byte Integer".
> 2. The non-normative encode and decode algorithms refer to something they call "digits", when I think they mean "bytes" or "octets". In particular in line 412 it says "digit = 'next digit from stream' ".
> 3. The termination check in the decode algorithm is not safe. It will continue reading bytes until it encounters one < 128, so if you feed it malformed input it could end up processing more than 4 b ytes of input data. I realize this is non-normative, but we should be encouraging developers to code defensively and raise an error if they encounter 4 successive bytes all > 127.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]