-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5
-
Fix Version/s: 5
-
Component/s: core
-
Labels:None
-
Environment:
This was discussed in
MQTT-276with notes from the F2F meetings and has been tracked inMQTT-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."
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."
-
Proposal:
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.