[OASIS Issue Tracker] (MQTT-197) Support request/reply as a new MEP

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63437#comment-63437 ] 

Ken Borgendale commented on MQTT-197:
-------------------------------------

As we try to move to the next step in this, we have general agreement that we will add two Identifier/Value pairs on PUBLISH
- A ReplyTopic which is a string which must be a valid MQTT topic name
- A CorrelationID which we have proposed to be a 4 byte integer 
A server receiving a PUBLISH with one of these must pass it on when the message is forwarded to a client at MQTTv5.  Is there any other normative text we need about these values?

Is a 4 byte integer an acceptable type for the Correlation ID?

There is also a desire for a way of configuring the ReplyTopic based on information from the server.  I think this is an inappropriate thing to put into the protocol.  Today to configure the client to correctly communicate with a server, you need to know a number of items:
- The address of the server (and perhaps how to look this up)
- The ClientID of the client
- The security required (TLS, client cert, truststore, etc)
- The authentication required (username, password, etc)

If you can configure all of that it seems like a small addition to configure how to determine a set of client specific reply topics.  It is quite possible that a server does not know this information and there is no good way of telling the client what the rules are for creating a valid topic which will be authorized.  The server for instance may have a way to validate that a particular topic is valid but have no rule to generate a set of valid topics.  This is really similar to asking the server to give the client a username which is knows is valid for that client, and might well be considered a security exposure.

> Support request/reply as a new MEP 
> -----------------------------------
>
>                 Key: MQTT-197
>                 URL: https://issues.oasis-open.org/browse/MQTT-197
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: candidateCN, ReqRespMEP
>    Affects Versions: 5
>            Reporter: Shawn McAllister
>            Assignee: Shawn McAllister
>
> This JIRA requests that the version of the MQTT protocol after 3.1.1 be augmented to support the request/reply message exchange pattern.  Minimally what is required is the ability to (optionally) carry a "reply-to" topic in a published "request" message that would allow the receiver to publish a "reply" message addressed to the contained reply-to topic.
> Hopefully the need to support request/reply is not in dispute as it is a very common message exchange pattern supported by HTTP, JMS and all major messaging products because of its usefulness and for which there are many applications in M2M use cases.
> The only way now with MQTT3.1.1 (that I am aware of)  to return a reply to the sender of a request message is for the requester and replier to coordinate on the reply-to address outside of any specific services provided by MQTT.  For example, by embedding the reply-to address in the payload of the message.   The main functional reason this is insufficient is that it does not allow protocol interworking functions(MQTT to some other messaging protocol)  that are not (and should not be) aware of application payloads to create an end-to-end request/reply flow.
> Therefore I would like to request that the TC consider and implement the protocol changes required to support this functionality.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)