[OASIS Issue Tracker] Commented: (MQTT-64) Edge case handling of unsubscribe

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

    [ http://tools.oasis-open.org/issues/browse/MQTT-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34231#action_34231 ] 

Nick O'Leary commented on MQTT-64:
----------------------------------

Peter: agreed on all points.

> Edge case handling of unsubscribe
> ---------------------------------
>
>                 Key: MQTT-64
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-64
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.1.1
>            Reporter: Peter Niblett
>
> This issue is related to MQTT-58 
> The meaning of unsubscribe is clear in cases where the topic name(s) that it contains precisely match with topic names that have appeared in earlier subscribe commands, but what happens in other cases? In particular
> 1. Unsubscribe contains an absolute (non-wildcarded) Topic Name, but the client has no subscription (wildcarded or otherwise) currently matching that topic (i.e. the client is not currently receiving any messages that were published to this topic).
> 2. Unsubscribe contains a wildcarded Topic Expression, but the client has no current subscription that overlaps this expression
> 3. Unsubscribe contains a wildcarded Topic Expression, but the client has one or more absolute topic subscriptions that come within the scope of this wildcard expression
> 4. Unsubscribe contains an absolute or wildcarded Topic Expression that has a non-zero ovelap with one or more current subscriptions.
> There are two subcases of the above which we might want to consider as special cases:
> 5. The client has no current subscriptions at all
> 6. Unsubscribe to #
> We need words that will cover each of these cases and determine whether the server should
> i)  Take no action, but respond positively by sending a SUBACK
> ii)  Delete some portion of the client's current subscriptions and then send a SUBACK
> iii) Terminate the client
>  
> It might be helpful to use the conceptual model that I proposed in a comment to issue 58, namely that a client has a single subscription which is the logical disjunction of a set of filters, each filter containing a Topic Expression (absolute or wildcarded).  The effect of subscribe is to add a filter to the list (unless there's one already there with the same expression). My cases then boil down to  asking what unsubscribe should do if 
> a) None of the filters in the list intersect at all with the expression in the unsubscribe
> b) One or more of the filters are completely contained by the expression in the unsubscribe
> c) The expression in the unsubscribe is completely contained by one or more fo the filters in the list
> d) There is a partial overlap between the expression in the unsubscribe and one or more of the filters in the list.
> e) Mixtures of the above

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira