[OASIS Issue Tracker] (MQTT-419) Ambiguity over Session Expiry

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

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

Ken Borgendale commented on MQTT-419:
-------------------------------------

I have been thinking about the statement: After the Network Connection is closed and the Session Expiry Interval has elapsed without a new connection being made, the Client and Server MUST delete the Session state they hold [MQTT-3.1.2-21]. 

I believe this statement is meaningless.  What this is trying to say is that when a Network Connection is made with a ClientID after more than the Session Expiry Interval of the previous Network Connection has elapsed since the close of the previous Network Connection, the Server MUST create a new Session and return a Session Present of 0.

The server is free to discard the resources used by the session after the expiration interval, but the only required and testable action is that it not allow a reconnect to such a session.

I do not see the point of any statement about what the Client must do.  A client is free at any time to throw its session state away and inform the server of this by using CleanStart=1. A client should not use its client state if the server returns a SessionPresiont=0. 

A server is also free to throw the session state away based on resources, administrative action, or just about any reason it can thing of, and just return a SessionPresent=0 (as explained in section 4.1).

Add to all of this the fact that time intervals a imprecise for a variety of reasons, which makes any statement about "when" somewhat suspect..

My recommendations are:
1. Move what is now  in 3.1.2.12.1 into section 4.1 as the only location of this information.  Add references to it into section 3.1.2.12 and other places as appropriate.  Section 3 is primarily about mechanism, and section 4 about concepts.

2.  Remove the statement which is now MQTT-3.1.2-21.

3. Find some good wording for my convoluted statement above and put it into the Session Present section.

4. Make an explicit statement that if the expiration interval is 0, a reconnect of the session is not allowed.

> Ambiguity over Session Expiry
> -----------------------------
>
>                 Key: MQTT-419
>                 URL: https://issues.oasis-open.org/browse/MQTT-419
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: wd12
>            Reporter: Peter Niblett
>            Priority: Minor
>
> WD11 and 12 are unclear about whether state can continue after the Session Expiry interval has elapsed or not. In particular whether server state gets deleted right away when a client with Session Expiry of 0 disconnects.
> You might imagine that it would get deleted when the Expiry interval elapses (so that if the client reconnects again at that point it would see no state, even if it had clean Start = 0).  Text supporting this view can be found in 3.1.2.11.3 where it says
> "After reconnection, the Session lasts as long as the Network Connection plus the new Session Expiry Interval."
> and in 3.2.2.2 where it says "The Client can discard the Session state on both Client and Server by sending a DISCONNECT packet with Session Expiry set to 0. 
> However the normative statement in 3.1.2.11.3  says
> "After the Network Connection is closed and the Session Expiry Interval has elapsed without a new connection being made, the Client and Server MUST delete the Session state they hold [MQTT-3.1.2-21]. "
> At first sight you might think that's saying the same thing, but I am told that the choice  to use the word "After" rather then "When" is significant, and the intent is that the Server could keep the state for an indefinite length of time after the expiry and still be compliant.  The reasons given for this are:
> i)  the server might be down at the time the interval expires
> ii) it might crash while trying to do a Disconnect(SessionExpiry = 0)
> but we don't say that explicitly, so if you interpret "After" to mean "Any time after" then that particular compliance statement becomes untestable, and therefore rather pointless.
> We need to decide one way or the other (particularly in the case of 0)
> a) Do we tighten up by making the After into a When, or
> b) Make it clear that the State MUST last for at least as long as the Expiry interval, but could continue for some time after that.  For clarity this would require changes to all the sentences I listed above.
> For what it's worth I favour a).  I imagine that there are other normative statements that would not be true if the server crashes, and if we were to go through the spec watering them all down we might not have many left.
>  



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