[OASIS Issue Tracker] (MQTT-322) Add ContentType property to PUBLISH messages

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

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

Ken Borgendale commented on MQTT-322:
-------------------------------------

The type of the data in this proposal is a mess to parse and violates most of the principles of data type.  It in fact uses one of the values inside the data type to determine what the data type is.

It seems cleaner to just have two properties, the payload format which is a byte and the content type which is a string.  If we want to make sure that they do not conflict, we could just say that you cannot sent both.  

In the HTTP RFC the ContentType is defined with a reference to MIME but is consistently just called content type (without the MIME).  We should do the same, especially if we do not require the value to be parsed.


> Add ContentType property to PUBLISH messages
> --------------------------------------------
>
>                 Key: MQTT-322
>                 URL: https://issues.oasis-open.org/browse/MQTT-322
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 5
>         Environment: This was discussed in MQTT-276 with notes from the F2F meetings and has been tracked in MQTT-256. 
> I'm opening a separate, specific issue per Ken's comments - https://issues.oasis-open.org/browse/MQTT-256?focusedCommentId=62192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62192: 
> "All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values." 
>            Reporter: Ed Briggs
>            Assignee: Ed Briggs
>              Labels: Proposed
>
> MQTT 5.0 needs the ability to describe the payload content with a property that is not part of the payload for those systems which may not be able to reliably infer the content type from the payload field or topic alone. Such a need arises in larger system in which payloads may be encrypted or otherwise indecipherable to applications which may need to perform special processing on certain payload types. This may also occur if multiple applications are consolidated into a single system.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)