[CESG] [OASIS] Proposed Charter for Message Queuing Telemetry Transport TC

Thu Jan 24 13:15:34 EST 2013

Dear all,

In order to keep the CESG aware of OMG / OASIS activities similar to those 
performed by CCSDS, I am attaching below a mail from them. OASIS is 
forming a technical committee for Message Queuing Telemetry Transport 
(MQTT) which is a lightweight pub/sub message bus for telemetry very close 
to being a standard that effectively competes with AMS.

We would like to get your feedback   

ciao
nestor
========================================
Subject: [members] Proposed Charter for MQTT TC
Date: Mon, 14 Jan 2013 11:16:31 -0500
From: Chet Ensign <chet.ensign at oasis-open.org> <
mailto:chet.ensign at oasis-open.org> 
To: tc-announce at lists.oasis-open.org <tc-announce at lists.oasis-open.org> <
mailto:tc-announce at lists.oasis-open.org> , members at lists.oasis-open.org <
members at lists.oasis-open.org> <mailto:members at lists.oasis-open.org> , 
oasis-charter-discuss at lists.oasis-open.org <
oasis-charter-discuss at lists.oasis-open.org> <
mailto:oasis-charter-discuss at lists.oasis-open.org> 
CC: Alex.Kritikos at softwareag.com <Alex.Kritikos at softwareag.com> <
mailto:Alex.Kritikos at softwareag.com> , arlen.nipper at cirrus-link.com <
arlen.nipper at cirrus-link.com> <mailto:arlen.nipper at cirrus-link.com> , 
Arlen.nipper at gmail.com <Arlen.nipper at gmail.com> <
mailto:Arlen.nipper at gmail.com> , Dave Ings <ings at ca.ibm.com> <
mailto:ings at ca.ibm.com> , Diane Jordan <drj at us.ibm.com> <
mailto:drj at us.ibm.com> , hilary.tomasson at eurotech.com <
hilary.tomasson at eurotech.com> <mailto:hilary.tomasson at eurotech.com> , 
marco.carrer at eurotech.com <marco.carrer at eurotech.com> <
mailto:marco.carrer at eurotech.com> , Peter Niblett <
peter_niblett at uk.ibm.com> <mailto:peter_niblett at uk.ibm.com> , 
Prasad.Yendluri at softwareag.com <Prasad.Yendluri at softwareag.com> <
mailto:Prasad.Yendluri at softwareag.com> , raphael.cohn at stormmq.com <
raphael.cohn at stormmq.com> <mailto:raphael.cohn at stormmq.com> , 
dedeugd at us.ibm.com <dedeugd at us.ibm.com> <mailto:dedeugd at us.ibm.com> , 
Carol Geyer <carol.geyer at oasis-open.org> <
mailto:carol.geyer at oasis-open.org> , Robin Cover <
robin.cover at oasis-open.org> <mailto:robin.cover at oasis-open.org> 

To OASIS Members:

