[OASIS Issue Tracker] (MQTT-291) Collect Version Compatibility and Upgrade Issues

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

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

Ken Borgendale commented on MQTT-291:
-------------------------------------

I accept that I am most likely in the minority on this, but I believe that the various versions of MQTT should not try to define the interaction with different versions of MQTT.  As we have agreed, one version of MQTT cannot define its interaction with a future version of MQTT.  I have no problem with having non-normative text about this but I think it is a madness to specify outside of this version.  Although we are constrained from creating a conformance test, it should be possible for anything in normative text to be validated by a conformance test.

Although many of us already support multiple versions of MQTT and plan to continue adding versions is the future,  no implementation is required to support multiple versions of MQTT.  Therefore it would be a fully compliant MQTTv5.0 server which rejected any MQTTv3.1.1 connection.  It would be valid to implement the two versions on separate servers which do not interact with each other, and it is valid to have a single server which implements both and processes messages as best it can between them.  Since a server is free to reject any connection it is not willing to service, it could simply reject a connection with if a session by that name already exists (as we do if a session exists from a different protocol).

Thus the sort of normative statement you could make is:  If you support multiple versions of MQTT, and if you accept connections from multiple of them with the same ClientID, and if you decide to treat them as the same session, this is what you should do.

In reality we currently handle this on the muddle thru rule.  If the incoming message has replyto, correlation, and message format and your outgoing message protocol does not support them, then you do not send them.  We have this already in JMS and other more complex protocols.  If you have a similar but non-matching concept like a protocol with seven QoS levels, it gets mapped to MQTT with 3 (and from MQTT to one of the output QoS as required).  If you round trip thru a a version or protocol with less functionality, you will suffer information loss.  However, If the server has a configuration to say: do not forward a message with a ReplyTo to a v3.1.1 client, I would suggest that is a valid thing for a server to allow (and I could always say the subscription is not authorized to receive such a message, and then I guess we all agree it is valid).

My suggestion for the non-normative text is to say:  It is highly desirable to have servers which support multiple versions of the protocol to make it easier for clients to gradually upgrade connections to the new version.  It is very important to preserve the existing level of function when some clients upgrade to a new version.  However, some new function will only fully work when all clients and servers in the messaging path are updated to the new version.

> Collect Version Compatibility and Upgrade Issues
> ------------------------------------------------
>
>                 Key: MQTT-291
>                 URL: https://issues.oasis-open.org/browse/MQTT-291
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>    Affects Versions: 5
>            Reporter: Ed Briggs
>
> A recurring theme in discussions on various JIRAs concerns how to handle various version upgrade or interop issues. In the interest of finding a consistent approach to these sorts of issues, I'm a creating this JIRA so we can collect the issues.
> I'll start the process with one example issue.  Please add others.
> 1) If an MQTT 3.1.1 client creates a 'persistent session' (CleanSession=0) on a server, and later re-connects to the session using MQTT 5.0, what problems may result?  Should the session be preserved, or destroyed?   The reverse is also interesting: if the session is established with MQTT 5.0, and a subsequent connection is made using MQTT 3.1.1,  is the session still valid and usable? 
> 2).  If an end-to-end path (client-server-client) consists of mixed protocol versions, do any end-to-end operations break?   For example, suppose an MQTT 5.0 client sends a request/reply message to a client which is running MQTT 3.1 or MQTT 3.1.1. ?   What happens?  (This request/reply message contains a reply topic, correlation id, time-to-live field etc. which are not available in MQTT 3.1.1).  The general question is if something breaks, what should be the strategy to handle it (and similar problems)



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)