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


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

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

Subject: [OASIS Issue Tracker] (MQTT-256) Message Format indication

    [ https://issues.oasis-open.org/browse/MQTT-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59219#comment-59219 ] 

Raphael Cohen commented on MQTT-256:

I understand the rationale, and it's a common request. However, in real world use of message queues, I've found the need to actually specify the MIME type quite uncommon. More commonly, though, I have wanted to define the compression of the payload - more to indicate that a particular payload is compressed, and another isn't. This is quite common, although, again, with the advent of modern compressors (eg Snappy), it's usually easier these days to just compress everything, even if there's no real gain. Changing compression format though is rare - one usually opts for one and sticks with it (firmware - lzip, lrzip, xz; some data - gzip).

Usually (1) applies. I don't actually like (2) for implementations myself, as message type is actually an orthogonal axis to topic (as are other header-like things, including noLocal; think tuple spaces). As for (3), well, for diagnostic clients and administrative tools, there's the `file` command (and library) in Unix that works rather well indeed...

If we _do_ add a message type, we need to recognise:-
- MIME doesn't define lots of types (and vendor extension types are really long-winded)
- MIME doesn't define compression (eg gzip, etc). And some compressions are bespoke designs for particular data
- One can choose to use MIME envelopes or use HTTP headers + bodies - we don't preclude this
- MIME types can 'lie', eg charset
- MIME types have too many things that are optional
- I'm against, though, bespoke types because they're worse (we have to maintain them)
- We also say nothing about encrypted payloads, and footers (which are needed rather than headers, ideally).

Perhaps we can offer a recommendation on a header + body format for messages.

> Message Format indication
> -------------------------
>                 Key: MQTT-256
>                 URL: https://issues.oasis-open.org/browse/MQTT-256
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: futures
>            Reporter: Peter Niblett
> MQTT 3.1.1 does not provide an architected way of indicating the format of the payload that is passed in a PUBLISH packet. We need to avoid the risk of spec or data bloat, and I'm not advocating adding a complicated header structure that passes schemas, messageType indicators, MIME type strings or the like, but at the moment there is no standard way for a receiver even to be able to tell whether the payload is binary or string. 
> There are three ways that this can be dealt with today:
> 1. The Receiver already knows. It's implementing some bigger standard or program design which has dictated the encoding format (e.g. someone decides that all messages will be JSON)
> 2. There is an indicator embedded somewhere in the Topic name (The Topic name is  the only header we have in MQTT 3.1.1). There isn't a standard convention for this, so topic space designers have to choose their own way of doing it.
> 3. The Receiver assumes one format and has a go parsing it. If that doesn't look right it tries another

This message was sent by Atlassian JIRA

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