Specification URIs

This version:

https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.docx (Authoritative)

https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html

https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.pdf

Previous version:

http://docs.oasis-open.org/mqtt/mqtt/v5.0/cos01/mqtt-v5.0-cos01.docx (Authoritative)

http://docs.oasis-open.org/mqtt/mqtt/v5.0/cos01/mqtt-v5.0-cos01.html

http://docs.oasis-open.org/mqtt/mqtt/v5.0/cos01/mqtt-v5.0-cos01.pdf

Latest version:

https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.docx (Authoritative)

https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.pdf

Technical Committee:

OASIS Message QueuingTelemetry Transport (MQTT) TC

Chairs:

Richard Coppen (coppen@uk.ibm.com),IBM

Editors:

Andrew Banks (andrew_banks@uk.ibm.com),IBM

Ed Briggs (edbriggs@microsoft.com),Microsoft

Ken Borgendale (kwb@us.ibm.com),IBM

Rahul Gupta (rahul.gupta@us.ibm.com),IBM

Related work:

This specification replaces or supersedes:

·        MQTT Version 3.1.1. Edited by Andrew Banks and RahulGupta. 29 October 2014. OASIS Standard.http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html.Latest version:http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html.

This specification is related to:

·        MQTT and the NIST Cybersecurity Framework Version 1.0.Edited by Geoff Brown and Louis-Philippe Lamoureux.Latestversion:http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html.

Abstract:

MQTT is a Client Server publish/subscribe messaging transportprotocol. It is light weight, open, simple, and designed to be easy toimplement. These characteristics make it ideal for use in many situations,including constrained environments such as for communication in Machine toMachine (M2M) and Internet of Things (IoT) contexts where a small codefootprint is required and/or network bandwidth is at a premium.

The protocol runs over TCP/IP, or over other networkprotocols that provide ordered, lossless, bi-directional connections. Itsfeatures include:

·        Use of the publish/subscribe message pattern which providesone-to-many message distribution and decoupling of applications.

·        A messaging transport that is agnostic to the content of thepayload.

·        Three qualities of service for message delivery:

o   "At most once", where messages are delivered accordingto the best efforts of the operating environment. Message loss can occur. Thislevel could be used, for example, with ambient sensor data where it does notmatter if an individual reading is lost as the next one will be published soonafter.

o   "At least once", where messages are assured to arrivebut duplicates can occur.

o   "Exactly once", where messages are assured to arriveexactly once. This level could be used, for example, with billing systems whereduplicate or lost messages could lead to incorrect charges being applied.

·        A small transport overhead and protocol exchanges minimized toreduce network traffic.

·        A mechanism to notify interested parties when an abnormal disconnectionoccurs.

Status:

This document was last revised or approved by the membershipof OASIS on the above date. The level of approval is also listed above. Checkthe “Latest version” location noted above for possible later revisions of thisdocument. Any other numbered Versions and other technical work produced by theTechnical Committee (TC) are listed athttps://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt#technical.

TC members should send comments on this document to the TC’semail list. Others should send comments to the TC’s public comment list, aftersubscribing to it by following the instructions at the “SendA Comment” button on the TC’s web page athttps://www.oasis-open.org/committees/mqtt/.

This specification is provided under theNon-AssertionMode of theOASISIPR Policy, the mode chosen when the Technical Committee was established. Forinformation on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms,please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/mqtt/ipr.php).

Note that any machine-readable content (ComputerLanguage Definitions) declared Normative for this Work Product is providedin separate plain text files. In the event of a discrepancy between any suchplain text file and display content in the Work Product's prose narrative document(s),the content in the separate plain text file prevails.

Citation format:

When referencing this specification the following citationformat should be used:

[mqtt-v5.0]

MQTT Version 5.0. Edited by AndrewBanks, Ed Briggs, Ken Borgendale, and Rahul Gupta. 07 March 2019. OASISStandard.https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html.Latest version:https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html.

Copyright © OASIS Open 2019. All Rights Reserved.

All capitalized terms in the following text have themeanings assigned to them in the OASIS Intellectual Property Rights Policy (the"OASIS IPR Policy"). The fullPolicy may befound at the OASIS website.

This document and translations of it may be copied andfurnished to others, and derivative works that comment on or otherwise explainit or assist in its implementation may be prepared, copied, published, anddistributed, in whole or in part, without restriction of any kind, providedthat the above copyright notice and this section are included on all such copiesand derivative works. However, this document itself may not be modified in anyway, including by removing the copyright notice or references to OASIS, exceptas needed for the purpose of developing any document or deliverable produced byan OASIS Technical Committee (in which case the rules applicable to copyrights,as set forth in the OASIS IPR Policy, must be followed) or as required totranslate it into languages other than English.

The limited permissions granted above are perpetual and willnot be revoked by OASIS or its successors or assigns.

This document and the information contained herein isprovided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party thatbelieves it has patent claims that would necessarily be infringed byimplementations of this OASIS Committee Specification or OASIS Standard, tonotify OASIS TC Administrator and provide an indication of its willingness togrant patent licenses to such patent claims in a manner consistent with the IPRMode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TCAdministrator if it is aware of a claim of ownership of any patent claims thatwould necessarily be infringed by implementations of this specification by apatent holder that is not willing to provide a license to such patent claims ina manner consistent with the IPR Mode of the OASIS Technical Committee thatproduced this specification. OASIS may include such claims on its website, butdisclaims any obligation to do so.

OASIS takes no position regarding the validity or scope ofany intellectual property or other rights that might be claimed to pertain tothe implementation or use of the technology described in this document or theextent to which any license under such rights might or might not be available;neither does it represent that it has made any effort to identify any suchrights. Information on OASIS' procedures with respect to rights in any documentor deliverable produced by an OASIS Technical Committee can be found on theOASIS website. Copies of claims of rights made available for publication andany assurances of licenses to be made available, or the result of an attemptmade to obtain a general license or permission for the use of such proprietaryrights by implementers or users of this OASIS Committee Specification or OASISStandard, can be obtained from the OASIS TC Administrator. OASIS makes norepresentation that any information or list of intellectual property rightswill at any time be complete, or that any claims in such list are, in fact,Essential Claims.

The name "OASIS" is a trademark ofOASIS, the owner and developer of thisspecification, and should be used only to refer to the organization and itsofficial outputs. OASIS welcomes reference to, and implementation and use of,specifications, while reserving the right to enforce its marks against misleadinguses. Please seehttps://www.oasis-open.org/policies-guidelines/trademarkfor above guidance.

1       Introduction.11

1.0Intellectual property rights policy.11

1.1Organization of the MQTT specification.11

1.2Terminology.11

1.3 Normativereferences.13

1.4Non-normative references.13

1.5 Datarepresentation.16

1.5.1 Bits.16

1.5.2 Two ByteInteger16

1.5.3 FourByte Integer16

1.5.4 UTF-8Encoded String.16

1.5.5 VariableByte Integer18

1.5.6 BinaryData.19

1.5.7 UTF-8String Pair19

1.6 Security.19

1.7 Editingconvention.20

1.8 Changehistory.20

1.8.1 MQTTv3.1.1.20

1.8.2 MQTTv5.0.20

2       MQTTControl Packet format21

2.1 Structureof an MQTT Control Packet21

2.1.1 FixedHeader21

2.1.2 MQTTControl Packet type.21

2.1.3 Flags.22

2.1.4Remaining Length.23

2.2 VariableHeader23

2.2.1 PacketIdentifier23

2.2.2Properties.25

2.2.2.1Property Length.25

2.2.2.2Property.25

2.3 Payload.26

2.4 ReasonCode.27

3       MQTTControl Packets.30

3.1 CONNECT –Connection Request30

3.1.1 CONNECTFixed Header30

3.1.2 CONNECTVariable Header30

3.1.2.1Protocol Name.30

3.1.2.2Protocol Version.31

3.1.2.3Connect Flags.31

3.1.2.4 CleanStart32

3.1.2.5 WillFlag.32

3.1.2.6 WillQoS..33

3.1.2.7 WillRetain.33

3.1.2.8 UserName Flag.33

3.1.2.9Password Flag.33

3.1.2.10 KeepAlive.34

3.1.2.11CONNECT Properties.34

3.1.2.11.1Property Length.34

3.1.2.11.2 Session Expiry Interval35

3.1.2.11.3Receive Maximum...36

3.1.2.11.4Maximum Packet Size.36

3.1.2.11.5Topic Alias Maximum...37

3.1.2.11.6Request Response Information.37

3.1.2.11.7Request Problem Information.37

3.1.2.11.8User Property.38

3.1.2.11.9Authentication Method.38

3.1.2.11.10Authentication Data.38

3.1.2.12Variable Header non-normative example.39

3.1.3 CONNECTPayload.40

3.1.3.1 ClientIdentifier (ClientID)40

3.1.3.2 WillProperties.40

3.1.3.2.1Property Length.40

3.1.3.2.2 WillDelay Interval41

3.1.3.2.3Payload Format Indicator41

3.1.3.2.4Message Expiry Interval41

3.1.3.2.5Content Type.42

3.1.3.2.6Response Topic.42

3.1.3.2.7Correlation Data.42

3.1.3.2.8 UserProperty.42

3.1.3.3 WillTopic.42

3.1.3.4 WillPayload.43

3.1.3.5 UserName.43

3.1.3.6Password.43

3.1.4 CONNECTActions.43

3.2 CONNACK –Connect acknowledgement44

3.2.1 CONNACKFixed Header45

3.2.2 CONNACKVariable Header45

3.2.2.1Connect Acknowledge Flags.45

3.2.2.1.1Session Present45

3.2.2.2Connect Reason Code.46

3.2.2.3CONNACK Properties.47

3.2.2.3.1Property Length.47

3.2.2.3.2 Session Expiry Interval47

3.2.2.3.3Receive Maximum...48

3.2.2.3.4Maximum QoS..48

3.2.2.3.5Retain Available.49

3.2.2.3.6Maximum Packet Size.49

3.2.2.3.7Assigned Client Identifier49

3.2.2.3.8Topic Alias Maximum...50

3.2.2.3.9Reason String.50

3.2.2.3.10User Property.50

3.2.2.3.11Wildcard Subscription Available.50

3.2.2.3.12Subscription Identifiers Available.51

3.2.2.3.13Shared Subscription Available.51

3.2.2.3.14Server Keep Alive.51

3.2.2.3.15Response Information.52

3.2.2.3.16Server Reference.52

3.2.2.3.17Authentication Method.52

3.2.2.3.18Authentication Data.52

3.2.3 CONNACKPayload.53

3.3 PUBLISH –Publish message.53

3.3.1 PUBLISHFixed Header53

3.3.1.1 DUP..53

3.3.1.2 QoS..54

3.3.1.3 RETAIN..54

3.3.1.4Remaining Length.55

3.3.2 PUBLISHVariable Header55

3.3.2.1 TopicName.55

3.3.2.2 PacketIdentifier56

3.3.2.3PUBLISH Properties.56

3.3.2.3.1Property Length.56

3.3.2.3.2Payload Format Indicator56

