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

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

What exists in these documents is not really a list of optional capabilities, it is a list of new things added in MQTTv5.  The actual list of optional items cannot really be specified as the server can close any connection if it specifies something it does not like.  Thus even the MUST does not help much.  For instance a server must support ClientIDs of 1-23 alphanumeric characters, but it is free even then to reject all possible clientID settings matching this which do not match its ClientID rules.

On CONNECT you can also say that the following are optionally supported
Will flag
Will QoS       
Will Retain    (we cover this in MQTTv5 in the Retain unavailable)
Username
Password
CleanSession  (the server might not support durable sessions)
KeepAlive (the server can reject any connection if it does not like the keepalive)
ClientID (the server can reject any connection if it does not like the clientID)
Will Message (the server can reject any connection if it does not like the will message)

Similar things exist for existing PUBLISH and SUBSCRIBE where the server can reject oor simply not do anything which it does not support.  For instance on PUBLISH, it is allowed to simply send the ACK and not forward the message.

Also note that the DISCONNECT Packet is itself optional for a server to send, in addition to the fields within it




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