MQTT Version 3.1 - OASIS · 1 MQTT Version 3.1.1 2 Working Draft 13 ... 198 • The specific details of each Control Packet type ... mqtt-v3.1.1-wd1 3 Working Draft 1 3 05 October

mqtt-v3.1.1-wd13 Working Draft 13 05 October 2013 Standards Track Draft Copyright © OASIS Open 2013. All Rights Reserved. Page 1 of 59

MQTT Version 3.1.1 1

Working Draft 13 2

October 5, 2013 3

Technical Committee: 4 OASIS Message Queuing Telemetry Transport (MQTT) TC 5

Chairs: 6 Raphael J Cohn ([email protected]), Individual 7 Richard J Coppen ([email protected]), IBM 8

Editors: 9 Andrew Banks ([email protected]), IBM 10 Rahul Gupta ([email protected]), IBM 11

12 Additional artifacts: 13

• None 14

Related work: 15 Declared XML namespaces: 16

• None 17

Abstract: 18 19 MQ Telemetry Transport (MQTT) is a lightweight broker-based publish/subscribe messaging 20

protocol designed to be open, simple, lightweight and easy to implement. These characteristics 21 make it ideal for use in constrained environments, for example, but not limited to: 22

23 o Where the network is expensive, has low bandwidth or is unreliable 24 o When run on an embedded device with limited processor or memory resources 25

26 Features of the protocol include: 27 28

o The publish/subscribe message pattern to provide one-to-many message distribution and 29 decoupling of applications 30

o A messaging transport that is agnostic to the content of the payload 31 o The use of TCP/IP to provide basic network connectivity 32 o Three qualities of service for message delivery: 33

• "At most once", where messages are delivered according to the best efforts of 34 the operating environment. Message loss or duplication can occur. This level could 35 be used, for example, with ambient sensor data where it does not matter if an 36 individual reading is lost as the next one will be published soon after. 37 • "At least once", where messages are assured to arrive but duplicates may occur. 38 • "Exactly once", where message are assured to arrive exactly once. This level 39 could be used, for example, with billing systems where duplicate or lost messages 40 could lead to incorrect charges being applied. 41

o A small transport overhead and protocol exchanges minimized to reduce network traffic 42 o A mechanism to notify interested parties to an abnormal disconnection of a client using 43

the Last Will and Testament feature 44 45 Status: 46

This Working Draft (WD) has been produced by one or more TC Members; it has not yet been 47 voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a 48 Committee Note Draft). The OASIS document Approval Process begins officially with a TC vote 49 to approve a WD as a Committee Draft. A TC may approve a Working Draft, revise it, and re-50 approve it any number of times as a Committee Draft. 51

Deleted: 2

Deleted: September 25, 2013

Deleted: 2

Deleted: 2

Deleted: 25 September 2013


Initial URI pattern: 52 http://docs.oasis-open.org/mqtt/mqtt/v4.0/csd01/mqtt-v4.0-csd01.doc 53

(Managed by OASIS TC Administration; please don’t modify.) 54

55

56

57

58

59

60

61

62

63

64

65

66

67

Copyright © OASIS Open 2013. All Rights Reserved. 68

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 69 Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 70

This document and translations of it may be copied and furnished to others, and derivative works that 71 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 72 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 73 and this section are included on all such copies and derivative works. However, this document itself may 74 not be modified in any way, including by removing the copyright notice or references to OASIS, except as 75 needed for the purpose of developing any document or deliverable produced by an OASIS Technical 76 Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 77 be followed) or as required to translate it into languages other than English. 78

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 79 or assigns. 80

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

86

Deleted: 2

Deleted: 2



Table of contents 87

Contents 88

1 Introduction........................................................................................................................................... 6 89

1.1 Terminology ........................................................................................................................................ 6 90

1.2 Conventions........................................................................................................................................ 7 91

1.3 Normative references ......................................................................................................................... 7 92

1.4 Non normative references .................................................................................................................. 8 93

1.5 Acknowledgements............................................................................................................................. 8 94

2 MQTT Control Packet format ............................................................................................................... 9 95

2.1 Data representations .......................................................................................................................... 9 96

2.1.1 Integer data values...................................................................................................................... 9 97

2.1.2 UTF-8 encoded strings................................................................................................................ 9 98

2.2 Fixed header ..................................................................................................................................... 10 99

2.2.1 MQTT Control Packet types ...................................................................................................... 10 100

2.2.2 Flags.......................................................................................................................................... 11 101

2.2.3 Remaining Length ..................................................................................................................... 13 102

2.3 Variable header ................................................................................................................................ 15 103

2.3.1 Packet identifier ......................................................................................................................... 15 104

2.4 Payload ............................................................................................................................................. 16 105

3 MQTT Control Packets ....................................................................................................................... 17 106

3.1 CONNECT – Client requests a connection to a server .................................................................... 17 107

3.1.1 Fixed header.............................................................................................................................. 17 108

3.1.2 Variable header ......................................................................................................................... 17 109

3.1.3 Payload...................................................................................................................................... 22 110

3.1.4 Response .................................................................................................................................. 23 111

3.2 CONNACK – Acknowledge connection request............................................................................... 24 112

3.2.1 Fixed header.............................................................................................................................. 24 113

3.2.2 Variable header ......................................................................................................................... 25 114

3.2.3 Payload...................................................................................................................................... 25 115

3.3 PUBLISH – Publish message........................................................................................................... 25 116

3.3.1 Fixed header.............................................................................................................................. 26 117

3.3.2 Variable header ......................................................................................................................... 26 118

3.3.3 Payload...................................................................................................................................... 27 119

3.3.4 Response .................................................................................................................................. 27 120

3.3.5 Actions....................................................................................................................................... 28 121

3.4 PUBACK – Publish acknowledgement ............................................................................................. 28 122

3.4.1 Fixed header.............................................................................................................................. 28 123

3.4.2 Variable header ......................................................................................................................... 28 124

3.4.3 Payload...................................................................................................................................... 29 125

3.4.4 Actions....................................................................................................................................... 29 126

3.5 PUBREC – Publish received (QoS 2 publish received, part 1) ........................................................ 29 127

3.5.1 Fixed header.............................................................................................................................. 29 128

3.5.2 Variable header ......................................................................................................................... 29 129

Deleted: 24

Deleted: 25

Deleted: 25

Deleted: 26

Deleted: 27

Deleted: 27

Deleted: 27

Deleted: 28

Deleted: 28

Deleted: 28

Deleted: 28

Deleted: 28

Deleted: 2

Deleted: 2



3.5.3 Payload...................................................................................................................................... 29 130

3.5.4 Actions....................................................................................................................................... 30 131

3.6 PUBREL – Publish release (QoS 2 publish received, part 2)........................................................... 30 132

3.6.1 Fixed header.............................................................................................................................. 30 133

3.6.2 Variable header ......................................................................................................................... 30 134

3.6.3 Payload...................................................................................................................................... 31 135

3.6.4 Actions....................................................................................................................................... 31 136

3.7 PUBCOMP – Publish complete (QoS 2 publish received, part 3) .................................................... 31 137

3.7.1 Fixed header.............................................................................................................................. 31 138

3.7.2 Variable header ......................................................................................................................... 31 139

3.7.3 Payload...................................................................................................................................... 31 140

3.7.4 Actions....................................................................................................................................... 32 141

3.8 SUBSCRIBE - Subscribe to topics ................................................................................................... 32 142

3.8.1 Fixed header.............................................................................................................................. 32 143

3.8.2 Variable header ......................................................................................................................... 32 144

3.8.3 Payload...................................................................................................................................... 33 145

3.8.4 Response .................................................................................................................................. 34 146

3.9 SUBACK – Subscription acknowledgement ..................................................................................... 35 147

3.9.1 Fixed header.............................................................................................................................. 35 148

3.9.2 Variable header ......................................................................................................................... 35 149

3.9.3 Payload...................................................................................................................................... 35 150

3.10 UNSUBSCRIBE – Unsubscribe from topics ................................................................................... 36 151

3.10.1 Fixed header............................................................................................................................ 36 152

3.10.2 Variable header ....................................................................................................................... 37 153

3.10.3 Response ................................................................................................................................ 38 154

3.11 UNSUBACK – Unsubscribe acknowledgement.............................................................................. 38 155

3.11.1 Fixed header............................................................................................................................ 38 156

3.11.2 Variable header ....................................................................................................................... 38 157

3.11.3 Payload.................................................................................................................................... 38 158

3.12 PINGREQ – PING request ............................................................................................................. 39 159

3.12.1 Fixed header............................................................................................................................ 39 160

3.12.2 Variable header ....................................................................................................................... 39 161

3.12.3 Payload.................................................................................................................................... 39 162

3.12.4 Response ................................................................................................................................ 39 163

3.13 PINGRESP – PING response ........................................................................................................ 39 164

3.13.1 Fixed header............................................................................................................................ 40 165

3.13.2 Variable header ....................................................................................................................... 40 166

3.13.3 Payload.................................................................................................................................... 40 167

3.14 DISCONNECT – Disconnect notification........................................................................................ 40 168

3.14.1 Fixed header............................................................................................................................ 40 169

3.14.2 Variable header ....................................................................................................................... 40 170

3.14.3 Payload.................................................................................................................................... 40 171

3.14.4 Response ................................................................................................................................ 40 172

4 Operational behaviour ........................................................................................................................ 42 173

4.1 Storing state...................................................................................................................................... 42 174

Deleted: 29

Deleted: 29

Deleted: 29

Deleted: 30

Deleted: 30

Deleted: 30

Deleted: 30

Deleted: 30

Deleted: 31

Deleted: 31

Deleted: 31

Deleted: 32

Deleted: 33

Deleted: 34

Deleted: 34

Deleted: 35

Deleted: 36

Deleted: 37

Deleted: 37

Deleted: 37

Deleted: 38

Deleted: 38

Deleted: 38

Deleted: 38

Deleted: 39

Deleted: 39

Deleted: 39

Deleted: 39

Deleted: 39

Deleted: 41

Deleted: 41

Deleted: 2

Deleted: 2



4.2 Quality of Service levels and flows ................................................................................................... 42 175

4.2.1 QoS 0: At most once delivery.................................................................................................... 43 176

4.2.2 QoS 1: At least once delivery .................................................................................................... 43 177

4.2.3 QoS 2: Exactly once delivery .................................................................................................... 44 178

4.3 Message delivery retry...................................................................................................................... 45 179

4.4 Message ordering ............................................................................................................................. 46 180

4.5 Topic Names and Topic Filters ......................................................................................................... 47 181

4.5.1 Topic wildcards.......................................................................................................................... 47 182

4.5.2 Topic semantic and usage ........................................................................................................ 49 183

4.6 Handling protocol violations.............................................................................................................. 49 184

5 Security............................................................................................................................................... 50 185

6 # Conformance ................................................................................................................................... 56 186

6.1 Conformance Targets ....................................................................................................................... 56 187

6.1.1 MQTT Server............................................................................................................................. 56 188

6.1.2 MQTT Client .............................................................................................................................. 56 189

Appendix A. Title text............................................................................................................................. 57 190

A.1 Subsidiary section ..............................................................................Error! Bookmark not defined. 191

A.1.1 Sub-subsidiary section................................................................Error! Bookmark not defined. 192

Appendix B. Revision history................................................................................................................. 58 193

Deleted: 41

Deleted: 41

Deleted: 42

Deleted: 42

Deleted: 43

Deleted: 44

Deleted: 45

Deleted: 45

Deleted: 46

Deleted: 47

Deleted: 48

Deleted: 50

Deleted: 50

Deleted: 50

Deleted: 50

Deleted: 51

Deleted: 51

Deleted: 51

Deleted: 52

Deleted: 2

Deleted: 2



1 Introduction 194

This specification is split into six main sections: 195

• Introduction and concepts 196

• Control Packet format 197

• The specific details of each Control Packet type 198

• Operational behaviour of the Client and Server 199

• Security considerations 200

• Conformance requirements for this version of the specification 201

1.1 Terminology 202

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 203 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as 204 described in IETF RFC 2119 [RFC2119]. 205

Network Connection: 206

• Connects the Client to the Server, 207

• Provides the means to send an ordered, lossless, stream of bytes in both directions. 208

For examples see section 4.2. 209

Client: 210

A program that establishes the Network Connection: 211

The client can: 212

• Publish Application Messages that Clients may be interested in. 213 • Subscribe to request Application Messages that it is interested in receiving. 214 • Unsubscribe to remove a request for Application Messages. 215 • Disconnect from the server. 216

Server: 217 Accepts connections from Clients. It is the intermediary between the Client publishing Application 218 Messages and the Clients which have made Subscriptions. 219