3.3.2.3.3Message Expiry Interval`56

3.3.2.3.4Topic Alias.57

3.3.2.3.5Response Topic.58

3.3.2.3.6Correlation Data.58

3.3.2.3.7 UserProperty.58

3.3.2.3.8Subscription Identifier59

3.3.2.3.9Content Type.59

3.3.3 PUBLISHPayload.60

3.3.4 PUBLISHActions.60

3.4 PUBACK –Publish acknowledgement62

3.4.1 PUBACKFixed Header63

3.4.2 PUBACKVariable Header63

3.4.2.1 PUBACKReason Code.63

3.4.2.2 PUBACKProperties.64

3.4.2.2.1Property Length.64

3.4.2.2.2Reason String.64

3.4.2.2.3 UserProperty.64

3.4.3 PUBACKPayload.65

3.4.4 PUBACKActions.65

3.5 PUBREC –Publish received (QoS 2 delivery part 1)65

3.5.1 PUBRECFixed Header65

3.5.2 PUBRECVariable Header65

3.5.2.1 PUBRECReason Code.65

3.5.2.2 PUBRECProperties.66

3.5.2.2.1Property Length.66

3.5.2.2.2Reason String.66

3.5.2.2.3 UserProperty.67

3.5.3 PUBRECPayload.67

3.5.4 PUBRECActions.67

3.6 PUBREL –Publish release (QoS 2 delivery part 2)67

3.6.1 PUBRELFixed Header67

3.6.2 PUBRELVariable Header67

3.6.2.1 PUBRELReason Code.68

3.6.2.2 PUBRELProperties.68

3.6.2.2.1Property Length.68

3.6.2.2.2Reason String.68

3.6.2.2.3 UserProperty.69

3.6.3 PUBRELPayload.69

3.6.4 PUBRELActions.69

3.7 PUBCOMP –Publish complete (QoS 2 delivery part 3)69

3.7.1 PUBCOMPFixed Header69

3.7.2 PUBCOMPVariable Header69

3.7.2.1PUBCOMP Reason Code.70

3.7.2.2PUBCOMP Properties.70

3.7.2.2.1Property Length.70

3.7.2.2.2Reason String.70

3.7.2.2.3 UserProperty.70

3.7.3 PUBCOMPPayload.71

3.7.4 PUBCOMPActions.71

3.8 SUBSCRIBE- Subscribe request71

3.8.1SUBSCRIBE Fixed Header71

3.8.2SUBSCRIBE Variable Header71

3.8.2.1SUBSCRIBE Properties.72

3.8.2.1.1Property Length.72

3.8.2.1.2Subscription Identifier72

3.8.2.1.3 UserProperty.72

3.8.3SUBSCRIBE Payload.72

3.8.3.1Subscription Options.73

3.8.4 SUBSCRIBEActions.75

3.9 SUBACK –Subscribe acknowledgement77

3.9.1 SUBACKFixed Header77

3.9.2 SUBACKVariable Header77

3.9.2.1 SUBACKProperties.77

3.9.2.1.1Property Length.77

3.9.2.1.2Reason String.78

3.9.2.1.3 UserProperty.78

3.9.3 SUBACKPayload.78

3.10UNSUBSCRIBE – Unsubscribe request79

3.10.1UNSUBSCRIBE Fixed Header79

3.10.2UNSUBSCRIBE Variable Header80

3.10.2.1UNSUBSCRIBE Properties.80

3.10.2.1.1Property Length.80

3.10.2.1.2User Property.80

3.10.3UNSUBSCRIBE Payload.80

3.10.4UNSUBSCRIBE Actions.81

3.11 UNSUBACK– Unsubscribe acknowledgement81

3.11.1UNSUBACK Fixed Header82

3.11.2UNSUBACK Variable Header82

3.11.2.1UNSUBACK Properties.82

3.11.2.1.1Property Length.82

3.11.2.1.2Reason String.82

3.11.2.1.3User Property.83

3.11.3UNSUBACK Payload.83

3.12 PINGREQ –PING request83

3.12.1 PINGREQFixed Header84

3.12.2 PINGREQVariable Header84

3.12.3 PINGREQPayload.84

3.12.4 PINGREQActions.84

3.13 PINGRESP– PING response.84

3.13.1PINGRESP Fixed Header84

3.13.2PINGRESP Variable Header85

3.13.3PINGRESP Payload.85

3.13.4PINGRESP Actions.85

3.14DISCONNECT – Disconnect notification.85

3.14.1DISCONNECT Fixed Header85

3.14.2DISCONNECT Variable Header85

3.14.2.1Disconnect Reason Code.86

3.14.2.2DISCONNECT Properties.88

3.14.2.2.1Property Length.88

3.14.2.2.2Session Expiry Interval88

3.14.2.2.3Reason String.88

3.14.2.2.4User Property.88

3.14.2.2.5Server Reference.88

3.14.3 DISCONNECTPayload.89

3.14.4DISCONNECT Actions.89

3.15 AUTH –Authentication exchange.89

3.15.1 AUTHFixed Header90

3.15.2 AUTHVariable Header90

3.15.2.1Authenticate Reason Code.90

3.15.2.2 AUTHProperties.90

3.15.2.2.1Property Length.90

3.15.2.2.2Authentication Method.91

3.15.2.2.3Authentication Data.91

3.15.2.2.4Reason String.91

3.15.2.2.5User Property.91

3.15.3 AUTHPayload.91

3.15.4 AUTHActions.91

4       Operationalbehavior92

4.1 SessionState.92

4.1.1 StoringSession State.92

4.1.2 SessionState non-normative examples.93

4.2 NetworkConnections.93

4.3 Quality ofService levels and protocol flows.93

4.3.1 QoS 0:At most once delivery.94

4.3.2 QoS 1:At least once delivery.94

4.3.3 QoS 2:Exactly once delivery.95

4.4 Messagedelivery retry.96

4.5 Messagereceipt97

4.6 Messageordering.97

4.7 TopicNames and Topic Filters.98

4.7.1 Topicwildcards.98

4.7.1.1 Topiclevel separator98

4.7.1.2Multi-level wildcard.98

4.7.1.3Single-level wildcard.99

4.7.2 Topicsbeginning with $.99

4.7.3 Topicsemantic and usage.100

4.8Subscriptions.101

4.8.1 Non‑sharedSubscriptions.101

4.8.2 SharedSubscriptions.101

4.9 Flow Control103

4.10 Request /Response.104

4.10.1 BasicRequest Response (non-normative)104

4.10.2Determining a Response Topic value (non-normative)105

4.11 Serverredirection.106

4.12 Enhancedauthentication.106

4.12.1Re-authentication.108

4.13 Handlingerrors.109

4.13.1Malformed Packet and Protocol Errors.109

4.13.2 Othererrors.110

5       Security(non-normative)111

5.1Introduction.111

5.2 MQTTsolutions: security and certification.111

5.3Lightweight crytography and constrained devices.112

5.4Implementation notes.112

5.4.1Authentication of Clients by the Server112

5.4.2Authorization of Clients by the Server112

5.4.3Authentication of the Server by the Client113

5.4.4Integrity of Application Messages and MQTT Control Packets.113

5.4.5 Privacyof Application Messages and MQTT Control Packets.113

5.4.6Non-repudiation of message transmission.114

5.4.7Detecting compromise of Clients and Servers.114

5.4.8Detecting abnormal behaviors.114

5.4.9 Handlingof Disallowed Unicode code points.115

5.4.9.1Considerations for the use of Disallowed Unicode code points.115

5.4.9.2Interactions between Publishers and Subscribers.115

5.4.9.3Remedies.116

5.4.10 Othersecurity considerations.116

5.4.11 Use ofSOCKS.116

5.4.12Security profiles.117

5.4.12.1 Clearcommunication profile.117

5.4.12.2Secured network communication profile.117

5.4.12.3Secured transport profile.117

5.4.12.4Industry specific security profiles.117

6       UsingWebSocket as a network transport118

6.1 IANAconsiderations.118

7       Conformance.119

7.1Conformance clauses.119

7.1.1 MQTTServer conformance clause.119

7.1.2 MQTTClient conformance clause.119

Appendix A.Acknowledgments.120

Appendix B.Mandatory normative statement (non-normative)121

Appendix C.Summary of new features in MQTT v5.0 (non-normative)136

1.0 Intellectual propertyrights policy

This specification is provided under theNon-AssertionMode of theOASISIPR Policy, the mode chosen when the Technical Committee was established. Forinformation on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms,please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/mqtt/ipr.php).

1.1 Organization of the MQTT specification

The specification is split into seven chapters:

·        Chapter 1 - Introduction

·        Chapter2 - MQTT Control Packet format

·        Chapter3 - MQTT Control Packets

·        Chapter4 - Operational behavior

·        Chapter 5 - Security

·        Chapter 6 - Using WebSocket as anetwork transport

·        Chapter 7 - Conformance Targets

1.2Terminology

The keywords "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL"in this specification are to be interpreted as described in IETF RFC 2119[RFC2119], except where they appear in text that is markedas non-normative.

NetworkConnection:

A construct provided by the underlyingtransport protocol that is being used by MQTT.

·        Itconnects the Client to the Server.

·        Itprovides the means to send an ordered, lossless, stream of bytes in bothdirections.

Refer tosection 4.2 NetworkConnection for non-normative examples.

ApplicationMessage:

The data carried by the MQTT protocol across the network forthe application. When an Application Message is transported by MQTT it containspayload data, a Quality of Service (QoS), a collection of Properties, and aTopic Name.

Client:

A program or device that uses MQTT. A Client:

·        opens the Network Connection to the Server

·        publishes Application Messages that other Clients might beinterested in.

·        subscribes to request Application Messages that it is interestedin receiving.

·        unsubscribes to remove a request for Application Messages.

·        closes the Network Connection to the Server.

Server:

A program or device that acts as an intermediary betweenClients which publish Application Messages and Clients which have madeSubscriptions. A Server:

·        accepts Network Connections from Clients.

·        accepts Application Messages published by Clients.

·        processes Subscribe and Unsubscribe requests from Clients.

·        forwards Application Messages that match Client Subscriptions.

·        closes the Network Connection from the Client.

Session:

A stateful interaction between a Client and a Server. SomeSessions last only as long as the Network Connection, others can span multipleconsecutive Network Connections between a Client and a Server.

Subscription:

A Subscription comprises a Topic Filter and a maximum QoS. ASubscription is associated with a single Session. A Session can contain morethan one Subscription. Each Subscription within a Session has a different TopicFilter.

Shared Subscription:

A Shared Subscription comprises a Topic Filter and a maximumQoS. A Shared Subscription can be associated with more than one Session toallow a wider range of message exchange patterns. An Application Message thatmatches a Shared Subscription is only sent to the Client associated with one ofthese Sessions. A Session can subscribe to more than one Shared Subscriptionand can contain both Shared Subscriptions and Subscriptions which are notshared.

Wildcard Subscription:

A Wildcard Subscription is a Subscription with a TopicFilter containing one or more wildcard characters. This allows the subscriptionto match more than one Topic Name. Refer tosection4.7 for a description of wildcard characters in a Topic Filter.

Topic Name:

The label attached to an Application Message which ismatched against the Subscriptions known to the Server.

Topic Filter:

An expression contained in a Subscription to indicate aninterest in one or more topics. A Topic Filter can include wildcard characters.

MQTT Control Packet:

A packet of information that is sent across the NetworkConnection. The MQTT specification defines fifteen different types of MQTT ControlPacket, for example the PUBLISH packet is used to convey Application Messages.

Malformed Packet:

A control packet that cannot be parsed according to thisspecification. Refer tosection 4.13 forinformation about error handling.

Protocol Error:

An error that is detected after the packet has been parsedand found to contain data that is not allowed by the protocol or isinconsistent with the state of the Client or Server. Refer tosection 4.13 for information about error handling.

Will Message:

An Application Message which is published by the Serverafter the Network Connection is closed in cases where the Network Connection isnot closed normally. Refer tosection 3.1.2.5 forinformation about Will Messages.

Disallowed Unicode code point:

The set of Unicode Control Codes and Unicode Noncharacterswhich should not be included in a UTF-8 Encoded String. Refer tosection 1.5.4 formore information about the Disallowed Unicode code points.

1.3 Normative references

[RFC2119]

Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,

http://www.rfc-editor.org/info/rfc2119

[RFC3629]

Yergeau, F., "UTF-8, a transformation format of ISO10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003,

http://www.rfc-editor.org/info/rfc3629

[RFC6455]

Fette, I. and A. Melnikov, "The WebSocketProtocol", RFC 6455, DOI 10.17487/RFC6455, December 2011,

http://www.rfc-editor.org/info/rfc6455

[Unicode]

The Unicode Consortium. The Unicode Standard,

http://www.unicode.org/versions/latest/

1.4 Non-normative references

[RFC0793]

Postel, J., "Transmission Control Protocol", STD7, RFC 793, DOI 10.17487/RFC0793, September 1981,http://www.rfc-editor.org/info/rfc793

[RFC5246]

Dierks, T. and E. Rescorla, "The Transport LayerSecurity (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246,August 2008,

http://www.rfc-editor.org/info/rfc5246

[AES]

Advanced Encryption Standard (AES) (FIPS PUB 197).

https://csrc.nist.gov/csrc/media/publications/fips/197/final/documents/fips-197.pdf

[CHACHA20]

ChaCha20 and Poly1305 for IETF Protocols

https://tools.ietf.org/html/rfc7539

[FIPS1402]

Security Requirements for Cryptographic Modules (FIPS PUB140-2)

https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf

[IEEE 802.1AR]

IEEE Standard for Local and metropolitan area networks -Secure Device Identity

http://standards.ieee.org/findstds/standard/802.1AR-2009.html

[ISO29192]

ISO/IEC 29192-1:2012 Information technology -- Securitytechniques -- Lightweight cryptography -- Part 1: General

https://www.iso.org/standard/56425.html

[MQTT NIST]

MQTT supplemental publication, MQTT and the NIST Frameworkfor Improving Critical Infrastructure Cybersecurity

http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html

[MQTTV311]

MQTT V3.1.1 Protocol Specification

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

[ISO20922]

MQTT V3.1.1ISO Standard (ISO/IEC 20922:2016)

https://www.iso.org/standard/69466.html

[NISTCSF]

Improving Critical Infrastructure Cybersecurity ExecutiveOrder 13636

https://www.nist.gov/sites/default/files/documents/itl/preliminary-cybersecurity-framework.pdf

[NIST7628]

NISTIR 7628 Guidelines for Smart Grid Cyber Security Catalogue

https://www.nist.gov/sites/default/files/documents/smartgrid/nistir-7628_total.pdf

[NSAB]

NSA Suite B Cryptography

http://www.nsa.gov/ia/programs/suiteb_cryptography/

[PCIDSS]

PCI-DSS Payment Card Industry Data Security Standard

https://www.pcisecuritystandards.org/pci_security/

[RFC1928]

Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L.Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928,March 1996,

http://www.rfc-editor.org/info/rfc1928

[RFC4511]

Sermersheim, J., Ed., "Lightweight Directory AccessProtocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, June 2006,

http://www.rfc-editor.org/info/rfc4511

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280,May 2008,

http://www.rfc-editor.org/info/rfc5280

[RFC6066]

Eastlake 3rd, D., "Transport Layer Security (TLS)Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066,January 2011,

http://www.rfc-editor.org/info/rfc6066

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 AuthorizationFramework", RFC 6749, DOI 10.17487/RFC6749, October 2012,

http://www.rfc-editor.org/info/rfc6749

[RFC6960]

Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin,S., and C. Adams, "X.509 Internet Public Key Infrastructure OnlineCertificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June2013,

http://www.rfc-editor.org/info/rfc6960

[SARBANES]

Sarbanes-Oxley Act of 2002.

http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm

[USEUPRIVSH]

U.S.-EU Privacy Shield Framework

https://www.privacyshield.gov

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter,"Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC3986, DOI 10.17487/RFC3986, January 2005,

http://www.rfc-editor.org/info/rfc3986

[RFC1035]

Mockapetris, P., "Domain names - implementation andspecification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987,

http://www.rfc-editor.org/info/rfc1035

[RFC2782]

Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RRfor specifying the location of services (DNS SRV)", RFC 2782, DOI10.17487/RFC2782, February 2000,

http://www.rfc-editor.org/info/rfc2782

1.5 Data representation

1.5.1 Bits

Bits in a byte are labelled 7 to 0. Bit number 7 is the mostsignificant bit, the least significant bit is assigned bit number 0.

1.5.2 Two Byte Integer

Two Byte Integer data values are 16-bit unsigned integers inbig-endian order: the high order byte precedes the lower order byte. This meansthat a 16-bit word is presented on the network as Most Significant Byte (MSB),followed by Least Significant Byte (LSB).

1.5.3 Four Byte Integer

Four Byte Integer data values are 32-bit unsigned integersin big-endian order: the high order byte precedes the successively lower orderbytes. This means that a 32-bit word is presented on the network as MostSignificant Byte (MSB), followed by the next most Significant Byte (MSB),followed by the next most Significant Byte (MSB), followed by Least SignificantByte (LSB).

1.5.4 UTF-8 Encoded String

Text fields within the MQTT Control Packets described laterare encoded as UTF-8 strings. UTF-8[RFC3629] is anefficient encoding of Unicode[Unicode] characters thatoptimizes the encoding of ASCII characters in support of text-basedcommunications.

Each of these strings is prefixed with a Two Byte Integerlength field that gives the number of bytes in a UTF-8 encoded string itself,as illustrated inFigure 1.1 Structure of UTF-8 EncodedStrings below. Consequently, the maximum size of a UTF-8 Encoded String is65,535 bytes.

Unless stated otherwise all UTF-8encoded strings can have any length in the range 0 to 65,535 bytes.

Figure1‑1 Structure of UTF-8 Encoded Strings

The character data in aUTF-8 Encoded String MUST be well-formed UTF-8 as defined by the Unicodespecification[Unicode] and restated in RFC 3629[RFC3629].In particular, the character data MUST NOT include encodings of code pointsbetween U+D800 and U+DFFF[MQTT-1.5.4-1].If the Client or Serverreceives an MQTT Control Packet containing ill-formed UTF-8 it is a MalformedPacket. Refer tosection 4.13 for information about handling errors.

A UTF-8 Encoded String MUSTNOT include an encoding of the null character U+0000.[MQTT-1.5.4-2]. If a receiver (Server or Client)receives an MQTT Control Packet containing U+0000 it is a Malformed Packet.Refer to section 4.13 for information abouthandling errors.

The data SHOULD NOT include encodings of the Unicode[Unicode] code points listed below. If a receiver (Server or Client) receives anMQTT Control Packet containing any of them it MAY treat it as a Malformed Packet.These are the Disallowed Unicode code points.Refertosection5.4.9 for more informationabout handling Disallowed Unicode code points.

·        U+0001..U+001F control characters

·        U+007F..U+009F control characters

·        Code points defined in the Unicode specification[Unicode] to be non-characters (for example U+0FFFF)

A UTF-8 encoded sequence0xEF 0xBB 0xBF is always interpreted as U+FEFF ("ZERO WIDTH NO-BREAK SPACE")wherever it appears in a string and MUST NOT be skipped over or stripped off bya packet receiver[MQTT-1.5.4-3].

Non-normative example

For example,the string A𪛔which isLATINCAPITAL Letter A followed by the code point U+2A6D4 (which represents a CJKIDEOGRAPH EXTENSION B character) is encoded as follows:

Figure1‑2 UTF-8 Encoded String non-normative example

1.5.5 Variable Byte Integer

The Variable Byte Integer is encoded using an encodingscheme which uses a single byte for values up to 127. Larger values are handledas follows. The least significant seven bits of each byte encode the data, andthe most significant bit is used to indicate whether there are bytes followingin the representation. Thus, each byte encodes 128 values and a"continuation bit". The maximum number of bytes in the Variable ByteInteger field is four.The encoded value MUSTuse the minimum number of bytes necessary to represent the value[MQTT-1.5.5-1].This isshown inTable 1‑1 Size of Variable Byte Integer.

Table1‑1Size of Variable Byte Integer

Non-normativecomment

The algorithmfor encoding a non-negative integer (X) into the Variable Byte Integer encodingscheme is as follows:

do

   encodedByte= X MOD 128

   X= X DIV 128

   //if there are more data to encode, set the top bit of this byte

   if(X > 0)

      encodedByte= encodedByte OR 128

   endif

   'output'encodedByte

while(X > 0)

WhereMOD is the modulo operator (% in C),DIV is integer division (/in C), andOR is bit-wise or (| in C).

Non-normativecomment

The algorithmfor decoding a Variable Byte Integer type is as follows:

multiplier= 1

value= 0

do

   encodedByte= 'next byte from stream'

   value+= (encodedByte AND 127) * multiplier

   if(multiplier > 128*128*128)

      throwError(Malformed Variable Byte Integer)

   multiplier*= 128

while((encodedByte AND 128) != 0)

whereAND is the bit-wise andoperator (& in C).

When this algorithm terminates,value contains the VariableByte Integer value.

1.5.6Binary Data

Binary Data is represented by a Two Byte Integer lengthwhich indicates the number of data bytes, followed by that number of bytes. Thus,the length of Binary Data is limited to the range of 0 to 65,535 Bytes.

1.5.7UTF-8 String Pair

A UTF-8 String Pair consists of two UTF-8 Encoded Strings.This data type is used to hold name-value pairs. The first string serves as thename, and the second string contains the value.

Both strings MUST complywith the requirements for UTF-8 Encoded Strings[MQTT-1.5.7-1].If a receiver (Client or Server) receives a string pair which does not meetthese requirements it is a Malformed Packet. Refer tosection4.13 for information about handling errors.

1.6 Security

MQTT Client and Serverimplementations SHOULD offer Authentication, Authorization and securecommunication options, such as those discussed in Chapter5. Applicationsconcerned with critical infrastructure, personally identifiable information, orother personal or sensitive information are strongly advised to use thesesecurity capabilities.

1.7Editing convention

Text highlighted inYellowwithin this specification identifies conformance statements. Each conformancestatement has been assigned a reference in the format[MQTT-x.x.x-y]wherex.x.xis thesection number andy is a statement counter within the section.

1.8 Change history

1.8.1 MQTT v3.1.1

MQTT v3.1.1 was the first OASIS standard version of MQTT[MQTTV311].

MQTT v3.1.1 is also standardized as ISO/IEC 20922:2016[ISO20922].

1.8.2 MQTT v5.0

MQTT v5.0 adds a significant number of new features to MQTTwhile keeping much of the core in place. The major functional objectives are:

·        Enhancements for scalability and large scale systems

·        Improved error reporting

·        Formalize common patterns including capability discovery andrequest response

·        Extensibility mechanisms including user properties

·        Performance improvements and support for small clients

Refer toAppendix C for a summaryof changes in MQTT v5.0.

2.1 Structure of an MQTTControl Packet

The MQTT protocol operates by exchanging a series of MQTTControl Packets in a defined way. This section describes the format of thesepackets.

An MQTT Control Packet consists of up to three parts, alwaysin the following order as shown below.

Figure 2‑1Structure of an MQTT Control Packet

2.1.1 Fixed Header

Each MQTT Control Packet contains a Fixed Header as shownbelow.

Figure2‑2 Fixed Header format

2.1.2 MQTT Control Packet type

Position: byte 1, bits 7-4.

Represented as a 4-bit unsigned value, the values are shownbelow.

Table 2‑1 MQTT Control Packet types

2.1.3 Flags

The remaining bits [3-0] of byte 1 in the Fixed Headercontain flags specific to each MQTT Control Packet type as shown below.Where a flag bit ismarked as “Reserved”, it is reserved for future use and MUST be set to thevalue listed[MQTT-2.1.3-1]. If invalidflags are received it is a Malformed Packet.Refer tosection 4.13 for details about handling errors.

Table2‑2 Flag Bits

DUP = Duplicate delivery of a PUBLISH packet

QoS = PUBLISH Quality of Service

RETAIN = PUBLISH retained message flag

Refer tosection 3.3.1for a description of the DUP, QoS, and RETAIN flags in the PUBLISH packet.

2.1.4 Remaining Length

Position: starts at byte2.

The Remaining Length is a Variable Byte Integer thatrepresents the number of bytes remaining within the current Control Packet,including data in the Variable Header and the Payload. The Remaining Lengthdoes not include the bytes used to encode the Remaining Length.The packet size is the total number of bytes in an MQTT ControlPacket, this is equal to the length of the Fixed Header plus the RemainingLength.

2.2 Variable Header

Some types of MQTT Control Packet contain a Variable Headercomponent. It resides between the Fixed Header and the Payload. The content ofthe Variable Header varies depending on the packet type. The Packet Identifierfield of Variable Header is common in several packet types.

2.2.1 PacketIdentifier

The Variable Header component ofmany of the MQTT Control Packet types includes a Two Byte Integer PacketIdentifier field. These MQTT Control Packets are PUBLISH (where QoS > 0),PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.

MQTT Control Packets that require a Packet Identifier are shownbelow:

Table 2‑3 MQTT Control Packets that contain a PacketIdentifier

A PUBLISH packet MUST NOTcontain a Packet Identifier if its QoS value is set to 0[MQTT-2.2.1-2].

Each time a Client sends anew SUBSCRIBE, UNSUBSCRIBE,or PUBLISH (where QoS > 0) MQTT Control Packet itMUST assign it a non-zero Packet Identifier that is currently unused[MQTT-2.2.1-3].

Each time a Server sends anew PUBLISH (with QoS > 0) MQTT Control Packet it MUST assign it a non zeroPacket Identifier that is currently unused[MQTT-2.2.1-4].

The Packet Identifier becomes available for reuse after the senderhas processed the corresponding acknowledgement packet, defined as follows. Inthe case of a QoS 1 PUBLISH, this is the corresponding PUBACK; in the case ofQoS 2 PUBLISH it is PUBCOMP or a PUBREC with a Reason Code of 128 or greater.For SUBSCRIBE or UNSUBSCRIBE it is the corresponding SUBACK or UNSUBACK.

Packet Identifiers used with PUBLISH, SUBSCRIBE andUNSUBSCRIBE packets form a single, unified set of identifiers separately forthe Client and the Server in a Session. A Packet Identifier cannot be used bymore than one command at any time.

A PUBACK, PUBREC , PUBREL,or PUBCOMP packet MUST contain the same Packet Identifier as the PUBLISH packetthat was originally sent[MQTT-2.2.1-5].A SUBACK and UNSUBACK MUST contain the PacketIdentifier that was used in the corresponding SUBSCRIBE and UNSUBSCRIBE packet respectively[MQTT-2.2.1-6].

The Client and Server assign Packet Identifiersindependently of each other. As a result, Client-Server pairs can participatein concurrent message exchanges using the same Packet Identifiers.

Non-normativecomment

It is possible for a Client to senda PUBLISH packet with Packet Identifier 0x1234 and then receive a differentPUBLISH packet with Packet Identifier 0x1234 from its Server before it receivesa PUBACK for the PUBLISH packet that it sent.

 Client                                                   Server

PUBLISH Packet Identifier=0x1234‒→

                                                     ←‒PUBLISH PacketIdentifier=0x1234

PUBACK PacketIdentifier=0x1234‒→

                                                    ←‒PUBACKPacket Identifier=0x1234

2.2.2 Properties

The last field in the Variable Header of the CONNECT, CONNACK,PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE,UNSUBACK, DISCONNECT, and AUTH packet is a set of Properties. In the CONNECTpacket there is also an optional set of Properties in the Will Properties fieldwith the Payload.

The set of Properties is composed of a Property Length followedby the Properties.

2.2.2.1 Property Length

The Property Length is encoded as a Variable Byte Integer.The Property Length does not include the bytes used to encode itself, butincludes the length of the Properties.If thereare no properties, this MUST be indicated by including a Property Length ofzero[MQTT-2.2.2-1].

2.2.2.2 Property

A Property consists of an Identifier which defines its usageand data type, followed by a value. The Identifier is encoded as a VariableByte Integer. A Control Packet which contains an Identifier which is not validfor its packet type, or contains a value not of the specified data type, is aMalformed Packet. If received, use a CONNACK or DISCONNECT packet with ReasonCode 0x81 (Malformed Packet) as described insection4.13 Handling errors. There is no significance in the order of Propertieswith different Identifiers.

Table 2‑4- Properties

Non-normative comment

Although the Property Identifier isdefined as a Variable Byte Integer, in this version of the specification all ofthe Property Identifiers are one byte long.

2.3 Payload

Some MQTT Control Packets contain a Payload as the finalpart of the packet. In the PUBLISH packet this is the Application Message

Table2‑5 - MQTT Control Packets that contain a Payload

2.4 Reason Code

A Reason Code is a one byte unsigned value that indicatesthe result of an operation. Reason Codes less than 0x80 indicate successfulcompletion of an operation. The normal Reason Code for success is 0. ReasonCode values of 0x80 or greater indicate failure.

The CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, DISCONNECT andAUTH Control Packets have a single Reason Code as part of the Variable Header.The SUBACK and UNSUBACK packets contain a list of one or more Reason Codes inthe Payload.

The Reason Codes share a common set of values as shownbelow.

Table2‑6 - Reason Codes

Non-normative comment

For Reason Code 0x91 (Packetidentifier in use), the response to this is either to try to fix the state, orto reset the Session state by connecting using Clean Start set to 1, or todecide if the Client or Server implementations are defective.

3.1 CONNECT – Connection Request

After a Network Connectionis established by a Client to a Server, the first packet sent from the Client tothe Server MUST be a CONNECT packet[MQTT-3.1.0-1].

A Client can only send the CONNECT packet once over aNetwork Connection.The Server MUST process asecond CONNECT packet sent from a Client as a Protocol Error and close theNetwork Connection[MQTT-3.1.0-2]. Refer tosection 4.13 for information about handling errors.

The Payload contains one or moreencoded fields. They specify a unique Client identifier for the Client, a Will Topic,Will Payload, User Name and Password. All but the Client identifier can beomitted and their presence is determined based on flags in the Variable Header.

3.1.1 CONNECT Fixed Header

Figure 3‑1- CONNECT packet Fixed Header

Remaining Length field

This is the length of the Variable Header plus the length ofthe Payload. It is encoded as a Variable Byte Integer.

3.1.2 CONNECT Variable Header

The Variable Header for the CONNECT Packet contains the followingfields in this order: Protocol Name, Protocol Level, Connect Flags, Keep Alive,and Properties. The rules for encoding Properties are described insection 2.2.2.

3.1.2.1 Protocol Name

Figure 3‑2- Protocol Name bytes

The Protocol Name is a UTF-8Encoded String that represents the protocol name “MQTT”, capitalized as shown.The string, its offset and length will not be changed by future versions of theMQTT specification.

A Server which support multiple protocols uses the ProtocolName to determine whether the data is MQTT.Theprotocol name MUST be the UTF-8 String "MQTT". If the Server does notwant to accept the CONNECT, and wishes to reveal that it is an MQTT Server itMAY send a CONNACK packet with Reason Code of 0x84 (Unsupported ProtocolVersion), and then it MUST close the Network Connection [MQTT-3.1.2-1].

Non-normativecomment

Packetinspectors, such as firewalls, could use the Protocol Name to identify MQTTtraffic.

3.1.2.2 Protocol Version

Figure 3‑3- Protocol Version byte

The one byte unsigned value that represents the revisionlevel of the protocol used by the Client. The value of the Protocol Versionfield for version 5.0 of the protocol is 5 (0x05).

A Server which supports multiple versions of the MQTTprotocol uses the Protocol Version to determine which version of MQTT theClient is using.If the Protocol Version is not5 and the Server does not want to accept the CONNECT packet, the Server MAYsend a CONNACK packet with ReasonCode0x84 (Unsupported Protocol Version) and then MUST close the Network Connection[MQTT-3.1.2-2].

3.1.2.3 Connect Flags

The Connect Flags byte contains several parametersspecifying the behavior of the MQTT connection. It also indicates the presenceor absence of fields in the Payload.

Figure 3‑4- Connect Flag bits

The Server MUST validatethat the reserved flag in the CONNECT packet is set to 0[MQTT-3.1.2-3]. If the reserved flag is not 0 it is aMalformed Packet. Refer tosection 4.13 forinformation about handling errors.

3.1.2.4Clean Start

Position: bit 1 of theConnect Flags byte.

This bit specifies whether the Connection starts a newSession or is a continuation of an existing Session. Refer tosection 4.1 for a definition of the Session State.

Ifa CONNECT packet is received with Clean Start is set to 1, the Client andServer MUST discard any existing Session and start a new Session[MQTT-3.1.2-4]. Consequently, the Session Present flagin CONNACK is always set to 0 if Clean Start is set to 1.

Ifa CONNECT packet is received with Clean Start set to 0 and there is a Sessionassociated with the Client Identifier, the Server MUST resume communicationswith the Client based on state from the existing Session[MQTT-3.1.2-5].If aCONNECT packet is received with Clean Start set to 0 and there is no Sessionassociated with the Client Identifier, the Server MUST create a new Session[MQTT-3.1.2-6].

3.1.2.5Will Flag

Position: bit 2 of the Connect Flags.

If the Will Flag is set to 1this indicates that a Will Message MUST be stored on the Server and associatedwith the Session[MQTT-3.1.2-7]. The WillMessage consists of the Will Properties, Will Topic, and Will Payload fields inthe CONNECT Payload.The Will Message MUST bepublished after the Network Connection is subsequently closed and either theWill Delay Interval has elapsed or the Session ends, unless the Will Messagehas been deleted by the Server on receipt of a DISCONNECT packet with ReasonCode 0x00 (Normal disconnection) or a new Network Connection for the ClientIDis opened before the Will Delay Interval has elapsed[MQTT-3.1.2-8].

Situations in which the Will Message is published include,but are not limited to:

• An I/O error or network failure detected by the Server.
• The Client fails to communicate within the Keep Alive time.
• The Client closes the Network Connection without first sending a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection).
• The Server closes the Network Connection without first receiving a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection).

If the Will Flag is set to1, the Will Properties, Will Topic, and Will Payload fields MUST be present inthe Payload[MQTT-3.1.2-9].The Will Message MUST be removed from the storedSession State in the Server once it has been published or the Server hasreceived a DISCONNECT packet with a Reason Code of 0x00 (Normal disconnection)from the Client[MQTT-3.1.2-10].

The Server SHOULD publish Will Messages promptly after theNetwork Connection is closed and the Will Delay Interval has passed, or whenthe Session ends, whichever occurs first. In the case of a Server shutdown orfailure, the Server MAY defer publication of Will Messages until a subsequentrestart. If this happens, there might be a delay between the time the Serverexperienced failure and when the Will Message is published.

Refer tosection 3.1.3.2for information about the Will Delay Interval.

Non-normative comment

The Client can arrange for the WillMessage to notify that Session Expiry has occurred by setting the Will DelayInterval to be longer than the Session Expiry Interval and sending DISCONNECTwith Reason Code 0x04 (Disconnect with Will Message).

3.1.2.6 Will QoS

Position: bits 4 and 3 of the Connect Flags.

These two bits specify the QoS level to be used whenpublishing the Will Message.

If the Will Flag is set to 0,then the Will QoS MUST be set to 0(0x00)[MQTT-3.1.2-11].

If the Will Flag is set to1, the value of Will QoS can be 0 (0x00), 1 (0x01), or 2 (0x02)[MQTT-3.1.2-12].Avalue of 3 (0x03) is a Malformed Packet.Refer tosection 4.13 for information about handling errors.

3.1.2.7 Will Retain

Position: bit 5 of the Connect Flags.

This bit specifies if the Will Message is to be retainedwhen it is published.

If the Will Flag is set to0, then Will Retain MUST be set to 0 [MQTT-3.1.2-13].If the Will Flag isset to 1 and Will Retain is set to 0, the Server MUST publish the Will Messageas a non-retained message[MQTT-3.1.2-14].If the Will Flag isset to 1 and Will Retain is set to 1, the Server MUST publish the Will Messageas a retained message[MQTT-3.1.2-15].

3.1.2.8 User Name Flag

Position: bit 7 of the Connect Flags.

If the User Name Flag is setto 0, a User Name MUST NOT be present in the Payload[MQTT-3.1.2-16].Ifthe User Name Flag is set to 1, a User Name MUST be present in the Payload[MQTT-3.1.2-17].

3.1.2.9 Password Flag

Position: bit 6 of the Connect Flags.

If the Password Flag is setto 0, a Password MUST NOT be present in the Payload[MQTT-3.1.2-18].Ifthe Password Flag is set to 1, a Password MUST be present in the Payload[MQTT-3.1.2-19].

Non-normative comment

This version of the protocol allowsthe sending of a Password with no User Name, where MQTT v3.1.1 did not. Thisreflects the common use of Password for credentials other than a password.

3.1.2.10Keep Alive

Figure 3‑5- Keep Alive bytes

The Keep Alive is a Two Byte Integer which is a timeinterval measured in seconds. It is the maximum time interval that is permittedto elapse between the point at which the Client finishes transmitting one MQTT ControlPacket and the point it starts sending the next. It is the responsibility ofthe Client to ensure that the interval between MQTT Control Packets being sentdoes not exceed the Keep Alive value.If KeepAlive is non-zero and in the absence of sending any other MQTT Control Packets,the Client MUST send a PINGREQ packet[MQTT-3.1.2-20].

If the Server returns aServer Keep Alive on the CONNACK packet, the Client MUST use that value insteadof the value it sent as the Keep Alive[MQTT-3.1.2-21].

The Client can send PINGREQ at any time, irrespective of theKeep Alive value, and check for a corresponding PINGRESP to determine that thenetwork and the Server are available.

If the Keep Alive value isnon-zero and the Server does not receive an MQTT Control Packet from the Clientwithin one and a half times the Keep Alive time period, it MUST close theNetwork Connection to the Client as if the network had failed[MQTT-3.1.2-22].

If a Client does not receive a PINGRESP packet within areasonable amount of time after it has sent a PINGREQ, it SHOULD close theNetwork Connection to the Server.

A Keep Alive value of 0 has the effect of turning off the KeepAlive mechanism. If Keep Alive is 0 the Client is not obliged to send MQTTControl Packets on any particular schedule.

Non-normative comment

The Server may have other reasonsto disconnect the Client, for instance because it is shutting down. SettingKeep Alive does not guarantee that the Client will remain connected.

Non-normativecomment

The actual value of the Keep Aliveis application specific; typically, this is a few minutes. The maximum value of65,535 is 18 hours 12 minutes and 15 seconds.

3.1.2.11 CONNECT Properties

3.1.2.11.1 Property Length

The length of the Properties in the CONNECT packet VariableHeader encoded as a Variable Byte Integer.

3.1.2.11.2Session Expiry Interval

17 (0x11) Byte, Identifier of the SessionExpiry Interval.

Followed by the Four Byte Integer representing the Session ExpiryInterval in seconds. It is a Protocol Error to include the Session Expiry Intervalmore than once.

If the Session Expiry Interval is absent the value 0 isused. If it is set to 0, or is absent, the Session ends when the Network Connectionis closed.

If the Session Expiry Interval is 0xFFFFFFFF (UINT_MAX), theSession does not expire.

The Client and Server MUSTstore the Session State after the Network Connection is closed if the SessionExpiry Interval is greater than 0[MQTT-3.1.2-23].

Non-normative comment

The clock in the Client or Servermay not be running for part of the time interval, for instance because theClient or Server are not running. This might cause the deletion of the state tobe delayed.

Refertosection 4.1 for more information about Sessions.Refer tosection 4.1.1 for details andlimitations of stored state.

When the Session expires the Clientand Server need not process the deletion of state atomically.

Non-normativecomment

Setting Clean Start to 1 and aSession Expiry Interval of 0, is equivalent to setting CleanSession to 1 in theMQTT Specification Version 3.1.1. Setting Clean Start to 0 and no SessionExpiry Interval, is equivalent to setting CleanSession to 0 in the MQTTSpecification Version 3.1.1.

Non-normativecomment

A Client that only wants to processmessages while connected will set the Clean Start to 1 and set the SessionExpiry Interval to 0. It will not receive Application Messages published beforeit connected and has to subscribe afresh to any topics that it is interested ineach time it connects.

Non-normativecomment

A Client might be connecting to a Serverusing a network that provides intermittent connectivity. This Client can use ashort Session Expiry Interval so that it can reconnect when the network isavailable again and continue reliable message delivery. If the Client does notreconnect, allowing the Session to expire, then Application Messages will belost.

Non-normative comment

When a Client connects with a longSession Expiry Interval, it is requesting that the Server maintain its MQTTsession state after it disconnects for an extended period. Clients should onlyconnect with a long Session Expiry Interval if they intend to reconnect to theServer at some later point in time. When a Client has determined that it has nofurther use for the Session it should disconnect with a Session Expiry Intervalset to 0.

Non-normative comment

The Client should always use the SessionPresent flag in the CONNACK to determine whether the Server has a Session Statefor this Client.

Non-normativecomment

The Client can avoid implementingits own Session expiry and instead rely on the Session Present flag returnedfrom the Server to determine if the Session had expired. If the Client doesimplement its own Session expiry, it needs to store the time at which the SessionState will be deleted as part of its Session State.

3.1.2.11.3Receive Maximum

33 (0x21) Byte, Identifier of the Receive Maximum.

Followed by the Two Byte Integer representing the ReceiveMaximum value. It is a Protocol Error to include the Receive Maximum value morethan once or for it to have the value 0.

The Client uses this value to limit the number of QoS 1 andQoS 2 publications that it is willing to process concurrently. There is no mechanismto limit the QoS 0 publications that the Server might try to send.

The value of Receive Maximum applies only to the currentNetwork Connection.If the Receive Maximum value isabsent then its value defaults to 65,535.

Refer tosection4.9 Flow Control for details of how the Receive Maximum is used.

3.1.2.11.4Maximum Packet Size

39 (0x27) Byte, Identifier of the Maximum Packet Size.

Followed by a Four Byte Integerrepresenting the Maximum Packet Size the Client is willing to accept. If theMaximum Packet Size is not present, no limit on the packet size is imposedbeyond the limitations in the protocol as a result of the remaining lengthencoding and the protocol header sizes.

It is a Protocol Error to include the Maximum Packet Sizemore than once, or for the value to be set to zero.

           Non-normative comment

It is theresponsibility of the application to select a suitable Maximum Packet Sizevalue if it chooses to restrict the Maximum Packet Size.

The packet size is the total number ofbytes in an MQTT Control Packet, as defined insection 2.1.4. The Client uses the Maximum Packet Size to inform the Server thatit will not process packets exceeding this limit.

The Server MUSTNOT send packets exceeding Maximum Packet Size to the Client[MQTT-3.1.2-24]. If a Clientreceives a packet whose size exceeds this limit, this is a Protocol Error, theClient uses DISCONNECT with Reason Code 0x95 (Packet too large), as describedinsection 4.13.

Where a Packet istoo large to send, the Server MUST discard it without sending it and thenbehave as if it had completed sending that Application Message[MQTT-3.1.2-25].

In the case of a Shared Subscription where themessage is too large to send to one or more of the Clients but other Clients canreceive it, the Server can choose either discard the message without sendingthe message to any of the Clients, or to send the message to one of the Clientsthat can receive it.

Non-normativecomment

Where a packet is discarded withoutbeing sent, the Server could place the discarded packet on a ‘dead letterqueue’ or perform other diagnostic action. Such actions are outside the scopeof this specification.

3.1.2.11.5Topic Alias Maximum

34 (0x22) Byte, Identifier of the Topic Alias Maximum.

Followed by the Two Byte Integer representing the TopicAlias Maximum value. It is a Protocol Error to include the Topic Alias Maximumvalue more than once. If the Topic Alias Maximum property is absent, thedefault value is 0.

This value indicates the highest value that the Client willaccept as a Topic Alias sent by the Server. The Client uses this value to limitthe number of Topic Aliases that it is willing to hold on this Connection.The Server MUST NOT send a Topic Alias in a PUBLISHpacket to the Client greater than Topic Alias Maximum[MQTT-3.1.2-26]. A value of 0 indicates that theClient does not accept any Topic Aliases on this connection.If Topic Alias Maximum is absent or zero, the ServerMUST NOT send any Topic Aliases to the Client[MQTT-3.1.2-27].

3.1.2.11.6 Request Response Information

25 (0x19) Byte, Identifier of the Request ResponseInformation.

Followed by a Byte with a value of either 0 or 1. It isProtocol Error to include the Request Response Information more than once, orto have a value other than 0 or 1. If the Request Response Information isabsent, the value of 0 is used.

The Client uses this value to request the Server to returnResponse Information in the CONNACK.A value of0 indicates that the Server MUST NOT return Response Information[MQTT-3.1.2-28]. If the value is 1 the Server MAYreturn Response Information in the CONNACK packet.

Non-normativecomment

The Server can choose not toinclude Response Information in the CONNACK, even if the Client requested it.

Refer tosection 4.10 for more information about Request/ Response.

3.1.2.11.7Request Problem Information

23 (0x17) Byte, Identifier of the Request ProblemInformation.

Followed by a Byte with a value of either 0 or 1. It is aProtocol Error to include Request Problem Information more than once, or tohave a value other than 0 or 1. If the Request Problem Information is absent, thevalue of 1 is used.

The Client uses this value to indicate whether the ReasonString or User Properties are sent in the case of failures.

If the value of RequestProblem Information is 0, the Server MAY return a Reason String or UserProperties on a CONNACK or DISCONNECT packet, but MUST NOT send a Reason Stringor User Properties on any packetother than PUBLISH,CONNACK, or DISCONNECT[MQTT-3.1.2-29].If the value is 0 and the Client receives a Reason String or User Properties ina packet other than PUBLISH, CONNACK, or DISCONNECT, it uses a DISCONNECT packetwith Reason Code 0x82 (Protocol Error) as described insection4.13 Handling errors.

If this value is 1, the Server MAY return a Reason String orUser Properties on any packet where it is allowed.

3.1.2.11.8 User Property

38 (0x26) Byte, Identifier of the User Property.

Followed by a UTF-8 String Pair.

The User Property is allowed toappear multiple times to represent multiple name, value pairs. The same name isallowed to appear more than once.

Non-normativecomment

User Properties on the CONNECTpacket can be used to send connection related properties from the Client to theServer. The meaning of these properties is not defined by this specification.

3.1.2.11.9 Authentication Method

21 (0x15) Byte, Identifier of the AuthenticationMethod.

Followed by a UTF-8 Encoded String containing the name ofthe authentication method used for extended authentication .It is a ProtocolError to include Authentication Method more than once.

If Authentication Method is absent, extended authenticationis not performed. Refer tosection 4.12.

If a Client sets an AuthenticationMethod in the CONNECT, the Client MUST NOT send any packets other than AUTH orDISCONNECT packets until it has received a CONNACK packet[MQTT-3.1.2-30].

3.1.2.11.10 Authentication Data

22 (0x16) Byte, Identifier of the AuthenticationData.

Followed by Binary Data containing authentication data. Itis a Protocol Error to include Authentication Data if there is noAuthentication Method. It is a Protocol Error to include Authentication Datamore than once.

The contents of this data are defined by the authenticationmethod. Refer tosection 4.12 for moreinformation about extended authentication.

3.1.2.12 Variable Header non-normative example

Figure 3‑6- Variable Header example

3.1.3 CONNECT Payload

The Payload of the CONNECTpacket contains one or more length-prefixed fields, whose presence isdetermined by the flags in the Variable Header. These fields, if present, MUSTappear in the order Client Identifier, Will Properties, Will Topic, Will Payload,User Name, Password[MQTT-3.1.3-1].

3.1.3.1 Client Identifier(ClientID)

The Client Identifier (ClientID)identifies the Client to the Server. Each Client connecting to the Server has aunique ClientID.The ClientID MUST be used byClients and by Servers to identify state that they hold relating to this MQTTSession between the Client and the Server[MQTT-3.1.3-2]. Refer tosection 4.1 for more information about Session State.

TheClientID MUST be present and is the first field in the CONNECT packet Payload[MQTT-3.1.3-3].

The ClientID MUST be a UTF-8Encoded String as defined insection1.5.4[MQTT-3.1.3-4].

The Server MUST allow ClientID’swhich are between 1 and 23 UTF-8 encoded bytes in length, and that contain onlythe characters

"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"[MQTT-3.1.3-5].

The Server MAY allow ClientID’s that contain more than 23 encodedbytes. The Server MAY allow ClientID’s that contain characters not included inthe list given above.

A Server MAY allow a Clientto supply a ClientID that has a length of zero bytes, however if it does so theServer MUST treat this as a special case and assign a unique ClientID to thatClient[MQTT-3.1.3-6].It MUST then process the CONNECT packet as if theClient had provided that unique ClientID, and MUSTreturn the Assigned Client Identifier in the CONNACK packet[MQTT-3.1.3-7].

If the Server rejects theClientID it MAY respond to the CONNECT packet with a CONNACK using Reason Code0x85 (Client Identifier not valid) as described insection 4.13 Handling errors, and then it MUST close the NetworkConnection[MQTT-3.1.3-8].

Non-normativecomment

A Client implementation couldprovide a convenience method to generate a random ClientID. Clients using thismethod should take care to avoid creating long-lived orphaned Sessions.

3.1.3.2 Will Properties

If the Will Flag is set to 1, the Will Properties is thenext field in the Payload. The Will Properties field defines the ApplicationMessage properties to be sent with the Will Message when it is published, andproperties which define when to publish the Will Message. The Will Propertiesconsists of a Property Length and the Properties.

3.1.3.2.1 Property Length

The length of the Properties in the Will Properties encodedas a Variable Byte Integer.

3.1.3.2.2 WillDelay Interval

24 (0x18) Byte, Identifier of the Will DelayInterval.

Followed by the Four Byte Integer representing the WillDelay Interval in seconds. It is a Protocol Error to include the Will Delay Intervalmore than once. If the Will Delay Interval is absent, the default value is 0and there is no delay before the Will Message is published.

The Server delays publishing the Client’s Will Message untilthe Will Delay Interval has passed or the Session ends, whichever happensfirst.If a new Network Connection to thisSession is made before the Will Delay Interval has passed, the Server MUST NOTsend the Will Message[MQTT-3.1.3-9].

Non-normative comment

One use of this is to avoidpublishing Will Messages if there is a temporary network disconnection and theClient succeeds in reconnecting and continuing its Session before the WillMessage is published.

Non-normative comment

If a Network Connection uses aClient Identifier of an existing Network Connection to the Server, the WillMessage for the exiting connection is sent unless the new connection specifiesClean Start of 0 and the Will Delay is greater than zero. If the Will Delay is 0the Will Message is sent at the close of the existing Network Connection, andif Clean Start is 1 the Will Message is sent because the Session ends.

3.1.3.2.3 Payload FormatIndicator

1 (0x01) Byte, Identifier of the Payload FormatIndicator.

Followed by the value of the Payload Format Indicator,either of:

·        0 (0x00) Byte Indicates that the Will Message is unspecifiedbytes, which is equivalent to not sending a Payload Format Indicator.

·        1 (0x01) Byte Indicates that the Will Message is UTF-8 EncodedCharacter Data. The UTF-8 data in the PayloadMUST be well-formed UTF-8 as defined by theUnicode specification[Unicode]and restated in RFC 3629[RFC3629].

It is a Protocol Error to include the Payload Format Indicatormore than once. The Server MAY validate that the Will Message is of the formatindicated, and if it is not send a CONNACK with the Reason Code of 0x99 (Payloadformat invalid) as described in section 4.13.

3.1.3.2.4 Message Expiry Interval

2 (0x02) Byte, Identifier of the Message Expiry Interval.

Followed by the Four Byte Integer representing the MessageExpiry Interval. It is a Protocol Error to include the Message Expiry Intervalmore than once.

If present, the Four Byte value is the lifetime of the WillMessage in seconds and is sent as the Publication Expiry Interval when theServer publishes the Will Message.

If absent, no Message Expiry Interval is sent when theServer publishes the Will Message.

3.1.3.2.5 Content Type

3 (0x03) Identifier ofthe Content Type.

Followed by a UTF-8 Encoded Stringdescribing the content of the Will Message.It is a Protocol Error to include the Content Type more thanonce.The value of the Content Type is defined by the sending and receivingapplication.

3.1.3.2.6 Response Topic

8 (0x08)Byte, Identifier of theResponse Topic.

Followed by aUTF-8 Encoded String which is used as the Topic Name for a response message. Itis a Protocol Error to include the Response Topic more than once. The presenceof a Response Topic identifies the Will Message as a Request.

Refer tosection 4.10 for more information about Request / Response.

3.1.3.2.7 Correlation Data

9 (0x09) Byte, Identifier of the Correlation Data.

Followed by Binary Data. The Correlation Data is used by thesender of the Request Message to identify which request the Response Message isfor when it is received. It is a Protocol Error to include Correlation Datamore than once. If the Correlation Data is not present, the Requester does notrequire any correlation data.

The value of the Correlation Data only has meaning to thesender of the Request Message and receiver of the Response Message.

Refer tosection 4.10 formore information about Request / Response

3.1.3.2.8 User Property

38 (0x26) Byte, Identifier of the User Property.

Followed by a UTF-8 String Pair. The User Property isallowed to appear multiple times to represent multiple name, value pairs. Thesame name is allowed to appear more than once.

The Server MUST maintain theorder of User Properties when publishing the Will Message[MQTT-3.1.3-10].

Non-normative comment

This property is intended toprovide a means of transferring application layer name-value tags whose meaningand interpretation are known only by the application programs responsible forsending and receiving them.

3.1.3.3 Will Topic

If the Will Flag is set to 1, the Will Topic is the nextfield in the Payload. The Will Topic MUST be aUTF-8 Encoded String as defined insection1.5.4[MQTT-3.1.3-11].

3.1.3.4 Will Payload

If the Will Flag is set to 1 the Will Payload is the nextfield in the Payload. The Will Payload defines the Application Message Payloadthat is to be published to the Will Topic as described insection 3.1.2.5. This field consists of Binary Data.

3.1.3.5 User Name

If the User Name Flag is setto 1, the User Name is the next field in the Payload. The User Name MUST be aUTF-8 Encoded String as defined insection1.5.4[MQTT-3.1.3-12].It can be used by the Server for authentication andauthorization.

3.1.3.6 Password

If the Password Flag is set to 1, the Password is the nextfield in the Payload. The Password field is Binary Data. Although this field iscalled Password, it can be used to carry any credential information.

3.1.4 CONNECT Actions

Note that a Server MAY support multiple protocols (includingother versions of the MQTT protocol) on the same TCP port or other networkendpoint. If the Server determines that the protocol is MQTT v5.0 then itvalidates the connection attempt as follows.

1.    If theServer does not receive a CONNECT packet within a reasonable amount of timeafter the Network Connection is established, the Server SHOULD close the NetworkConnection.

2.    The Server MUST validate that the CONNECT packet matchesthe format described insection 3.1and close the Network Connection if it does not match[MQTT-3.1.4-1]. TheServer MAY send a CONNACK with a Reason Code of 0x80 or greater as described insection 4.13 before closing the Network Connection.

3. The Server MAY check that the contents of the CONNECT packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail, it MUST close the Network Connection[MQTT-3.1.4-2]. Before closing the Network Connection, it MAY send an appropriate CONNACK response with a Reason Code of 0x80 or greater as described insection 3.2 andsection 4.13.

If validation is successful, theServer performs the following steps.

1.    If the ClientID represents a Client already connectedto the Server, the Server sends a DISCONNECT packet to the existing Client withReason Code of 0x8E (Session taken over) as described insection 4.13 and MUST close the Network Connection of theexisting Client[MQTT-3.1.4-3]. If theexisting Client has a Will Message, that Will Message is published as describedin section 3.1.2.5.

Non-normative comment

If the Will Delay Interval of theexisting Network Connection is 0 and there is a Will Message, it will be sentbecause the Network Connection is closed. If the Session Expiry Interval of theexisting Network Connection is 0, or the new Network Connection has Clean Startset to 1 then if the existing Network Connection has a Will Message it will besent because the original Session is ended on the takeover.

2.    The Server MUST perform the processing of Clean Startthat is described insection 3.1.2.4[MQTT-3.1.4-4].

3.    The Server MUST acknowledge the CONNECT packet with aCONNACK packet containing a 0x00 (Success) Reason Code[MQTT-3.1.4-5].

Non-normative comment

It is recommended thatauthentication and authorization checks be performed if the Server is beingused to process any form of business critical data. If these checks succeed,the Server responds by sending CONNACK with a 0x00 (Success) Reason Code. Ifthey fail, it is suggested that the Server does not send a CONNACK at all, asthis could alert a potential attacker to the presence of the MQTT Server andencourage such an attacker to launch a denial of service or password-guessingattack.

4.    Startmessage delivery and Keep Alive monitoring.

Clients are allowed to send further MQTT Control Packetsimmediately after sending a CONNECT packet; Clients need not wait for a CONNACKpacket to arrive from the Server.If the Serverrejects the CONNECT, it MUST NOT process any data sent by the Client after theCONNECT packet except AUTH packets[MQTT-3.1.4-6].

Non-normative comment

Clients typically wait for aCONNACK packet, However, if the Client exploits its freedom to send MQTT ControlPackets before it receives a CONNACK, it might simplify the Clientimplementation as it does not have to police the connected state. The Client acceptsthat any data that it sends before it receives a CONNACK packet from the Serverwill not be processed if the Server rejects the connection.

Non-normative comment

Clients that send MQTT ControlPackets before they receive CONNACK will be unaware of the Server constraintsand whether any existing Session is being used.

Non-normative comment

The Server can limit reading fromthe Network Connection or close the Network Connection if the Client sends toomuch data before authentication is complete. This is suggested as a way ofavoiding denial of service attacks.

3.2 CONNACK – Connectacknowledgement

The CONNACK packet is the packet sent by the Server inresponse to a CONNECT packet received from a Client.The Server MUST send a CONNACK with a 0x00 (Success) Reason Code beforesending any Packet other than AUTH[MQTT-3.2.0-1].The Server MUST NOT send more than one CONNACKin a Network Connection[MQTT-3.2.0-2].

If the Client does not receive aCONNACK packet from the Server within a reasonable amount of time, the ClientSHOULD close the Network Connection. A "reasonable" amount of timedepends on the type of application and the communications infrastructure.

3.2.1 CONNACK Fixed Header

The Fixed Header format is illustrated in Figure 3-7.

Figure 3‑7 – CONNACK packet Fixed Header

Remaining Length field

This is the length of the VariableHeader encoded as a Variable Byte Integer.

3.2.2 CONNACK Variable Header

The Variable Header of the CONNACK Packet contains thefollowing fields in the order: Connect Acknowledge Flags, Connect Reason Code, andProperties. The rules for encoding Properties are described insection 2.2.2.

3.2.2.1 Connect Acknowledge Flags

Byte 1 is the "ConnectAcknowledge Flags". Bits 7-1 are reserved and MUST be set to 0[MQTT-3.2.2-1].

Bit 0 is the Session Present Flag.

3.2.2.1.1 Session Present

Position: bit 0 of the Connect Acknowledge Flags.

The Session Present flag informs the Client whether theServer is using Session State from a previous connection for this ClientID.This allows the Client and Server to have a consistent view of the SessionState.

If the Server accepts aconnection with Clean Start set to 1, the Server MUST set Session Present to 0in the CONNACK packet in addition to setting a 0x00 (Success) Reason Code inthe CONNACK packet[MQTT-3.2.2-2].

If the Server accepts aconnection with Clean Start set to 0 and the Server has Session State for theClientID, it MUST set Session Present to 1 in the CONNACK packet, otherwise itMUST set Session Present to 0 in the CONNACK packet. In both cases it MUST seta 0x00 (Success) Reason Code in the CONNACK packet [MQTT-3.2.2-3].

If the value of Session Present received by the Client fromthe Server is not as expected, the Client proceeds as follows:

·        If the Client does not haveSession State and receives Session Present set to 1 it MUST close the NetworkConnection[MQTT-3.2.2-4]. If it wishesto restart with a new Session the Client can reconnect using Clean Start set to1.

·        If the Client does have SessionState and receives Session Present set to 0 it MUST discard its Session Stateif it continues with the Network Connection[MQTT-3.2.2-5].

If a Server sends a CONNACKpacket containing a non-zero Reason Code it MUST set Session Present to 0[MQTT-3.2.2-6].

3.2.2.2 Connect Reason Code

Byte 2 in the Variable Header is the Connect Reason Code.

The values the Connect Reason Code are shown below. If awell formed CONNECT packet is received by the Server, but the Server is unableto complete the Connection the Server MAY send a CONNACK packet containing theappropriate Connect Reason code from this table.Ifa Server sends a CONNACK packet containing a Reason code of 128 or greater itMUST then close the Network Connection[MQTT-3.2.2-7].

Table3‑1 - Connect Reason Code values

The Server sending theCONNACK packet MUST use one of the Connect Reason Code valuesT-3.2.2-8].

Non-normativecomment

Reason Code 0x80 (Unspecifiederror) may be used where the Server knows the reason for the failure but doesnot wish to reveal it to the Client, or when none of the other Reason Codevalues applies.

The Server may choose to close the NetworkConnection without sending a CONNACK to enhance security in the case where anerror is found on the CONNECT. For instance, when on a public network and theconnection has not been authorized it might be unwise to indicate that this isan MQTT Server.

3.2.2.3 CONNACK Properties

3.2.2.3.1 Property Length

This is the length of the Properties in the CONNACK packet VariableHeader encoded as a Variable Byte Integer.

3.2.2.3.2SessionExpiry Interval

17 (0x11) Byte, Identifier of the Session ExpiryInterval.

Followed by the Four Byte Integer representing the SessionExpiry Interval in seconds. It is a Protocol Error to include the SessionExpiry Interval more than once.

If the Session Expiry Interval is absent the value in theCONNECT Packet used. The server uses this property to inform the Client that itis using a value other than that sent by the Client in the CONNACK. Refer to section3.1.2.11.2 for a description of the use of Session Expiry Interval.

3.2.2.3.3 Receive Maximum

33 (0x21) Byte, Identifier of the Receive Maximum.

Followed by the Two Byte Integer representing the ReceiveMaximum value. It is a Protocol Error to include the Receive Maximum value morethan once or for it to have the value 0.

The Server uses this value to limit the number of QoS 1 andQoS 2 publications that it is willing to process concurrently for the Client. Itdoes not provide a mechanism to limit the QoS 0 publications that the Clientmight try to send.

If the Receive Maximum value isabsent, then its value defaults to 65,535.

Refer tosection4.9 Flow Control for details of how the Receive Maximum is used.

3.2.2.3.4 Maximum QoS

36 (0x24) Byte, Identifier of the Maximum QoS.

Followed by a Byte with a value of either 0 or 1. It is aProtocol Error to include Maximum QoS more than once, or to have a value otherthan 0 or 1. If the Maximum QoS is absent, the Client uses a Maximum QoS of 2.

If a Server does not supportQoS 1 or QoS 2 PUBLISH packets it MUST send a Maximum QoS in the CONNACK packetspecifying the highest QoS it supports[MQTT-3.2.2-9].A Server that does not support QoS 1 or QoS 2PUBLISH packets MUST still accept SUBSCRIBE packets containing a Requested QoSof 0, 1 or 2[MQTT-3.2.2-10].

If a Client receives aMaximum QoS from a Server, it MUST NOT send PUBLISH packets at a QoS level exceedingthe Maximum QoS level specified[MQTT-3.2.2-11].It is a Protocol Error if the Server receives a PUBLISH packet with a QoSgreater than the Maximum QoS it specified. In this case use DISCONNECT withReason Code 0x9B (QoS not supported) as described insection4.13 Handling errors.

If a Server receives aCONNECT packet containing a Will QoS that exceeds its capabilities, it MUSTreject the connection. It SHOULD use a CONNACK packet with Reason Code 0x9B(QoS not supported)as described insection 4.13 Handling errors, and MUST close the Network Connection[MQTT-3.2.2-12].

Non-normativecomment

A Client does not need to supportQoS 1 or QoS 2 PUBLISH packets. If this is the case, the Client simplyrestricts the maximum QoS field in any SUBSCRIBE commands it sends to a valueit can support.

3.2.2.3.5Retain Available

37 (0x25) Byte, Identifier of Retain Available.

Followed by a Byte field. If present, this byte declareswhether the Server supports retained messages. A value of 0 means that retainedmessages are not supported. A value of 1 means retained messages are supported.If not present, then retained messages are supported. It is a Protocol Error toinclude Retain Available more than once or to use a value other than 0 or 1.

If a Server receives aCONNECT packet containing a Will Message with the Will Retain set to 1, and itdoes not support retained messages, the Server MUST reject the connectionrequest. It SHOULD send CONNACK with Reason Code 0x9A (Retain not supported)and then it MUST close the Network Connection[MQTT-3.2.2-13].

A Client receiving RetainAvailable set to 0 from the Server MUST NOT send a PUBLISH packet with theRETAIN flag set to 1[MQTT-3.2.2-14]. Ifthe Server receives such a packet, this is a Protocol Error. The Server SHOULDsend a DISCONNECT with Reason Code of 0x9A (Retain not supported) as describedinsection 4.13.

3.2.2.3.6 Maximum Packet Size

39 (0x27) Byte, Identifier of the Maximum PacketSize.

Followed by a Four Byte Integer representing the MaximumPacket Size the Server is willing to accept. If the Maximum Packet Size is notpresent, there is no limit on the packet size imposed beyond the limitations inthe protocol as a result of the remaining length encoding and the protocolheader sizes.

It is a Protocol Error to include the Maximum Packet Size morethan once, or for the value to be set to zero.

The packet size is the total numberof bytes in an MQTT Control Packet, as defined insection 2.1.4. The Server uses theMaximum Packet Size to inform the Client that it will not process packets whosesize exceeds this limit.

The Client MUSTNOT send packets exceeding Maximum Packet Size to the Server[MQTT-3.2.2-15]. If a Server receives a packet whose size exceeds this limit, this isa Protocol Error, the Server uses DISCONNECT with Reason Code 0x95 (Packet too large),as described insection 4.13.

3.2.2.3.7 Assigned Client Identifier

18 (0x12) Byte, Identifier of the Assigned ClientIdentifier.

Followed by the UTF-8 string which is the Assigned ClientIdentifier. It is a Protocol Error to include the Assigned Client Identifiermore than once.

The Client Identifier which was assigned by theServer because a zero length Client Identifier was found in the CONNECT packet.

If the Client connects usinga zero length Client Identifier, the Server MUST respond with a CONNACKcontaining an Assigned Client Identifier. The Assigned Client Identifier MUSTbe a new Client Identifier not used by any other Session currently in theServer[MQTT-3.2.2-16].

3.2.2.3.8Topic Alias Maximum

34 (0x22) Byte, Identifier of the Topic Alias Maximum.

Followed by the Two Byte Integer representing the TopicAlias Maximum value. It is a Protocol Error to include the Topic Alias Maximumvalue more than once. If the Topic Alias Maximum property is absent, thedefault value is 0.

This value indicates the highest value that the Server willaccept as a Topic Alias sent by the Client. The Server uses this value to limitthe number of Topic Aliases that it is willing to hold on this Connection.The Client MUST NOT send a Topic Alias in a PUBLISHpacket to the Server greater than this value[MQTT-3.2.2-17].A value of 0 indicates that the Server does not accept any Topic Aliases onthis connection.If Topic Alias Maximum isabsent or 0, the Client MUST NOT send any Topic Aliases on to the Server[MQTT-3.2.2-18].

3.2.2.3.9Reason String

31 (0x1F) Byte Identifier of the Reason String.

Followed by the UTF-8 Encoded String representing the reasonassociated with this response. This Reason String is a human readable stringdesigned for diagnostics and SHOULD NOT be parsed by the Client.

The Server uses this value to give additional information tothe Client.The Server MUST NOT send thisproperty if it would increase the size of the CONNACK packet beyond the MaximumPacket Size specified by the Client[MQTT-3.2.2-19].It is a Protocol Error to include the Reason String more than once.

Non-normativecomment

Proper uses for the reason stringin the Client would include using this information in an exception thrown by theClient code, or writing this string to a log.

3.2.2.3.10User Property

38 (0x26) Byte,Identifierof User Property.

Followed by a UTF-8String Pair. This property can be used to provide additional information to theClient including diagnostic information.The ServerMUST NOT send this property if it would increase the size of the CONNACK packetbeyond the Maximum Packet Size specified by the Client[MQTT-3.2.2-20]. The User Property is allowed toappear multiple times to represent multiple name, value pairs. The same name isallowed to appear more than once.

The content and meaning of thisproperty is not defined by this specification. The receiver of a CONNACKcontaining this property MAY ignore it.

3.2.2.3.11Wildcard Subscription Available

40 (0x28) Byte, Identifier of Wildcard SubscriptionAvailable.

Followed by a Byte field. If present, this byte declareswhether the Server supports Wildcard Subscriptions. A value is 0 means thatWildcard Subscriptions are not supported. A value of 1 means WildcardSubscriptions are supported. If not present, then Wildcard Subscriptions aresupported. It is a Protocol Error to include the Wildcard SubscriptionAvailable more than once or to send a value other than 0 or 1.

If the Server receives a SUBSCRIBE packet containing a WildcardSubscription and it does not support Wildcard Subscriptions, this is a ProtocolError. The Server uses DISCONNECT with Reason Code 0xA2 (Wildcard Subscriptionsnot supported) as described insection 4.13.

If a Server supports Wildcard Subscriptions, it can still rejecta particular subscribe request containing a Wildcard Subscription. In this casethe Server MAY send a SUBACK Control Packet with a Reason Code 0xA2 (WildcardSubscriptions not supported).

3.2.2.3.12Subscription Identifiers Available

41 (0x29) Byte, Identifier of Subscription IdentifierAvailable.

Followed by a Byte field. If present, this byte declareswhether the Server supports Subscription Identifiers. A value is 0 means thatSubscription Identifiers are not supported. A value of 1 means SubscriptionIdentifiers are supported. If not present, then Subscription Identifiers aresupported. It is a Protocol Error to include the Subscription IdentifierAvailable more than once, or to send a value other than 0 or 1.

If the Server receives a SUBSCRIBE packet containingSubscription Identifier and it does not support Subscription Identifiers, thisis a Protocol Error. The Server uses DISCONNECT with Reason Code of 0xA1(Subscription Identifiers not supported) as described insection4.13.

3.2.2.3.13Shared Subscription Available

42 (0x2A) Byte, Identifier of Shared SubscriptionAvailable.

Followed by a Byte field. If present, this byte declareswhether the Server supports Shared Subscriptions. A value is 0 means thatShared Subscriptions are not supported. A value of 1 means Shared Subscriptionsare supported. If not present, then Shared Subscriptions are supported. It is aProtocol Error to include the Shared Subscription Available more than once orto send a value other than 0 or 1.

If the Server receives a SUBSCRIBE packet containing SharedSubscriptions and it does not support Shared Subscriptions, this is a ProtocolError. The Server uses DISCONNECT with Reason Code 0x9E (Shared Subscriptionsnot supported) as described insection 4.13.

3.2.2.3.14Server Keep Alive

19 (0x13) Byte, Identifier of the Server Keep Alive.

Followed by a Two Byte Integer with the Keep Alive timeassigned by the Server.If the Server sends aServer Keep Alive on the CONNACK packet, the Client MUST use this value insteadof the Keep Alive value the Client sent on CONNECT[MQTT-3.2.2-21].Ifthe Server does not send the Server Keep Alive, the Server MUST use the KeepAlive value set by the Client on CONNECT[MQTT-3.2.2-22].It is a Protocol Error to include the Server Keep Alive more than once.

Non-normativecomment

The primary use of the Server KeepAlive is for the Server to inform the Client that it will disconnect the Clientfor inactivity sooner than the Keep Alive specified by the Client.

3.2.2.3.15 ResponseInformation

26 (0x1A) Byte, Identifier of the ResponseInformation.

Followed by a UTF-8 Encoded String which is used as thebasis for creating a Response Topic. The way in which the Client creates aResponse Topic from the Response Information is not defined by thisspecification. It is a Protocol Error to include the Response Information morethan once.

If the Client sends a Request Response Information with avalue 1, it is OPTIONAL for the Server to send the Response Information in theCONNACK.

Non-normativecomment

A common use of this is to pass aglobally unique portion of the topic tree which is reserved for this Client forat least the lifetime of its Session. This often cannot just be a random nameas both the requesting Client and the responding Client need to be authorizedto use it. It is normal to use this as the root of a topic tree for aparticular Client. For the Server to return this information, it normally needsto be correctly configured. Using this mechanism allows this configuration tobe done once in the Server rather than in each Client.

Refer tosection 4.10 for more information about Request/ Response.

3.2.2.3.16Server Reference

28 (0x1C) Byte, Identifier of the Server Reference.

Followed by a UTF-8 Encoded String which can be used by theClient to identify another Server to use. It is a Protocol Error to include theServer Reference more than once.

The Server uses a Server Reference in either a CONNACK orDISCONNECT packet with Reason code of 0x9C (Use another server) or Reason Code0x9D (Server moved) as described insection 4.13.

Refer to section 4.11 Server redirection for informationabout how Server Reference is used.

3.2.2.3.17 Authentication Method

21 (0x15) Byte, Identifier of the AuthenticationMethod.

Followed by a UTF-8 Encoded String containing the name ofthe authentication method. It is a Protocol Error to include the AuthenticationMethod more than once. Refer tosection4.12 for more information about extended authentication.

3.2.2.3.18 Authentication Data

22 (0x16) Byte, Identifier of the AuthenticationData.

Followed by Binary Data containing authentication data. Thecontents of this data are defined by the authentication method and the state ofalready exchanged authentication data. It is a Protocol Error to include theAuthentication Data more than once. Refer tosection4.12 for more information about extended authentication.

3.2.3CONNACK Payload

The CONNACK packet has no Payload.

3.3 PUBLISH – Publish message

A PUBLISH packet is sent from a Client to a Server or from aServer to a Client to transport an Application Message.

3.3.1PUBLISH Fixed Header

Figure3‑8 – PUBLISH packet Fixed Header

3.3.1.1 DUP

Position: byte 1, bit 3.

If the DUP flag is set to 0, it indicates that this is thefirst occasion that the Client or Server has attempted to send this PUBLISH packet.If the DUP flag is set to 1, it indicates that this might be re-delivery of anearlier attempt to send the packet.

The DUP flag MUST be set to1 by the Client or Server when it attempts to re-deliver a PUBLISH packet[MQTT-3.3.1-1].TheDUP flag MUST be set to 0 for all QoS 0 messages[MQTT-3.3.1-2].

The value of the DUP flag from an incoming PUBLISH packet isnot propagated when the PUBLISH packet is sent to subscribers by the Server.The DUP flag in the outgoing PUBLISH packet is setindependently to the incoming PUBLISH packet, its value MUST be determinedsolely by whether the outgoing PUBLISH packet is a retransmission[MQTT-3.3.1-3].

Non-normativecomment

The receiver of an MQTT ControlPacket that contains the DUP flag set to 1 cannot assume that it has seen anearlier copy of this packet.

Non-normativecomment

It is important to note that theDUP flag refers to the MQTT Control Packet itself and not to the ApplicationMessage that it contains. When using QoS 1, it is possible for a Client toreceive a PUBLISH packet with DUP flag set to 0 that contains a repetition ofan Application Message that it received earlier, but with a different PacketIdentifier. Section 2.2.1 provides moreinformation about Packet Identifiers.

3.3.1.2 QoS

Position: byte 1, bits 2-1.

This field indicates the level of assurance for delivery ofan Application Message. The QoS levels are shown below.

Table3‑2 - QoS definitions

If the Server included a Maximum QoS in its CONNACK responseto a Client and it receives a PUBLISH packet with a QoS greater than this, thenit uses DISCONNECT with Reason Code 0x9B (QoS not supported) as described insection 4.13 Handling errors.

A PUBLISH Packet MUST NOThave both QoS bits set to 1[MQTT-3.3.1-4].If a Server or Client receives a PUBLISH packet which has both QoS bits set to1 it is a Malformed Packet. Use DISCONNECT with Reason Code 0x81 (MalformedPacket) as described insection 4.13.

3.3.1.3RETAIN

Position: byte 1, bit 0.

If the RETAIN flag is set to1 in a PUBLISH packet sent by a Client to a Server, the Server MUST replace anyexisting retained message for this topic and store the Application Message[MQTT-3.3.1-5], so that it can be delivered tofuture subscribers whose subscriptions match its Topic Name.If the Payload contains zero bytes it is processednormally by the Server but any retained message with the same topic name MUSTbe removed and any future subscribers for the topic will not receive a retainedmessage[MQTT-3.3.1-6].A retained message with a Payload containing zero bytesMUST NOT be stored as a retained message on the Server[MQTT-3.3.1-7].

If the RETAIN flag is 0 in aPUBLISH packet sent by a Client to a Server, the Server MUST NOT store the messageas a retained message and MUST NOT remove or replace any existing retainedmessage[MQTT-3.3.1-8].

If the Server included Retain Available in its CONNACKresponse to a Client with its value set to 0 and it receives a PUBLISH packetwith the RETAIN flag is set to 1, then it uses the DISCONNECT Reason Code of0x9A (Retain not supported) as described insection4.13.

When a new Non‑shared Subscription is made, the lastretained message, if any, on each matching topic name is sent to the Client asdirected by the Retain Handling Subscription Option. These messages are sentwith the RETAIN flag set to 1. Which retained messages are sent is controlledby the Retain Handling Subscription Option. At the time of the Subscription:

·        If Retain Handling is set to 0the Server MUST send the retained messages matching the Topic Filter of thesubscription to the Client[MQTT-3.3.1-9].

·        If Retain Handling is set to 1 thenif the subscription did not already exist, the Server MUST send all retainedmessage matching the Topic Filter of the subscription to the Client, and if thesubscription did exist the Server MUST NOT send the retained messages.[MQTT-3.3.1-10].

·        If Retain Handling is set to 2,the Server MUST NOT send the retained messages[MQTT-3.3.1-11].

Refer tosection 3.8.3.1for a definition of the Subscription Options.

If the Server receives a PUBLISH packet with the RETAIN flagset to 1, and QoS 0 it SHOULD store the new QoS 0 message as the new retainedmessage for that topic, but MAY choose to discard it at any time. If thishappens there will be no retained message for that topic.

If the current retained message for a Topic expires, it isdiscarded and there will be no retained message for that topic.

The setting of the RETAIN flag in an Application Messageforwarded by the Server from an established connection is controlled by the RetainAs Published subscription option. Refer tosection3.8.3.1 for a definition of the Subscription Options.

·        If the value of Retain AsPublished subscription option is set to 0, the Server MUST set the RETAIN flagto 0 when forwarding an Application Message regardless of how the RETAIN flagwas set in the received PUBLISH packet[MQTT-3.3.1-12].

·        If the value of Retain As Publishedsubscription option is set to 1, the Server MUST set the RETAIN flag equal tothe RETAIN flag in the received PUBLISH packet[MQTT-3.3.1-13].

Non-normativecomment

Retained messages are useful wherepublishers send state messages on an irregular basis. A new non-sharedsubscriber will receive the most recent state.

3.3.1.4 Remaining Length

This is the length of Variable Header plus the length of thePayload, encoded as a Variable Byte Integer.

3.3.2 PUBLISHVariable Header

The Variable Header of the PUBLISH Packet contains thefollowing fields in the order: Topic Name, Packet Identifier, and Properties.The rules for encoding Properties are described insection2.2.2.

3.3.2.1 Topic Name

The Topic Name identifies the information channel to which Payloaddata is published.

The Topic Name MUST bepresent as the first field in the PUBLISH packet Variable Header. It MUST be aUTF-8 Encoded String as defined insection1.5.4[MQTT-3.3.2-1].

TheTopic Name in the PUBLISH packet MUST NOT contain wildcard characters[MQTT-3.3.2-2].

The Topic Name in a PUBLISHpacket sent by a Server to a subscribing Client MUST match the Subscription’sTopic Filter according to the matching process defined insection 4.7[MQTT-3.3.2-3].However, as the Server is permitted to map the Topic Name to another name, itmight not be the same as the Topic Name in the original PUBLISH packet.

To reduce the size of the PUBLISH packet the sender can usea Topic Alias. The Topic Alias is described insection3.3.2.3.4. It is a Protocol Error if the Topic Name is zero length andthere is no Topic Alias.

3.3.2.2 Packet Identifier

The Packet Identifier field is only present in PUBLISH packetswhere the QoS level is 1 or 2.Section 2.2.1provides more information about Packet Identifiers.

3.3.2.3 PUBLISH Properties

3.3.2.3.1 Property Length

The length of the Properties inthe PUBLISH packet Variable Header encoded as a Variable Byte Integer.

3.3.2.3.2Payload Format Indicator

1 (0x01) Byte, Identifier of the Payload FormatIndicator.

Followed by the value of the Payload Forma t Indicator,either of:

·        0 (0x00) Byte Indicates that the Payload is unspecified bytes, whichis equivalent to not sending a Payload Format Indicator.

·        1 (0x01) Byte Indicates that the Payload is UTF-8 EncodedCharacter Data. The UTF-8 data in the PayloadMUST be well-formed UTF-8 as defined by theUnicode specification[Unicode] and restated in RFC 3629[RFC3629].

A Server MUST send thePayload Format Indicator unaltered to all subscribers receiving the ApplicationMessage[MQTT-3.3.2-4]. The receiver MAYvalidate that the Payload is of the format indicated, and if it is not send aPUBACK, PUBREC, or DISCONNECT with Reason Code of 0x99 (Payload format invalid)as described insection 4.13. Refer tosection5.4.9 for information about security issues invalidating the payload format.

3.3.2.3.3Message Expiry Interval`

