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: Recharter: Shared subscriptions and $share


Forwarding to the mailing list for broader awareness and discussion.


The conversation is related to this out-of-scope item in the draft charter:


·       The TC will not identify MQTT topics nor prescribe any mechanism or convention for classification of MQTT topics or topic spaces.




From: Andrew Banks [mailto:andrew_banks@uk.ibm.com]
Sent: Friday, April 1, 2016 12:35 PM
To: Ken Borgendale <kwb@us.ibm.com>
Cc: Brian Raymor <Brian.Raymor@microsoft.com>
Subject: Re: MQTT shared subs and charter


Ken, using the $share topic prefix seems the more natural way to go to me.

To avoid using the $ prefix we would still have to encode the sharename  into the subscribe packet, probably using the same metadata encoding method as for the Publish Metadata. The existence of the sharename should signal the shared subscription and so remove the need to use one of the Qos bits. However, the Subscribe packet can carry multiple subscriptions and SubAck can carry multiple outcomes so that is where it starts to look unnatural.

The $ prefix was reserved in the V3.1.1 specification for uses such as this, and it is being used in practice,  so I think we should alter the charter to make its use allowed.

Andrew Banks
Telephone (44) 1962 816123

From:        Ken Borgendale/Austin/IBM
To:        Andrew Banks/UK/IBM@IBMGB
Date:        31/03/2016 22:18
Subject:        MQTT shared subs and charter

The issue I have with charter and shared subs in the prohibition in the charter of defining topics.  I would prefer to keep this charter limitation but it means that using $shared or any other $ topic to indicate shared subs would not be allowed.  I think it makes much more sense to use one of the bits in the QoS byte of SUBSCRIBE for this purpose.  This is especially true if we also implement nolocal in this way, as there needs to be an explanation of the intersection of shared subs and nolocal.  The problem is that there is no corresponding bit on UNSUBSCRIBE but perhaps we should have an options byte per UNSUBSCRIBE and on UNSUBACK.  This makes them symetical with SUBSCRIBE and allows for a return status on individual UNSUBSCRIBES.

On the issue of shared subs, how you specify shared subs is the simple issue.  Some of the semantics of shared subs are very messy especially any text around overlapping subs and shared subs.

Ken Borgendale  --  kwb@us.ibm.com    1-207-805-6708  1-207-371-8082
Senior Programmer  --  IBM MessageSight - Architect

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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