[OASIS Issue Tracker] (MQTT-273) Comments on request / reply TC note

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

Ken Borgendale created MQTT-273:
-----------------------------------

             Summary: Comments on request / reply TC note
                 Key: MQTT-273
                 URL: https://issues.oasis-open.org/browse/MQTT-273
             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
          Issue Type: Improvement
          Components: ReqRespMEP
            Reporter: Ken Borgendale
            Priority: Minor


1. The Motivation section (2.1) starts out by defining two classes of clients (A and D).  While there are any number of client classes out there, we have in the past tried to avoid architecture which differed by client class.  In fact the section mostly goes on to then say that both classes have similar requirements.  In fact the request response might be from A to A, or from the yet undefined client classes P and Q.  We should avoid making distinctions about client class except when we really need to, even in non-normative text.  

2. Requirment 5.  " all state to perform the request reply and any correlation must be maintained at the endpoints".  Much as I would like to make sure that the server be stateless (as the designer of a server), It is often even a bigger problem to force clients to have state.  The state that MQTT already requires of clients is quite a significant problem.  I think we must go back to the original point of the requirement, which is that the solution scale well.

3. Requirement 7.  This requirement discusses the internal parts of a server which again is to be avoided.  We are far better to describe the conversation as between a requesting client and a responding client without any statement of the organization of the server.  Whatever the server must do as part of this should be independent of the organization of the server.

MQTT along with most other protocol is silent on the issue of how its constructs are routed to other protocols.  It is a bit of a slippery slope to go down that road.  I understand that the requirement is that the server must be able to understand enough about the request and response to route it both to other MQTT servers, and to other protocols.  We must be clear that we are walking a fine line here 




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