2 (0x02) Byte, Identifier of the Message Expiry Interval.

Followed by the Four Byte Integer representing the Message ExpiryInterval.

If present, the Four Byte value is the lifetime of the ApplicationMessage in seconds.If the Message ExpiryInterval has passed and the Server has not managed to start onward delivery toa matching subscriber, then it MUST delete the copy of the message for thatsubscriber[MQTT-3.3.2-5].

If absent, the Application Messagedoes not expire.

The PUBLISH packet sent to aClient by the Server MUST contain a Message Expiry Interval set to the receivedvalue minus the time that the Application Message has been waiting in theServer[MQTT-3.3.2-6].Refer tosection 4.1 for details and limitations of storedstate.

3.3.2.3.4 Topic Alias

35 (0x23) Byte, Identifier of the Topic Alias.

Followed by the Two Byte integer representing the TopicAlias value. It is a Protocol Error to include the Topic Alias value more thanonce.

A Topic Alias is an integer value that is used to identifythe Topic instead of using the Topic Name. This reduces the size of the PUBLISHpacket, and is useful when the Topic Names are long and the same Topic Namesare used repetitively within a Network Connection.

The sender decides whether to use a Topic Alias and choosesthe value. It sets a Topic Alias mapping by including a non-zero length TopicName and a Topic Alias in the PUBLISH packet. The receiver processes thePUBLISH as normal but also sets the specified Topic Alias mapping to this TopicName.

