[OASIS Issue Tracker] (MQTT-324) Consolidate list of optional server capabilities and review how they are signaled to the client

From
OASIS Issues Tracker <>
Date
2016-12-08T16:55:46+00:00
ID
Thread
[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=64649#comment-64649 ] 

Stefan Hagen commented on MQTT-324:
-----------------------------------

I like Ken and Ed suggest to tackle it more like a short list or maximally present like a block matrix with only the reasonable x,y dimensions per "block" - as mentioned in the call w.r.t. slide page 9 matrix, tit is more irritating than enlightening when only local info of a correlation is to be expected reasonably. (this is independent of optional, new or what attribute is chosen, it is just a critique / feedback on the correlating / segmenting approach.

> 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)