[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-148) 7 conformance
[ https://tools.oasis-open.org/issues/browse/MQTT-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Niblett updated MQTT-148:
-------------------------------
Proposal:
1. Add the following additional numbered conformance statements:
[MQTT-2.2.2-6].
A PUBLISH Packet MUST NOT have both QoS bits set to 1. If a Server or Client receives a PUBLISH Packet which has both QoS bits set to 1 it MUST close the Network Connection
[MQTT-3.1.2-11].
If the Will Flag is set to 0 the Will QoS and Will Retain fields in the Connect Flags MUST be set to zero and the Will Topic and Will Message fields MUST NOT be present in the payload
[MQTT-3.1.2-12].
If the Will Flag is set to 0, a Will Message MUST NOT be published when this Network Connection ends.
[MQTT-3.1.3-10]
The Will Topic MUST be a UTF-8 encoded string as defined in Section 1.5.3.
[MQTT-3.1.3-11]
The User Name MUST be a UTF-8 encoded string as defined in Section 1.5.3.
[MQTT-3.1.4-3]
If CONNECT validation is successful the Server MUST perform the processing of CleanSession MUST that is described in section 3.1.2.4
[MQTT-3.1.4-4]
If CONNECT validation is successful the Server MUST acknowledge the CONNECT Packet with a CONNACK Packet containing a zero return code
[MQTT-3.8.3-1]
The Topic Filters in a SUBSCRIBE packet payload MUST be UTF-8 encoded strings as defined in Section 1.5.3.
[MQTT-3.10.3-1]
The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 encoded strings as defined in Section 1.5.3, packed contiguously.
[MQTT-3.14.4-3]
On receipt of DISCONNECT the Server MUST discard any Will Message associated with the current connection without publishing it, as described in Section 3.1.2.5.
2. Augment the following numbered statements so they now read
[MQTT-3.1.2-4]
If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected
[MQTT-3.3.2-1]
The Topic Name MUST be present as the first field in the PUBLISH packet variable header. It MUST be a UTF-8 encoded string
[MQTT-3.3.2-3]
The Topic Name in a PUBLISH Packet sent by a Server to a subscribing Client MUST match the Subscription’s Topic Filter according to the matching process defined in Section 4.7.
3. Improve the wording of the following statements, as follows:
[MQTT-1.4.0-1]
The character data in a UTF-8 encoded string MUST be well-formed UTF-8 as defined by the Unicode specification [Unicode] and restated in RFC 3629 [RFC 3629]. In particular this data MUST NOT include encodings of code points between U+D800 and U+DFFF. If a receiver (Server or Client) receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection.
[MQTT-2.2.2-1]
Where a flag bit is marked as “Reserved” in Table 2.2 - Flag Bits, it is reserved for future use and MUST be set to the value listed in that Table.
[MQTT-3.1.2-5]
After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state
[MQTT-3.1.2-6]
If CleanSession is set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this session MUST NOT be reused in any subsequent Session
[MQTT-3.1.2-8].
If the Will Flag is set to 1 this indicates that, if the Connect request is accepted,a Will Message MUST be stored on the Server and associated with the Network Connection. The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet.
[MQTT-3.1.2-24]
If the Keep Alive value is non-zero and the Server does not receive a Control Packet from the Client within one and a half times the Keep Alive time period, it MUST disconnect the Network Connection to the Client as if the network had failed.
[MQTT-3.1.3-3]
The Client Identifier (ClientId) MUST be present and MUST be the first field in the CONNECT packet payload
[MQTT-3.2.2-2]
If none of the return codes listed in Table 3.1 are deemed applicable, then the Server MUST close the Network Connection without sending a CONNACK.
--------------------------------------------------------
Was >> Revise the conformance clauses in terms of making reference to normative sections, with appropriate exclusions for notes, examples, etc. <<
was:
Verify all RFC2119 language and validate all conformance statements are identified
Was >> Revise the conformance clauses in terms of making reference to normative sections, with appropriate exclusions for notes, examples, etc. <<
> 7 conformance
> -------------
>
> Key: MQTT-148
> URL: https://tools.oasis-open.org/issues/browse/MQTT-148
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.1
> Environment: Conformance
> Reporter: Patrick Durusau
> Priority: Critical
>
> The reference to MUST level requirements is insufficient as conformance clauses.
> To illustrate: for both client and server, summarizing:
> 1. Follow syntax in chaps 2 and 3
> 2. MUST level for Chapter 3
> OK, so where does:
> 3.1 "A Client can only flow the CONNECT Packet once over a Network Connection."
> 3.1.2.4 "If set to 0, the Server resumes communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server creates a new Session. "
> 3.1.2.10, "The Keep Alive is a time interval measured in seconds. Expressed as a 16-bit word, it is the maximum time interval that is permitted to elapse between two successive Control Packets sent by the Client."
> 3.1.2.10, "If a Client does not receive a PINGRESP Packet within a reasonable amount of time after it has sent a PINGREQ, it SHOULD close the Network Connection to the Server...."
> 3.1.3.1 "The Server MAY restrict the ClientId it allows in terms of their lengths and the characters they contain" (Note the ",." typo at the end of this sentence.)
> I won't go all the way through three but you get the idea.
> The conformance clauses as written, are leaving a lot of normative behavior unspecified for "conforming" applications. I could depart from any of these statements and still be a conforming server/client under MQTT. I don't think that is what you intended.
--
This message was sent by Atlassian JIRA
(v6.1.1#6155)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]