[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-324) Consolidate list of optional server capabilities and review how they are signaled to the client
[ https://issues.oasis-open.org/browse/MQTT-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64648#comment-64648 ] Ken Borgendale commented on MQTT-324: ------------------------------------- Just to go back in history a bit, this was expensively discussed at the F2F in January 2016 as MQTT-276. At that time we decided to specify four things as the primary candidates for server advertisements of function not supported: - QoS=2 - Retrain - Durable sessions - Maximum message size (it was noted this is really a constraint and not an optional feature) We created separate issues to create these properties using MQTT-276 as a tracking Jira. As we have added new items we have talked about optionality. I continue to believe that any discussion of optionality belongs with the individual items and not as a global issue. We can put this issue in the tracking component, but it seems too general to make it easy to resolve and apply changes to the spec. > Consolidate list of optional server capabilities and review how they are signaled to the client > ----------------------------------------------------------------------------------------------- > > Key: MQTT-324 > URL: https://issues.oasis-open.org/browse/MQTT-324 > Project: OASIS Message Queuing Telemetry Transport (MQTT) TC > Issue Type: Task > Components: core > Affects Versions: 5 > Reporter: Shawn McAllister > Assignee: Rahul Gupta > > This jira is raised as a result of a decision from the Nov 17 TC: > The action is to perform the following analysis to then determine if there should be technical changes to the specification:: > - create a consolidated list of optional server capabilities (eg. support for Retain, wildcard subscriptions, QoS2, subscription identifiers, etc) > - document the current method by which a client learns of these capabilities for a given connection. > - determine if the manner in which the client learns of these is adequate or should be changed to be more uniform, consistent, simple > The intent is to ensure we do not have what appear to be randomly different ways of notifying the client of what is and is not supported for a given connection. > Depending on the outcome of this analysis, normative or non-normative sections may be added to the specification -- 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]