[OASIS Issue Tracker] (MQTT-519) Conformance - MUST statements

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

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

Ken Borgendale commented on MQTT-519:
-------------------------------------

This spec has three levels of text: mandatory statements, normative text, and non-normative text.  We have tried to clearly delineate these.  In a number of cases there is amount of normative text which then includes some mandatory statements saying you must implement this normative text.  Thus if you conform to the mandatory statements the implementation will be conforming, but to do so you need to read the rest of the normative text.

The conformance clause on networks is in section 7.1.1 (server)and section 7.1.2 (client).  MQTT generally describes only a single functional layer.  To achieve interoperability the client and server need to interchange at other layers as well. For instance, while we discuss the requirement for ordered and reliable network, you also need a common physical path to send data between client and server.  We do not deal with this in the spec.

In the case of QoS, A server must implement all of them, or declare that it does not support QoS 2, or QoS 1 and QoS 2.  If the server declares that it does not support these, there are mandatory statements saying that it must give an error to any client which uses then.  Thus again the mandatory statements cover conformance in either case.

> Conformance - MUST statements
> -----------------------------
>
>                 Key: MQTT-519
>                 URL: https://issues.oasis-open.org/browse/MQTT-519
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: edits
>    Affects Versions: 5, CSD01
>            Reporter: Ken Borgendale
>            Priority: Critical
>              Labels: TAB
>
> TAB-2569 - Patrick Durusau
> Hopefully I won't be stepping too hard on Jacques toes if I venture a comment on the conformance clauses. ;-) 
> I'm concerned with the language: 
> "It satisfies the MUST level requirements in the following chapters that are identified except for those that only apply to the Client:" (or Server for the other clause) 
> There are normative requirements in MQTT which are NOT announced with MUST language. 
> For example, reading 4.2 Network Connections, I find a conforming use of the MQTT protocol has this requirement: 
> ***** 
> The MQTT protocol requires an underlying transport that provides an ordered, lossless, stream of bytes from the Client to Server and Server to Client. 
> ***** 
> If my MQTT implementation does not provide "an ordered, lossless, stream of bytes from the Client to Server and Server to Client," then I would argue it does not conform to MQTT. 
> Yes? 
> That is conformance is more than just following all the MUST statements in a specification but also the descriptions that give those MUST statements context and meaning. 
> BTW, the following statement at that section: "Connectionless network transports such as User Datagram Protocol (UDP) are not suitable on their own because they might lose or reorder data." is an observation about UDP and thus should be a Comment. Yes? 
> ***** 
> Another example of normative requirements without MUST statements. Take 4.3 Quality of Service levels and protocol flows. 
> ***** 
> MQTT delivers Application Messages according to the Quality of Service (QoS) levels defined in the following sections. The delivery protocol is symmetric, in the description below the Client and Server can each take the role of either sender or receiver. The delivery protocol is concerned solely with the delivery of an application message from a single sender to a single receiver. When the Server is delivering an Application Message to more than one Client, each Client is treated independently. The QoS level used to deliver an Application Message outbound to the Client could differ from that of the inbound Application Message. 
> ***** 
> There is no MUST statement (nor should there be) but it is clear that any use of MQTT has to choose (normative) between 4.3.1 or 4.3.2 or 4.3.3 and the following sections. It is NOT permitted to vary from those and still claim conformance. 
> My point being that while it is tempting to say, conformance is all MUST statements, that only tells part of the story written in the text. All normative text, where applicable, contributes to the requirements for conformance. 
> It will make the conformance clauses a bit longer but if you say a conforming client, for example, 
> "conforms to one or more of the Quality of Service levels, 4.3 Quality of Service levels and protocol flows" 
> then you have alerted implementers that they must implement and test for the conditions specified there, even though there is no MUST statement concerning that choice.



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