[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-300) Metadata: CONNACK Maximum QoS
[ https://issues.oasis-open.org/browse/MQTT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63598#comment-63598 ]
Andrew Banks commented on MQTT-300:
-----------------------------------
On balance I prefer a model where the server returns its capabilities in the CONNACK and then returns an error if the client does not fall within it. For this Jira, maximum message size and optional retain publication support, ie anything that is optional for the client or server to support. This means that the server does not have to implement, for example Qos=2 if it does not wish to support it.
The criticism of this was that the client application may be able to tolerate the downgraded level of support and not have to adapt to it.
But this toleration could be put in the client library and hence becomes a choice of the implementation.
> Metadata: CONNACK Maximum QoS
> ------------------------------
>
> Key: MQTT-300
> URL: https://issues.oasis-open.org/browse/MQTT-300
> 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]