[OASIS Issue Tracker] Commented: (MQTT-2) UTF-8 for will messages

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

    [ http://tools.oasis-open.org/issues/browse/MQTT-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33534#action_33534 ] 

Peter Niblett commented on MQTT-2:
----------------------------------

Firstly a comment on Dominik's remark about zero length messages.  The UTF-8 RFC (3629) doesn't mention length prefixes (that's something that the Java writeUTF method puts on the front of its string encodings). So there should be nothing to stop you coding a zero-length WIll Message in the Connect message, and you will then get zero bytes in the payload of the message itself.
 
This is because of the part of the sentence that says "when it is published to the Will Topic only the bytes of the message are sent, not the first two length bytes" 

This is useful as it makes it clear that the length bytes are part of the variable header structure, not the message itself.  This part should be kept in the specification.  

However there are two other questions here
1. What is the rationale for saying "The message must therefore only consist of 7-bit ASCII characters."?  As far as I can see, there is none and this sentence should be deleted.
2. Should the spec actually define this field to be UTF-8 at all?

Nick has given an explanation of how this came about. We can't go through the spec now and change all references to UTF-8 into "2-byte length-prefixed" binary - that would be a significant change to the current protocol. However there's a reasonable case here to say that we could change this field to be binary. That would make the Will Message consistent with other MQTT messages. 

> UTF-8 for will messages
> -----------------------
>
>                 Key: MQTT-2
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-2
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Dominik Obermaier
>
> The current 3.1 specification states that the will message is encoded in UTF-8 in the CONNECT message but will be published in ASCII encoding by a MQTT broker. This is a major inconsistency in the specification since this is the only case where ASCII encoding is used.
> Here's the relevant citation from the specification: 
> "Although the Will Message is UTF-8 encoded in the CONNECT message, when it is published to the Will Topic only the bytes of the message are sent, not the first two length bytes. The message must therefore only consist of 7-bit ASCII characters."
> A payload for a PUBLISH can of course be any raw bytes, in case of the will message we should think of removing the inconsistency from the spec. I see two possibilities:
> 1. The will message in the CONNECT message is *not* UTF-8 encoded but ASCII encoded. 
> 2. The will message in the will PUBLISH is UTF-8. This would collide with the current spec because empty payloads are possible regarding to the 3.1 spec (in case of UTF-8 IIRC two length bytes have to be sent even with an empty message). 
> I would vote for option two because this would remove this inconsistency in the spec and the will message is encoded in the CONNECT message in UTF-8 anyway. I don't think the overhead of the two length bytes in case of an empty message are a serious problem. We could discuss if it would be reasonable that in case of an empty payload (= empty UTF-8 String) the length bytes should be removed automatically by broker implementations to reduce the overhead in PUBLISH messages.

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