Chet, I have made two insertions to the Charter
to add Paul Fremantle and WSO2 (section 2d and section 2e). This is the
final version per our convener call today.
regards............Scott
Scott de Deugd
IBM Standards
---------------------------
(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 implementations, 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@eurotech.com (Eurotech)
Marco Carrer,
marco.carrer@eurotech.com (Eurotech)
Peter Niblett,
peter_niblett@uk.ibm.com (IBM)
Scott de Deugd,
dedeugd@us.ibm.com (IBM)
Diane Jordan,
drj@us.ibm.com (IBM)
Arlen Nipper,
arlen.nipper@cirrus-link.com (Individual/Associate)
Alex Kritikos,
Alex.Kritikos@softwareag.com (SoftwareAG)
Prasad Yendluri,
Prasad.Yendluri@softwareag.com (Software AG)
Raphael Cohn,
raphael.cohn@stormmq.com (Individual/Associate)
Paul Fremantle,
paul@wso2.com (WSO2)
(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@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@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@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.
Paul Fremantle,
paul@wso2.com WSO2
As WSO2’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 From:
Chet Ensign <
chet.ensign@oasis-open.org>
To:
tc-announce@lists.oasis-open.org,
members@lists.oasis-open.org,
oasis-charter-discuss@lists.oasis-open.org Cc:
Alex.Kritikos@softwareag.com,
arlen.nipper@cirrus-link.com,
Arlen.nipper@gmail.com, Dave Ings <
ings@ca.ibm.com>,
Diane Jordan/Raleigh/IBM@IBMUS,
hilary.tomasson@eurotech.com,
marco.carrer@eurotech.com,
Peter Niblett <
peter_niblett@uk.ibm.com>,
Prasad.Yendluri@softwareag.com,
raphael.cohn@stormmq.com, Scott de Deugd/Raleigh/IBM@IBMUS, Carol Geyer
<
carol.geyer@oasis-open.org>, Robin Cover <
robin.cover@oasis-open.org>
Date:
01/14/2013 11:22 AM
Subject:
Proposed Charter
for MQTT TC
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@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 implementations, 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@eurotech.com (Eurotech)
Marco Carrer,
marco.carrer@eurotech.com (Eurotech)
Peter Niblett,
peter_niblett@uk.ibm.com (IBM)
Scott de Deugd,
dedeugd@us.ibm.com (IBM)
Diane Jordan,
drj@us.ibm.com (IBM)
Arlen Nipper,
arlen.nipper@cirrus-link.com (Individual/Associate)
Alex Kritikos,
Alex.Kritikos@softwareag.com (SoftwareAG)
Prasad Yendluri,
Prasad.Yendluri@softwareag.com (Software AG)
Raphael Cohn,
raphael.cohn@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@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@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@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