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

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64545#comment-64545 ] 

Ken Borgendale commented on MQTT-324:
-------------------------------------

I do not think it is possible to clearly specify the set of optional features.  The problem is that ultimately the server can reject more or less anything with a bad return code, or by closing the network connection.  In some cases the server can simply not do what is requested by the client.

We have a small set of things which we have canonized as optional by putting properties on CONNECT and/or CONNACK to indicate the restrictions to the other side.    

In reality, the limits like max topic alias (0 = do not support topic alias) and max receive (not specified means no flow control) will be used.  For other things like retain and shared subs if they are not available and the client requires them the server is just unacceptable and this is found out in testing and not at connect.

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