Application Message: 220 The data carried by the MQTT protocol across the network for the application. 221 Application Messages are transported by MQTT they have an associated Quality of Service and a Topic 222 Name. 223

Topic Name: 224 The label attached to an Application Message which is matched against the subscriptions known to the 225 Server. The Application Message is sent to each client with a matching Subscription. 226

Deleted: TCP

Deleted: <#>Defined in [RFC793] .¶

Deleted: ¶>>>>>>>>>>Needs to be Generalised to SSSL/Websockets etc.

Deleted: TCP

Deleted: application

Deleted: Payload Message





Deleted: ¶>>>>> should be Application Message




Deleted: 2

Deleted: 2



Subscription: 227 The request made by a client to receive Application Messages published by Clients. The Subscription 228 contains a Topic Name which can include wild card characters so that it may match many Topic Names. 229

Session: 230 A stateful interaction between a Client and a Server. Some sessions only last as long as the Network 231 Connection, others span multiple NETWORK Connections. 232

MQTT Control Packet: 233 The packet of information that MQTT flows across the network, this might contain the “Application 234 Message”. 235

1.2 Conventions 236

Bits in a byte are labeled 7 through 0. Bit number 7 is the most significant bit, the least significant bit is 237 assigned bit number 0. 238

All 16-bit word presented in this specification is in big-endian order: higher order bytes precede lower 239 order bytes over the wire. A 16-bit word is presented on the wire as Most Significant Byte (MSB), followed 240 by Least Significant Byte (LSB). This is based on IETF RFC 1700. 241

1.3 Normative references 242

[RFC793] 243 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 244 http://www.ietf.org/rfc/rfc793.txt 245 246

[RFC2119] 247 S. Bradner, Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997. 248 http://www.ietf.org/rfc/rfc2119.txt 249

250

[RFC 3629] 251 F. Yergeau UTF-8, a transformation format of ISO 10646 IETF RFC 3629, November 2003. 252 http://www.ietf.org/rfc/rfc3629.txt 253

254

[Unicode 6.2] Unicode 6.2 specification 255

http://www.unicode.org/versions/Unicode6.2.0 256

257

[RFC 1700] 258

Joyce K. Reynolds, Assigned Numbers, Internet standard STD 2, IETF RFC 1700, October 1994 259

http://tools.ietf.org/html/rfc1700 260

261

[RFC 6455] 262

T. Dierks,The Transport Layer Security (TLS) Protocol Version 1.2, August 2008 263


265

[RFC 5246] 266

I Fette, Proposed Standard STD 2, The WebSocket Protocol, IETF RFC 6455, December 2011 267


Formatted: Font: (Default)

Arial Unicode MS, Font color:

Auto, English (U.S.)


Arial Unicode MS, Font color:

Auto, English (U.S.)


Courier New, Font color: Black

Formatted: HTML

Preformatted, Tabs: Not at

1.62 cm + 3.23 cm + 4.85 cm

+ 6.46 cm + 8.08 cm + 9.69

cm + 11.31 cm + 12.92 cm +

14.54 cm + 16.16 cm +

17.77 cm + 19.39 cm + 21

cm + 22.62 cm + 24.23 cm +

25.85 cm


Deleted: TCP

Deleted: TCP


Deleted: I Fette

Deleted:

Deleted: Proposed Standard STD 2, The WebSocket Protocol, IETF RFC 6455, December 2011¶

Deleted: 2

Deleted: 2



1.4 Non normative references 269

270

[MQTTV31] 271

MQTT V3.1 Protocol Specification. 272

http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-273 v3r1.htmlhttp://www.ibm.com/developerworks/webservices/library/ws-mqtt/index.html. 274

275

1.5 Acknowledgements 276

Secretary: 277 Geoff Brown ([email protected]), M2MI 278

279

280

281

282

283

284

Deleted: 2

Deleted: 2



2 MQTT Control Packet format 285

286

The MQTT protocol works by exchanging a series of MQTT Control Packets in a defined way. This 287 section describes the format of these packets. An MQTT Control Packet consists of up to three parts, 288 always in the following order: 289

290

Fixed header, present in all MQTT Control Packets

Variable header, present in some MQTT Control Packets

Payload, present in some MQTT Control Packets

291 292

Unless stated otherwise, if either the server or client receives a Control Packet which does not meet this 293 specification, it MUST disconnect the Network Connection. If the client or server encounters a transient 294 error while processing an inbound Control Packet it MUST disconnect Network Connection which was 295 used to send the packet. If a server detects a transient error it SHOULD NOT affect any other client. 296

2.1 Data representations 297

2.1.1 Integer data values 298

Integer data values are in big-endian order: higher order bytes precede lower order bytes. A 16-bit 299 word is presented on the wire as Most Significant Byte (MSB), followed by Least Significant Byte 300 (LSB). 301

2.1.2 UTF-8 encoded strings 302

Many of the fields in the Control Packets are encoded as UTF-8. UTF-8 [RFC3629] is an efficient 303 encoding of Unicode character that optimizes the encoding of ASCII characters in support of text-304 based communications. 305

306

In MQTT many of the Control Packets contain components that are defined as UTF-8 encoded 307 strings. Each of these strings is prefixed with a two byte length field that gives the number of bytes in 308 the UTF-8 encoded string itself, as shown in table below. Consequently there is a limit on the size of 309 a string that can be passed in one of these UTF-8 encoded string components; you cannot use a 310 string that would encode to more than 65535 bytes. 311

Unless stated otherwise all UTF-8 encoded strings are 0 to 65535 bytes in length. 312

313

Bit 7 6 5 4 3 2 1 0

Byte 1 String byte length MSB

Byte 2 String byte length LSB

Byte 3 …. UTF-8 Encoded Character Data, if length > 0.

314

Non normative example. 315

Formatted: Font: 10 pt, Font

color: Auto, Pattern: Clear





Deleted: TCP

Deleted:

Deleted: 2

Deleted: 2



For example, the string A� which is LATIN CAPITAL Letter A followed by the code point 316

U+2A6D4 (which represents a CJK IDEOGRAPH EXTENSION B character). 317

318

Bit 7 6 5 4 3 2 1 0

byte 1 Message Length MSB (0x00)

0 0 0 0 0 0 0 0

byte 2 Message Length LSB (0x05)

0 0 0 0 0 1 0 1

byte 3 'A' (0x41)

0 1 0 0 0 0 0 1

byte 4 (0xF0)

1 1 1 1 0 0 0 0

byte 5 (0xAA)

1 0 1 0 1 0 1 0

byte 6 (0x9B)

1 0 0 1 1 0 1 1

byte 7 (0x94)

1 0 0 1 0 1 0 0

319

320

2.2 Fixed header 321

Each MQTT Control Packet contains a fixed header. The table below shows the fixed header format. 322

323

Bit 7 6 5 4 3 2 1 0

Byte 1 MQTT Control Packet type Flags specific to each MQTT Control Packet type

Byte 2… Remaining Length

324

2.2.1 MQTT Control Packet types 325

326

Position: byte 1, bits 7-4. 327

Represented as a 4-bit unsigned value, the values are shown in the table below. 328

329

Name Value Direction of Description

Deleted: 2

Deleted: 2



flow

Reserved 0 Forbidden Reserved

CONNECT 1 Client to server Client request to connect to server

CONNACK 2 Server to client Connect acknowledgment

PUBLISH 3 Client to server

or

Server to client

Publish message

PUBACK 4 Client to server

or

Server to client

Publish acknowledgment

PUBREC 5 Client to server

or

Server to client

Publish received (assured delivery part 1)

PUBREL 6 Client to server

or

Server to client

Publish release (assured delivery part 2)

PUBCOMP 7 Client to server

or

Server to client

Publish complete (assured delivery part 3)

SUBSCRIBE 8 Client to server Client subscribe request

SUBACK 9 Server to client Subscribe acknowledgment

UNSUBSCRIBE 10 Client to server Client unsubscribe request

UNSUBACK 11 Server to client Unsubscribe acknowledgment

PINGREQ 12 Client to server PING request

PINGRESP 13 Server to client PING response

DISCONNECT 14 Client to server Client is disconnecting

Reserved 15 Forbidden Reserved

330

2.2.2 Flags 331

The remaining bits[3-0] of byte 1 in the fixed header contain flags specific to each MQTT Control Packet 332 type as detailed in the table below. Where a bit is unused, it must be set to zero and is reserved for 333 future use. If invalid flags are received, the receiver MUST disconnect the Network connection. 334

335

Control Packet Fixed header flags Bit 3 Bit 2 Bit 1 Bit 0

CONNECT Reserved 0 0 0 0

CONNACK Reserved 0 0 0 0

Deleted: TCP

Deleted:

Deleted: 2

Deleted: 2



PUBLISH Used in MQTT Dup QoS QoS RETAIN

PUBACK Reserved 0 0 0 0

PUBREC Reserved 0 0 0 0

PUBREL Used in MQTT Dup 0 1 0

PUBCOMP Reserved 0 0 0 0

SUBSCRIBE Used in MQTT Dup 0 1 0

SUBACK Reserved 0 0 0 0

UNSUBSCRIBE Used in MQTT Dup 0 1 0

UNSUBACK Reserved 0 0 0 0

PINGREQ Reserved 0 0 0 0

PINGRESP Reserved 0 0 0 0

DISCONNECT Reserved 0 0 0 0

336

Dup = Duplicate delivery of Control Packet 337

QoS = Quality of Service 338

RETAIN = Retain flag 339

2.2.2.1 Dup 340

Position: byte 1, bit 3. 341

This flag MUST be set to 1 by the client or server when it attempts to re-deliver a PUBLISH,Packet. 342 The Dup flag MUST be 0 for all QoS 0 messages and for PUBREL, SUBSCRIBE and 343 UNSUBSCRIBE Packets. If Dup 0 then the flow is the first occasion that the client or server has 344 attempted to send the MQTT PUBISH Packet. If Dup 1 then the this indicates that the flow might be 345 re-delivery of an earlier packet. The DUP flag MUST not be propagated when the PUBLISH Packet is 346 sent to subscribers by the server. 347

348

349

Non Normative comment. 350

The recipient of a Control Packet that contains the Dup flag set to 1 cannot assume that it has seen 351 an earlier copy of this packet. It is important to note that the Dup flag refers to the Control Packet 352 itself and not to to the Application Message that it contains. When using QoS 1, it is possible for a 353 client to receive a PUBLISH Packet with DUP set to 0 that contains a repetition of an Application 354 Message that it received earlier, but with a different MessageID. 355

2.2.2.2 QoS 356

Position: byte 1, bit 2-1. 357

This field indicates the level of assurance for delivery of an Application Message. The QoS levels are 358 shown in the table below. 359

360

QoS value bit 2 bit 1 Description

0 0 0 At most once delivery

Formatted: Heading 4,H4,

Indent: Left: 2.16 cm

Formatted: Justified, Indent:

Left: 0.63 cm







Formatted: Default Paragraph

Font, Font: 10 pt, Font color:

Auto, Pattern: Clear

Formatted: Left









Formatted: Font: Not Bold



Formatted: Bullets and

Numbering



Deleted: ¶

Deleted: ¶See MQTT Issue-27.

Deleted: PUBREL, SUBSCRIBE or UNSUBSCRIBE Control

Deleted: if

Deleted: Control

Deleted:

Deleted: If Dup 1 then the flow is a re-delivery of an earlier packet.

Deleted: If 1, the recipient might have previously received the Control Packet it should not treat this flag as an indication that it has previously received the MQTT Control Packet and should not use the Dup flag alone to guarantee to its application that a duplicate


Deleted: 2

Deleted: 2


... [1]

... [2]


1 0 1 At least once delivery

2 1 0 Exactly once delivery

3 1 1 Reserved

2.2.2.3 RETAIN 361

Position: byte 1, bit 0. 362

363

See issue MQTT-10. 364

This flag is only used on the PUBLISH Packet. 365

366

If 1, in a PUBLISH Packet sent by a client to a server, the server MUST store the publication, so that 367 it can be delivered to future subscribers whose subscriptions match the topic. When a new 368 subscription is established, the last retained message, if any, on each matching topic MUST be sent 369 to the subscriber. 370

371

If 0, in a PUBLISH Packet sent by a client to a server, the server does not store the message nor 372 does it remove or replace any existing retained publication. 373

374

When sending a PUBLISH Packet to a client the server MUST set the RETAIN bit to 1 if a message is 375 sent as a result of a new subscription being made by a client. It MUST set the RETAIN bit to 0 when a 376 PUBLISH Packet is sent to a client because it matches an established subscription regardless of how 377 the bit was set in the message it received. 378

379

