OASIS MQTT Technical Committee kicked off

434 views
Skip to first unread message

Richard J Coppen

unread,
Apr 4, 2013, 5:21:09 AM4/4/13
to mq...@googlegroups.com
Hi all,

The kick off meeting of the OASIS MQTT Technical Committee (TC) was hosted in Boston (US) last week.
Raphael Cohn (stormmq) and myself Richard Coppen (IBM) were appointed as co-chairs, alongside Geoff Brown (m2mi) as secretary.

Exciting times!
We have a well defined charter in place > https://www.oasis-open.org/committees/mqtt/charter.php < and aim to convert the input specification (MQTT v3.1) into a working draft in due course.

If you're interested in the TC's progress or wish to submit a comment on its 'technical work' (e.g., draft standards), then take a look at the OASIS MQTT TC public pages > https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt <

Best regards

Richard

Richard Coppen CEng FBCS
Software Engineer
IBM United Kingdom
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Andy Piper

unread,
Apr 16, 2013, 7:11:02 AM4/16/13
to mq...@googlegroups.com, cop...@uk.ibm.com
Thanks Rich.

It looks like the OASIS MQTT TC are aiming towards a potential "MQTT v4.0" revision of the spec. Can you comment on whether this will just include the clarifications this community has curated on the mqtt.org wiki and this mailing list, or more features and extensions such as the defacto bridging feature shared by RSMB and mosquitto?

Andy

Richard J Coppen

unread,
Apr 16, 2013, 10:46:05 AM4/16/13
to Andy Piper, mq...@googlegroups.com
Hi Andy,

The TC has not yet made any decision on MQTT version numbers or names.
To get moving, the TC need a working draft in the correct OASIS format and the editors are currently working on transcribing the input spec (MQTT v3.1). Other than the format, no changes are scheduled at this point.

Version 4 is simply a "place holder" on the working draft (the field is required on the OASIS template request) and therefore subject to change as the TC will define version numbers and naming.

Many thanks

Richard

Richard Coppen CEng FBCS  IBM United Kingdom
Software Engineer  Hursley Park
WebSphere MQ  Winchester
     SO21 2JN
Phone: +44 (0)1962 817164  England
e-mail: cop...@uk.ibm.com  
blog: testingblues.com  

Tim Kellogg

unread,
Sep 14, 2013, 11:59:29 AM9/14/13
to mq...@googlegroups.com, cop...@uk.ibm.com
Hi Richard, et al,

I read through the latest draft and it looks like it will be addressing security concerns. This is great, I think there's a lot more we could do in that area.

Aside from security, a pain I constantly experience with MQTT is that it's very hard to give a new user a good experience when things go wrong. For instance, what if my server requires subscribers to be authenticated to subscribe to `com.example/foo/bar`. From my understanding of the MQTT spec, there's no way to inform an unauthenticated user that they need to log in to subscribe to that topic. It seems that errors are communicated by silence - if you don't get a PUBACK, then **something** went wrong. As an MQTT server developer, I feel terrible when my users can't figure out what went wrong on their own.

I would be grateful if the new MQTT spec contained better error reporting. Error codes would go a long way - but are relatively inflexible. What would be very useful would be a flag indicating success/failure with an optional payload for *ACK messages. The payload would be used for longer error messages. I would hope that we could accomplish this without breaking existing clients and servers.

Thanks for listening. My hope is that this feature could be specified in a way that existing clients and servers would require minimal changes. Do you think this could be fit into the pending draft?

Regards,
Tim

Nicholas O'Leary

unread,
Sep 14, 2013, 3:04:37 PM9/14/13
to mq...@googlegroups.com
Hi Tim,

the OASIS charter [1] we are working under for the first version prohibits us from making changes to the protocol (except the CONNECT packet), other than for editorial/clarification work. This is in part to minimise the impact on existing implementations. The idea of having negative acknowledgement is widely recognised as a needed feature, but is out of scope for the first version.

