OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

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

Rahul Gupta commented on MQTT-324:
----------------------------------

https://www.oasis-open.org/apps/org/workgroup/mqtt/download.php/59654/Optional%20features%20with%20MQTT%20v5%20-%2012-15-2016.docx

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.




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