A PUBLISH Packet with a retain flag set to 1 and a payload containing zero bytes will be processed 380 as normal by the server and sent to clients with a subscription matching the topic name. Additionally 381 any existing retained publication with the same topic name MUST be removed and any future 382 subscribers for the topic will not receive a retained publication. As normal means that the retained bit 383 is not set in the message received by existing clients. 384

385

Non normative comment. 386

Retained messages are useful where publishers send state messages on an irregular basis. A new 387 subscriber will receive the most recent state. 388

389

2.2.3 Remaining Length 390

Position: byte 2. 391

392

The Remaining length is the number of bytes remaining within the current packet, including data in 393 the variable header and the payload. The Remaining Length does not include the bytes used to 394 encode the Remaining Length. 395

396

The Remaining Length is encoded using a variable length encoding scheme which uses a single byte 397 for values up to 127. Larger values are handled as follows. Seven bits of each byte encode the data, 398 and the eighth bit indicates that there are following bytes in the representation. Each byte encodes 399 128 values and a "continuation bit". The maximum number of bytes in the Remaining Length is four. 400

401

Deleted: Control

Deleted: p

Deleted: p

Deleted: p

Deleted: A server MAY delete a retained message if it receives a message with a zero-length payload and the Retain flag set on the same topic.¶

Deleted: will

Deleted: 2

Deleted: 2




For example, the number 64 decimal is encoded as a single byte, decimal value 64, hex 0x40. The 403 number 321 decimal (= 65 + 2*128) is encoded as two bytes, least significant first. The first byte 404 65+128 = 193. Note that the top bit is set to indicate at least one following byte. The second byte is 2. 405

406


This allows applications to send Control Packets of size up to 268,435,455 (256 MB). The 408 representation of this number on the wire is: 0xFF, 0xFF, 0xFF, 0x7F. The table below shows the 409 Remaining Length values represented by increasing numbers of bytes. 410

411

Digits From To

1 0 (0x00) 127 (0x7F)

2 128 (0x80, 0x01) 16 383 (0xFF, 0x7F)

3 16 384 (0x80, 0x80, 0x01) 2 097 151 (0xFF, 0xFF, 0x7F)

4 2 097 152 (0x80, 0x80, 0x80, 0x01) 268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)

412


The algorithm for encoding a non negative integer (X) into the variable length encoding scheme is as 414 follows: 415

do 416

encodedByte = X MOD 128 417

X = X DIV 128 418

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

if ( X > 0 ) 420

encodedByte = encodedByte OR 128 421

endif 422

'output' encodedByte 423

while ( X > 0 ) 424

425

Where MOD is the modulo operator (% in C), DIV is integer division (/ in C), and OR is bit-wise or (| in 426 C). 427

428


The algorithm for decoding the Remaining Length field is as follows: 430

431

multiplier = 1 432

value = 0 433

do 434

encodedByte = 'next byte from stream' 435

value += (encodedByte AND 127) * multiplier 436

multiplier *= 128 437

if (multiplier > 128*128*128) 438

Deleted: p

Deleted: 2

Deleted: 2



throw Error(Malformed Remaining Length) 439

while ((encodedByte AND 128) != 0) 440

441

where AND is the bit-wise and operator (& in C). 442

443

When this algorithm terminates, value contains the Length. 444

2.3 Variable header 445

Some types of MQTT Control Packets also contain a variable header component. It resides between 446 the fixed header and the payload. The Packet Identifier is common to several packet types 447

2.3.1 Packet Identifier 448

Bit 7 6 5 4 3 2 1 0

Packet Identifier MSB

Packet Identifier LSB

449

The variable header component of many of the Control Packet types includes a 2 byte Packet 450 Identifier (PacketId) field. These Control Packets are PUBLISH (where QoS > 0), PUBACK, 451 PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK. 452

453

A PUBACK, PUBREC, PUBREL Packet MUST contain the same PacketId as the PUBLISH Packet 454 that initiated the flow. Similarly SUBACK and UNSUBACK MUST contain the PacketId that was used 455 in the corresponding SUBSCRIBE and UNSUBSCRIBE Packet respectively. 456

457

A PUBLISH Packet MUST NOT contain a PacketId if its QoS value is set to 0. 458

459

SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) MUST contain a non-zero 460 16-bit PacketId. Each time a client sends a new packet of one of these types it MUST assign it a 461 currently unused PacketId. If a client resends a particular Control Packet, then it MUST use the same 462 PacketId in subsequent resends of that packet. The PacketId becomes available for reuse after the 463 client has processed the corresponding acknowledgement packet (PUBREC in the case of QoS 2). 464 The same conditions apply to a server when it sends a PUBLISH with QoS > 0. 465

466

Control Packets that contain a Packet Identifier 467

Control Packet Packet Identifier field

CONNECT NO

CONNACK NO

PUBLISH YES (If Qos > 0)

PUBACK YES

PUBREC YES

PUBREL YES

Deleted: i

Deleted: Control

Deleted: Control

Deleted: Control

Deleted: Control

Deleted: 2

Deleted: 2



PUBCOMP YES

SUBSCRIBE YES

SUBACK YES

UNSUBSCRIBE YES

UNSUBACK YES

PINGREQ NO

PINGRESP NO

DISCONNECT NO

468

469

The client and server assign PacketIds independently of each other. As a result, client server pairs 470 can participate in concurrent message exchanges using the same PacketId. 471

472

Non-Normative comment 473

474

It is possible for a client to send a PUBLISH Packet with PacketId 0x1234 and then receive a different 475 PUBLISH with PacketId 0x1234 from its server before it receives a PUBACK for the PUBLISH that it 476 sent. 477

Client Server 478 PUBLISH PacketId=0x1234---� 479 --PUBLISH PacketId=0x1234 480 PUBACK PacketId=0x1234---� 481 --PUBACK PacketId=0x1234 482

483

484

2.4 Payload 485

Some MQTT Control Packets contain a payload as the final part of the packet, as described in section 486 3. 487

Deleted: Control

Deleted: s

Deleted: ublish

Deleted: ublish

Deleted: ,

Deleted: 3

Deleted: 2

Deleted: 2



3 MQTT Control Packets 488

3.1 CONNECT – Client requests a connection to a server 489

490

After a Network Connection is established by a client to a server, the first flow from the client to the 491 server MUST be a CONNECT Packet..A client can only flow the CONNECT Packet once over a 492 Network Connection. The Server MUST process a second CONNECT Packet sent from a client as a 493 protocol violation and disconnect the client. 494

495

The payload contains one or more encoded fields. They specify a unique client identifier for the client, 496 a Will topic and message and the User Name and Password. All but the client identifier are optional 497 and their presence is determined based on flags in the variable header. 498

3.1.1 Fixed header 499

The fixed header format is shown in the table below. 500

501

Bit 7 6 5 4 3 2 1 0

byte 1 MQTT Control Packet type (1) Reserved

0 0 0 1 0 0 0 0

byte 2… Remaining Length

502

Remaining Length field 503

Remaining Length is the length of the variable header (10 bytes) plus the length of the Payload. As 504 described in section 2.2.3 505

3.1.2 Variable header 506

The variable header for the CONNECT Packet consists of four fields in the following order: Protocol 507 Name, Protocol Level, Connect Flags, and Keep Alive. 508

3.1.2.1 Protocol Name 509

510

Description 7 6 5 4 3 2 1 0

Protocol Name

byte 1 Length MSB (0) 0 0 0 0 0 0 0 0

byte 2 Length LSB (4) 0 0 0 0 0 1 0 0

byte 3 ‘M’ 0 1 0 0 1 1 0 1

byte 4 ‘Q’ 0 1 0 1 0 0 0 1

byte 5 ‘T’ 0 1 0 1 0 1 0 0







Deleted: TCP/IP [RFC793]

Deleted: c

Deleted: Control

Deleted: Timer

Deleted: 2

Deleted: 2



byte 6 ‘T’ 0 1 0 1 0 1 0 0

511

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

515

The server MAY disconnect the client if the protocol name is incorrect. 516

517

Non normative comment 518

Control Packet inspectors, such as firewalls, can use the Protocol Name to identify MQTT traffic 519

3.1.2.2 Protocol Level 520


Protocol Level

byte 7 Level(4) 0 0 0 0 0 1 0 0

521

The 8 bit unsigned value that represents the revision level of the protocol used by the client. The 522 value of the Protocol Level field for the current version of the protocol is 4 (0x04). The server MUST 523 respond to the CONNECT Packet with a CONNACK return code 0x01 (unacceptable protocol level) 524 and then disconnect the client if the Protocol Level is not supported by the server. 525

526

3.1.2.3 Connect Flags 527

The Connect Flags byte contains a number of parameters specifying the behavior of the MQTT 528 connection. It also indicates the presence or absence of fields in the payload. 529

530

7 6 5 4 3 2 1 0

User Name Flag

Password Flag

Will Retain Will QoS Will Flag Clean Session

Reserved

byte 8 X X X X X X X 0

The server MUST validate that reserved bits are set to zero and disconnect the client if they are not zero. 531

532

3.1.2.3.1 Clean Session 533

Position: bit 1 of the Connect Flags byte. 534

535

If set to 0, the Server resumes communications with the Client based on state from the current 536 Session, otherwise it creates a new Session. The Client and Server will store the Session after the 537 Client and Server are disconnected. After disconnection, the Server MUST accumulate further QoS 1 538 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection. It 539 MAY accumulate QOS 0 messages that meet the same criteria. 540

541

Deleted: p

Deleted: 2

Deleted: 2



If set to 1, the Client and Server MUST discard any previous Session and start a new one. This 542 Session lasts as long as the Network Connection and MUST NOT be reused. 543

544

The Session state in the client consists of: 545

• QoS 1 and QoS 2 messages for which transmission to the server is incomplete. 546

• The client MAY store QoS 0 messages for transmission after the CONNECT Packet has flowed. 547

548

The Session state in the server consists of: 549

• The client subscriptions which it has acknowledged. 550

• All QoS 1 and QoS 2 messages for which transmission to the client is incomplete or where 551 transmission to the client has not yet been started. 552

• The server MAY store QoS 0 messages for which transmission is incomplete or where 553 transmission to the client has not yet been started. 554

555

Retained publications do not form part of the Session state in the server, they MUST NOT be deleted 556 when the Session ends. 557

558

State could be lost by either the client or server due to the storage mechanism used, or an administrator 559 action. This could result in the loss or duplication of messages regardless of the QoS used. 560

561

When Clean Session is set to 1 the client and server need not process the deletion of state atomically. 562

563


Consequently in the event of a failure to connect the client should repeat its attempts to connect with 565 Clean Session set to 1, until it connects successfully. 566

567


Typically, a client will always connect using CleanSession 0 or CleanSession 1 and not swap between the 569 two values. The choice will depend on the application. A client using CleanSession 1 will not receive old 570 publications and has to subscribe afresh to any topics that it is interested in each time it connects. A client 571 using CleanSession 0 will receive all QoS 1 or QoS 2 messages that were published whilst it was 572 disconnected. Hence, to ensure that you do not lose messages use QoS 1 or QoS 2 with CleanSession 573 0. 574


When a client connects with cleanSession = 0 it is requesting that the server maintain its MQTT session 576 state after it disconnects. Clients should only connect with cleanSession = 0 if they intend to reconnect to 577 the server at some later point in time. When a client has determined that it has no further use for the 578 session it should do a final reconnect with cleanSession = 1 579

3.1.2.3.2 Will Flag 580

Position: bit 2 of the Connect Flags. 581

582

The Will Flag indicates that a Will Message MUST be published by the server when the server detects 583 that the client is disconnected for any reason other than the client flowing a DISCONNECT Packet. This 584 includes but is not limited to the flowing situations: 585

• An I/O error or network failure detected by the server. 586



Deleted: TCP

Deleted: connect

Deleted: p

Deleted: o

Deleted: Control

Deleted: 2

Deleted: 2



• The client fails to communicate within the Keep Alive time. 587

• The client disconnects the Network Connection without first sending a DISCONNECT Packet. 588

589

If the Will Flag is set to 1, the Will QoS and Will Retain fields in the Connect Flags will be used by the 590 server, and the Will Topic and Will Message fields MUST be present in the payload. 591

592

3.1.2.3.3 Will QoS 593

Position: bits 4 and 3 of the Connect Flags. 594

595

A connecting client specifies the QoS level of the Will message in the Will QoS field. 596

597

If the Will Flag is set to 0, then the Will QoS MUST be set to 0 (0x00). 598

If the will Flag is set to 1, the value of Will QoS can be 0 (0x00), 1 (0x01), or 2 (0x02). 599

3.1.2.3.4 Will Retain 600


602

If the Will Flag is set to 0, then the Will Retain Flag MUST be set to 0 603

604

If the Will Flag is set to 1: 605

• If Will Retain is set to 0, the server MUST publish the will message as a non-retained publication. 606

• If Will Retain is set to 1, the server MUST publish the will message as a retained publication. 607

608

3.1.2.3.5 User Name Flag 609


611

If the User Name Flag is set to 0, a user name MUST NOT be present in the payload. 612

If the User Name Flag is set to 1, a user name MUST be present in the payload. 613

614

3.1.2.3.6 Password Flag 615

Position: bit 6 of the Connect Flags byte. 616

617

If the Password Flag is set to 0, a password MUST NOT be present in the payload. 618

If the Password Flag is set to 1, a password MUST be present in the payload. 619

If the User Name Flag is set to 0 then the Password Flag MUST be set to 0. 620

621

3.1.2.4 Keep Alive 622

7 6 5 4 3 2 1 0

byte 9 Keep Alive MSB

Deleted: Timer schedule

Deleted: TCP

Deleted: c

Deleted: Control

Deleted: 2

Deleted: 2



byte 10 Keep Alive LSB

623

The Keep Alive is a time interval measured in seconds. Expressed as a 16-bit word, it is the maximum 624 time interval that is permitted to elapse between Control Packets sent by a client. 625

626

It is the responsibility of the client to ensure that the interval between Control Packets being sent does not 627 exceed the Keep Alive value. In the absence of sending any other Control Packets, the client MUST send 628 a PINGREQ Packet. 629

The client can send PINGREQ at any time and use the PINGRESP to determine that the network and the 630 server are working. 631

632

If the server does not receive a Control Packet from the client within one and a half times the Keep Alive 633 time period, it MUST disconnect the client as if the network had failed. 634

635

If a client does not receive a PINGRESP Packet within a reasonable amount of time after it has sent a 636 PINGREQ, it SHOULD close the Network Connection. 637

638

A Keep Alive value of zero (0) has the effect of turning off the keep alive mechanism. 639

640


The actual value of the Keep Alive is application-specific, typically this is a few minutes. The maximum 642 value is approximately 18 hours. 643

644

3.1.2.5 Variable header example, Non normative 645

646


Protocol Name

byte 1 Length MSB (0) 0 0 0 0 0 0 0 0

byte 2 Length LSB (4) 0 0 0 0 0 1 0 0

byte 3 ‘M’ 0 1 0 0 1 1 0 1

byte 4 ‘Q’ 0 1 0 1 0 0 0 1

byte 5 ‘T’ 0 1 0 1 0 1 0 0

byte 6 ‘T’ 0 1 0 1 0 1 0 0

Protocol Level


byte 7 Level (4) 0 0 0 0 0 1 0 0

Connect Flags

Deleted: Control

Deleted: p

Deleted: TCP c

Deleted: 2

Deleted: 2



byte 8

User Name Flag (1)

Password Flag (1)

Will Retain (0)

Will QoS (01)

Will Flag (1)

Clean Session (1)

Reserved (0)

1

1

0

0

1

1

1

0

Keep Alive

byte 9 Keep Alive MSB (0) 0 0 0 0 0 0 0 0

byte 10 Keep Alive LSB (10) 0 0 0 0 1 0 1 0

647

3.1.3 Payload 648

The payload of the CONNECT Packet contains one or more length-prefixed fields, whose presence is 649 determined by the flags in the variable header. These fields, if present, MUST appear in the order below. 650

651

3.1.3.1 Client Identifier 652

The Client Identifier (ClientId) MUST be present and is the first field in the payload. 653

654

The ClientId MUST comprise only Unicode characters, and the length of the UTF-8 encoding 655 must be at least zero bytes and no more than 65535 bytes. 656 657 The server MAY restrict the ClientId it allows in terms of their lengths and the characters they 658 contain, however the server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded 659 bytes in length, and contain only the characters 660 "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ". 661 662 A zero-byte clientId is considered a special case and a server MUST support the following 663 behaviour or not permit zero-byte clientIds. 664 665 If the client supplies a zero-byte ClientId, the client MUST also set Clean Session to 1. This 666 combination indicates that the client has no unique identifier and that the server will process the 667 connection as if it were a unique client. 668 669 If the client supplies a zero-byte clientId with Clean Session set to 0, the server MUST respond to 670 the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then terminate 671 the Network Connection 672 673 If the server rejects the ClientId it MUST respond to the CONNECT Packet with a CONNACK 674 return code 0x02 (Identifier rejected) and then terminate the Network Connection 675

676

The ClientId identifies the client to the server. The ClientId MUST be unique for each client 677 connecting to the server, It can be used by clients and by servers to identify state that they hold 678 relating to this MQTT connection between the client and the server. 679





color: Auto







color: Auto







color: Auto



Formatted: Justified











color: Auto








color: Auto






Deleted: Control

Deleted: ¶

Deleted: ¶The ClientId MUST comprise only Unicode characters, and Deleted: 2

Deleted: 2


... [3]


680


682

A client implementation may provide a convenience method to generate a random ClientId. Use 683 of such a method should be actively discouraged when the Clean Session flag is set to 0. 684

3.1.3.2 Will Topic 685

If the Will Flag is set to 1, the Will Topic is the next field in the payload. The Will Topic is a UTF-8 686 encoded string. 687

3.1.3.3 Will Message 688

See Issue MQTT-2 689

If the Will Flag is set to 1 the Will Message is the next field in the payload. The Will Message 690 defines the payload content of the message that is published to the Will Topic if the client is 691 disconnected for any reason other than the client sending a DISCONNECT Packet. This field 692 consists of a 2-byte length followed by the payload for the Will Message expressed as a 693 sequence of zero or more bytes. The length gives the number of bytes in the payload that follows 694 and does not include the 2 bytes taken up by the length itself. 695

696

When the Will Message is published to the Will Topic its payload consists only of the payload 697 portion of this field, not the first two length bytes. 698

3.1.3.4 User Name 699

If the User Name Flag is set to 1, this is the next field in the payload. User Name is a UTF-8 700 encoded string and can be used by the server for authentication, and authorization. 701

3.1.3.5 Password 702

If the Password Flag is set to 1, this is the next field in the payload. Password is a UTF-8 703 encoded string and can be used by the server for authentication of the client. 704

3.1.4 Response 705

Note that a server MAY support multiple protocols (including earlier versions of this protocol) on 706 the same TCP port or other endpoint. If the server determines that the protocol is MQTT 3.1.1 707 then it MUST validate the connection attempt as follows. 708

709

1. If the server does not receive a CONNECT Packet within a reasonable amount of time 710 after the Network Connection is established, the server SHOULD close the connection. 711 712

2. The server MUST validate that the CONNECT Packet conforms to section 3.1 and close 713 the Network Connection without sending a CONNACK if it does not conform. 714 715

3. The server MAY check that the contents of the CONNECT Packet meet any further 716 restrictions and MAY perform authentication and authorization checks. If any of these 717 checks fail, it SHOULD send an appropriate CONNACK response with a non zero return 718 code as described in section 3.2 and it MUST close the Network Connection. 719

720

If validation is successful the server MUST perform the following steps. 721

722

Deleted: ¶

Deleted: p

Deleted: p

Deleted: TCP c

Deleted: TCP c

Deleted: TCP connection

Deleted: 2

Deleted: 2



1. If the ClientId represents a client already connected to the server then the server MUST 723 disconnect the existing client. 724

725

2. Processing of Clean Session is performed as described in section 3.1.2.3.1. 726

727

3. The server acknowledges the CONNECT Packet with a CONNACK Packet containing a 728 zero return code. 729

730

4. Start message delivery and keep alive monitoring. 731

732

Clients are allowed to send further Control Packets immediately after sending a CONNECT 733 Packet; clients need not wait for a CONNACK Packet to arrive from the server. If the server 734 rejects the CONNECT, it MUST NOT process any data sent by the client after the CONNECT 735 Packet. 736 737

Non Normative comment. 738 739 Clients typically wait for a CONNACK Packet, However, if the client exploits its freedom to send 740 Control Packets before it receives a CONNACK, it might simplify the client implementation as it 741 does not have to police the connected state. The client accepts that any data that it sends before 742 it receives a CONNACK packet from the server will not be processed if the server rejects the 743 connection. 744

745

746

747

3.2 CONNACK – Acknowledge connection request 748

749

The CONNACK Packet is the packet sent by the server in response to a CONNECT Packet received from 750 a client. The first packet sent from the server to the client MUST be a CONNACK Packet. 751

752

If the client does not receive a CONNACK Packet from the server within a reasonable amount of time, the 753 client SHOULD close the Network Connection. A "reasonable" amount of time depends on the type of 754 application and the communications infrastructure. 755

756


758

The fixed header format is shown in the table below. 759

760

Bit 7 6 5 4 3 2 1 0

byte 1 MQTT Control Packet Type (2) Reserved

0 0 1 0 0 0 0 0

byte 2 Remaining Length (2)

0 0 0 0 0 0 1 0

Formatted: Indent: Left: 0

cm

Deleted: ¶

Deleted: p

Deleted: p

Deleted: p

Deleted: Control

Deleted: Control

Deleted: p

Deleted: TCP c

Deleted: 2

Deleted: 2



761


This is the length of the variable header. For the CONNACK Packet this has the value 2. 763


The variable header format is shown in the table below.- 765


Reserved for future use

byte 1 0 0 0 0 0 0 0 0

CONNECT Return code

byte 2

766

If a correctly formed CONNECT Packet is received by the server, but the server is unable to process it 767 (for some reason), then the server SHOULD attempt to flow one of the following CONNACK return codes 768 before disconnecting the Network Connection. The values for the one byte unsigned CONNECT Return 769 code field are shown in the table below. 770

771

Value Return Code Response Description

0 0x00 Connection Accepted Connection accepted

1 0x01 Connection Refused, unacceptable protocol version

The server does not support the level of the MQTT protocol requested by the client

2 0x02 Connection Refused, identifier rejected The client identifier is correct UTF-8 but not allowed in the server

3 0x03 Connection Refused, server unavailable - the Network Connection has been made but the MQTT service is unavailable

4 0x04 Connection Refused, bad user name or password

The data in the user name or password is malformed

5 0x05 Connection Refused, not authorized The client is not authorized to connect

6-255 Reserved for future use

772

If none of these return codes are deemed applicable, then the server MUST disconnect the Network 773 Connection without flowing a CONNACK. 774

3.2.3 Payload 775

There is no payload in the CONNACK Packet. 776

777

3.3 PUBLISH – Publish message 778

A PUBLISH Control Packet is sent from a client to a server or from server to a client to transport a 779 Application Message. 780

Deleted: p

Deleted: TCP Connection




Deleted: 2

Deleted: 2




The table below shows the fixed header format: 782

783

Bit 7 6 5 4 3 2 1 0

byte 1 MQTT Control Packet type (3) Dup flag QoS level RETAIN

0 0 1 1 X X X X

byte 2 Remaining Length

784

Dup flag 785

See Dup section 1.1.1.1 for details. 786

787

QoS level 788

See QoS section 2.2.2.2 for details. 789

790

RETAIN flag 791

See Retain section 2.2.2.3 for details. 792

793


This is the length of variable header plus the length of the payload. 795

796


The variable header contains the following fields in the order below: 798

3.3.2.1 Topic name 799

The topic name is always present as the first field in the variable header. The topic name identifies the 800 information channel to which payload data is published. 801

802

The Topic name MUST be a UTF-8 encoded string as defined in section 2.1.2. 803

804

The topic name in the PUBLISH Packet received by a subscribing client MUST NOT contain wild card 805 characters. The topic name received will match the subscriber’s topic filter. However, since the server is 806 permitted to override the topic name, it might not be the same as the topic name in the original PUBLISH 807 Packet. 808

3.3.2.2 Packet Identifier 809

The Packet Identifier (PacketId) field is only present in PUBLISH Packets where the QoS level is 1 or 2. 810 See Packet Identifiers section 2.3.1 for more details. 811

812

3.3.2.3 Variable header example Non Normative 813

814

The table below illustrates an example of variable header for a PUBLISH Packet. 815

Deleted: 2.2.2.1

Deleted: p

Deleted: 2

Deleted: 2



816

Field Value

Topic Name a/b

PacketId 10

817

The format of the variable header in this case is shown in the table below. 818

819


Topic Name

byte 1 Length MSB (0) 0 0 0 0 0 0 0 0

byte 2 Length LSB (3) 0 0 0 0 0 0 1 1

byte 3 ‘a’ (0x61) 0 1 1 0 0 0 0 1

byte 4 ‘/’ (0x2F) 0 0 1 0 1 1 1 1