A draft TC charter has been submitted to establish the OASIS Message 
Queuing Telemetry Transport (MQTT) Technical Committee. In accordance with 
the OASIS TC Process Policy section 2.2: (
https://www.oasis-open.org/policies-guidelines/tc-process#formation) the 
proposed charter is hereby submitted for comment. The comment period shall 
remain open until 11:59 pm ET on 28 January 2013.

OASIS maintains a mailing list for the purpose of submitting comments on 
proposed charters. Any OASIS member may post to this list by sending email 
to: oasis-charter-discuss at lists.oasis-open.org. All messages will be 
publicly archived at: 
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who 
wish to receive emails must join the group by selecting "join group" on 
the group home page: 
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. 
Employees of organizational members do not require primary representative 
approval to subscribe to the oasis-charter-discuss e-mail.

A telephone conference will be held among the Convener, the OASIS TC 
Administrator, and those proposers who wish to attend within four days of 
the close of the comment period. The announcement and call-in information 
will be noted on the OASIS Charter Discuss Group Calendar.

We encourage member comment and ask that you note the name of the proposed 
TC (MQTT) in the subject line of your email message.

--- TC CHARTER

(1)(a) Name of Technical Committee:

OASIS Message Queuing Telemetry Transport (MQTT) Technical Committee

(1)(b) Statement of purpose.

The purpose of the Message Queuing Telemetry Transport (MQTT) Technical 
Committee is to define an open publish/subscribe protocol for telemetry 
messaging 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 enterprise and Web 
applications, bringing an inherent need to integrate sensors, actuators 
and other types of devices with a wide range of application middleware and 
Web programming models. These applications 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 intermittently-connected networks and 
devices, 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 that 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 large numbers of 
devices need to be connected to a server infrastructure.

> Value of Standardization:
Although connectivity solutions currently exist to integrate these types 
of systems, the lack of a standardized messaging protocol designed 
explicitly to address the needs and requirements listed above 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 of Work of the TC:

The TC will accept, as its input document, Version 3.1 of the MQTT 
specification as published by Eurotech and IBM, and publically available 
under royalty free terms at http://mqtt.org/documentation. The TC will 
also accept as input a list of issues and recommended changes from the TC 
Members. Changes to the input document, other than editorial changes and 
other points of clarification, will be limited to the Connect command, and 
should be backward compatible with implementations of previous versions of 
the specification such that a client coded to speak an older version of 
the protocol will be able to connect to, and successfully use, a server 
that implements a newer version of the protocol. Mobile and other field 
equipment is often expensive or otherwise impractical to upgrade 
immediately in response to server and other IT version changes. A goal of 
the TC is to minimize disruption to existing impleme!
 ntations
, making it straightforward to support both the Version 3.1 of the MQTT 
specification and the OASIS standard.

Changes to the input document or other 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.

The scope of the TC's first set of deliverables includes further 
refinement of the input document, addressing specification issues raised 
by authoring companies, incorporating appropriate additional contributions 
to the TC, and addressing issues raised in the TC itself.

In Scope

The scope of the TC?s work is to refine and finalize the input MQTT 
specification document, and to address specification issues raised in the 
TC in order to produce a standard version of the specification covering 
the following concepts and capabilities:

a - Use of a publish-subscribe message pattern to provide one-to-many 
message distribution and decoupling of applications

b - A messaging transport that is agnostic to the content of the payload

c - Use of TCP/IP to provide basic network connectivity

d - QoS specifications for message delivery:
   > At Most Once: where messages are delivered according to the best 
efforts of the underlying TCP/IP network. Message loss can occur here. 
This level could be used, for example, with ambient sensor data where it 
does not matter if an individual reading is lost as the next one will be 
published soon after.
   > At Least Once: where messages are assured to arrive but duplicates 
may occur.
   > Exactly Once: where message are assured to arrive exactly once. This 
level could be used, for example, in control systems where duplicate 
triggers or lost messages could lead to incorrect commands being sent, or 
invalid business logic being triggered.

e - Maintaining a very low transport overhead (fixed-length header of 2 
bytes), and minimizing protocol exchanges to reduce network traffic.

f - A mechanism to notify interested parties to an abnormal disconnection 
of a client using a keep-alive message and a last-will-and-testament 
mechanism.

This TC may produce the following non-normative Committee Notes for the 
MQTT specification:

a ? A requirements and recommendations document for enhancements which 
break backward compatibility or are otherwise deemed out of scope. These 
will be collected for consideration in a future major revision or 
re-charter of the TC.

b ? A requirements and recommendations document for enhancements or issues 
deemed within in scope but which cannot otherwise be contained in the 
first version of the standard. These will be collected for consideration 
in a future major or minor revision of the standardized specification.

c ? A primer or white paper describing usage examples, scenarios and/or 
best practices, including examples of integration with message servers.

d ? A primer or white paper describing examples and usage of MQTT topics 
with commonly available registry and discovery mechanisms.

e - Test scenario descriptions.

Out of Scope

A non-exhaustive list is provided below for the sake of clarity. If some 
function, mechanism or feature is not mentioned here as Out of Scope, and 
it is not listed as In Scope in the Scope of Work section, then it will 
also be considered as 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 will be assumed and no security features will 
be added.

Maintenance

Once the TC has completed work on the deliverable and it has become an 
OASIS Standard, the TC will enter "maintenance mode" for the deliverable.

The purpose of maintenance mode is to provide minor revisions to 
previously adopted deliverables to clarify ambiguities, inconsistencies 
and obvious 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 
minor revision of the deliverables including these updates.

(1)(d) Deliverables

The TC shall produce the OASIS standard version of the MQTT protocol 
specification which will be targeted for completion within 12 months of 
the TC's first meeting. Follow-on versions of the standard to address 
additional in scope capabilities may be developed by the TC on a schedule 
to be defined by the TC.

(1)(e) IPR Mode

The TC shall operate under Non Assertion Terms.

(1)(f) Anticipated 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.

- Cellular providers and other communications companies participating in 
M2M based service offerings will apply this specification for service 
level offerings.

(1)(g) Language

The TC will use English as the language for conducting its operations.

(2) Non-normative information regarding the startup of the TC:

(2)(a) Identification of similar or applicable work that is being done in 
other OASIS TCs or by other organizations:

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 & 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) Date, Time and Location of First Meeting

The first meeting will be held in person on Monday, 25 March 2013, at 9:00 
AM Eastern Standard Time. It will be hosted by IBM at a location in 
Boston. Conference calling facilities will be provided for those who 
cannot attend in person.

The details of the first TC meeting will be determined and confirmed prior 
the close of the member review period.

(2)(c) Ongoing Meeting Plans and Sponsors

The MQTT TC will meet by telephone every other week at a time to be 
determined.  The time, date and recurrence of the periodic phone call will 
be confirmed at the MQTT TC will also hold face-to-face meetings 
periodically.  The date, time and place of the face-to-face meetings will 
be determined by the MQTT TC.

(2)(d) Names, electronic mail addresses, and membership affiliations of at 
least Minimum Membership who support this proposal and are committed to 
the Charter and projected meeting schedule:

Hilary Tomasson, hilary.tomasson at eurotech.com (Eurotech)
Marco Carrer, marco.carrer at eurotech.com (Eurotech)
Peter Niblett, peter_niblett at uk.ibm.com (IBM)
Scott de Deugd, dedeugd at us.ibm.com (IBM)
Diane Jordan, drj at us.ibm.com (IBM)
Arlen Nipper, arlen.nipper at cirrus-link.com (Individual/Associate)
Alex Kritikos, Alex.Kritikos at softwareag.com (SoftwareAG)
Prasad Yendluri, Prasad.Yendluri at softwareag.com (Software AG)
Raphael Cohn, raphael.cohn at stormmq.com (Individual/Associate)

(2)(e) For each OASIS Organizational Member listed in (2)(d), the name, 
electronic mail address, membership affiliation, and statement of support 
for the proposed Charter from the Primary Representative:

Marco Carrer,marco.carrer at eurotech.
Eurotech
As Eurotech's primary OASIS rep, I approve the MQTT TC Charter, and 
endorse our proposers (listed above) as named co-proposers.

Dave Ings, ings at ca.ibm.com
IBM
As IBM's primary OASIS rep, I approve the MQTT TC Charter, and endorse our 
proposers (listed above) as named co-proposers.

Prasad Yendhuri, Prasad.Yendluri at softwareag.com
Software AG
As Software AG's primary OASIS rep, I approve the MQTT TC Charter, and 
endorse our proposers (listed above) as named co-proposers.

(2)(f) Convener
Scott de Deugd, IBM

(2)(h) Contributions of existing technical work:

The Version 3.1 of the MQTT Specification will be used as an input 
document by the TC, and can be found at 
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html

/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393

---------------------------------------------------------------------

This email list is used solely by OASIS for official consortium 
communications.

Opt-out requests may be sent to member-services at oasis-open.org, however, 
all members are strongly encouraged to maintain a subscription to this 
list.

Dr. James Afarin 
Space Data Standards Manager 
Space Communications and Navigation Office 
Office: 202-358-5221 
Mobile: 216-469-5976
This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20130124/3a4c9cf7/attachment-0001.htm