If a Topic Alias mapping has been set at the receiver, asender can send a PUBLISH packet that contains that Topic Alias and a zero lengthTopic Name. The receiver then treats the incoming PUBLISH as if it hadcontained the Topic Name of the Topic Alias.

A sender can modify the Topic Alias mapping by sendinganother PUBLISH in the same Network Connection with the same Topic Alias valueand a different non-zero length Topic Name.

Topic Alias mappings exist only within a Network Connectionand last only for the lifetime of that Network Connection.A receiver MUST NOT carry forward any Topic Alias mappingsfrom one Network Connection to another[MQTT-3.3.2-7].

A Topic Alias of 0 is not permitted.A sender MUST NOT send a PUBLISH packet containing a Topic Alias whichhas the value 0[MQTT-3.3.2-8].

A Client MUST NOT send aPUBLISH packet with a Topic Alias greater than the Topic Alias Maximum valuereturned by the Server in the CONNACK packet[MQTT-3.3.2-9].A Client MUST accept all Topic Alias valuesgreater than 0 and less than or equal to the Topic Alias Maximum value that itsent in the CONNECT packet[MQTT-3.3.2-10].

A Server MUST NOT send aPUBLISH packet with a Topic Alias greater than the Topic Alias Maximum valuesent by the Client in the CONNECT packet[MQTT-3.3.2-11].A Server MUST accept all Topic Alias valuesgreater than 0 and less than or equal to the Topic Alias Maximum value that itreturned in the CONNACK packet[MQTT-3.3.2-12].

