OASIS members and interested parties,
On 25 April 2016, the OASIS Message Queuing Telemetry Transport (MQTT) TC approved [1] the revised charter included below. The TC will hold its first meeting under this revised charter from 15:00 to 16:00 UTC (11:00am to 12:00pm EDT) on 16 June 2016. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode and language specified in this revision will constitute the TC's official charter beginning with that meeting.
OASIS and the TC welcome participation by all interested parties. The eligibility requirements for becoming a participant in the TC are:
(a) you must be an employee of an OASIS member organization or an individual member of OASIS, and
(b) you must join the Technical Committee, which members may do by using the Roster "join group" link on the TC's home page at [2].
Note that everyone who wishes to participate must explicitly join the TC as described in (b). Membership under the original charter does not automatically carry over.
Non-OASIS members who wish to participate may contact us about joining OASIS [3]. Instructions for joining the Technical Committee can be found at the "Join This TC" link on the TC's public home page [4]
Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation in our work.
---
[1] recharter ballot:
[2] TC web page:
--- Revised Charter ---
Section 1: TC Charter
(1)(a) TC Name
OASIS Message Queuing Telemetry Transport Technical Committee
(1)(b) Statement of Purpose
The purpose of the Message Queuing Telemetry Transport (MQTT) Technical Committee is to standardize a lightweight publish/subscribe messaging protocol designed to be open, simple, lightweight, and suited for use in constrained networks and multi-platform environments. The TC will accomplish this purpose through the refinement of an input specification.
Background and Opportunity:
Many industries are seeing rapid demand for products and solutions which map physical world events into digital events for applications and large scale distributed services. These applications and services need to connect and communicate with devices ranging from simple sensors, actuators and complex embedded edge-of-network controllers, to mobile devices, often over wireless networks.
Needs and Requirements:
A simple, predictable, and easy to implement message protocol is needed for connecting embedded and mobile devices such as physical sensors, controllers, and smart phones with servers used in Web, enterprise, and other applications where a lightweight messaging protocol is desired. The protocol must be able to cope with runtime platform constraints, network constraints and various combinations of both. It must support implementations that run on embedded devices with limited power, processor or memory resources, connecting to a range of web services and enterprise middleware in constrained environments where networks may have any combination of low bandwidth, intermittent connectivity, unpredictable reliability, or high data cost.
Experience with physical world messages and events across many industry domains has identified key requirements for such a message protocol:
* Bi-directional messaging to uniformly handle both signals and commands.
* Determinable delivery of messages to and from sensors and actuators, and other resource constrained devices connected over intermittent, limited bandwidth networks. Basic Quality of Service (QoS) levels are needed to reflect tradeoffs between bandwidth, availability, and delivery guarantees. Always-connected and sometimes-connected models both need to be supported. A message subscriber must be able to set up a quality of service needed that reflects the constraints and characteristics of message source’s network connection.
* Connectivity Awareness. To support intermittent networks, the publish/subscribe infrastructure needs to provide message subscribers, if necessary, a means to determine the likely connected, disconnected or error state of the end devices in the network.
* Loose coupling to support dynamic system environments where high volumes of physical world messages and events need to be made available to enterprise servers and other consumers in ways which may not have been originally anticipated. Time, space, and synchronization decoupling are needed.
* Constrained operations. Instrumentation of the physical world must be supported in a proliferation of platforms, technologies and networks that are driven by very diverse equations of cost, technology and physical constraints.
* Scalability suitable to supporting environments where millions of devices are connected to large scale distributed services.
Value of Standardization:
Although connectivity solutions currently exist to integrate these types of systems, the lack of a standardized messaging protocol to address the inherent constraints and fragmentation has become an inhibitor in growing markets. Standardization of an open protocol that addresses the technical and market requirements can overcome these inhibitors through:
* Choices. With a standard protocol, initial choices in devices, networks and suppliers, will not limit choices and adaptability in the future. A standard protocol that supports current and future device payload formats will support deployment, connectivity, and reconfiguration over a wide range of network and server characteristics.
* Flexible Integration. Even if highly effective, decoupling techniques between internal device infrastructure and external systems will not see widespread adoption without standardization. With devices and device controllers utilizing a standardized message protocol, a basic publish/subscribe model can support integration with a wide range of established messaging and event processing systems, allowing subscribers to effectively decouple from device and network APIs.
* Time to Market. Porting and supporting multiple protocols on multiple platforms tends to inhibit adoption in control and instrumentation systems, which are built using many variations of hardware and software platforms, device types, and networks. Providing an open protocol that scales well from critical embedded systems up to high volume enterprise transaction processing, and one that is data, platform and language independent, will shorten time to market and support new levels of integration.
* Skills. A standard, based on protocol and programming models familiar to both embedded and IT programming communities, will accelerate markets by building on skilled resources that already understand these types of solutions.
(1)(c) Scope
The TC will accept the OASIS Standard MQTT Version 3.1.1 as its input specification. The TC will also accept as input a list of issues and recommended changes from the TC Members, incorporating appropriate additional contributions to the TC.
All contributions will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter and its schedule.
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
It is often expensive or impractical to immediately upgrade mobile and other field equipment in response to protocol updates. There needs to be a careful balance between feature enhancements and potential disruption to existing implementations.
The newer version of the standard will build on the previous version so that it is straightforward for existing implementations to support multiple versions.
This TC may also produce the following non-normative Committee Notes for the MQTT specification:
* A requirements and recommendations document for enhancements or issues deemed within in scope but which could not be included in the next version of the specification. These will be collected for consideration in a future version of the standardized specification.
* Primers or white papers describing usage examples, scenarios and/or best practices.
* Test scenario descriptions.
Out of Scope
Any proposal that does not contribute to one or more of the categories listed in the Scope of Work section is deemed out of scope. Furthermore, any proposal that cannot be completed within the deliverable milestone is deemed out of scope. The following items are specifically out of scope:
* The TC will not specify mappings of MQTT functions described in the specifications, to any programming language or particular messaging middleware.
* The TC will not produce reference implementations of the protocol.
* Except for the values and fields directly related to the MQTT protocol, the TC will not prescribe the payload format of messages that are published according to the specifications.
* The TC will not identify MQTT topics nor prescribe any mechanism or convention for classification of MQTT topics or topic spaces.
* Transport level security is assumed and no mandatory security features will be added.
Contributions to this TC which are out of scope for this charter may be accumulated and taken into consideration for potential development in a future charter.
Maintenance
Once the TC has completed work on a deliverable and it has become an OASIS Standard, the TC will enter "maintenance mode" for that deliverable.
The purpose of maintenance mode is to provide fixes to address ambiguity, inconsistencies and errors. The maintenance mode will not functionally enhance a previously adopted deliverable or extend its functionality.
The TC will collect issues raised against the deliverables and periodically process those issues. Issues that request or require new or enhanced functionality shall be marked as enhancement requests and set aside. Issues that result in the clarification or non-substantive correction of the deliverables shall be processed. The TC shall maintain a list of these adopted clarifications and may periodically create a new maintenance revision of the deliverables including these updates.
(1)(d) Deliverables
The TC will prepare an initial Committee Specification Draft before the end of 2016.
The TC will produce the OASIS standard version of the MQTT protocol specification, targeted for completion within twelve months following the initial TC meeting. The TC may then advance this version to ISO/IEC JTC 1 through the JTC 1 PAS Transposition Process.
(1)(e) IPR Mode
The TC shall operate under Non Assertion Terms.
(1)(f) Audience
* Developers of products and solutions in constrained environments for which the MQTT specification is designed, such as devices, edge-of-network servers/controllers, monitoring servers, embedded and control systems, embedded platforms, mobile and web applications, middleware and enterprise applications as well as network providers.
* System integrators at multiple levels will apply this specification, including integration with products and solutions from various wireless network providers and middleware suppliers.
* Companies offering next generation large scale distributed services for IoT scenarios
(1)(g) Language
TC business will be conducted in English.
Section 2: Additional Information
(2)(a) Identification of Similar Work
The CoAP work at IETF includes shares some protocol characteristics in common with MQTT that should be complementary in sensor network configurations.
The Eclipse M2M Industry Working Group supports open source implementations of this protocol and may be interested in supporting standardized versions.
The OASIS AMQP Technical Committee has released a specification that provides for transaction and publish and subscribe messaging between autonomous businesses, departments and applications using an open protocol for enterprise middleware. This MQTT TC complements the AMQP TC by providing a means by which sensors, control systems, embedded systems and mobile devices can publish and subscribe low-level, technically-orientated data. There is natural affinity to bridge MQTT with AMQP, so as to connect telemetry with enterprise applications.
(2)(b) First TC Meeting
Richard Coppen will sponsor the conference call from 11:00am to 12:00pm EDT on June 16, 2016.
(2)(c) Ongoing Meeting Schedule
There will be reoccurring biweekly meetings on Thursdays from 11:00am to 12:00pm EDT.
The initial meetings will be sponsored by IBM.
(2)(d) TC Proposers
Not applicable for re-charter.
(2)(e) Primary Representatives' Support
Not applicable for re-charter.
(2)(f) TC Convener
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.orgPrimary: +1 973-996-2298
Mobile: +1 201-341-1393