Re: [mqtt-comment] application layer

["Ken Borgendale" <kwb@us.ibm.com>]

The goal of MQTTv5.0 is to enhance the protocol to enable new uses while maintaining the core values and compatibility with earlier versions of MQTT. This is not a desire to define an application layer, but to enable applications by adding abilities within the transport layer. While we define properties for request/response and user properties, the spec only says how to encode these properties. The only requirements on the server for these properties is to validate that they are UTF-8 strings, and to forward them to the subscribing client. The concepts of how request/response and server redirection work is in non-normative text.

One example of the use of user properties is for enhanced routing where the single topic name is not enough information. The application could encode this in the payload, but this causes problems for complex routing between the sender and receiver, especially when the payload is encrypted. Thus the very examples you give are the ones best served by these new capabilities. Note that in almost all cases, the other protocols the application uses also have the ability to pass metadata in similar ways (properties in JMS, WMQ, and AMQP, headers in HTTP). An application which does not need this externalized data can put all of its information into the payload.

My own experience in creating both full function servers and clients, and also limited use clients, is that the added complexity is not that significant in any of these cases.

If you do not want any of these new facilities, the existing MQTTv3.1.1 is likely to continue to be supported. However, I believe that applications will see the value in the enhanced error handling, and in things like the ability to tag the payload with a content type, and move to MQTTv5.0.

Ken Borgendale -- kwb@us.ibm.com

<mqtt-comment@lists.oasis-open.org> wrote on 12/05/2017 10:24:52 AM:

> From: David Katz <David.Katz@bmw-carit.de>
> To: "mqtt-comment@lists.oasis-open.org" <mqtt-comment@lists.oasis-open.org>
> Date: 12/05/2017 10:25 AM
> Subject: [mqtt-comment] application layer
> Sent by: <mqtt-comment@lists.oasis-open.org>
>
> Hi all,
>  
> A number of new elements have been introduced to the protocol that address application
> layer concerns. User Property, Correlation Data and Reply Topic are examples. These
> extensions make server code more complicated, while only presenting limited use for more
> advanced deployments. As an example, while IoT devices might be connected to a server
> via MQTT, the corresponding backend application logic may potentially not receive
> messages via MQTT, but rather use some other technology such as a queuing or streaming
> solution to better run at scale. Even larger IoT-like devices such as vehicle that might
> be using MQTT as an off-board protocol are often using other protocols internally, with
> messages being transferred from internal to external protocols by a generic gateway on
> the vehicle. The corresponding backend applications will not be able to access
> information that is stored in the MQTT header without this information being copied from
> the MQTT layer into an application layer within the MQTT server (by a plugin, for
> instance). In addition, information that can be used to authenticate the original
> publisher, such as a signed message payload, cannot be applied to the header
> information, making this information a target for spoofing and other attacks.
>  
> It would be preferable to keep the transport protocol simple, and provide other
> application-layer functionality on top. Of course, these layers too can be standardised,
> but it is not clear what the benefit is from doing so within the MQTT protocol.
>  
> David Katz>  
> BMW Car IT GmbH