[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-301) Metadata: CONNACK Retained messages supported
[ https://issues.oasis-open.org/browse/MQTT-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63562#comment-63562 ] Ed Briggs commented on MQTT-301: -------------------------------- Ken, If a server can simply ignore the RETAIN flag in the CONNECT and PUBLISH messages that arrive before it sends a CONNACK, and it can also ignore RETAIN after sending a CONNACK with a RETAIN Unavailable advertisement on some, but not necessarily all messages, should we just say that implementing RETAIN is not a mandatory requirement for compliance with MQTT 5.0? I'm not trying to be flippant here, I am having difficulty imagining how to specify this kind of 'maybe sometimes' or 'client has to guess' behavior in normative text. > Metadata: CONNACK Retained messages supported > --------------------------------------------- > > Key: MQTT-301 > URL: https://issues.oasis-open.org/browse/MQTT-301 > Project: OASIS Message Queuing Telemetry Transport (MQTT) TC > Issue Type: New Feature > Components: core > Affects Versions: 5 > Reporter: Brian Raymor > Assignee: Ed Briggs > Labels: Proposed > > 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." -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]