The Topic Alias mappings used by the Client and Server areindependent from each other. Thus, when a Client sends a PUBLISH containing aTopic Alias value of 1 to a Server and the Server sends a PUBLISH with a TopicAlias value of 1 to that Client they will in general be referring to differentTopics.

3.3.2.3.5Response Topic

8 (0x08)Byte, Identifier of theResponse Topic.

Followed by aUTF-8 Encoded String which is used as the Topic Name for a response message.The Response Topic MUST be a UTF-8 Encoded Stringas defined insection 1.5.4[MQTT-3.3.2-13].The Response Topic MUST NOT containwildcard characters[MQTT-3.3.2-14]. It is a Protocol Error to include the ResponseTopic more than once. The presence of a Response Topic identifies the Messageas a Request.

Refertosection4.10 for more information about Request/ Response.

The Server MUSTsend the Response Topic unaltered to all subscribers receiving the ApplicationMessage[MQTT-3.3.2-15].

Non-normative comment:

The receiver of an Application Message with a Response Topicsends a response by using the Response Topic as the Topic Name of a PUBLISH. Ifthe Request Message contains a Correlation Data, the receiver of the RequestMessage should also include this Correlation Data as a property in the PUBLISHpacket of the Response Message.

3.3.2.3.6 CorrelationData

