idnits 2.17.1 draft-zhengjp-sipcore-sipim-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 24, 2016) is 2679 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jianping Zheng 3 Internet-Draft Yichuan Wu 4 Intended Status: Experimental China Mobile Communications Corporation 5 Expires: June 24, 2017 Weimin Lei 6 Wei Zhang 7 Hao Li 8 Northeastern University 9 December 24, 2016 11 An Extension for SIP Instant Message Using Publish/Subscribe Mode 12 draft-zhengjp-sipcore-sipim-ext-00 14 Abstract 16 SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) 17 is a protocol suite for instant messaging (IM) service, but it is 18 inefficient in processing instant message in session mode due to its 19 complex signaling processes and heavy header overheads, which makes 20 it difficult to meet the QoE (quality of experience) requirement, 21 especially in the usage scenario of mobile Internet and other traffic 22 sensitive networks. 24 This document describes an alternative Session Initiation Protocol 25 (SIP) extension for instant messaging service. The extension uses the 26 publish-subscribe mode to simplify signaling procedures and 27 introduces message user agent (MUA) to publish and receive message, 28 and message broker (MB) as an intermediary to exchange messages 29 between MUAs. Message is tagged with a topic, and the lightweight 30 message format is more suitable for traffic sensitive networks. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 22, 2017. 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. This document is subject to 58 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 59 Documents (http://trustee.ietf.org/license-info) in effect on the 60 date of publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5 Entities Behavior Description . . . . . . . . . . . . . . . . . 9 74 5.1 MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1.1 Connection Maintenance . . . . . . . . . . . . . . . . 9 76 5.1.2 Topic Subscription and Message Publication . . . . . . 9 77 5.1.3 Message ID Generation . . . . . . . . . . . . . . . . . 9 78 5.1.4 Session Termination . . . . . . . . . . . . . . . . . . 9 79 5.2 MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2.1 Request Authentication . . . . . . . . . . . . . . . . 10 81 5.2.2 Connection Maintenance . . . . . . . . . . . . . . . . 10 82 5.2.3 Sending Responses . . . . . . . . . . . . . . . . . . . 10 83 5.2.4 Processing Offline Messages . . . . . . . . . . . . . . 10 84 5.2.5 Other Capacities . . . . . . . . . . . . . . . . . . . 10 85 6 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6.1 Setting Topic Rules . . . . . . . . . . . . . . . . . . . . 11 87 6.2 Organization of Topic . . . . . . . . . . . . . . . . . . . 11 88 6.3 Message Routing Based on Topic . . . . . . . . . . . . . . 12 89 7 Message Types . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.1.1 Fixed Header . . . . . . . . . . . . . . . . . . . . . 13 92 7.1.2 Variable Header . . . . . . . . . . . . . . . . . . . . 14 93 7.2 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 7.3 CONNACK . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 7.4 PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 7.5 PUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 7.6 SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 7.7 SUBACK . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 7.8 UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 22 100 7.9 UNSUBACK . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 7.10 PINGREQ . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 7.11 PINGRSEP . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 7.12 DISCONNECT . . . . . . . . . . . . . . . . . . . . . . . . 25 104 8 Compatibility Considerations . . . . . . . . . . . . . . . . . 25 105 9 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 106 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 107 10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 26 108 10.2 Informative References . . . . . . . . . . . . . . . . . . 26 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 111 1 Introduction 113 Instant message (IM) refers to a kind of real-time message transfer 114 service. The major service characteristics of IM include various 115 media type (text, audio, video, picture, emoji etc.) and high 116 interactivity (group chat, online game etc.). Besides some 117 proprietary protocols, IM service can be implemented by some open 118 protocol suites, such as Extensible Messaging and Presence Protocol 119 (XMPP) (RFC 3920, RFC 3921)[1][2], Common Profile for Instant 120 Messaging (CPIM) (RFC 3860, RFC 3922)[3][4], SIP[7] for Instant 121 Messaging and Presence Leveraging Extensions (SIMPLE)[8]. And SIMPLE 122 is well-developed among these protocols and has been adopted by many 123 vendors as the standard of instant messaging applications. 125 SIMPLE is a SIP-based protocol suite, which has been applied in many 126 applications, such as the presence and the instant messaging. 127 However, with the development of the multimedia and related storage 128 technology, the increasing user requirement and the changing of usage 129 scenario, the existing SIMPLE framework limits the further 130 application and development of IM service which is mainly embodied as 131 follow. 133 1) Currently, store-and-forward mode turns to be the main 134 application patterns of message service, however, SIMPLE framework 135 still use Peer-to-Peer mode which is lagging behind the 136 development of instant message. 138 2) SIMPLE uses SIP and MSRP (The Message Session Relay Protocol) 139 as the core protocols, and provides three kinds of transmission 140 modes to achieve instant message: page mode, large message mode 141 and session mode. Page mode is suitable for transmitting short 142 messages by the way of SIP MESSAGE, in which the cost of message 143 header is more than message content in most case. Large message 144 mode adopts SIP and MSRP to transmit long messages. It firstly 145 creates a session between participants through SIP signaling and 146 transmits data through MSRP. As for session mode, it requires to 147 establish a SIP session and IM session, and keeps them for a 148 period of time. Message transmitting by SIP and MSRP is based on a 149 session, and the procedure of session establishing and terminating 150 add extra overhead, and thus affects the overall efficiency of 151 message transfer. MSRP is a text-based connection oriented 152 protocol and the extra overhead of the message is big, which will 153 also reduce execution efficiency to some extent. 155 3) The main usage scenario of instant message is mobile Internet. 156 In mobile Internet, the IP address of the mobile device is time- 157 varying as it moves. To provide the addressability of the 158 endpoint, the mobile device must register to server constantly 159 when its address changes. For a SIP-based instant message 160 application, the vibrating registration which caused by the 161 changing IP address will cause a huge overhead of traffic and 162 power. The mobile device is sensitive to the traffic and power 163 consumption of terminal equipment in mobile Internet, and the 164 vibrating registration will decrease the quality of experience of 165 users. 167 4) Group chatting is an important feature of IM service, and the 168 implementation of group chatting by SIMPLE uses the SIP Conference 169 service for references. RFC7701[5] provides a group messaging 170 frame based on SIP and MSRP, which requires all participants 171 maintain a MSRP connection with MSRP Switch. However, maintaining 172 connection with the Switch over a length of time would cause a 173 great waste of network resources when there is no traffic transfer 174 and the re-establishment of the connection will waste more when a 175 short message needs to be transmitted. This method will cause a 176 higher traffic and power consumption and thus reduce service 177 experience of user. 179 5) The group chatting in SIMPLE works in the peer-to-peer (P2P) 180 mode, and the routing problem of P2P have negative influence on 181 the extensibility and the promotion of execution efficiency. The 182 above issues have impeded the development of group chatting 183 service. 185 Although much of the functions can be realized through SIMPLE, there 186 are many disadvantages like low data transfer rate, network resource 187 waste and inefficient execution. Peer-to-peer mode limits the 188 development of IM service. In addition, instant messaging 189 applications based on SIMPLE or other related protocol suites are 190 primarily enterprise-oriented, which don't apply to use on a large 191 scale. To solve these problems, this document extends the current 192 SIP, adding two kinds of logical entities named Message User Agent 193 (MUA) and Message Broker (MB). MUA is an agent of user, which is 194 responsible for publishing and receiving messages, creating, 195 modifying and deleting a group. MB is in charge of message receiving, 196 storing and forwarding, and in the meanwhile it manages the group. 197 Each message is associated with a related topic and the transfer 198 method is based on the publish/subscribe mode which decouples 199 publisher and receiver dependencies and reduce the system develop 200 difficulty. 202 2 Terminology 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 205 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 206 this document are to be interpreted as described in RFC 2119[6]. 208 3 Definitions 210 To extend SIP, this document defines: 212 1)MUA (Message User Agent): has functions of SIP User Agent. It is 213 responsible for producing, subscribing and publishing messages to 214 relevant Topic. At the same time, it receives messages from MB, 215 manages the users' configuration files and participates in 216 creation, modification and deletion of a group. It's also used for 217 authentication and register of user. 219 2) MB (Message Broker): deals the authentication, registration and 220 Topic subscribing request of MUA and manages user configuration 221 files. At the same time, it manages Topic, receives, stores and 222 forwards the messages and manages the group chat as well. It is 223 able to interact with other SIP entities to complete 224 authentication and registration for users. 226 3) Topic: is structured as a layered organization. Topic name is 227 the label of a kind of or a set of instant message. It is 228 generated in MUA, and published to MB, and finally stored in MB. 229 MUA updates the message contents of a Topic, and MB will match the 230 subscribers of the Topic and push the message to those 231 subscribers. And the group chatting topic is generated in MB and 232 must be be globally unique. 234 4) Message Configuration Files: includes the users' basic 235 information and messaging strategy and group information. When the 236 users start registering, they will upload the configuration 237 documents to MB and MB will complete the subscription of relevant 238 Topic for the users according to it. 240 4 Overview 242 SIMPLE framework implements the function of instant message based on 243 SIP and MSRP, but there are existing shortcomings in complex system 244 design, low execution efficiency and transmission efficiency and 245 unsuitable for large-scale usage scenario and so on. To solve these 246 problems, this document introduces two logical entities: MUA and MB, 247 which are responsible for SIP message service. This scheme uses 248 store-and-forward mode to transmit messages instead of the peer-to- 249 peer mode. And each message is associated with a related topic and 250 transmitted as the publish/subscribe mode. 252 Publish/subscribe mode, also called Observer mode, is a kind of 253 messages transport pattern which can be applied to store-and-forward 254 mode effectively. The messages are defined as the form of topic. The 255 users or MUAs generate topics according to some specific rules and 256 then publish to the MB. Users or MUAs can subscribe a topic from MB 257 and become relevant subscribers. When the message publisher publishes 258 the messages to topic, MB publishes the messages to all the relevant 259 subscribers. And the advantages of this solution are: 261 (1) Decoupling 262 a. Decoupling publisher from receiver 264 i. Space decoupling 266 When sending messages, the publisher and receiver don't need 267 to know the exist of each other, a relevant topic 268 subscriptions relationships will help the MB publish the 269 messages that the publisher published to MB to all relevant 270 subscribers. 272 ii. Time decoupling 274 The publisher and receiver don't need to establish 275 connection simultaneously to assure the immediacy and 276 efficiency. 278 iii. Synchronization decoupling 280 The publisher doesn't need to establish the synchronization 281 relationship with the receiver. It publishes the messages to 282 MB and the receiver receives in an asynchronous way, i.e., 283 MUA-to-MB, MB-to-MUA, by keeping a connection with MB. 285 b. Decoupling the user from terminal device For multi-terminal 286 user, the user just keeps the weak relation with the terminal 287 device. The terminal device keeps the synchronization 288 relationship with MB and subscribes topic independently. 290 (2) Reducing the complexity of implementation All the messages 291 including one-to-one messages, one-to-many messages and group 292 messages can be defined as the form of topic and transmitted as 293 the publish/subscribe mode. This method makes different kinds of 294 messages have the approximate cost. Furthermore, it reduces the 295 implementation complexity of group chatting messages. 297 (3) Stateless processing In the store-and-forward mode based on 298 publish/subscribe pattern, publishing the messages is asynchronous 299 with receiving the messages, so MB doesn't need to keep the state- 300 transition relationship for publishing and forwarding. Moreover, 301 this mode gets rid of the dependence of transaction and reduces 302 the cost. 304 (4) Expansibility Publish/subscribe mode achieves distributed 305 architecture, parallel operations, message buffer and tree routing 306 or mesh routing. Therefore, it could achieve a high expansibility, 307 and suit for the large-scale usage scenario and improve the 308 insufficiency caused by the tightly coupled and data-center 309 service. 311 (5) Environmental suitability Publish/subscribe mode is more 312 suitable for current mobile Internet. The publisher and receiver 313 are loosely coupled, which makes it free from P2P connection and 314 reduces the network resource consumption. In addition, combining 315 publishing with forwarding, it lowers the cost of transmitting the 316 messages. Furthermore, MUA just needs to keep a connection with MB 317 and don't need to request registration frequently because of IP 318 address changes. 320 (6) Service openness Current SIMPLE frame has the session 321 negotiation through SIP/SDP, but the SDP is fit for audio and 322 video session not suitable for message service. For the purpose of 323 supporting the message service, SDP has to be extended, so it 324 brings more difficulty to realize. As for topic mode, users can 325 generate different Topics in terms of the requirement and the 326 other can subscribe the topics that they are interested in. 327 Therefore, this method enables the definition of service to be 328 more flexible from the standard and it is good for new message 329 service and service openness. 331 To support mobile Internet scenario, the communication between MUA 332 and MB breaks the limit that SIP is a test-based protocol. SIP is 333 an open protocol, which can be extended according to the 334 requirement of service. Mobile device is sensitive to traffic and 335 we must pay more attention to the efficiency of messages. So this 336 document defines a kind of lightweight and binary protocol for the 337 communication between MUA and MB. This protocol refers to the 338 design and message format of MQTT which will be described in more 339 detail in the subsequent sections. 341 The registration mechanism of SIP system is integrated. MUA and 342 MB's authentication and registration adopt this mechanism to ease 343 the work. MB needs to register to the Proxy or the application 344 server (AS) in charge of message service for the purpose of 345 legality. The registration mechanism of MUA is similar with SIP UA 346 but not the same, the difference is that MUA is responsible for 347 message service and needs to request authentication to Proxy or 348 AS. Proxy or AS would assign a MB for MUA, both of which will be 349 informed. What's more, this registration mechanism is beneficial 350 to load balancing. 352 5 Entities Behavior Description 354 5.1 MUA 356 The entity address, i.e., user ID, in network communication is 357 unique. The User ID is distributed by MB, but the username can be 358 defined by the user himself, such as Email address, SIP URL and 359 telephone number. 361 5.1.1 Connection Maintenance 363 A TCP connection needs to be established between MUA and MB. The 364 heartbeat mechanism with PINGREQ and PINGRESP messages is employed to 365 maintain the long-lived connection between client and MB. 366 Communication among MUAs is based on Topic. This topic-based 367 transport pattern gets a loose coupling between the publisher and 368 receiver and achieves one-to-one message service and group message 369 service easily. On the other hand, it's also helpful to make the user 370 and terminal decoupled and support multi-terminal mode easily. 372 5.1.2 Topic Subscription and Message Publication 374 By sending SUBSCRIBE message to MB, MUA subscribes the Topics which 375 it is interested in. About publishing, MUA adopts PUBLISH message 376 which includes the Topic information and message content. 378 There are some differences in the receiving and sending different 379 types of messages. For text message, MUA sends data to MB directly, 380 and then MB sends it to MUA who has subscribed this Topic before. For 381 multimedia message such as picture, document and so on, the 382 transmission mode is a little complex. Referring to the offline file, 383 The MUA of sender sends data to specialized multimedia data server 384 and the server returns relevant URL link. Then MUA puts the URL link 385 in the payload of PUBLISH message and send to MB. When MB receives, 386 it sends the message to all relevant subscribers. Finally, the 387 subscribers will parse the message to get the URL and downloads 388 multimedia data from the multimedia data server. 390 5.1.3 Message ID Generation 392 MUA needs to generate a new and unique message ID when constructing 393 some messages, such as PUBLISH (in cases where QoS > 0), SUBSCRIBE, 394 and UNSUBSCRIBE. The message ID is used to associate response 395 messages with their corresponding request messages and thus ensure 396 the transmission reliability. 398 5.1.4 Session Termination 399 When terminating session for some reason, the MUA will send DISCONNET 400 message to MB and turn to offline state itself. 402 5.2 MB 404 MB is responsible for complicated processing logic. It manages the 405 forwarding of messages and the storage of users' offline messages and 406 buddy list information. 408 5.2.1 Request Authentication 410 When MUA sends CONNECT message to request connection, MB must 411 authenticate the request by comparing the Token value in CONNECT 412 message with the token in uniform authentication platform. If the 413 comparison result is equal, MB will pre-subscribe the Topics of 414 user's buddy list and relevant Topics of user's behavior. If failed, 415 MB will reject to the CONNECT message. 417 5.2.2 Connection Maintenance 419 MB maintains the connection with client and replies to the MUA's 420 heartbeat request. When beyond the keep-alive time expires but no 421 data packet from MUA is received, the MB will mark the MUA as 422 unreachable. 424 5.2.3 Sending Responses 426 When receiving a request message from MUA, MB will send a 427 corresponding response message back according to different message 428 types. And the response message has the same message ID with the 429 corresponding request message. For example, when receiving a 430 SUBSCRIBE message, MB will send a SUBACK message as a response. 431 According to whether receiving SUBACK message or not, MUA will know 432 whether subscribe successfully or not. 434 5.2.4 Processing Offline Messages 436 For some reason, MUA has disconnected MB and its user state is 437 offline. At that time, if someone sends messages to it, the MB will 438 be responsible for receiving and storing these offline messages until 439 it is online again. What's more, the MB will push these offline 440 messages to MUA as soon as it is online. 442 5.2.5 Other Capacities 444 MB has some other capacities: 446 Semantic Parsing: MB is responsible for parsing the Topic semantic 447 and determining the Topic behavior according to the Topic information 448 of MUA. For example, by parsing the user ID included in Topic, MB 449 finds the receiver of messages and sends the messages to him. 451 Message Routing: when MUA publishes messages, if the destination sets 452 are not null, MB will forward the messages to the destination, i.e., 453 the MB or the MUA who is interested in this Topic. 455 Permission Checking: MB performs ACL permission checkout and filters 456 the messages in relevant Topic of MUA. The filtering operation can be 457 set by system as well as its user. For example, if a Topic is set 458 "read", its user will only have the permission of receiving. On the 459 contrast, if a Topic is set "write", its user will only have the 460 permission of sending. (definition rules: username topic rw) 462 State Presenting: all the states are presented by user presence. The 463 function of presence is presenting the state of any terminal. State 464 is related to the type of terminal. When a user's presence state 465 changes, MB will inform all his friends. 467 Broker to Broker: it is the connection between two MBs and is 468 considered as the communicating extension between client and server. 470 6 Topic 472 6.1 Setting Topic Rules 474 Topic can be considered as the identification of message data. As for 475 receiving messages, the MUA of receiver needs to subscribe the Topic 476 of interest to MB. To different message types, MB's processing logic 477 is different. So this document defines that the first part of Topic 478 is the service profile identifiers which is used to distinguish 479 different message types. For example, the one-to-one messages' 480 service profile identifier is defined as 110 while the group 481 messages' is 200. The one-to-one messages' Topic is /100/UID while 482 the group messages' is /200/GID. For one-to-one messages service, MUA 483 subscribes the Topic it is interested in for itself, while for group 484 messages service, all the users in the group subscribe the same 485 Topic. 487 6.2 Organization of Topic 489 The organization of Topic is related to the user behavior. Some 490 Topics are defined according to the user behavior, such as the Topic 491 of adding friends is user/friend/new, deleting friends corresponds to 492 user/friend/delete, user's IM Topic is user/chat while the Topic of 493 state presenting is presence/user. Typically, the users transmit 494 instant messages with each other in user/chat. 496 Using adding friends as an example, when Alice wants Bob to become a 497 friend of hers, she needs to send requesting to the Topic of Bob's 498 adding friends, i.e., Bob@example.com/friend/new. Then Bob sends 499 response to Alice's Topic, i.e., Alice@example.com/friend/new. If Bob 500 agree with this requesting, Alice will send the information both of 501 them to relevant Topic and at last they will communicate with each 502 other in this Topic. 504 6.3 Message Routing Based on Topic 506 MB achieves the functions of filtering and routing based on Topic. In 507 Publish/subscribe message system, the publisher publishes the 508 messages to MB and the subscriber subscribes the Topic which it is 509 interested in through MB. And MB stores and forwards these messages. 511 When a client subscribes a Topic, the MB at which the client located 512 will notify all the other MBs that the Topic has been subscribed by 513 it. 515 When a client publishes a message, the MB located will route this 516 message to the MB which subscribed the Topic and the latter message 517 will be routed to the client. 519 The message routing based on Topic supports the user-defined Topic, 520 which requires the user to register the Topic. This way is beneficial 521 to service opening and diversity. 523 7 Message Types 525 7.1 Overview 527 Referring to MQTT protocol [9], this scheme defines 11 kinds of 528 message types expressed in 4 bits. These 11 kinds of messages types 529 are CONNECT, CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, 530 UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP and DISCONNECT. They can be 531 divided into 4 categories according to different functions: 533 1) Connection Class: CONNECT (value =1), and MUA sends it to MB to 534 request connection. CONNACK (value =2), and MB sends it to MUA as 535 the response of CONNECT. DISCONNECT (value =14), and MUA sends it 536 MB to request disconnection. 538 2) Keep-alive Class: PINGREQ (value =12), and MUA sends it to MB 539 to ask whether the connection still exist. PINGRESP (value =13), 540 and MB sends it to MUA in response to PINGREQ. 542 3) Subscription Class: SUBSCRIBE (value =8), and MUA sends it to 543 MB to subscribe Topic. SUBACK (value =9), and MB sends it to MUA 544 in response to subscribe. UNSUBSCRIBE (value =10), and MUA sends 545 it to MB to cancel the SUBSCRIBE. UNSUBACK (value =11), and MB 546 sends it to MUA in response to UNSUBSCRIBE. 548 4) Publishing Class: PUBLISH (value =3), and MUA and MB can send 549 it to each other to publish messages in a Topic. PUBACK (value 550 =4), and it is the response of PUBLISH. 552 The message contains 3 components: Fixed header, Variable header and 553 Payload as illustrated in Figure 7.1. 555 +-------------------------------+ 556 | Fixed header | 557 +-------------------------------+ 558 | Variable header | 559 +-------------------------------+ 560 | Payload | 561 +-------------------------------+ 563 Figure 7.1 - Message structure 565 7.1.1 Fixed Header 567 Each message contains a fixed header. Figure 7.2 illustrates the 568 fixed header format. 569 +---------------------------------------+ 570 |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 571 +---------------------------------------+ 572 |byte 1 | Message Type | Flags | 573 +---------------------------------------+ 574 |byte 2 | Remaining Length | 575 +---------------------------------------+ 577 Figure 7.2 - Fixed header format 579 Message Type: byte 1, bits 7-4. Represented as a 4-bit unsigned 580 value, different value expresses different message type. For example, 581 value 1 expresses the CONNECT message while value 2 expresses the 582 CONNACK message. 584 Flags: remaining bits 3-0 of byte 1, specific to each kind message. 586 Remaining Length: starts at byte 2, bits 7-0, the number of bytes 587 remaining within the current message, including data in the variable 588 header and the payload. The fixed header can be extended to four 589 bytes at most. 591 7.1.2 Variable Header 593 Some types of messages contain a variable header component. It 594 resides between the fixed header and the payload. The content of the 595 variable header varies depending on the message type. The Message 596 Identifier field of variable header is common in several message 597 types as illustrated in Figure 7.3. 599 +-----------------------------------+ 600 |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 601 +-----------------------------------+ 602 |byte 1 | Message Identifier MSB | 603 +-----------------------------------+ 604 |byte 2 | Message Identifier LSB | 605 +-----------------------------------+ 607 Figure 7.3 - Message Identifier bytes 609 Message Identifier: two bytes, non-zero, unique identification of a 610 message. 612 This document refers to MQTT protocol to define the message types, 613 however, not using the message header whose QoS is 2, this 614 specification defines 11 kinds of message types, including CONNECT, 615 CONNACK, PUBLISH, PUBACK, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, 616 PINGREQ, PINGRES and DISCONNECT. 618 7.2 CONNECT 620 CONNECT, requesting connection, the fixed header as illustrated in 621 Figure 7.4. 623 +----------------------------------------+ 624 |Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 625 +----------------------------------------+ 626 |byte 1 |Message Type (1)| Reserved | 627 +----------------------------------------+ 628 | | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 629 +----------------------------------------+ 630 |byte 2 | Remaining Length | 631 +----------------------------------------+ 633 Figure 7.4 - CONNECT message fixed header 635 Message Type: 1, represent the CONNECT message; 637 Flags: 0, reserved for future use; 638 Remaining Length: uncertain, depend on the data in the variable 639 header and the payload. 641 The variable header carries the protocol version information as 642 illustrated in Figure 7.5. The protocol version is a UTF-8 encoded 643 string that represents the protocol version "IM01". 645 +------------------------------------------------------+ 646 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 647 +------------------------------------------------------+ 648 |Protocol Version Information | 649 +------------------------------------------------------+ 650 |byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 651 +------------------------------------------------------+ 652 |byte 2 |Length LSB (4)| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 653 +------------------------------------------------------+ 654 |byte 3 | 'I' | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 1 | 655 +------------------------------------------------------+ 656 |byte 4 | 'M' | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 657 +------------------------------------------------------+ 658 |byte 5 | '0' | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 659 +------------------------------------------------------+ 660 |byte 6 | '1' | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 661 +------------------------------------------------------+ 663 Figure 7.5 - CONNECT message variable header 665 As for the payload, it mainly includes personal information of user, 666 such as username and authentication Token and heart beats 667 information. Username and authentication Token are the UTF-8 encoded 668 strings. 670 7.3 CONNACK 672 CONNACK is the MB's response of CONNECT, the fixed forehead as 673 illustrated in Figure 7.6. 675 +--------------------------------------+ 676 |Bit |7 |6 |5 |4 |3 |2 |1 |0 | 677 +--------------------------------------+ 678 |byte 1|Message Type(2)| Reserved | 679 +--------------------------------------+ 680 | |0 |0 |1 |0 |0 |0 |0 |0 | 681 +--------------------------------------+ 682 |byte 2|Remaining Length (2) | 683 +--------------------------------------+ 684 | |0 |0 |0 |0 |0 |0 |1 |0 | 685 +--------------------------------------+ 687 Figure 7.6 - CONNACK message fixed header 689 Message Type: 2, represent the CONNACK message; 691 Flags: 0, reserved for future use; 693 Remaining Length: 2, represent that there are 2 bytes remaining 694 within this message. 696 The variable header mainly contains 2 components: CONNECT Acknowledge 697 Flags and CONNECT Return code and its format is illustrated in Figure 698 7.7. 700 +----------------------------------------------------------+ 701 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 702 +----------------------------------------------------------+ 703 |CONNECT Acknowledge Flags | Reserved |SP1| 704 +----------------------------------------------------------+ 705 | byte 1 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | X | 706 +----------------------------------------------------------+ 707 |CONNECT Return code | 708 +----------------------------------------------------------+ 709 | byte 2 | | X | X | X | X | X | X | X | X | 710 +----------------------------------------------------------+ 712 Figure 7.7 - CONNACK message variable header 714 CONNECT Acknowledge Flags: Bits 7-1 are reserved and MUST be set to 715 0. Bit 0 (SP1) is the Session Present Flag. 717 CONNECT Return code: represent the responding situation. 0 represents 718 that the connection is successful, 1 represents that the connection 719 is failed because of the unacceptable protocol version and 2 720 represents that connection is failed because of rejected user ID. 722 7.4 PUBLISH 723 PUBLISH, sent from MUA to MB or from MB to MUA to transport an 724 application message, the fixed header as illustrated in Figure 7.8. 725 Typically, 727 DUM = Duplicate delivery of a PUBLISH message; 729 QoS = PUBLISH quality of service; 731 RETAIN = PUBLISH retain flag. 733 +------------------------------------------------------------+ 734 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 735 +------------------------------------------------------------+ 736 | byte 1 | Message Type (3) |DUM flag| QoS level |RETAIN| 737 +------------------------------------------------------------+ 738 | | 0 | 0 | 1 | 1 | X | X | X | X | 739 +------------------------------------------------------------+ 740 | byte 2 | Remaining Length | 741 +------------------------------------------------------------+ 743 Figure 7.8 - PUBLISH message fixed header 745 Message Type: 3, represent the PUBLISH message; 747 DUM flag: 0 indicates that it isn't a retransmission message and 1 748 indicates it is. 750 QoS level: indicate the level of assurance for delivery of an 751 Application Message. 753 RETAIN: 0 indicates that MB must not store the application message 754 and must not remove or replace any existing retained message, while 755 1indicates that the MB must store it. 757 Remaining Length: uncertain, depend on the data in the variable 758 header and the payload. The variable header mainly contains 2 759 components: Topic Name and Message Identifier. Figure 7.9 shows a non 760 normative example variable header, typically, the value of Topic Name 761 set "a/b" and the value of Message Identifier set 10. 763 +----------------------------------------------------------------------+ 764 | |Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 765 +----------------------------------------------------------------------+ 766 | Topic Name | 767 +----------------------------------------------------------------------+ 768 | byte 1 |Length MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 769 +----------------------------------------------------------------------+ 770 | byte 2 |Length LSB (3) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 771 +----------------------------------------------------------------------+ 772 | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 773 +----------------------------------------------------------------------+ 774 | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 775 +----------------------------------------------------------------------+ 776 | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 777 +----------------------------------------------------------------------+ 778 | Message Identifier | 779 +----------------------------------------------------------------------+ 780 | byte 6 |Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 781 +----------------------------------------------------------------------+ 782 | byte 7 |Message Identifier LSB (10) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 783 +----------------------------------------------------------------------+ 785 Figure 7.9 - PUBLISH message variable header non normative example 787 Topic Name: indicate which Topic is going to send data; 789 Message Identifier: is only present in PUBLISH message where the QoS 790 level is 1 or 2. 792 Payload in PUBLISH carries the data which is described in Topic, 793 i.e., the message content. 795 7.5 PUBACK If QoS is 1 in PUBLISH, PUBACK will as the response and 796 expresses that the message is received successfully by Broker. The 797 fixed forehead is illustrated in Figure 7.10. 799 +---------------------------------------+ 800 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 801 +---------------------------------------+ 802 | byte 1|Message Type(4)| Reserved | 803 +---------------------------------------+ 804 | | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 805 +---------------------------------------+ 806 | byte 2| Remaining Length (2) | 807 +---------------------------------------+ 808 | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 809 +---------------------------------------+ 810 Figure 7.10 - PUBACK message fixed header 812 Except the Message Type, the description of message field is the same 813 as CONNACK. The value of Message Type is 4. 815 The variable header of PUBACK is a message descriptor as same as 816 PUBLISH: 818 +-----------------------------------------+ 819 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 820 +-----------------------------------------+ 821 | byte 1 | Message Identifier MSB | 822 +-----------------------------------------+ 823 | byte 2 | Message Identifier LSB | 824 +-----------------------------------------+ 826 Figure 7.11 - PUBACK message variable header 828 7.6 SUBSCRIBE 830 SUBSCRIBE expresses the subscription of Topic and the specification 831 allows to define more than one Topic in a SUBSCRIBE. The fixed 832 forehead is illustrated in Figure 7.12. 834 +---------------------------------------+ 835 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 836 +---------------------------------------+ 837 | byte 1|Message Type(8)| Reserved | 838 +---------------------------------------+ 839 | | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 840 +---------------------------------------+ 841 | byte 2| Remaining Length | 842 +---------------------------------------+ 844 Figure 7.12 - SUBSCRIBE message fixed header 846 Message Type: 8, represent the SUBSCRIBE message; 848 Flags: 2, reserved for future use. Attention, it must be set to 2 849 respectively. The MB must treat any other value as malformed and 850 close the network connection; 852 Remaining Length: uncertain, depend on the data in the variable 853 header and the payload. The variable header contains a Message 854 Identifier. Figure 7.13 shows a variable header with Packet 855 Identifier set to 10. 857 +------------------------------------------------------------------+ 858 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 859 +------------------------------------------------------------------+ 860 |Message Identifier | 861 +------------------------------------------------------------------+ 862 |byte 1|Message Identifier MSB (0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 863 +------------------------------------------------------------------+ 864 |byte 2|Message Identifier LSB (10)| 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 865 +------------------------------------------------------------------+ 867 Figure 7.13 - SUBSCRIBE message variable header 869 The payload of a SUBSCRIBE message contains a list of Topic Filters 870 indicating the Topics to which the Client wants to subscribe. The 871 Topic Filters in a SUBSCRIBE message payload MUST be UTF-8 encoded 872 strings. The payload is illustrated in Figure 7.14. 874 +-------------------------------------------+ 875 |Description| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 876 +-------------------------------------------+ 877 |Topic Filter | 878 +-------------------------------------------+ 879 |byte 1 |Length MSB | 880 +-------------------------------------------+ 881 |byte 2 |Length LSB | 882 +-------------------------------------------+ 883 |bytes 3..N |Topic Filter | 884 +-------------------------------------------+ 885 |Requested QoS | 886 +-------------------------------------------+ 887 | | Reserved | QoS | 888 +-------------------------------------------+ 889 |byte N+1 | 0 | 0 | 0 | 0 | 0 | 0 | X | X | 890 +-------------------------------------------+ 892 Figure 7.14 - SUBSCRIBE message payload 894 Typically, the upper 6 bits of the Requested QoS byte are not used in 895 the current version of the protocol. They are reserved for future 896 use. The MB must treat a SUBSCRIBE packet as malformed and close the 897 network connection if any of Reserved bits in the payload are non- 898 zero, or QoS is not 0, 1 or 2. 900 7.7 SUBACK 902 SUBACK is MB's response of SUBSCRIBE. The fixed forehead is 903 illustrated in Figure 7.15. 905 +-------------------------------------------------------+ 906 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 907 +-------------------------------------------------------+ 908 | byte 1| MQTT Message Type (9) | Reserved | 909 +-------------------------------------------------------+ 910 | | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 911 +-------------------------------------------------------+ 912 | byte 2| Remaining Length | 913 +-------------------------------------------------------+ 915 Figure 7.15 - SUBSCRIBE message fixed header 917 Except the Message Type, the description of message field is the same 918 as PUBLISH. The value of Message Type is 9. 920 The variable header contains the Message Identifier from the 921 SUBSCRIBE Packet that is being acknowledged. Figure 7.16 below 922 illustrates the format of the variable header. 924 +-------------------------------------------------------+ 925 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 926 +-------------------------------------------------------+ 927 | byte 1| Message Identifier MSB | 928 +-------------------------------------------------------+ 929 | byte 2| Message Identifier LSB | 930 +-------------------------------------------------------+ 932 Figure 7.16 - SUBSCRIBE message variable header 934 The payload contains a list of return codes. Each return code 935 corresponds to a Topic Filter in the SUBSCRIBE message being 936 acknowledged. The order of return codes in the SUBACK message must 937 match the order of Topic Filters in the SUBSCRIBE message. Figure 938 7.17 below illustrates the format of the variable header. 940 +-------------------------------------------------------+ 941 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 942 +-------------------------------------------------------+ 943 | | Return Code | 944 +-------------------------------------------------------+ 945 | byte 1| X | 0 | 0 | 0 | 0 | 0 | X | X | 946 +-------------------------------------------------------+ 948 Figure 7.17 - SUBSCRIBE message payload 950 Allowed return codes: 952 0x00 - Success - Maximum QoS 0 ; 954 0x01 - Success - Maximum QoS 1 ; 956 0x02 - Success - Maximum QoS 2 ; 958 0x80 - Failure . 960 7.8 UNSUBSCRIBE 962 UNSUBSCRIBE expresses canceling the subscription of a Topic and the 963 specification allows canceling subscription of different Topics at a 964 time. The fixed forehead is illustrated in Figure 7.18. 966 +-------------------------------------------------------+ 967 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 968 +-------------------------------------------------------+ 969 | byte 1| Message Type (10) | Reserved | 970 +-------------------------------------------------------+ 971 | | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 | 972 +-------------------------------------------------------+ 973 | byte 2| Remaining Length | 974 +-------------------------------------------------------+ 976 Figure 7.18 - UNSUBSCRIBE message fixed header 978 Except the Message Type, the description of message field is the same 979 as he UNSUBSRIBE. The value of Message Type is 10. 981 The variable header is the message descriptor, as illustrated in 982 Figure 7.19. 984 +-------------------------------------------------------+ 985 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 986 +-------------------------------------------------------+ 987 | byte 1| Message Identifier MSB | 988 +-------------------------------------------------------+ 989 | byte 2| Message Identifier LSB | 990 +-------------------------------------------------------+ 992 Figure 7.19 - UNSUBSCRIBE message variable header 994 The payload for the UNSUBSCRIBE message contains the list of Topic 995 Filters that the Client wishes to unsubscribe from. The Topic Filters 996 in an UNSUBSCRIBE message must be UTF-8 encoded strings. Figure 7.20 997 shows a non normative example payload, typically, it set two Topic 998 Filters, the one is "a/b" and the other one is "c/d". 1000 +-----------------------------------------------------------+ 1001 | | Description | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1002 +-----------------------------------------------------------+ 1003 |Topic Filter | 1004 +-----------------------------------------------------------+ 1005 | byte 1 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1006 +-----------------------------------------------------------+ 1007 | byte 2 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1008 +-----------------------------------------------------------+ 1009 | byte 3 | 'a' (0x61) | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1010 +-----------------------------------------------------------+ 1011 | byte 4 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1012 +-----------------------------------------------------------+ 1013 | byte 5 | 'b' (0x62) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 1014 +-----------------------------------------------------------+ 1015 |Topic Filter | 1016 +-----------------------------------------------------------+ 1017 | byte 6 |Length MSB (0)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1018 +-----------------------------------------------------------+ 1019 | byte 7 |Length LSB (3)| 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1020 +-----------------------------------------------------------+ 1021 | byte 8 | 'c' (0x63) | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1022 +-----------------------------------------------------------+ 1023 | byte 9 | '/' (0x2F) | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 1 | 1024 +-----------------------------------------------------------+ 1025 | byte 10 | 'd' (0x64) | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 1026 +-----------------------------------------------------------+ 1028 Figure 7.20 - UNSUBSCRIBE message payload non normative example 1030 7.9 UNSUBACK 1032 UNSUBACK is MB's response of UNSUBSCRIBE. The fixed forehead is 1033 illustrated in Figure 7.21. 1035 +-------------------------------------------------------+ 1036 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1037 +-------------------------------------------------------+ 1038 | byte 1| Message Type (11) | Reserved | 1039 +-------------------------------------------------------+ 1040 | | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1041 +-------------------------------------------------------+ 1042 | byte 2| Remaining Length (2) | 1043 +-------------------------------------------------------+ 1044 | | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1045 +-------------------------------------------------------+ 1047 Figure 7.21 - UNSUBSACK message fixed header 1049 Except the Message Type, the description of message field is the same 1050 as CONNACK. The value of Message Type is 11. 1052 The variable header is the message descriptor, as illustrated in 1053 Figure. 1055 +-------------------------------------------------------+ 1056 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1057 +-------------------------------------------------------+ 1058 | byte 1| Message Identifier MSB | 1059 +-------------------------------------------------------+ 1060 | byte 2| Message Identifier LSB | 1061 +-------------------------------------------------------+ 1063 Figure 7.22 - UNSUBACK message variable header. 1065 7.10 PINGREQ 1067 Heartbeat packet, which the client sent to MB, only has fixed 1068 forehead. The fixed forehead is illustrated in Figure 7.23. 1070 +-------------------------------------------------------+ 1071 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1072 +-------------------------------------------------------+ 1073 | byte 1| Message Type (12) | Reserved | 1074 +-------------------------------------------------------+ 1075 | | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1076 +-------------------------------------------------------+ 1077 | byte 2| Remaining Length (0) | 1078 +-------------------------------------------------------+ 1079 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1080 +-------------------------------------------------------+ 1082 Figure 7.23 - PINGREQ message fixed header 1084 Message Type: 12, represent the PINGREQ message; 1086 Flags: 0, reserved for future use; 1088 Remaining Length: 0, no variable header or the payload. 1090 7.11 PINGRSEP 1092 The response of PINGREQ message, only has fixed forehead which is 1093 illustrated in Figure 7.24. 1095 +-------------------------------------------------------+ 1096 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1097 +-------------------------------------------------------+ 1098 | byte 1| Message Type (13) | Reserved | 1099 +-------------------------------------------------------+ 1100 | | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1101 +-------------------------------------------------------+ 1102 | byte 2| Remaining Length (0) | 1103 +-------------------------------------------------------+ 1104 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1105 +-------------------------------------------------------+ 1107 Figure 7.24 - PINGRSEP message fixed header 1109 Except the Message Type, the description of message field is the same 1110 as PINGREQ. The value of Message Type is 13. 1112 7.12 DISCONNECT 1114 The DISCONNECT message indicates that the MUA is disconnecting 1115 cleanly. It has fixed forehead only as illustrated in Figure 7.25 1116 with no variable header or payload. 1118 +-------------------------------------------------------+ 1119 | Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 1120 +-------------------------------------------------------+ 1121 | byte 1| Message Type (14) | Reserved | 1122 +-------------------------------------------------------+ 1123 | | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1124 +-------------------------------------------------------+ 1125 | byte 2| Remaining Length (0) | 1126 +-------------------------------------------------------+ 1127 | | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1128 +-------------------------------------------------------+ 1130 Figure 7.25 - DISCONNECT message fixed header 1132 Except the Message Type, the description of message field is the same 1133 as PINGREQ. The value of Message Type is 14. 1135 8 Compatibility Considerations 1137 The proposed scheme follows the extension logic of SIP protocol. 1138 Newly defined entity MUA provides backwards compatibility with SIP UA 1139 and has the same functions as SIP UA. The definition of MUA and MB 1140 meets the extension demand of SIP entity, furthermore, MUA and MB can 1141 interact with SIP logical entity normally. For example, when MUA 1142 requests authentication and registration, it sends registration 1143 message to application server firstly, and then application server 1144 would assign the most suitable MB for MUA and notify MUA if the 1145 message is matched. The message used in this process is in accordance 1146 with the method in SIP, which maintains compatibility about messages. 1148 9 Security Considerations 1150 Although the message publisher and receiver are loosely-coupled while 1151 transmitting messages, the security can be ensured. Firstly, before 1152 subscribing or publishing, MUAs need to authenticate and register 1153 user authentication information with AS. In the process, the username 1154 and password must be encrypted to prevent interception of assertions. 1155 Secondly, the username and password stored in AS are also encrypted 1156 to prevent identity leakage. Thirdly, MB only sends messages of a 1157 Topic to the MUA which has been authenticated and subscribed the 1158 related Topic. The authentication and topic management belongs to 1159 different entities, and it could avoid network attacks and was under 1160 firm security. When the IP address changes, current transmitting will 1161 stop and MUAs need to send a CONNECT message to MB to create a new 1162 connection. The message content should be encrypted by the encryption 1163 algorithm to ensure integrality and reliability of the message. 1165 10 References 1166 10.1 Normative Reference 1168 [1] Saint-Andre, P., "Extensible Messaging and Presence Protocol 1169 (XMPP): Core", RFC 6120, March 2011. 1171 [2] Saint-Andre, P., "Extensible Messaging and Presence Protocol 1172 (XMPP): Instant Messaging and Presence", RFC 6121, March 2011. 1174 [3] Peterson, J., "Common Profile for Instant Messaging (CPIM)", 1175 RFC3860, August 2004. 1177 [4] Saint-Andre, P., "Mapping Extensible Messaging and Presence 1178 Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 1179 3922, October 2004. 1181 [5] Niemi, A., Garcia-Martion, M., and G. Sandbakken, "Multi-party 1182 Chat Using the Message Session Relay Protocol (MSRP)", RFC7701, 1183 December 2015. 1185 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1186 Levels", BCP 14, RFC 2119, March 1997. 1188 10.2 Informative References 1190 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1191 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session 1192 Initiation Protocol", RFC 3261, June 2002. 1194 [8] Rosenberg, J., "SIMPLE Made Simple: An Overview of the IETF 1195 Specifications for Instant Messaging and Presence Using the Session 1196 Initiation Protocol (SIP)", RFC6914, April 2013. 1198 [9] International Business Machines Corporation (IBM), "MQTT V3.1 1199 Protocol Specification", 1200 http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt- 1201 v3rl.html, August 2010. 1203 Authors' Addresses 1205 Jianping Zheng 1206 China Mobile Communications Corporation 1207 China Mobile Research Institute 1208 Beijing, 100031 1209 P. R. China 1211 Email: zhengjianping@chinamobile.com 1213 Yichuan Wu 1214 China Mobile Communications Corporation 1215 China Mobile Research Institute 1216 Beijing, 100031 1217 P. R. China 1219 Email: wuyichuan@chinamobile.com 1221 Weimin Lei 1222 Northeastern University 1223 School of Computer Science and Engineering 1224 Shenyang, China, 110819 1225 P. R. China 1227 Email: leiweimin@mail.neu.edu.cn 1229 Wei Zhang 1230 Northeastern University 1231 School of Computer Science and Engineering 1232 Shenyang, China, 110819 1233 P. R. China 1234 Email: zhangwei1@mail.neu.edu.cn 1236 Hao Li 1237 Northeastern University 1238 School of Computer Science and Engineering 1239 Shenyang, China, 110819 1240 P. R. China 1242 Email: haoli2015@stumail.neu.edu.cn