byte 5 ‘b’ (0x62) 0 1 1 0 0 0 1 0

Packet Identifier

byte 6 PacketId MSB (0) 0 0 0 0 0 0 0 0

byte 7 PacketId LSB (10) 0 0 0 0 1 0 1 0

820

3.3.3 Payload 821

The Payload contains the data for publishing. The content and format of the data is application specific. 822 The length of the payload can be calculated by subtracting the length of the variable header from the 823 Remaining Length field that is in the Fixed Header. It is valid for a PUBLISH Packet to contain a zero 824 length payload. 825

826

3.3.4 Response 827

The response to a PUBLISH Packet depends on the QoS level. The table below shows the expected 828 responses. 829

830

QoS Level Expected Response

QoS 0 None

QoS 1 PUBACK Packet

QoS 2 PUBREC Packet

The Packet Identifier in the PUBACK Packet or PUBREC Packet MUST be the same as that in the 831 PUBLISH Packet. 832

833

Deleted: p

Deleted: 2

Deleted: 2



3.3.5 Actions 834

The client uses a PUBLISH Packet to send an Application Message to the server for distribution to clients 835 with matching subscriptions. 836

837

The server uses a PUBLISH Packet to send an Application Message to clients with matching 838 subscriptions. 839

840

The action of the recipient when it receives a PUBLISH Packet depends on the QoS level as described in 841 section 4.3. 842

843

See MQTT issue-52 844

Note that if a server implementation does not authorize a PUBLISH to be performed by a client; it has no 845 way of informing that client. It must therefore make a positive acknowledgement, according to the normal 846 QoS rules, and the client will not be informed that it was not authorized to publish the message. 847

848

3.4 PUBACK – Publish acknowledgement 849

850

A PUBACK Packet is the response to a PUBLISH Packet with QoS level 1. 851


The table below shows the format of the fixed header. 853

854

Bit 7 6 5 4 3 2 1 0


0 1 0 0 0 0 0 0


0 0 0 0 0 0 1 0

855


This is the length of the variable header. For the PUBACK Packet this has the value 2. 857


859

Contains the Packet Identifier (PacketId) from the PUBLISH Packet that is being acknowledged. The 860 table below shows the format of the variable header. 861

862

Bit 7 6 5 4 3 2 1 0

byte 1 PacketId MSB

byte 2 PacketId LSB

863

Deleted: application message


Deleted: 4.2

Deleted: 2

Deleted: 2



3.4.3 Payload 864

There is no payload in the PUBACK Packet. 865

3.4.4 Actions 866

When the sender of a PUBLISH Packet receives a PUBACK Packet it discards the original message. 867

The action of the recipient is fully described in section 4.3. 868

869

3.5 PUBREC – Publish received (QoS 2 publish received, part 1) 870

871

A PUBREC Packet is the response to a PUBLISH Packet with QoS 2. It is the second packet of the QoS 872 2 protocol flow. 873



876

Bit 7 6 5 4 3 2 1 0


0 1 0 1 0 0 0 0


0 0 0 0 0 0 1 0

877


This is the length of the variable header. For the PUBREC Packet this has the value 2. 879

880


882

The variable header contains the Packet Identifier for the acknowledged PUBLISH Packet. The table 883 below shows the format of the variable header. 884

885

bit 7 6 5 4 3 2 1 0

byte 1 PacketId MSB

byte 2 PacketId LSB

886

3.5.3 Payload 887

There is no payload in the PUBREC Packet. 888

889

Deleted: 4.2

Deleted: Control

Deleted: 2

Deleted: 2



3.5.4 Actions 890

When the sender of a PUBLISH Packet receives a PUBREC Packet, it MUST reply with a PUBREL 891 Packet. 892

893


895

3.6 PUBREL – Publish release (QoS 2 publish received, part 2) 896

897

A PUBREL Packet is the response to a PUBREC Packet. It is the third packet of the QoS 2 protocol flow. 898



901

Bit 7 6 5 4 3 2 1 0

byte 1 MQTT Control Packet type (6) Dup flag Reserved

0 1 1 0 0 0 1 0


0 0 0 0 0 0 1 0

902

903

Dup flag 904

See Dup section 1.1.1.1 for details. 905

906

Bits 2,1 and 0 of the fixed header are reserved and must be set to 0,1 and 0 respectively. The server 907 MUST treat any other value as malformed and close the Network Connection. 908

909


This is the length of the variable header. For the PUBREL Packet this has the value 2. 911


The variable header contains the same Packet Identifier as the PUBREC Packet that is being 913 acknowledged. The table below shows the format of the variable header. 914

915

Bit 7 6 5 4 3 2 1 0

byte 1 PacketId MSB

byte 2 PacketId LSB

916

Deleted: 4.2

Deleted: Control

Deleted: 2.2.2.1


Deleted: 2

Deleted: 2



3.6.3 Payload 917

There is no payload in the PUBREL packet. 918

3.6.4 Actions 919

When the sender of a PUBREC Packet receives a PUBREL Packet it MUST reply with a PUBCOMP 920 Packet. 921

922


3.7 PUBCOMP – Publish complete (QoS 2 publish received, part 3) 924

925

The PUBCOMP Packet is the response to a PUBREL Packet. It is the fourth and final packet of the QoS 926 2 protocol flow. 927

928



931

Bit 7 6 5 4 3 2 1 0


0 1 1 1 0 0 0 0


0 0 0 0 0 0 1 0

932


This is the length of the variable header. For the PUBCOMP Packet this has the value 2. 934

935


The variable header contains the same Packet Identifier as the acknowledged PUBREL Packet. 937

938

Bit 7 6 5 4 3 2 1 0

byte 1 PacketId MSB

byte 2 PacketId LSB

939

3.7.3 Payload 940

There is no payload in the PUBCOMP Packet. 941

942

Deleted: 4.2

Deleted: Control

Deleted: 2

Deleted: 2



3.7.4 Actions 943

When the sender of a PUBREL receives a PUBCOMP Packet it removes any remaining state 944 associated with the original PUBLISH Packet. 945

946


3.8 SUBSCRIBE - Subscribe to topics 948

The SUBSCRIBE Packet is sent from the Client to the Server to register an interest in one or more 949 Topics. Application Messages that match the topic filter are delivered to the Client using a PUBLISH 950 Packet. The SUBSCRIBE Packet also specifies the maximum QoS with which the server sends 951 publications to the Client. 952

953



956

Bit 7 6 5 4 3 2 1 0


1 0 0 0 0 0 1 0


957

See MQTT Issue-27 958

Dup flag 959

Set to zero (0). This means that the packet is being sent for the first time. See DUP, section 960 1.1.1.1 for more details. 961

962


965


This is the length of variable header (2 bytes) plus the length of the payload. 967


The variable header contains a Packet Identifier. See section 2.3.1 for more details. 969

970

3.8.2.1 Variable Header Non Normative example 971

The table below shows an example of the variable header with a Packet Identifier of 10. 972

973


Packet Identifier

byte 1 Packet Identifier MSB (0) 0 0 0 0 0 0 0 0

Deleted: 4.2

Deleted: Control


Deleted: Control

Deleted: p

Deleted: 2.2.2.1


Deleted: 2

Deleted: 2



byte 2 Packet Identifier LSB (10) 0 0 0 0 1 0 1 0

974

3.8.3 Payload 975

The payload of a SUBSCRIBE Packet contains a list of topic filters to which the Client wants to subscribe. 976 The topic filters are UTF-8 encoded strings. Each filter is followed by a byte giving the maximum QoS 977 level at which the Server sends publications to the Client 978

979

Topic filters MAY contain special wildcard characters to represent a set of topics, see section 4.6.1. 980 These topic filter / QoS pairs are packed contiguously as shown in the example payload in the table 981 below. 982

983

The requested maximum QoS field is encoded in the byte following each UTF-8 encoded topic name as 984 shown in the table below. 985

986


Topic filter

byte 1 Length MSB

byte 2 Length LSB

byte 3-N Topic filter

Requested QoS

Reserved QoS

byte N+1 0 0 0 0 0 0 X X

987

The upper 6 bits of this byte are not used in the current version of the protocol. They are reserved for 988 future use. 989

990

3.8.3.1 Payload Non Normative Example 991

Topic name “a/b”

Requested QoS 0x01

Topic name “c/d”

Requested QoS 0x02

992

The format of the example payload is shown in the table below. 993

994


Topic filter

byte 1 Length MSB (0) 0 0 0 0 0 0 0 0

Deleted: 4.5.1

Deleted: 2

Deleted: 2



byte 2 Length MSB (3) 0 0 0 0 0 0 1 1

byte 3 ‘a’ (0x61) 0 1 1 0 0 0 0 1

byte 4 ‘/’ (0x2F) 0 0 1 0 1 1 1 1

byte 5 ‘b’ (0x62) 0 1 1 0 0 0 1 0

Requested QoS

byte 6 Requested QoS(1) 0 0 0 0 0 0 0 1

Topic filter

byte 7 Length MSB (0) 0 0 0 0 0 0 0 0

byte 8 Length MSB (3) 0 0 0 0 0 0 1 1

byte 9 ‘c’ (0x63) 0 1 1 0 0 0 1 1

byte 10 ‘/’ (0x2F) 0 0 1 0 1 1 1 1

byte 11 ‘d’ (0x64) 0 1 1 0 0 1 0 0

Requested QoS

byte 12 Requested QoS(2) 0 0 0 0 0 0 1 0

995

3.8.4 Response 996

See MQTT Issues 52,58,59,60. Processing of subscribe requests, sending retained publications, storing 997 subscriptions, starting the flow of publications. 998

999

1000

When the Server receives a SUBSCRIBE Packet from a Client, the Server MUST respond with a 1001 SUBACK Packet. The SUBACK Packet MUST have the same Packet Identifier as the SUBSCRIBE 1002 Packet. 1003

1004

The Server MAY start sending PUBLISH packets matching the subscription before the Server sends the 1005 SUBACK Packet. 1006

1007


Note that if a server implementation does not authorize a SUBSCRIBE request to be made by a 1009 subscriber, it has no way of informing that subscriber. It MUST therefore make a positive 1010 acknowledgement with a SUBACK, and the subscriber will not be informed that it was not authorized to 1011 subscribe. 1012

1013

The SUBACK Packet sent to the Client by the Server contains the maximum QoS for each Topic Filter 1014 that the Server will use. The Server might grant a lower level of QoS than the subscriber requested. 1015

1016

The QoS of Application Messages sent in response to a subscription MUST be the minimum of the 1017 published message and the granted QoS returned by the Server to the Client. 1018

1019



Deleted: 2

Deleted: 2



For example, if a subscriber has requested QoS 1 for a particular topic filter, then a QoS 0 Message 1021 matching the filter is delivered to the Client at QoS 0. A QoS 2 Message published to the same topic is 1022 downgraded by the Server to QoS 1 for delivery to the Client. 1023

1024


A corollary to this is that subscribing to a topic filter at QoS 2 is equivalent to saying "I would like to 1026 receive Messages matching this filter at the QoS with which they were published". This means a publisher 1027 is responsible for determining the maximum QoS a Message can be delivered at, but a subscriber is able 1028 to require that the Server downgrades the QoS to one more suitable for its usage. 1029

1030

3.9 SUBACK – Subscription acknowledgement 1031

1032

A SUBACK Packet is sent by the Server to the Client, to confirm receipt and processing of a SUBSCRIBE 1033 Packet. 1034

1035

A SUBACK Packet contains a list of granted QoS levels. 1036


The table below shows the fixed header format. 1038

1039

Bit 7 6 5 4 3 2 1 0


1 0 0 1 0 0 0 0


1040




The variable header contains the Packet Identifier from the SUBSCRIBE Packet that is being 1044 acknowledged. The table below shows the format of the variable header. 1045

1046

7 6 5 4 3 2 1 0

byte 1 Packet Identifier MSB

byte 2 Packet Identifier LSB

3.9.3 Payload 1047

The payload contains a list of granted QoS levels. Each QoS level corresponds to a topic filter in the 1048 SUBSCRIBE Packet being acknowledged. The order of granted QoS levels in the SUBACK Packet 1049 MUST match the order of topic filters in the SUBSCRIBE Packet. 1050

1051

The table below shows the Granted QoS field encoded in a byte. 1052

Deleted: Control

Deleted: p

Deleted: 2

Deleted: 2



1053


Reserved Granted QoS

byte 1 0 0 0 0 0 0 X X

1054

The upper 6 bits of this byte are not used in the current version of the protocol. They are reserved for 1055 future use. 1056

1057

3.9.3.1 Payload Non Normative Example 1058

1059

Granted QoS 0

Granted QoS 2

1060

The payload for this example is shown in the table below. 1061

