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

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

This was discussed in MQTT-320 and it was clear that there is no way to be precise about times.   

We might want to be explicit about a session expiration of 0 which is a pretty  non-ambiguous time.

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