9 (0x09) Byte, Identifier of the Correlation Data.

Followed by Binary Data. The Correlation Data is used by thesender of the Request Message to identify which request the Response Message isfor when it is received. It is a Protocol Error to include Correlation Datamore than once. If the Correlation Data is not present, the Requester does notrequire any correlation data.

TheServer MUST send the Correlation Data unaltered to all subscribers receivingthe Application Message[MQTT-3.3.2-16].The value of the Correlation Data only has meaning to the sender of the RequestMessage and receiver of the Response Message.

Non-normativecomment

The receiver of an ApplicationMessage which contains both a Response Topic and a Correlation Data sends aresponse by using the Response Topic as the Topic Name of a PUBLISH. The Clientshould also send the Correlation Data unaltered as part of the PUBLISH of theresponses.

Non-normative comment

If the Correlation Data containsinformation which can cause application failures if modified by the Client respondingto the request, it should be encrypted and/or hashed to allow any alteration tobe detected.

Refer tosection 4.10 formore information about Request / Response

3.3.2.3.7User Property

38 (0x26) Byte, Identifier of the User Property.

Followed by a UTF-8 String Pair. The User Property is allowedto appear multiple times to represent multiple name, value pairs. The same nameis allowed to appear more than once.

The Server MUST send allUser Properties unaltered in a PUBLISH packet when forwarding the ApplicationMessage to a Client[MQTT-3.3.2-17].The Server MUST maintain the order of User Propertieswhen forwarding the Application Message[MQTT-3.3.2-18].

