OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Public review comments for mqtt-v3.1.1-csprd02: 1.5.3 UTF-8 encoded strings


IMPORTANT NOTE: Please make sure that you are subscribed to the mqtt-comment@lists.oasis-open.org mailing list before submitting feedback with this form. For instructions on subscribing see https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=mqtt.

Comment type [editorial | technical] ? technical

Impact [major | minor] ? major

According to the current draft:

“The character data in a UTF-8 encoded string MUST be well-formed UTF-8 as defined by the Unicode specification [Unicode] and restated in RFC 3629 [RFC3629]. In particular this data MUST NOT include encodings of code points between U+D800 and U+DFFF. If a Server or Client receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection [MQTT-1.4.0-1].”

“A UTF-8 encoded string MUST NOT include an encoding of the null character U+0000. If a receiver (Server or Client) receives a Control Packet containing U+0000 it MUST close the Network Connection [MQTT-1.4.0-2].”

This requires the server to scan the UTF-8 content of all strings in all packets. Since the strings themselves are bounded by a length prefix, can this be “downgraded” to “SHOULD” and “SHOULD NOT” for lower-latency solutions?

Regards,

/djk

David Kemper
Principal Architect
TIBCO Software Inc.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]