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-291) Collect Version Compatibility and Upgrade Issues


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

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

We should get some direction on this going into the CSD for MQTTv5.0.  Currently most of the references to MQTTv3.1.1 are gone from the spec and are left only in non-normative text.

While I agree with Ed that for implementors of this spec it is very important that a transition from V3.1.1 to V5 works well, it is not clear that the spec should mandate how to do this.  Consider the case of how to handle a session in a server which supports multiple versions of MQTT.

1. Use a separate session name space by version (in an extreme case, separate servers) 
2. Do not allow a connection from a version other than the version which created the session
3. Use the rules of version of the current connection to the session

There are advantages and disadvantages to each of these implementations.  A server implementing any of these would presumably conform to the spec, as would a server which only implemented MQTTv5.0.  

I would suggest that we remove even the non-normative comments about how to implement multi-version support.  We can leave in a recommendation that implementors provide means for users to migrate from older versions of MQTT to MQTTv5.

> 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
>          Components: Tracking
>    Affects Versions: 5
>            Reporter: Ed Briggs
>            Assignee: 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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]