Non-normativecomment

This property is intended toprovide a means of transferring application layer name-value tags whose meaningand interpretation are known only by the application programs responsible forsending and receiving them.

3.3.2.3.8 Subscription Identifier

11 (0x0B),Identifier of the Subscription Identifier.

Followed by aVariable Byte Integer representing the identifier of the subscription.

The SubscriptionIdentifier can have the value of 1 to 268,435,455. It is a Protocol Error ifthe Subscription Identifier has a value of 0. Multiple Subscription Identifierswill be included if the publication is the result of a match to more than onesubscription, in this case their order is not significant.

3.3.2.3.9 Content Type

3 (0x03)Identifier of the Content Type.

Followed by a UTF-8Encoded String describing the content of the Application Message.The Content Type MUST be a UTF-8Encoded String as definedinsection1.5.4[MQTT-3.3.2-19].

It is a Protocol Error to include the ContentType more than once.The value of the Content Type is defined by thesending and receiving application.

AServer MUST send the Content Type unaltered to all subscribers receiving the ApplicationMessage[MQTT-3.3.2-20].

Non-normativecomment

The UTF-8 Encoded String may use a MIMEcontent type string to describe the contents of the Application message.However, since the sending and receiving applications are responsible for thedefinition and interpretation of the string, MQTT performs no validation of thestring except to insure it is a valid UTF-8 Encoded String.

Non-normative example

Figure 3-9 shows an example of a PUBLISHpacket with the Topic Name set to “a/b”, the Packet Identifier set to 10, andhaving no properties.

Figure3‑9- PUBLISH packet Variable Header non-normative example