[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=64652#comment-64652 ] 

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

The whole point of server optional features originated with MQTT-276.  This was a request to admit in the spec that some of the features of MQTT were in fact optional.  The reason for not implementing function was not that the programmers were lazy but that some of the functions of MQTT cause problems for clusters and other distributed servers.  A simple list of those things is:

- QoS=2 (and in some cased QoS=1)
- Retained messages
- Durable sessions (cleansession=0 in MQTTv3.1.1 and SessionExpiry>0 in MQTTv5)
- Shared subscriptions

There are several others which could be optional
- Authentication and authorization
- Will messages 
- Wildcard subscriptions
- Subscription IDs
- Message expiration

There exist a number of things which are limits
- Max packet size
- Flow control
- Max topic alias
- Max subscriptions
- Max connection rate
- Max data rate (bytes, messages)

In addition to these, almost anything can be made an optional feature by simply not allowing any client to use them.  

Besides things which are not implemented, you have things for which this particular connection is not allowed to use.  This could be very complex for instance a particular ClientID might be able to use QoS=2 only on some topics when authenticated as a particular user.  Something like wildcard subscriptions is not an all or nothing.  The server could support only some forms of wildcard or only in some parts of the topic.

There are several possible responses to not supporting something:
- Close the connection
- Just don't do it (just throw away an unsupported publish, and do not make an unsupported subscription)
- Return a bad return code

If we want to advertise what a server can do, the best place is probably in the product documentation.  It seems unlikely that a client will decide at runtime what server to use by making a connection and getting back a response saying it is not supported.  This will be handled during design and validated during initial testing.  When an client app is in production this is never an issue.  While I do not oppose advertisements such as MaxQoS and RetainUnavailable, I think they are pointless.

It might make sense for some of the limits to be sent on the CONNECT or CONNACK.  A good example of that is the MaxTopicAlias.and MaxReceive.  Many of the other limits are only nominally useful to send at runtime as the application needs to be created knowing these constraints.

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