[OASIS Issue Tracker] (MQTT-249) Add expiry capabilities to MQTT.

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

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

Ken Borgendale commented on MQTT-249:
-------------------------------------

Concerning the proposal from 2016-05-31

This change also affect section 4.1 (Session State) and 3.2.2.2 (Session Present)

- In section 4.1 there is a non-normative statement that specifies the clients and server may delete the client state based on policies or resource constraints.  This is an important thing to state and should be in normative text.

- I do not see the point for the statement about client without clocks and this should be removed.  The client does not need to delete it state when the server does, but could easily be reactive and delete its state on reconnect to the server (if the Session Present flag is not set).  Indeed a client which only uses QoS=0 does not have any state to store, but the server for those same clients might well have session state.

- We should clarify the best use of the interaction of the Session Present flag and the Clean Start flag.  This can either be in the section on the Clean Start or Session Present, but they should reference each other:
* A client without state should set the Clean Start flag to true
* A client which has state but receives a Session Present of 0 should delete that state before continuing.  

- Remove or radically change the first non-normative comment in this section (To ensure consistent state ...).  The statement should be as above that a client without session state should set CleanStart=1.

- Change the second non-normative comment.
* Setting a SessionExpiry of 0 and setting CleanStart=1 is the equivalent of setting CleanSession=1 in MQTT v3.1.1.
* Setting no SessionExpiry of 0 and setting CleanStart=0 is the equivalent of setting CleanSession=0 in MQTT v3.1.1

The third non-normative comment was reworded from the one describing the cleansession flag and is no longer accurate.  I suggest removing it or significantly altering it.  In fact in the new fourth non-normative comment contradicts this one.  

As an encoding issue to discuss.  we currently have customers with load balancer scripts which do a minimal parse the MQTT CONNECT packet looking for the CleanSession=1 flag.  Some of these might get a correct result just looking at the CleanStart flag.  I am a little concerned that in this case we are creating an inhibitor to moving to the new version of MQTT by taking a very common concept like cleansession=1 and splitting it into a flag and an optional id/value.



> Add expiry capabilities to MQTT.
> --------------------------------
>
>                 Key: MQTT-249
>                 URL: https://issues.oasis-open.org/browse/MQTT-249
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>    Affects Versions: 3.1.1
>            Reporter: Andrew Banks
>            Assignee: Andrew Banks
>
> MQTT has the ability to purge all of the session state on demand by using the clean session flag. This proposal is for a time based and more granular capability to clear up state.  
> Add capabilities to MQTT to allow for expiry of.
> 1) Messages.
> 2) Subscriptions.
> 3) All session state, for example if the client is disconnected for a time period then treat it as if it had connected with clean session true.  This is sometimes referred to as offline keep alive.



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