Major 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
Ken - You correctly pointed out and it is an important question for us answer whether the client will decide at runtime by discovering the optional features or it decides this at the design, implementation and testing time based on product manuals.
Optional Server Capabilities in MQTT v5:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Server capabilities which are already advertised through CONNACK:
1) Maximum QoS – The purpose of this capability in server is to inform the client that what is the maximum QoS supported by the server. Maximum QoS is advertised to the client using CONNACK control packet. Clients mention the Maximum QoS in the subscription options of the SUBSCRIBE control packet
Advertisement – Advertisement from MQTT Sever to MQTT Client happens through CONNACK Control Packet Field Maximum QoS.
2) Retain Available – This field in CONNACK needs to be reflected in a positive way and should be renamed from Retain Unavailable to Retain Available. Retain Available should have a one byte value defaulting to 1. This will allow both positive and negative to be asserted by the Server. In absence of this field in CONNACK it would mean that the server support Retain.
If the Server included Retain Available in its CONNACK response and the value is set to 0 to a Client and it receives a PUBLISH Packet with the RETAIN flag is set to 1, then it MUST send a DISCONNECT Packet with a return code 0x9E Retain Not Supported and disconnect the network.
Advertisement - Advertisement from MQTT Sever to MQTT Client happens through CONNACK Control Packet Field Retain Available.
3) Maximum Packet Size – This field in CONNECT and CONNACK would define the maximum packet size which could be accepted by the Client and Server respectively.
Advertisement - Advertisement from MQTT Server to MQTT Client happens through CONNACK Control Packet Field Maximum Packet Size.
4) Topic Alias Maximum – Topic Alias Maximum could be set on both CONNECT and CONNACK. When set on CONNECT the client tells the server the maximum limit of topic alias it is willing to hold on this connection. When set on CONNACK the server tells the client the highest topic alias value it will accept by the client on this connection.
Advertisement - Advertisement from MQTT Server to MQTT Client happens through CONNACK Control Packet Field Topic Alias Maximum.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Server capabilities which could be advertised through CONNACK:
1) Wild Card Subscription Available - Wild Card Subscription Available should have a one byte value defaulting to 1. This will allow both positive and negative to be asserted by the Server. In absence of this field in CONNACK it would mean that the server support Wild Card Subscriptions.
In the case where server has already advertised that it does not supports Wild Card Subscriptions and the client sends a SUBCRIBE with topic filter having Wild Card Subscriptions then the it should be treated as a protocol error and a DISCONNECT packet with RC Not Authorized or a new RC could be sent followed by the network disconnect.
In some cases server MAY say that it supports Wild Card Subscriptions but may reject the SUBSCRIBE request at SUBACK and flow the negative RC on SUBACK
Advertisement – Advertisement from MQTT Server to MQTT Client happens through a binary property in CONNACK Control Packet Field Wild Card Subscription Available.
2) Subscription Identifiers Available - Subscription Identifiers Available should have a one byte value defaulting to 1. This will allow both positive and negative to be asserted by the Server. In absence of this field in CONNACK it would mean that the server support Subscription identifiers.
In the case where server has already advertised that it does not support Subscriptions Identifiers are and the client sends Subscription Identifiers then the it should be treated as a protocol error and a DISCONNECT packet with RC Not Authorized or a new RC could be sent followed by the network disconnect.
Advertisement – Advertisement from MQTT Server to MQTT Client happens through a binary property in CONNACK Control Packet Field Subscription Identifier Available.
3) Shared Subscription Available - Shared Subscription Available should have a one byte value defaulting to 1. This will allow both positive and negative to be asserted by the Server. In absence of this field in CONNACK it would mean that the server support Shared Subscriptions.
In the case where server has already advertised that it does not support Shared Subscriptions Identifiers are and the client sends Shared Subscription in SUBSCRIBE then the it should be treated as a protocol error and a DISCONNECT packet with RC Shared Subscription Not Supported will be sent followed by the network disconnect.
Advertisement – Advertisement from MQTT Server to MQTT Client happens through a binary property in CONNACK Control Packet Field Shared Subscription Available.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Additional Return Code on CONNACK:
Will Messages: Server currently reject the CONNECT with CONNACK RC 135 (0X87) Not Authorized when a CONNECT with Will Message is set and the Server does not support that. This RC is very generic and a new RC could be added in CONNACK specifically for Will Messages Not Supported by the Server.
TC has agreed with the findings and the editors will go ahead and add the new properties and Return Codes
Issue included in MQTTv5.0 CS01 December 25, 2017
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:There are several others which could be optional
There exist a number of things which are limits
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:
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.