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-322) Add ContentType property to PUBLISH messages

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

Ed Briggs commented on MQTT-322:

The following is proposed as normative text which adds a third new payload format indicator to the existing two. This new payload format indicator contains a MIME 
content-type string which is used to describe the content-type in those cases where it may be necessary to provide a more specific payload type description.

WD09 Contains the following Normative Text

Start Existing Normative -------------------- Payload Format Indicator

If absent, the PUBLISH payload consists of unspecified bytes.

1 (0x01) Byte  Identifier of the Payload Format Indicator. Followed by the Value of the Payload Format Indicator, either of

0 (0x00) Byte Indicates that the payload is unspecified bytes, this is equivalent to not sending a Payload Format Indicator.

1 (0x01) Byte Indicates that the payload is UTF-8 Encoded Character Data. Note that the UTF-8 Data in the payload does not include a length prefix, nor is it subject to the restrictions described in section 1.5.3.

--- New Addition ---

2 (0x02) Byte indicates that a MIME content-type string follows.  Immediately following this byte is a UTF-8 string containing the  MIME content-type string. The interpretation of the MIME string is the responsibility of the Application. The MQTT receiver does not check that the string matches the requirements of RFC-2184 or RFC-2231.

----- End New Addition

A server MUST send the Payload Format Indicator unaltered to all subscribers receiving the publication, using this version of MQTT. The receiver is not required to validate that the payload is of the format indicated, however it MAY close the network connection if it  discovers that the payload does not match the Payload Format Indicator.

-- END of existing normative

I ask the TC to vote on including this proposed normative text in the next working draft

> 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

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