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-519) Conformance - MUST statements

Ken Borgendale created MQTT-519:

             Summary: 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

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. 


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

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