The security section we're adding helps to highlight some of the issues that need to be considered to build a properly secure system. It is not meant to be a comprehensive guide on the subject, but gives an implementer a point in the right direction. Again, it does not introduce any changes to the protocol itself.

The first Committee Specification Draft should be available in the near future for public review. 

Cheers,
Nick



--
--
To learn more about MQTT please visit http://mqtt.org
 
To post to this group, send email to mq...@googlegroups.com
To unsubscribe from this group, send email to
mqtt+uns...@googlegroups.com
 
For more options, visit this group at
http://groups.google.com/group/mqtt
 
---
You received this message because you are subscribed to the Google Groups "MQ Telemetry Transport" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Geoff Brown

unread,
Sep 14, 2013, 3:54:47 PM9/14/13
to mq...@googlegroups.com, mq...@googlegroups.com, cop...@uk.ibm.com
Hi Tim,

I appreciate your interest and your suggestions. We recently finalized the security section for the core specification. However we the security subcommittee is now moving on to address a series of supplemental security areas, which will be on a par level.

As Chair of the Security subcommittee I personally extend you an invitation to join the group and/or have your input in the mix.

Thanks and all the best,

Geoff Brown
CEO & Founder

Machine-To-Machine Intelligence (M2Mi) Corporation
NASA Research Park
Building 19, #2063
Moffett Field, CA 94035

M2M Intelligence®


Legal : This message contains information that is CONFIDENTIAL and legally exempt from disclosure and that is intended only for the addressee of this message. If you  are not the addressee or a person responsible for delivering this message to the addressee, then please do not deliver this message to anyone and delete all copies. Thank you.
--

Tim Kellogg

unread,
Sep 15, 2013, 5:06:03 PM9/15/13
to Geoff Brown, mq...@googlegroups.com, mq...@googlegroups.com, cop...@uk.ibm.com
hi Geoff,

I'd be glad to participate in the security subcommittee. Let me know how I can help.

tim kellogg
sr software engineer
@kellogh
You received this message because you are subscribed to a topic in the Google Groups "MQ Telemetry Transport" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mqtt/BmZDQ9K02wg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mqtt+uns...@googlegroups.com.

Richard J Coppen

unread,
Sep 16, 2013, 11:03:05 AM9/16/13
to t...@2lemetry.com, mq...@googlegroups.com
Hi Tim,

Many thanks for your email. I appreciate Nick and Geoff have already responded, just a few comments to add below.

As Nick mentioned, the MQTT Technical Committee (TC) charter restricts us from making wide-spread changes to the protocol as part of the initial standardization exercise and the addition of 'error handling' falls out of scope of for 3.1.1.

The TC have been keen to include some security context to improve reader awareness and voted to include a security section delivered by the MQTT Security Subcommittee (SC) last week. This should become part of the next working draft, but for now can be found on the SC documents page here > https://www.oasis-open.org/committees/documents.php?wg_abbrev=mqtt-security < listed as "SecuritySectionProposal.odt".

Of course, future revisions of an OASIS MQTT standard may elect to focus on specific areas of the protocol. If you'd like to join the MQTT TC and the related MQTT Security SC, more information on OASIS membership can be found here > https://www.oasis-open.org/join <

Best regards

Richard





From:        Tim Kellogg <t...@2lemetry.com>
To:        mq...@googlegroups.com,
Cc:        Richard J Coppen/UK/IBM@IBMGB

--

--
To learn more about MQTT please visit

http://mqtt.org



To post to this group, send email to mq...@googlegroups.com
To unsubscribe from this group, send email to
mqtt+uns...@googlegroups.com

For more options, visit this group at

http://groups.google.com/group/mqtt

---
You received this message because you are subscribed to the Google Groups "MQ Telemetry Transport" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
For more options, visit
https://groups.google.com/groups/opt_out.

Reply all
Reply to author
Forward
0 new messages