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,
…Brian
From: [mailto:]
On Behalf Of
Sent: Tuesday, March 14, 2017 5:04 AM
To:
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
Cheers
Christoph Krey
<> 7582 9188 8D6C E945 15BA 4CD9 900D FB34 2AB0 38D7
Breite Strasse 79, 41460 Neuss, Germany
+49 1511 874 4526