1062


byte 1 Granted QoS (0) 0 0 0 0 0 0 0 0

byte 2 Granted QoS (2) 0 0 0 0 0 0 1 0

3.10 UNSUBSCRIBE – Unsubscribe from topics 1063

See MQTT Issue-60,64 1064

An UNSUBSCRIBE Packet is sent by the Client to the Server, to unsubscribe from topics. 1065

1066


The table below shows an example fixed header format. 1068

1069

Bit 7 6 5 4 3 2 1 0


1 0 1 0 0 0 1 0



Dup flag 1071

Set to zero (0). This means that the packet is being sent for the first time. See Dup section 2.2.2.1 1072 for more details. 1073

1074



Deleted: 2

Deleted: 2



1077




The variable header contains a Packet Identifier. See section 2.3.1 for more details. 1081

1082

The table below shows the format of the variable header. 1083

1084

7 6 5 4 3 2 1 0



1085

3.10.2.1 Payload 1086

The payload for the UNSUBSCRIBE Packet contains the list of topic filters that the Client wishes to 1087 unsubscribe from. The topic filters are UTF-8 string, packed contiguously. 1088

1089

1090

3.10.2.2 Payload Non Normative example 1091

The table below shows an example payload. 1092

1093

Topic filter “a/b”

Topic filter “c/d”

1094

The table below shows the format of this payload. 1095

1096


Topic Filter

byte 1 Length MSB (0) 0 0 0 0 0 0 0 0

byte 2 Length MSB (3) 0 0 0 0 0 0 1 1

byte 3 ‘a’ (0x61) 0 1 1 0 0 0 0 1

byte 4 ‘/’ (0x2F) 0 0 1 0 1 1 1 1

byte 5 ‘b’ (0x62) 0 1 1 0 0 0 1 0

Topic Filter

byte 6 Length MSB (0) 0 0 0 0 0 0 0 0

byte 7 Length MSB (3) 0 0 0 0 0 0 1 1

Deleted: 2

Deleted: 2



byte 8 ‘c’ (0x63) 0 1 1 0 0 0 1 1

byte 9 ‘/’ (0x2F) 0 0 1 0 1 1 1 1

byte 10 ‘d’ (0x64) 0 1 1 0 0 1 0 0

3.10.3 Response 1097

The Server sends an UNSUBACK Packet to the Client in response to an UNSUBSCRIBE Packet. The 1098 UNSUBACK Packet MUST have the same Packet Identifier as the UNSUBSCRIBE Packet. 1099

1100

The Topic Filter (whether containing a wild-card or not) supplied in an unsubscribe MUST be compared 1101 byte-for-byte with the current set of Topic Filters held by the Server for the Client. If any filter matches 1102 exactly then it is deleted, otherwise no additional processing occurs. 1103 1104 Even where no Topic Filters are deleted, the server MUST respond with an UNSUBACK. 1105

3.11 UNSUBACK – Unsubscribe acknowledgement 1106

1107

The UNSUBACK Packet is sent by the Server to the Client to confirm receipt and processing of an 1108 UNSUBSCRIBE Packet. 1109



1112

Bit 7 6 5 4 3 2 1 0


1 0 1 1 0 0 0 0


0 0 0 0 0 0 1 0


This is the length of the variable header. For the UNSUBACK Packet this has the value 2. 1114


The variable header contains the Packet Identifier of the UNSUBSCRIBE Packet that is being 1116 acknowledged. The table below shows the format of the variable header. 1117

1118

7 6 5 4 3 2 1 0



1119

3.11.3 Payload 1120

There is no payload. 1121

Formatted: Heading 3,H3,

Indent: Hanging: 2.38 cm

Deleted: ¶See MQTT Issue-64.

Deleted: ¶

Deleted: p

Deleted: 2

Deleted: 2



1122

3.12 PINGREQ – PING request 1123

1124

The PINGREQ Packet is sent from a Client to the Server. It can be used to: 1125

1. Indicate to the Server that the Client is alive in the absence of any other Control Packets flowing 1126 from the Client to the Server. 1127

2. Request that the Server responds to confirm that it is alive. 1128

3. Exercise the network to indicate that the Network Connection is active. 1129

1130

This Packet is used in Keep Alive processing, see section 3.1.2.4 for more details. 1131

1132



1135

Bit 7 6 5 4 3 2 1 0


1 1 0 0 0 0 0 0


0 0 0 0 0 0 0 0

1136


There is no variable header. 1138

3.12.3 Payload 1139



See MQTT Ussue-54. 1142

The Server MUST send a PINGRESP Packet in response to a PINGREQ packet. 1143

1144

3.13 PINGRESP – PING response 1145

1146

A PINGRESP Packet is sent by the Server to the Client in response to a PINGREQ Packet, it indicates 1147 that the server is alive. 1148

1149

This Packet is used in Keep Alive processing, see 3.1.2.4 for more details. 1150

1151


Deleted: 2

Deleted: 2





1154

Bit 7 6 5 4 3 2 1 0


1 1 0 1 0 0 0 0


0 0 0 0 0 0 0 0

1155



3.13.3 Payload 1158


1160

3.14 DISCONNECT – Disconnect notification 1161

1162

The DISCONNECT Packet is the final Control Packet sent from the Client to the Server. It indicates that 1163 the Client is disconnecting cleanly. 1164



1167

Bit 7 6 5 4 3 2 1 0


1 1 1 0 0 0 0 0


0 0 0 0 0 0 0 0

The server MUST validate that reserved bits are set to zero and disconnect the client if they are not zero. 1168



3.14.3 Payload 1171



After sending a DISCONNECT Packet the Client: 1174

Deleted: 2

Deleted: 2



• MUST close the Network Connection. 1175

• MUST NOT send any more Control Packets on that Network Connection. 1176

1177

On receipt of DISCONNECT the Server: 1178

• MUST discard the Will Message without publishing it, see 3.1.2.3.2. 1179

• SHOULD close the Network Connection if the client has not already done so. 1180




Deleted: 2

Deleted: 2



4 Operational behaviour 1181

4.1 Storing state 1182

The client and server implement data storage independently and the duration for which data persists can 1183 be different in each. The Client and Server MUST store data for at least as long as the Network 1184 Connection lasts. Quality of Service guarantees are only valid so long as both client and server store 1185 data. Durable subscriptions and retained publications only survive as long as the Server stores them. 1186

1187


An MQTT user should evaluate the storage capabilities of the MQTT Client and Server implementations 1189 to ensure that they are sufficient for their needs. 1190

1191

For example, a user wishing to gather electricity meter readings may decide that they need to use QoS 1 1192 messages because they need to protect the readings against loss over the network, however they may 1193 decide that the power supply is sufficiently reliable that the data in the Client and Server can be stored in 1194 volatile memory without too much risk of its loss. 1195

1196

Conversely a parking meter payment application provider might decide that there are no circumstances 1197 where a payment message can be lost so they require that all data are force written to non-volatile 1198 memory before it is transmitted across the network. 1199

4.2 Network Connections 1200

The network connection used to transport the MQTT protocol MUST be an ordered, lossless, stream of 1201 bytes from the client to server and server to client. 1202

1203


The initial transport protocol used to carry MQTT was TCP/IP as defined in The following are also 1205 suitable: 1206

• TLS [RFC6455] 1207

• WebSockets [RFC5246] 1208

1209

Connectionless network transports such as User Datagram Protocol (UDP) are not suitable on their own 1210 because they might loose or reorder data. 1211

1212

4.3 Quality of Service levels and flows 1213

1214

MQTT delivers Application Messages according to the Quality of Service (QoS) levels defined here. The 1215 delivery protocol is symmetric, in the diagrams below the Client and Server can each take the role of 1216 either Sender or Receiver. In the case of the Client, “Deliver Application Message” means give the 1217 message to the application. In the case of the Server it means send a copy of the Message to each Client 1218 with a matching subscription. 1219

Formatted: Heading 2,H2

Formatted: Font: Bold


Numbering


Font

Formatted: Font: Not Bold




Numbering











Deleted: 2

Deleted: 2



4.3.1 QoS 0: At most once delivery 1220

The message is delivered according to the capabilities of the underlying network. No response is sent by 1221 the receiver and no retry is performed by the sender. The message arrives at the receiver either once or 1222 not at all. 1223

1224

The diagram below shows the QoS 0 protocol flow. 1225

1226

Sender Action Control Packet Receiver Action

PUBLISH QoS 0

---------->

Deliver Application Message

4.3.2 QoS 1: At least once delivery 1227

The receiver of a QoS 1 PUBLISH Packet acknowledges receipt with a PUBACK Packet. If the Client 1228 reconnects and the Session is resumed, the sender MUST resend any in flight Qos 1 messages with the 1229 Dup flag set to 1. 1230

1231

See MQTT Issue-68. 1232

or the acknowledgement message is not received after a specified period of time, 1233

1234

The message arrives at the receiver at least once. 1235

1236

A QoS 1 message has a Packet Identifier in its variable header see section 2.3.1. 1237

1238

The diagram below shows the QoS 1 protocol flow. 1239

1240

Sender Action Control Packet Receiver action

Store message

Send PUBLISH QoS 1, Dup 0, <Packet Identifier>

---------->

Initiate onward delivery of the Application Message

1

<---------- Send PUBACK <Packet Identifier>

Discard message

1241

1 The receiver is not required to complete delivery of the Application Message before sending the 1242

PUBACK. On receipt, ownership of the Application Message is transferred to the Server. The Server 1243 MUST store the message in accordance to its QoS properties and ensure onward delivery to applicable 1244 subscribers. 1245

1246

Deleted: 2

Deleted: 2



Numbering


Numbering



When it receives a PUBLISH Packet with Dup set to 1 the receiver MUST perform the same actions as 1248 above which might result in a redelivery of the Application Message. 1249

1250

4.3.3 QoS 2: Exactly once delivery 1251

This is the highest quality of service, for use when neither loss nor duplication of messages are 1252 acceptable. There is an increased overhead associated with this quality of service. 1253

A QoS 2 message has a Packet Identifier in its variable header see section 2.3.1. 1254

1255

The diagram below shows the QoS 2 protocol flow. There are two semantics available for how this flow 1256 should be handled by the receiver. They affect the point within the flow at which the message is made 1257 available for onward delivery. The choice of semantic is implementation specific and does not affect the 1258 guarantees of a QoS 2 flow. 1259

1260

1261

Sender Action Control Packet Receiver Action

Store message

PUBLISH QoS 2 <Packet Identifier>

Dup 0

---------->

Store message

or

Store <Packet Identifier> then Initiate onward delivery of the Application Message

1

PUBREC <Packet Identifier>

<----------

Discard message, Store PUBREC received <Packet Identifier>

PUBREL <Packet Identifier>

---------->

Initiate onward delivery of the Application Message

1 then discard

message

or

Discard <Packet Identifier>

Send PUBCOMP <Packet Identifier>

<----------

Discard stored state

1262

Deleted: 2

Deleted: 2



Numbering


1 The receiver is not required to complete delivery of the Application Message before sending the 1263

PUBREC or PUBCOMP. On receipt, ownership of the Application Message is transferred to the Server. 1264 The Server MUST store the message in accordance to its QoS properties and ensure onward delivery to 1265 applicable subscribers.

1266

1267

When a Client reconnects with CleanSession = 0, both the client and server MUST redeliver any 1268 previous in-flight messages. This means re-sending any unacknowledged PUBLISH Packets (where QoS 1269 > 0) and PUBREL Packets. This is the only circumstance where a Client or Server is REQUIRED to 1270 redeliver messages. Clients MAY resend SUBSCRIBE and UNSUBSCRIBE Packets on reconnect but 1271 are not REQUIRED to do this. 1272

1273 While a modern TCP network is unlikely to lose packets, a Client or Server is permitted to attempt 1274 redelivery at other times. However, redelivery is not encouraged unless a network failure has been 1275 detected. 1276 1277 Non-normative comment 1278 1279 Historically retransmission of Control Packets was required to overcome data loss on some older TCP 1280 networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such 1281 environments. 1282

1283

See Issue MQTT-70 1284

4.4 Message delivery retry 1285

In any network, it is possible for devices or communication links to fail. If this happens, one end of the link 1286 might not know what is happening at the other end; these are known as in doubt windows. In these 1287 scenarios assumptions have to be made about the reliability of the devices and networks involved in 1288 message delivery. 1289

1290

When a Client reconnects, if it is not marked clean session, both the client and server MUST redeliver any 1291 previous in-flight messages. 1292

1293


1295

