OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Ken Borgendale commented on MQTT-273:
-------------------------------------

Specific comments on with line numbers from working draft 2

Line 124: Remove lines 124 and 125 and drop the concept of different classes of clients.  

Line 126: In the figure, change Device and Application to Client, and "Broker a& Interworking Function" to Server.  If it clarifies things, we can call one client Requester and the other Responder.

Line 130: Change requirement to:  Support Request/Reply between any two clients, and change text to avoid talking about client classes with just obscures the requirement

Line 142: Support asynchronous Request/Reply.  A client may achieve pseudo synchronous behavior by waiting for a response before proceeding, but in the spec all communications should be synchronous

Line 151: change to:  "Allow the server to scale well". 

 Line 155: change to "Allow any QoS at the client's discretion".  Either client can use the QoS it desired.

Line 164: Remove references to client classes and use the term Server as we do thruout the MQTT spec.  We can mention that the server might itself have complex structure.  If this is an important requirement and have implications on the design, it should be in section 2.2.1.

Line 170: The requirement here seems to be that the information about req/resp must be enough so that not only can clients respond as required, but that a server with a complex internal structure can understand enough about what is required to assist the req/resp.  For instance, stashing the information in the existing topic or body can cause problems in this regard.

Line 175: The concept of separate servers and separate protocols should be separated at a top level.  This is a different requirement.  The information about req/resp must be understood by the server so that it is able to allow req/resp to be routed to non-MQTT implementation.  Note however that this spec does not define any such interactions.



> 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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]