OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt-comment message

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

Subject: RE: [mqtt-comment] MQTT v5.0 RETAIN optional

Hi Christoph,


Reviewing our charter scope - https://www.oasis-open.org/committees/mqtt/charter.php - may offer some insights into our objectives for this version:


The scope of the TC's work is limited to technical refinements of features organized into the following categories:

    • Enhancements for Scalability and Large Scale Systems including the ability to communicate functional levels, define optional functions, and control resource usage.
    • Improved Error Reporting allowing error indications to be returned by both MQTT client and MQTT server with the definition of additional return values.
    • Formalize commonly observed patterns including, but not limited to capability discovery, request-response, correlation.
    • Extensibility Mechanisms enabling the addition of data fields on packets, including application-extensible data whose interpretation is not specified by MQTT.
    • Performance Improvements and additional support for Resource Constrained MQTT clients.


MQTT enhancements for large scale distributed systems has been tracked in https://issues.oasis-open.org/browse/MQTT-276 and was extensively discussed in the TC.


Regarding “Would you include in the v5 specification a section were all features which became optional compared to MQTT3.1.1” in your related messages about optional features, I added a comment to - https://issues.oasis-open.org/browse/MQTT-291.


Thank you for your feedback,







From: mqtt-comment@lists.oasis-open.org [mailto:mqtt-comment@lists.oasis-open.org] On Behalf Of c@ckrey.de
Sent: Tuesday, March 14, 2017 5:04 AM
To: mqtt-comment@lists.oasis-open.org
Subject: [mqtt-comment] MQTT v5.0 RETAIN optional


Dear committee members,


I may be a bit late in the process, but I am very concerned about the future direction of MQTT:


RETAINed messages have always been a key feature of MQTT and are substantial for applications which

do not want to implement a secondary transport to modify or query status information.


Your current working draft #11 shows the broker support of RETAINed messages and wills as „MAY“ while 

MQTT3.1.1 insists on a „MUST“ for a broker to be compliant.


I know that a number of major IoT platforms decided not to make RETAIN available over MQTT

(e.g. AWS IoT, IBM IoT Foundation Services).


Please review your decision to make support or RETAINed messages optional. Otherwise I see

- interoperability issues between applications and brokers (think bridging)

- more complex client application

- a decrease in the use of MQTT




Christoph Krey

<c@ckrey.de> 7582 9188 8D6C E945 15BA  4CD9 900D FB34 2AB0 38D7
Breite Strasse 79, 41460 Neuss, Germany
+49 1511 874 4526


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