Although TCP normally guarantees delivery of packets, there are certain scenarios where an MQTT 1296 message may not be received. In the case of MQTT messages that expect a response (QoS >0 1297 PUBLISH, PUBREL, SUBSCRIBE, UNSUBSCRIBE), if the response is not received within a certain time 1298 period, the sender may retry delivery. The sender should set the Dup flag on the message. 1299

1300

The retry timeout should be a configurable option. However care must be taken to ensure message 1301 delivery does not timeout while it is still being sent. For example, sending a large message over a slow 1302 network will naturally take longer than a small message over a fast network. Repeatedly retrying a timed-1303 out message could often make matters worse so a strategy of increasing the timeout value across 1304 multiple retries should be used. 1305

1306

Other than this "on reconnect" retry behavior, clients are not required to retry message delivery. Brokers, 1307 however, should retry any unacknowledged message. 1308

1309












Formatted

Formatted

Formatted

Formatted

Formatted




Formatted



Formatted

Formatted

Formatted

Formatted

Formatted

Formatted


Numbering



Formatted

Formatted

Formatted

Formatted

Deleted: ¶See MQTT Issue-68¶If a failure is detected, or after a defined time period, the protocol flow is retried from the last unacknowledged protocol message; either the PUBLISH or PUBREL. See Message delivery retry for more details. The additional protocol flows ensure that the message is delivered to subscribers once only.

Deleted: 2

Deleted: 2


... [4]

... [5]

... [10]

... [6]

... [9]

... [7]

... [12]

... [8]

... [13]

... [18]

... [14]

... [19]

... [15]

... [20]

... [16]

... [11]

... [17]


4.5 Message ordering 1310


Application Messages from a single Client or Server are delivered in order as long as they have the same 1312 QoS and the same Topic Name. The Client or Server MUST respond in the same order that it receives 1313 the inbound Control Packets for Application Messages with identical Topic Names and Qos. 1314

1315


Message ordering can be affected by a number of factors, including how many in-flight PUBLISH Packet 1317 flows a client allows and whether the client is single or multi-threaded. For purposes of discussion, clients 1318 are assumed to be single-threaded at the point Control Packets are written to and read from the network. 1319

1320

For an implementation to provide any guarantees regarding the ordering of messages it must ensure 1321 each stage of the message delivery flows are completed in the order they were started. For example, in a 1322 series of QoS level 2 flows, the PUBREL Packet flows must be sent in the same order as the original 1323 PUBLISH Packet flows: 1324

1325

1326

Client Direction Server

PUBLISH 1 ---------->

PUBLISH 2 ---------->

PUBLISH 3 ---------->

<---------- PUBREC 1

<---------- PUBREC 2

PUBREL 1 ---------->

<---------- PUBREC 3

PUBREL 2 ---------->

<---------- PUBCOMP 1

PUBREL 3 ---------->

<---------- PUBCOMP 2

<---------- PUBCOMP 3

1327

The number of in-flight messages permitted also has an effect on the type of guarantees that can be 1328 made: 1329

• Where a single message is in-flight and each delivery flow is completed before the next one 1330 starts. This means that messages are carried between the Client and Server in order. 1331

• Where more than one message is in flight, message ordering can only be achieved within the 1332 QoS level. 1333

1334


Numbering


Deleted: -

Deleted: p

Deleted: Message and d

Deleted: are

Deleted: -

Deleted: 2

Deleted: 2



4.6 Topic Names and Topic Filters 1335

4.6.1 Topic wildcards 1336

A subscription may contain special characters, which allow you to subscribe to multiple topics at once. 1337

1338

The topic level separator is used to introduce structure into the topic, and can therefore be specified 1339 within the topic for that purpose. The multi-level wildcard character and single-level wildcard character 1340 can be used for subscriptions. Wildcard characters MUST NOT be used within a topic name of a 1341 PUBLISH Packet. 1342

4.6.1.1 Topic level separator 1343

The forward slash ('/' 0x2F) is used to separate each level within a topic tree and provide a 1344 hierarchical structure to the topic names. The use of the topic level separator is significant when 1345 either of the two wildcard characters are encountered in topic filters specified by subscribing 1346 Clients. Topic level separators may appear anywhere in a Topic Filter or Topic Name. Adjacent 1347 Topic level separators indicate a zero length topic level. Topic names and topic filters are used 1348 in their literal form. 1349

4.6.1.2 Multi-level wildcard 1350

The number sign (‘#’ 0x23) is a wildcard character that matches any number of levels within a topic. 1351

The multi-level wildcard represents the parent and any number of child levels. The multi-level wildcard 1352 character MUST be specified on its own or following a topic level separator, in either case it MUST be the 1353 last character specified in the topic filter. 1354

1355


For example, if a Client subscribes to “sport/tennis/player1/#”, it receives messages published using 1357 these topic names: 1358

1359 “sport/tennis/player1” 1360 “sport/tennis/player1/ranking” 1361 “sport/tennis/player1/score/wimbledon” 1362 1363 1364


1366

• “sport/#” also matches the singular sport, since # includes the parent level. 1367

• “#” is valid and will receive every publication 1368

• “sport/tennis/#” is valid 1369

• “sport/tennis#” is not valid 1370

• “sport/tennis/#/ranking” is not valid 1371

1372

4.6.1.3 Single level wildcard 1373

The plus sign (‘+’ 0x2B) is a wildcard character that matches only one topic level. 1374

1375




Numbering


Numbering


Numbering


Numbering

Deleted: The forward slash (‘/’ 0x2F) is used to separate each level within a topic tree and provide a hierarchical structure to the topic names. The use of the topic level separator is significant when either of the two wildcard characters are encountered in topic filters specified by subscribing Clients.

Deleted: nadal

Deleted: nadalDeleted: nadalDeleted: nadal

Deleted: 2

Deleted: 2



The single-level wildcard can be used at any level in the topic filter, including first and last levels. Where it 1376 is used it MUST occupy an entire level of the filter. It can be used at more than one level in the topic filter 1377 and can be used in conjunction with the multilevel wildcard. 1378

1379


For example, sport/tennis/+ matches sport/tennis/player1 and sport/tennis/player2, but not 1381 sport/tennis/player1/ranking. Also, because the single-level wildcard matches only a single level, sport/+ 1382 does not match sport. 1383

1384


• “+” is valid 1386

• “+/tennis/#” is valid 1387

• “sport+” is not valid 1388

• “sport/+/player1” is valid 1389

• “/finance” matches "+/+" and "/+", but not "+" 1390

4.6.2 Topics beginning with $ 1391

1392

MQTT server implementations MAY define topic names that start with a leading $ character 1393

1394


1396

• $SYS/ has been widely adopted as a prefix to topics that contain server-specific information or 1397 control APIs 1398

• Applications cannot use a topic with a leading $ character for their own purpose 1399

1400

1401

4.6.2.1 Subscription handling 1402

1403

A topic filter that starts with a wildcard character (# or +) does not match topic names that begin with a $ 1404 character 1405

1406


1408

• A subscription to # will not receive any messages published to a topic beginning with a $ 1409

• A subscription to +/monitor/clients will not receive any messages published to 1410 $SYS/monitor/clients 1411

• A subscription to $SYS/# will receive messages published to topics beginning with $SYS/ 1412

• A subscription to $SYS/monitor/+ will receive messages published to $SYS/monitor/clients 1413

• For a client to receive messages from topics that begin with $SYS/ and from topics that don't 1414 begin with a $, it must subscribe to both # and $SYS/# 1415

1416




Numbering


Numbering



Deleted: The single-level wildcard can be used at any level in the topic filter. It can be used in conjunction with the multilevel wildcard. ¶It MUST be the only character between two topic level separators, or the last level, or on its own. ¶

Deleted: nadal

Deleted: murray

Deleted: nadal

Deleted: sport/+

Deleted: nadal

Deleted: 2

Deleted: 2



4.6.3 Topic semantic and usage 1417

1418

The following rules apply to topic names and topic filters 1419


1421

• A topic names and topic filters MUST be at least one character long 1422

• Topic names and topic filters are case sensitive 1423

• Topic names and topic filters can include the space character 1424

• A leading "/" creates a distinct topic name or topic filter 1425

• Topic names and topic filters MUST NOT include the null character (Unicode \x0000) 1426

• Topic names and topic filters are UTF-8 encoded strings, they MUST NOT encode to more than 1427 65535 bytes. Refer section 2.1.2 1428

• There is no limit to the number of levels in a topic name or topic filter 1429

1430


• “ACCOUNTS” and “Accounts” are two different topic names 1432

• “Accounts payable” is a valid topic name 1433

• “/finance” is different from “finance” 1434

1435


1437

A publication is sent to each client subscription that matches the topic name in the publication. The topic 1438 resource may be either predefined in the server by an administrator or it may be dynamically created by 1439 the server when it receives the first subscription or publication with that topic name. The server may also 1440 use a security component to selectively authorize actions on the topic resource for a given client. 1441

4.7 Handling protocol violations 1442

See MQTT Issue-8,6,50 etc 1443

Deleted: 2

Deleted: 2



Numbering


Numbering


5 Security 1444

1445

The recommendations contained in this section are provided for guidance only and are not intended to 1446 serve as a complete reference on the subject. 1447

1448

There are a number of threats that solution providers should consider. For example: 1449

1450

• Devices may be compromised 1451

• Data at rest in Clients and Servers may be accessible 1452

• Protocol behaviours may have side effects (e.g., 'timing attacks') 1453

• Denial of Service (DoS) attacks 1454

• Communications may be intercepted, altered, re-routed or disclosed 1455

• Injection of spoofed Control Packets 1456

1457

MQTT solutions are often deployed in hostile communication environments. In such cases, 1458 implementations will often need to provide mechanisms for: 1459

1460

• Authentication of users and devices 1461

• Authorisation of access to server resources 1462

• Integrity of MQTT Control Packets and application data contained therein 1463

• Privacy of MQTT Control Packets and application data contained therein 1464

1465

As a transport protocol, MQTT is concerned only with message transmission and it is the implementors' 1466 responsibility to provide appropriate security features. This is commonly achieved by using TLS. 1467

1468

Server implementations that offer TLS SHOULD use TCP port 8883 [IANA service name: secure-mqtt]. 1469

1470

In addition to technical security issues there may also be geographic (e.g., European SafeHarbour), 1471 industry specific (e.g., PCI DSS) and regulatory considerations (e.g., Sarbannes-Oxley). 1472

1473

The remainder of this section is non-normative. 1474

1475

5.1 MQTT solutions: security and certification 1476

1477

An implementation may want to provide conformance with specific industry security standards such as 1478 NIST Cyber Security Framework, PCI-DSS, FIPS-140-2 and NSA Suite B. 1479

1480

The use of industry proven, independently verified and certified technologies will help meet compliance 1481 requirements. 1482

1483

Deleted: 2

Deleted: 2



5.2 Lightweight cryptography and constrained devices 1484

1485

Advanced Encryption Standard (AES) and Data Encryption Standard (DES) are widely adopted 1486

1487

ISO 29192 makes recommendations for cryptographic primitives specifically tuned to perform on 1488 constrained 'low end' devices. 1489

1490

5.3 Implementation notes 1491

1492

There are many security concerns to consider when implementing or using MQTT. The following section 1493 should not be considered a “check list”. 1494

1495

An implementation might want to achieve some, or all, of the following: 1496

1497

5.3.1 Authentication of Clients by the Server 1498

1499

The CONNECT Packet contains Username and Password fields. Implementations can choose how to 1500 make use of the content of these fields. They may provide their own authentication mechanism, use an 1501 external authentication system such as LDAP or Oauth tokens, or leverage operating system 1502 authentication mechanisms. 1503

1504

Implementations passing authentication data in clear text, obfuscating such data elements or requiring no 1505 authentication data should be aware this may give rise to Man-in-the-Middle and replay attacks. Section 1506 5.4.5 introduces approaches to ensure data privacy. 1507

1508

A Virtual Private Network (VPN) between the Clients and Servers can provide confidence that data is only 1509 being received from authorised Clients. 1510

1511

Where TLS is used, SSL Certificates flowed from the Client can be used by the Server to authenticate the 1512 Client. 1513

1514

An implementation might allow for authentication where the credentials are flowed in an Application 1515 Message from the Client to the Server. 1516

1517

5.3.2 Authorisation of Clients by the Server 1518

1519

An implementation may restrict access to Server resources based on information provided by the Client 1520 such as Username, ClientID, the hostname/IP address of the Client, or the outcome of authentication 1521 mechanisms. 1522

1523

1524 Deleted: 2

Deleted: 2



5.3.3 Authentication of the Server by the Client 1525

1526

The MQTT protocol is not trust symmetrical: it provides no mechanism for the client to authenticate the 1527 server. 1528

1529

Where TLS is used, SSL Certificates flowed from the Server can be used by the Client to authenticate the 1530 Server. Implementations providing MQTT service for multiple hostnames from a single IP address should 1531 be aware of the Server Name Indication extension to TLS [https://tools.ietf.org/html/rfc3546#section-3.1]. 1532 This allows a Client to tell the Server the hostname of the Server it is trying to connect to. 1533

1534

An implementation may allow for authentication where the credentials are flowed in an Application 1535 Message from the Server to the Client. 1536

1537

A VPN between Clients and Servers can provide confidence that Clients are connecting to the intended 1538 Server. 1539

1540

5.3.4 Integrity of Application Messages and Control Packets 1541

1542

Applications can independently include hash values in their Application Messages. This can provide 1543 integrity of the contents of Publish Control Packets across the network and at rest. 1544

1545

TLS provides hash algorithms to verify the integrity of data sent over the network. 1546

1547

The use of VPNs to connect Clients and Servers can provide integrity of data across the section of the 1548 network covered by a VPN. 1549

1550

5.3.5 Privacy of Application Messages and Control Packets 1551

1552

TLS can provide encryption of data sent over the network. There are valid TLS cipher suites that include 1553 a NULL encryption algorithm that does not encrypt data. To ensure privacy Clients and Servers should 1554 avoid these cipher suites. 1555

1556

An application may independently encrypt the contents of its Application Messages. This could provide 1557 privacy of the Application Message both over the network and at rest. This would not provide privacy for 1558 other properties of the Application Message such as Topic Name. 1559

1560

Client and Server implementations may provide encrypted storage for data at rest such as Application 1561 Messages stored as part of a Session. 1562

1563

The use of VPNs to connect Clients and Servers can provide privacy of data across the section of the 1564 network covered by a VPN. 1565

1566


Deleted: 2

Deleted: 2



5.3.6 Non-repudiation of message transmission 1567

1568

Application designers might need to consider appropriate strategies to achieve end to end non-1569 repudiation. 1570

1571

5.3.7 Detecting compromise of Clients and Servers 1572

1573

Client and Server implementations using TLS should provide capabilities to ensure that any SSL 1574 certificates provided when initiating a TLS connection are associated with the hostname of the Client 1575 connecting or Server being connected to. 1576

1577

Client and Server implementations using TLS may choose to provide capabilities to check Certificate 1578 Revocation Lists (CRLs) and Online Certificate Status Protocol (OSCP) to prevent revoked certificates 1579 from being used. 1580

1581

Physical deployments might combine tamper-proof hardware with the transmission of specific data in 1582 Application Messages. For example a meter might have an embedded GPS to ensure it is not used in an 1583 unauthorised location. IEEE 802.1AR is a standard for implementing mechanisms to authenticate a 1584 device's identity using a cryptographically bound identifier. 1585

1586

5.3.8 Detecting abnormal behaviours 1587

1588

Server implementations might monitor client behaviour to detect potential security incidents. For example: 1589

1590

• Repeated connection attempts 1591

• Repeated authentication attempts 1592

• Abnormal termination of connections 1593

• Topic scanning (attempts to send or subscribe to many topics) 1594

• Sending undeliverable messages (no subscribers to the topics) 1595

• Clients that connect but do not send data 1596

1597

Server implementations might disconnect clients that breach its security rules. 1598

1599

Server implementations detecting unwelcome behaviour might implement a dynamic block list based on 1600 identifiers such as IP address or Client ID. 1601

1602

Deployments might use network level controls (where available) to implement rate limiting or blocking 1603 based on IP address or other information. 1604

1605

1606

1607 Deleted: 2

Deleted: 2



5.3.9 Other security considerations 1608

1609

If Client or Server SSL certificates are lost or it is considered that they might be compromised they should 1610 be revoked (utilising CRLs and/or OSCP). 1611

1612

Client or Server authentication credentials, such as Username and Password, that are lost or considered 1613 compromised should be revoked and/or reissued. 1614

1615

In the case of long lasting connections (such as meters): 1616

1617

• Client and Server implementations using TLS should allow for session renegotiation to establish 1618 new cryptographic parameters (replace session keys, change cipher suites, change 1619 authentication credentials). 1620

• Servers may disconnect clients and require them to re-authenticate with new credentials. 1621

1622

Constrained devices and clients on constrained networks can make use of TLS session resumption to 1623 reduce the costs of reconnecting TLS sessions. 1624

1625

Clients connected to a Server have an transitive trust relationship with other Clients connected to the 1626 same Server and who have authority to publish data on the same topics. 1627

1628

5.3.10 Use of SOCKS 1629

1630

Implementations of clients should be aware that some environments will require the use of SOCKSv5 1631 [http://www.ietf.org/rfc/rfc1928.txt] proxies to make outbound Network Connections. Some MQTT 1632 implementations may make use of alternative secured tunnels (e.g. SSH) through the use of SOCKS. 1633 Where implementations choose to use SOCKS, they should support both anonymous and user-name 1634 password authenticating SOCKS proxies. In the latter case, implementations should be aware that 1635 SOCKS authentication may occur in plain-text and so should avoid using the same credentials for 1636 connection to a MQTT server. 1637

1638

5.3.11 Security profiles 1639

1640

Implementors and solution designers may wish to consider security as a set of profiles which can be 1641 applied to the MQTT protocol. An example of a layered security hierarchy is presented below. 1642

1643

5.3.11.1 Clear communication profile 1644

1645

MQTT protocol running over an open network with no additional secure communication mechanisms in 1646 place. 1647

1648

1649

1650


Deleted: 2

Deleted: 2



5.3.11.2 Secured network communication profile 1651

1652

MQTT protocol running over a physical or virtual network which has security controls e.g., VPNs or 1653 physically secure network. 1654

1655

5.3.11.3 Secured transport profile 1656

1657

MQTT protocol running over a physical or virtual network and using TLS which provides authentication, 1658 integrity and privacy. 1659

1660

TLS Client authentication may be used in addition to – or in place of – MQTT Client authentication as 1661 provided by the Username and Password fields. 1662

1663

5.3.11.4 Industry specific security profile 1664

1665

It is anticipated that the MQTT protocol will be designed into industry specific application profiles, each 1666 defining a threat model and the specific security mechanisms to be used to address these threats. 1667 Recommendations for specific security mechanisms will often be taken from existing works including: 1668

1669

NIST Cyber Security Framework 1670

NISTIR 7628 Guidelines for Smart Grid Cyber Security 1671

Federal Information Processing Standards (FIPS-140-2) 1672

PCI-DSS 1673

NSA Suite B 1674

1675

An MQTT supplemental publication: MQTT security standards will provide further information related to 1676 the usage of various industry security frameworks and standards. 1677

Deleted: 2

Deleted: 2



6 Conformance 1678

1679

The MQTT specification defines conformance for MQTT Client implementations and MQTT Server 1680 implementations. 1681

1682

A single entity MAY conform as both an MQTT Client and MQTT Server implementation. For example, a 1683 server that both accepts inbound connections and establishes outbound connections to other servers 1684 MUST conform as both an MQTT Client and MQTT Server. 1685

1686

Conformant implementations SHALL NOT require the use of any extensions defined outside of this 1687 specification in order to interoperate with any other conformant implementation. 1688

6.1 Conformance Targets 1689

6.1.1 MQTT Server 1690

1691

An MQTT Server accepts Network Connections from MQTT Clients. 1692

1693

An MQTT Server conforms to this specification if it satisfies all of the MUST level requirements in the 1694 following sections that are identified for the Server: 1695

- [MQTT0001] Section 2 - MQTT Control Packet format 1696

- [MQTT0002] Section 3 - MQTT Control Packets 1697

- [MQTT0003] Section 4 - Operational behaviour 1698

- [MQTT0004] Section 5 - Security 1699

1700

6.1.2 MQTT Client 1701

1702

An MQTT Client creates a Network Connection to an MQTT Server. 1703

1704

An MQTT Client conforms to this specification if it satisfies all of the MUST level requirements in the 1705 following sections that are identified for the Client: 1706

- [MQTT0005] Section 2 - MQTT Control Packet format 1707

- [MQTT0006] Section 3 - MQTT Control Packets 1708

- [MQTT0007] Section 4 - Operational behaviour 1709

- [MQTT0008] Section 5 - Security 1710



Deleted: 2

Deleted: 2



Appendix A. Using WebSockets as a network 1711

transport. 1712

MQTT can be transported over a WebSocket [RFC 6455] connection using the following conventions: 1713

• WebSocket binary frames are used. A single frame may contain multiple or partial MQTT Control 1714 Packets; they are not required to be aligned. 1715

• The WebSocket Protocol Name consists of the MQTT Protocol Name concatenated with the 1716 ASCII representation of the MQTT Protocol Version number. For MQTT v3.1.1, this will be 1717 "MQTT4". 1718

• No restriction is placed on the path portion of the WebSocket url. 1719

1720

Deleted: 2

Deleted: 2



Appendix B. Revision history 1721

1722

Revision Date Editor Changes Made

[02] [29 April 2013] [A Banks] [Tighten up language for Connect packet]

[03] [09 May 2013] [ A Banks] [Tighten up language in Section 02 Command Message Format]

[04] [20 May 2013] [Rahul Gupta] Tighten up language for PUBLISH message

[05] [5th June 2013] [ A Banks]

[Rahul Gupta]

[ Issues -5,9,13 ]

[Formatting and language tighten up in PUBACK, PUBREC, PUBREL, PUBCOMP message]

[06] [20th

June 2013] [Rahul Gupta] [Issue – 17, 2, 28, 33]

[Formatting and language tighten up in SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP, DISCONNECT Control Packets]

Terms Command message change to Control Packet

Term “message” is generically used, replaced this word accordingly with packet, publication, subscription.

[06] [21 June 2013] [A Banks]

[Rahul Gupta]

Resolved Issues – 12,20,15, 3, 35, 34, 23, 5, 21

Resolved Issues – 32,39, 41

[07] [03 July 2013] [A Banks]

[Rahul Gupta]

Resolved Issues – 18,11,4

Resolved Issues – 26,31,36,37

[08] [19 July 2013] [A Banks]

[Rahul Gupta]

Resolved Issues – 6, 29, 45

Resolved Issues – 36, 25, 24

Added table for fixed header and payload

[09] [01 August 2013] [A Banks] Resolved Issues – 49, 53, 46, 67, 29, 66, 62, 45, 69, 40, 61, 30

[10] [10 August 2013] [A Banks]

[Rahul Gupta]

Resolved Issues – 19, 63, 57, 65, 72

Conformance section added

[11] [10 September 2013]

[A Banks]

[N O'Leary & Rahul Gupta]

Resolved Issues – 56

Updated Conformance section

[12] [18 September 2013]

[Rahul Gupta]

[A Banks]

Resolved Issues – 22, 42, 81, 84, 85, 7, 8, 14, 16, Security section is added

Resolved Issue -1

Deleted: 2

Deleted: 2



[12] [27 September 2013]

[A Banks] Resolved Issues – 64, 68, 76, 86, 27, 60, 82, 55, 78, 51, 83, 80

1723

Deleted: 2

Deleted: 2


Page 12: [1] Deleted Andrew_Banks 03/10/2013 17:29:00

If 1, the recipient might have previously received the Control Packet it should not treat this flag as an indication that it has previously received the MQTT Control Packet and should not use the Dup flag alone to guarantee to its application that a duplicate message is being redelivered to its application interface.

Page 12: [2] Change Andrew_Banks 27/09/2013 14:08:00

Formatted Bullets and Numbering

Page 22: [3] Deleted Andrew_Banks 03/10/2013 17:44:00

The ClientId MUST comprise only Unicode characters, and the length of the UTF-8 encoding MUST be at least one byte and no more than 65535 bytes. The server MAY restrict the ClientId it allows in terms of their lengths and the characters they contain, however the server MUST allow ClientIds which are 23 or fewer UTF-8 encoded bytes in length, and contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".

If the server rejects the ClientId it MUST respond to the CONNECT packet with a CONNACK return code 0x02 (Identifier rejected) and then terminate the TCP connection.

Page 45: [4] Formatted Andrew_Banks 27/09/2013 14:12:00

Default Paragraph Font, Font: 10 pt, Font color: Auto, Pattern: Clear


Font: 10 pt, Font color: Auto, Pattern: Clear






Font: 10 pt, Font color: Auto























Page 45: [20] Change Andrew_Banks 27/09/2013 14:08:00

Formatted Bullets and Numbering

Documents

MQTT Version 3.1 - OASIS · 1 MQTT Version 3.1.1 2 Working Draft 13 ... 198 • The specific details of each Control Packet type ... mqtt-v3.1.1-wd1 3 Working Draft 1 3 05 October