ࡱ> jl[\]^_`abcdefghi +bjbj11 zSSz*****$+++PX+43+pC$(kdkkk,m~hTVVVVVV$-ߊNzQ*,m,mz**kk4˂t, , , *k*kT, T, , Ho$xk z̨]f0r`@?`Ds--$x$x0-*T{, zz, - ):  MQTT Version 3.1.1 Plus Errata 01 OASIS Standard Incorporating Approved Errata 01 10 December 2015 Specification URIs This version:  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.doc" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.doc (Authoritative)  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.pdf" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.pdf Previous version:  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.doc (Authoritative)  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf Latest version:  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc (Authoritative)  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf Technical Committee: HYPERLINK "https://www.oasis-open.org/committees/mqtt/"OASIS Message Queuing Telemetry Transport (MQTT) TC Chairs: Raphael J Cohn ( HYPERLINK "mailto:raphael.cohn@stormmq.com" raphael.cohn@stormmq.com), Individual Richard J Coppen ( HYPERLINK "mailto:coppen@uk.ibm.com" coppen@uk.ibm.com),  HYPERLINK "http://www.ibm.com/" IBM Editors: Andrew Banks ( HYPERLINK "mailto:Andrew_Banks@uk.ibm.com" Andrew_Banks@uk.ibm.com),  HYPERLINK "http://www.ibm.com/" IBM Rahul Gupta ( HYPERLINK "mailto:rahul.gupta@us.ibm.com" rahul.gupta@us.ibm.com),  HYPERLINK "http://www.ibm.com/" IBM Additional artifacts: This prose specification is one component of a Work Product that also includes: MQTT Version 3.1.1 Errata 01. Edited by Andrew Banks and Rahul Gupta. 10 December 2015. OASIS Approved Errata.  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os.html" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os.html. Related work: This specification replaces or supersedes: MQTT Version 3.1.1. Edited by Andrew Banks and Rahul Gupta. 29 October 2014. OASIS Standard.  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. This specification is related to: MQTT and the NIST Cybersecurity Framework Version 1.0. Edited by Geoff Brown and Louis-Philippe Lamoureux. Latest version:  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html" http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html. Abstract: MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium. The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections. Its features include: Use of the publish/subscribe message pattern which provides one-to-many message distribution and decoupling of applications. A messaging transport that is agnostic to the content of the payload. Three qualities of service for message delivery: "At most once", where messages are delivered according to the best efforts of the operating environment. Message loss can occur. This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published soon after. "At least once", where messages are assured to arrive but duplicates can occur. "Exactly once", where message are assured to arrive exactly once. This level could be used, for example, with billing systems where duplicate or lost messages could lead to incorrect charges being applied. A small transport overhead and protocol exchanges minimized to reduce network traffic. A mechanism to notify interested parties when an abnormal disconnection occurs. Status: This document was last revised or approved by the OASIS Message Queuing Telemetry Transport (MQTT) TC on the above date. The level of approval is also listed above. Check the Latest version location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at HYPERLINK "https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt" \l "technical"https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt#technical. TC members should send comments on this specification to the TCs email list. Others should send comments to the TCs public comment list, after subscribing to it by following the instructions at the HYPERLINK "https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=mqtt"Send A Comment button on the TCs web page at HYPERLINK "https://www.oasis-open.org/committees/mqtt/"https://www.oasis-open.org/committees/mqtt/. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page ( HYPERLINK "https://www.oasis-open.org/committees/mqtt/ipr.php" https://www.oasis-open.org/committees/mqtt/ipr.php). Citation format: When referencing this specification the following citation format should be used: [mqtt-v3.1.1-plus-errata01] MQTT Version 3.1.1 Plus Errata 01. Edited by Andrew Banks and Rahul Gupta. 10 December 2015. OASIS Standard Incorporating Approved Errata 01.  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html. Latest version:  HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html" http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html. Notices Copyright OASIS Open 2015. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full HYPERLINK "https://www.oasis-open.org/policies-guidelines/ipr"Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims. The name "OASIS" is a trademark of HYPERLINK "https://www.oasis-open.org/"OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see HYPERLINK "https://www.oasis-open.org/policies-guidelines/trademark"https://www.oasis-open.org/policies-guidelines/trademark for above guidance. Table of Contents  TOC \o "1-3" \h \z \u  HYPERLINK \l "_Toc442180821" 1 Introduction  PAGEREF _Toc442180821 \h 9  HYPERLINK \l "_Toc442180822" 1.1 Organization of MQTT  PAGEREF _Toc442180822 \h 9  HYPERLINK \l "_Toc442180823" 1.2 Terminology  PAGEREF _Toc442180823 \h 9  HYPERLINK \l "_Toc442180824" 1.3 Normative references  PAGEREF _Toc442180824 \h 10  HYPERLINK \l "_Toc442180825" 1.4 Non normative references  PAGEREF _Toc442180825 \h 11  HYPERLINK \l "_Toc442180826" 1.5 Data representations  PAGEREF _Toc442180826 \h 13  HYPERLINK \l "_Toc442180827" 1.5.1 Bits  PAGEREF _Toc442180827 \h 13  HYPERLINK \l "_Toc442180828" 1.5.2 Integer data values  PAGEREF _Toc442180828 \h 13  HYPERLINK \l "_Toc442180829" 1.5.3 UTF-8 encoded strings  PAGEREF _Toc442180829 \h 13  HYPERLINK \l "_Toc442180830" 1.6 Editing conventions  PAGEREF _Toc442180830 \h 15  HYPERLINK \l "_Toc442180831" 2 MQTT Control Packet format  PAGEREF _Toc442180831 \h 16  HYPERLINK \l "_Toc442180832" 2.1 Structure of an MQTT Control Packet  PAGEREF _Toc442180832 \h 16  HYPERLINK \l "_Toc442180833" 2.2 Fixed header  PAGEREF _Toc442180833 \h 16  HYPERLINK \l "_Toc442180834" 2.2.1 MQTT Control Packet type  PAGEREF _Toc442180834 \h 16  HYPERLINK \l "_Toc442180835" 2.2.2 Flags  PAGEREF _Toc442180835 \h 17  HYPERLINK \l "_Toc442180836" 2.2.3 Remaining Length  PAGEREF _Toc442180836 \h 18  HYPERLINK \l "_Toc442180837" 2.3 Variable header  PAGEREF _Toc442180837 \h 20  HYPERLINK \l "_Toc442180838" 2.3.1 Packet Identifier  PAGEREF _Toc442180838 \h 20  HYPERLINK \l "_Toc442180839" 2.4 Payload  PAGEREF _Toc442180839 \h 21  HYPERLINK \l "_Toc442180840" 3 MQTT Control Packets  PAGEREF _Toc442180840 \h 23  HYPERLINK \l "_Toc442180841" 3.1 CONNECT Client requests a connection to a Server  PAGEREF _Toc442180841 \h 23  HYPERLINK \l "_Toc442180842" 3.1.1 Fixed header  PAGEREF _Toc442180842 \h 23  HYPERLINK \l "_Toc442180843" 3.1.2 Variable header  PAGEREF _Toc442180843 \h 23  HYPERLINK \l "_Toc442180844" 3.1.3 Payload  PAGEREF _Toc442180844 \h 29  HYPERLINK \l "_Toc442180845" 3.1.4 Response  PAGEREF _Toc442180845 \h 30  HYPERLINK \l "_Toc442180846" 3.2 CONNACK Acknowledge connection request  PAGEREF _Toc442180846 \h 31  HYPERLINK \l "_Toc442180847" 3.2.1 Fixed header  PAGEREF _Toc442180847 \h 31  HYPERLINK \l "_Toc442180848" 3.2.2 Variable header  PAGEREF _Toc442180848 \h 31  HYPERLINK \l "_Toc442180849" 3.2.3 Payload  PAGEREF _Toc442180849 \h 33  HYPERLINK \l "_Toc442180850" 3.3 PUBLISH Publish message  PAGEREF _Toc442180850 \h 33  HYPERLINK \l "_Toc442180851" 3.3.1 Fixed header  PAGEREF _Toc442180851 \h 33  HYPERLINK \l "_Toc442180852" 3.3.2 Variable header  PAGEREF _Toc442180852 \h 35  HYPERLINK \l "_Toc442180853" 3.3.3 Payload  PAGEREF _Toc442180853 \h 36  HYPERLINK \l "_Toc442180854" 3.3.4 Response  PAGEREF _Toc442180854 \h 36  HYPERLINK \l "_Toc442180855" 3.3.5 Actions  PAGEREF _Toc442180855 \h 36  HYPERLINK \l "_Toc442180856" 3.4 PUBACK Publish acknowledgement  PAGEREF _Toc442180856 \h 37  HYPERLINK \l "_Toc442180857" 3.4.1 Fixed header  PAGEREF _Toc442180857 \h 37  HYPERLINK \l "_Toc442180858" 3.4.2 Variable header  PAGEREF _Toc442180858 \h 37  HYPERLINK \l "_Toc442180859" 3.4.3 Payload  PAGEREF _Toc442180859 \h 37  HYPERLINK \l "_Toc442180860" 3.4.4 Actions  PAGEREF _Toc442180860 \h 37  HYPERLINK \l "_Toc442180861" 3.5 PUBREC Publish received (QoS 2 publish received, part 1)  PAGEREF _Toc442180861 \h 38  HYPERLINK \l "_Toc442180862" 3.5.1 Fixed header  PAGEREF _Toc442180862 \h 38  HYPERLINK \l "_Toc442180863" 3.5.2 Variable header  PAGEREF _Toc442180863 \h 38  HYPERLINK \l "_Toc442180864" 3.5.3 Payload  PAGEREF _Toc442180864 \h 38  HYPERLINK \l "_Toc442180865" 3.5.4 Actions  PAGEREF _Toc442180865 \h 38  HYPERLINK \l "_Toc442180866" 3.6 PUBREL Publish release (QoS 2 publish received, part 2)  PAGEREF _Toc442180866 \h 38  HYPERLINK \l "_Toc442180867" 3.6.1 Fixed header  PAGEREF _Toc442180867 \h 38  HYPERLINK \l "_Toc442180868" 3.6.2 Variable header  PAGEREF _Toc442180868 \h 39  HYPERLINK \l "_Toc442180869" 3.6.3 Payload  PAGEREF _Toc442180869 \h 39  HYPERLINK \l "_Toc442180870" 3.6.4 Actions  PAGEREF _Toc442180870 \h 39  HYPERLINK \l "_Toc442180871" 3.7 PUBCOMP Publish complete (QoS 2 publish received, part 3)  PAGEREF _Toc442180871 \h 39  HYPERLINK \l "_Toc442180872" 3.7.1 Fixed header  PAGEREF _Toc442180872 \h 39  HYPERLINK \l "_Toc442180873" 3.7.2 Variable header  PAGEREF _Toc442180873 \h 40  HYPERLINK \l "_Toc442180874" 3.7.3 Payload  PAGEREF _Toc442180874 \h 40  HYPERLINK \l "_Toc442180875" 3.7.4 Actions  PAGEREF _Toc442180875 \h 40  HYPERLINK \l "_Toc442180876" 3.8 SUBSCRIBE - Subscribe to topics  PAGEREF _Toc442180876 \h 40  HYPERLINK \l "_Toc442180877" 3.8.1 Fixed header  PAGEREF _Toc442180877 \h 40  HYPERLINK \l "_Toc442180878" 3.8.2 Variable header  PAGEREF _Toc442180878 \h 40  HYPERLINK \l "_Toc442180879" 3.8.3 Payload  PAGEREF _Toc442180879 \h 41  HYPERLINK \l "_Toc442180880" 3.8.4 Response  PAGEREF _Toc442180880 \h 42  HYPERLINK \l "_Toc442180881" 3.9 SUBACK Subscribe acknowledgement  PAGEREF _Toc442180881 \h 43  HYPERLINK \l "_Toc442180882" 3.9.1 Fixed header  PAGEREF _Toc442180882 \h 44  HYPERLINK \l "_Toc442180883" 3.9.2 Variable header  PAGEREF _Toc442180883 \h 44  HYPERLINK \l "_Toc442180884" 3.9.3 Payload  PAGEREF _Toc442180884 \h 44  HYPERLINK \l "_Toc442180885" 3.10 UNSUBSCRIBE Unsubscribe from topics  PAGEREF _Toc442180885 \h 45  HYPERLINK \l "_Toc442180886" 3.10.1 Fixed header  PAGEREF _Toc442180886 \h 45  HYPERLINK \l "_Toc442180887" 3.10.2 Variable header  PAGEREF _Toc442180887 \h 45  HYPERLINK \l "_Toc442180888" 3.10.3 Payload  PAGEREF _Toc442180888 \h 46  HYPERLINK \l "_Toc442180889" 3.10.4 Response  PAGEREF _Toc442180889 \h 46  HYPERLINK \l "_Toc442180890" 3.11 UNSUBACK Unsubscribe acknowledgement  PAGEREF _Toc442180890 \h 47  HYPERLINK \l "_Toc442180891" 3.11.1 Fixed header  PAGEREF _Toc442180891 \h 47  HYPERLINK \l "_Toc442180892" 3.11.2 Variable header  PAGEREF _Toc442180892 \h 47  HYPERLINK \l "_Toc442180893" 3.11.3 Payload  PAGEREF _Toc442180893 \h 48  HYPERLINK \l "_Toc442180894" 3.12 PINGREQ PING request  PAGEREF _Toc442180894 \h 48  HYPERLINK \l "_Toc442180895" 3.12.1 Fixed header  PAGEREF _Toc442180895 \h 48  HYPERLINK \l "_Toc442180896" 3.12.2 Variable header  PAGEREF _Toc442180896 \h 48  HYPERLINK \l "_Toc442180897" 3.12.3 Payload  PAGEREF _Toc442180897 \h 48  HYPERLINK \l "_Toc442180898" 3.12.4 Response  PAGEREF _Toc442180898 \h 48  HYPERLINK \l "_Toc442180899" 3.13 PINGRESP PING response  PAGEREF _Toc442180899 \h 48  HYPERLINK \l "_Toc442180900" 3.13.1 Fixed header  PAGEREF _Toc442180900 \h 48  HYPERLINK \l "_Toc442180901" 3.13.2 Variable header  PAGEREF _Toc442180901 \h 49  HYPERLINK \l "_Toc442180902" 3.13.3 Payload  PAGEREF _Toc442180902 \h 49  HYPERLINK \l "_Toc442180903" 3.14 DISCONNECT Disconnect notification  PAGEREF _Toc442180903 \h 49  HYPERLINK \l "_Toc442180904" 3.14.1 Fixed header  PAGEREF _Toc442180904 \h 49  HYPERLINK \l "_Toc442180905" 3.14.2 Variable header  PAGEREF _Toc442180905 \h 49  HYPERLINK \l "_Toc442180906" 3.14.3 Payload  PAGEREF _Toc442180906 \h 49  HYPERLINK \l "_Toc442180907" 3.14.4 Response  PAGEREF _Toc442180907 \h 49  HYPERLINK \l "_Toc442180908" 4 Operational behavior  PAGEREF _Toc442180908 \h 51  HYPERLINK \l "_Toc442180909" 4.1 Storing state  PAGEREF _Toc442180909 \h 51  HYPERLINK \l "_Toc442180910" 4.1.1 Non normative example  PAGEREF _Toc442180910 \h 51  HYPERLINK \l "_Toc442180911" 4.2 Network Connections  PAGEREF _Toc442180911 \h 52  HYPERLINK \l "_Toc442180912" 4.3 Quality of Service levels and protocol flows  PAGEREF _Toc442180912 \h 52  HYPERLINK \l "_Toc442180913" 4.3.1 QoS 0: At most once delivery  PAGEREF _Toc442180913 \h 52  HYPERLINK \l "_Toc442180914" 4.3.2 QoS 1: At least once delivery  PAGEREF _Toc442180914 \h 53  HYPERLINK \l "_Toc442180915" 4.3.3 QoS 2: Exactly once delivery  PAGEREF _Toc442180915 \h 54  HYPERLINK \l "_Toc442180916" 4.4 Message delivery retry  PAGEREF _Toc442180916 \h 55  HYPERLINK \l "_Toc442180917" 4.5 Message receipt  PAGEREF _Toc442180917 \h 56  HYPERLINK \l "_Toc442180918" 4.6 Message ordering  PAGEREF _Toc442180918 \h 56  HYPERLINK \l "_Toc442180919" 4.7 Topic Names and Topic Filters  PAGEREF _Toc442180919 \h 57  HYPERLINK \l "_Toc442180920" 4.7.1 Topic wildcards  PAGEREF _Toc442180920 \h 57  HYPERLINK \l "_Toc442180921" 4.7.2 Topics beginning with $  PAGEREF _Toc442180921 \h 58  HYPERLINK \l "_Toc442180922" 4.7.3 Topic semantic and usage  PAGEREF _Toc442180922 \h 58  HYPERLINK \l "_Toc442180923" 4.8 Handling errors  PAGEREF _Toc442180923 \h 59  HYPERLINK \l "_Toc442180924" 5 Security  PAGEREF _Toc442180924 \h 60  HYPERLINK \l "_Toc442180925" 5.1 Introduction  PAGEREF _Toc442180925 \h 60  HYPERLINK \l "_Toc442180926" 5.2 MQTT solutions: security and certification  PAGEREF _Toc442180926 \h 60  HYPERLINK \l "_Toc442180927" 5.3 Lightweight cryptography and constrained devices  PAGEREF _Toc442180927 \h 61  HYPERLINK \l "_Toc442180928" 5.4 Implementation notes  PAGEREF _Toc442180928 \h 61  HYPERLINK \l "_Toc442180929" 5.4.1 Authentication of Clients by the Server  PAGEREF _Toc442180929 \h 61  HYPERLINK \l "_Toc442180930" 5.4.2 Authorization of Clients by the Server  PAGEREF _Toc442180930 \h 61  HYPERLINK \l "_Toc442180931" 5.4.3 Authentication of the Server by the Client  PAGEREF _Toc442180931 \h 61  HYPERLINK \l "_Toc442180932" 5.4.4 Integrity of Application Messages and Control Packets  PAGEREF _Toc442180932 \h 62  HYPERLINK \l "_Toc442180933" 5.4.5 Privacy of Application Messages and Control Packets  PAGEREF _Toc442180933 \h 62  HYPERLINK \l "_Toc442180934" 5.4.6 Non-repudiation of message transmission  PAGEREF _Toc442180934 \h 62  HYPERLINK \l "_Toc442180935" 5.4.7 Detecting compromise of Clients and Servers  PAGEREF _Toc442180935 \h 62  HYPERLINK \l "_Toc442180936" 5.4.8 Detecting abnormal behaviors  PAGEREF _Toc442180936 \h 63  HYPERLINK \l "_Toc442180937" 5.4.9 Other security considerations  PAGEREF _Toc442180937 \h 63  HYPERLINK \l "_Toc442180938" 5.4.10 Use of SOCKS  PAGEREF _Toc442180938 \h 64  HYPERLINK \l "_Toc442180939" 5.4.11 Security profiles  PAGEREF _Toc442180939 \h 64  HYPERLINK \l "_Toc442180940" 6 Using WebSocket as a network transport  PAGEREF _Toc442180940 \h 65  HYPERLINK \l "_Toc442180941" 6.1 IANA Considerations  PAGEREF _Toc442180941 \h 65  HYPERLINK \l "_Toc442180942" 7 Conformance  PAGEREF _Toc442180942 \h 66  HYPERLINK \l "_Toc442180943" 7.1 Conformance Targets  PAGEREF _Toc442180943 \h 66  HYPERLINK \l "_Toc442180944" 7.1.1 MQTT Server  PAGEREF _Toc442180944 \h 66  HYPERLINK \l "_Toc442180945" 7.1.2 MQTT Client  PAGEREF _Toc442180945 \h 66  HYPERLINK \l "_Toc442180946" Appendix A. Acknowledgements (non normative)  PAGEREF _Toc442180946 \h 68  HYPERLINK \l "_Toc442180947" Appendix B. Mandatory normative statements (non normative)  PAGEREF _Toc442180947 \h 70  HYPERLINK \l "_Toc442180948" Appendix C. Revision history (non normative)  PAGEREF _Toc442180948 \h 80  Table of Figures and Tables  TOC \o "1-5" \h \z \u  HYPERLINK \l "_Toc385349200" Figure 1.1 Structure of UTF-8 encoded strings  PAGEREF _Toc385349200 \h 13  HYPERLINK \l "_Figure_1.2_UTF-8_1" Figure 1.2 UTF-8 encoded string non normative example..14  HYPERLINK \l "_Toc385349205" Figure 2.1 Structure of an MQTT Control Packet  PAGEREF _Toc385349205 \h 16  HYPERLINK \l "_Toc385349207" Figure 2.2 - Fixed header format  PAGEREF _Toc385349207 \h 16  HYPERLINK \l "_Toc385349209" Table 2.1 - Control packet types  PAGEREF _Toc385349209 \h 16  HYPERLINK \l "_Toc385349211" Table 2.2 - Flag Bits  PAGEREF _Toc385349211 \h 17  HYPERLINK \l "_Toc385349213" Table 2.4 Size of Remaining Length field  PAGEREF _Toc385349213 \h 18  HYPERLINK \l "_Toc385349216" Figure 2.3 - Packet Identifier bytes  PAGEREF _Toc385349216 \h 20  HYPERLINK \l "_Toc385349217" Table 2.5 - Control Packets that contain a Packet Identifier  PAGEREF _Toc385349217 \h 20  HYPERLINK \l "_Toc385349219" Table 2.6 - Control Packets that contain a Payload  PAGEREF _Toc385349219 \h 21  HYPERLINK \l "_Toc385349223" Figure 3.1 CONNECT Packet fixed header  PAGEREF _Toc385349223 \h 23  HYPERLINK \l "_Toc385349226" Figure 3.2 - Protocol Name bytes  PAGEREF _Toc385349226 \h 23  HYPERLINK \l "_Toc385349228" Figure 3.3 - Protocol Level byte  PAGEREF _Toc385349228 \h 24  HYPERLINK \l "_Toc385349230" Figure 3.4 - Connect Flag bits  PAGEREF _Toc385349230 \h 24  HYPERLINK \l "_Toc385349238" Figure 3.5 Keep Alive bytes  PAGEREF _Toc385349238 \h 27  HYPERLINK \l "_Toc385349240" Figure 3.6 - Variable header non normative example  PAGEREF _Toc385349240 \h 28  HYPERLINK \l "_Toc385349247" Figure 3.7 - Password bytes  PAGEREF _Toc385349247 \h 30  HYPERLINK \l "_Toc385349251" Figure 3.8 CONNACK Packet fixed header  PAGEREF _Toc385349251 \h 31  HYPERLINK \l "_Toc385349253" Figure 3.9 CONNACK Packet variable header  PAGEREF _Toc385349253 \h 31  HYPERLINK \l "_Toc385349257" Table 3.1 Connect Return code values  PAGEREF _Toc385349257 \h 32  HYPERLINK \l "_Toc385349261" Figure 3.10 PUBLISH Packet fixed header  PAGEREF _Toc385349261 \h 33  HYPERLINK \l "_Toc385349264" Table 3.2 - QoS definitions  PAGEREF _Toc385349264 \h 34  HYPERLINK \l "_Toc385349270" Table 3.3 - Publish Packet non normative example  PAGEREF _Toc385349270 \h 35  HYPERLINK \l "_Toc385349271" Figure 3.11 - Publish Packet variable header non normative example  PAGEREF _Toc385349271 \h 36  HYPERLINK \l "_Toc385349274" Table 3.4 - Expected Publish Packet response  PAGEREF _Toc385349274 \h 36  HYPERLINK \l "_Toc385349278" Figure 3.12 - PUBACK Packet fixed header  PAGEREF _Toc385349278 \h 37  HYPERLINK \l "_Toc385349280" Figure 3.13 PUBACK Packet variable header  PAGEREF _Toc385349280 \h 37  HYPERLINK \l "_Toc385349285" Figure 3.14 PUBREC Packet fixed header  PAGEREF _Toc385349285 \h 38  HYPERLINK \l "_Toc385349287" Figure 3.15 PUBREC Packet variable header  PAGEREF _Toc385349287 \h 38  HYPERLINK \l "_Toc385349292" Figure 3.16 PUBREL Packet fixed header  PAGEREF _Toc385349292 \h 38  HYPERLINK \l "_Toc385349294" Figure 3.17 PUBREL Packet variable header  PAGEREF _Toc385349294 \h 39  HYPERLINK \l "_Toc385349299" Figure 3.18 PUBCOMP Packet fixed header  PAGEREF _Toc385349299 \h 39  HYPERLINK \l "_Toc385349301" Figure 3.19 PUBCOMP Packet variable header  PAGEREF _Toc385349301 \h 40  HYPERLINK \l "_Toc385349306" Figure 3.20 SUBSCRIBE Packet fixed header  PAGEREF _Toc385349306 \h 40  HYPERLINK \l "_Toc385349309" Figure 3.21 - Variable header with a Packet Identifier of 10, Non normative example  PAGEREF _Toc385349309 \h 41  HYPERLINK \l "_Toc385349311" Figure 3.22 SUBSCRIBE Packet payload format  PAGEREF _Toc385349311 \h 41  HYPERLINK \l "_Toc385349313" Table 3.5 - Payload non normative example  PAGEREF _Toc385349313 \h 42  HYPERLINK \l "_Toc385349314" Figure 3.23 - Payload byte format non normative example  PAGEREF _Toc385349314 \h 42  HYPERLINK \l "_Toc385349318" Figure 3.24 SUBACK Packet fixed header  PAGEREF _Toc385349318 \h 44  HYPERLINK \l "_Toc385349320" Figure 3.25 SUBACK Packet variable header  PAGEREF _Toc385349320 \h 44  HYPERLINK \l "_Toc385349322" Figure 3.26 SUBACK Packet payload format  PAGEREF _Toc385349322 \h 44  HYPERLINK \l "_Toc385349324" Table 3.6 - Payload non normative example  PAGEREF _Toc385349324 \h 45  HYPERLINK \l "_Toc385349325" Figure 3.27 - Payload byte format non normative example  PAGEREF _Toc385349325 \h 45  HYPERLINK \l "_Toc385349328" Figure 3.28 UNSUBSCRIBE Packet Fixed header  PAGEREF _Toc385349328 \h 45  HYPERLINK \l "_Toc385349330" Figure 3.29 UNSUBSCRIBE Packet variable header  PAGEREF _Toc385349330 \h 45  HYPERLINK \l "_Toc385349333" Table3.7 - Payload non normative example  PAGEREF _Toc385349333 \h 46  HYPERLINK \l "_Toc385349334" Figure 3.30 - Payload byte format non normative example  PAGEREF _Toc385349334 \h 46  HYPERLINK \l "_Toc385349338" Figure 3.31 UNSUBACK Packet fixed header  PAGEREF _Toc385349338 \h 47  HYPERLINK \l "_Toc385349340" Figure 3.32 UNSUBACK Packet variable header  PAGEREF _Toc385349340 \h 47  HYPERLINK \l "_Toc385349344" Figure 3.33 PINGREQ Packet fixed header  PAGEREF _Toc385349344 \h 48  HYPERLINK \l "_Toc385349350" Figure 3.34 PINGRESP Packet fixed header  PAGEREF _Toc385349350 \h 48  HYPERLINK \l "_Toc385349355" Figure 3.35 DISCONNECT Packet fixed header  PAGEREF _Toc385349355 \h 49  HYPERLINK \l "_Toc385349365" Figure 4.1 QoS 0 protocol flow diagram, non normative example  PAGEREF _Toc385349365 \h 52  HYPERLINK \l "_Toc385349367" Figure 4.2 QoS 1 protocol flow diagram, non normative example  PAGEREF _Toc385349367 \h 53  HYPERLINK \l "_Toc385349369" Figure 4.3 QoS 2 protocol flow diagram, non normative example  PAGEREF _Toc385349369 \h 54  HYPERLINK \l "_Toc385349403" Figure 6.1 - IANA WebSocket Identifier  PAGEREF _Toc385349403 \h 65  Introduction Organization of MQTT This specification is split into seven chapters:  HYPERLINK \l "_Introduction" Chapter 1 - Introduction  HYPERLINK \l "_MQTT_Control_Packet" Chapter 2 - MQTT Control Packet format  HYPERLINK \l "_MQTT_Control_Packets" Chapter 3 - MQTT Control Packets  HYPERLINK \l "_Operational_behavior" Chapter 4 - Operational behavior  HYPERLINK \l "_Security" Chapter 5 - Security  HYPERLINK \l "_Using_WebSocket_as" Chapter 6 - Using WebSocket as a network transport  HYPERLINK \l "_Conformance" Chapter 7 - Conformance Targets Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 HYPERLINK \l "anchor-RFC2119"[RFC2119]. Network Connection: A construct provided by the underlying transport protocol that is being used by MQTT. It connects the Client to the Server. It provides the means to send an ordered, lossless, stream of bytes in both directions. For examples see Section  REF _Ref368642907 \r \h 4.2. Application Message: The data carried by the MQTT protocol across the network for the application. When Application Messages are transported by MQTT they have an associated Quality of Service and a Topic Name. Client: A program or device that uses MQTT. A Client always establishes the Network Connection to the Server. It can Publish Application Messages that other Clients might be interested in. Subscribe to request Application Messages that it is interested in receiving. Unsubscribe to remove a request for Application Messages. Disconnect from the Server. Server: A program or device that acts as an intermediary between Clients which publish Application Messages and Clients which have made Subscriptions. A Server Accepts Network Connections from Clients. Accepts Application Messages published by Clients. Processes Subscribe and Unsubscribe requests from Clients. Forwards Application Messages that match Client Subscriptions. Subscription: A Subscription comprises a Topic Filter and a maximum QoS. A Subscription is associated with a single Session. A Session can contain more than one Subscription. Each Subscription within a session has a different Topic Filter. Topic Name: The label attached to an Application Message which is matched against the Subscriptions known to the Server. The Server sends a copy of the Application Message to each Client that has a matching Subscription. Topic Filter: An expression contained in a Subscription, to indicate an interest in one or more topics. A Topic Filter can include wildcard characters. Session: A stateful interaction between a Client and a Server. Some Sessions last only as long as the Network Connection, others can span multiple consecutive Network Connections between a Client and a Server. MQTT Control Packet: A packet of information that is sent across the Network Connection. The MQTT specification defines fourteen different types of Control Packet, one of which (the PUBLISH packet) is used to convey Application Messages. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  HYPERLINK "http://www.ietf.org/rfc/rfc2119.txt" http://www.ietf.org/rfc/rfc2119.txt [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003 http://www.ietf.org/rfc/rfc3629.txt [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.  HYPERLINK "http://www.ietf.org/rfc/rfc5246.txt" http://www.ietf.org/rfc/rfc5246.txt [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.  HYPERLINK "http://www.ietf.org/rfc/rfc6455.txt" http://www.ietf.org/rfc/rfc6455.txt [Unicode] The Unicode Consortium. The Unicode Standard.  HYPERLINK "http://www.unicode.org/versions/latest/" http://www.unicode.org/versions/latest/ Non normative references [RFC793] Postel, J. Transmission Control Protocol. STD 7, IETF RFC 793, September 1981.  HYPERLINK "http://www.ietf.org/rfc/rfc793.txt" http://www.ietf.org/rfc/rfc793.txt [AES] Advanced Encryption Standard (AES) (FIPS PUB 197).  HYPERLINK "http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf" http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf [DES] Data Encryption Standard (DES).  HYPERLINK "http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf" http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf [FIPS1402] Security Requirements for Cryptographic Modules (FIPS PUB 140-2)  HYPERLINK "http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf" http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf [IEEE 802.1AR] IEEE Standard for Local and metropolitan area networks - Secure Device Identity  HYPERLINK "http://standards.ieee.org/findstds/standard/802.1AR-2009.html" http://standards.ieee.org/findstds/standard/802.1AR-2009.html [ISO29192] ISO/IEC 29192-1:2012 Information technology -- Security techniques -- Lightweight cryptography -- Part 1: General  HYPERLINK "http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425" http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425 [MQTT NIST] MQTT supplemental publication, MQTT and the NIST Framework for Improving Critical Infrastructure Cybersecurity HYPERLINK "http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html"http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html [ HYPERLINK \l "_Normative_References" MQTTV31] MQTT V3.1 Protocol Specification.  HYPERLINK "http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html" http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html [NISTCSF] Improving Critical Infrastructure Cybersecurity Executive Order 13636  HYPERLINK "http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf" http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdf [NIST7628] NISTIR 7628 Guidelines for Smart Grid Cyber Security  HYPERLINK "http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf" http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf [NSAB] NSA Suite B Cryptography  HYPERLINK "http://www.nsa.gov/ia/programs/suiteb_cryptography/" http://www.nsa.gov/ia/programs/suiteb_cryptography/ [PCIDSS] PCI-DSS Payment Card Industry Data Security Standard  HYPERLINK "https://www.pcisecuritystandards.org/security_standards/" https://www.pcisecuritystandards.org/security_standards/ [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.  HYPERLINK "http://www.ietf.org/rfc/rfc1928.txt" http://www.ietf.org/rfc/rfc1928.txt [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.  HYPERLINK "http://www.ietf.org/rfc/rfc4511.txt" http://www.ietf.org/rfc/rfc4511.txt [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.  HYPERLINK "http://www.ietf.org/rfc/rfc5077.txt" http://www.ietf.org/rfc/rfc5077.txt [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.  HYPERLINK "http://www.ietf.org/rfc/rfc5280.txt" http://www.ietf.org/rfc/rfc5280.txt [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.  HYPERLINK "http://www.ietf.org/rfc/rfc6066.txt" http://www.ietf.org/rfc/rfc6066.txt [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.  HYPERLINK "http://www.ietf.org/rfc/rfc6749.txt" http://www.ietf.org/rfc/rfc6749.txt [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.  HYPERLINK "http://www.ietf.org/rfc/rfc6960.txt" http://www.ietf.org/rfc/rfc6960.txt [SARBANES] Sarbanes-Oxley Act of 2002.  HYPERLINK "http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm" http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm [USEUSAFEHARB] U.S.-EU Safe Harbor  HYPERLINK "http://export.gov/safeharbor/eu/eg_main_018365.asp" http://export.gov/safeharbor/eu/eg_main_018365.asp Data representations Bits Bits in a byte are labeled 7 through 0. Bit number 7 is the most significant bit, the least significant bit is assigned bit number 0. Integer data values Integer data values are 16 bits in big-endian order: the high order byte precedes the lower order byte. This means that a 16-bit word is presented on the network as Most Significant Byte (MSB), followed by Least Significant Byte (LSB). UTF-8 encoded strings Text fields in the Control Packets described later are encoded as UTF-8 strings. UTF-8 [ HYPERLINK \l "RFC3629" RFC3629]is an efficient encoding of Unicode [HYPERLINK \l "Unicode"Unicode] characters that optimizes the encoding of ASCII characters in support of text-based communications. Each of these strings is prefixed with a two byte length field that gives the number of bytes in a UTF-8 encoded string itself, as illustrated in  HYPERLINK \l "_Figure_1.1_Structure" Figure 1.1 Structure of UTF-8 encoded strings below. Consequently there is a limit on the size of a string that can be passed in one of these UTF-8 encoded string components; you cannot use a string that would encode to more than 65535 bytes. Unless stated otherwise all UTF-8 encoded strings can have any length in the range 0 to 65535 bytes. Figure 1.1 Structure of UTF-8 encoded strings Bit76543210byte 1String length MSBbyte 2String length LSBbyte 3 .UTF-8 Encoded Character Data, if length > 0. The character data in a UTF-8 encoded string MUST be well-formed UTF-8 as defined by the Unicode specification [ HYPERLINK \l "Unicode" Unicode] and restated in RFC 3629 [ HYPERLINK \l "RFC3629" RFC3629]. In particular this data MUST NOT include encodings of code points between U+D800 and U+DFFF. If a Server or Client receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection[MQTT-1.5.3-1]. A UTF-8 encoded string MUST NOT include an encoding of the null character U+0000. If a receiver (Server or Client) receives a Control Packet containing U+0000 it MUST close the Network Connection[MQTT-1.5.3-2]. The data SHOULD NOT include encodings of the Unicode [ HYPERLINK \l "Unicode" Unicode] code points listed below. If a receiver (Server or Client) receives a Control Packet containing any of them it MAY close the Network Connection: U+0001..U+001F control characters U+007F..U+009F control characters Code points defined in the Unicode specification [ HYPERLINK \l "Unicode" Unicode] to be non-characters (for example U+0FFFF) A UTF-8 encoded sequence 0xEF 0xBB 0xBF is always to be interpreted to mean U+FEFF ("ZERO WIDTH NO-BREAK SPACE") wherever it appears in a string and MUST NOT be skipped over or stripped off by a packet receiver[MQTT-1.5.3-3]. Non normative example For example, the string Ai which is LATIN CAPITAL Letter A followed by the code point U+2A6D4 (which represents a CJK IDEOGRAPH EXTENSION B character) is encoded as follows: Figure 1.2 UTF-8 encoded string non normative example Bit76543210byte 1String Length MSB (0x00)00000000byte 2String Length LSB (0x05)00000101byte 3A (0x41)01000001byte 4(0xF0)11110000byte 5(0xAA)10101010byte 6(0x9B)10011011byte 7(0x94)10010100 Editing conventions Text highlighted in Yellow within this specification identifies conformance statements. Each conformance statement has been assigned a reference in the format [MQTT-x.x.x-y]. MQTT Control Packet format Structure of an MQTT Control Packet The MQTT protocol works by exchanging a series of MQTT Control Packets in a defined way. This section describes the format of these packets. An MQTT Control Packet consists of up to three parts, always in the following order as illustrated in HYPERLINK \l "_Figure_2.1_-"Figure 2.1 - Structure of an MQTT Control Packet. Figure 2.1 Structure of an MQTT Control Packet Fixed header, present in all MQTT Control PacketsVariable header, present in some MQTT Control PacketsPayload, present in some MQTT Control PacketsFixed header Each MQTT Control Packet contains a fixed header.  HYPERLINK \l "_Figure_2.2_-" Figure 2.2 - Fixed header format illustrates the fixed header format. Figure 2.2 - Fixed header format Bit76543210byte 1MQTT Control Packet typeFlags specific to each MQTT Control Packet typebyte 2Remaining Length MQTT Control Packet type Position: byte 1, bits 7-4. Represented as a 4-bit unsigned value, the values are listed in  HYPERLINK \l "_Table_2.1_-" Table 2.1 - Control packet types. Table 2.1 - Control packet types NameValueDirection of flowDescriptionReserved0ForbiddenReservedCONNECT1Client to ServerClient request to connect to ServerCONNACK2Server to ClientConnect acknowledgmentPUBLISH3Client to Server or Server to ClientPublish messagePUBACK4Client to Server or Server to Client Publish acknowledgmentPUBREC5Client to Server or Server to Client Publish received (assured delivery part 1)PUBREL6Client to Server or Server to Client Publish release (assured delivery part 2)PUBCOMP7Client to Server or Server to Client Publish complete (assured delivery part 3)SUBSCRIBE8Client to ServerClient subscribe requestSUBACK9Server to ClientSubscribe acknowledgmentUNSUBSCRIBE10Client to ServerUnsubscribe requestUNSUBACK11Server to ClientUnsubscribe acknowledgmentPINGREQ12Client to ServerPING requestPINGRESP13Server to ClientPING responseDISCONNECT14Client to ServerClient is disconnectingReserved15ForbiddenReserved Flags The remaining bits [3-0] of byte 1 in the fixed header contain flags specific to each MQTT Control Packet type as listed in the  HYPERLINK \l "_Table_2.2_-" Table 2.2 - Flag Bits below. Where a flag bit is marked as Reserved in  HYPERLINK \l "_Table_2.2_-" Table 2.2 - Flag Bits, it is reserved for future use and MUST be set to the value listed in that table [MQTT-2.2.2-1]. If invalid flags are received, the receiver MUST close the Network Connection [MQTT-2.2.2-2]. See Section  REF _Ref381955543 \r \h 4.8 for details about handling errors. Table 2.2 - Flag Bits Control PacketFixed header flagsBit 3Bit 2Bit 1Bit 0CONNECTReserved0000CONNACKReserved0000PUBLISHUsed in MQTT 3.1.1DUP1QoS2QoS2RETAIN3PUBACKReserved0000PUBRECReserved0000PUBRELReserved0010PUBCOMPReserved0000SUBSCRIBEReserved0010SUBACKReserved0000UNSUBSCRIBEReserved0010UNSUBACKReserved0000PINGREQReserved0000PINGRESPReserved0000DISCONNECTReserved0000 DUP1 = Duplicate delivery of a PUBLISH Control Packet QoS2 = PUBLISH Quality of Service RETAIN3 = PUBLISH Retain flag See Section  REF _Ref384201650 \r \h 3.3.1 for a description of the DUP, QoS, and RETAIN flags in the PUBLISH Control Packet. Remaining Length Position: starts at byte 2. The Remaining Length is the number of bytes remaining within the current packet, including data in the variable header and the payload. The Remaining Length does not include the bytes used to encode the Remaining Length. The Remaining Length is encoded using a variable length encoding scheme which uses a single byte for values up to 127. Larger values are handled as follows. The least significant seven bits of each byte encode the data, and the most significant bit is used to indicate that there are following bytes in the representation. Thus each byte encodes 128 values and a "continuation bit". The maximum number of bytes in the Remaining Length field is four. Non normative comment For example, the number 64 decimal is encoded as a single byte, decimal value 64, hexadecimal 0x40. The number 321 decimal (= 65 + 2*128) is encoded as two bytes, least significant first. The first byte is 65+128 = 193. Note that the top bit is set to indicate at least one following byte. The second byte is 2. Non normative comment This allows applications to send Control Packets of size up to 268,435,455 (256 MB). The representation of this number on the wire is: 0xFF, 0xFF, 0xFF, 0x7F. HYPERLINK \l "_Table_2.4_Size"Table 2.4 shows the Remaining Length values represented by increasing numbers of bytes. Table 2.4 Size of Remaining Length field DigitsFromTo10 (0x00)127 (0x7F)2128 (0x80, 0x01)16 383 (0xFF, 0x7F)316 384 (0x80, 0x80, 0x01)2 097 151 (0xFF, 0xFF, 0x7F)42 097 152 (0x80, 0x80, 0x80, 0x01)268 435 455 (0xFF, 0xFF, 0xFF, 0x7F) Non normative comment The algorithm for encoding a non negative integer (X) into the variable length encoding scheme is as follows: do encodedByte = X MOD 128 X = X DIV 128 // if there are more data to encode, set the top bit of this byte if ( X > 0 ) encodedByte = encodedByte OR 128 endif 'output' encodedByte while ( X > 0 ) Where MOD is the modulo operator (% in C), DIV is integer division (/ in C), and OR is bit-wise or (| in C). Non normative comment The algorithm for decoding the Remaining Length field is as follows: multiplier = 1 value = 0 do encodedByte = 'next byte from stream' value += (encodedByte AND 127) * multiplier if (multiplier > 128*128*128) throw Error(Malformed Remaining Length) multiplier *= 128 while ((encodedByte AND 128) != 0) multiplier = 1 value = 0 do encodedByte = 'next byte from stream' value += (encodedByte AND 127) * multiplier multiplier *= 128 if (multiplier > 128*128*128) throw Error(Malformed Remaining Length) while ((encodedByte AND 128) != 0) where AND is the bit-wise and operator (& in C). When this algorithm terminates, value contains the Remaining Length value. Variable header Some types of MQTT Control Packets contain a variable header component. It resides between the fixed header and the payload. The content of the variable header varies depending on the Packet type. The Packet Identifier field of variable header is common in several packet types. Packet Identifier Figure 2.3 - Packet Identifier bytes Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSB The variable header component of many of the Control Packet types includes a 2 byte Packet Identifier field. These Control Packets are PUBLISH (where QoS > 0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK. SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) Control Packets MUST contain a non-zero 16-bit Packet Identifier [MQTT-2.3.1-1]. Each time a Client sends a new packet of one of these types it MUST assign it a currently unused Packet Identifier [MQTT-2.3.1-2]. If a Client re-sends a particular Control Packet, then it MUST use the same Packet Identifier in subsequent re-sends of that packet. The Packet Identifier becomes available for reuse after the Client has processed the corresponding acknowledgement packet. In the case of a QoS 1 PUBLISH this is the corresponding PUBACK; in the case of QoS 2 it is PUBCOMP. For SUBSCRIBE or UNSUBSCRIBE it is the corresponding SUBACK or UNSUBACK [MQTT-2.3.1-3]. The same conditions apply to a Server when it sends a PUBLISH with QoS > 0 [MQTT-2.3.1-4]. A PUBLISH Packet MUST NOT contain a Packet Identifier if its QoS value is set to 0 [MQTT-2.3.1-5]. A PUBACK, PUBREC or PUBREL Packet MUST contain the same Packet Identifier as the PUBLISH Packet that was originally sent [MQTT-2.3.1-6]. Similarly SUBACK and UNSUBACK MUST contain the Packet Identifier that was used in the corresponding SUBSCRIBE and UNSUBSCRIBE Packet respectively [MQTT-2.3.1-7]. Control Packets that require a Packet Identifier are listed in  HYPERLINK \l "_Table_2.5_-" Table 2.5 - Control Packets that contain a Packet Identifier. Table 2.5 - Control Packets that contain a Packet Identifier Control PacketPacket Identifier fieldCONNECTNOCONNACKNOPUBLISHYES (If QoS > 0)PUBACKYESPUBRECYESPUBRELYESPUBCOMPYESSUBSCRIBEYESSUBACKYESUNSUBSCRIBEYESUNSUBACKYESPINGREQNOPINGRESPNODISCONNECTNO The Client and Server assign Packet Identifiers independently of each other. As a result, Client Server pairs can participate in concurrent message exchanges using the same Packet Identifiers. Non normative comment It is possible for a Client to send a PUBLISH Packet with Packet Identifier 0x1234 and then receive a different PUBLISH with Packet Identifier 0x1234 from its Server before it receives a PUBACK for the PUBLISH that it sent. Client Server PUBLISH Packet Identifier=0x1234---( (--PUBLISH Packet Identifier=0x1234 PUBACK Packet Identifier=0x1234---( (--PUBACK Packet Identifier=0x1234 Payload Some MQTT Control Packets contain a payload as the final part of the packet, as described in Chapter  REF _Ref363142907 \r \h 3. In the case of the PUBLISH packet this is the Application Message.  HYPERLINK \l "_Table_2.6_-" Table 2.6 - Control Packets that contain a Payload lists the Control Packets that require a Payload. Table 2.6 - Control Packets that contain a Payload Control PacketPayloadCONNECTRequiredCONNACKNonePUBLISHOptionalPUBACKNonePUBRECNonePUBRELNonePUBCOMPNoneSUBSCRIBERequiredSUBACKRequiredUNSUBSCRIBERequiredUNSUBACKNonePINGREQNonePINGRESPNoneDISCONNECTNone MQTT Control Packets CONNECT Client requests a connection to a Server After a Network Connection is established by a Client to a Server, the first Packet sent from the Client to the Server MUST be a CONNECT Packet [MQTT-3.1.0-1]. A Client can only send the CONNECT Packet once over a Network Connection. The Server MUST process a second CONNECT Packet sent from a Client as a protocol violation and disconnect the Client [MQTT-3.1.0-2]. See section  REF _Ref381955543 \r \h 4.8 for information about handling errors. The payload contains one or more encoded fields. They specify a unique Client identifier for the Client, a Will topic, Will Message, User Name and Password. All but the Client identifier are optional and their presence is determined based on flags in the variable header. Fixed header Figure 3.1 CONNECT Packet fixed header Bit76543210byte 1MQTT Control Packet type (1)Reserved00010000byte 2Remaining Length Remaining Length field Remaining Length is the length of the variable header (10 bytes) plus the length of the Payload. It is encoded in the manner described in section  REF _Ref355703004 \r \h 2.2.3. Variable header The variable header for the CONNECT Packet consists of four fields in the following order: Protocol Name, Protocol Level, Connect Flags, and Keep Alive. Protocol Name Figure 3.2 - Protocol Name bytes Description76543210Protocol Namebyte 1Length MSB (0)00000000byte 2Length LSB (4)00000100byte 3M01001101byte 4Q01010001byte 5T01010100byte 6T01010100 The Protocol Name is a UTF-8 encoded string that represents the protocol name MQTT, capitalized as shown. The string, its offset and length will not be changed by future versions of the MQTT specification. If the protocol name is incorrect the Server MAY disconnect the Client, or it MAY continue processing the CONNECT packet in accordance with some other specification. In the latter case, the Server MUST NOT continue to process the CONNECT packet in line with this specification [MQTT-3.1.2-1]. Non normative comment Packet inspectors, such as firewalls, could use the Protocol Name to identify MQTT traffic. Protocol Level Figure 3.3 - Protocol Level byte Description76543210Protocol Levelbyte 7Level(4)00000100 The 8 bit unsigned value that represents the revision level of the protocol used by the Client. The value of the Protocol Level field for the version 3.1.1 of the protocol is 4 (0x04). The Server MUST respond to the CONNECT Packet with a CONNACK return code 0x01 (unacceptable protocol level) and then disconnect the Client if the Protocol Level is not supported by the Server [MQTT-3.1.2-2]. Connect Flags The Connect Flags byte contains a number of parameters specifying the behavior of the MQTT connection. It also indicates the presence or absence of fields in the payload. Figure 3.4 - Connect Flag bits Bit76543210User Name FlagPassword FlagWill RetainWill QoSWill FlagClean SessionReservedbyte 8XXXXXXX0The Server MUST validate that the reserved flag in the CONNECT Control Packet is set to zero and disconnect the Client if it is not zero [MQTT-3.1.2-3]. Clean Session Position: bit 1 of the Connect Flags byte. This bit specifies the handling of the Session state. The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state. If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected [MQTT-3.1.2-4]. After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state [ HYPERLINK "https://tools.oasis-open.org/issues/browse/MQTT-3" \o "Keep alive interval grace period." MQTT-3.1.2-5]. It MAY also store QoS 0 messages that meet the same criteria. If CleanSession is set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this Session MUST NOT be reused in any subsequent Session [MQTT-3.1.2-6]. The Session state in the Client consists of: QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged. QoS 2 messages which have been received from the Server, but have not been completely acknowledged. The Session state in the Server consists of: The existence of a Session, even if the rest of the Session state is empty. The Clients subscriptions. QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged. QoS 1 and QoS 2 messages pending transmission to the Client. QoS 2 messages which have been received from the Client, but have not been completely acknowledged. Optionally, QoS 0 messages pending transmission to the Client. Retained messages do not form part of the Session state in the Server, they MUST NOT be deleted when the Session ends [MQTT-3.1.2.7]. See Section  REF _Ref369188333 \r \h 4.1 for details and limitations of stored state. When CleanSession is set to 1 the Client and Server need not process the deletion of state atomically. Non normative comment To ensure consistent state in the event of a failure, the Client should repeat its attempts to connect with CleanSession set to 1, until it connects successfully. Non normative comment Typically, a Client will always connect using CleanSession set to 0 or CleanSession set to 1 and not swap between the two values. The choice will depend on the application. A Client using CleanSession set to 1 will not receive old Application Messages and has to subscribe afresh to any topics that it is interested in each time it connects. A Client using CleanSession set to 0 will receive all QoS 1 or QoS 2 messages that were published while it was disconnected. Hence, to ensure that you do not lose messages while disconnected, use QoS 1 or QoS 2 with CleanSession set to 0. Non normative comment When a Client connects with CleanSession set to 0, it is requesting that the Server maintain its MQTT session state after it disconnects. Clients should only connect with CleanSession set to 0, if they intend to reconnect to the Server at some later point in time. When a Client has determined that it has no further use for the session it should do a final connect with CleanSession set to 1 and then disconnect. Will Flag Position: bit 2 of the Connect Flags. If the Will Flag is set to 1 this indicates that, if the Connect request is accepted, a Will Message MUST be stored on the Server and associated with the Network Connection. The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet [MQTT-3.1.2-8]. Situations in which the Will Message is published include, but are not limited to: An I/O error or network failure detected by the Server. The Client fails to communicate within the Keep Alive time. The Client closes the Network Connection without first sending a DISCONNECT Packet. The Server closes the Network Connection because of a protocol error. If the Will Flag is set to 1, the Will QoS and Will Retain fields in the Connect Flags will be used by the Server, and the Will Topic and Will Message fields MUST be present in the payload [MQTT-3.1.2-9]. The Will Message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client [MQTT-3.1.2-10]. If the Will Flag is set to 0 the Will QoS and Will Retain fields in the Connect Flags MUST be set to zero and the Will Topic and Will Message fields MUST NOT be present in the payload [MQTT-3.1.2-11]. If the Will Flag is set to 0, a Will Message MUST NOT be published when this Network Connection ends [MQTT-3.1.2-12]. The Server SHOULD publish Will Messages promptly. In the case of a Server shutdown or failure the server MAY defer publication of Will Messages until a subsequent restart. If this happens there might be a delay between the time the server experienced failure and a Will Message being published. Will QoS Position: bits 4 and 3 of the Connect Flags. These two bits specify the QoS level to be used when publishing the Will Message. If the Will Flag is set to 0, then the Will QoS MUST be set to 0(0x00) [MQTT-3.1.2-13]. If the Will Flag is set to 1, the value of Will QoS can be 0 (0x00), 1 (0x01), or 2 (0x02). It MUST NOT be 3 (0x03) [MQTT-3.1.2-14]. Will Retain Position: bit 5 of the Connect Flags. This bit specifies if the Will Message is to be Retained when it is published. If the Will Flag is set to 0, then the Will Retain Flag MUST be set to 0 [MQTT-3.1.2-15]. If the Will Flag is set to 1: If Will Retain is set to 0, the Server MUST publish the Will Message as a non-retained message [MQTT-3.1.2-16]. If Will Retain is set to 1, the Server MUST publish the Will Message as a retained message [MQTT-3.1.2-17]. User Name Flag Position: bit 7 of the Connect Flags. If the User Name Flag is set to 0, a user name MUST NOT be present in the payload [MQTT-3.1.2-18]. If the User Name Flag is set to 1, a user name MUST be present in the payload [MQTT-3.1.2-19]. Password Flag Position: bit 6 of the Connect Flags byte. If the Password Flag is set to 0, a password MUST NOT be present in the payload [MQTT-3.1.2-20]. If the Password Flag is set to 1, a password MUST be present in the payload [MQTT-3.1.2-21]. If the User Name Flag is set to 0, the Password Flag MUST be set to 0 [MQTT-3.1.2-22]. Keep Alive Figure 3.5 Keep Alive bytes Bit76543210byte 9Keep Alive MSBbyte 10Keep Alive LSB The Keep Alive is a time interval measured in seconds. Expressed as a 16-bit word, it is the maximum time interval that is permitted to elapse between the point at which the Client finishes transmitting one Control Packet and the point it starts sending the next. It is the responsibility of the Client to ensure that the interval between Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other Control Packets, the Client MUST send a PINGREQ Packet [MQTT-3.1.2-23]. The Client can send PINGREQ at any time, irrespective of the Keep Alive value, and use the PINGRESP to determine that the network and the Server are working. If the Keep Alive value is non-zero and the Server does not receive a Control Packet from the Client within one and a half times the Keep Alive time period, it MUST disconnect the Network Connection to the Client as if the network had failed [MQTT-3.1.2-24]. If a Client does not receive a PINGRESP Packet within a reasonable amount of time after it has sent a PINGREQ, it SHOULD close the Network Connection to the Server. A Keep Alive value of zero (0) has the effect of turning off the keep alive mechanism. This means that, in this case, the Server is not required to disconnect the Client on the grounds of inactivity. Note that a Server is permitted to disconnect a Client that it determines to be inactive or non-responsive at any time, regardless of the Keep Alive value provided by that Client. Non normative comment The actual value of the Keep Alive is application specific; typically this is a few minutes. The maximum value is 18 hours 12 minutes and 15 seconds. Variable header non normative example Figure 3.6 - Variable header non normative example Description76543210Protocol Namebyte 1Length MSB (0)00000000byte 2Length LSB (4)00000100byte 3M01001101byte 4Q01010001byte 5T01010100byte 6T01010100Protocol LevelDescription76543210byte 7Level (4)00000100Connect Flags byte 8User 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 0Keep Alivebyte 9Keep Alive MSB (0)00000000byte 10Keep Alive LSB (10)00001010 Payload The payload of the CONNECT Packet contains one or more length-prefixed fields, whose presence is determined by the flags in the variable header. These fields, if present, MUST appear in the order Client Identifier, Will Topic, Will Message, User Name, Password [MQTT-3.1.3-1]. Client Identifier The Client Identifier (ClientId) identifies the Client to the Server. Each Client connecting to the Server has a unique ClientId. The ClientId MUST be used by Clients and by Servers to identify state that they hold relating to this MQTT Session between the Client and the Server [MQTT-3.1.3-2]. The Client Identifier (ClientId) MUST be present and MUST be the first field in the CONNECT packet payload [MQTT-3.1.3-3]. The ClientId MUST be a UTF-8 encoded string as defined in Section  REF _Ref374438163 \r \h 1.5.3 [MQTT-3.1.3-4]. The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" [MQTT-3.1.3-5]. The Server MAY allow ClientIds that contain more than 23 encoded bytes. The Server MAY allow ClientIds that contain characters not included in the list given above. A Server MAY allow a Client to supply a ClientId that has a length of zero bytes, however if it does so the Server MUST treat this as a special case and assign a unique ClientId to that Client. It MUST then process the CONNECT packet as if the Client had provided that unique ClientId [MQTT-3.1.3-6]. If the Client supplies a zero-byte ClientId, the Client MUST also set CleanSession to 1 [MQTT-3.1.3-7]. If the Client supplies a zero-byte ClientId with CleanSession set to 0, the Server MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection [MQTT-3.1.3-8]. If the Server rejects the ClientId it MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection [MQTT-3.1.3-9]. Non normative comment A Client implementation could provide a convenience method to generate a random ClientId. Use of such a method should be actively discouraged when the CleanSession is set to 0. Will Topic If the Will Flag is set to 1, the Will Topic is the next field in the payload. The Will Topic MUST be a UTF-8 encoded string as defined in Section  REF _Ref374438163 \r \h 1.5.3 [MQTT-3.1.3-10]. Will Message If the Will Flag is set to 1 the Will Message is the next field in the payload. The Will Message defines the Application Message that is to be published to the Will Topic as described in Section  REF _Ref363648298 \r \h 3.1.2.5. This field consists of a two byte length followed by the payload for the Will Message expressed as a sequence of zero or more bytes. The length gives the number of bytes in the data that follows and does not include the 2 bytes taken up by the length itself. When the Will Message is published to the Will Topic its payload consists only of the data portion of this field, not the first two length bytes. User Name If the User Name Flag is set to 1, this is the next field in the payload. The User Name MUST be a UTF-8 encoded string as defined in Section  REF _Ref374438163 \r \h 1.5.3 [MQTT-3.1.3-11]. It can be used by the Server for authentication and authorization. Password If the Password Flag is set to 1, this is the next field in the payload. The Password field contains 0 to 65535 bytes of binary data prefixed with a two byte length field which indicates the number of bytes used by the binary data (it does not include the two bytes taken up by the length field itself). Figure 3.7 - Password bytes Bit76543210byte 1Data length MSBbyte 2Data length LSBbyte 3 .Data, if length > 0. Response Note that a Server MAY support multiple protocols (including earlier versions of this protocol) on the same TCP port or other network endpoint. If the Server determines that the protocol is MQTT 3.1.1 then it validates the connection attempt as follows. If the Server does not receive a CONNECT Packet within a reasonable amount of time after the Network Connection is established, the Server SHOULD close the connection. The Server MUST validate that the CONNECT Packet conforms to section  REF _Ref363033523 \r \h  \* MERGEFORMAT 3.1 and close the Network Connection without sending a CONNACK if it does not conform [MQTT-3.1.4-1]. The Server MAY check that the contents of the CONNECT Packet meet any further restrictions and MAY perform authentication and authorization checks. If any of these checks fail, it SHOULD send an appropriate CONNACK response with a non-zero return code as described in section  REF _Ref362964779 \r \h 3.2 and it MUST close the Network Connection. If validation is successful the Server performs the following steps. If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client [MQTT-3.1.4-2]. The Server MUST perform the processing of CleanSession that is described in section  REF _Ref362965194 \r \h  \* MERGEFORMAT 3.1.2.4 [MQTT-3.1.4-3]. The Server MUST acknowledge the CONNECT Packet with a CONNACK Packet containing a zero return code [MQTT-3.1.4-4]. Start message delivery and keep alive monitoring. Clients are allowed to send further Control Packets immediately after sending a CONNECT Packet; Clients need not wait for a CONNACK Packet to arrive from the Server. If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT Packet [MQTT-3.1.4-5]. Non normative comment Clients typically wait for a CONNACK Packet, However, if the Client exploits its freedom to send Control Packets before it receives a CONNACK,it might simplify the Client implementation as it does not have to police the connected state. The Client accepts that any data that it sends before it receives a CONNACK packet from the Serverwill not be processed if the Server rejects the connection. CONNACK Acknowledge connection request The CONNACK Packet is the packet sent by the Server in response to a CONNECT Packet received from a Client. The first packet sent from the Server to the Client MUST be a CONNACK Packet [MQTT-3.2.0-1]. If the Client does not receive a CONNACK Packet from the Server within a reasonable amount of time, the Client SHOULD close the Network Connection. A "reasonable" amount of time depends on the type of application and the communications infrastructure. Fixed header The fixed header format is illustrated in  HYPERLINK \l "_Figure_3.8_" Figure 3.8 CONNACK Packet fixed header. Figure 3.8 CONNACK Packet fixed header Bit76543210byte 1MQTT Control Packet Type (2)Reserved00100000byte 2Remaining Length (2)00000010 Remaining Length field This is the length of the variable header. For the CONNACK Packet this has the value 2. Variable header The variable header format is illustrated in  REF _Ref383984522 \h  \* MERGEFORMAT Figure 3.9 CONNACK Packet variable header. Figure 3.9 CONNACK Packet variable header Description76543210Connect Acknowledge FlagsReservedSP1byte 10000000XConnect Return codebyte 2XXXXXXXXConnect Acknowledge Flags Byte 1 is the "Connect Acknowledge Flags". Bits 7-1 are reserved and MUST be set to 0. Bit 0 (SP1) is the Session Present Flag. Session Present Position: bit 0 of the Connect Acknowledge Flags. If the Server accepts a connection with CleanSession set to 1, the Server MUST set Session Present to 0 in the CONNACK packet in addition to setting a zero return code in the CONNACK packet [MQTT-3.2.2-1]. If the Server accepts a connection with CleanSession set to 0, the value set in Session Present depends on whether the Server already has stored Session state for the supplied client ID. If the Server has stored Session state, it MUST set SessionPresent to 1 in the CONNACK packet [MQTT-3.2.2-2]. If the Server does not have stored Session state, it MUST set Session Present to 0 in the CONNACK packet. This is in addition to setting a zero return code in the CONNACK packet [MQTT-3.2.2-3]. The Session Present flag enables a Client to establish whether the Client and Server have a consistent view about whether there is already stored Session state. Once the initial setup of a Session is complete, a Client with stored Session state will expect the Server to maintain its stored Session state. In the event that the value of Session Present received by the Client from the Server is not as expected, the Client can choose whether to proceed with the Session or to disconnect. The Client can discard the Session state on both Client and Server by disconnecting, connecting with Clean Session set to 1 and then disconnecting again. If a server sends a CONNACK packet containing a non-zero return code it MUST set Session Present to 0 [MQTT-3.2.2-4]. Connect Return code Byte 2 in the Variable header. The values for the one byte unsigned Connect Return code field are listed in  HYPERLINK \l "_Table_3.1_-" Table 3.1 Connect Return code values. If a well formed CONNECT Packet is received by the Server, but the Server is unable to process it for some reason, then the Server SHOULD attempt to send a CONNACK packet containing the appropriate non-zero Connect return code from this table. If a server sends a CONNACK packet containing a non-zero return code it MUST then close the Network Connection [MQTT-3.2.2-5]. Table 3.1 Connect Return code values ValueReturn Code ResponseDescription00x00 Connection AcceptedConnection accepted10x01 Connection Refused, unacceptable protocol versionThe Server does not support the level of the MQTT protocol requested by the Client20x02 Connection Refused, identifier rejectedThe Client identifier is correct UTF-8 but not allowed by the Server30x03 Connection Refused, Server unavailableThe Network Connection has been made but the MQTT service is unavailable40x04 Connection Refused, bad user name or passwordThe data in the user name or password is malformed50x05 Connection Refused, not authorizedThe Client is not authorized to connect6-255Reserved for future use If none of the return codes listed in  REF _Ref383985930 \h  \* MERGEFORMAT Table 3.1 Connect Return code values are deemed applicable, then the Server MUST close the Network Connection without sending a CONNACK [MQTT-3.2.2-6]. Payload The CONNACK Packet has no payload. PUBLISH Publish message A PUBLISH Control Packet is sent from a Client to a Server or from Server to a Client to transport an Application Message. Fixed header  REF _Ref383984666 \h Figure 3.10 PUBLISH Packet fixed header illustrates the fixed header format: Figure 3.10 PUBLISH Packet fixed header Bit76543210byte 1MQTT Control Packet type (3)DUP flagQoS levelRETAIN0011XXXXbyte 2Remaining Length DUP Position: byte 1, bit 3. If the DUP flag is set to 0, it indicates that this is the first occasion that the Client or Server has attempted to send this MQTT PUBLISH Packet. If the DUP flag is set to 1, it indicates that this might be re-delivery of an earlier attempt to send the Packet. The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver a PUBLISH Packet [MQTT-3.3.1.-1]. The DUP flag MUST be set to 0 for all QoS 0 messages [MQTT-3.3.1-2]. The value of the DUP flag from an incoming PUBLISH packet is not propagated when the PUBLISH Packet is sent to subscribers by the Server. The DUP flag in the outgoing PUBLISH packet is set independently to the incoming PUBLISH packet, its value MUST be determined solely by whether the outgoing PUBLISH packet is a retransmission [MQTT-3.3.1-3]. Non normative comment The recipient of a Control Packet that contains the DUP flag set to 1 cannot assume that it has seen an earlier copy of this packet. Non normative comment It is important to note that the DUP flag refers to the Control Packet itself and not to the Application Message that it contains. When using QoS 1, it is possible for a Client to receive a PUBLISH Packet with DUP flag set to 0 that contains a repetition of an Application Message that it received earlier, but with a different Packet Identifier. Section  REF _Ref363041167 \r \h 2.3.1 provides more information about Packet Identifiers. QoS Position: byte 1, bits 2-1. This field indicates the level of assurance for delivery of an Application Message. The QoS levels are listed in the HYPERLINK \l "_Table_3.11_-"Table 3.2 - QoS definitions, below. Table 3.2 - QoS definitions QoS valueBit 2bit 1Description000At most once delivery101At least once delivery210Exactly once delivery-11Reserved must not be usedA PUBLISH Packet MUST NOT have both QoS bits set to 1. If a Server or Client receives a PUBLISH Packet which has both QoS bits set to 1 it MUST close the Network Connection[MQTT-3.3.1-4]. RETAIN Position: byte 1, bit 0. If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a Client to a Server, the Server MUST store the Application Message and its QoS, so that it can be delivered to future subscribers whose subscriptions match its topic name [MQTT-3.3.1-5]. When a new subscription is established, the last retained message, if any, on each matching topic name MUST be sent to the subscriber [MQTT-3.3.1-6]. If the Server receives a QoS 0 message with the RETAIN flag set to 1 it MUST discard any message previously retained for that topic. It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time - if this happens there will be no retained message for that topic [MQTT-3.3.1-7]. See Section  REF _Ref369188333 \r \h 4.1 for more information on storing state. When sending a PUBLISH Packet to a Client the Server MUST set the RETAIN flag to 1 if a message is sent as a result of a new subscription being made by a Client [MQTT-3.3.1-8]. It MUST set the RETAIN flag to 0 when a PUBLISH Packet is sent to a Client because it matches an established subscription regardless of how the flag was set in the message it received [MQTT-3.3.1-9]. A PUBLISH Packet with a RETAIN flag set to 1 and a payload containing zero bytes will be processed as normal by the Server and sent to Clients with a subscription matching the topic name. Additionally any existing retained message with the same topic name MUST be removed and any future subscribers for the topic will not receive a retained message [MQTT-3.3.1-10]. As normal means that the RETAIN flag is not set in the message received by existing Clients. A zero byte retained message MUST NOT be stored as a retained message on the Server [MQTT-3.3.1-11]. If the RETAIN flag is 0, in a PUBLISH Packet sent by a Client to a Server, the Server MUST NOT store the message and MUST NOT remove or replace any existing retained message [MQTT-3.3.1-12]. Non normative comment Retained messages are useful where publishers send state messages on an irregular basis. A new subscriber will receive the most recent state. Remaining Length field This is the length of variable header plus the length of the payload. Variable header The variable header contains the following fields in the order: Topic Name, Packet Identifier. Topic Name The Topic Name identifies the information channel to which payload data is published. The Topic Name MUST be present as the first field in the PUBLISH Packet Variable header. It MUST be a UTF-8 encoded string [MQTT-3.3.2-1] as defined in section  REF _Ref374438163 \r \h 1.5.3. The Topic Name in the PUBLISH Packet MUST NOT contain wildcard characters [MQTT-3.3.2-2]. The Topic Name in a PUBLISH Packet sent by a Server to a subscribing Client MUST match the Subscriptions Topic Filter according to the matching process defined in Section  REF _Ref374621403 \r \h  \* MERGEFORMAT 4.7 [MQTT-3.3.2-3]. However, since the Server is permitted to override the Topic Name, it might not be the same as the Topic Name in the original PUBLISH Packet. Packet Identifier The Packet Identifier field is only present in PUBLISH Packets where the QoS level is 1 or 2. Section  REF _Ref363041167 \r \h 2.3.1 provides more information about Packet Identifiers. Variable header non normative example  HYPERLINK \l "_Figure_3.11_-" Figure 3.11 - Publish Packet variable header non normative example illustrates an example variable header for the PUBLISH Packet briefly described in  HYPERLINK \l "_Table_3.2_-" Table 3.3 - Publish Packet non normative example. Table 3.3 - Publish Packet non normative example FieldValueTopic Namea/bPacket Identifier10 Figure 3.11 - Publish Packet variable header non normative example Description76543210Topic Namebyte 1Length MSB (0)00000000byte 2Length LSB (3)00000011byte 3a (0x61)01100001byte 4/ (0x2F)00101111byte 5b (0x62)01100010Packet Identifierbyte 6Packet Identifier MSB (0)00000000byte 7Packet Identifier LSB (10)00001010 Payload The Payload contains the Application Message that is being published. The content and format of the data is application specific. The length of the payload can be calculated by subtracting the length of the variable header from the Remaining Length field that is in the Fixed Header. It is valid for a PUBLISH Packet to contain a zero length payload. Response The receiver of a PUBLISH Packet MUST respond according to  HYPERLINK \l "_Table_3.3_-" Table 3.4 - Expected Publish Packet response as determined by the QoS in the PUBLISH Packet [MQTT-3.3.4-1]. Table 3.4 - Expected Publish Packet response QoS LevelExpected ResponseQoS 0NoneQoS 1PUBACK PacketQoS 2PUBREC Packet Actions The Client uses a PUBLISH Packet to send an Application Message to the Server, for distribution to Clients with matching subscriptions. The Server uses a PUBLISH Packet to send an Application Message to each Client which has a matching subscription. When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Clients subscriptions to overlap so that a published message might match multiple filters. In this case the Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions [MQTT-3.3.5-1]. In addition, the Server MAY deliver further copies of the message, one for each additional matching subscription and respecting the subscriptions QoS in each case. The action of the recipient when it receives a PUBLISH Packet depends on the QoS level as described in Section  REF _Ref363045966 \r \h 4.3. If a Server implementation does not authorize a PUBLISH to be performed by a Client; it has no way of informing that Client. It MUST either make a positive acknowledgement, according to the normal QoS rules, or close the Network Connection [MQTT-3.3.5-2]. PUBACK Publish acknowledgement A PUBACK Packet is the response to a PUBLISH Packet with QoS level 1. Fixed header Figure 3.12 - PUBACK Packet fixed header Bit76543210byte 1MQTT Control Packet type (4)Reserved01000000byte 2Remaining Length (2)00000010 Remaining Length field This is the length of the variable header. For the PUBACK Packet this has the value 2. Variable header This contains the Packet Identifier from the PUBLISH Packet that is being acknowledged. Figure 3.13 PUBACK Packet variable header Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSB Payload The PUBACK Packet has no payload. Actions This is fully described in Section  REF _Ref384138490 \r \h 4.3.2. PUBREC Publish received (QoS 2 publish received, part 1) A PUBREC Packet is the response to a PUBLISH Packet with QoS 2. It is the second packet of the QoS 2 protocol exchange. Fixed header Figure 3.14 PUBREC Packet fixed header Bit76543210byte 1MQTT Control Packet type (5)Reserved01010000byte 2Remaining Length (2)00000010 Remaining Length field This is the length of the variable header. For the PUBREC Packet this has the value 2. Variable header The variable header contains the Packet Identifier from the PUBLISH Packet that is being acknowledged. Figure 3.15 PUBREC Packet variable header Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSB Payload The PUBREC Packet has no payload. Actions This is fully described in Section  REF _Ref384138602 \r \h 4.3.3. PUBREL Publish release (QoS 2 publish received, part 2) A PUBREL Packet is the response to a PUBREC Packet. It is the third packet of the QoS 2 protocol exchange. Fixed header Figure 3.16 PUBREL Packet fixed header Bit76543210byte 1MQTT Control Packet type (6)Reserved01100010byte 2Remaining Length (2)00000010 Bits 3,2,1 and 0 of the fixed header in the PUBREL Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection [MQTT-3.6.1-1]. Remaining Length field This is the length of the variable header. For the PUBREL Packet this has the value 2. Variable header The variable header contains the same Packet Identifier as the PUBREC Packet that is being acknowledged. Figure 3.17 PUBREL Packet variable header Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSB Payload The PUBREL Packet has no payload. Actions This is fully described in Section  REF _Ref384138787 \r \h 4.3.3. PUBCOMP Publish complete (QoS 2 publish received, part 3) The PUBCOMP Packet is the response to a PUBREL Packet. It is the fourth and final packet of the QoS 2 protocol exchange. Fixed header Figure 3.18 PUBCOMP Packet fixed header Bit76543210byte 1MQTT Control Packet type (7)Reserved01110000byte 2Remaining Length (2)00000010 Remaining Length field This is the length of the variable header. For the PUBCOMP Packet this has the value 2. Variable header The variable header contains the same Packet Identifier as the PUBREL Packet that is being acknowledged. Figure 3.19 PUBCOMP Packet variable header Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSB Payload The PUBCOMP Packet has no payload. Actions This is fully described in Section  REF _Ref384138988 \r \h 4.3.3. SUBSCRIBE - Subscribe to topics The SUBSCRIBE Packet is sent from the Client to the Server to create one or more Subscriptions. Each Subscription registers a Clients interest in one or more Topics. The Server sends PUBLISH Packets to the Client in order to forward Application Messages that were published to Topics that match these Subscriptions. The SUBSCRIBE Packet also specifies (for each Subscription) the maximum QoS with which the Server can send Application Messages to the Client. Fixed header Figure 3.20 SUBSCRIBE Packet fixed header Bit76543210byte 1MQTT Control Packet type (8)Reserved10000010byte 2Remaining Length Bits 3,2,1 and 0 of the fixed header of the SUBSCRIBE Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection [MQTT-3.8.1-1]. Remaining Length field This is the length of variable header (2 bytes) plus the length of the payload. Variable header The variable header contains a Packet Identifier. Section  REF _Ref363041167 \r \h 2.3.1 provides more information about Packet Identifiers. Variable header non normative example  HYPERLINK \l "_Figure_3.21_-" Figure 3.21 shows a variable header with Packet Identifier set to 10. Figure 3.21 - Variable header with a Packet Identifier of 10, Non normative example Description76543210Packet Identifierbyte 1 Packet Identifier MSB (0)00000000byte 2Packet Identifier LSB (10)00001010 Payload The payload of a SUBSCRIBE Packet contains a list of Topic Filters indicating the Topics to which the Client wants to subscribe. The Topic Filters in a SUBSCRIBE packet payload MUST be UTF-8 encoded strings as defined in Section  REF _Ref374438163 \r \h  \* MERGEFORMAT 1.5.3 [MQTT-3.8.3-1]. A Server SHOULD support Topic filters that contain the wildcard characters defined in Section  HYPERLINK \l "_Topic_wildcards" 4.7.1. If it chooses not to support topic filters that contain wildcard characters it MUST reject any Subscription request whose filter contains them [MQTT-3.8.3-2]. Each filter is followed by a byte called the Requested QoS. This gives the maximum QoS level at which the Server can send Application Messages to the Client. The payload of a SUBSCRIBE packet MUST contain at least one Topic Filter / QoS pair. A SUBSCRIBE packet with no payload is a protocol violation [MQTT-3.8.3-3]. See section  REF _Ref381955543 \r \h 4.8 for information about handling errors. The requested maximum QoS field is encoded in the byte following each UTF-8 encoded topic name, and these Topic Filter / QoS pairs are packed contiguously. Figure 3.22 SUBSCRIBE Packet payload format Description76543210Topic Filterbyte 1Length MSBbyte 2Length LSBbytes 3..NTopic FilterRequested QoSReservedQoSbyte N+1000000XX The upper 6 bits of the Requested QoS byte are not used in the current version of the protocol. They are reserved for future use. The Server MUST treat a SUBSCRIBE packet as malformed and close the Network Connection if any of Reserved bits in the payload are non-zero, or QoS is not 0,1 or 2 [MQTT-3-8.3-4]. Payload non normative example  HYPERLINK \l "_Figure_3.23_-" Figure 3.23 - Payload byte format non normative example shows the payload for the SUBSCRIBE Packet briefly described in  HYPERLINK \l "_Table_3.4_-" Table 3.5 - Payload non normative example. Table 3.5 - Payload non normative example Topic Namea/bRequested QoS0x01Topic Namec/dRequested QoS0x02Figure 3.23 - Payload byte format non normative example Description76543210Topic Filterbyte 1Length MSB (0)00000000byte 2Length LSB (3)00000011byte 3a (0x61)01100001byte 4/ (0x2F)00101111byte 5b (0x62)01100010Requested QoSbyte 6Requested QoS(1)00000001Topic Filterbyte 7Length MSB (0)00000000byte 8Length LSB (3)00000011byte 9c (0x63)01100011byte 10/ (0x2F)00101111byte 11d (0x64)01100100Requested QoSbyte 12Requested QoS(2)00000010 Response When the Server receives a SUBSCRIBE Packet from a Client, the Server MUST respond with a SUBACK Packet [MQTT-3.8.4-1]. The SUBACK Packet MUST have the same Packet Identifier as the SUBSCRIBE Packet that it is acknowledging [MQTT-3.8.4-2]. The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet. If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to an existing Subscriptions Topic Filter then it MUST completely replace that existing Subscription with a new Subscription. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its maximum QoS value could be different. Any existing retained messages matching the Topic Filter MUST be re-sent, but the flow of publications MUST NOT be interrupted [ HYPERLINK "https://tools.oasis-open.org/issues/browse/MQTT-3" \o "Keep alive interval grace period." MQTT-3.8.4-3]. Where the Topic Filter is not identical to any existing Subscriptions filter, a new Subscription is created and all matching retained messages are sent. If a Server receives a SUBSCRIBE packet that contains multiple Topic Filters it MUST handle that packet as if it had received a sequence of multiple SUBSCRIBE packets, except that it combines their responses into a single SUBACK response [MQTT-3.8.4-4]. The SUBACK Packet sent by the Server to the Client MUST contain a return code for each Topic Filter/QoS pair. This return code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed [ HYPERLINK "https://tools.oasis-open.org/issues/browse/MQTT-3" \o "Keep alive interval grace period." MQTT-3.8.4-5]. The Server might grant a lower maximum QoS than the subscriber requested. The QoS of Payload Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published message and the maximum QoS granted by the Server. The server is permitted to send duplicate copies of a message to a subscriber in the case where the original message was published with QoS 1 and the maximum QoS granted was QoS 0 [ HYPERLINK "https://tools.oasis-open.org/issues/browse/MQTT-3" \o "Keep alive interval grace period." MQTT-3.8.4-6]. Non normative examples If a subscribing Client has been granted maximum QoS 1 for a particular Topic Filter, then a QoS 0 Application Message matching the filter is delivered to the Client at QoS 0. This means that at most one copy of the message is received by the Client. On the other hand a QoS 2 Message published to the same topic is downgraded by the Server to QoS 1 for delivery to the Client, so that Client might receive duplicate copies of the Message. If the subscribing Client has been granted maximum QoS 0, then an Application Message originally published as QoS 2 might get lost on the hop to the Client, but the Server should never send a duplicate of that Message. A QoS 1 Message published to the same topic might either get lost or duplicated on its transmission to that Client. Non normative comment Subscribing to a Topic Filter at QoS 2 is equivalent to saying "I would like to receive Messages matching this filter at the QoS with which they were published". This means a publisher is responsible for determining the maximum QoS a Message can be delivered at, but a subscriber is able to require that the Server downgrades the QoS to one more suitable for its usage. SUBACK Subscribe acknowledgement A SUBACK Packet is sent by the Server to the Client to confirm receipt and processing of a SUBSCRIBE Packet. A SUBACK Packet contains a list of return codes, that specify the maximum QoS level that was granted in each Subscription that was requested by the SUBSCRIBE. Fixed header Figure 3.24 SUBACK Packet fixed header Bit76543210byte 1MQTT Control Packet type (9)Reserved10010000byte 2Remaining Length Remaining Length field This is the length of variable header (2 bytes) plus the length of the payload. Variable header The variable header contains the Packet Identifier from the SUBSCRIBE Packet that is being acknowledged.  HYPERLINK \l "_Figure_3.25_-" Figure 3.25 - variable header format below illustrates the format of the variable header. Figure 3.25 SUBACK Packet variable header Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSBPayload The payload contains a list of return codes. Each return code corresponds to a Topic Filter in the SUBSCRIBE Packet being acknowledged. The order of return codes in the SUBACK Packet MUST match the order of Topic Filters in the SUBSCRIBE Packet [MQTT-3.9.3-1].  HYPERLINK \l "_Figure_3.26_-" Figure 3.26 - Payload format below illustrates the Return Code field encoded in a byte in the Payload. Figure 3.26 SUBACK Packet payload format Bit76543210Return Codebyte 1X00000XX Allowed return codes: 0x00 - Success - Maximum QoS 0 0x01 - Success - Maximum QoS 1 0x02 - Success - Maximum QoS 2 0x80 - Failure SUBACK return codes other than 0x00, 0x01, 0x02 and 0x80 are reserved and MUST NOT be used[MQTT-3.9.3-2]. Payload non normative example  HYPERLINK \l "_Figure_3.27_-" Figure 3.27 - Payload byte format non normative example shows the payload for the SUBACK Packet briefly described in  HYPERLINK \l "_Table_3.5_-" Table 3.6 - Payload non normative example. Table 3.6 - Payload non normative example Success - Maximum QoS 00Success - Maximum QoS 2 2Failure128Figure 3.27 - Payload byte format non normative example Description76543210byte 1Success - Maximum QoS 000000000byte 2Success - Maximum QoS 200000010byte 3Failure10000000 UNSUBSCRIBE Unsubscribe from topics An UNSUBSCRIBE Packet is sent by the Client to the Server, to unsubscribe from topics. Fixed header Figure 3.28 UNSUBSCRIBE Packet Fixed header Bit76543210byte 1MQTT Control Packet type (10)Reserved10100010byte 2Remaining Length Bits 3,2,1 and 0 of the fixed header of the UNSUBSCRIBE Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection [MQTT-3.10.1-1]. Remaining Length field This is the length of variable header (2 bytes) plus the length of the payload. Variable header The variable header contains a Packet Identifier. Section  REF _Ref363041167 \r \h 2.3.1 provides more information about Packet Identifiers. Figure 3.29 UNSUBSCRIBE Packet variable header Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSB Payload The payload for the UNSUBSCRIBE Packet contains the list of Topic Filters that the Client wishes to unsubscribe from. The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 encoded strings as defined in Section  REF _Ref374438163 \r \h  \* MERGEFORMAT 1.5.3, packed contiguously [MQTT-3.10.3-1]. The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter. An UNSUBSCRIBE packet with no payload is a protocol violation [MQTT-3.10.3-2]. See section  REF _Ref381955543 \r \h 4.8 for information about handling errors. Payload non normative example  HYPERLINK \l "_Figure_3.30_-" Figure 3.30 - Payload byte format non normative example show the payload for the UNSUBSCRIBE Packet briefly described in  HYPERLINK \l "_Table3.6_-_Payload" Table3.7 - Payload non normative example. Table3.7 - Payload non normative example Topic Filtera/bTopic Filterc/dFigure 3.30 - Payload byte format non normative example Description76543210Topic Filterbyte 1Length MSB (0)00000000byte 2Length LSB (3)00000011byte 3a (0x61)01100001byte 4/ (0x2F)00101111byte 5b (0x62)01100010Topic Filterbyte 6Length MSB (0)00000000byte 7Length LSB (3)00000011byte 8c (0x63)01100011byte 9/ (0x2F)00101111byte 10d (0x64)01100100Response The Topic Filters (whether they contain wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription is deleted, otherwise no additional processing occurs [MQTT-3.10.4-1]. If a Server deletes a Subscription: It MUST stop adding any new messages for delivery to the Client [MQTT-3.10.4-2]. It MUST complete the delivery of any QoS 1 or QoS 2 messages which it has started to send to the Client [MQTT-3.10.4-3]. It MAY continue to deliver any existing messages buffered for delivery to the Client. The Server MUST respond to an UNSUBSUBCRIBE request by sending an UNSUBACK packet. The UNSUBACK Packet MUST have the same Packet Identifier as the UNSUBSCRIBE Packet [MQTT-3.10.4-4]. Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK [MQTT-3.10.4-5]. If a Server receives an UNSUBSCRIBE packet that contains multiple Topic Filters it MUST handle that packet as if it had received a sequence of multiple UNSUBSCRIBE packets, except that it sends just one UNSUBACK response [MQTT-3.10.4-6]. UNSUBACK Unsubscribe acknowledgement The UNSUBACK Packet is sent by the Server to the Client to confirm receipt of an UNSUBSCRIBE Packet. Fixed header Figure 3.31 UNSUBACK Packet fixed header Bit76543210byte 1MQTT Control Packet type (11)Reserved10110000byte 2Remaining Length (2)00000010Remaining Length field This is the length of the variable header. For the UNSUBACK Packet this has the value 2. Variable header The variable header contains the Packet Identifier of the UNSUBSCRIBE Packet that is being acknowledged. Figure 3.32 UNSUBACK Packet variable header Bit76543210byte 1Packet Identifier MSBbyte 2Packet Identifier LSB Payload The UNSUBACK Packet has no payload. PINGREQ PING request The PINGREQ Packet is sent from a Client to the Server. It can be used to: Indicate to the Server that the Client is alive in the absence of any other Control Packets being sent from the Client to the Server. Request that the Server responds to confirm that it is alive. Exercise the network to indicate that the Network Connection is active. This Packet is used in Keep Alive processing, see Section  REF _Ref363645900 \r \h 3.1.2.10 for more details. Fixed header Figure 3.33 PINGREQ Packet fixed header Bit76543210byte 1MQTT Control Packet type (12)Reserved11000000byte 2Remaining Length (0)00000000 Variable header The PINGREQ Packet has no variable header. Payload The PINGREQ Packet has no payload. Response The Server MUST send a PINGRESP Packet in response to a PINGREQ Packet [MQTT-3.12.4-1]. PINGRESP PING response A PINGRESP Packet is sent by the Server to the Client in response to a PINGREQ Packet. It indicates that the Server is alive. This Packet is used in Keep Alive processing, see Section  REF _Ref363645900 \r \h 3.1.2.10 for more details. Fixed header Figure 3.34 PINGRESP Packet fixed header Bit76543210byte 1MQTT Control Packet type (13)Reserved11010000byte 2Remaining Length (0)00000000 Variable header The PINGRESP Packet has no variable header. Payload The PINGRESP Packet has no payload. DISCONNECT Disconnect notification The DISCONNECT Packet is the final Control Packet sent from the Client to the Server. It indicates that the Client is disconnecting cleanly. Fixed header Figure 3.35 DISCONNECT Packet fixed header Bit76543210byte 1MQTT Control Packet type (14)Reserved11100000byte 2Remaining Length (0)00000000The Server MUST validate that reserved bits are set to zero and disconnect the Client if they are not zero [MQTT-3.14.1-1]. Variable header The DISCONNECT Packet has no variable header. Payload The DISCONNECT Packet has no payload. Response After sending a DISCONNECT Packet the Client: MUST close the Network Connection [MQTT-3.14.4-1]. MUST NOT send any more Control Packets on that Network Connection [MQTT-3.14.4-2]. On receipt of DISCONNECT the Server: MUST discard any Will Message associated with the current connection without publishing it, as described in Section  REF _Ref363648298 \r \h  \* MERGEFORMAT 3.1.2.5 [MQTT-3.14.4-3]. SHOULD close the Network Connection if the Client has not already done so. Operational behavior Storing state It is necessary for the Client and Server to store Session state in order to provide Quality of Service guarantees. The Client and Server MUST store Session state for the entire duration of the Session [MQTT-4.1.0-1]. A Session MUST last at least as long it has an active Network Connection [MQTT-4.1.0-2]. Retained messages do not form part of the Session state in the Server. The Server SHOULD retain such messages until deleted by a Client. Non normative comment The storage capabilities of Client and Server implementations will of course have limits in terms of capacity and may be subject to administrative policies such as the maximum time that Session state is stored between Network Connections. Stored Session state can be discarded as a result of an administrator action, including an automated response to defined conditions. This has the effect of terminating the Session. These actions might be prompted by resource constraints or for other operational reasons. It is prudent to evaluate the storage capabilities of the Client and Server to ensure that they are sufficient. Non normative comment It is possible that hardware or software failures may result in loss or corruption of Session state stored by the Client or Server. Non normative comment Normal operation of the Client of Server could mean that stored state is lost or corrupted because of administrator action,hardware failure or software failure. An administrator action could be an automated response to defined conditions. These actions might be prompted by resource constraints or for other operational reasons.For example the server might determine that based on external knowledge, a message or messages can no longer be delivered to any current or future client. Non normative comment An MQTT user should evaluate the storage capabilities of the MQTT Client and Server implementations to ensure that they are sufficient for their needs. Non normative example For example, a user wishing to gather electricity meter readings may decide that they need to use QoS 1 messages because they need to protect the readings against loss over the network, however they may have determined that the power supply is sufficiently reliable that the data in the Client and Server can be stored in volatile memory without too much risk of its loss. Conversely a parking meter payment application provider might decide that there are no circumstances where a payment message can be lost so they require that all data are force written to non-volatile memory before it is transmitted across the network. Network Connections The MQTT protocol requires an underlying transport that provides an ordered, lossless, stream of bytes from the Client to Server and Server to Client. Non normative comment The transport protocol used to carry MQTT 3.1 was TCP/IP as defined in [ HYPERLINK \l "RFC793" RFC793].TCP/IP can be used for MQTT 3.1.1.  REF RFC793 \h  \* MERGEFORMAT The following are also suitable: TLS HYPERLINK \l "RFC5246"[RFC5246] WebSocket HYPERLINK \l "RFC6455"[RFC6455] Non normative comment TCP ports 8883 and 1883 are registered with IANA for MQTT TLS and non TLS communication respectively. Connectionless network transports such as  HYPERLINK "http://en.wikipedia.org/wiki/User_Datagram_Protocol" \o "User Datagram Protocol" User Datagram Protocol(UDP) are not suitable on their own because they might lose or reorder data. Quality of Service levels and protocol flows MQTT delivers Application Messages according to the Quality of Service (QoS) levels defined here. The delivery protocol is symmetric, in the description below the Client and Server can each take the role of either Sender or Receiver. The delivery protocol is concerned solely with the delivery of an application message from a single Sender to a single Receiver. When the Server is delivering an Application Message to more than one Client, each Client is treated independently. The QoS level used to deliver an Application Message outbound to the Client could differ from that of the inbound Application Message. The non-normative flow diagrams in the following sections are intended to show possible implementation approaches. QoS 0: At most once delivery The message is delivered according to the capabilities of the underlying network. No response is sent by the receiver and no retry is performed by the sender. The message arrives at the receiver either once or not at all. In the QoS 0 delivery protocol, the Sender MUST send a PUBLISH packet with QoS=0, DUP=0 [MQTT-4.3.1-1]. In the QoS 0 delivery protocol, the Receiver Accepts ownership of the message when it receives the PUBLISH packet. Figure 4.1 QoS 0 protocol flow diagram, non normative example Sender ActionControl PacketReceiver ActionPUBLISH QoS 0, DUP=0 ---------->Deliver Application Message to appropriate onward recipient(s) QoS 1: At least once delivery This quality of service ensures that the message arrives at the receiver at least once. A QoS 1 PUBLISH Packet has a Packet Identifier in its variable header and is acknowledged by a PUBACK Packet. Section  REF _Ref363041167 \r \h 2.3.1 provides more information about Packet Identifiers. In the QoS 1 delivery protocol, the Sender MUST assign an unused Packet Identifier each time it has a new Application Message to publish. MUST send a PUBLISH Packet containing this Packet Identifier with QoS=1, DUP=0. MUST treat the PUBLISH Packet as unacknowledged until it has received the corresponding PUBACK packet from the receiver. See Section  REF _Ref383618483 \r \h 4.4 for a discussion of unacknowledged messages. [MQTT-4.3.2-1]. The Packet Identifier becomes available for reuse once the Sender has received the PUBACK Packet. Note that a Sender is permitted to send further PUBLISH Packets with different Packet Identifiers while it is waiting to receive acknowledgements. In the QoS 1 delivery protocol, the Receiver MUST respond with a PUBACK Packet containing the Packet Identifier from the incoming PUBLISH Packet, having accepted ownership of the Application Message After it has sent a PUBACK Packet the Receiver MUST treat any incoming PUBLISH packet that contains the same Packet Identifier as being a new publication, irrespective of the setting of its DUP flag. [MQTT-4.3.2-2]. Figure 4.2 QoS 1 protocol flow diagram, non normative example Sender ActionControl PacketReceiver actionStore messageSend PUBLISH QoS 1, DUP 0, ---------->Initiate onward delivery of the Application Message1<----------Send PUBACK Discard message 1 The receiver is not required to complete delivery of the Application Message before sending the PUBACK. When its original sender receives the PUBACK packet, ownership of the Application Message is transferred to the receiver. QoS 2: Exactly once delivery This is the highest quality of service, for use when neither loss nor duplication of messages are acceptable. There is an increased overhead associated with this quality of service. A QoS 2 message has a Packet Identifier in its variable header. Section  REF _Ref363041167 \r \h 2.3.1 provides more information about Packet Identifiers. The receiver of a QoS 2 PUBLISH Packet acknowledges receipt with a two-step acknowledgement process. In the QoS 2 delivery protocol, the Sender MUST assign an unused Packet Identifier when it has a new Application Message to publish. MUST send a PUBLISH packet containing this Packet Identifier with QoS=2, DUP=0. MUST treat the PUBLISH packet as unacknowledged until it has received the corresponding PUBREC packet from the receiver. See Section  REF _Ref383618483 \r \h 4.4 for a discussion of unacknowledged messages. MUST send a PUBREL packet when it receives a PUBREC packet from the receiver. This PUBREL packet MUST contain the same Packet Identifier as the original PUBLISH packet. MUST treat the PUBREL packet as unacknowledged until it has received the corresponding PUBCOMP packet from the receiver. MUST NOT re-send the PUBLISH once it has sent the corresponding PUBREL packet. [MQTT-4.3.3-1]. The Packet Identifier becomes available for reuse once the Sender has received the PUBCOMP Packet. Note that a Sender is permitted to send further PUBLISH Packets with different Packet Identifiers while it is waiting to receive acknowledgements. In the QoS 2 delivery protocol, the Receiver MUST respond with a PUBREC containing the Packet Identifier from the incoming PUBLISH Packet, having accepted ownership of the Application Message. Until it has received the corresponding PUBREL packet, the Receiver MUST acknowledge any subsequent PUBLISH packet with the same Packet Identifier by sending a PUBREC. It MUST NOT cause duplicate messages to be delivered to any onward recipients in this case. MUST respond to a PUBREL packet by sending a PUBCOMP packet containing the same Packet Identifier as the PUBREL. After it has sent a PUBCOMP, the receiver MUST treat any subsequent PUBLISH packet that contains that Packet Identifier as being a new publication. [MQTT-4.3.3-2]. Figure 4.3 QoS 2 protocol flow diagram, non normative example Sender ActionControl PacketReceiver ActionStore messagePUBLISH QoS 2, DUP 0 ---------->Method A, Store message or Method B, Store then Initiate onward delivery of the Application Message1PUBREC <----------Discard message, Store PUBREC received PUBREL ---------->Method A, Initiate onward delivery of the Application Message1 then discard message or Method B, Discard Send PUBCOMP <----------Discard stored state 1 The receiver is not required to complete delivery of the Application Message before sending the PUBREC or PUBCOMP. When its original sender receives the PUBREC packet, ownership of the Application Message is transferred to the receiver. HYPERLINK \l "_Figure_4.3_"Figure 4.3 shows that there are two methods by which QoS 2 can be handled by the receiver. They differ in the point within the flow at which the message is made available for onward delivery. The choice of Method A or Method B is implementation specific. As long as an implementation chooses exactly one of these approaches, this does not affect the guarantees of a QoS 2 flow. Message delivery retry When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers[MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages. Non normative comment Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks.This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments. Message receipt When a Server takes ownership of an incoming Application Message it MUST add it to the Session state of those clients that have matching Subscriptions. Matching rules are defined in Section  REF _Ref374621403 \r \h  \* MERGEFORMAT 4.7 [MQTT-4.5.0-1]. Under normal circumstances Clients receive messages in response to Subscriptions they have created. A Client could also receive messages that do not match any of its explicit Subscriptions. This can happen if the Server automatically assigned a subscription to the Client. A Client could also receive messages while an UNSUBSCRIBE operation is in progress. The Client MUST acknowledge any Publish Packet it receives according to the applicable QoS rules regardless of whether it elects to process the Application Message that it contains [MQTT-4.5.0-2]. Message ordering A Client MUST follow these rules when implementing the protocol flows defined elsewhere in this chapter: When it re-sends any PUBLISH packets, it MUST re-send them in the order in which the original PUBLISH packets were sent (this applies to QoS 1 and QoS 2 messages) [MQTT-4.6.0-1] It MUST send PUBACK packets in the order in which the corresponding PUBLISH packets were received (QoS 1 messages) [MQTT-4.6.0-2] It MUST send PUBREC packets in the order in which the corresponding PUBLISH packets were received (QoS 2 messages) [MQTT-4.6.0-3] It MUST send PUBREL packets in the order in which the corresponding PUBREC packets were received (QoS 2 messages) [MQTT-4.6.0-4] A Server MUST by default treat each Topic as an "Ordered Topic". It MAY provide an administrative or other mechanism to allow one or more Topics to be treated as an "Unordered Topic" [MQTT-4.6.0-5]. When a Server processes a message that has been published to an Ordered Topic, it MUST follow the rules listed above when delivering messages to each of its subscribers. In addition it MUST send PUBLISH packets to consumers (for the same Topic and QoS) in the order that they were received from any given Client [MQTT-4.6.0-6]. Non normative comment The rules listed above ensure that when a stream of messages is published and subscribed to with QoS 1, the final copy of each message received by the subscribers will be in the order that they were originally published in, but the possibility of message duplication could result in a re-send of an earlier message being received after one of its successor messages. For example a publisher might send messages in the order 1,2,3,4 and the subscriber might receive them in the order 1,2,3,2,3,4. If both Client and Server make sure that no more than one message is in-flight at any one time (by not sending a message until its predecessor has been acknowledged), then no QoS 1 message will be received after any later one - for example a subscriber might receive them in the order 1,2,3,3,4 but not 1,2,3,2,3,4. Setting an in-flight window of 1 also means that order will be preserved even if the publisher sends a sequence of messages with different QoS levels on the same topic. Topic Names and Topic Filters Topic wildcards The topic level separator is used to introduce structure into the Topic Name. If present, it divides the Topic Name into multiple topic levels. A subscriptions Topic Filter can contain special wildcard characters, which allow you to subscribe to multiple topics at once. The wildcard characters can be used in Topic Filters, but MUST NOT be used within a Topic Name [MQTT-4.7.1-1]. Topic level separator The forward slash (/ U+002F) 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 is encountered in Topic Filters specified by subscribing Clients. Topic level separators can appear anywhere in a Topic Filter or Topic Name. Adjacent Topic level separators indicate a zero length topic level. Multi-level wildcard The number sign (# U+0023) is a wildcard character that matches any number of levels within a topic. The multi-level wildcard represents the parent and any number of child levels. The multi-level wildcard character MUST be specified either on its own or following a topic level separator. In either case it MUST be the last character specified in the Topic Filter [MQTT-4.7.1-2]. Non normative comment For example, if a Client subscribes to sport/tennis/player1/#, it would receive messages published using these topic names: sport/tennis/player1 sport/tennis/player1/ranking sport/tennis/player1/score/wimbledon Non normative comment sport/# also matches the singular sport, since # includes the parent level. # is valid and will receive every Application Message sport/tennis/# is valid sport/tennis# is not valid sport/tennis/#/ranking is not valid Single level wildcard The plus sign (+ U+002B) is a wildcard character that matches only one topic level. The single-level wildcard can be used at any level in the Topic Filter, including first and last levels. Where it is used it MUST occupy an entire level of the filter [MQTT-4.7.1-3]. It can be used at more than one level in the Topic Filter and can be used in conjunction with the multilevel wildcard. Non normative comment For example, sport/tennis/+ matches sport/tennis/player1 and sport/tennis/player2, but not sport/tennis/player1/ranking. Also, because the single-level wildcard matches only a single level, sport/+ does not match sport but it does match sport/. Non normative comment + is valid +/tennis/# is valid sport+ is not valid sport/+/player1 is valid /finance matches +/+ and /+, but not + Topics beginning with $ The Server MUST NOT match Topic Filters starting with a wildcard character (# or +) with Topic Names beginning with a $ character [MQTT-4.7.2-1]. The Server SHOULD prevent Clients from using such Topic Names to exchange messages with other Clients. Server implementations MAY use Topic Names that start with a leading $ character for other purposes. Non normative comment $SYS/ has been widely adopted as a prefix to topics that contain Server-specific information or control APIs Applications cannot use a topic with a leading $ character for their own purposes Non normative comment A subscription to # will not receive any messages published to a topic beginning with a $ A subscription to +/monitor/Clients will not receive any messages published to $SYS/monitor/Clients A subscription to $SYS/# will receive messages published to topics beginning with $SYS/ A subscription to $SYS/monitor/+ will receive messages published to $SYS/monitor/Clients For a Client to receive messages from topics that begin with $SYS/ and from topics that dont begin with a $, it has to subscribe to both # and $SYS/# Topic semantic and usage The following rules apply to Topic Names and Topic Filters: All Topic Names and Topic Filters MUST be at least one character long [MQTT-4.7.3-1] Topic Names and Topic Filters are case sensitive Topic Names and Topic Filters can include the space character A leadingor trailing / creates a distinct Topic Name or Topic Filter A Topic Name or Topic Filter consisting only of the / character is valid Topic Names and Topic Filters MUST NOT include the null character (Unicode U+0000) [ HYPERLINK \l "Unicode" Unicode] [MQTT-4.7.3-2] Topic Names and Topic Filters are UTF-8 encoded strings, they MUST NOT encode to more than 65535 bytes [MQTT-4.7.3-3]. See Section  REF _Ref374438163 \r \h 1.5.3 There is no limit to the number of levels in a Topic Name or Topic Filter, other than that imposed by the overall length of a UTF-8 encoded string. When it performs subscription matching the Server MUST NOT perform any normalization of Topic Names or Topic Filters, or any modification or substitution of unrecognized characters [MQTT-4.7.3-4]. Each non-wildcarded level in the Topic Filter has to match the corresponding level in the Topic Name character for character for the match to succeed. Non normative comment The UTF-8 encoding rules mean that the comparison of Topic Filter and Topic Name could be performed either by comparing the encoded UTF-8 bytes, or by comparing decoded Unicode characters Non normative comment ACCOUNTS and Accounts are two different topic names Accounts payable is a valid topic name /finance is different from finance An Application Message is sent to each Client Subscription whose Topic Filter matches the Topic Name attached to an Application Message. The topic resource MAY be either predefined in the Server by an administrator or it MAY be dynamically created by the Server when it receives the first subscription or an Application Message with that Topic Name. The Server MAY also use a security component to selectively authorize actions on the topic resource for a given Client. Handling errors Unless stated otherwise, if either the Server or Client encounters a protocol violation, it MUST close the Network Connection on which it received that Control Packet which caused the protocol violation [MQTT-4.8.0-1]. A Client or Server implementation might encounter a Transient Error (for example an internal buffer full condition) that prevents successful processing of an MQTT packet. If the Client or Server encounters a Transient Error while processing an inbound Control Packet it MUST close the Network Connection on which it received that Control Packet [MQTT-4.8.0-2]. If a Server detects a Transient Error it SHOULD NOT disconnect or have any other effect on its interactions with any other Client. Security Introduction This Chapter is provided for guidance only and is Non Normative. However, it is strongly recommended that Server implementations that offer TLS  HYPERLINK \l "RFC5246" [RFC5246] SHOULD use TCP port 8883 (IANA service name: secure-mqtt). There are a number of threats that solution providers should consider. For example: Devices could be compromised Data at rest in Clients and Servers might be accessible Protocol behaviors could have side effects (e.g. timing attacks) Denial of Service (DoS) attacks Communications could be intercepted, altered, re-routed or disclosed Injection of spoofed Control Packets MQTT solutions are often deployed in hostile communication environments. In such cases, implementations will often need to provide mechanisms for: Authentication of users and devices Authorization of access to Server resources Integrity of MQTT Control Packets and application data contained therein Privacy of MQTT Control Packets and application data contained therein As a transport protocol, MQTT is concerned only with message transmission and it is the implementers responsibility to provide appropriate security features. This is commonly achieved by using TLS  HYPERLINK \l "RFC5246" [RFC5246]. In addition to technical security issues there could also be geographic (e.g. U.S.-EU SafeHarbor  HYPERLINK \l "USEUSAFEHARB" [USEUSAFEHARB]), industry specific (e.g. PCI DSS  HYPERLINK \l "PCIDSS" [PCIDSS]) and regulatory considerations (e.g. Sarbanes-Oxley  HYPERLINK \l "SARBANES" [SARBANES]). MQTT solutions: security and certification An implementation might want to provide conformance with specific industry security standards such as NIST Cyber Security Framework [ HYPERLINK \l "NISTCSF" NISTCSF], PCI-DSS  HYPERLINK \l "PCIDSS" [PCIDSS]), FIPS-140-2  HYPERLINK \l "FIPS1402" [FIPS1402] and NSA Suite B [ HYPERLINK \l "NSAB" NSAB]. Guidance on using MQTT within the NIST Cyber Security Framework [ HYPERLINK \l "NISTCSF" NISTCSF] can be found in the MQTT supplemental publication, MQTT and the NIST Framework for Improving Critical Infrastructure Cybersecurity  HYPERLINK \l "MQTTSupplementalPublication" [MQTT NIST]. The use of industry proven, independently verified and certified technologies will help meet compliance requirements. Lightweight cryptography and constrained devices Advanced Encryption Standard  HYPERLINK \l "AES" [AES] and Data Encryption Standard  HYPERLINK \l "DES" [DES] are widely adopted. ISO 29192  HYPERLINK \l "ISO29192" [ISO29192] makes recommendations for cryptographic primitives specifically tuned to perform on constrained low end devices. Implementation notes There are many security concerns to consider when implementing or using MQTT. The following section should not be considered a check list. An implementation might want to achieve some, or all, of the following: Authentication of Clients by the Server The CONNECT Packet contains Username and Password fields. Implementations can choose how to make use of the content of these fields. They may provide their own authentication mechanism, use an external authentication system such as LDAP  HYPERLINK \l "RFC4511" [RFC4511] or OAuth  HYPERLINK \l "RFC6749" [RFC6749] tokens, or leverage operating system authentication mechanisms. Implementations passing authentication data in clear text, obfuscating such data elements or requiring no authentication data should be aware this can give rise to Man-in-the-Middle and replay attacks. Section  REF _Ref374028308 \r \h 5.4.5 introduces approaches to ensure data privacy. A Virtual Private Network (VPN) between the Clients and Servers can provide confidence that data is only being received from authorized Clients. Where TLS  HYPERLINK \l "RFC5246" [RFC5246] is used, SSL Certificates sent from the Client can be used by the Server to authenticate the Client. An implementation might allow for authentication where the credentials are sent in an Application Message from the Client to the Server. Authorization of Clients by the Server An implementation may restrict access to Server resources based on information provided by the Client such as User Name, Client Identifier, the hostname/IP address of the Client, or the outcome of authentication mechanisms. Authentication of the Server by the Client The MQTT protocol is not trust symmetrical: it provides no mechanism for the Client to authenticate the Server. Where TLS  HYPERLINK \l "RFC5246" [RFC5246] is used, SSL Certificates sent from the Server can be used by the Client to authenticate the Server. Implementations providing MQTT service for multiple hostnames from a single IP address should be aware of the Server Name Indication extension to TLS defined in section 3 of RFC 6066  HYPERLINK \l "RFC6066" [RFC6066].This allows a Client to tell the Server the hostname of the Server it is trying to connect to. An implementation might allow for authentication where the credentials are sent in an Application Message from the Server to the Client. A VPN between Clients and Servers can provide confidence that Clients are connecting to the intended Server. Integrity of Application Messages and Control Packets Applications can independently include hash values in their Application Messages. This can provide integrity of the contents of Publish Control Packets across the network and at rest. TLS  HYPERLINK \l "RFC5246" [RFC5246] provides hash algorithms to verify the integrity of data sent over the network. The use of VPNs to connect Clients and Servers can provide integrity of data across the section of the network covered by a VPN. Privacy of Application Messages and Control Packets TLS  HYPERLINK \l "RFC5246" [RFC5246] can provide encryption of data sent over the network. There are valid TLS cipher suites that include a NULL encryption algorithm that does not encrypt data. To ensure privacy Clients and Servers should avoid these cipher suites. An application might independently encrypt the contents of its Application Messages. This could provide privacy of the Application Message both over the network and at rest. This would not provide privacy for other properties of the Application Message such as Topic Name. Client and Server implementations can provide encrypted storage for data at rest such as Application Messages stored as part of a Session. The use of VPNs to connect Clients and Servers can provide privacy of data across the section of the network covered by a VPN. Non-repudiation of message transmission Application designers might need to consider appropriate strategies to achieve end to end non-repudiation. Detecting compromise of Clients and Servers Client and Server implementations using TLS  HYPERLINK \l "RFC5246" [RFC5246] should provide capabilities to ensure that any SSL certificates provided when initiating a TLS  HYPERLINK \l "RFC5246" [RFC5246] connection are associated with the hostname of the Client connecting or Server being connected to. Client and Server implementations using TLS  HYPERLINK \l "RFC5246" [RFC5246] can choose to provide capabilities to check Certificate Revocation Lists (CRLs  HYPERLINK \l "RFC5280" [RFC5280]) and Online Certificate Status Protocol (OSCP)  HYPERLINK \l "RFC6960" [RFC6960] to prevent revoked certificates from being used. Physical deployments might combine tamper-proof hardware with the transmission of specific data in Application Messages. For example a meter might have an embedded GPS to ensure it is not used in an unauthorized location.  HYPERLINK \l "IEEE8021AR" [IEEE 802.1AR] is a standard for implementing mechanisms to authenticate a devices identity using a cryptographically bound identifier. Detecting abnormal behaviors Server implementations might monitor Client behavior to detect potential security incidents. For example: Repeated connection attempts Repeated authentication attempts Abnormal termination of connections Topic scanning (attempts to send or subscribe to many topics) Sending undeliverable messages (no subscribers to the topics) Clients that connect but do not send data Server implementations might disconnect Clients that breach its security rules. Server implementations detecting unwelcome behavior might implement a dynamic block list based on identifiers such as IP address or Client Identifier. Deployments might use network level controls (where available) to implement rate limiting or blocking based on IP address or other information. Other security considerations If Client or Server SSL certificates are lost or it is considered that they might be compromised they should be revoked (utilizing CRLs  HYPERLINK \l "RFC5280" [RFC5280] and/or OSCP  HYPERLINK \l "RFC6960" [RFC6960]). Client or Server authentication credentials, such as User Name and Password, that are lost or considered compromised should be revoked and/or reissued. In the case of long lasting connections: Client and Server implementations using TLS  HYPERLINK \l "RFC5246" [RFC5246] should allow for session renegotiation to establish new cryptographic parameters (replace session keys, change cipher suites, change authentication credentials). Servers may disconnect Clients and require them to re-authenticate with new credentials. Constrained devices and Clients on constrained networks can make use of TLS session resumption  HYPERLINK \l "RFC5077" [RFC5077], in order to reduce the costs of reconnecting TLS  HYPERLINK \l "RFC5246" [RFC5246] sessions. Clients connected to a Server have a transitive trust relationship with other Clients connected to the same Server and who have authority to publish data on the same topics. Use of SOCKS Implementations of Clients should be aware that some environments will require the use of SOCKSv5  HYPERLINK \l "RFC1928" [RFC1928] proxies to make outbound Network Connections. Some MQTT implementations could make use of alternative secured tunnels (e.g. SSH) through the use of SOCKS. Where implementations choose to use SOCKS, they should support both anonymous and user-name password authenticating SOCKS proxies. In the latter case, implementations should be aware that SOCKS authentication might occur in plain-text and so should avoid using the same credentials for connection to a MQTT Server. Security profiles Implementers and solution designers might wish to consider security as a set of profiles which can be applied to the MQTT protocol. An example of a layered security hierarchy is presented below. Clear communication profile When using the clear communication profile, the MQTT protocol runs over an open network with no additional secure communication mechanisms in place. Secured network communication profile When using the secured network communication profile, the MQTT protocol runs over a physical or virtual network which has security controls e.g., VPNs or physically secure network. Secured transport profile When using the secured transport profile, the MQTT protocol runs over a physical or virtual network and using TLS  HYPERLINK \l "RFC5246" [RFC5246] which provides authentication, integrity and privacy. TLS  HYPERLINK \l "RFC5246" [RFC5246] Client authentication can be used in addition to or in place of MQTT Client authentication as provided by the Username and Password fields. Industry specific security profiles It is anticipated that the MQTT protocol will be designed into industry specific application profiles, each defining a threat model and the specific security mechanisms to be used to address these threats. Recommendations for specific security mechanisms will often be taken from existing works including:  HYPERLINK \l "NISTCSF" [NISTCSF] NIST Cyber Security Framework  HYPERLINK \l "NIST7628" [NIST7628] NISTIR 7628 Guidelines for Smart Grid Cyber Security  HYPERLINK \l "FIPS1402" [FIPS1402] Security Requirements for Cryptographic Modules (FIPS PUB 140-2)  HYPERLINK \l "PCIDSS" [PCIDSS] PCI-DSS Payment Card Industry Data Security Standard  HYPERLINK \l "NSAB" [NSAB] NSA Suite B Cryptography Using WebSocket as a network transport If MQTT is transported over a WebSocket  HYPERLINK \l "RFC6455" [RFC6455] connection, the following conditions apply: MQTT Control Packets MUST be sent in WebSocket binary data frames. If any other type of data frame is received the recipient MUST close the Network Connection [MQTT-6.0.0-1]. A single WebSocket data frame can contain multiple or partial MQTT Control Packets. The receiver MUST NOT assume that MQTT Control Packets are aligned on WebSocket frame boundaries [MQTT-6.0.0-2]. The client MUST include mqtt in the list of WebSocket Sub Protocols it offers [MQTT-6.0.0-3]. The WebSocket Sub Protocol name selected and returned by the server MUST be mqtt [MQTT-6.0.0-4]. The WebSocket URI used to connect the client and server has no impact on the MQTT protocol. IANA Considerations This specification requests IANA to register the WebSocket MQTT sub-protocol under the WebSocket Subprotocol Name registry with the following data: Figure 6. SEQ Figure \* ARABIC \s 5 1 - IANA WebSocket Identifier Subprotocol IdentifiermqttSubprotocol Common NamemqttSubprotocol Definitionhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html Conformance The MQTT specification defines conformance for MQTT Client implementations and MQTT Server implementations. An MQTT implementation MAY conform as both an MQTT Client and MQTT Server implementation. A Server that both accepts inbound connections and establishes outbound connections to other Servers MUST conform as both an MQTT Client and MQTT Server [MQTT-7.0.0-1]. Conformant implementations MUST NOT require the use of any extensions defined outside of this specification in order to interoperate with any other conformant implementation [MQTT-7.0.0-2]. Conformance Targets MQTT Server An MQTT Server conforms to this specification only if it satisfies all the statements below: 1. The format of all Control Packets that the Server sends matches the format described in Chapter 2 and Chapter 3. 2. It follows the Topic matching rules described in Section  REF _Ref374621403 \r \h 4.7. 3. It satisfies all of the MUST level requirements in the following chapters that are identified except for those that only apply to the Client: - Chapter 1 - Introduction - Chapter 2 - MQTT Control Packet format - Chapter 3 - MQTT Control Packets - Chapter 4 - Operational behavior - Chapter 6 - (if MQTT is transported over a WebSocket connection) - Chapter 7 - Conformance Targets A conformant Server MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client [MQTT-7.1.1-1]. However conformance does not depend on it supporting any specific transport protocols. A Server MAY support any of the transport protocols listed in Section  REF _Ref368642907 \r \h 4.2, or any other transport protocol that meets the requirements of [MQTT-7.1.1-1]. MQTT Client An MQTT Client conforms to this specification only if it satisfies all the statements below: 1. The format of all Control Packets that the Client sends matches the format described in Chapter 2 and Chapter 3. 2. It satisfies all of the MUST level requirements in the following chapters that are identified except for those that only apply to the Server: - Chapter 1 - Introduction - Chapter 2 - MQTT Control Packet format - Chapter 3 - MQTT Control Packets - Chapter 4 - Operational behavior - Chapter 6 - (if MQTT is transported over a WebSocket connection) - Chapter 7 - Conformance Targets A conformant Client MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client [MQTT-7.1.2-1]. However conformance does not depend on it supporting any specific transport protocols. A Client MAY support any of the transport protocols listed in Section  REF _Ref368642907 \r \h 4.2, or any other transport protocol that meets the requirements of [MQTT-7.1.2-1]. Acknowledgements (non normative) The TC owes special thanks to Dr Andy Stanford-Clark and Arlen Nipper as the original inventors of the MQTT protocol and for their continued support with the standardization process. The following individuals were members of the OASIS Technical Committee during the creation of this specification and their contributions are gratefully acknowledged: Sanjay Aiyagari (VMware, Inc.) Ben Bakowski (IBM) Andrew Banks (IBM) Arthur Barr (IBM) William Bathurst (Machine-to-Machine Intelligence (M2MI) Corporation) Ken Borgendale (IBM) Geoff Brown (Machine-to-Machine Intelligence (M2MI) Corporation) James Butler (Cimetrics Inc.) Marco Carrer (Eurotech S.p.A.) Raphael Cohn (Individual) Sarah Cooper (Machine-to-Machine Intelligence (M2MI) Corporation) Richard Coppen (IBM) AJ Dalola (Telit Communications S.p.A.) Mark Darbyshire (TIBCO Software Inc.) Scott deDeugd (IBM) Paul Duffy (Cisco Systems) Phili DesAutels (LogMeIn Inc.) John Fallows (Kaazing) Pradeep Fernando (WSO2) Paul Fremantle (WSO2) Thomas Glover (Cognizant Technology Solutions) Rahul Gupta (IBM) Steve Huston (Individual) Wes Johnson (Eurotech S.p.A.) Christopher Kelley (Cisco Systems) David Kemper (TIBCO Software Inc.) James Kirkland (Red Hat) Alex Kritikos (Software AG, Inc.) Louis-P. Lamoureux (Machine-to-Machine Intelligence (M2MI) Corporation) David Locke (IBM) Shawn McAllister (Solace Systems) Dale Moberg (Axway Software) Manu Namboodiri (Machine-to-Machine Intelligence (M2MI) Corporation) Peter Niblett (IBM) Arlen Nipper (Individual) Julien Niset (Machine-to-Machine Intelligence (M2MI) Corporation) Mark Nixon (Emerson Process Management) Nicholas O'Leary (IBM) Sandor Palfy (LogMeIn Inc.) Dominik Obermaier (dc-square GmbH) Pavan Reddy (Cisco Systems) Andrew Schofield (IBM) Wadih Shaib (BlackBerry) Ian Skerrett (Eclipse Foundation) Joe Speed (IBM) Allan Stockdill-Mander (IBM) Gary Stuebing (Cisco Systems) Steve Upton (IBM) James Wert jr. (Telit Communications S.p.A.) T. Wyatt (Individual) SHAWN XIE (Machine-to-Machine Intelligence (M2MI) Corporation) Dominik Zajac (dc-square GmbH) Ed Briggs (Microsoft) Secretary: Geoff Brown ( HYPERLINK "mailto:geoff.brown@m2mi.com" geoff.brown@m2mi.com),  HYPERLINK "http://www.m2mi.com/" M2MI Mandatory normative statements (non normative) This Appendix is non-normative and is provided as a convenient summary of the numbered conformance statements found in the main body of this document. See Chapter 7 for a definitive list of conformance requirements. Normative Statement NumberNormative Statement[MQTT-1.5.3-1]The character data in a UTF-8 encoded string MUST be well-formed UTF-8 as defined by the Unicode specification [Unicode] and restated in RFC 3629 [RFC3629]. In particular this data MUST NOT include encodings of code points between U+D800 and U+DFFF. If a Server or Client receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection.[MQTT-1.5.3-2]A UTF-8 encoded string MUST NOT include an encoding of the null character U+0000. If a receiver (Server or Client) receives a Control Packet containing U+0000 it MUST close the Network Connection.[MQTT-1.5.3-3]A UTF-8 encoded sequence 0xEF 0xBB 0xBF is always to be interpreted to mean U+FEFF ("ZERO WIDTH NO-BREAK SPACE") wherever it appears in a string and MUST NOT be skipped over or stripped off by a packet receiver.[MQTT-2.2.2-1]Where a flag bit is marked as Reserved in Table 2.2 - Flag Bits, it is reserved for future use and MUST be set to the value listed in that table.[MQTT-2.2.2-2]If invalid flags are received, the receiver MUST close the Network Connection.[MQTT-2.3.1-1]SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) Control Packets MUST contain a non-zero 16-bit Packet Identifier.[MQTT-2.3.1-2]Each time a Client sends a new packet of one of these types it MUST assign it a currently unused Packet Identifier.[MQTT-2.3.1-3]If a Client re-sends a particular Control Packet, then it MUST use the same Packet Identifier in subsequent re-sends of that packet. The Packet Identifier becomes available for reuse after the Client has processed the corresponding acknowledgement packet. In the case of a QoS 1 PUBLISH this is the corresponding PUBACK; in the case of QO2 it is PUBCOMP. For SUBSCRIBE or UNSUBSCRIBE it is the corresponding SUBACK or UNSUBACK.[MQTT-2.3.1-4]The same conditions [MQTT-2.3.1-3] apply to a Server when it sends a PUBLISH with QoS >0. [MQTT-2.3.1-5]A PUBLISH Packet MUST NOT contain a Packet Identifier if its QoS value is set to 0.[MQTT-2.3.1-6]A PUBACK, PUBREC or PUBREL Packet MUST contain the same Packet Identifier as the PUBLISH Packet that was originally sent.[MQTT-2.3.1-7] Similarly to [MQTT-2.3.1-6], SUBACK and UNSUBACK MUST contain the Packet Identifier that was used in the corresponding SUBSCRIBE and UNSUBSCRIBE Packet respectively.[MQTT-3.1.0-1]After a Network Connection is established by a Client to a Server, the first Packet sent from the Client to the Server MUST be a CONNECT Packet.[MQTT-3.1.0-2]The Server MUST process a second CONNECT Packet sent from a Client as a protocol violation and disconnect the Client.[MQTT-3.1.2-1]If the protocol name is incorrect the Server MAY disconnect the Client, or it MAY continue processing the CONNECT packet in accordance with some other specification. In the latter case, the Server MUST NOT continue to process the CONNECT packet in line with this specification.[MQTT-3.1.2-2]The Server MUST respond to the CONNECT Packet with a CONNACK return code 0x01 (unacceptable protocol level) and then disconnect the Client if the Protocol Level is not supported by the Server.[MQTT-3.1.2-3]The Server MUST validate that the reserved flag in the CONNECT Control Packet is set to zero and disconnect the Client if it is not zero. [MQTT-3.1.2-4]If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected.[MQTT-3.1.2-5]After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state.[MQTT-3.1.2-6]If CleanSession is set to 1, the Client and Server MUST discard any previous Session and start a new one. This Session lasts as long as the Network Connection. State data associated with this Session MUST NOT be reused in any subsequent Session.[MQTT-3.1.2.7]Retained messages do not form part of the Session state in the Server, they MUST NOT be deleted when the Session ends.[MQTT-3.1.2-8]If the Will Flag is set to 1 this indicates that, if the Connect request is accepted, a Will Message MUST be stored on the Server and associated with the Network Connection. The Will Message MUST be published when the Network Connection is subsequently closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet.[MQTT-3.1.2-9]If the Will Flag is set to 1, the Will QoS and Will Retain fields in the Connect Flags will be used by the Server, and the Will Topic and Will Message fields MUST be present in the payload.[MQTT-3.1.2-10]The Will Message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client.[MQTT-3.1.2-11]If the Will Flag is set to 0 the Will QoS and Will Retain fields in the Connect Flags MUST be set to zero and the Will Topic and Will Message fields MUST NOT be present in the payload. [MQTT-3.1.2-12]If the Will Flag is set to 0, a Will Message MUST NOT be published when this Network Connection ends.[MQTT-3.1.2-13]If the Will Flag is set to 0, then the Will QoS MUST be set to 0 (0x00).[MQTT-3.1.2-14]If the Will Flag is set to 1, the value of Will QoS can be 0 (0x00), 1 (0x01), or 2 (0x02). It MUST NOT be 3 (0x03). [MQTT-3.1.2-15]If the Will Flag is set to 0, then the Will Retain Flag MUST be set to 0.[MQTT-3.1.2-16]If the Will Flag is set to 1 and If Will Retain is set to 0, the Server MUST publish the Will Message as a non-retained message.[MQTT-3.1.2-17]If the Will Flag is set to 1 and If Will Retain is set to 1, the Server MUST publish the Will Message as a retained message.[MQTT-3.1.2-18]If the User Name Flag is set to 0, a user name MUST NOT be present in the payload.[MQTT-3.1.2-19]If the User Name Flag is set to 1, a user name MUST be present in the payload.[MQTT-3.1.2-20]If the Password Flag is set to 0, a password MUST NOT be present in the payload.[MQTT-3.1.2-21]If the Password Flag is set to 1, a password MUST be present in the payload.[MQTT-3.1.2-22]If the User Name Flag is set to 0, the Password Flag MUST be set to 0.[MQTT-3.1.2-23]It is the responsibility of the Client to ensure that the interval between Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other Control Packets, the Client MUST send a PINGREQ Packet.[MQTT-3.1.2-24]If the Keep Alive value is non-zero and the Server does not receive a Control Packet from the Client within one and a half times the Keep Alive time period, it MUST disconnect the Network Connection to the Client as if the network had failed.[MQTT-3.1.3-1]These fields, if present, MUST appear in the order Client Identifier, Will Topic, Will Message, User Name, Password.[MQTT-3.1.3-2]Each Client connecting to the Server has a unique ClientId. The ClientId MUST be used by Clients and by Servers to identify state that they hold relating to this MQTT Session between the Client and the Server.[MQTT-3.1.3-3]The Client Identifier (ClientId) MUST be present and MUST be the first field in the CONNECT packet payload.[MQTT-3.1.3-4]The ClientId MUST be a UTF-8 encoded string as defined in Section  REF _Ref374438163 \r \h  \* MERGEFORMAT 1.5.3.[MQTT-3.1.3-5]The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".[MQTT-3.1.3-6]A Server MAY allow a Client to supply a ClientId that has a length of zero bytes. However if it does so the Server MUST treat this as a special case and assign a unique ClientId to that Client. It MUST then process the CONNECT packet as if the Client had provided that unique ClientId.[MQTT-3.1.3-7]If the Client supplies a zero-byte ClientId, the Client MUST also set CleanSession to 1.[MQTT-3.1.3-8]If the Client supplies a zero-byte ClientId with CleanSession set to 0, the Server MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection.[MQTT-3.1.3-9]If the Server rejects the ClientId it MUST respond to the CONNECT Packet with a CONNACK return code 0x02 (Identifier rejected) and then close the Network Connection.[MQTT-3.1.3-10]The Will Topic MUST be a UTF-8 encoded string as defined in Section  1.5.3. [MQTT-3.1.3-11]The User Name MUST be a UTF-8 encoded string as defined in Section 1.5.3.[MQTT-3.1.4-1]The Server MUST validate that the CONNECT Packet conforms to section  REF _Ref363033523 \r \h  \* MERGEFORMAT 3.1 and close the Network Connection without sending a CONNACK if it does not conform.[MQTT-3.1.4-2]If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client.[MQTT-3.1.4-3]If CONNECT validation is successful the Server MUST perform the processing of CleanSession that is described in section 3.1.2.4.[MQTT-3.1.4-4] If CONNECT validation is successful the Server MUST acknowledge the CONNECT Packet with a CONNACK Packet containing a zero return code.[MQTT-3.1.4-5]If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT Packet.[MQTT-3.2.0-1]The first packet sent from the Server to the Client MUST be a CONNACK Packet.[MQTT-3.2.2-1]If the Server accepts a connection with CleanSession set to 1, the Server MUST set Session Present to 0 in the CONNACK packet in addition to setting a zero return code in the CONNACK packet.[MQTT-3.2.2-2] If the Server accepts a connection with CleanSession set to 0, the value set in Session Present depends on whether the Server already has stored Session state for the supplied client ID. If the Server has stored Session state, it MUST set SessionPresent to 1 in the CONNACK packet. [MQTT-3.2.2-3]If the Server does not have stored Session state, it MUST set Session Present to 0 in the CONNACK packet. This is in addition to setting a zero return code in the CONNACK packet. [MQTT-3.2.2-4]If a server sends a CONNACK packet containing a non-zero return code it MUST set Session Present to 0.[MQTT-3.2.2-5]If a server sends a CONNACK packet containing a non-zero return code it MUST then close the Network Connection.[MQTT-3.2.2-6]If none of the return codes listed in  REF _Ref383985930 \h  \* MERGEFORMAT Table 3.1 Connect Return code values are deemed applicable, then the Server MUST close the Network Connection without sending a CONNACK.[MQTT-3.3.1-1]The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver a PUBLISH Packet.[MQTT-3.3.1-2]The DUP flag MUST be set to 0 for all QoS 0 messages. [MQTT-3.3.1-3]The value of the DUP flag from an incoming PUBLISH packet is not propagated when the PUBLISH Packet is sent to subscribers by the Server. The DUP flag in the outgoing PUBLISH packet is set independently to the incoming PUBLISH packet, its value MUST be determined solely by whether the outgoing PUBLISH packet is a retransmission.[MQTT-3.3.1-4]A PUBLISH Packet MUST NOT have both QoS bits set to 1. If a Server or Client receives a PUBLISH Packet which has both QoS bits set to 1 it MUST close the Network Connection.[MQTT-3.3.1-5]If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a Client to a Server, the Server MUST store the Application Message and its QoS, so that it can be delivered to future subscribers whose subscriptions match its topic name. [MQTT-3.3.1-6]When a new subscription is established, the last retained message, if any, on each matching topic name MUST be sent to the subscriber.[MQTT-3.3.1-7]If the Server receives a QoS 0 message with the RETAIN flag set to 1 it MUST discard any message previously retained for that topic. It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time - if this happens there will be no retained message for that topic.[MQTT-3.3.1-8]When sending a PUBLISH Packet to a Client the Server MUST set the RETAIN flag to 1 if a message is sent as a result of a new subscription being made by a Client.[MQTT-3.3.1-9]It MUST set the RETAIN flag to 0 when a PUBLISH Packet is sent to a Client because it matches an established subscription regardless of how the flag was set in the message it received. [MQTT-3.3.1-10]A PUBLISH Packet with a RETAIN flag set to 1 and a payload containing zero bytes will be processed as normal by the Server and sent to Clients with a subscription matching the topic name. Additionally any existing retained message with the same topic name MUST be removed and any future subscribers for the topic will not receive a retained message.[MQTT-3.3.1-11]A zero byte retained message MUST NOT be stored as a retained message on the Server.[MQTT-3.3.1-12]If the RETAIN flag is 0, in a PUBLISH Packet sent by a Client to a Server, the Server MUST NOT store the message and MUST NOT remove or replace any existing retained message.[MQTT-3.3.2-1]The Topic Name MUST be present as the first field in the PUBLISH Packet Variable header. It MUST be a UTF-8 encoded string.[MQTT-3.3.2-2]The Topic Name in the PUBLISH Packet MUST NOT contain wildcard characters.[MQTT-3.3.2-3]The Topic Name in a PUBLISH Packet sent by a Server to a subscribing Client MUST match the Subscriptions Topic Filter according to the matching process defined in Section 4.7.[MQTT-3.3.4-1]The receiver of a PUBLISH Packet MUST respond according to Table 3.4 - Expected Publish Packet response as determined by the QoS in the PUBLISH Packet.[MQTT-3.3.5-1]The Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions.[MQTT-3.3.5-2]If a Server implementation does not authorize a PUBLISH to be performed by a Client; it has no way of informing that Client. It MUST either make a positive acknowledgement, according to the normal QoS rules, or close the Network Connection.[MQTT-3.6.1-1]Bits 3,2,1 and 0 of the fixed header in the PUBREL Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection.[MQTT-3.8.1-1]Bits 3,2,1 and 0 of the fixed header of the SUBSCRIBE Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection.[MQTT-3.8.3-1]The Topic Filters in a SUBSCRIBE packet payload MUST be UTF-8 encoded strings as defined in Section 1.5.3.[MQTT-3.8.3-2]If the Server chooses not to support topic filters that contain wildcard characters it MUST reject any Subscription request whose filter contains them.[MQTT-3.8.3-3]The payload of a SUBSCRIBE packet MUST contain at least one Topic Filter / QoS pair. A SUBSCRIBE packet with no payload is a protocol violation.[MQTT-3-8.3-4]The Server MUST treat a SUBSCRIBE packet as malformed and close the Network Connection if any of Reserved bits in the payload are non-zero, or QoS is not 0,1 or 2.[MQTT-3.8.4-1]When the Server receives a SUBSCRIBE Packet from a Client, the Server MUST respond with a SUBACK Packet.[MQTT-3.8.4-2]The SUBACK Packet MUST have the same Packet Identifier as the SUBSCRIBE Packet that it is acknowledging.[MQTT-3.8.4-3]If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to an existing Subscriptions Topic Filter then it MUST completely replace that existing Subscription with a new Subscription. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its maximum QoS value could be different. Any existing retained messages matching the Topic Filter MUST be re-sent, but the flow of publications MUST NOT be interrupted.[MQTT-3.8.4-4]If a Server receives a SUBSCRIBE packet that contains multiple Topic Filters it MUST handle that packet as if it had received a sequence of multiple SUBSCRIBE packets, except that it combines their responses into a single SUBACK response.[MQTT-3.8.4-5]The SUBACK Packet sent by the Server to the Client MUST contain a return code for each Topic Filter/QoS pair. This return code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed.[MQTT-3.8.4-6]The Server might grant a lower maximum QoS than the subscriber requested. The QoS of Payload Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published message and the maximum QoS granted by the Server. The server is permitted to send duplicate copies of a message to a subscriber in the case where the original message was published with QoS 1 and the maximum QoS granted was QoS 0.[MQTT-3.9.3-1] The order of return codes in the SUBACK Packet MUST match the order of Topic Filters in the SUBSCRIBE Packet.[MQTT-3.9.3-2]SUBACK return codes other than 0x00, 0x01, 0x02 and 0x80 are reserved and MUST NOT be used. [MQTT-3.10.1-1]Bits 3,2,1 and 0 of the fixed header of the UNSUBSCRIBE Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection.[MQTT-3.10.3-1]The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 encoded strings as defined in Section  REF _Ref374438163 \r \h 1.5.3, packed contiguously.[MQTT-3.10.3-2]The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter. An UNSUBSCRIBE packet with no payload is a protocol violation. [MQTT-3.10.4-1]The Topic Filters (whether they contain wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription is deleted, otherwise no additional processing occurs.[MQTT-3.10.4-2]If a Server deletes a Subscription It MUST stop adding any new messages for delivery to the Client.[MQTT-3.10.4-3]If a Server deletes a Subscription It MUST complete the delivery of any QoS 1 or QoS 2 messages which it has started to send to the Client.[MQTT-3.10.4-4]The Server MUST respond to an UNSUBSUBCRIBE request by sending an UNSUBACK packet. The UNSUBACK Packet MUST have the same Packet Identifier as the UNSUBSCRIBE Packet.[MQTT-3.10.4-5]Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK.[MQTT-3.10.4-6]If a Server receives an UNSUBSCRIBE packet that contains multiple Topic Filters it MUST handle that packet as if it had received a sequence of multiple UNSUBSCRIBE packets, except that it sends just one UNSUBACK response.[MQTT-3.12.4-1]The Server MUST send a PINGRESP Packet in response to a PINGREQ packet.[MQTT-3.14.1-1]The Server MUST validate that reserved bits are set to zero and disconnect the Client if they are not zero.[MQTT-3.14.4-1]After sending a DISCONNECT Packet the Client MUST close the Network Connection.[MQTT-3.14.4-2]After sending a DISCONNECT Packet the Client MUST NOT send any more Control Packets on that Network Connection.[MQTT-3.14.4-3]On receipt of DISCONNECT the Server MUST discard any Will Message associated with the current connection without publishing it, as described in Section  REF _Ref363648298 \r \h 3.1.2.5.[MQTT-4.1.0-1]The Client and Server MUST store Session state for the entire duration of the Session.[MQTT-4.1.0-2]A Session MUST last at least as long it has an active Network Connection.[MQTT-4.3.1-1] In the QoS 0 delivery protocol, the Sender MUST send a PUBLISH packet with QoS=0, DUP=0.[MQTT-4.3.2-1] In the QoS 1 delivery protocol, the Sender MUST assign an unused Packet Identifier each time it has a new Application Message to publish. MUST send a PUBLISH Packet containing this Packet Identifier with QoS=1, DUP=0. MUST treat the PUBLISH Packet as "unacknowledged" until it has received the corresponding PUBACK packet from the receiver. See Section  REF _Ref383618483 \r \h  \* MERGEFORMAT 4.4 for a discussion of unacknowledged messages.[MQTT-4.3.2-2] In the QoS 1 delivery protocol, the Receiver MUST respond with a PUBACK Packet containing the Packet Identifier from the incoming PUBLISH Packet, having accepted ownership of the Application Message. After it has sent a PUBACK Packet the Receiver MUST treat any incoming PUBLISH packet that contains the same Packet Identifier as being a new publication, irrespective of the setting of its DUP flag.[MQTT-4.3.3-1] In the QoS 2 delivery protocol, the Sender MUST assign an unused Packet Identifier when it has a new Application Message to publish. MUST send a PUBLISH packet containing this Packet Identifier with QoS=2, DUP=0. MUST treat the PUBLISH packet as "unacknowledged" until it has received the corresponding PUBREC packet from the receiver. See Section  REF _Ref383618483 \r \h  \* MERGEFORMAT 4.4 for a discussion of unacknowledged messages. MUST send a PUBREL packet when it receives a PUBREC packet from the receiver. This PUBREL packet MUST contain the same Packet Identifier as the original PUBLISH packet. MUST treat the PUBREL packet as "unacknowledged" until it has received the corresponding PUBCOMP packet from the receiver. MUST NOT re-send the PUBLISH once it has sent the corresponding PUBREL packet.[MQTT-4.3.3-2] In the QoS 2 delivery protocol, the Receiver MUST respond with a PUBREC containing the Packet Identifier from the incoming PUBLISH Packet, having accepted ownership of the Application Message. Until it has received the corresponding PUBREL packet, the Receiver MUST acknowledge any subsequent PUBLISH packet with the same Packet Identifier by sending a PUBREC. It MUST NOT cause duplicate messages to be delivered to any onward recipients in this case. MUST respond to a PUBREL packet by sending a PUBCOMP packet containing the same Packet Identifier as the PUBREL. After it has sent a PUBCOMP, the receiver MUST treat any subsequent PUBLISH packet that contains that Packet Identifier as being a new publication.[MQTT-4.4.0-1]When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers.[MQTT-4.5.0-1]When a Server takes ownership of an incoming Application Message it MUST add it to the Session state of those clients that have matching Subscriptions. Matching rules are defined in Section 4.7.[MQTT-4.5.0-2]The Client MUST acknowledge any Publish Packet it receives according to the applicable QoS rules regardless of whether it elects to process the Application Message that it contains.[MQTT-4.6.0-1]When it re-sends any PUBLISH packets, it MUST re-send them in the order in which the original PUBLISH packets were sent (this applies to QoS 1 and QoS 2 messages).[MQTT-4.6.0-2]Client MUST send PUBACK packets in the order in which the corresponding PUBLISH packets were received (QoS 1 messages).[MQTT-4.6.0-3]Client MUST send PUBREC packets in the order in which the corresponding PUBLISH packets were received (QoS 2 messages).[MQTT-4.6.0-4]Client MUST send PUBREL packets in the order in which the corresponding PUBREC packets were received (QoS 2 messages).[MQTT-4.6.0-5]A Server MUST by default treat each Topic as an "Ordered Topic". It MAY provide an administrative or other mechanism to allow one or more Topics to be treated as an "Unordered Topic".[MQTT-4.6.0-6]When a Server processes a message that has been published to an Ordered Topic, it MUST follow the rules listed above when delivering messages to each of its subscribers. In addition it MUST send PUBLISH packets to consumers (for the same Topic and QoS) in the order that they were received from any given Client. [MQTT-4.7.1-1]The wildcard characters can be used in Topic Filters, but MUST NOT be used within a Topic Name.[MQTT-4.7.1-2]The multi-level wildcard character MUST be specified either on its own or following a topic level separator. In either case it MUST be the last character specified in the Topic Filter.[MQTT-4.7.1-3]The single-level wildcard can be used at any level in the Topic Filter, including first and last levels. Where it is used it MUST occupy an entire level of the filter.[MQTT-4.7.2-1]The Server MUST NOT match Topic Filters starting with a wildcard character (# or +) with Topic Names beginning with a $ character.[MQTT-4.7.3-1]All Topic Names and Topic Filters MUST be at least one character long.[MQTT-4.7.3-2]Topic Names and Topic Filters MUST NOT include the null character (Unicode U+0000).[MQTT-4.7.3-3]Topic Names and Topic Filters are UTF-8 encoded strings, they MUST NOT encode to more than 65535 bytes.[MQTT-4.7.3-4]When it performs subscription matching the Server MUST NOT perform any normalization of Topic Names or Topic Filters, or any modification or substitution of unrecognized characters.[MQTT-4.8.0-1]Unless stated otherwise, if either the Server or Client encounters a protocol violation, it MUST close the Network Connection on which it received that Control Packet which caused the protocol violation.[MQTT-4.8.0-2]If the Client or Server encounters a Transient Error while processing an inbound Control Packet it MUST close the Network Connection on which it received that Control Packet.[MQTT-6.0.0-1]MQTT Control Packets MUST be sent in WebSocket binary data frames. If any other type of data frame is received the recipient MUST close the Network Connection.[MQTT-6.0.0-2]A single WebSocket data frame can contain multiple or partial MQTT Control Packets. The receiver MUST NOT assume that MQTT Control Packets are aligned on WebSocket frame boundaries.[MQTT-6.0.0-3]The client MUST include mqtt in the list of WebSocket Sub Protocols it offers.[MQTT-6.0.0-4]The WebSocket Sub Protocol name selected and returned by the server MUST be mqtt.[MQTT-7.0.0-1]A Server that both accepts inbound connections and establishes outbound connections to other Servers MUST conform as both an MQTT Client and MQTT Server.[MQTT-7.0.0-2]Conformant implementations MUST NOT require the use of any extensions defined outside of this specification in order to interoperate with any other conformant implementation. [MQTT-7.1.1-1]A conformant Server MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client. [MQTT-7.1.2-1]A conformant Client MUST support the use of one or more underlying transport protocols that provide an ordered, lossless, stream of bytes from the Client to Server and Server to Client. Revision history (non normative) RevisionDateEditorChanges 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[13][27 September 2013][A Banks]Resolved Issues 64, 68, 76, 86, 27, 60, 82, 55, 78, 51, 83, 80[14][10 October 2013][A Banks] [Rahul Gupta]Resolved Issues 58, 59, 10, 89, 90, 88, 77 Resolved Issues 94, 96, 93, 92, 95, 87, 74, 71[15][24 October 2013][A Banks] [Rahul Gupta]Resolved Issues 52, 97, 98, 101 Resolved Issues 100 Added normative statement numbering and Appendix A[16][21 November 2013][A Banks]Resolved Issues -103, 104, 44[17][05 December 2013][A Banks] [Rahul Gupta]Resolved Issues 105, 70, 102, 106, 107, 108, 109, 110 Updated normative statement numbering and Appendix A[CSD04][28 January 2014][Rahul Gupta]Resolved Issues 112, 114, 115, 120, 117, 134, 132, 133, 130, 131, 129[18][20 February 2014][A Banks] [Rahul Gupta]Resolved Issues 175, 139, 176, 166, 149, 164, 140, 154, 178, 188, 181, 155, 170, 196, 173, 157, 195, 191, 150, 179, 185, 174, 163 Resolved Issues 135, 136, 147, 161, 169, 180, 182, 184, 189, 187[19][28 February 2014][A Banks] [Rahul Gupta]Resolved Issues 167, 192, 141, 138, 137, 198, 165 Resolved Issues 199, 144, 159, [20][07 March 2014][A Banks] [Rahul Gupta]Resolved Issues 113, 162, 158, 146 Resolved Issues 172, 190, 202, 201[21][17 March 2014][A Banks] [Rahul Gupta]Resolved Issues 151, 194, 160, 168 Resolved Issues 205, [22][27 March 2014][Rahul Gupta] [A Banks]Resolved Issues 145, 186, 142 Resolved Issues 152, 193[23][28 March 2014][A Banks]Resolved Issues 204, 148, 210, 208, 209, 171, 183, 117, 212[24][7 April 2014][Rahul Gupta] [A Banks]Added Table of figures Corrected Issue 209[25][8 May 2014][Rahul Gupta]Resolved Issues 213, 214[25][3 September 2014][A Banks]Resolved Issues 240, 242, 246[26][17 September 2014][Rahul Gupta]Resolved Issues 247 [27][18 November 2015][Rahul Gupta] [A Banks]Updated with Errata 01 for Resolved Issue - 275     mqtt-v3.1.1-errata01-os-complete 10 December 2015 #$24STU_derx}~N O P _ ` a m {lbht60JB*phjht60JB*UphhG|Xh1D0JB*phhG|XhY&0JB*phh5ht60J hq8oht6 h:Fht6ht6jht6Uh1Dh]Qh7;h.h)CJaJhWCJaJhn(h)h$xhc)hm^ch#hO[hIjhIU"$Tex` , C  gd)gd gdBgd7;gdG|Xgdgdt6gdsgd1Dgd1Dgd)gd gd )gd m * + , - 9    W Y Z ̶謨}paWhS/0JB*phjhS/0JB*UphhG|XhG|X0JB*phh5hS/0J hG|XhS/hS/jhS/Uht6h7;B*phh]Qh7;h0JB*phhG|Xhs0JB*phh5ht60Jjht60JB*Uphhq8oht60JB*phht60JB*phh:Fht60JB*ph! A B C D 1 2 3 n o p  ñne]V h;|ghBhDB*phhBhB0J$jhBhBB*UphhBhBB*phjhBhBB*Uphh]Qh7;hS/hG|X0JB*ph"jhS/hG|X0JB*UphhG|XhG|X0JB*phh5hS/0JjhS/0JB*UphhS/0JB*phhG|XhS/0JB*ph    UVW 01^ɶݰ~ujfb[P[jhc5hc5U hc5hc5h}h.h)hCLB*phh)h)0J$j h)h)B*Uphh)h)B*phjh)h)B*UphhCL hpSc0J$jhBhBB*UphhBhBB*phhBhB0JjhBhBB*Uph$jhBhBB*Uph^_`xy DEF]^abֺ液{pphQJhQJmH sH j hQJhQJUhQJhQJ0Jj[ hQJhQJUjhQJhQJU hQJhQJh.hxj hc5hc5Uj hc5hc5U hc5hc5hc5hc50Jjhc5hc5Ujn hc5hc5U'  n3=v:k> & F gdZ]> & FgdZ]>gd%U=gd&lgd =gd= wgd= w=gdG|X = & F^gdG|XgdG|XgdQJgd gdc5Z^mn!79>@AB浱yplha h|MLh= wh= wh h5hG|X0JjhG|XU h-hG|XjhG|XU hG|X^J h\*hG|Xh8:phG|X6\ hVhG|XhG|XhQJh|MLmH sH jPhQJhQJUhQJhQJmH sH hQJhQJ0JmH sH jhQJhQJUj hQJhQJU$/0<~Scd0123=YafnĽ}v}rnra]hVh,Nh,NB*^Jphhc5hq#o h%Uh%Uh}h&lhVmHsHh&lh&l0JmHsHjh&lh&lUjh&lh&lUh&lh&lmHsH h&lh&lh&lh&l6 h|MLh hNIh h5h= w0Jh= wjh= wU h= wh= wh= wh= w6! Ya|3 !'!# #(#Z#i$'(W) +gd.?gd >^gdDgd!>gd >gdIgdI>gd $>gd@>gd,Ngd > & FgdZ]> & F gdZ] [cde-./yz{|EF01˷ڳ{ic hX,0J"jWhX,0JB*Uphh0hX,0J"j>hX,0JB*UphhX,0JB*phjhX,0JB*UphhX,h} hw0Jj3hwhwUjhwhwUhR#W hwhwhwhc5h $hh,hihq#o hY&hY&"1230 1 = A B c q r ! ! ! !!!%!&!'!9!H!p!q!иЫڜ|rkd\hBhB6 hBhB hfM6\hBhB6\ hfM0J- hs0J- hC]0J- hV0J-h^hQhIh $hB*phhYhY0JB*phhv2hY0Jh@hY0J hY0JjhY0JUhc5 hihih@hX,0JB*phh1hX,0JB*ph#q!r!!!!!!!!!""!"""#"""""""""###ۯ堕vcVKh|h!mHsHh|h!0JmHsH$jehBh!B*Uphh|h!B*mHphsHjhBh!B*Uphh|h&=mHsH h}0Jh5hfM0J"j8hfM0JB*Uphhq8ohfM0JB*phh:FhfM0JB*phhfM0JB*phjhfM0JB*Uphh4WhfMhB# #'#(#9#>#?#A#B#C###<$=$>$D$E$G$!1%1-1.1<1=1@1A1h1i1j1o1p1u12222233$3ƻʵʱҭҥҡwqdwqwjh&+0JU h&+0Jjhu:0JUh*Kh.0Jj?hHUhHjh*KUh.hmhhHYzh1Y h1Y0JjPh&+Uh&+jhYU h.h.h hVUhhYhshwhs3~h|hImHsH' +,1$3%37333N44 5f556p66+777L888L999P: $  $  $ ?gd gdlgd.$3%3637383O3P3Q3R3n3o3p3q3r3s333333333333333żŦŒŇxfx[xӒżhVmHnHu#jxhgUmHnHujhgUmHnHuhgmHnHu'hshgCJOJQJaJmHnHu*jh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHuh jh Uhwh} h.>*3333333333333334444,4-4.4H4I4J4K4L4M4N4O4P4ɾ~u_ɾM~#jlhgUmHnHu*jh9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#jrhgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu*jh9tEhg0JUmHnHuP4l4m4n4o4444444444444444444455555 5ҿ败t^败L#j`hgUmHnHu*jh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#jfhgUmHnHujhgUmHnHuhgmHnHu$jh9tEhg0JUmHnHu*jh9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHu 5 5 5 5(5)5*5+5C5D5E5_5`5a5c5d5e5f5g5h55555555555ʫʠt^ʠL#jThgUmHnHu*jh9tEhg0JUmHnHuhVmHnHu#jZhgUmHnHujhgUmHnHuhgmHnHu*jh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHu55555555555555 6 6 6666666/6061626M6N6O6i6ӿӱӱuӿӱ_ӱ*j h9tEhg0JUmHnHu#jN hgUmHnHuhgmHnHu*jh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHujhgUmHnHuhVmHnHui6j6k6m6n6o6p6q6r6666666666666666666666ttbL*j"h9tEhg0JUmHnHu#jB"hgUmHnHuhgmHnHu*j!h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHujhgUmHnHu#jH!hgUmHnHu667 7 7$7%7&7(7)7*7+7,7-7I7J7K7L7s7t7u777777777777ұæÓ݊tbæÓ݊#j6$hgUmHnHu*j#h9tEhg0JUmHnHuhgmHnHu$jh9tEhg0JUmHnHuhVmHnHu#j<#hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu7777777777777778 8 8 8)8*8+8E8F8G8I8J8K8L8M8N8ɾ~u_ɾM~#j*&hgUmHnHu*j%h9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j0%hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu*j$h9tEhg0JUmHnHuN8j8k8l8m8x8y8z88888888888888888888888ҿ败t^败L#j(hgUmHnHu*j'h9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j$'hgUmHnHujhgUmHnHuhgmHnHu$jh9tEhg0JUmHnHu*j&h9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHu88889999)9*9+9E9F9G9I9J9K9L9M9N9j9k9l9m9999999ʫʠt^ʠL#j*hgUmHnHu*j)h9tEhg0JUmHnHuhVmHnHu#j)hgUmHnHujhgUmHnHuhgmHnHu*j(h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHu99999999999999999999999::::::-:.:/:I:ӿӱӱuӿӱ_ӱ*j+h9tEhg0JUmHnHu#j +hgUmHnHuhgmHnHu*j*h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHujhgUmHnHuhVmHnHu I:J:K:M:N:O:P:Q:R:n:o:p:q::::::::::::::::::ttbL*j}-h9tEhg0JUmHnHu#j-hgUmHnHuhgmHnHu*j,h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHujhgUmHnHu#j,hgUmHnHuP:: ;y;;<<<;===C>>>????N@@@IAA!BzBBCCCLD $  $ :::;;;;;; ;!;";>;?;@;A;V;W;X;r;s;t;v;w;x;y;z;{;;;;涢uc涢M*jq/h9tEhg0JUmHnHu#j.hgUmHnHu*jw.h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHu#j-hgUmHnHujhgUmHnHuhgmHnHu;;;;;;;;;;;;;;;;;;;;;<<<<<<<<<:<;<ԳŨߋucŨߋ#j0hgUmHnHu*jk0h9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j/hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu;<<<=<i<j<k<<<<<<<<<<<<<<<<<<<<<<<<<<ɾ~u_ɾM~#j2hgUmHnHu*j_2h9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j1hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu*je1h9tEhg0JUmHnHu<=======4=5=6=8=9=:=;=<===Y=Z=[=\=i=j=k=======ҿ败t^败L#j4hgUmHnHu*jS4h9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j3hgUmHnHujhgUmHnHuhgmHnHu$jh9tEhg0JUmHnHu*jY3h9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHu==================== > > >> >!>"><>=>>>ʫʠt^ʠL#j6hgUmHnHu*jG6h9tEhg0JUmHnHuhVmHnHu#j5hgUmHnHujhgUmHnHuhgmHnHu*jM5h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHu>>@>A>B>C>D>E>a>b>c>d>y>z>{>>>>>>>>>>>>>>>>>>ӿӱӱuӿӱ_ӱ*j;8h9tEhg0JUmHnHu#j7hgUmHnHuhgmHnHu*jA7h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHujhgUmHnHuhVmHnHu>>>>>>>>> ? ? ?????8?9?:????@?A?]?^?_?`?m?ttbL*j/:h9tEhg0JUmHnHu#j9hgUmHnHuhgmHnHu*j59h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHujhgUmHnHu#j8hgUmHnHum?n?o??????????????????????????@@@涢uc涢M*j#<h9tEhg0JUmHnHu#j;hgUmHnHu*j);h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHu#j:hgUmHnHujhgUmHnHuhgmHnHu@@+@,@-@G@H@I@K@L@M@N@O@P@l@m@n@o@@@@@@@@@@@@@@@ԳŨߋucŨߋ#j=hgUmHnHu*j=h9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j<hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu@@@@@@@@@@@@@@@AAAA&A'A(ABACADAFAGAHAIAJAKAɾ~u_ɾM~#j?hgUmHnHu*j?h9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j>hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu*j>h9tEhg0JUmHnHuKAgAhAiAjAAAAAAAAAAAAAAAAAAABBBBBB Bҿ败t^败L#jAhgUmHnHu*jAh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j@hgUmHnHujhgUmHnHuhgmHnHu$jh9tEhg0JUmHnHu*j @h9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHu B!B"B#B?B@BABBBWBXBYBsBtBuBwBxByBzB{B|BBBBBBBBBBBʫʠt^ʠL#jvChgUmHnHu*jBh9tEhg0JUmHnHuhVmHnHu#j|BhgUmHnHujhgUmHnHuhgmHnHu*jAh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuBBBBBBBBBBBBBBCCCCCCCCC:C;CF?F@FAFNFOFPFjFkFlFnFoFpFqFrFsFFFFFFFFFFFFFFҿ败t^败L#j4NhgUmHnHu*jMh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j:MhgUmHnHujhgUmHnHuhgmHnHu$jh9tEhg0JUmHnHu*jLh9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHuFFFFFFFFGGG"G#G$G&G'G(G)G*G+GGGHGIGJG\G]G^GxGyGzGʫʠt^ʠL#j(PhgUmHnHu*jOh9tEhg0JUmHnHuhVmHnHu#j.OhgUmHnHujhgUmHnHuhgmHnHu*jNh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuzG|G}G~GGGGGGGGGGGGGGGGGGGGGGGGHHH"Hӿӱӱuӿӱ_ӱ*jQh9tEhg0JUmHnHu#j"QhgUmHnHuhgmHnHu*jPh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHujhgUmHnHuhVmHnHu"H#H$H&H'H(H)H*H+HGHHHIHJHXHYHZHtHuHvHxHyHzH{H|H}HHHHHHttbL*jSh9tEhg0JUmHnHu#jShgUmHnHuhgmHnHu*jRh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHujhgUmHnHu#jRhgUmHnHuHHHHHHHHHHHHIIIIIII4I5I6I8I9I:I;IS?SYSZS[S]S^S_S`SaSbS~SSSSSSSSSSSSSҿ败t^败L#jVrhgUmHnHu*jqh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j\qhgUmHnHujhgUmHnHuhgmHnHu$jh9tEhg0JUmHnHu*jph9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHuSSSSSSSSTTT3T4T5T7T8T9T:T;TvhgUmHnHuUUU VVVVVVVVV2V3V4V5VVVWVXVrVsVtVvVwVxVyVzV{VVVV涢uc涢M*jyh9tEhg0JUmHnHu#j,yhgUmHnHu*jxh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHu#j2xhgUmHnHujhgUmHnHuhgmHnHuVVVVVVVVVVVVVVVVVVWWW,W-W.W0W1W2W3W4W5WQWRWԳŨߋucŨߋ#j {hgUmHnHu*jzh9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j&zhgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHuRWSWTWrWsWtWWWWWWWWWWWWWWWWWWWWWWWWWWɾ~u_ɾM~#j}hgUmHnHu*j|h9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j|hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu*j{h9tEhg0JUmHnHuW X X X XXXXXX3X4X5X7X8X9X:X;XZ?Z@ZBZCZDZEZFZGZcZdZeZfZZZZZZZZZZZZZZZZ涢uc涢M*jgh9tEhg0JUmHnHu#jhgUmHnHu*jmh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHu#jhgUmHnHujhgUmHnHuhgmHnHuZZ[[["[#[$[&['[([)[*[+[G[H[I[J[[[[[[[[[[[[[[[ԳŨߋucŨߋ#jޅhgUmHnHu*jah9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#jhgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu[[[\\\\\ \"\#\$\%\&\'\C\D\E\F\s\t\u\\\\\\\\\\ɾ~u_ɾM~#j҇hgUmHnHu*jUh9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j؆hgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu*j[h9tEhg0JUmHnHu\\\\\\\\]]]] ] ] ] ] ])]*]+],]N]O]P]j]k]l]n]o]p]ҿ败t^败L#jƉhgUmHnHu*jIh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#j̈hgUmHnHujhgUmHnHuhgmHnHu$jh9tEhg0JUmHnHu*jOh9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHup]q]r]s]]]]]]]]]]]]]]]]]]]]] ^ ^^(^)^*^ʫʠt^ʠL#jhgUmHnHu*j=h9tEhg0JUmHnHuhVmHnHu#jhgUmHnHujhgUmHnHuhgmHnHu*jCh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu'hshgCJOJQJaJmHnHu*^,^-^.^/^0^1^M^N^O^P^h^i^j^^^^^^^^^^^^^^^^^^^^ӿӱӱuӿӱ_ӱ*j1h9tEhg0JUmHnHu#jhgUmHnHuhgmHnHu*j7h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHujhgUmHnHuhVmHnHu ^^^^^^^^^____/_0_1_K_L_M_O_P_Q_R_S_T_p_q_r_s_t_ttbL*j%h9tEhg0JUmHnHu#jhgUmHnHuhgmHnHu*j+h9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHujhgUmHnHu#jhgUmHnHut_u____________________________```ұæÓ݊tbæÓ݊#jhgUmHnHu*jh9tEhg0JUmHnHuhgmHnHu$jh9tEhg0JUmHnHuhVmHnHu#jhgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu```0`1`2`L`M`N`P`Q`R`S`T`U`q`r`s`t`````````````ɾ~u_ɾM~#jhgUmHnHu*jh9tEhg0JUmHnHuhgmHnHu'hshgCJOJQJaJmHnHuhVmHnHu#jhgUmHnHujhgUmHnHuhgmHnHuh9tEhg0JmHnHu$jh9tEhg0JUmHnHu*jh9tEhg0JUmHnHu````````````aaaaaaaaa7a8a9a:aEaFataҿzhz]zG*jh9tEhg0JUmHnHuhVmHnHu#jhgUmHnHujhgUmHnHuhgmHnHu,h9tEhg0JfHmHnHq u'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHu*j h9tEhg0JUmHnHuh9tEhg0JmHnHuhgmHnHutauavaaaaaaaaaaaaaaaaaaaaabbbbbbb涢u^L涢#j~hgUmHnHu,h9tEhg0JfHmHnHq u*jh9tEhg0JUmHnHuhgmHnHuh9tEhg0JmHnHu'hshgCJOJQJaJmHnHu$jh9tEhg0JUmHnHuhVmHnHu#jhgUmHnHujhgUmHnHuhgmHnHub b b&b'b>b?b@bAb]b^b_b`bbbbbbbbbbϽϽkRkCkhVCJaJmHnHu1jxhEShCJUaJmHnHu+jhEShCJUaJmHnHu"hEShCJaJmHnHu2jhESh0JCJUaJmHnHuhEShCJaJmHnHu#hESh0JCJaJmHnHu,jhESh0JCJUaJmHnHujhUh h>*jh U b&bb,ccdhdd-eefff[gg!hhhUii0jjkfkk`l 7 $ ^gdgdES  $ gdES?gdbbbbbb*c+c,c-c.cJcKcLcMc}c~cccιۧۗvmvWvL=LjhUmHnHuhmHnHu*j~hfh0JUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHuhEShESCJaJmHnHu#hJhES0JCJaJmHnHu(jhJCJUaJmHnHuhJCJaJmHnHu"jhJCJUaJmHnHu#hEShES0JCJaJmHnHucccccccccccccccccccdddddd"d#d$d%dEdttbL*jrhfh0JUmHnHu#jhUmHnHuhmHnHu*jxhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHujhUmHnHu#jhUmHnHuEdFdGdadbdcdedfdgdhdidjdddddddddddddddddddd涢uc涢M*jfhfh0JUmHnHu#jhUmHnHu*jlhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHudd e e e&e'e(e*e+e,e-e.e/eKeLeMeNereseteeeeeeeeeeeeԳŨߋucŨߋ#jݜhUmHnHu*j`hfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHueeeeeefffffffff3f4f5f6fhfifjffffffffffɾ~u_ɾM~#jўhUmHnHu*jThfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jםhUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu*jZhfh0JUmHnHufffffffffffffffffgggg8g9g:gTgUgVgXgYgZgҿ败t^败L#jŠhUmHnHu*jHhfh0JUmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#j˟hUmHnHujhUmHnHuhmHnHu$jhfh0JUmHnHu*jNhfh0JUmHnHuhfh0JmHnHuhmHnHuZg[g\g]gygzg{g|ggggggggggggggggggghhhhʫʠt^ʠL#jhUmHnHu*j<hfh0JUmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHu*jBhfh0JUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu'h&'hCJOJQJaJmHnHuhhh h!h"h#h?h@hAhBh]h^h_hyhzh{h}h~hhhhhhhhhhhhhӿӱӱuӿӱ_ӱ*j0hfh0JUmHnHu#jhUmHnHuhmHnHu*j6hfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHujhUmHnHuhVmHnHuhhhhhhhhhiiii2i3i4iNiOiPiRiSiTiUiViWisitiuiviittbL*j$hfh0JUmHnHu#jhUmHnHuhmHnHu*j*hfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHujhUmHnHu#jhUmHnHuiiiiiiiiiiiiiiii jjj)j*j+j-j.j/j0j1j2jNjOjPj涢uc涢M*jhfh0JUmHnHu#jhUmHnHu*jhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHuPjQjwjxjyjjjjjjjjjjjjjjjjjkkkkkkkk k%k&kԳŨߋucŨߋ#jhUmHnHu*jhfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu&k'k(kCkDkEk_k`kakckdkekfkgkhkkkkkkkkkkkkkkkkkɾ~u_ɾM~#jhUmHnHu*jhfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu*j hfh0JUmHnHukkkkk=l>l?lYlZl[l]l^l_l`lalbl~lllllllllllllҿ败t^败L#jwhUmHnHu*jhfh0JUmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#j}hUmHnHujhUmHnHuhmHnHu$jhfh0JUmHnHu*jhfh0JUmHnHuhfh0JmHnHuhmHnHu`llppDqq"rr sxssStt?uuvvwywwTxx 7 $ ^gdllllllllmmm5m6m7m9m:m;mmZm[m\m]mmmmmmmʫʠt^ʠL#jkhUmHnHu*jhfh0JUmHnHuhVmHnHu#jqhUmHnHujhUmHnHuhmHnHu*jhfh0JUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu'h&'hCJOJQJaJmHnHummmmmmmmmmmmmmnnnnnnnnn5n6n7n8ncndnennӿӱӱuӿӱ_ӱ*jhfh0JUmHnHu#jehUmHnHuhmHnHu*jhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHujhUmHnHuhVmHnHunnnnnnnnnnnnnnnnnnnnnnnnnoooo>ottbL*jֲhfh0JUmHnHu#jYhUmHnHuhmHnHu*jܱhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHujhUmHnHu#j_hUmHnHu>o?o@oZo[o\o^o_o`oaobocoooooooooooooooooooo涢uc涢M*jʴhfh0JUmHnHu#jMhUmHnHu*jгhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHu#jShUmHnHujhUmHnHuhmHnHuooppp7p8p9p;pp?p@p\p]p^p_pppppppppppppppԳŨߋucŨߋ#jAhUmHnHu*jĵhfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jGhUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHuppp!q"q#q=q>q?qAqBqCqDqEqFqbqcqdqeqqqqqqqqqqqqqɾ~u_ɾM~#j5hUmHnHu*jhfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#j;hUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu*jhfh0JUmHnHuqqqqqqrrrrrr r!r"r#r$r@rArBrCrzr{r|rrrrrrrҿ败t^败L#j)hUmHnHu*jhfh0JUmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#j/hUmHnHujhUmHnHuhmHnHu$jhfh0JUmHnHu*jhfh0JUmHnHuhfh0JmHnHuhmHnHurrrrrrrrrrrssssss s s s's(s)s*sUsVsWsqsrsssʫʠt^ʠL#jhUmHnHu*jhfh0JUmHnHuhVmHnHu#j#hUmHnHujhUmHnHuhmHnHu*jhfh0JUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu'h&'hCJOJQJaJmHnHussusvswsxsyszssssssssssssssssstttt0t1t2tLtӿӱӱuӿӱ_ӱ*jhfh0JUmHnHu#jhUmHnHuhmHnHu*jhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHujhUmHnHuhVmHnHuLtMtNtPtQtRtStTtUtqtrtstttttttttttttttttttuttbL*jhfh0JUmHnHu#j hUmHnHuhmHnHu*jhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHujhUmHnHu#jhUmHnHuuuu8u9u:uu?u@uAu]u^u_u`uuuuuuuuuuuuuuuu涢uc涢M*j|hfh0JUmHnHu#jhUmHnHu*jhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHuuuuuuvvvvvvv v!v=v>v?v@vwvxvyvvvvvvvvvvvvԳŨߋucŨߋ#jhUmHnHu*jvhfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHuvvvvvvwwwwwww w w&w'w(w)wVwWwXwrwswtwvwwwxwywzw{wɾ~u_ɾM~#jhUmHnHu*jjhfh0JUmHnHuhmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu*jphfh0JUmHnHu{wwwwwwwwwwwwwwwwwxxxx1x2x3xMxNxOxQxRxSxҿ败t^败L#jhUmHnHu*j^hfh0JUmHnHu'h&'hCJOJQJaJmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHu$jhfh0JUmHnHu*jdhfh0JUmHnHuhfh0JmHnHuhmHnHuSxTxUxVxrxsxtxuxxxxxxxxxxxxxxxxx$y%y&y@yAyByʫʠt^ʠL#jhUmHnHu*jRhfh0JUmHnHuhVmHnHu#jhUmHnHujhUmHnHuhmHnHu*jXhfh0JUmHnHuhmHnHuhfh0JmHnHu$jhfh0JUmHnHu'h&'hCJOJQJaJmHnHuByDyEyFyGyHyIyeyfygyhyyyyyyyyyyyyyyyyy*z+z,zFzӿӱӱuӿӱ_ӱ*jFhfh0JUmHnHu#jhUmHnHuhmHnHu*jLhfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHujhUmHnHuhVmHnHuxGyyMzzzzzzz{L{{{5|i||}} ~~ gdg5 & F dgdZ]gdg5 & FgdZ]$ & F xa$gdZ]@gd @gd  $ gd 7 $ ^gdFzGzHzJzKzLzMzNzOzkzlzmznzzzzzzzzzzzzzzzttbXTMIhg5 h}h}h}jhUaJ#jhUmHnHuhmHnHu*j@hfh0JUmHnHuhmHnHuhfh0JmHnHu'h&'hCJOJQJaJmHnHu$jhfh0JUmHnHuhVmHnHujhUmHnHu#jhUmHnHuzzz{{{0{1{2{J{K{L{M{s{t{u{{{{{{{{{{{{|||3|4|5|6|Q|R|S|g|h|i|j|||||||||ܭܭܭܭܭz h shg5jhg5Uj\hg5Ujhg5UjBhg5Uhmhg50Jjhg5U hZhg5hDhg50Jj:hg5Ujhg5Uh7thg55] hqFhg5hg5 h.hg50||||}}}}}}}}}~ ~ ~ ~~~~g~ҿq^NH?H5hhg50J-5hJhg50J- hg50J-hg5B*OJQJ^JaJph%h;Dhg5B*OJQJ^JaJph hhg50JOJQJ^JaJ.jh ?B*OJQJU^JaJphh ?B*OJQJ^JaJph(jhB*OJQJU^JaJph%h;!hg5B*OJQJ^JaJph hB hg5 h0shg5hmhg50Jjhg5UjZhg5Uhg5~v~~~/ v Fb,_قɃ> & FgdZ] gdg5 & F gdZ] & F [$^`gdZ]gdg5g~v~z~~~~~~~~ '(),-/BCE uvǀȀbijλƷέΙΆ~wp]%h"Ahg5B*OJQJ^JaJph hhg5 hT^hg5hT^hg55%hQhg5B*OJQJ^JaJph h;!hg5hJhg50J-PJ^Jhg50J-PJ^JhVjThg5Ujhg5Uhg5%h#|)hg5B*OJQJ^JaJphhg5B*OJQJ^JaJphhJ+hg50J-5j +23]^؂قTǃȃɃӃԃՃ =>FGhnstu¸ܥܥ܋¸~ܥܥܥܸkkk%h-}hg5B*OJQJ^JaJphhrhg50J-PJ^J hF{hg5%hF{hg5B*OJQJ^JaJph%he~hg5B*OJQJ^JaJphhg50J-PJ^JhJhg50J-PJ^Jhp hg50J-PJ^Jhg5B*OJQJ^JaJph%ho9Qhg5B*OJQJ^JaJph*u{|}$&BIUV\Նֆн~raRAr jhg5B*U^JaJphh;!hg5B*^JaJph hqhg56B*^JaJphhg5B*^JaJph h\hg50J-OJPJQJ^Jhg5hg50JNCJaJ%h;!hg5B*OJQJ^JaJphhJhg50J-PJ^J%hz'hg5B*OJQJ^JaJphhg50J-PJ^J(h-}hg55B*OJQJ^JaJphhg5B*OJQJ^JaJph܇݇߇/DEFikostuijġti]L>L.hNhg55OJPJQJ^Jhg50J-OJPJQJ^J h\hg50J-OJPJQJ^JhVDhg55\aJh hg50J^J#h:hg56B*]^JaJphh:hg56]^Jhg56B*]^JaJph#h hg56B*]^JaJph h3,hg50J-OJPJQJ^Jhg5B*aJphffhqwhg50J^JaJ jhg5B*U^JaJph&jhg5B*U^JaJphއ߇jku<=G'PQW#gdg5 & FgdZ]gdg5u:;<=AEFGʼnljȉɉƹƨЙƋzzjƹYЙƋ!jChg5UaJmH sH hNhg55OJPJQJ^J h\hg50J-OJPJQJ^Jhg50J-OJPJQJ^JhRhg50JaJmH sH !jhg5UaJmH sH hC[hg5aJmH sH hg5aJmH sH jhg5UaJmH sH hg56B*]^JaJph#hC[hg56B*]^JaJph%'(]^_Ҋ˼yhd]TA++h;!hg56B*OJPJQJ]^Jph%hg55B*OJPJQJ\^Jphffh3,hg50J- hvhg5hg5 hrbhg5B*]^JaJphhrbhg50J]^JaJ)jhg5B*U]^JaJphhg5B*]^JaJph#jhg5B*U]^JaJphhg56B*]^JaJph#hf.hg56B*]^JaJph#hVDhg56B*]^JaJph hVDhg50J-OJPJQJ^JҊӊڊߊ*+,NOPQRWԋՋ֋Ÿŕŋ}l}VNJ?N9N hg50Jjthg5Uhg5jhg5U+hXhg56B*OJPJQJ]^Jph h\hg50J-OJPJQJ^Jhg50J-OJPJQJ^Jhg5OJQJ^Jh;!hg50JOJQJ^J'jh;!hg5OJQJU^Jh;!hg5OJQJ^J!jh;!hg5OJQJU^J+h;!hg56B*OJPJQJ]^Jph%hg56B*OJPJQJ]^Jph:Ōƌь Ώ= @b#gdg5gdg5# 2( Px 4 #\'*.25@9gdg59:;ÌČŌƌnjόЌь^_`ïyhhVRGAR hg50JjHhg5Uhg5#h~hg56B*]^JaJph h*Bhg50J-OJPJQJ^Jhhg5mHsHhaZhg50JmHsHj]hg5UhaZhg5mHsHjhg5U'haZhg56B*]^JmHphsH3hhg56B*OJPJQJ]^JmHphsH(hhg50J-OJPJQJ^JmHsHhg50J-OJPJQJ^JKLM klmÏ͏Ώ=Ѽͫ|qѼjYG#hrhg56B*]^JaJph hrhg50J-OJPJQJ^J hg50J-5j"hg5Uhg56B*]^JaJph#h"hg56B*]^JaJphhg50J-OJPJQJ^J h*Bhg50J-OJPJQJ^J hg50Jj5hg5Uhg5jhg5U+hXhg56B*OJPJQJ]^Jph h31hg50J-OJPJQJ^J=> 456=>@bcoϾ{j^O^;&jhg5B*U^JaJphhahg5B*^JaJphhg5B*^JaJph jhg5B*U^JaJph+h#hg56B*OJPJQJ]^Jph/jhh31hg50J-OJPJQJU^J)jh31hg50J-OJPJQJU^J h31hg50J-OJPJQJ^Jh"hg50J-5hrhg50Jj9hg50JU hg50Jjhg50JUVW67œȷȥȷrgR(hhg50J-OJPJQJ^JmH sH jhg5U+hXhg56B*OJPJQJ]^Jph hg50Jjhg5Uhg5jhg5U#hXhg56B*]^JaJph h*Bhg50J-OJPJQJ^Jhg50J-OJPJQJ^Jhg5B*^JaJphh{1Lhg50J^JaJ jhg5B*U^JaJphb6œޓWXa$# 2( Px 4 #\'*.25@9gdg5#gdg5$ 5( \ Px 4 #\'*.25@9gdg5gdg5œޓߓ !"UVWXYaݔޔߔݺݯ{eUQF@Q{ hg50Jjhg5Uhg5hXhg56B*]^Jph+hXhg56B*OJPJQJ]^Jphhg50J-OJPJQJ^J h*Bhg50J-OJPJQJ^J(hhg50J-OJPJQJ^JmH sH haZhg5mH sH h**hg50JmH sH jhg5Uh**hg5mH sH jhg5U3hhg56B*OJPJQJ]^JmH phsH !"$˕͕ΕϕghizgcQ?#jhg5B*U]^JaJph#h hg56B*]^JaJphhg5$hRhg50JOJPJQJ^JaJ)jhg5OJPJQJU^JaJ hqhg5OJPJQJ^JaJhg5OJPJQJ^JaJ#jhg5OJPJQJU^JaJhg56B*]^JaJph#hqhg56B*]^JaJphhg50J-OJPJQJ^J h31hg50J-OJPJQJ^Jh–̖i—×͗h™Ù͙wx<# 2( Px 4 #\'*.25@9gdg5gdg5iu–̖hijv×̗̺zrngn\rSrnB h:hg50J-OJPJQJ^JhRhg50Jj hg5U h hg5hg5jhg5Uhg56B*]^JaJph#h hg56B*]^JaJph h31hg50J-OJPJQJ^JhRhg50J]^JaJ#jhg5B*U]^JaJph)jShg5B*U]^JaJph h hg5B*]^JaJphhg5B*]^JaJph̗͗ŘǘȘɘhi™Ù͙+NPQRuvx}žųɪŢŗɎŇvžkɪZ hhg50J-OJPJQJ^Jj7hg5U h31hg50J-OJPJQJ^J h hg5hJhg50Jj~hg5Uhhg55hRhg50Jjhg5U hC[hg5hg5jhg5Uhg56B*]^JaJph#hC[hg56B*]^JaJphhg50J-OJPJQJ^J#}~;<=IlnopXYZj~ĵ}lZOIlZ hg50Jjhg5U#h#hg56B*]^JaJph h#hg50J-OJPJQJ^J h]hg50J-OJPJQJ^JhRhg50Jjhg5U hC[hg5hg5jhg5Uhg56B*]^JaJph#hC[hg56B*]^JaJphh#hg50J-PJ hhg50J-OJPJQJ^Jhg50J-OJPJQJ^JZ[j~ ן؟ $$Ifa$gdZ] & Fgdg5Ogdg5 & FgdZ] & FgdZ]# 2( Px 4 #\'*.25@9gdg5gdg5~ ȝޝ "CJ '()ϺϺϺϺϺϺϺϺϞwhh;Dhg50JB*aJph(j}h;Dhg5B*UaJph"jh;Dhg5B*UaJphh;Dhg5B*aJphhzhg5B*^JaJph h|Phg5 hdxUhg5 h"n3hg5hg5 hg50Jjh#hg50JUh#hg50Jjh#hg50JU&)*NOPghipqrs֟ן؟9:[fjk àɠʠhػ؛ػ؉wppph]hThpphdhg50Jj_hg5Ujhg5U h"hg5#hshg56B*]^JaJph#h{hg56B*]^JaJph>jh;Dhg50J-5B*OJPJQJU\^Jph8jh;Dhg50J-5B*OJPJQJU\^Jph/h;Dhg50J-5B*OJPJQJ\^Jphhg5hu hg5B*phff0ʢ ()*124MNOѾѾu_L5-j *h;Dhg5B*PJU^JaJph$ *h;Dhg5B*PJ^JaJph+ *h;Dhg50JB*PJ\^JaJph6j *h;Dhg5B*PJU\^JaJph0j *h;Dhg5B*PJU\^JaJph' *h;Dhg5B*PJ\^JaJph$ *h ]hg5B*PJ^JaJph *hg5B*PJ^JaJphhg5h~hg55hg5CJaJhfSphg5CJaJ "$&(*,.018J $IfgdZ]Ff $$Ifa$gdZ] JKRdvma $$Ifa$gdZ] $IfgdZ]kd2$$Ifl0 $x  t0644 lapytZ]deovma $$Ifa$gdZ] $IfgdZ]kd$$Ifl0 $x  t0644 lapytZ])ŧƧܧ.0vqqqqeYTgdi $^a$gdg5  & F|^|gdZ]gdg5kdp$$Ifl0 $x  t0644 lapytZ]Ohijqrsףݣ0189BCHJKLMNQRTUVjŤӼ혈vnvnvnvg h@ hg5hg5B*phh1hg5B*ph hXjhg5 *hg5B*PJ^JaJph$ *h ]hg5B*PJ^JaJph *h;Dhg5B*PJ^Jph-j *h;Dhg5B*PJU^JaJph3j *h;Dhg5B*PJU^JaJph$ *h;Dhg5B*PJ^JaJph(ŤҤӤڤۤ  !"#$%&'()]^_`yz{˸ִִ_>jh;Dhg50J-5B*OJPJQJU\^Jph8jh;Dhg50J-5B*OJPJQJU\^Jph/h;Dhg50J-5B*OJPJQJ\^Jphhg5h;Dhg5B*phhg5B*phh1hg5B*ph hXjhg5 *hg5B*PJ^JaJph$ *h ]hg5B*PJ^JaJph{˥̥ӥԥ ab̴̴̴yf$ *hRhg5B*PJ^JaJph *hg5B*PJ^JaJph>jbh;Dhg50J-5B*OJPJQJU\^Jph hXjhg5hg5/h;Dhg50J-5B*OJPJQJ\^Jph8jh;Dhg50J-5B*OJPJQJU\^Jph,h;Dhg50JB*OJPJQJ\^Jph&§çħŧƧܧ4.0ĩ#345SXYZuxz{Ľ˩˛ˆ{slllllllll hmhih~hi5hfSphiCJaJhi!h_%hg5B*OJQJaJphhg5B*OJQJaJph&hg5B*OJPJQJ^JaJo(ph hT|hg5 h\hg5hg5#hshg56B*]^JaJphh;Dhg5B*phhg5B*phh1hg5B*ph*0ĩƩԩ $Ifgd[nFf $$Ifa$gd[n & Fgdi  vmaaaaaaaa $$Ifa$gd[n $Ifgd[nkd'$$Ifl0$z t0644 lapyt[n 678:<>@B\kd$$Ifl0$z t0644 lapyt[n $$Ifa$gd[n $Ifgd[nFf BDFHIP[\]_a\kd $$Ifl0$z t0644 lapyt[n $Ifgd[nFf $$Ifa$gd[n acegikmnu|}\kd$$Ifl0$z t0644 lapyt[n $Ifgd[nFf $$Ifa$gd[n }~Ff $$Ifa$gd[n $Ifgd[n vmaaaaaaaa $$Ifa$gd[n $Ifgd[nkd$$Ifl0$z t0644 lapyt[n ªĪƪȪʪZkd$$Ifl0$z t0644 lapyt[n $$Ifa$gd[n $Ifgd[nFf ت۪ݪު!"( 9:=HVn,FGfghѮȹȮȝȊȝhJZhg50Jjhg5Uhg5CJaJhfSphg5CJaJ hg50Jj hg5Ujhg5U h:rhg5hg5h}hiB*phhQhiB*phht *hQhi h%Yhi hmhihi0ʪ̪ΪЪѪتߪ\kd $$Ifl0$z t0644 lapyt[n $Ifgd[nFf| $$Ifa$gd[n ѫ<=n $$Ifa$gdZ] & Fgdg5gdg5 & FgdZ]$ & F xa$gdZ]gdi & Fgdi $^a$gdg5Ffo  $$Ifa$gd[n׭ $$Ifa$gdZ]okdM$$IflD%% t0%44 lap ytZ]׭ح $$Ifa$gdZ]okd$$IflD%% t0%44 lap ytZ]Ѯծ׮ٮۮݮ߮znnnnnnn $$Ifa$gdZ] & Fgdg5gdg5 & FgdZ]okdU$$IflD%% t0%44 lap ytZ] 67Dkd$$IflF$<H t06    44 lapytZ] $IfgdZ]Ffs $$Ifa$gdZ]Ѯjktǯȯ -1278IVktڰ!*jkuƱ !+KLMTز󽵽 hehg5 hg5h; h|Phg5 hg55hg5CJaJhfSphg5CJaJhJZhg50Jj*hg5Ujhg5Uh|Phg55 h_hg5hg5hHhg55=7?PQRk a\T\\\ & FgdZ]gdg5kd$$Ifl0$<, t0644 lapytZ] $$Ifa$gdZ] $IfgdZ] -28JV $$Ifa$gdZ] & Fgdg5VW`bluG>2>> $$Ifa$gdZ] $IfgdZ]kd$$Ifl\ H$}T t044 lap(ytZ]uv~G>2>> $$Ifa$gdZ] $IfgdZ]kdq$$Ifl\ H$}Z t044 lap(ytZ]ѰG>2>> $$Ifa$gdZ] $IfgdZ]kd=$$Ifl\ H$}Z t044 lap(ytZ]G>2>> $$Ifa$gdZ] $IfgdZ]kd $$Ifl\ H$}Z t044 lap(ytZ]"23:<>2 $$Ifa$gdZ]kd$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ]<MZl>kd$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $IfgdZ] $$Ifa$gdZ]G>2>> $$Ifa$gdZ] $IfgdZ]kdm$$Ifl\ H$}Z t044 lap(ytZ]"LMUW>2 $$Ifa$gdZ]kd9$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ]Whu>kd$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ]в2kd$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ]*2kd$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ])=>?RS[o|}ҳسٳ "/9ASYcw´ (,-KLMþþj# *h:hg5Uj *hg5U *hg5 *hShg5h:hg50Jj5#hg5Ujhg5U h`hg5 h|Phg5 hehg5hg5=*->RS\2kdi$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ]\_p2kd5$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ]2kd $$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ]³ӳ2kd $$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ]#2kd!$$Ifl\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ]#&09:0kde"$$Ifl<\ H$}Z t044 lap(ytZ] $IfgdZ] $$Ifa$gdZ]:;AstǶ $$Ifa$gdZ] & Fgdg5 & FgdZ]gdg5 Mbcgõŵ  !"#/0IJKNOrt޸޸ǭǭǗog\hfSphg5CJaJhVB*ph$j+$hD2hg5B*Uphhg5B*phjhg5B*UphhFhg5B*phh;Dhg5B*phh1hg5B*ph *h1hg5 h Whg5hg5B*phhShg5B*phhg5 *hg5 *hShg5j *hg5U *h:hg50J!ƶǶ $%,-XYYZdjkt)?x./NOPYZԿԴԩԢԒԒԿԇ hg50Jj2hg5Uh\hg55h42hg55 h]hg5 h~8hg5hVj2hg5Ujhg5U hg5H*hWhg5H*hg5h hg55h1hg55 hg55hfSphg5CJaJhg5CJaJ1Ƕȶkd$$$IflֈP8 t044 lahp<ytZ]ȶжٶ۶ݶ߶ $IfgdZ]kd%$$IflֈP8 t044 lahp<ytZ] $IfgdZ]kdr&$$IflֈP8 t044 lahp<ytZ]!&. $IfgdZ]./kdW'$$IflֈP8 t044 lahp<ytZ]/6?ACEG $IfgdZ]GHkd<($$IflֈP8 t044 lahp<ytZ]HOXZ\^` $IfgdZ]`akd!)$$IflֈP8 t044 lahp<ytZ]ahqsuwy $IfgdZ]yzkd*$$IflֈP8 t044 lahp<ytZ]z $IfgdZ]kd*$$IflֈP8 t044 lahp<ytZ] $IfgdZ]kd+$$IflֈP8 t044 lahp<ytZ]·ķƷȷ $IfgdZ]ȷɷkd,$$IflֈP8 t044 lahp<ytZ]ɷշ޷ $IfgdZ]kd-$$IflֈP8 t044 lahp<ytZ] $IfgdZ]kd.$$IflֈP8 t044 lahp<ytZ]  $IfgdZ]kdj/$$IflֈP8 t044 lahp<ytZ]%.0246 $IfgdZ]67kdO0$$IflֈP8 t044 lahp<ytZ]7BKMOQS $IfgdZ]STkd41$$IflֈP8 t044 lahp<ytZ]TUظZkef()?wx.Ӿھ߾ $$Ifa$gdZ] & Fgdg5 $^a$gdg5$a$gdg5 & FgdZ]gdg5Ӿ $=>Z^,;LWHSeflsv67XZŻŻŻŻŻŻŻŻ黨Hhs;gh$xOJQJ^J%Hhs;gheh$xOJQJ^Jhg5OJQJ^Jh}|%hg5OJQJ^Jh}|%hg56h\hg55 h42hg5hg5hHhg55hphg5CJaJ<`THH $$Ifa$gdZ] $$Ifa$gdZ]kd3$$IflF*: t06    44 lapytZ] !`THH $$Ifa$gdZ] $$Ifa$gdZ]kd3$$IflF*: t06    44 lapytZ]!"$>[`THH $$Ifa$gdZ] $$Ifa$gdZ]kd{4$$IflF*: t06    44 lapytZ][\^`THH $$Ifa$gdZ] $$Ifa$gdZ]kd-5$$IflF*: t06    44 lapytZ],>d`XLLLLLL $^a$gdg5$a$gdg5kd5$$IflF*: t06    44 lapytZ].Tlm67FPS $G]nx $^a$gd$x$^`a$gd$x $^a$gdg5FGN]dnux`ahp{Ch|#$ɳɳɳɳɳɳɳɳɳɳɳz *h nhg5 *hg5 *hLhg5h~hg55hphg5CJaJh}|%hg5OJQJ^Jhg5+h}|%hg5h$xOJQJ^JcHdhs;g%hg5h$xOJQJ^JcHdhs;g%Hhs;gheh$xOJQJ^JHhs;gh$xOJQJ^J.*a 1Chlnprtvxz|}Ffc7 $$Ifa$gdZ] & Fgdg5 & FgdZ]$a$gdg5 & FgdZ] $^a$gdg5}ckd9$$Ifl0$(@! t0644 lapytZ] $$Ifa$gdZ] $IfgdZ]34_`<xssssssssssk & Fgdg5gdg5kdY:$$Ifl0$(@! t0644 lapytZ] $,-0124@F #)FGIQx~ cdkmpqrt"#ɾݶض媲آآ *h"hg5 *hxOhg5hg5 *hchg5htFhg5B*ph htFhg5 *h F$hg5 *hg5 *hLhg5 hthg5hg5B*phhLhg5B*ph<#+014DGrsu}NOWX[\]<DEJK̸譛v+hUhg55OJQJaJmH nH sH tH hg55aJmH nH sH tH #hhg55aJmH nH sH tH hxOhg5CJaJhX! hg50Jj:hg5Ujhg5U hthg5 *hg5 *h"hg5hg5hg5B*phh"hg5B*ph+<Kcdlolcc $IfgdZ]kdn;$$Ifl0EHI t0644 lahpytZ] $$Ifa$gdZ]Kbcdklp{| $%()/045}~ɴɦɴɴڢ j hg5 j hg5 hg55hdhg55hg5hg5aJmH nH sH tH (hNrvhg5OJQJaJmH nH sH tH  hNrvhg5aJmH nH sH tH hNrvhg5aJh=g$hg55aJ#h[hg55aJmH nH sH tH 3opx{vmm $IfgdZ]kd <$$IflU0EHI t0644 lahpytZ]{|xoo $IfgdZ]kd<$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kdO=$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kd=$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kd>$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kd,?$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kd?$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kdj@$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kd A$$Ifl0EHI t0644 lahpytZ]xoo $IfgdZ]kdA$$Ifl0EHI t0644 lahpytZ] xoo $IfgdZ]kdGB$$Ifl0EHI t0644 lahpytZ] xoo $IfgdZ]kdB$$Ifl0EHI t0644 lahpytZ]%(xoo $IfgdZ]kdC$$Ifl0EHI t0644 lahpytZ]()* 1Xxsssjjjaaaa^gdg5^gdg5gdg5kd$D$$Ifl0EHI t0644 lahpytZ] />FGLkdE$$Ifl0EjI% t0644 lahpytZ] $$Ifa$gdZ] & Fgdg5gdg5 & FgdZ]^gdg5,-./0uv/78=>EFGNOWY~udOIu hg5aJ(hNrvhg5OJQJaJmH nH sH tH  hNrvhg5aJmH nH sH tH hNrvhg5aJh=g$hg55aJ+hUhg55OJQJaJmH nH sH tH hg55aJmH nH sH tH #hhg55aJmH nH sH tH hxOhg5CJaJh)hg50Jj@Ehg5UhVjDhg5Ujhg5Uhg5 hfChg5GOXYafkkd_F$$IflU0EjI% t0644 lahpytZ] $IfgdZ]Yaefgowxy $%&pؿ *hg5 *hrhg5 *h%hg5hg5(hNrvhg5OJQJaJmH nH sH tH hNrvhg5aJhg5aJmH nH sH tH  hNrvhg5aJmH nH sH tH Cfgoxvmm $IfgdZ]kdG$$Ifl0EjI% t0644 lahpytZ]xyvmm $IfgdZ]kdG$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kdOH$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kdH$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kdI$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kd;J$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kdJ$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kdK$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kd'L$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kdL$$Ifl0EjI% t0644 lahpytZ]vmm $IfgdZ]kdoM$$Ifl0EjI% t0644 lahpytZ] %vmm $IfgdZ]kdN$$Ifl0EjI% t0644 lahpytZ]%&'<p67GvqiaqqqYY$a$gdg5 & FgdZ] & FgdZ]gdg5kdN$$Ifl0EjI% t0644 lahpytZ] $()Z\`f 7Xf~FU`abr|}~󳫳hy}9hg55 hg55hu^hg55hg5CJaJhxOhg5CJaJ h{!ehg5hVj[Ohg5Ujhg5U *hg5 hd^hg5h%hg5B*phhg5 *h%hg5;GU~ $IfgdZ]FfQ $$Ifa$gdZ] & Fgdg5 & FgdZ]^UIIIIII $$Ifa$gdZ] $IfgdZ]kdS$$IflFd$< t06    44 lapytZ]\WWWgdg5kdW$$Ifl0$<, t0644 lapytZ] $IfgdZ]Ff~U $$Ifa$gdZ] O^_es~OQw}ef h 6hg5 *hg5 *hIhg5 hXhg5 h_hg5 hNhg5 hhg5hu^hg55hg5CJaJhxOhg5CJaJ hm<hg5 h]hg5hVjhg5Uj~Xhg5Uhg55esFfY $$Ifa$gdZ] $IfgdZ] & Fgdg5  & F|^|gdZ]gdg5 & FgdZ]yyyyyyyytFf^ $$Ifa$gdZ] $IfgdZ]qkd\$$IflL$% t0644 lap ytZ]   "$&(*+268:<FfBeFfa $$Ifa$gdZ] $IfgdZ]<>@BDFGNRTVXZ\^`bcjnprtvxz|Ffhl $IfgdZ]Ffh $$Ifa$gdZ]|~PQvw')+-/135 $IfgdZ] & Fgdg5  & F|^|gdZ]^gdg5 $^a$gdg5$a$gdg5gdg5Ffo $$Ifa$gdZ]fpqrstuw'(8FHWbcdefgi"#'- ǿᷲᤜ hThg5h( hg5B*ph *hg5 *h( hg5 hM#fhg5 hu?hg5 hg55hu^hg55hg5CJaJhxOhg5CJaJ hNhg5hXhg55hg5 hd^hg5hg5B*phh%hg5B*ph1578GHOXZ\^`bdftqkdv$$IflL$% t0644 lap ytZ] $IfgdZ]Ffs $$Ifa$gdZ] fhij  $IfgdZ]Ffi{ & Fgdg5  & F|^|gdZ]$a$gdg5Ffw $$Ifa$gdZ]MQWkox"{|rst᪢ᐈԈԈqfh)hg5B*ph,hg5B*CJ^JaJfHphq  *h)hg5 he0hg5h\7,hg5B*ph *h\7,hg5 *hrhg5 h#hg5hbhg55hg5B*phh( hg5B*ph *hg5 *h( hg5hg5hHhg55hbIhg55hMihg5CJaJ%+45<>@BDFHJLM+,1Ogdg5$a$gdg5  & F|^|gdZ]gdg5FfG $IfgdZ]Ff~ $$Ifa$gdZ]tu),/?MSX^ !-./_*+Z)*fg KQÿʟ hg5aJ h#hg5 h`7Ohg5h#hg5aJh( hg5B*ph *hhg5 *hg5 *h( hg5hg5 h)hg5hg5B*ph$jh)hg5B*Uphh)hg5B*phjh)hg5B*Uph312_,-Z*g UVl&kl $^a$gdg54 *gdg5$a$gdg5VZ[l& z<CDLMTU`hjlpq -.:@BCgmʾʩ hhg5 hgb.hg5 hThg5 h&-h{ hg55h\hg55hVj}hg5Ujhg5Uhg5B*phh( hg5B*phhg5Bl *PJ !pDw$a$gdg5 & FgdZ]gdg5  & F|^|gdZ]^gdg5 *3PQ+,34AN!KLAEʳ~v *hrhg5hC'hg5B*ph *hC'hg5hhg5B*phhg5B*ph *hhg5 hghg5,hg5B*CJ^JaJfHphq h~3\hg5B*phhghg5B*ph *hghg5 *hg5hOqhg55hg5 hhg5.E^_mnop frtuBCKNOQRTqrzz *hg5 hnV+hg5h"CBhg55 *hYhg59 *hhg50JNB*CJ ^JaJ fHphq hgLhg55 hKRhg5hRhg5B*ph *hrhg5h~3\hg5B*phhhg5B*phhg5B*phhg5 *hhg50TrO^HVA $$Ifa$gdZ] & Fgdg5  & F|^|gdZ] & FgdZ]gdg5$a$gdg5  !6>?EIKLMN^g67DEFV_/0<>?۶țțțțh hg5B*ph *h hg5hOYhg55h~3\hg5B*ph h1Uhg5hg5B*phh/hg5B*phhhg5B*phhg5 *hthg5 *hhg5 *hg5=?Abd  YyO#)*:GMh\hg55 h3hg5 hDEhg5h@hg5B*ph *hU#hg5 hrhg5hHhg55hbIhg55hrhg5CJaJhg5B*phh hg5B*ph *hg5 *h hg5hg59\kd$$Ifl0$!G! t0644 lapytZ] $IfgdZ]Ff% $$Ifa$gdZ] NOvnnnnnnnnnnn$a$gdg5kd%$$Ifl0$!G! t0644 lapytZ] yFf $$Ifa$gdZ] $IfgdZ] & Fgdg5  & F|^|gdZ] $^a$gdg5.:;<     (-.23DEM-.56PWm}:;~h^ghg5B*ph *h%fhg5 *hDdhg5 hmjhg5 hFhg5 h`Ihg5hFhg55CJhShg56hg5mHsHhhg5mHsH hu?hg5 hhg5hu^hg55hg5CJaJh >hg5CJaJhg5/ "$&'.yyyyyyyytFf֏ $$Ifa$gdZ] $IfgdZ]qkdR$$Ifl$h% t0644 lap ytZ] .=?ACEGIKMNUY[]_acegijquwy{FfFfd $$Ifa$gdZ] $IfgdZ]{}Ff $IfgdZ]Ff $$Ifa$gdZ]tqkd-$$Ifl$h% t0644 lap ytZ] $IfgdZ]Ff $$Ifa$gdZ]    Ff? $IfgdZ]Ff $$Ifa$gdZ] !(;M]kyyyyyyyy dh$IfgdZ] $IfgdZ]qkdЫ$$Ifl$h% t0644 lap ytZ]  $$Ifa$gdZ] $IfgdZ]FfX $$Ifa$gdZ]yyyyyyyytFfq $$Ifa$gdZ] $IfgdZ]qkd$$Ifl$h% t0644 lap ytZ]  "$&(*,-.6K]HI! $a$gdg5  & F|^|gdZ] & FgdZ]gdg5Ff $$Ifa$gdZ] $IfgdZ];EFGHIJ]a{|~ JQ^dmst~ C˿ҿҜ *hhg5h hg5B*ph *h hg5 *hz_+hg5 *hg5 h6Zhg5 h+hg5hg5hWOhg5B*phhz_+hg5B*phhg5B*phh,<hg5B*ph;CD]^_defpqrstuxy|78BCDEFGHIMSX]fg····‘ *hz_+hg5 hVu>hg5hg5 *hhg5 *hj"hg5 h0 hg5hWOhg5B*phhhg5B*phhg5B*phh,<hg5B*ph hVShg5 *hVj *h hg5U *hg5j *hg5U3         ' - C I Q W w x              > C Z [ e f g h i j l s y             " & ' ûଷûաûա hg55h\hg55hjmhg5B*phhWOhg5B*phhg5 *hz_+hg5 h0 hg5hWOhg5B*phhz_+hg5B*phhg5B*phh,<hg5B*ph h"0hg5 *hg5:! " 8     GQV_ $$Ifa$gdZ] & Fgdg5gdg5  & F|^|gdZ] $^a$gdg5^gdg5$a$gdg5' / 0 7 8        - A B C G Q W                    ҸȳȬ懀xjhg5U hhg5 h&xhg5hhg5B*phhg5B*phh,<hg5B*ph h"0hg5 *hVj  *h hg5Uj *hg5U *hg5 *hhg5 h: hg5hg5h1Dhg55 hg55h\hg55,bf   2ɿɯzsss hldhg5hjmhg5B*phhhg5B*phhg5B*phh,<hg5B*ph h>?hg5 *hVj *h hg5Uj *hg5U *hg5 *hhg5 h&xhg5 hhg5hg5hVjhg5Ujhg5U(&'-.1L  #$4589ELRbhڽͳګwskkkkk *hW4Shg5hVj hg5Ujhg5Uhjmhg5B*phhW4Shg5B*phh$hg5B*ph *hM `hg5 *hV *hg5j *hj|hg5Uj *hj|hg5U *hj|hg5 hGhg5hg5h~hg55h2whg5CJaJ*^kd$$Ifl0 $x  t0644 lapytZ] $IfgdZ]Ffd $$Ifa$gdZ]xoc $$Ifa$gdZ] $IfgdZ]kdZ$$Ifl0 $x  t0644 lapytZ]xskssZZI & F ^gdZ] & F ^gdZ] & FgdZ]gdg5kd$$Ifl0 $x  t0644 lapytZ]DEgh2Hq & Fgdg5 & FgdZ] & FgdZ]@^@gdg5$ & F ^a$gdZ]gdg5$a$gdg5"#<=MNUVWcdeh+<ghmuw| !-./01267Fþӹ蠘萋 hg55h\hg55 *hW4Shg5 hhhg5 h_hg5h9Lhg5B*ph *hV *hg5j *hrhg5Uj *hrhg5U *hrhg5hg5hW4Shg5B*phhg5B*ph6FGH46:@ *1KZbhij:?@EFHSTUhg5CJaJh2whg5CJaJhXhg50J hg50Jjhg5Ujhg5U h| @ B C Ff & Fgdg5 & FgdZ]gdg5Ff; $$Ifa$gdZ]C ] f j k r s u w UIII $$Ifa$gdZ]kd$$IflFK"$ t06    44 lapytZ] $IfgdZ]i j    !!"!#!$!*!,!.!/!1!N!O!^!_!`!!Q"R"`"a"c"|#}######>$?$K$L$M$N$&&ʼ㞌yrgyhiohg5B*ph hrhg5hjmhg5B*phhg5B*ph hIghg5htZhg5B*ph *h{>hg5 h5hg5hWhg5H* heIUhg5hg5B*CJ^JaJph0hg50JNB*CJ^JaJfHphq hhg5 hdhg5hg5heIUhg5^JaJ(w y { }           tqkd$$Ifl$h% t0644 lap ytZ] $IfgdZ]Ffg $$Ifa$gdZ]         O!`!L'M'a'''))))) & Fgdg5gdg5  & F|^|gdZ]Ff $$Ifa$gdZ]&&;'<'H'I'J'K'M'N'T'U'a'f'g'i''''''''''''''''((((((!(1(2(K(Q([(a(((((((( ) )ĽĽĶĶĶĶģččččččččč hohg5 hg50Jhg*Thg50Jjhg5Ujhg5U hIhg5 hdhg5hg5h`Nhg5B*phhg5B*phhtZhg5B*phhiohg5B*ph *hlhg5 hhg54 )z){)))))))))))))))****#*&*B*C*G*M************++%+-+9+:+;+>+P++++++++++, ,,,,,!,>,F,^,a,ʽծծէէէէէէէէէէէէէէէէէէէծ h\hg5 h!~hg5hu^hg55 hg55hg5CJaJh2whg5CJaJhg5hg5B*phhtZhg5B*phhiohg5B*ph *hiohg5B)))) *^UUU $IfgdZ]kd$$IflFd$ t06    44 lapytZ] * * *C**^UUU $IfgdZ]kdE$$IflFd$ t06    44 lapytZ]**** +^UUU $IfgdZ]kd$$IflFd$ t06    44 lapytZ] + ++:++^UUU $IfgdZ]kd$$IflFd$ t06    44 lapytZ]+++++^UUU $IfgdZ]kdj$$IflFd$ t06    44 lapytZ]+++,?,^UUU $IfgdZ]kd!$$IflFd$ t06    44 lapytZ]?,@,F,G,_,^UUU $IfgdZ]kd$$IflFd$ t06    44 lapytZ]_,`,a,K-S-v-- ..^YYQYIYQ & FgdZ] & FgdZ]gdg5kd$$IflFd$ t06    44 lapytZ]a,},,,,,,,,,,,,- -)-1-:-;-G-H-I-J-K-R- ..../.0.1.=.>.?.O.Z.[.k.....̧̧̟̔~skhg5CJaJhz%hhg5CJaJ hrhg5 hVaJhz%hhVaJjhg5Ujhg5U hkhg5h`Nhg5B*phhg5B*phhtZhg5B*phhg5 *hVhVjF *h4hg5Uj *hg5U *hg5 *htZhg5*.................. $IfgdZ]Ff $$Ifa$gdZ] & Fgdg5gdg5........///+/,/.///8/H/K/O/P/W/[/b///////M0P0R0W0u0v0000000000000001 1 1 1 11ỶỶ hghg5hghg5B*ph hHhg5h?Fhg5B*phhg5B*ph *hg5 *h?Fhg5 h# hg5h5hg55 hwXhg5hvPhg5\hg5hS'hg55hg5CJaJhz%hhg5CJaJ6../.% $IfgdZ]kd$$Iflr'#A'm t0644 lap2ytxS///// / /////)/ $IfgdZ]Ff $$Ifa$gdZ] )/*/+///H/O0P0 11h2i2vqeqqq]]]q$a$gdg5  & F|^|gdZ]gdg5kdw$$Ifl0#AG t0644 lapytxS 111 1"1(1O11111111W2X2^2e2f2g2i2m2n2~2222333 3 333?3A3z3333334/4e44444444444޼ް޷ްްްްްޠޕފ hR:hhg5hVjhg5Ujhg5Uhhg55 hwhg5 hg55h\hg55 hIhg5hg5B*phh?Fhg5B*phhg5 *h.>>>????? @h@s@@@AAeCwC4D  & F|^|gdZ] & FgdZ] $^a$gdg5gdg5$a$gdg5Q:R:S:V:W::::::::; ;!;';.;/;0;H;L;u;{;;;;;;;;;<<o<u<<<<<O=W=X=^=f=g=h=i=j=s=t=========>>Ĺ̮ן *hU6hg5 hH<hg5hrhg5B*phhrhg5B*phhg5B*phh.C hg5B*ph *hg5 *h.C hg5hg5hVjhg5Ujhg5U;>>">*>+>.>>>>>>>>?????? @A@g@h@n@o@r@@@@@.AEAFARASATAkAlAAʿݷݲݣݜݲݕݍ}}vnjhg5U hJhg5htZhg5B*ph *hg5 *htZhg5 hohg5 h#hg5 hkhg5hohg55 hg55hu (hg55hrhg5B*phh.C hg5B*ph *hhg5hg5hg5B*phh Bhg5B*phhU6hg5B*ph&AAAAAAAAAAAAAAAAAABB B.B4B5B_BBBBBBBBBBBBBBBBBBCCCC:C;C@CAC]C^C̹ױܱן̹ă hUhg5 *hVj *h4Ahg5Uj *hg5U *hrhg5 *h:Ahg5hrhg5B*phhg5B*phhtZhg5B*ph *hg5 *htZhg5hg5hVjhg5Ujhg5U3^CdCwC{CCCCCCCCCCCCCC D2DZD[D{D|D}DDDDDDDDEE3E4E5E=E>EIEJEeEfEhEpEqE|E}EEEEEE漤 hwBhg5hS'hg55hg5CJaJhwBhg5CJaJ hg50Jjhg5U hohg5h%hg50Jjhg5U hR:hhg5hVjhg5Ujhg5U h'hg5hg5 hUhg534DZDhEEEEEEEQHH $IfgdZ]kd $$Ifl02 t* t0644 lapytZ] $$Ifa$gdZ] & Fgdg5gdg5  & F|^|gdZ]EEEEvmm $IfgdZ]kd$$Ifl02 t* t0644 lapytZ]EEEFFFF!F#F%Fvqi`TTTTT $$Ifa$gdZ] $IfgdZ] & Fgdg5gdg5kdG$$Ifl02 t* t0644 lapytZ] EFFF-FGGGGHHHHHHHHHII4I5I6I>I?IbIcIIIIIIIIIIIII(K-K3KMKTKKKKKKL"L_LҵҰ饝鋃 *hclthg5 h#hg5h`Nhg5B*phhg5B*phhtZhg5B*ph *hg5j *h hg5Uj *h hg5U *h hg5 hNhg5hS'hg55hg5hwBhg5CJaJhg5CJaJ3%F'F)F+F-F.F9F:FAFPFRFTFVFXFvv $IfgdZ]nkdj$$Ifl$h% t0644 lap ytZ]Ff $$Ifa$gdZ] XFZF\F^F`FaFhFwFyF{F}FFFFFFFFFFFFFFFFFFfn $IfgdZ]Ff $$Ifa$gdZ]FFFFFFFFFFFFFFFFFFFFFFFFGFfFfv $$Ifa$gdZ] $IfgdZ]FfGG G%G'G)G+G-G/G1G3G5G6G=G{{{{{{{{vFf  $$Ifa$gdZ] $IfgdZ]nkd$$Ifl$h% t0644 lap ytZ] =GXGZG\G^G`GbGdGfGhGiGjGrGHHIIII & Fgdg5 & FgdZ]gdg5Ff  $$Ifa$gdZ] $IfgdZ]IIIIvmm $IfgdZ]kd$$Ifl0 N t0644 lapytZ]III Jvmm $IfgdZ]kd*$$Ifl0 N t0644 lapytZ] JJJ"Jvmm $IfgdZ]kd$$Ifl0 N t0644 lapytZ]"J#J$J,JJJ'K(KMMMMNvqiqqqqqqqqq & FgdZ]gdg5kdh$$Ifl0 N t0644 lapytZ] _L`LnLLLMMMMFMUMmMMMMMMMMMMMMMN$NwNxN|NNNNNNNNNNNNOO3O:OGO[OOOOĿĿĿĿĿĿzh/hg55 hg55h'hg55hg5CJaJhwBhg5CJaJ hq:hg5h`Nhg5B*phhrhg5B*ph *hg5 *hclthg5hVjhg5Ujhg5U hhg5 h#hg5hhg5B*phhg50NNOOGOKOMOOOQOSOUOWOYO[O\OcOOO $IfgdZ]Fft $$Ifa$gdZ] & Fgdg5 & FgdZ]gdg5 & FgdZ]OOOOOOOOO_VJJJJJJ $$Ifa$gdZ] $IfgdZ]kd$$IflFE $ t0    44 lapytZ]OOOOOOOOOOO]kd$$Ifl0E$ t044 lapytZ] $IfgdZ]Ffv $$Ifa$gdZ] OOOOOOOOO:PJPPPPPPPPPPPPPP $IfgdZ]Ff & Fgdg5 & FgdZ]gdg5Ff` $$Ifa$gdZ]OPP\PbPoPrPPPPPPPPPPPJQKQSQUQvQwQQQQQQQQQRR&R,RCRYRZRfRgRhRwRRRSSSSSSSSSSSSSSSS T˼ hOPhg5h/hg55 hg55h=hg5CJaJ h.hg5hVj<"hg5Ujhg5U hhg5h'hg55hg5CJaJhwBhg5CJaJ h/hg5hg5;PQQ QQlc $IfgdZ]kd!$$Ifl0 $2 6 t0644 lapytZ] $$Ifa$gdZ]Q Q!Q)QKQSQQQMRZRRxskskscsk[ & Fgdg5 & FgdZ] & FgdZ]gdg5kd!$$Ifl0 $2 6 t0644 lapytZ] RRRRRRRRRRRRRR $IfgdZ]Ff# $$Ifa$gdZ] RRRRRRRRR_VJJJJJJ $$Ifa$gdZ] $IfgdZ]kd[&$$IflFN$  t0    44 lapytZ]RRRRRRRRRRR]kd*$$Ifl0$ \ t044 lapytZ] $IfgdZ]FfE( $$Ifa$gdZ] RRSSSSSSSvSSSTT T"T$T&T(T*T,T.T/TFf/ & Fgdg5 & FgdZ]`gdg5gdg5Ff, $$Ifa$gdZ] TTT.TTTTTTTTTTTTU(U.UKUcUUUUUUUUUUUUDVEViVVWW#W$W&W6W=WWο䱸䦞𖑖tlh/hg55h`Nhg5B*phhmhg5B*ph hmhg5 *hg5 *hmhg5hg5CJaJh5hg5CJaJ hd hg5 hOPhg5hVj_3hg5Ujhg5U hhg5 h/hg5hg5h'hg55 hg55h=hg5CJaJ*/T6TLTMTTTjTckd+2$$Ifl0 $2 6 t0644 lapytZ] $$Ifa$gdZ] $IfgdZ]jTkTlTtTTTTUUUUxskskscsk[ & Fgdg5 & FgdZ] & FgdZ]gdg5kd2$$Ifl0 $2 6 t0644 lapytZ] UUUUUUUUUUUUUV$IfgdZ]oTFf4 $$Ifa$gdZ] VVVVV V VVV_VJJJJJJ $$Ifa$gdZ] $IfgdZ]kd.7$$IflFD%; t0%    44 lapytZ]VVVVV1V2V3V5V7V9V]kd&;$$Ifl0D%; t0%44 lapytZ] $IfgdZ]Ff8 $$Ifa$gdZ] 9V;V=V?VAVCVDVEV%W&W=WWWX:X>X@XBXDXFXHXJXLXNX & Fgdg5 & FgdZ] ^`gdg5gdg5Ff< $$Ifa$gdZ]WWWWW XXXXX+X:XNXXXXXXXXXXYYEYIYMYNYTYoYpYqYYYYYYYYYYYZwZZZZ[-[5[:[;[<[C[^[_[k[ĵh Dhg5CJaJ h+hg5h/hg55 hg55 hd hg5hVjChg5Ujhg5U hhg5 h/hg5h'hg55hg5CJaJh'hg5CJaJhg5 hOPhg58NXOXVXlXmXtXX^kdXB$$Ifl0 $2 6 t0644 lapytZ] $$Ifa$gdZ] $IfgdZ]Ff?XXXXXXYAYBYYYxskskscssk & FgdZ] & FgdZ]gdg5kdB$$Ifl0 $2 6 t0644 lapytZ] YYYYYYYZZZZZZ+Z4Z $IfgdZ]FfD $$Ifa$gdZ] & Fgdg54Z5Z6Z8Z:ZZ@ZBZ_VJJJJJJ $$Ifa$gdZ] $IfgdZ]kdIG$$IflF4$ t0    44 lapytZ]BZDZFZGZNZcZdZeZgZiZkZ]kd/K$$Ifl04$ t044 lapytZ] $IfgdZ]FfH $$Ifa$gdZ] kZmZoZqZsZuZvZwZZZZ_[[[[[[[[[[[[[ $IfgdZ]FfO & Fgdg5 & FgdZ]gdg5FfL $$Ifa$gdZ]k[l[m[}[[[\ \\\4\5\N\O\P\U\V\|\\\\\\\\\\\]]]]]]]]]]]]^^^B^C^Q^]^^^_^q^}^^^^^_0___˼ᢝ *hg5 *hkkhg5h}]Whg5CJaJ hszhg5hVjShg5Ujhg5U hhg5 h/hg5hg5h'hg55h Dhg5CJaJhg5CJaJ:[[[[[lc $IfgdZ]kdUR$$Ifl0 $2 6 t0644 lapytZ] $$Ifa$gdZ][[[[ \\X\x\D^Q^}^xskskscsk[ & Fgdg5 & FgdZ] & FgdZ]gdg5kdR$$Ifl0 $2 6 t0644 lapytZ] }^^^^^^^^^^^^^^ $IfgdZ]FfMU $$Ifa$gdZ] ^^^^^^^^^^UIIIIII $$Ifa$gdZ] $IfgdZ]kdW$$IflFf$< t06    44 lapytZ]^^^^^^^^___\WWWWgdg5kd[$$Ifl0$<, t0644 lapytZ] $IfgdZ]FfY $$Ifa$gdZ] _______ ``5````````````a a!a,a-ahaaaaaa\bwb}bbbbbbbbbbbAcɺɟ唌}}}}}}u *hrhg5 hRhg5h'hg55hg5CJaJh Dhg5CJaJhy=zhg50Jj]hg5U huhg5hVj\hg5Ujhg5U hu'khg5h/hg55 hg55hg5h`Nhg5B*phhkkhg5B*ph-_7`G```haaaaaaaaaaaaaaFf^ $$Ifa$gdZ] $IfgdZ] & Fgdg5^gdg5  & F|^|gdZ]gdg5 & FgdZ]^gdg5aaabbbbbbbbb b'b{{{{{{{{vFfb $$Ifa$gdZ] $IfgdZ]nkda$$Ifl$h% t0644 lap ytZ] 'bBbDbFbHbJbLbNbPbRbSbTb\bMeNeCfDfffgggg!g#g & Fgdg5 & FgdZ]gdg5Fff $$Ifa$gdZ] $IfgdZ]AcBc[c\clcmcrcsctcccccddd d dddddddeeKeLeMeNeReSeeeeeeeʿʸ}vogggg *hlhg5 hRhg5 hszhg5hg5B*phh hg5B*ph *h hg5h;hg50Jj%ihg5Uhg5jhg5U h;hg5hhg5B*ph hhg5 *hV *hg5jh *hrhg5U *hrhg5j *hrhg5U%eeeeeeefffffffffffffffgg+g,g4hhhhhhhhhiiḰᗏyyn^jhjhg5B*Uphh`Nhg5B*phhchg5B*phh1vhg5B*ph *hchg5 *h2%hg5h6Lhg5aJh'hg55hg5CJaJhiJhg5CJaJ hRhg5hVjihg5Ujhg5Uhg5 h5;hg5hg5B*phhlhg5B*ph$#g%g'g)g+g,g9g:gAgLgtqkdm$$Ifl$h% t0644 lap ytZ] $IfgdZ]FfPk $$Ifa$gdZ] LgMgTg_gvma $$Ifa$gdZ] $IfgdZ]kd8n$$Ifl0$s t0644 lapytZ]_g`gkgxgvma $$Ifa$gdZ] $IfgdZ]kdn$$Ifl0$s t0644 lapytZ]xgyggvm $IfgdZ]kdvo$$Ifl0$s t0644 lapytZ]gggggyy $$Ifa$gdZ] $IfgdZ]qkdp$$Ifl$h% t0644 lap ytZ]ggggggggg^UIIIIII $$Ifa$gdZ] $IfgdZ]kdp$$IflF$sx} t06    44 lapytZ]ggggghiiij$j*j $IfgdZ] & Fgdg57^7gdg5  & F|^|gdZ]gdg5Ff~r $$Ifa$gdZ] i&i'i(i_i`iaijiiiiiiiiiiiiiiijejsjtjzjjjjjlllllmm)mѽȜ|x||xpxhchchch *hg5 *h:hg5h'hg55hg5hg5CJaJhrhg5CJaJhjhg55B*ph hg50J$j^uhjhg5B*Uphhg5B*phhrhg5B*phhjhg50Jjhjhg5B*Uph$jthjhg5B*Uphhjhg5B*ph&*j+j9j>jxoo $IfgdZ]kdu$$Ifl0 * t0644 lapytZ]>j?jJjPjxoo $IfgdZ]kdsv$$Ifl0 * t0644 lapytZ]PjQj_jdjxoo $IfgdZ]kd w$$Ifl0 * t0644 lapytZ]djejjjjjjjjjjjxpddddddddd $$Ifa$gdZ] & Fgdg5kdw$$Ifl0 * t0644 lapytZ] jjjjjjjjjjjjjjvnkd{$$Ifl$h% t0644 lap ytZ] $IfgdZ]Ff9y $$Ifa$gdZ] jjjjkk k kkkkkkkk)k+k-k/k1k3k5k7k9k:kAkFfGFfÀ $IfgdZ]Ff?} $$Ifa$gdZ]AkLkNkPkRkTkVkXkZk\k]kdkokqkskukwkyk{k}kkkkFfO $IfgdZ]Ffˇ $$Ifa$gdZ]kkkkkkkkkkkkkk{{{{{{{{{vFfU $$Ifa$gdZ] $IfgdZ]nkdۍ$$Ifl$h% t0644 lap ytZ] kkkkkkkkkkkkkk{{{{{{{{{vFf[ $$Ifa$gdZ] $IfgdZ]nkd$$Ifl$h% t0644 lap ytZ] klll l l llllll&l(l*l,l.l0l2l4l6l7l?lJlLlNlPlFfc $IfgdZ]Ffߖ $$Ifa$gdZ]PlRlTlVlXlZl[lclnlplrltlvlxlzl|l~lllFfk $IfgdZ]Ff $$Ifa$gdZ]llllllllllllll{{{{{{{{{vqgdg5Ffq $$Ifa$gdZ] $IfgdZ]nkd$$Ifl$h% t0644 lap ytZ] llmm1n2npp-q.q,r-ruuwxxxhzzzz{{{ & Fgdg5 & FgdZ]^gdg5gdg5 & FgdZ])m*m8m:mmmmmmm2nnnoooopppppppppppppppppppppppq!q,q.q3q9qmqnqsqtqrr(r)r*r²Ÿ²hg5B*ph hn9hg5 hG/hg5$jhrhg5B*Uphjhrhg5B*Uphhrhg5B*ph *hg5 *h[hg5 h3hg5 *hhhg5 *h:hg5h:hg5B*phhg56*r,r-rssssssssssssssAuBuCuDuuuuuuuuuuuuuuuǼwd\W\ hg55hbUhg55$jh+uhg5B*Uph *h+uhg5 h+uhg5hS/hg5B*phhg5B*ph$jҨh+uhg5B*Uphjh+uhg5B*Uphh+uhg5B*ph'hg5B*^JaJmH nH phsH tH  *h@^hg50hg50JNB*CJ^JaJfHphq hg5"uuwwxxxx{{{{{{{=|M|T|j||||||||}}}>}?}@}N}O}d}e}l}w}}}}}}ļļĴ毧晑憑}w}lh Dhg5CJaJ hg50Jhlhg50Jjhg5Ujhg5U hIhg5 haOhg5h/hg55 hg55h'hg55hg5CJaJhhhg5CJaJhWhg55hIl|hg55 hrhg5hg5 hbUhg5hg5B*CJ^JaJph*{{{{{{{{{{{{|| $IfgdZ]Ff $$Ifa$gdZ] |||||||||_VJJJJJJ $$Ifa$gdZ] $IfgdZ]kd$$IflFN$  t0    44 lapytZ]| |"|#|*|;|<|=|T||]XXO^gdg5gdg5kdf$$Ifl0$ \ t044 lapytZ] $IfgdZ]Ff $$Ifa$gdZ] ||}}}}}}}}}}}}}} $IfgdZ]Ffo $$Ifa$gdZ] & Fgdg5gdg5 & FgdZ]}}}}}}}}~~~~~#&'GHIef.JKjkֶ֣֮폄xxxxpx *hahg5 h('hg5 hg55hZshg5CJaJhiJhg5CJaJhlhg50Jjhg5Ujhg5Uh7vhg5B*ph *hg5 *h7vhg5h'hg55hg5hbIhg55hhhg5CJaJhg5CJaJh Dhg5CJaJ,}}~~xoc $$Ifa$gdZ] $IfgdZ]kd˶$$Ifl0 $2 6 t0644 lapytZ]~~ ~%&xpkkkcWWWW $$Ifa$gdZ] & Fgdg5gdg5 & FgdZ]kde$$Ifl0 $2 6 t0644 lapytZ] \kd $$Ifl0$s t0644 lapytZ] $IfgdZ]Ff $$Ifa$gdZ]   . )9RT $IfgdZ] & F^`gdg57^7gdg5  & F|^|gdZ] gdg5gdg5FfԽ $$Ifa$gdZ]   )*JKLÁ  9NOQUjkmrz¯ͦ͞€ͦz“rg````` h('hg5hZshg5CJaJhg5CJaJ hg50J$jhjhg5B*Uphhrhg5B*phhg5B*phhjhg50J$j5hjhg5B*Uphhjhg5B*phjhjhg5B*Uphhg5hS/hg5B*phhg5B*phh7vhg5B*ph%TUoqvma $$Ifa$gdZ] $IfgdZ]kd/$$Ifl0@   t0644 lapytZ]qr{vma $$Ifa$gdZ] $IfgdZ]kd$$Ifl0@   t0644 lapytZ]łǂɂ˂͂ςтvneYYYYYYY $$Ifa$gdZ] $IfgdZ] & Fgdg5kdm$$Ifl0@   t0644 lapytZ] Ղ݂#$&?FՃ%KTȄ UVefhxͅ3鵰饞陑jhg5U haOhg5h/hg55 hg55 h&hg5h7vhg5B*ph *hg5 *h7vhg5hhg5CJaJh!chhg5CJaJ hhg5 h('hg5h'hg55hg5hrhg5CJaJhg5CJaJ1тӂՂւ݂')+-/13578FfOFf $IfgdZ]Ff $$Ifa$gdZ]8?GIKMOQSUWXYփ! & Fgdg5 & FgdZ] & FgdZ]gdg5Ff $$Ifa$gdZ] $IfgdZ]!#%&-KTUEkd$$IflF$X> t0    44 lapytZ] $IfgdZ]Ff $$Ifa$gdZ]UVXZ\^`bdfgnFf $$Ifa$gdZ] $IfgdZ] ghυ߅pwjeeee]eU & Fgdg5 & FgdZ]gdg5 ^`gdg5kd$$Ifl0$X t044 lapytZ] 345:;Enp|}~")*78<DE\joqЇч 䳫ynhlhg5B*phhSAhg5B*ph *hV *hg5j *hrhg5Uj *hrhg5U *hrhg5 he5hg5h'hg55hbIhg55hg5CJaJh!chhg5CJaJ huhg5hg5hVjhg5Ujhg5U(ӆ $IfgdZ]Ff  $$Ifa$gdZ] ӆԆۆxoc $$Ifa$gdZ] $IfgdZ]kdg$$Ifl0 $2 6 t0644 lapytZ])9)xsksss_V7^7gdg5  & F|^|gdZ] & FgdZ]gdg5kd$$Ifl0 $2 6 t0644 lapytZ] $%&'()9=hinowxy{ˆÈĈш҈9:Z[\̽thrhg5B*phhhhg5B*phh*3hg50J$jh*3hg5B*Uphjhg5B*Uphhg55B*phhVjhg5Ujhg5U *hg5 *hlhg5hg5 h5;hg5hlhg5B*phhg5B*ph*Չ։׉&')1RzЊdtuь )/Tk׻쭢~~~~~~~sssh7vhg5B*ph *hg5 *h7vhg5h'hg55hrhg5CJaJhg5hZshg5CJaJhg5CJaJ hg50Jh*3hg50J$jh*3hg5B*Uphjhg5B*Uphhg5B*phhrhg5B*phhg5B*ph*)R_efsyQkd$$Ifl0Ft t0644 lapytZ] $$Ifa$gdZ] $IfgdZ] & F^`gdg5yzÊŊNJɊˊ͊vnbbbbbbbbb $$Ifa$gdZ] & Fgdg5kd<$$Ifl0Ft t0644 lapytZ] ͊ϊЊ݊ފvnkd_$$Ifl$h% t0644 lap ytZ] $IfgdZ]Ff $$Ifa$gdZ]  !#%')+,3>@BDFHJLNOVFfFf] $IfgdZ]Ff $$Ifa$gdZ]VacegikmoqryFf $IfgdZ]Ffe $$Ifa$gdZ]ËŋNjɋʋы{{{{{{{{{vFf $$Ifa$gdZ] $IfgdZ]nkdu$$Ifl$h% t0644 lap ytZ] ы   &(*,Ff $IfgdZ]Ffs $$Ifa$gdZ],.02467?JLNPRTVXZ[dٍ* & FgdZ]gdg5 & FgdZ]Ff $IfgdZ]Ff{ $$Ifa$gdZ]ٍ܍$%&'(*- 158ŏя  &]^cd 2?EU[ci}h!chhg5CJaJ hShg5 hhg5hg5B*phh7vhg5B*ph *h7vhg5 *hg5hg5 hV@3hg5G 12ϑӑՑבّۑݑߑ  $IfgdZ]Ff  $$Ifa$gdZ] & Fgdg5 & FgdZ] & FgdZ]gdg5ÑϑTdkԒ  =>JKL]lopڕĖŖ9:?@O#$=Ჽ៚hXhg5B*ph *hg5 *hXhg5 huhg5hVjhg5Ujhg5UhbIhg55 h1hg5h/hg55 hg55hg5h'hg55h!chhg5CJaJhg5CJaJ6 _VJJJJJJ $$Ifa$gdZ] $IfgdZ]kd $$IflFE$0 t0    44 lapytZ] "$%,ABCEGI]kd$$Ifl0E$ t044 lapytZ] $IfgdZ]Ff $$Ifa$gdZ] IKMOQSTkĒԒ>lprtvxz|~ $IfgdZ]Ff & Fgdg5 & FgdZ]`gdg5gdg5Ff $$Ifa$gdZ]lc $IfgdZ]kdc$$Ifl0 $2 6 t0644 lapytZ] $$Ifa$gdZ]ƓNԔZxsksscs[[[ & FgdZ] & FgdZ] & FgdZ]gdg5kd$$Ifl0 $2 6 t0644 lapytZ] Z[͕ڕ   >G $IfgdZ]Ff? $$Ifa$gdZ] & Fgdg5 & FgdZ]gdg5GHIKMOQSU^UIIIIII $$Ifa$gdZ] $IfgdZ]kd$$IflFE$ t06    44 lapytZ]UWYZavwxz|~\kd!$$Ifl0E$ t0644 lapytZ] $IfgdZ]Ff $$Ifa$gdZ] ~Ŗ͖Qj[h & Fgdg5 & FgdZ] & FgdZ]gdg5Ff# $$Ifa$gdZ]=>?GHhtuvTUAMNObnBH]^m 34CE23Lѷѷ䯪䯪䯪䗊j *hrhg5U *hrhg5hhg5B*ph *hg5 *hhg5hhg5CJaJ he%Xhg5h'hg55hg5CJaJh!chhg5CJaJhg5hVjhg5Uj&hg5U2֘͘ $IfgdZ]Ff{' $$Ifa$gdZ]֘טؘژܘޘ_VJJJJJJ $$Ifa$gdZ] $IfgdZ]kd)$$IflFE $ t0    44 lapytZ]   ]kd-$$Ifl0E$ t044 lapytZ] $IfgdZ]Ff}+ $$Ifa$gdZ] )U]4Anrtvxz|~ & Fgdg5 & FgdZ] & FgdZ]gdg5Ffg/ $$Ifa$gdZ]Ekd=5$$IflFE$ t0    44 lapytZ] $$Ifa$gdZ] $IfgdZ]Ff2ÚĚ˚ $IfgdZ]Ff 7 $$Ifa$gdZ] wnbbbbbbbb $$Ifa$gdZ] $IfgdZ]kdi9$$Ifl0E$ t044 lapytZ] oۛExÝ؝(^gdg5 & FgdZ] & FgdZ] & FgdZ] & FgdZ] & FgdZ]gdg5Ff;LM]^efgtuv؝Z)?âĢ٢ڢɣջճը¨¨ՂՂ}ug`` hahg5hg5B*CJ^JaJphhahg55 hg55hQhg55 *hQhg5 *hJhg5 hQhg5 h+ hg5hEhhg5B*ph *hQhg5 h-B hg5hg5B*phhhg5B*phhg5 *hVj *hrhg5U *hg5j}= *hrhg5U%()?âĢڢ֤op ^gd Cf & F^gdZ] & F ^gdZ] & FgdZ] & FgdZ]^gdg5gdg5ɣʣ;@֤op #$%ўyeyVyhrr*hg50JB*\ph'j=hrr*hg5B*U\ph(jhrr*hg50J-5B*U\phhrr*hg50J-5B*\phhhg55 h}hg5 hrhg5hrhg55 hE5hg5 hj6hg5 hrhg5hWhg55 hg55,hg5B*CJ^JaJfHphq hahg5hg5%&'JKZ[kloة٩کabcʿʿyqjf[j?hg5Uh Cf h&-h Cfhh Cf5hWh Cf5jI?hg5UhJhg50Jj>hg5Ujhg5Uhg5$ji>hrr*hg5B*Uphhrr*hg5B*phjhrr*hg5B*Uphhrr*hg5B*^Jphh;!hg5B*^Jphffhrr*hg50J-5\"bcSYvUV2r $$Ifa$gdZ]$ $Ifa$gdZ]  & F^gdg5<^<gdg5 & F"gdZ] & FgdZ] & FgdZ]gdg5^gd&-DFRܫYuUV_`tuvw2=?BDZqrưǰѰҰݰ   ǿҸ hP)Khg5h'hg55 hg55hg5CJaJhRhg5CJaJ hymhg5hg5B*phhEhhg5B*ph *hc$hg5 *hg5 h9;+hg5 h0+'hg5hg5jhg5U h`Qhg57^RIRI $IfgdZ] $$Ifa$gdZ]kd@$$IflFd$   t0,"6    44 lapytZ]ưǰ^RRR $$Ifa$gdZ]kdOA$$IflFd$   t0,"6    44 lapytZ]ǰȰɰʰ ^RRR $$Ifa$gdZ]kd B$$IflFd$   t0,"6    44 lapytZ]  )NOz^VNA<gdg5 x7$8$H$gdg5$a$gdg5 & FgdZ]kdB$$IflFd$   t0,"6    44 lapytZ] ()"LNOYZmpڲ()*BKLZ[˳̳ͳгѳꯧ{ *hVjD *hmGhg5Uj *hg5U *hrr*hg5 *hg5 *h:hg59hg55B*CJOJ QJ \^J aJmH nH phsH tH  huhg5hVjChg5Ujhg5Uhg5 hg50J!6hGhg50J!6.zڲ*rs4ϵ $$Ifa$gdZ]  & F^gdg5 & F#gdZ]gdg5$a$gdg5<^<gdg5 & F"gdZ]   qrs´ôȴɴʴԴ%(89OVefklmǵϵ $%<=BNhжh'hg55 hg55hRhg5CJaJhg5CJaJhEhhg5B*ph h?Bhg5 *h:hg5 *hg5hg5hg5B*phhrhg5B*phBVWcdefɷʷڷ۷ܷݷ޷߷|¸ĸ 57z *hg5 *h:hg5 *h]/hg5 hgbhg5 huhg5hVjHhg5Ujhg5U ht$hg5 h2 hg5 hg5H* ht(hg5h{?hg5H* hP)Khg5 hg5hkAhg5 hg55h'hg554$%&^UIU $$Ifa$gdZ] $IfgdZ]kd}D$$IflFd$   t0,"6    44 lapytZ]&'Wcd^UIU $$Ifa$gdZ] $IfgdZ]kd9E$$IflFd$   t0,"6    44 lapytZ]defg^UUU $IfgdZ]kdE$$IflFd$   t0,"6    44 lapytZ]ʷ^UII $$Ifa$gdZ] $IfgdZ]kdF$$IflFd$   t0,"6    44 lapytZ]ʷ˷۷ܷݷ^UII $$Ifa$gdZ] $IfgdZ]kdmG$$IflFd$   t0,"6    44 lapytZ]ݷ޷߷øĸ^YPYHYYY & FgdZ]^gdg5gdg5kd)H$$IflFd$   t0,"6    44 lapytZ]ɺ#sHl˽/0þľ $$Ifa$gdZ]  & F^gdg5 & F%gdZ] x7$8$H$gdg5$a$gdg5 & F$gdZ]gdg5ߺ!"N_qrGм !jku{ǽȽɽʽ./0=SWhi¾ h?Bhg5 hvhg5hg5 h2hg5hg5B*phhhg5B*ph *hVjbI *hmGhg5Uj *hg5U *hrr*hg5 *h]/hg5 *hg5<¾þľξо !"#V\^p}  ar䩡h'hg55 hg55hRhg5CJaJhg5CJaJhg5 h2hg5hg5B*phhhg5B*ph9hg55B*CJOJ QJ \^J aJmH nH phsH tH  *h]/hg5 *h:hg5 *hg5 hGUhg56 RIII $IfgdZ]kdI$$IflFd$   t0,"6    44 lapytZ] $$Ifa$gdZ]  HIJKYZgtnopq5678CDFNZ[^_ƼƢ hg5h hg5H* ht$hg5 hg5h hohg5hrhg5hMh{?hg5H* hP)Khg5 hjo=hg5h'hg5hM5 hg5hG;Zhg5 hg55h'hg55=IJK^UUU $IfgdZ]kdJ$$IflFd$   t0,"6    44 lapytZ]KLMYZ^UIU $$Ifa$gdZ] $IfgdZ]kdWK$$IflFd$   t0,"6    44 lapytZ]Z[\]^UUU $IfgdZ]kdL$$IflFd$   t0,"6    44 lapytZ]^UIU $$Ifa$gdZ] $IfgdZ]kdL$$IflFd$   t0,"6    44 lapytZ]^UIU $$Ifa$gdZ] $IfgdZ]kdM$$IflFd$   t0,"6    44 lapytZ]QRS^UIU $$Ifa$gdZ] $IfgdZ]kdGN$$IflFd$   t0,"6    44 lapytZ]STopq^UIU $$Ifa$gdZ] $IfgdZ]kdO$$IflFd$   t0,"6    44 lapytZ]qrs^UIU $$Ifa$gdZ] $IfgdZ]kdO$$IflFd$   t0,"6    44 lapytZ]^UIU $$Ifa$gdZ] $IfgdZ]kd{P$$IflFd$   t0,"6    44 lapytZ]6^UIU $$Ifa$gdZ] $IfgdZ]kd7Q$$IflFd$   t0,"6    44 lapytZ]678DE^UIU $$Ifa$gdZ] $IfgdZ]kdQ$$IflFd$   t0,"6    44 lapytZ]EF[\]^UIU $$Ifa$gdZ] $IfgdZ]kdR$$IflFd$   t0,"6    44 lapytZ]]^_O7^UULUD?gdg5 & FgdZ]@^@gdg5^gdg5kdkS$$IflFd$   t0,"6    44 lapytZ]_`aDLNOPmnoyz0 -3@FKQV  678;=M!2~y~ hg55h<hg55hg5B*phhrr*hg5B*phh9mhg5B*ph h#hg5 *h(+hg5 *hg5 *h9mhg5 ht$hg5 hZ0+hg5 hg50Jj'Thg5Ujhg5U h2 hg5hg5 hg5H*h{?hg5H*,7"21[l   4$% *:L & FgdZ]^gdg5 & FgdZ]gdg5 & FgdZ]@^@gdg52   !-./01LRtu :gJKWXYZlnt wx {|źՌՌՌ *h9mhg5 *h6hg5 h&*hg5hg5hrr*hg5B*phhg5B*phh9mhg5B*phhuHhg5B*ph *hV *hg5jT *hrhg5Uj *hrhg5U *hrhg57      !#3jk:|}LstyzOPUV踳 h@hg5 hBhg5 h5hg5 hg55h<hg55hhg5B*ph *hhg5 *hF<hg5 *hg5 *h9mhg5hg5h9mhg5B*phhg5B*ph>!"8*{'~ & FgdZ] & FgdZ]^gdg5gdg5  & F|^|gdZ]Y  "8)%&4cdijݳݎݎhg5B*ph *hrhg5 hCZhg5 hs7hg5 h?[hg5 hhg5 h6,hg5h hg5OJ PJ QJ hrhg5hWhg55hhg5B*ph *hg5 *hhg5 h@hg5hg58ef|;<Rrj & F gdZ] & F gdZ] & FgdZ] & FgdZ] & FgdZ]^gdg5gdg5df{<Qij )*/0dfklmnңn8jhF hg50J-5B*OJPJQJU\^Jph/hF hg50J-5B*OJPJQJ\^Jph hshg50J-OJPJQJ^J hwphg5 hW&hg5hhg5B*ph *hg5 *hhg5 hCZhg5hWhg55hg5 hrhg5hhg5B*ph*FH89O  #[p\e & FgdZ] & FgdZ] & F!gdZ]^gdg5gdg5 & F gdZ] %&?@AFGìÔ~vqvqvqv~~jb~WbSb~hVjUhg5Ujhg5U h3hg5 *hg5 *hhg5hg5hhg5B*ph hXjhg5/hF hg50J-5B*OJPJQJ\^Jph,hF hg50JB*OJPJQJ\^Jph8jhF hg50J-5B*OJPJQJU\^Jph>j!UhF hg50J-5B*OJPJQJU\^Jph789<=O  #3LMUV^_e橡ڔڜڍچogbgbgbgbgWh1hg5B*ph *hg5 *hQhg5,hg5B*CJ ^JaJ fHphq h hg5 h.Chg5hWhg55 hg55hwUhg55,hg5B*CJ^JaJfHphq hwUhg5hg5B*phhhg5B*phhg5 *hrhg52hwUhg5B*CJ^JaJfHphq "efghmn"(,2@AJK *1JTZ[\qr»ᴭjVhF hg5U\hF hg5\jhF hg5U\hhhg55 hhhg5 h-+hg5 h\hg5 h<uhg5hw"hg5B*ph *h1hg5 *hg5hg5 h@ hg5h1hg5B*phhg5B*ph2erdeQqoOP>?w> & FgdZ]^gdg5 & FgdZ]gdg5 & FgdZ]'(BCabc012;<=  ̾́̕yi̾Q.jlWh}9hg55OJPJQJU^JjVhF hg5U\hF hg5\&hF hg50J-5OJPJQJ\^J hF hg50JOJPJQJ^J.jVhF hg55OJPJQJU^Jhg50J-OJPJQJ^J#jhg50J-OJPJQJU^Jhg5 hhhg5hF hg50J\jhF hg5U\LMghistw&'(ABCKLVWopqº ϙρs[sC.jXh}9hg55OJPJQJU^J.jNXh}9hg55OJPJQJU^Jhg50J-OJPJQJ^J/h}9hg50J-5B*OJPJQJ\^Jph hp^hg5hF hg50J\jWhF hg5U\hF hg5\jhF hg5U\hg5#jhg50J-OJPJQJU^Jh}9hg50J\ h}9hg50JOJPJQJ^Jqyz#˳ٛ~b~K~9#h_hg50J-5OJPJQJ^J,h%\Chg50JB*OJPJQJ\^Jph7jYh%\Chg5B*OJPJQJU\^Jph8jh%\Chg50J-5B*OJPJQJU\^Jph/h%\Chg50J-5B*OJPJQJ\^Jph.j.Yh}9hg55OJPJQJU^Jhg50J-OJPJQJ^Jhg5#jhg50J-OJPJQJU^J h}9hg50JOJPJQJ^J#$%>?@HIJ}   !ǯ՞ǚ{j՚cK՞՚.j[h}9hg55OJPJQJU^J hp^hg5 h%\Chg50JOJPJQJ^J.j}Zh%\Chg55OJPJQJU^J h.hg5hg5 h}9hg50JOJPJQJ^J.j Zh}9hg55OJPJQJU^Jhg50J-OJPJQJ^J#jhg50J-OJPJQJU^J/h}9hg50J-5B*OJPJQJ\^Jph!"#()IJdefpqr  0ֳ֊||ֳdSֳ hYQhg50JOJPJQJ^J.j[\hYQhg55OJPJQJU^J h+<hg5 hp^hg5 h*Bhg50J-OJPJQJ^J.j[h}9hg55OJPJQJU^Jhg50J-OJPJQJ^Jhg5 h}9hg50JOJPJQJ^J#jhg50J-OJPJQJU^J.j[h}9hg55OJPJQJU^J>?}~34T{[UV & FgdZ] & FgdZ]gdg5012;<PQjklqr>?XYZcdT[\ekt{&,Z[qw֜}}}vvvvvvvvv֜ hf6hg5 hbhg5.j]h}9hg55OJPJQJU^Jhg50J-OJPJQJ^JhVj=]hg5Ujhg5Uhg5 h}9hg50JOJPJQJ^J#jhg50J-OJPJQJU^J.j\h}9hg55OJPJQJU^J-'( #DEF_`ajkցibցJ9 hYQhg50JOJPJQJ^J.j _hYQhg55OJPJQJU^J h=hg5.j^hL8hg55OJPJQJU^Jhg50J-OJPJQJ^J hIhg50J-OJPJQJ^Jhg50J-5OJPJQJ^J#h,`Chg50J-5OJPJQJ^Jhg5 hL8hg50JOJPJQJ^J#jhg50J-OJPJQJU^J.j+^hL8hg55OJPJQJU^J./ <     ` a  o & FgdZ] & FgdZ]gdg5   ; <             $ %        < = Լԅm.j``hYQhg55OJPJQJU^J.j_hYQhg55OJPJQJU^J hmhg5 hrhg5 hYQhg50JOJPJQJ^J.j~_hYQhg55OJPJQJU^Jhg50J-OJPJQJ^J hFhg5hg5#jhg50J-OJPJQJU^J*= V W X a b            " # $ - . / 0 = ȷȳȷȳqȷ`L&hYhg50J-5OJPJQJ\^J h;Jhg50J-OJPJQJ^J.jahYQhg55OJPJQJU^J#h^Thg50J-5OJPJQJ^J.jBahYQhg55OJPJQJU^Jhg5 hYQhg50JOJPJQJ^J#jhg50J-OJPJQJU^J.j`hYQhg55OJPJQJU^Jhg50J-OJPJQJ^J= ? @ \ ] ^ l m  Ϸݦݢ|kݢSkݢ.j chYhg55OJPJQJU^J hYhg50JOJPJQJ^J.jbhYhg55OJPJQJU^J hnAhg5 hV}hg5hg5 hYQhg50JOJPJQJ^J.j$bhYQhg55OJPJQJU^Jhg50J-OJPJQJ^J#jhg50J-OJPJQJU^J htw$hg50J-OJPJQJ^JMwx`a  & FgdZ] & FgdZ] & FgdZ]gdg5 & FgdZ]ef ֣֣sleeQ&jh!hg5B*U^JaJph hF>6hg5 hi6hg5.j_dhYhg55OJPJQJU^J.jchYhg55OJPJQJU^Jhg50J-OJPJQJ^JhR|hg55OJPJQJ^Jhg5 hYhg50JOJPJQJ^J#jhg50J-OJPJQJU^J.j}chYhg55OJPJQJU^J'()23M_|  %&AE+<=jkŸűxjhg50J-OJPJQJ^J#jhg50J-OJPJQJU^J hq+hg5 h&khg5 hghg5 h5hg5 hJhg5hg5 hF>6hg5h!hg50J^JaJ&jh!hg5B*U^JaJph,jdh!hg5B*U^JaJphh!hg5B*^JaJph'kTU4gh 0[  !!!B"W" & FgdZ] & FgdZ] & FgdZ]# 2( Px 4 #\'*.25@9gdg5gdg5  & F|^|gdZ]YZstu~2hi   &ֳֳֳ|ֳֳdֳֳ.jfhYhg55OJPJQJU^J.j#fhYhg55OJPJQJU^J hxhg5.jehYhg55OJPJQJU^Jhg50J-OJPJQJ^Jhg5 hYhg50JOJPJQJ^J#jhg50J-OJPJQJU^J.jAehYhg55OJPJQJU^J#&'(234tuv0XYַַַַ|ַmX)jhYhg5U\fHq hG7hg5fHq .jghYhg55OJPJQJU^J hlhg5.jzghYhg55OJPJQJU^Jhg5hg50J-OJPJQJ^J hYhg50JOJPJQJ^J#jhg50J-OJPJQJU^J.jghYhg55OJPJQJU^JYrst}~J K V W Y Z [ !!!!!! !8!9!=!>!o!p!{!|!~!!!!!¯£zrzkdzrzk__dzrzkW *h[ghg5 *hg5 hEhhg5 h+ hg5hg5B*phhEhhg5B*ph hG7hg5 *hQhg5hG7hg5fHq hg5fHq $hYhg50J\fHq )jhYhg5U\fHq /jThhYhg5U\fHq hYhg5\fHq "!!!!!!!!!!!A"B"W"""""""#####3#J#K#O#̽涣qqdqUIUh4sfHq hrhg5fHq hVCJaJmHnHujhhg5CJUaJhg5CJaJhhg5CJaJhg5^JaJmH nH sH tH $hEhhg5^JaJmH nH sH tH  hrhg5hG7hg5fHq h+ hg5hg5B*phhEhhg5B*phhg5fHq  *hQhg5 *hg5W"""3#J#O#P#h#m#Skdh$$Ifl0 $$  t0644 la<pytZ]h$If^hgdZ]o$ & Fgdg5<^<gdg5O#P#h#i#m#n#z#{#######$$$$/%0%6%7%8%9%=%>%?%A%%%%%%%%%%ݶ죜wowowod\wowowod *h <hg5hYhg5B*phhg5B*phh0hg5B*ph h=_hg5 *h3vhg5 hQhg5hg5 h"hg5%hrhg5fHmH q sH h4sh4sfHq hg5fHq h4sfHq hrhg5fHq %hUhg5fHmH q sH $m#n###vddh$If^hgdZ]o$kdii$$Ifl0 $$  t0644 la<pytZ]####<$=$@%A%%&vme`````X & FgdZ]gdg5 & FgdZ]<^<gdg5kd j$$Ifl0 $$  t0644 la<pytZ] %%&,'-'F'G'H'K'L'''''''q(z(|((()))))))))))2*:*;*<*U*V*W*Z*[*****+++,,,4, h;Chg5j.khg5Uhg5B*phh0hg5B*ph hThg5 *hQhg5 hQhg50hg50JNB*CJ^JaJfHphq hPshg5hVjjhg5Ujhg5U h ^hg5hg53&&|&&N'''%(J(o((((**++,5,`,,,, - -./,gdg5`gdg5gdg5 & FgdZ]4,5,,,,,, ----r.s.............../////⿸⚥u^WWPP hrhg5 h3=Hhg5,hg50JNB*CJaJfHphq 2h3=Hhg50JB*CJaJfHphq h#`hg5hVjkhg5Ujhg5UhEhhg5B*ph hM'hg5 *hQhg5hG7hg5fHq hg5fHq hg52hPshg5B*CJ^JaJfHphq ///d0000011W1u11112-2S2h2222223(3B3`3 4 h**^*gdg5gdg5/////d0j0k0s0t00000000000000000000011111"1#1U1V1d1e1s1t1u111111111111122222+2ҷƷҷƷƷƷƷƷƷƷƷƷƷƷƷƷƷƷƷƷƷƷƷƷhg5mH nH sH tH hhg5mH nH sH tH h]hg5mH nH sH tH hg5mH nH sH tH h)hg5mH nH sH tH  hrhg5&hg5OJ QJ ^J aJmH nH sH tH hg5=+2,2-2=2?2Q2R2S2b2c2f2g2s2t2222222222222222233"3#3&3'35363@3A3N3O3^3_3`3s3t33333333333333'4(4446494:4L4M4[4y444444444444hg5mHnH sHtH h]hg5mHnH sHtH h]hg5mH nH sH tH hg5mH nH sH tH P`33333)4;4]4z4444/5W5n5555556,6I6g6y66667 4 h**^*gdg54444-5.595;5U5V5g5i5l5555555555555555556666%6'6*6+6B6D6G6H6V6X6e6f6s6t6w66666666667 7777/70717huvhg5mH sH h]hbmH nH sH tH #Hhu;ghbmH nH sH tH #Hhu;ghg5mH nH sH tH h]hg5mH nH sH tH hg5mH nH sH tH A70717<7777888 $$Ifa$gdZ],gdg5^gdg5gdg5gdg5gdg5 4 h**^*gdg5 17<7I7J7s7t7u77777777777777788889k:l:m:{:|:@;A;B;P;Q;$<%<&<4<5<<<<<vvh Whg5B*ph#hGhg56B*]^JaJphhgwhg5B*phh |hg5B*phh\hg55 h^Rhg5 h3=Hhg5 hbhg5jlhg5UhaZhg50JmH sH j(lhg5Ujhg5UhaZhg5mH sH hg5,889l:rii $IfgdZ]kdlm$$Ifl0$ t044 lagpytZ]l:m:|:A;rii $IfgdZ]kdn$$Ifl0$ t044 lagpytZ]A;B;Q;%<rii $IfgdZ]kdn$$Ifl0$ t044 lagpytZ]%<&<5<<rii $IfgdZ]kd^o$$Ifl0$ t044 lagpytZ]<<<(=rii $IfgdZ]kdp$$Ifl0$ t044 lagpytZ]<<<<==(=)=1=2=====;><>D>E>W>]>>>??@@b@c@k@l@@@@@@@;ANAPAQAYAZABBBBdBoBBB.C/CRDSDTDUD%E&EEEEF3G4GIGMGZGG+H,H>HNHHH/I0I1I2IJIQIIII%K h!jhg5hC.hg5B*phhg5hgwhg5B*phhg5B*phS(=)=8==rii $IfgdZ]kdp$$Ifl0$ t044 lagpytZ]===;>rii $IfgdZ]kdPq$$Ifl0$ t044 lagpytZ];><>K>?rii $IfgdZ]kdq$$Ifl0$ t044 lagpytZ]??@b@rii $IfgdZ]kdr$$Ifl0$ t044 lagpytZ]b@c@r@@rii $IfgdZ]kdBs$$Ifl0$ t044 lagpytZ]@@@PArii $IfgdZ]kds$$Ifl0$ t044 lagpytZ]PAQAaABrii $IfgdZ]kdt$$Ifl0$ t044 lagpytZ]BBBBrii $IfgdZ]kd4u$$Ifl0$ t044 lagpytZ]BBB.Crii $IfgdZ]kdu$$Ifl0$ t044 lagpytZ].C/C>CTDrii $IfgdZ]kdv$$Ifl0$ t044 lagpytZ]TDUDdD%Erii $IfgdZ]kd&w$$Ifl0$ t044 lagpytZ]%E&E5EErii $IfgdZ]kdw$$Ifl0$ t044 lagpytZ]EEE3Grii $IfgdZ]kdrx$$Ifl0$ t044 lagpytZ]3G4GCG+Hrii $IfgdZ]kdy$$Ifl0$ t044 lagpytZ]+H,H;H1Irii $IfgdZ]kdy$$Ifl0$ t044 lagpytZ]1I2IAIIrii $IfgdZ]kddz$$Ifl0$ t044 lagpytZ]III&Krii $IfgdZ]kd {$$Ifl0$ t044 lagpytZ]%K&K'KKK L LLLLLLuMvMwMxMyMMMMMMMMMINJNWNXNNNNN+O,O9O:OOOOOOOOOOO'P(P,P-PBPIPKPLPYPZPPPPPQQQQqQrQ~QQQQQQQ%R&R'Rh/qhg5B*phhIhg5B*phhrhg5B*phhg5B*phhgwhg5B*phhg5 h hg5L&K'K6KKrii $IfgdZ]kd{$$Ifl0$ t044 lagpytZ]KKLLrii $IfgdZ]kdV|$$Ifl0$ t044 lagpytZ]LLLxMrii $IfgdZ]kd|$$Ifl0$ t044 lagpytZ]xMyMMMrii $IfgdZ]kd}$$Ifl0$ t044 lagpytZ]MMNINrii $IfgdZ]kdH~$$Ifl0$ t044 lagpytZ]INJNZNNrii $IfgdZ]kd~$$Ifl0$ t044 lagpytZ]NNN+Orii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]+O,O[N[P[[ȸȥ鸝h hg5B*phhVB*ph$jh hg5B*Uphjh hg5B*Uphh hg5B*phhVShg5B*phh\hg5B*phhg5B*phhgwhg5B*phhg55 S!S1S$Trii $IfgdZ]kdj$$Ifl0$ t044 lagpytZ]$T%T4TTrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]TTTUrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]UUUVrii $IfgdZ]kd\$$Ifl0$ t044 lagpytZ]VVVVrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]VVVW^Wri]i $$Ifa$gdZ] $IfgdZ]kd%$$Ifl0$ t044 lagpytZ]^W_WnWXrii $IfgdZ]kdˉ$$Ifl0$ t044 lagpytZ]XXXXrii $IfgdZ]kdq$$Ifl0$ t044 lagpytZ]XXYYrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]YYY[rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ][[>[[rii $IfgdZ]kdc$$Ifl0$ t044 lagpytZ][[[[[[E\F\G\H\\\\\\\\\ ]!]]]]]8^9^:^;^I^K^^^^^^^P_Q____仫䅻~sssƻhh#mhg5B*phhFjPhg5B*ph hg_Nhg5hrhg5B*phhVB*ph$jUhgwhg5B*Uphjhgwhg5B*Uphhgwhg5B*phhg5B*phh`Ihg5B*phh'\hg5B*phhg5h hg5B*phh hg5B*ph([[[G\rii $IfgdZ]kd $$Ifl0$ t044 lagpytZ]G\H\W\ ]rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ] ]!]0]]rii $IfgdZ]kdҎ$$Ifl0$ t044 lagpytZ]]]]:^rii $IfgdZ]kdx$$Ifl0$ t044 lagpytZ]:^;^K^^rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]^^^P_rii $IfgdZ]kdĐ$$Ifl0$ t044 lagpytZ]P_Q_`__rii $IfgdZ]kdj$$Ifl0$ t044 lagpytZ]___}`rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]__|`}`~`aaobpbbbbbfcgcsctccccccccccccccc>dEdQdRdXdYdZd[d\d]d^d_dfdhdddddddddddddddү¤h2whVaJ hVaJhVhVB*ph$jh xhg5B*Uphjh xhg5B*Uphh xhg5B*phhg5B*phhg5h#mhg5B*phhgwhg5B*ph:}`~``arii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]aaaobrii $IfgdZ]kd\$$Ifl0$ t044 lagpytZ]obpbbbrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]bbbfcrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]fcgcvcQdrii $IfgdZ]kdN$$Ifl0$ t044 lagpytZ]QdRdaddrii $IfgdZ]kdq$$Ifl0$ t044 lagpytZ]ddderii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]d e eeeeeeeeeeee1e3eeeeef fhfifjfkfqfrfsftfufvfwfxfzf&g'g(g)g/g0g1g2g3g4g5g6g?gEggggg"h#h)h*h+h,h-h.h/h0h2hhhhhhhhhhhhhhrhg5B*phh6Ffhg5B*ph h hg5hg5h4Ahg5B*phhg5B*phhgwhg5B*phKeeejfrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]jfkfzf(grii $IfgdZ]kdc$$Ifl0$ t044 lagpytZ](g)g8g"hrii $IfgdZ]kd $$Ifl0$ t044 lagpytZ]"h#h2hhrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]hhh jrii $IfgdZ]kdU$$Ifl0$ t044 lagpytZ]hii j jjjjjjjjjjjjjjjjjjjjjjjkkkkkkkkkkkkkklllm m\m]m^m_memfmgmhmimjmkmmmnh Bhg5B*phh8gQhg5B*phhrhg5B*phhg5B*phhg5hgwhg5B*ph/hg5B*OJ QJ ^J aJmH nH phsH tH 5hDhg5B*OJ QJ ^J aJmH nH phsH tH : jjjjrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]jjjkrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]kkklrii $IfgdZ]kdG$$Ifl0$ t044 lagpytZ]ll m^mrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]^m_momnrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]nn.nnrii $IfgdZ]kd9$$Ifl0$ t044 lagpytZ]nn-n.nnnnnnoooooooooompnpop}p~ppppppqqqqqrrrrrsssss.t/t0t>t?ttttttwuxuyuuuuкЯЯФФФМhg5B*phh(hg5B*phh6Vshg5B*phh&hg5B*phhXhhg5B*phh+4hg5B*phh hg5B*phhgwhg5B*phh%nhg5B*phhg5;nnnorii $IfgdZ]kdߞ$$Ifl0$ t044 lagpytZ]oooorii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]ooonprii $IfgdZ]kd+$$Ifl0$ t044 lagpytZ]npop~pprii $IfgdZ]kdѠ$$Ifl0$ t044 lagpytZ]pppqrii $IfgdZ]kdw$$Ifl0$ t044 lagpytZ]qqqrrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]rrrsrii $IfgdZ]kdâ$$Ifl0$ t044 lagpytZ]sss/trii $IfgdZ]kdi$$Ifl0$ t044 lagpytZ]/t0t?ttrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]tttxurii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]xuyuu-vrii $IfgdZ]kd[$$Ifl0$ t044 lagpytZ]uuu,v-v.vvvwwww w/wyyyyzz%z{{{||Q}R}}}~~~~~~~~~~/01ʿʿʿʿʿʿʿʿʿʊʃʃ{p{j}hg5Ujhg5U he5hg5h{hg5B*ph-hGhg5B*^JaJmH nH phsH tH h,Whg5B*phhg5B*phhgwhg5B*phhg5hXhhg5B*phh+4hg5B*ph6hXhhg50JNB*CJ^JaJfHphq ,-v.v=vvrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]vvvwrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]w w/wyrii $IfgdZ]kdM$$Ifl0$ t044 lagpytZ]yy&yzrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]zz%z{rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]{{&{|rii $IfgdZ]kd?$$Ifl0$ t044 lagpytZ]|||Q}rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]Q}R}a}}rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]}}}~rii $IfgdZ]kd1$$Ifl0$ t044 lagpytZ]~~~Nrii $IfgdZ]kd׫$$Ifl0$ t044 lagpytZ]1678LMNO\]^_:;<=HIMMNOZ[_opq|}^_`Ʉ456( hdhg5hPhg5B*phh!whg5B*phhgwhg5B*phhg5B*phhrhg5B*phh hg5B*ph he5hg5hg5jhg5UhV@NO_rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]<rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]<=Mrii $IfgdZ]kdF$$Ifl0$ t044 lagpytZ]Nrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]NO_rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]prii $IfgdZ]kd8$$Ifl0$ t044 lagpytZ]pq_rii $IfgdZ]kdް$$Ifl0$ t044 lagpytZ]_`prii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]Ʉ5rii $IfgdZ]kd*$$Ifl0$ t044 lagpytZ]56Frii $IfgdZ]kdв$$Ifl0$ t044 lagpytZ]rii $IfgdZ]kdv$$Ifl0$ t044 lagpytZ](rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ](چۆ܆-4LMNZ[]ևׇ؇ه!"LM쪵쵪쟵씟yjhSXhg5B*UphhSXhg5B*phhehg5B*phh>Ghg5B*phhdhg5B*phhgwhg5B*phhg5hVB*ph$j´hdhg5B*Uphjhg5B*Uphhg5B*phhdhg5B*ph.Mrii $IfgdZ]kd?$$Ifl0$ t044 lagpytZ]MN]rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]riii\ & F"$IfgdZ] $IfgdZ]kd$$Ifl0$ t044 lagpytZ]!"Mriii\\\ & F"$IfgdZ] $IfgdZ]kd1$$Ifl0$ t044 lagpytZ]TU  ·巨坒|qaqNa$jhM(hg5B*UphjhM(hg5B*UphhM(hg5B*phh2hg5B*phhHhg5B*phhrhg5B*phhgbhg5B*phh>Ghg5B*phhg5hehg5B*phhSXhg5B*phhVB*phjhSXhg5B*Uphhg5B*ph$j׷hSXhg5B*Uphriii\\ & F#$IfgdZ] $IfgdZ]kdT$$Ifl0$ t044 lagpytZ]hMqriii\\\\\\ & F$$IfgdZ] $IfgdZ]kd$$Ifl0$ t044 lagpytZ] ͎ΎЎюvwxyJKLXY)/OUŔƔMNՕ֕\]$%noޘߘº¯ͤͤͤͤͤͤͤͤͤͤͤͤhuHhg5B*phh4ENhg5B*phh+hg5B*phhgwhg5B*phh2hg5B*phhg5B*phhHhg5B*phhg5h.hg5B*phhM(hg5B*phjhM(hg5B*UphhVB*ph3ЎюriiWJJJJ & F%$IfgdZ]x$7$8$H$IfgdZ] $IfgdZ]kd$$Ifl0$ t044 lagpytZ]xrii $IfgdZ]kdú$$Ifl0$ t044 lagpytZ]xyKrii $IfgdZ]kdi$$Ifl0$ t044 lagpytZ]KL[rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]!Ŕrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]ŔƔՔMrii $IfgdZ]kd[$$Ifl0$ t044 lagpytZ]MN]Օrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]Օ֕\rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]\]l$rii $IfgdZ]kdM$$Ifl0$ t044 lagpytZ]$%4nrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]no~ޘrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]ޘߘrii $IfgdZ]kd?$$Ifl0$ t044 lagpytZ]_rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]_`noIJ%&235`fgkloۜܜ@AIJƝǝȝԝ՝ם567BC $%)*]^hZhg5B*phhQhg5B*phh Qhg5B*ph hwUhg5hg5B*phhrhg5B*phhg5hgwhg5B*phG_`orii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]Irii $IfgdZ]kd1$$Ifl0$ t044 lagpytZ]IJYrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]%rii $IfgdZ]kd}$$Ifl0$ t044 lagpytZ]%&5rii $IfgdZ]kd#$$Ifl0$ t044 lagpytZ]ǝrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]ǝȝםrii $IfgdZ]kdo$$Ifl0$ t044 lagpytZ]6rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]67Frii $IfgdZ]kd$$Ifl0$ t044 lagpytZ] ]rii $IfgdZ]kda$$Ifl0$ t044 lagpytZ]]^mrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]^ij РѠijklz{)*+,:;£ңӣԣأݼ誟w`Y h3=Hhg5,hg50JNB*CJaJfHphq 2h3=Hhg50JB*CJaJfHphq hg-hg5 hThg5h0hg5B*phh hg5B*ph hl!hg5hl!hg5B*phhrhg5B*phhgwhg5B*phh Qhg5B*phhg5hg5B*phhQhg5B*ph" Ѡkrii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]kl{+rii $IfgdZ]kdS$$Ifl0$ t044 lagpytZ]+,;rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]rii $IfgdZ]kd$$Ifl0$ t044 lagpytZ]£rmhm\\\\ $$Ifa$gdZ],gdg5gdg5kdE$$Ifl0$ t044 lagpytZ]أ٣    %&'(NOUVcdnoʤCKðǰ89=>@hS/hsjhsU hJ7NhJ7NHht;ghbh`EhWPhm"hfxhg5H* hjhg5hIxahg5H* he_hg5 h8hg5 hCqhg5h2hg55 h3=Hhg5hg58 'P[RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]PQVdo[RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]̤[RRRR $IfgdZ]kd3$$Ifl\ $L t0644 laytZ] #6[RRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]åCrݦ[RRRRRRR $IfgdZ]kd{$$Ifl\ $L t0644 laytZ]ݦަ <X[RRRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]XY^mw[RRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]çҧܧ#L[RRRRRRR $IfgdZ]kdg$$Ifl\ $L t0644 laytZ]LMRcm[RRRR $IfgdZ]kd $$Ifl\ $L t0644 laytZ]ŨϨݨ[RRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]"6@[p[RRRRRR $IfgdZ]kdS$$Ifl\ $L t0644 laytZ] [RRRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ] %9C[RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ][RRRRRR $IfgdZ]kd?$$Ifl\ $L t0644 laytZ]*4Bdz[RRRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]ƫЫ[RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]W[RRRRRR $IfgdZ]kd+$$Ifl\ $L t0644 laytZ][RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ] !"0[RRRRRRRR $IfgdZ]kds$$Ifl\ $L t0644 laytZ] )][RRRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]Ү[RRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ] %Jb[RRRRRR $IfgdZ]kd_$$Ifl\ $L t0644 laytZ]bchx˯[RRRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]˯̯ѯ)[RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ])*/>LVm[RRRRRR $IfgdZ]kdK$$Ifl\ $L t0644 laytZ][RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ]ðְ[RRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ](?[RRRR $IfgdZ]kd7$$Ifl\ $L t0644 laytZ]?@EXfp[RRRRR $IfgdZ]kd$$Ifl\ $L t0644 laytZ][VQQOQQOQgd gdJ7Nkd$$Ifl\ $L t0644 laytZ] rsа * !#gdv * !$gd,* !H$gdV* !H$gdVgd Standards Track Work Product Copyright OASIS Open 2015. All Rights Reserved. Page  PAGE 9 of  NUMPAGES 81  MACROBUTTON NoMacro [document identifier]   MACROBUTTON NoMacro [specification date]  Copyright OASIS Open 2004.All Rights Reserved. Page  PAGE 5 of  NUMPAGES 81 '(*8NOTU[\]^bcmnpqrstΰϰڰ۰돃xkx^hvhS/0J+CJaJhvhS/CJ^JaJhvhS/CJaJjhS/CJUaJhS/hV0J+CJaJmHnHuh dQhS/0J+CJaJ!jh dQhS/0J+CJUaJh dQhS/CJaJh.hS/CJaJh(hS/CJaJhS/CJ^JaJh,hS/CJaJUhS/CJaJ# !"$%&)*+ hJ7NhJ7NhshS/hvhS/CJaJ hV0J+CJaJmHnHu*hS/0J+CJaJmHnHuhvhS/0J+CJaJ!jhvhS/0J+CJUaJа&'()*+gdJ7Ngd  * !#gdv90&P1h:pE=/ =!"#$% =0P&P1h:pZ]/ =!"#$% DdJ0!H  C $A oasisbL @K@2rl(D:n  @K@2rlPNG  IHDRJzPLTE:o[+~Xք=X*bKGDH cmPPJCmp0712OmIDATho:9 QgRV\(3QA_=|II;ǟ'c7IFmFmž~OwOF6ؘƭOKc;Vh<魴W4{5xizۆ^:`fefd$[CoURk炳mfVfG>ȟVgʇ{d8uh%M 42>xQgjyF}X0Ag->E8i#B8iO}8iqj!(YIԱAѹq荢NvQe."pKx38VQǡoD.!_S7 _]B*qIcdi gE[{1 2t*@f82rC*IDATL['<Ox9†?HSxA< 6A^=2EIbK ̒nf1E"+LF85-;([~Ì=(8C?֋3(upv؊M4i09e8sRQu݁8^,=w>T<'7 ^Ccqz8x?8A @,'wwC g`E*+3.YD=Dk(V1Ιq MhߏP+8 upgG8M C#mGX--iwFw& УrC=!`P ۣ1;ꇌhVlj[QңqҰto1LC1 h\&yK4ۙ[ӗ#yP3.c5_>4ѯXfk2^]!KwU2h6dJ-IENDB`DyK yK xhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.docDyK yK zhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.htmlDyK yK xhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdfDyK yK Xhttps://www.oasis-open.org/committees/mqtt/DyK yK @mailto:raphael.cohn@stormmq.comDyK yK 2mailto:coppen@uk.ibm.comDyK yK (http://www.ibm.com/DyK yK >mailto:Andrew_Banks@uk.ibm.comDyK yK (http://www.ibm.com/DyK yK <mailto:rahul.gupta@us.ibm.comDyK yK (http://www.ibm.com/DyK yK http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os.html/DyK yK http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.html DyK  yK https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt technicalDyK yK https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=mqttyX;H,]ą'cDyK yK phttps://www.oasis-open.org/committees/mqtt/yX;H,]ą'c-DyK yK http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.htmlDyK yK zhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.htmlDyK yK ~https://www.oasis-open.org/policies-guidelines/ipryX;H,]ą'cDyK yK Phttps://www.oasis-open.org/yX;H,]ą'cDyK yK https://www.oasis-open.org/policies-guidelines/trademarkyX;H,]ą'c}DyK _Toc442180821}DyK _Toc442180821}DyK _Toc442180822}DyK _Toc442180822}DyK _Toc442180823}DyK _Toc442180823}DyK _Toc442180824}DyK _Toc442180824}DyK _Toc442180825}DyK _Toc442180825}DyK _Toc442180826}DyK _Toc442180826}DyK _Toc442180827}DyK _Toc442180827}DyK _Toc442180828}DyK _Toc442180828}DyK _Toc442180829}DyK _Toc442180829}DyK _Toc442180830}DyK _Toc442180830}DyK _Toc442180831}DyK _Toc442180831}DyK _Toc442180832}DyK _Toc442180832}DyK _Toc442180833}DyK _Toc442180833}DyK _Toc442180834}DyK _Toc442180834}DyK _Toc442180835}DyK _Toc442180835}DyK _Toc442180836}DyK _Toc442180836}DyK _Toc442180837}DyK _Toc442180837}DyK _Toc442180838}DyK _Toc442180838}DyK _Toc442180839}DyK _Toc442180839}DyK _Toc442180840}DyK _Toc442180840}DyK _Toc442180841}DyK _Toc442180841}DyK _Toc442180842}DyK _Toc442180842}DyK _Toc442180843}DyK _Toc442180843}DyK _Toc442180844}DyK _Toc442180844}DyK _Toc442180845}DyK _Toc442180845}DyK _Toc442180846}DyK _Toc442180846}DyK _Toc442180847}DyK _Toc442180847}DyK _Toc442180848}DyK _Toc442180848}DyK _Toc442180849}DyK _Toc442180849}DyK _Toc442180850}DyK _Toc442180850}DyK _Toc442180851}DyK _Toc442180851}DyK _Toc442180852}DyK _Toc442180852}DyK _Toc442180853}DyK _Toc442180853}DyK _Toc442180854}DyK _Toc442180854}DyK _Toc442180855}DyK _Toc442180855}DyK _Toc442180856}DyK _Toc442180856}DyK _Toc442180857}DyK _Toc442180857}DyK _Toc442180858}DyK _Toc442180858}DyK _Toc442180859}DyK _Toc442180859}DyK _Toc442180860}DyK _Toc442180860}DyK _Toc442180861}DyK _Toc442180861}DyK _Toc442180862}DyK _Toc442180862}DyK _Toc442180863}DyK _Toc442180863}DyK _Toc442180864}DyK _Toc442180864}DyK _Toc442180865}DyK _Toc442180865}DyK _Toc442180866}DyK _Toc442180866}DyK _Toc442180867}DyK _Toc442180867}DyK _Toc442180868}DyK _Toc442180868}DyK _Toc442180869}DyK _Toc442180869}DyK _Toc442180870}DyK _Toc442180870}DyK _Toc442180871}DyK _Toc442180871}DyK _Toc442180872}DyK _Toc442180872}DyK _Toc442180873}DyK _Toc442180873}DyK _Toc442180874}DyK _Toc442180874}DyK _Toc442180875}DyK _Toc442180875}DyK _Toc442180876}DyK _Toc442180876}DyK _Toc442180877}DyK _Toc442180877}DyK _Toc442180878}DyK _Toc442180878}DyK _Toc442180879}DyK _Toc442180879}DyK _Toc442180880}DyK _Toc442180880}DyK _Toc442180881}DyK _Toc442180881}DyK _Toc442180882}DyK _Toc442180882}DyK _Toc442180883}DyK _Toc442180883}DyK _Toc442180884}DyK _Toc442180884}DyK _Toc442180885}DyK _Toc442180885}DyK _Toc442180886}DyK _Toc442180886}DyK _Toc442180887}DyK _Toc442180887}DyK _Toc442180888}DyK _Toc442180888}DyK _Toc442180889}DyK _Toc442180889}DyK _Toc442180890}DyK _Toc442180890}DyK _Toc442180891}DyK _Toc442180891}DyK _Toc442180892}DyK _Toc442180892}DyK _Toc442180893}DyK _Toc442180893}DyK _Toc442180894}DyK _Toc442180894}DyK _Toc442180895}DyK _Toc442180895}DyK _Toc442180896}DyK _Toc442180896}DyK _Toc442180897}DyK _Toc442180897}DyK _Toc442180898}DyK _Toc442180898}DyK _Toc442180899}DyK _Toc442180899}DyK _Toc442180900}DyK _Toc442180900}DyK _Toc442180901}DyK _Toc442180901}DyK _Toc442180902}DyK _Toc442180902}DyK _Toc442180903}DyK _Toc442180903}DyK _Toc442180904}DyK _Toc442180904}DyK _Toc442180905}DyK _Toc442180905}DyK _Toc442180906}DyK _Toc442180906}DyK _Toc442180907}DyK _Toc442180907}DyK _Toc442180908}DyK _Toc442180908}DyK _Toc442180909}DyK _Toc442180909}DyK _Toc442180910}DyK _Toc442180910}DyK _Toc442180911}DyK _Toc442180911}DyK _Toc442180912}DyK _Toc442180912}DyK _Toc442180913}DyK _Toc442180913}DyK _Toc442180914}DyK _Toc442180914}DyK _Toc442180915}DyK _Toc442180915}DyK _Toc442180916}DyK _Toc442180916}DyK _Toc442180917}DyK _Toc442180917}DyK _Toc442180918}DyK _Toc442180918}DyK _Toc442180919}DyK _Toc442180919}DyK _Toc442180920}DyK _Toc442180920}DyK _Toc442180921}DyK _Toc442180921}DyK _Toc442180922}DyK _Toc442180922}DyK _Toc442180923}DyK _Toc442180923}DyK _Toc442180924}DyK _Toc442180924}DyK _Toc442180925}DyK _Toc442180925}DyK _Toc442180926}DyK _Toc442180926}DyK _Toc442180927}DyK _Toc442180927}DyK _Toc442180928}DyK _Toc442180928}DyK _Toc442180929}DyK _Toc442180929}DyK _Toc442180930}DyK _Toc442180930}DyK _Toc442180931}DyK _Toc442180931}DyK _Toc442180932}DyK _Toc442180932}DyK _Toc442180933}DyK _Toc442180933}DyK _Toc442180934}DyK _Toc442180934}DyK _Toc442180935}DyK _Toc442180935}DyK _Toc442180936}DyK _Toc442180936}DyK _Toc442180937}DyK _Toc442180937}DyK _Toc442180938}DyK _Toc442180938}DyK _Toc442180939}DyK _Toc442180939}DyK _Toc442180940}DyK _Toc442180940}DyK _Toc442180941}DyK _Toc442180941}DyK _Toc442180942}DyK _Toc442180942}DyK _Toc442180943}DyK _Toc442180943}DyK _Toc442180944}DyK _Toc442180944}DyK _Toc442180945}DyK _Toc442180945}DyK _Toc442180946}DyK _Toc442180946}DyK _Toc442180947}DyK _Toc442180947}DyK _Toc442180948}DyK _Toc442180948}DyK _Toc385349200}DyK _Toc385349200DyK _Figure_1.2_UTF-8_1}DyK _Toc385349205}DyK _Toc385349205}DyK _Toc385349207}DyK _Toc385349207}DyK _Toc385349209}DyK _Toc385349209}DyK _Toc385349211}DyK _Toc385349211}DyK _Toc385349213}DyK _Toc385349213}DyK _Toc385349216}DyK _Toc385349216}DyK _Toc385349217}DyK _Toc385349217}DyK _Toc385349219}DyK _Toc385349219}DyK _Toc385349223}DyK _Toc385349223}DyK _Toc385349226}DyK _Toc385349226}DyK _Toc385349228}DyK _Toc385349228}DyK _Toc385349230}DyK _Toc385349230}DyK _Toc385349238}DyK _Toc385349238}DyK _Toc385349240}DyK _Toc385349240}DyK _Toc385349247}DyK _Toc385349247}DyK _Toc385349251}DyK _Toc385349251}DyK _Toc385349253}DyK _Toc385349253}DyK _Toc385349257}DyK _Toc385349257}DyK _Toc385349261}DyK _Toc385349261}DyK _Toc385349264}DyK _Toc385349264}DyK _Toc385349270}DyK _Toc385349270}DyK _Toc385349271}DyK _Toc385349271}DyK _Toc385349274}DyK _Toc385349274}DyK _Toc385349278}DyK _Toc385349278}DyK _Toc385349280}DyK _Toc385349280}DyK _Toc385349285}DyK _Toc385349285}DyK _Toc385349287}DyK _Toc385349287}DyK _Toc385349292}DyK _Toc385349292}DyK _Toc385349294}DyK _Toc385349294}DyK _Toc385349299}DyK _Toc385349299}DyK _Toc385349301}DyK _Toc385349301}DyK _Toc385349306}DyK _Toc385349306}DyK _Toc385349309}DyK _Toc385349309}DyK _Toc385349311}DyK _Toc385349311}DyK _Toc385349313}DyK _Toc385349313}DyK _Toc385349314}DyK _Toc385349314}DyK _Toc385349318}DyK _Toc385349318}DyK _Toc385349320}DyK _Toc385349320}DyK _Toc385349322}DyK _Toc385349322}DyK _Toc385349324}DyK _Toc385349324}DyK _Toc385349325}DyK _Toc385349325}DyK _Toc385349328}DyK _Toc385349328}DyK _Toc385349330}DyK _Toc385349330}DyK _Toc385349333}DyK _Toc385349333}DyK _Toc385349334}DyK _Toc385349334}DyK _Toc385349338}DyK _Toc385349338}DyK _Toc385349340}DyK _Toc385349340}DyK _Toc385349344}DyK _Toc385349344}DyK _Toc385349350}DyK _Toc385349350}DyK _Toc385349355}DyK _Toc385349355}DyK _Toc385349365}DyK _Toc385349365}DyK _Toc385349367}DyK _Toc385349367}DyK _Toc385349369}DyK _Toc385349369}DyK _Toc385349403}DyK _Toc385349403}DyK _IntroductionDyK _MQTT_Control_PacketDyK _MQTT_Control_PacketsDyK _Operational_behavioruDyK  _SecurityDyK _Using_WebSocket_as{DyK  _ConformanceDyK anchor-RFC2119}DyK _Ref368642907DyK yK Hhttp://www.ietf.org/rfc/rfc2119.txtDyK yK Hhttp://www.ietf.org/rfc/rfc5246.txtDyK yK Hhttp://www.ietf.org/rfc/rfc6455.txtDyK yK Phttp://www.unicode.org/versions/latest/DyK yK Fhttp://www.ietf.org/rfc/rfc793.txtDyK yK xhttp://csrc.nist.gov/publications/fips/fips197/fips-197.pdfDyK yK zhttp://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdfDyK yK |http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdfDyK yK |http://standards.ieee.org/findstds/standard/802.1AR-2009.htmlDyK yK http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425/DyK yK http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.htmlDyK _Normative_ReferencesDyK yK http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.htmlDyK yK http://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdfDyK yK vhttp://www.nist.gov/smartgrid/upload/nistir-7628_total.pdfDyK yK hhttp://www.nsa.gov/ia/programs/suiteb_cryptography/DyK yK rhttps://www.pcisecuritystandards.org/security_standards/DyK yK Hhttp://www.ietf.org/rfc/rfc1928.txtDyK yK Hhttp://www.ietf.org/rfc/rfc4511.txtDyK yK Hhttp://www.ietf.org/rfc/rfc5077.txtDyK yK Hhttp://www.ietf.org/rfc/rfc5280.txtDyK yK Hhttp://www.ietf.org/rfc/rfc6066.txtDyK yK Hhttp://www.ietf.org/rfc/rfc6749.txtDyK yK Hhttp://www.ietf.org/rfc/rfc6960.txtDyK yK http://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htmDyK yK fhttp://export.gov/safeharbor/eu/eg_main_018365.aspqDyK RFC3629qDyK UnicodeDyK _Figure_1.1_Structure$$If!v h#vx #v :V l t065x 5 pZytZ]_kd$$Ifl *Hf!$x  t06$$$$44 lapZytZ]$$If!vh#vx #v:V l t065x 5pytZ]$$If!vh#vx #v:V l t065x 5pytZ]$$If!vh#vx #v:V l t065x 5pytZ]qDyK UnicodeqDyK RFC3629qDyK UnicodeqDyK Unicode$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd$$Ifl  F>!$z t06$$$$44 lapZyt[n$$If!vh#vz#v:V l t065z5pyt[n$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd$$Ifl  F>!$z t06$$$$44 lapZyt[n$$If!vh#vz#v:V l t065z5pyt[n$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd$$Ifl  F>!$z t06$$$$44 lapZyt[n$$If!vh#vz#v:V l t065z5pyt[n$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd$$Ifl  F>!$z t06$$$$44 lapZyt[n$$If!vh#vz#v:V l t065z5pyt[n$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd$$Ifl  F>!$z t06$$$$44 lapZyt[n$$If!vh#vz#v:V l t065z5pyt[n$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd$$Ifl  F>!$z t06$$$$44 lapZyt[n$$If!vh#vz#v:V l t065z5pyt[n$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd$$Ifl  F>!$z t06$$$$44 lapZyt[n$$If!vh#vz#v:V l t065z5pyt[n$$If!v h#vz#v#v :V l t065z55 pZyt[n_kd| $$Ifl  F>!$z t06$$$$44 lapZyt[n}DyK _Figure_2.1_-$$If!vh#v%:V l t0%5%p ytZ]$$If!vh#v%:V l t0%5%p ytZ]$$If!vh#v%:V l t0%5%p ytZ]}DyK _Figure_2.2_-$$If!v h#v<#v#v#v8#v#v :V l t065<555855 pZytZ]_kdV$$Ifl  \ P !$<888 t06$$$$44 lapZytZ]$$If!vh#v<#vH#v:V l t065<5H5pytZ]$$If!vh#v<#v,:V l t065<5,pytZ]{DyK  _Table_2.1_-$$If!vh#v}#v#vT#v:V l t05}55T5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l t05}55Z5p(ytZ]$$If!vh#v}#v#vZ#v:V l< t05}55Z5p(ytZ]{DyK  _Table_2.2_-{DyK  _Table_2.2_-}DyK _Ref381955543$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t0,55558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]$$Ifh!vh#v#v#v#v8:V l t055558ahp<ytZ]}DyK _Ref384201650DyK _Table_2.4_Size$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!v h#v (:V l t065 (pZytZ]Zkd6$$Ifl  4\ $((((((((( t06$$$$44 lapZytZ]$$If!vh#v(#v@!:V l t065(5@!pytZ]$$If!vh#v(#v@!:V l t065(5@!pytZ]{DyK  _Table_2.5_-$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V lU t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]$$Ifh!vh#vI#v :V l t065I5 ahpytZ]}DyK _Ref363142907{DyK  _Table_2.6_-$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V lU t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]$$Ifh!vh#vI#v%:V l t065I5%ahpytZ]}DyK _Ref381955543E$$If!v h#v<#v#v#v#v8#v #v#v8#v :V l t065<555585 5585 pZytZ]_kdO$$Ifl  ,d X $<8 8 t06$$$$44 lapZytZ]$$If!vh#v<#v#v:V l t065<55pytZ]E$$If!v h#v<#v#v#v#v8#v #v#v8#v :V l t065<555585 5585 pZytZ]_kd7T$$Ifl  ,d X $<8 8 t06$$$$44 lapZytZ]$$If!vh#v<#v,:V l t065<5,pytZ]}DyK _Ref355703004$$If!v h#v#v#v :V l t06555 apdytZ]kdX$$Ifl L\p "$ t06((((44 lapdytZ]$$If!vh#v%:V l t065%ap ytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kd]$$Ifl L\p "$ t06((((44 lapdytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kd`$$Ifl L\p "$ t06((((44 lapdytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kd@d$$Ifl L\p "$ t06((((44 lapdytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kdg$$Ifl L\p "$ t06((((44 lapdytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kdfk$$Ifl L\p "$ t06((((44 lapdytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kdn$$Ifl L\p "$ t06((((44 lapdytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kdr$$Ifl L\p "$ t06((((44 lapdytZ]$$If!vh#v%:V l t065%ap ytZ]$$If!v h#v#v#v :V l t06555 apdytZ]kdv$$Ifl L\p "$ t06((((44 lapdytZ])$$If!v h#v!#vo#v#v#v#v"#v 0:V l t065!5o5555"5 0pZytZ]_kd>z$$Ifl $  $!o"0 t06$$$$44 lapZytZ]$$If!vh#v!#vo#v#v#v#v"#v0:V l t065!5o5555"50pPytZ]/kd}$$Iflִ$  $!o"0 t06    44 lapPytZ])$$If!v h#v!#vo#v#v#v#v"#v 0:V l t065!5o5555"5 0pZytZ]_kd$$Ifl $  $!o"0 t06$$$$44 lapZytZ]DyK yK dhttps://tools.oasis-open.org/issues/browse/MQTT-3}DyK _Ref369188333)$$If!v h#v!#va#v8#v#v#v"#v 0:V l t065!5a58555"5 0pZytZ]_kd$$Ifl N  $!a888"0 t06$$$$44 lapZytZ]$$If!vh#v!#vG!:V l t065!5G!pytZ]$$If!vh#v!#vG!:V l t065!5G!pytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kdĊ$$Ifl \p "$< t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kdَ$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kdg$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kdB$$Ifl \p "$< t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kdW$$Ifl  \p "$< t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kdt$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]}DyK _Ref374438163}DyK _Ref374438163}DyK _Ref363648298}DyK _Ref374438163$$If!v h#vx #v :V l t065x 5 pZytZ]Zkd$$Ifl *Hf!$x  t06$$$$44 lapZytZ]$$If!vh#vx #v:V l t065x 5pytZ]$$If!vh#vx #v:V l t065x 5pytZ]$$If!vh#vx #v:V l t065x 5pytZ]}DyK _Ref363033523}DyK _Ref362964779}DyK _Ref362965194}DyK _Figure_3.8_ $$If!v h#v#v :V l t0655 pZytZ]_kd$$Ifl 4- &  !$ t06$$$$44 lapZytZ]$$If!vh#v#v:V l t0655pytZ]$$If!v h#v#v :V l t0655 pZytZ]_kdq$$Ifl 4- &  !$ t06$$$$44 lapZytZ]$$If!vh#v#v:V l t0655pytZ]$$If!v h#v#v :V l t0655 pZytZ]_kdV$$Ifl 4- &  !$ t06$$$$44 lapZytZ]}DyK _Ref383984522$$If!v h#v7#v#v #v ,:V l t065<55 pdytZ]kd$$Ifl K^q "$< t06((((44 lapdytZ]$$If!vh#v#v#v,:V l t06555pytZ]$$If!v h#v7#v#v #v ,:V l t065<55 pdytZ]kdd$$Ifl K^q "$< t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v7#v#v #v ,:V l t065<55 pdytZ]kd$$Ifl K^q "$< t06((((44 lapdytZ]{DyK  _Table_3.1_-$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]$$If!vh#v#v#v:V l t06555pytZ]}DyK _Ref383985930}DyK _Ref383984666E$$If!v h#v#v#v#v#ve#v#vz#v#v z:V l t065A555355'5545 mpZytxS_kd@$$Ifl / >'#A3'4m t06$$$$44 lapZytxS$$If!vh#v#v #v#v#vz:V l t065A55'55mp2ytxSE$$If!v h#v#v#v#v#ve#v#vz#v#v z:V l t065A555355'5545 mpZytxS_kd$$Ifl / >'#A3'4m t06$$$$44 lapZytxS$$If!vh#v#v :V l t065A5GpytxS}DyK _Ref363041167}DyK _Table_3.11_-$$If!vh#v<#v#v#vj:V l t065<555jp(ytZ]$$If!vh#v<#v#v#vj:V l t065<555jp(ytZ]$$If!vh#v<#v#v#vj:V l t065<555jp(ytZ]$$If!vh#v<#v#v#vj:V l t065<555jp(ytZ]$$If!vh#v<#v#v#vj:V l t065<555jp(ytZ]}DyK _Ref369188333}DyK _Ref374438163}DyK _Ref374621403}DyK _Ref363041167DyK _Figure_3.11_-{DyK  _Table_3.2_-$$If!vh#vt#v*:V l t065t5*pytZ]$$If!vh#vt#v*:V l t065t5*pytZ]$$If!vh#vt#v*:V l t065t5*pytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v<#v#v :V l t06, 5<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kdv$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd~$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd$$Ifl \p "$< t06((((44 lapdytZ]$$If!v h#v<#v#v :V l t065<55 pdytZ]kd $$Ifl \p "$< t06((((44 lapdytZ]{DyK  _Table_3.3_-$$If!vh#v #vN :V l t065 5N pytZ]$$If!vh#v #vN :V l t065 5N pytZ]$$If!vh#v #vN :V l t065 5N pytZ]$$If!vh#v #vN :V l t065 5N pytZ]}DyK _Ref363045966$$If!v h#v#v#v :V l t0555 pZytZ]\kd$$Ifl E; 2 ) !$ t0$$$$44 lapZytZ]$$If!vh#v#v#v:V l t0555pytZ]$$If!v h#v#v#v :V l t0555 pZytZ]\kd$$Ifl E; 2 ) !$ t0$$$$44 lapZytZ]$$If!vh#v#v:V l t055pytZ]$$If!v h#v#v#v :V l t0555 pZytZ]\kdp$$Ifl E; 2 ) !$ t0$$$$44 lapZytZ]$$If!v h#v2 #vf#v g:V l t0652 5f5 gpZytZ]Zkd$$Ifl , `.!$2 ffgggggg t06$$$$44 lapZytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]}DyK _Ref384138490B$$If!v h#v #v#v#v#v#v#v#v#v :V l t05 55555555 pZytZ]\kd"$$Ifl  w bN9%!$  t0$$$$44 lapZytZ]$$If!vh#v #v:V l t05 5pytZ]B$$If!v h#v #v#v#v#v#v#v#v#v :V l t05 55555555 pZytZ]\kd'$$Ifl  w bN9%!$  t0$$$$44 lapZytZ]$$If!vh#v #v\:V l t05 5\pytZ]B$$If!v h#v #v#v#v#v#v#v#v#v :V l t05 55555555 pZytZ]\kd?+$$Ifl  w bN9%!$  t0$$$$44 lapZytZ]$$If!v h#v2 #vf#v g:V l t0652 5f5 gpZytZ]Zkd.$$Ifl , `.!$2 ffgggggg t06$$$$44 lapZytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]}DyK _Ref384138602$$If!v h#v:#v#v#v#v :V l t0%5;5 pZytZ]\kd3$$Ifl  zl^!D%; t0%$$$$44 lapZytZ]$$If!vh#v:#v#v:V l t0%5;5pytZ]$$If!v h#v:#v#v#v :V l t0%5;5 pZytZ]\kd7$$Ifl  x^!D%; t0%$$$$44 lapZytZ]$$If!vh#v:#vv:V l t0%5;5pytZ]$$If!v h#v:#v#v#v :V l t0%5;5 pZytZ]\kd;$$Ifl  x^!D%; t0%$$$$44 lapZytZ]$$If!v h#v2 #vf#v g:V l t0652 5f5 gpZytZ]Zkd?$$Ifl , `.!$2 ffgggggg t06$$$$44 lapZytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]}DyK _Ref384138787$$If!v h#v#v :V l t055 pZytZ]\kd D$$Ifl 4- &  !$ t0$$$$44 lapZytZ]$$If!vh#v#v:V l t055pytZ]$$If!v h#v#v :V l t055 pZytZ]\kdG$$Ifl 4- &  !$ t0$$$$44 lapZytZ]$$If!vh#v#v:V l t055pytZ]$$If!v h#v#v :V l t055 pZytZ]\kdK$$Ifl 4- &  !$ t0$$$$44 lapZytZ]$$If!v h#v2 #vf#v g:V l t0652 5f5 gpZytZ]Zkd O$$Ifl , `.!$2 ffgggggg t06$$$$44 lapZytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]}DyK _Ref384138988E$$If!v h#v<#v#v#v#v#v#v#v#v :V l t065<55555555 pZytZ]_kdT$$Ifl  fK1!$< t06$$$$44 lapZytZ]$$If!vh#v<#v:V l t065<5pytZ]E$$If!v h#v<#v#v#v#v#v#v#v#v :V l t065<55555555 pZytZ]_kdWX$$Ifl  fK1!$< t06$$$$44 lapZytZ]$$If!vh#v<#v,:V l t065<5,pytZ]}DyK _Ref363041167DyK _Figure_3.21_-$$If!v h#v#v#v W:V l t06555 WpdytZ]kd]$$Ifl @DIN "$WWWWWWWW t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v#v#v W:V l t06555 WpdytZ]kda$$Ifl @DIN "$WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v#v W:V l t06555 WpdytZ]kd$e$$Ifl @DIN "$WWWWWWWW t06((((44 lapdytZ]}DyK _Ref374438163DyK _Topic_wildcards}DyK _Ref381955543)$$If!v h#vs#v#v#v#v#v#v :V l t065s555555 pZytZ]_kd%j$$Ifl  E>!$s t06$$$$44 lapZytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!vh#vs#v:V l t065s5pytZ]$$If!vh#vs#v:V l t065s5pytZ]$$If!vh#vs#v:V l t065s5pytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!vh#vs#vx#v}:V l t065s5x5}pytZ])$$If!v h#vs#v#v#v#v#v#v :V l t065s555555 pZytZ]_kdSq$$Ifl  E>!$s t06$$$$44 lapZytZ]DyK _Figure_3.23_-{DyK  _Table_3.4_-$$If!vh#v#v*:V l t0655*pytZ]$$If!vh#v#v*:V l t0655*pytZ]$$If!vh#v#v*:V l t0655*pytZ]$$If!vh#v#v*:V l t0655*pytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdAx$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdG|$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdO$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdӆ$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdW$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd]$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdc$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdk$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kds$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdy$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]DyK yK dhttps://tools.oasis-open.org/issues/browse/MQTT-3DyK yK dhttps://tools.oasis-open.org/issues/browse/MQTT-3DyK yK dhttps://tools.oasis-open.org/issues/browse/MQTT-3B$$If!v h#v #v#v#v#v#v#v#v#v :V l t05 55555555 pZytZ]\kd|$$Ifl  w bN9%!$  t0$$$$44 lapZytZ]$$If!vh#v #v:V l t05 5pytZ]B$$If!v h#v #v#v#v#v#v#v#v#v :V l t05 55555555 pZytZ]\kdĮ$$Ifl  w bN9%!$  t0$$$$44 lapZytZ]$$If!vh#v #v\:V l t05 5\pytZ]DyK _Figure_3.25_-$$If!v h#v2 #vf#v g:V l t0652 5f5 gpZytZ]Zkd$$Ifl , `.!$2 ffgggggg t06$$$$44 lapZytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]DyK _Figure_3.26_-)$$If!v h#vs#v#v#v#v#v#v :V l t065s555555 pZytZ]_kd~$$Ifl  E>!$s t06$$$$44 lapZytZ]$$If!vh#vs#v:V l t065s5pytZ])$$If!v h#vs#v#v#v#v#v#v :V l t065s555555 pZytZ]_kd$$Ifl  E>!$s t06$$$$44 lapZytZ]DyK _Figure_3.27_-{DyK  _Table_3.5_-$$If!vh#v #v:V l t065 5pytZ]$$If!vh#v #v:V l t065 5pytZ]$$If!vh#v #v:V l t065 5pytZ] $$If!v h#v#vv #v~#v :V l t0655v 5~5 pdytZ]kd $$Ifl }"$v ~~ t06((((44 lapdytZ] $$If!v h#v#vv #v~#v :V l t0655v 5~5 pdytZ]kd$$Ifl }"$v ~~ t06((((44 lapdytZ] $$If!v h#v#vv #v~#v :V l t0655v 5~5 pdytZ]kdD$$Ifl }"$v ~~ t06((((44 lapdytZ] $$If!v h#v#vv #v~#v :V l t0655v 5~5 pdytZ]kd$$Ifl }"$v ~~ t06((((44 lapdytZ] $$If!v h#vX#v#v#v8#v :V l t05X55585 pZytZ]\kd|$$Ifl   $X8 t0$$$$44 lapZytZ]$$If!vh#vX#v#v>:V l t05X55>pytZ] $$If!v h#vX#v#v#v8#v :V l t05X55585 pZytZ]\kd$$Ifl   $X8 t0$$$$44 lapZytZ]$$If!vh#vX#v :V l t05X5 pytZ]}DyK _Ref363041167$$If!v h#v2 #vf#v g:V l t0652 5f5 gpZytZ]Zkd$$Ifl , `.!$2 ffgggggg t06$$$$44 lapZytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]}DyK _Ref374438163}DyK _Ref381955543DyK _Figure_3.30_-DyK _Table3.6_-_Payload$$If!vh#v#vt:V l t0655tpytZ]$$If!vh#v#vt:V l t0655tpytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kde$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kdm$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!vh#vh%:V l t065h%p ytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd{$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ]$$If!v h#v#v #v W:V l t0655 5 WpdytZ]kd$$Ifl DIN "$ WWWWWWWW t06((((44 lapdytZ] $$If!v h#v#v#v8#v#v <:V l t0555855 <pZytZ]\kd $$Ifl E$ \ <!$88888< t0$$$$44 lapZytZ]$$If!vh#v#v#v0:V l t05550pytZ] $$If!v h#v#v#v8#v#v <:V l t0555855 <pZytZ]\kd $$Ifl E$ \ <!$88888< t0$$$$44 lapZytZ]$$If!vh#v#v:V l t055pytZ] $$If!v h#v#v#v8#v#v <:V l t0555855 <pZytZ]\kd$$Ifl E$ \ <!$88888< t0$$$$44 lapZytZ]$$If!v h#v2 #vf#v g:V l t0652 5f5 gpZytZ]Zkd$$Ifl , `.!$2 ffgggggg t06$$$$44 lapZytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]$$If!vh#v2 #v6:V l t0652 56pytZ]}DyK _Ref363645900)$$If!v h#v#v#v8#v#v8#v#v :V l t06555855855 pZytZ]_kd$$Ifl E$ \ P !$8888 t06$$$$44 lapZytZ]$$If!vh#v#v#v:V l t06555pytZ])$$If!v h#v#v#v8#v#v8#v#v :V l t06555855855 pZytZ]_kdW$$Ifl E$ \ P !$8888 t06$$$$44 lapZytZ]$$If!vh#v#v:V l t0655pytZ])$$If!v h#v#v#v8#v#v8#v#v :V l t06555855855 pZytZ]_kd"$$Ifl E$ \ P !$8888 t06$$$$44 lapZytZ]}DyK _Ref363645900$$If!v h#v#v#v :V l t0555 pZytZ]\kd&$$Ifl E; 2 ) !$ t0$$$$44 lapZytZ]$$If!vh#v#v#v:V l t0555pytZ]$$If!v h#v#v#v :V l t0555 pZytZ]\kd*$$Ifl E; 2 ) !$ t0$$$$44 lapZytZ]$$If!vh#v#v:V l t055pytZ]$$If!v h#v#v#v :V l t0555 pZytZ]\kdw.$$Ifl E; 2 ) !$ t0$$$$44 lapZytZ]$$If!v h#v#v#v#v8#v#v :V l t05555855 pZytZ]\kd1$$Ifl E$ P !$8888 t0$$$$44 lapZytZ]$$If!vh#v#v#v:V l t0555pytZ]$$If!v h#v#v#v#v8#v#v :V l t05555855 pZytZ]\kd5$$Ifl E$ P !$8888 t0$$$$44 lapZytZ]$$If!vh#v#v:V l t055pytZ]$$If!v h#v#v#v#v8#v#v :V l t05555855 pZytZ]\kd:$$Ifl E$ P !$8888 t0$$$$44 lapZytZ]}DyK _Ref363648298oDyK RFC793oDyK RFC793qDyK RFC5246qDyK RFC6455DyK yK hhttp://en.wikipedia.org/wiki/User_Datagram_Protocol$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]}DyK _Ref363041167}DyK _Ref383618483$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]}DyK _Ref363041167}DyK _Ref383618483$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]$$If!vh#v #v #v :V l t0,"65 5 5 apytZ]}DyK _Figure_4.3_ }DyK _Ref374621403qDyK Unicode}DyK _Ref374438163qDyK RFC5246qDyK RFC5246{DyK  USEUSAFEHARBoDyK PCIDSSsDyK  SARBANESqDyK NISTCSFoDyK PCIDSSsDyK  FIPS1402kDyK NSABqDyK NISTCSFDyK MQTTSupplementalPublicationiDyK AESiDyK DESsDyK  ISO29192qDyK RFC4511qDyK RFC6749}DyK _Ref374028308qDyK RFC5246qDyK RFC5246qDyK RFC6066qDyK RFC5246qDyK RFC5246qDyK RFC5246qDyK RFC5246qDyK RFC5246qDyK RFC5280qDyK RFC6960wDyK  IEEE8021ARqDyK RFC5280qDyK RFC6960qDyK RFC5246qDyK RFC5077qDyK RFC5246qDyK RFC1928qDyK RFC5246qDyK RFC5246qDyK NISTCSFsDyK  NIST7628sDyK  FIPS1402oDyK PCIDSSkDyK NSABqDyK RFC6455$$If<!vh#v$ #v:V l t065$ 5a<pytZ]$$If<!vh#v$ #v:V l t065$ 5a<pytZ]$$If<!vh#v$ #v:V l t065$ 5a<pytZ]}DyK _Ref374621403}DyK _Ref368642907}DyK _Ref368642907DyK yK 8mailto:geoff.brown@m2mi.comDyK yK *http://www.m2mi.com/$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]}DyK _Ref374438163$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]}DyK _Ref363033523$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]}DyK _Ref383985930$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]}DyK _Ref374438163$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]}DyK _Ref363648298$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]}DyK _Ref383618483$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]}DyK _Ref383618483$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v:V l t055gpytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]$$If!vh#v#v#v#vL:V l t065555LytZ]^[ xxxpppppp002&6FVfv2(&6FVfv&6FVfv&6FVfv&6FVfv&6FVfv&6FVfv8XV~_HmH nH sH tH L`L  Normal PPOJQJ_HaJmH sH tH x@x R]A Heading 1+$$ & Fx$d@&N5B* CJ$KH \^JaJ$ph;od@d S Heading 2,H2$$ & F$d@&NCJ\]aJJ@!J T Heading 3,H3  & F@& CJ\aJJ@1J U Heading 4,H4  & F@& CJ\aJB@AB  Heading 5  & F@& \]aJD@QD  Heading 6  & F@& CJ\aJ8@a8  Heading 7  & F@&>@q>  Heading 8  & F@&6]8 8  Heading 9 & F@&DA`D Default Paragraph FontVi@V  Table Normal :V 44 la (k (0No List `>@` ]ATitle$dN5B* CJ0KH\^JaJ0ph;o>J@> ]ASubtitleB* CJ$aJ$ph;oVO"V ]ATitle page info $5B* aJph;opOp E=Title page info description$P^m$ 5B*ph2O!22 U Contributor@!B@ Legal notice^0oQ0 DatatypeOJ QJ 6U`a6 0 Hyperlink >*B*ph.@. pTOC 1 <<6@6 pTOC 2<<^6@6 pTOC 3<<^~O~ CodeP$$d&d-DM NP]^ CJOJ QJ NO!N ]AAppendixHeading2  & F B* ph;oFV`F FollowedHyperlink >*B* ph2o2 Element CJOJ QJ 6o6 Attribute CJOJ QJ && KeywordR^@R Normal (Web) dd[$\$OJPJQJ^J.X`. Emphasis6]Ng`!N HTML TypewriterCJOJPJQJ^JaJe@2 HTML Preformatted?# 2( Px 4 #\'*.25@9OJPJQJ^JaJ4O4 Note Heading$<< Note%xx]^JOrJ Definition term &@ ]@ 5PJ@Ob@ Definition'x^PJFOF Ref(p((^p` B*\ph4@4 Header ) !4 @4 HFooter * !.)@. Page NumberdOd J7NAppendixHeading1, & Fdd[$\$B* KH$aJ$ph;o,o, Ref term5.(. Line Number66 pTOC 7/x^^O^ Example50$d&d-DM NP6o6 CODE temp CJOJ QJ FO"F Code small2-DM CJ:O2: Example small3CJ:0@B: List Bullet 4 & F2@2 pTOC 4 5^CJ,oa, Variable6.@Q. pTOC 5 7^2@2 pTOC 6 8^CJ:@: :$ Footnote Text9aJDoD 9$Footnote Text CharOJQJ@"@@ Caption ;xx6CJ\aJ>6> List Bullet 2 < & F<O!< |ML Related Work = & F0O!0 iAbstract>m$<O< ]ANotices?$ B* aJ$ph;o:O: w Text Body @$^rr   Table Grid7:VA0 APPNO1N ]AAppendixHeading3 B & F B* ph;o@&`1@ $Footnote ReferenceH*8+@B8 E7$ Endnote TextDaJBoQB D7$Endnote Text CharOJQJ>*`a> 7$Endnote ReferenceH*>r> g5 Heading 1 WP G$ & F:o: *g5 Footer Char OJQJaJX@X Jg5 Balloon Text ICJOJQJaJmHsHtHVoV Ig5Balloon Text CharCJOJQJaJmHsHtHO g5p TOC Heading-K$$ & Fd$d@& N-B*CJKHOJPJQJ^JaJnHph6_tHL@L g5pTOC 8Ldd^CJOJQJaJL@L g5pTOC 9Mdd^CJOJQJaJBoB g5apple-converted-space<@< Pg5 Comment TextOaJtHFoF Og5Comment Text Char OJQJtHpopg50Colorful Shading - Accent 11QOJQJ_HaJmH sH tH \o!\ g5Heading 1 Char'5B* CJ$KH OJQJ\^JaJ$ph;olo1l g5Heading 2 Char,H2 Char'5B* CJKH OJQJ]^JaJph;onoAn g5Heading 3 Char,H3 Char*5B* CJKH OJQJ\]^JaJph;oloQl g5Heading 4 Char,H4 Char'5B* CJKH OJQJ]^JaJph;oB'`aB g5Comment ReferenceCJaJDj@D Xg5Comment SubjectW 5\tH RoR Wg5Comment Subject Char5OJQJ\tH/ g5h1n`n$x0Colorful Shading - Accent 1ZOJQJ_HaJmH sH tH PK![Content_Types].xmlN0EH-J@%ǎǢ|ș$زULTB l,3;rØJB+$G]7O٭V$ !)O^rC$y@/yH*񄴽)޵߻UDb`}"qۋJחX^)I`nEp)liV[]1M<OP6r=zgbIguSebORD۫qu gZo~ٺlAplxpT0+[}`jzAV2Fi@qv֬5\|ʜ̭NleXdsjcs7f W+Ն7`g ȘJj|h(KD- dXiJ؇(x$( :;˹! I_TS 1?E??ZBΪmU/?~xY'y5g&΋/ɋ>GMGeD3Vq%'#q$8K)fw9:ĵ x}rxwr:\TZaG*y8IjbRc|XŻǿI u3KGnD1NIBs RuK>V.EL+M2#'fi ~V vl{u8zH *:(W☕ ~JTe\O*tHGHY}KNP*ݾ˦TѼ9/#A7qZ$*c?qUnwN%Oi4 =3N)cbJ uV4(Tn 7_?m-ٛ{UBwznʜ"Z xJZp; {/<P;,)''KQk5qpN8KGbe Sd̛\17 pa>SR! 3K4'+rzQ TTIIvt]Kc⫲K#v5+|D~O@%\w_nN[L9KqgVhn R!y+Un;*&/HrT >>\ t=.Tġ S; Z~!P9giCڧ!# B,;X=ۻ,I2UWV9$lk=Aj;{AP79|s*Y;̠[MCۿhf]o{oY=1kyVV5E8Vk+֜\80X4D)!!?*|fv u"xA@T_q64)kڬuV7 t '%;i9s9x,ڎ-45xd8?ǘd/Y|t &LILJ`& -Gt/PK! ѐ'theme/theme/_rels/themeManager.xml.relsM 0wooӺ&݈Э5 6?$Q ,.aic21h:qm@RN;d`o7gK(M&$R(.1r'JЊT8V"AȻHu}|$b{P8g/]QAsم(#L[PK-![Content_Types].xmlPK-!֧6 0_rels/.relsPK-!kytheme/theme/themeManager.xmlPK-!0C)theme/theme/theme1.xmlPK-! ѐ' theme/theme/_rels/themeManager.xml.relsPK] r;wyyyyyy|m ^1q!#$33P4 55i667N889I::;;<<=>>>m?@@KA BBC)DDE"FFzG"HH[IJJUKLLWMMN3OOPKQQpRSST^UUVRWWXqY"ZZ[\p]*^^t_``tabbcEddefZghhiPj&kklmn>oopqrssLtuuv{wSxByFzz|g~juuҊ=œi̗}~)OŤ{ѮM$#KYftE?;C' FUi & )a,.147Q:>A^CE_LO TWk[_Acei)m*ru}3 =Lɣ% ¾_2eq#!0= = &Y!O#%4,/+2417<%K'R[_dhnu1(^أ+Y[\]^`acdefhijklmnopqrsuvwxyz{|}~=DHIK[]kouxz|~ #'(13=FHIKPRS[\^lnoqsuvwyz{|}&28YZ  +P:LD+NW b`lx~b Jd0Ba}ʪ׭7 Vu<W*\#:Ƕȶ./GH`ayzȷɷ67ST![}<o{ (Gfx%G<|5f1l.{! qC w  ) ** +++?,_,../)/i25 6+6H6k6I74DEE%FXFFG=GII J"JNOOOPQRRRR/TjTUVV9VNXXY4ZBZkZ[[}^^^_a'b#gLg_gxgggg*j>jPjdjjjAkkkkPlll{|||}~Tqт8!Uӆ)y͊Vы, IZGU~֘ (ǰ z&dʷݷKZSq6E]7e>W"m##&/`378l:A;%<<(==;>?b@@PABB.CTD%EE3G+H1II&KKLxMMINN+OOKPPQqQQ'R S$TTUVV^WXXY[[G\ ]]:^^P__}`aobbfcQddejf(g"hh jjkl^mnnoonppqrs/ttxu-vvwyz{|Q}}~N<Np_5MxKŔMՕ\$nޘ_I%ǝ6]k+PݦXLb˯)?а+Z_bgt      !"#$%&'()*+,-./0123456789:;<>?@ABCEFGJLMNOPQRSTUVWXYZ\^_`abcdefghijlmnpqrstvwy{}     !"$%&)*+,-./02456789:;<>?@ABCDEGJLMNOQTUVWXYZ]_`abcdefghijkmprtx~      !"#$%'()*+,-./01345679:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW[N`*, YAC2n  V0_xE]a  A / c 0 .yE00q"=D@)i)o)**+7+O+P+p++++++++++++,-,I,K,L,N,n,,,,,,,,--- -*-D-`-c-d-f--------- ....1.N.j.m.n.p........ /%/(/)/+/K/t/////////// 0*0F0I0J0L0l0y000000000001*1F1I1J1L1l1111111111112.2J2M2N2P2p22222222333 3@3W3s3v3w3y3333333334444<4j4444444444455558595;5[5j55555555555 6!6=6@6A6C6c6z66666666666 7797<7=7?7_7n777777777778,8H8K8L8N8n8888888888889'9C9F9G9I9i99999999:::!:A:X:t:w:x:z:::::::::;;;;<;{;;;;;;;;;;;<*<F<I<J<L<l<{<<<<<<<<<<<=O=k=n=o=q=========>>> >@>O>k>n>o>q>>>>>>>>?#?&?'?)?I?]?y?|?}?????????@#@&@'@)@I@Y@u@x@y@{@@@@@@@AA5A8A9A;A[ArAAAAAAAAAAAB1BMBPBQBSBsBBBBBBBBBCCC$C4CPCSCTCVCvCCCCCCCCDDDD8DMDiDlDmDoDDDDDDDDDEEEE;EXEtEwExEzEEEEEEEE F%F(F)F+FKF[FwFzF{F}FFFFFFFFG+G.G/G1GQGfGGGGGGGGGGGHH.H1H2H4HTHHHHHHHHHHHHI0ILIOIPIRIrIIIIIIIIIIIIJ/JKJNJOJQJqJJJJJJJJJKKK%K>KZK]K^K`KKKKKKKKL4L7L8L:LZLLLLLLLLMMMM'MCM_MbMcMeMMMMMMMMMNNNN4NWNsNvNwNyNNNNNNNNO-O0O1O3OSOsOOOOOOOOOOO PP4P7P8P:PZPlPPPPPPPPPPQ QVQrQuQvQxQQQQQQQQ#R?RBRCREReRRRRRRRS#S&S'S)SISSSSSSSTT"T#T%TETtTTTTTTTUU U U+UOUkUnUoUqUUUUUUUU V)V,V-V/VOViVVVVVVVVVVVW0WLWOWPWRWrWWWWWWWWWWWWX1XMXPXQXSXsXXXXXXXXYYYY9YuYYYYYYYZZZZ&Z>Z?Z_ZZZZZZZ*[,[L[~[[[[[[[[\\\$\F\b\e\f\h\\\\\\\\ ]']*]+]-]M]s]]]]]]]^^^^5^i^^^^^^^^^^^_9_U_X_Y_[_{________```!`A`^`z`}`~````````a3aOaRaSaUauaaaaaaab*b-b.b0bPbxbbbbbbbcccc'cDc`cccdcfcccccccc>dZd]d^d`dddddddde6e9e:eh^hhhhhhh"i>iAiBiDidiiiiiiijjj j"jBj{jjjjjjjkkk k)kVkrkukvkxkkkkkkkl1lMlPlQlSlslllllllm9mZe &0E`f3NX:U_z1LV"4Ra   Z u       ' Nis]x'jMhr !<@0!K!O!g%%%>.i.~....NMyMMRRRYYY u%u+u|||xXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%̕ X%XX%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%X%̕XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX_afqt|!33!@ @H 0(  0(  B S  ? _Hlt316035702 _Toc304802775 _Toc353481048 _Toc353481147 _Toc353481293 _Ref363568628 _Ref374094080 _Ref374094088 _Ref374094089 _Toc384800382 _Toc385349191 _Toc385349745 _Toc442180821 _Toc85472893 _Toc287332007 _Toc304802776 _Toc353481049 _Toc353481148 _Toc353481294 _Toc353484663 _Toc354177524 _Toc354228413 _Toc358219853 _Toc358220077 _Toc358278237 _Toc359155534 _Toc359155646 _Toc360556049 _Toc361871087 _Toc366615110 _Toc370160556 _Toc370160697 _Toc384800383 _Toc385349192 _Toc385349746 _Toc442180822 _Toc353481050 _Toc353481149 _Toc353481295 _Toc353484664 _Toc354177525 _Toc354228414 _Toc358219854 _Toc358220078 _Toc358278238 _Toc359155535 _Toc359155647 _Toc360556050 _Toc361871088 _Toc366615111 _Toc370160557 _Toc370160698 _Hlt382346262 _Toc366615112 _Toc370160558 _Toc370160699 _Toc353481051 _Toc353481150 _Toc353481296 _Toc353484665 _Toc354177526 _Toc354228415 _Toc358219855 _Toc358220079 _Toc358278239 _Toc359155536 _Toc359155648 _Toc360556051 _Toc361871089 _Toc366615113 _Toc370160559 _Toc370160700 _Toc353481052 _Toc353481151 _Toc353481297 _Toc353484666 _Toc354177527 _Toc354228416 _Toc358219856 _Toc358220080 _Toc358278240 _Toc359155537 _Toc359155649 _Toc360556052 _Toc361871090 _Toc366615114 _Toc370160560 _Toc370160701 _Toc353481053 _Toc353481152 _Toc353481298 doc-idp4064 _Toc384800384 _Toc385349193 _Toc385349747 _Toc442180823 _Toc371461494 _Toc371461623 _Toc371461495 _Toc371461624_Normative_References doc-idp6784 _Toc384800385 _Toc385349194 _Toc385349748 _Toc442180824anchor-RFC2119 _Toc358219859 _Toc358220083 _Toc358278243RFC3629RFC6455RFC5246 _Hlt373047131 _Hlt373047132 _Hlt373047260 _Hlt373047284 _Hlt383372478 doc-idp75152 _Toc384800386 _Toc385349195 _Toc385349749 _Toc442180825RFC793AESDESFIPS1402 IEEE8021ARISO29192 _Hlt378682786 _Hlt378682787NISTCSFNIST7628NSABPCIDSSRFC1928RFC4511RFC5077RFC5280RFC6066RFC6749RFC6960SARBANES USEUSAFEHARB _Toc384800387 _Toc385349196 _Toc385349750 _Toc442180826 _Toc384800388 _Toc385349197 _Toc385349751 _Toc442180827 _Toc384800389 _Toc385349198 _Toc385349752 _Toc442180828_UTF-8_encoded_strings_ _Ref374438163 _Toc384800390 _Toc385349199 _Toc385349753 _Toc442180829 _Hlt383028091 _Hlt383372775 _Hlt383372698 _Hlt383374299 _Hlt383036824_Figure_1.1_Structure _Toc385349200 _Hlt383374352 _Toc385349201_Figure_1.2_UTF-8_1 _Toc442180830_Figure_1.2_UTF-8 _Toc374395200 _Toc374395201 _Toc374395202 _Toc374395203 _Toc374395204 _Toc374395205 _Toc353481059 _Toc353481158 _Toc353481304_MQTT_Control_Packet _Toc384800391 _Toc385349203 _Toc385349754 _Toc442180831 _Toc384800392 _Toc385349204 _Toc385349755 _Toc442180832 _Figure_2.1_- _Figure_2.1_ _Toc385349205 _Toc380743566_UTF-8_encoded_strings _Toc353481060 _Toc353481159 _Toc353481305 _Toc384800393 _Toc385349206 _Toc385349756 _Toc442180833 _Figure_2.2_- _Toc385349207 _Toc353481061 _Toc353481160 _Toc353481306 _Toc384800394 _Toc385349208 _Toc385349757 _Toc442180834 _Hlt383036464 _Table_2.1_- _Toc385349209 _Toc353481062 _Toc353481161 _Toc353481307 _Toc384800395 _Toc385349210 _Toc385349758 _Toc442180835 _Table_2.2_- _Toc385349211_Dup _Toc384202089 _Toc384202090 _Toc384202091 _Toc384202092 _Toc384202093 _Toc384202094 _Toc384202095 _Toc384202096 _Toc384202097 _Toc384202098 _Toc384202099 _Toc384202100 _Toc384202101 _Toc304802782_QoS _Toc384202102 _Toc384202104 _Toc384202105 _Table_2.3_-_RETAIN _Toc384202132 _Toc384202135 _Toc384202136 _Toc384202137 _Toc384202138 _Toc384202139 _Toc384202141 _Toc384202142 _Toc384202143 _Toc384202144 _Toc384202145 _Toc353481063 _Toc353481162 _Toc353481308 _Ref355703004 _Ref362880293 _Toc384800396 _Toc385349212 _Toc385349759 _Toc442180836_Table_2.4_Size _Toc385349213 _Toc353481064 _Toc353481163 _Toc353481309 _Toc384800397 _Toc385349214 _Toc385349760 _Toc442180837 _Ref363041167 _Ref363568594 _Ref363568656 _Ref363644896 _Ref363726497 _Toc358219870 _Toc358220094 _Toc358278254 _Toc359155438 _Toc359155550 _Toc359155662 _Toc358219871 _Toc358220095 _Toc358278255 _Toc359155439 _Toc359155551 _Toc359155663 _Toc358219872 _Toc358220096 _Toc358278256 _Toc359155440 _Toc359155552 _Toc359155664_Packet_Identifier _Toc384800398 _Toc385349215 _Toc385349761 _Toc442180838 _Figure_2.3_- _Toc385349216 _Table_2.5_- _Toc385349217 _Toc384800399 _Toc385349218 _Toc385349762 _Toc442180839 _Table_2.6_- _Toc385349219 _Ref363142907_MQTT_Control_Packets _Toc384800400 _Toc385349220 _Toc385349763 _Toc442180840 _Ref363033523 _Toc384800401 _Toc385349221 _Toc385349764 _Toc442180841 _Toc384800402 _Toc385349222 _Toc385349765 _Toc442180842 _Figure_3.1_ _Toc385349223 _Toc384800403 _Toc385349224 _Toc385349766 _Toc442180843 _Toc385349225 _Figure_3.2_- _Toc385349226 _Toc385349227 _Figure_3.3_- _Toc385349228 _Toc385349229 _Figure_3.4_- _Toc385349230 _Ref362965194 _Toc385349231 _Ref363648298 _Will_Flag _Toc385349232 _Toc385349233 _Toc385349234 _Toc385349235 _Toc385349236 _Ref363645900 _Keep_Alive _Toc385349237_Figure_3.5_Keep _Toc385349238 _Toc385349239 _Figure_3.6_- _Toc385349240 _Toc384800404 _Toc385349241 _Toc385349767 _Toc442180844 _Toc385349242 _Toc385349243 _Toc385349244 _Toc385349245 _Toc385349246 _Figure_3.7_- _Toc385349247 _Toc384800405 _Toc385349248 _Toc385349768 _Toc442180845 _Ref362964779 _Ref362964780 _Toc384800406 _Toc385349249 _Toc385349769 _Toc442180846 _Toc384800407 _Toc385349250 _Toc385349770 _Toc442180847 _Figure_3.8_- _Figure_3.8_ _Toc385349251 _Toc384800408 _Toc385349252 _Toc385349771 _Toc442180848 _Figure_3.9_- _Figure_3.9_ _Ref383984522 _Toc385349253 _Toc385349254 _Toc385349255 _Toc385349256 _Table_3.1_- _Ref383985930 _Toc385349257 _Toc360556075 _Toc384800409 _Toc385349258 _Toc385349772 _Toc442180849 _Toc384800410 _Toc385349259 _Toc385349773 _Toc442180850 _Toc359155456 _Toc359155568 _Toc359155680 _Toc359155457 _Toc359155569 _Toc359155681 _Ref384201650 _Toc384800411 _Toc385349260 _Toc385349774 _Toc442180851_Figure_3.10_- _Ref383984666_Figure_3.10_ _Toc385349261 _Toc385349262 _Toc385349263 _Table_3.11_- _Toc385349264 _Toc385349265 _Toc384800412 _Toc385349266 _Toc385349775 _Toc442180852 _Toc385349267 _Toc385349268 _Toc385349269 _Table_3.2_- _Toc385349270_Figure_3.11_- _Toc385349271 _Toc384800413 _Toc385349272 _Toc385349776 _Toc442180853 _Toc384800414 _Toc385349273 _Toc385349777 _Toc442180854 _Table_3.3_- _Toc385349274 _Toc384800415 _Toc385349275 _Toc385349778 _Toc442180855 _Toc384800416 _Toc385349276 _Toc385349779 _Toc442180856 _Toc384800417 _Toc385349277 _Toc385349780 _Toc442180857 _Toc385349278 _Toc384800418 _Toc385349279 _Toc385349781 _Toc442180858_Figure_3.13_ _Toc385349280 _Toc384800419 _Toc385349281 _Toc385349782 _Toc442180859 _Toc384800420 _Toc385349282 _Toc385349783 _Toc442180860 _Toc384800421 _Toc385349283 _Toc385349784 _Toc442180861 _Toc384800422 _Toc385349284 _Toc385349785 _Toc442180862_Figure_3.14_ _Toc385349285 _Toc384800423 _Toc385349286 _Toc385349786 _Toc442180863_Figure_3.15_ _Toc385349287 _Toc384800424 _Toc385349288 _Toc385349787 _Toc442180864 _Toc384800425 _Toc385349289 _Toc385349788 _Toc442180865 _Toc384800426 _Toc385349290 _Toc385349789 _Toc442180866 _Toc384800427 _Toc385349291 _Toc385349790 _Toc442180867_Figure_3.16_ _Toc385349292 _Toc384800428 _Toc385349293 _Toc385349791 _Toc442180868_Figure_3.17_ _Toc385349294 _Toc384800429 _Toc385349295 _Toc385349792 _Toc442180869 _Toc384800430 _Toc385349296 _Toc385349793 _Toc442180870 _Toc384800431 _Toc385349297 _Toc385349794 _Toc442180871 _Toc384800432 _Toc385349298 _Toc385349795 _Toc442180872_Figure_3.18_ _Toc385349299 _Toc384800433 _Toc385349300 _Toc385349796 _Toc442180873_Figure_3.19_ _Toc385349301 _Toc384800434 _Toc385349302 _Toc385349797 _Toc442180874 _Toc384800435 _Toc385349303 _Toc385349798 _Toc442180875 _Toc384800436 _Toc385349304 _Toc385349799 _Toc442180876 _Toc384800437 _Toc385349305 _Toc385349800 _Toc442180877_Figure_3.20_ _Toc385349306 _Toc384800438 _Toc385349307 _Toc385349801 _Toc442180878 _Toc385349308_Figure_3.21_- _Toc385349309 _Toc384800439 _Toc385349310 _Toc385349802 _Toc442180879 _Hlt383375795_Figure_3.22_ _Toc385349311 _Toc385349312 _Table_3.4_- _Toc385349313_Figure_3.23_- _Toc385349314 _Toc384800440 _Toc385349315 _Toc385349803 _Toc442180880 _Toc384800441 _Toc385349316 _Toc385349804 _Toc442180881 _Toc384800442 _Toc385349317 _Toc385349805 _Toc442180882_Figure_3.24_ _Toc385349318 _Toc384800443 _Toc385349319 _Toc385349806 _Toc442180883_Figure_3.25_-_Figure_3.25_ _Toc385349320 _Toc384800444 _Toc385349321 _Toc385349807 _Toc442180884_Figure_3.26_-_Figure_3.26_ _Toc385349322 _Toc385349323 _Table_3.5_- _Toc385349324_Figure_3.27_- _Toc385349325 _Toc384800445 _Toc385349326 _Toc385349808 _Toc442180885 _Toc384800446 _Toc385349327 _Toc385349809 _Toc442180886_Figure_3.28_ _Toc385349328 _Toc384800447 _Toc385349329 _Toc385349810 _Toc442180887_Figure_3.29_ _Toc385349330 _Toc384800448 _Toc385349331 _Toc385349811 _Toc442180888 _Toc385349332_Table3.6_-_Payload _Toc385349333_Figure_3.30_- _Toc385349334 _Toc384800449 _Toc385349335 _Toc385349812 _Toc442180889 _Toc384800450 _Toc385349336 _Toc385349813 _Toc442180890 _Toc384800451 _Toc385349337 _Toc385349814 _Toc442180891_Figure_3.31_ _Toc385349338 _Toc384800452 _Toc385349339 _Toc385349815 _Toc442180892_Figure_3.32_ _Toc385349340 _Toc384800453 _Toc385349341 _Toc385349816 _Toc442180893 _Toc384800454 _Toc385349342 _Toc385349817 _Toc442180894 _Toc384800455 _Toc385349343 _Toc385349818 _Toc442180895_Figure_3.33_ _Toc385349344 _Toc384800456 _Toc385349345 _Toc385349819 _Toc442180896 _Toc384800457 _Toc385349346 _Toc385349820 _Toc442180897 _Toc384800458 _Toc385349347 _Toc385349821 _Toc442180898 _Toc384800459 _Toc385349348 _Toc385349822 _Toc442180899 _Toc384800460 _Toc385349349 _Toc385349823 _Toc442180900_Figure_3.34_ _Toc385349350 _Toc360556127 _Toc360556129 _Toc384800461 _Toc385349351 _Toc385349824 _Toc442180901 _Toc384800462 _Toc385349352 _Toc385349825 _Toc442180902 _Toc384800463 _Toc385349353 _Toc385349826 _Toc442180903 _Toc384800464 _Toc385349354 _Toc385349827 _Toc442180904_Figure_3.35_ _Toc385349355 _Toc360556134 _Toc360556135 _Toc384800465 _Toc385349356 _Toc385349828 _Toc442180905 _Toc384800466 _Toc385349357 _Toc385349829 _Toc442180906 _Toc384800467 _Toc385349358 _Toc385349830 _Toc442180907_Operational_behavior _Toc384800468 _Toc385349359 _Toc385349831 _Toc442180908 _Ref369188333 _Ref369188335 _Ref369188337_Storing_state _Toc384800469 _Toc385349360 _Toc385349832 _Toc442180909 _Toc384800470 _Toc385349361 _Toc385349833 _Toc442180910_Network_Connections _Ref368642907 _Toc384800471 _Toc385349362 _Toc385349834 _Toc442180911 _Ref363045966 _Toc384800472 _Toc385349363 _Toc385349835 _Toc442180912 _Toc384800473 _Toc385349364 _Toc385349836 _Toc442180913 _Figure_4.1_ _Toc385349365 _Ref384138490 _Toc384800474 _Toc385349366 _Toc385349837 _Toc442180914 _Figure_4.2_ _Toc385349367 _Ref384138602 _Ref384138787 _Ref384138988 _Toc384800475 _Toc385349368 _Toc385349838 _Toc442180915 _Figure_4.3_ _Toc385349369 _Ref383618483 _Toc384800476 _Toc385349370 _Toc385349839 _Toc442180916 _Toc384800477 _Toc385349371 _Toc385349840 _Toc442180917 _Toc370160654 _Toc370160795 _Toc370160657 _Toc370160798 _Toc370160659 _Toc370160800 _Toc370160660 _Toc370160801 _Toc370160661 _Toc370160802 _Toc370160663 _Toc370160804 _Toc370160664 _Toc370160805 _Toc370160665 _Toc370160806 _Toc370160666 _Toc370160807 _Toc370160667 _Toc370160808 _Toc384800478 _Toc385349372 _Toc385349841 _Toc442180918 _Ref374621403 _Toc384800479 _Toc385349373 _Toc385349842 _Toc442180919 _Ref363571212_Topic_wildcards _Toc384800480 _Toc385349374 _Toc385349843 _Toc442180920 _Toc385349375 _Toc385349376 _Toc385349377 _Toc384800481 _Toc385349378 _Toc385349844 _Toc442180921 _Toc384800482 _Toc385349379 _Toc385349845 _Toc442180922 _Ref381955543 _Toc384800483 _Toc385349380 _Toc385349846 _Toc442180923 _Security _Toc384800484 _Toc385349381 _Toc385349847 _Toc442180924 _Toc384800485 _Toc385349382 _Toc385349848 _Toc442180925 _Toc384800486 _Toc385349383 _Toc385349849 _Toc442180926 _Toc384800487 _Toc385349384 _Toc385349850 _Toc442180927 _Toc384800488 _Toc385349385 _Toc385349851 _Toc442180928 _Toc384800489 _Toc385349386 _Toc385349852 _Toc442180929 _Toc384800490 _Toc385349387 _Toc385349853 _Toc442180930 _Toc384800491 _Toc385349388 _Toc385349854 _Toc442180931 _Toc384800492 _Toc385349389 _Toc385349855 _Toc442180932 _Ref374028308 _Toc384800493 _Toc385349390 _Toc385349856 _Toc442180933 _Toc384800494 _Toc385349391 _Toc385349857 _Toc442180934 _Toc384800495 _Toc385349392 _Toc385349858 _Toc442180935 _Toc384800496 _Toc385349393 _Toc385349859 _Toc442180936 _Toc384800497 _Toc385349394 _Toc385349860 _Toc442180937 _Toc384800498 _Toc385349395 _Toc385349861 _Toc442180938 _Toc384800499 _Toc385349396 _Toc385349862 _Toc442180939 _Toc385349397 _Toc385349398 _Toc385349399 _Toc385349400 _Hlt381014281_Using_WebSocket_as _Toc384800500 _Toc385349401 _Toc385349863 _Toc442180940 _Toc384800501 _Toc385349402 _Toc385349864 _Toc442180941 _Toc385349403 _Toc287332011 _Toc304802783 _Toc353481070 _Toc353481169 _Toc353481315 _Conformance _Toc384800502 _Toc385349404 _Toc385349865 _Toc442180942 _Toc384800503 _Toc385349405 _Toc385349866 _Toc442180943 _Toc384800504 _Toc385349406 _Toc385349867 _Toc442180944 _Toc384800505 _Toc385349407 _Toc385349868 _Toc442180945 _Toc384800506 _Toc385349408 _Toc385349869 _Toc442180946 _Toc384800507 _Toc385349409 _Toc385349870 _Toc442180947 _Toc85472898 _Toc287332014 _Toc304802788 _Toc353481075 _Toc353481174 _Toc353481320 _Toc384800508 _Toc385349410 _Toc385349871 _Toc442180948 rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrssssssssssssssssDsLsLsLsssssssssssssssssssssssssssssssssuuuuuuuu~~~~~~~~~~s>yQDŽYÎďđy\ ##ln+ƟƢƢƢƢ222GGGGGGG0000000ilOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO&&&&&&&&&&&&&&&&&&&&&&&&&&&&8811111====JJZhhlD=o####@<K      ===ZZZZDB   @$@$@$@$@$k$k$k$k$%%%%%%%%%%%v%v%v%v% &+,,.6666]7Z:);]<]<<<_>_>_>_>????@@AAAAEEEEFFFFF/G/G/G/GGGHHHH@H@H@H@HHHHHBIBIBIBIOIOIkJkJkJkJJJaKaKaKaKKKKKKKKKLLLLLLNNNNOOOOOOOOOOOOOOPPPPPPQQQQTRTRRRRRRRRRMSMSMSMS9U9U9U9UFUFU,W,W,W,WW]X]XIYIYIYIYZ]]_``ZaZacccc]q]q]q]qrrrrrrssssttt u u u uvvvxyyuyuyNzNzNzNzzzzzzz||||e}e}}}}}ooPPPP33ŒŒŒŒόόFFFFPPPP]]JJJJvvvv))))66ddddddВВВВ͔͔͔͔͔͔͔͔eeeeHHHHHNNNN''PPPPPPPPPPPPPPPPPPPPPPPP____wwwwwQQQQQZZZZllllvvvvIIIIPPPP        `8888!!!!%%%%....@ UVW %&'()*+,-./01"#$!@23456789:;<=>?@ABCDEFGHIJKLMNOPQRSTXYZ[\]^_`abcdefgijkhlmn@o@p@q@r@stuvwxyz{|}~@@@@@@@@@     %&'() !"#$*+,-./0123456798:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWYXZ[\]^`_abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;@<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-.0/123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ rrrrrrrrrrrrrrrrssssssssssssssssEsJsJsJsssssssssssssssssssssssssssssssss4t4t4t4t4t4t4t4t4t4t4t4t4t4t4t4tuuuuuuuu~~~~~iiis>zVτË_"ʎˏˑh $$mo,۟ŢŢŢŢŢŢŢ22bť_______!5555555iOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOYYYY_____ǵ &&&&&&&&&&&&&&&&&&&7777777778\0#00000]ccccIIIIJrgh wRJ****QES      ==eiiiiSU   @$G$G$G$G$$$$$%%%%%% % % % % %v%v%%%#&+,,$.6666g7k:N;]<<<=f>f>f>f>????@@ A A A AEEEEFFFF;F>G>G>G>GGGHHHHGHGHGHGHHHHHNINININIOIwIzJzJzJzJJKhKhKhKhKKKKKLLLLLLLLLLNNNNO.OOOOOOOOO5P5P5P5PPPPPPPQQQQTRRRRRRSSSSlSlSlSlSEUEUEUEUFUqU;W;W;W;WW]XXPYPYPYPYZ]^_` aZaaccccqqqqrrrrrrsssstttuuuuvvvxy-yuyyszszszszzzzzz{||||e}}}}}}-FoXXXX%%%%Èȉȉȉȉ3`ΌΌΌΌό^^^^\\\\]QQQQ55556bddssss͔ؒؒؒؒ̔̔̔̔ڔڔڔڔڔڔڔzzzztttttjjjj'fܭկկկկկկկԸ&&&&PPPPPPPPPPPPPPPPPPPP````.....wwwwQYYYYffffoooozzzz0000    y($$$$KKKK'!!!!%%%%....ǙǙǙǙǙǙؙؙؙؙDcdccc>d^ddde:eeeefdffff?g_ggghd^ddde:eeeefdffff?g_ggghq("ox/+H?2:Le^v<.[;WOGY7KĎziLXMɾsPVT]<*WTBTZ.$?M\/^Z`M_;`W_B q d&,Bfe|>iCj*)tkԐ$R1 m[VLtNBVJux= ^`OJQJo( 8^8`OJQJo( ^`OJ QJ o(o  p^ `OJ QJ o(  @ ^ `OJ QJ o( x^x`OJQJo( H^H`OJ QJ o(o ^`OJ QJ o( ^`OJ QJ o(^`.^`.88^8`.^`. ^`OJQJo( ^`OJQJo( 88^8`OJQJo(^`QJo( hh^h`. hh^h`OJQJo(h^`OJQJo(hHhp^p`OJ QJ ^J o(hHoh@ ^@ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhP^P`OJ QJ ^J o(hHoh ^ `OJ QJ o(hHh^`OJQJo(hHhp^p`OJ QJ ^J o(hHoh@ ^@ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhP^P`OJ QJ ^J o(hHoh ^ `OJ QJ o(hHh  ^ `OJQJo(hH*^*`OJPJQJ^Jo(" h^`OJ QJ o(hHh| | ^| `OJQJo(hHhLL^L`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohp^p`OJ QJ o(hHh@ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohP^P`OJ QJ o(hHh^`OJQJo(hHhp^p`OJ QJ ^J o(hHoh@ ^@ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhP^P`OJ QJ ^J o(hHoh ^ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohp^p`OJ QJ o(hHh@ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohp^p`OJ QJ o(hHh@ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohP^P`OJ QJ o(hHh ^`hH.h pp^p`hH.h @ L@ ^@ `LhH.h ^`hH.h ^`hH.h L^`LhH.h ^`hH.h PP^P`hH.h  L ^ `LhH.h ^`hH.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH.h^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohp^p`OJ QJ o(hHh@ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohp^p`OJ QJ o(hHh@ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohp^p`OJ QJ o(hHh@ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh2 ^2 `OJ QJ ^J o(hHoh ^ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohr^r`OJ QJ o(hHhB^B`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh  ^ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh| | ^| `OJQJo(hHhLL^L`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhT^T`OJ QJ ^J o(hHoh$ ^$ `OJ QJ o(hHh ^ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHhd^d`OJQJo(hHh4^4`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhp^p`OJ QJ ^J o(hHoh@ ^@ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhP^P`OJ QJ ^J o(hHoh ^ `OJ QJ o(hHh^`OJQJo(hHhp^p`OJ QJ ^J o(hHoh@ ^@ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhP^P`OJ QJ ^J o(hHoh ^ `OJ QJ o(hHh^`OJQJo(hHhp^p`OJ QJ ^J o(hHoh@ ^@ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhP^P`OJ QJ ^J o(hHoh ^ `OJ QJ o(hHP^`Po(@^@`o(.0^`0o(..`^``o(... ^`o( .... ^`o( ..... ^`o( ...... `^``o(....... 00^0`o(........ h h^h`o(hH Appendix . @^@`o(hH. 0^`0o(hH.. `^``o(hH...  ^`o(hH .... ^`o(hH ..... ^`o(hH ......  `^``o(hH.......  00^0`o(hH........P^`Po(@@^@`o(.0^`0o(..``^``o(... ^`o( .... ^`o( ..... ^`o( ...... `^``o(....... 00^0`o(........h ^`o(hH.hpp^p`OJ QJ ^J o(hHoh@ @ ^@ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHhPP^P`OJ QJ ^J o(hHoh  ^ `OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohp^p`OJ QJ o(hHh@ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohP^P`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohpp^p`OJ QJ o(hHh@ @ ^@ `OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHohPP^P`OJ QJ o(hHh88^8`OJQJo(hHh^`OJ QJ ^J o(hHoh  ^ `OJ QJ o(hHh  ^ `OJQJo(hHhxx^x`OJ QJ ^J o(hHohHH^H`OJ QJ o(hHh^`OJQJo(hHh^`OJ QJ ^J o(hHoh^`OJ QJ o(hH.fW_W_BVJuq d\; sP]<*W?2:iCj[<l &v<tkiL;WOGnl@4/+1 mnV >q(VLtM?M\&b`M_BTZ.Ts$ 7Kgf ~}|--                   "G                                                                                                                                                                                                                      Z$%                                    t,        V _Q0Vdo|TU]MVdt]gCU]MVdY9 _Q0VdU]M`QU]MVd 2]!c~9#h)_Q0X;_Q0Vd n?C':\DU]MVdfD_Q0Vdm NH_Q0Vd I_Q0VdnO;SU]MVd ']U]MVdz|^[4{_Wa_Q0VdAgU Ms_Q0VdONsU]MVd1itU]MVdnt 2zv~_:k(5CLt$A0@%9I E1@0n,R -n  n  (&=W"[nm&l/?FFC]kTcBUg}2bG;rS&`+xli4FKQE 1!$<"m"#s"#T#W%Y&'r'/@(n(c)3+*{++&+~&+f+~+h,X,@h,&-S/* 010)1x1 14g5`!6 l67A?7T9G :7;[;< <a<=E=1g> ?:.@AK*A&B/'B7XB?Cf CDD`E/Fm~FI%INIeIQJAJ> K*K|ML^MfM,NJ7N 9O[O&QdIQ dQ R~RcSxS!T}T;~T?MUVR#W+W4WG|XY1Y;)ZA^ZO[J\hS\.]0]Z]G`apScm^cef Cfg;|gRhijC4jI,kFlwol1mVtnoq#o+,oq8opcFpWp|!q2q9qeqgqrt/t-tgt6v).FLw a_2k/3[e1h5QBj s#OF?`XD1%U:Fb#"2/o7$}(>@$R^Dsm(%8}B_ESDPIV4sNqVU@<^$s:_gZ / PWPeE0F^?(qZ*`]AYqis8c~ sc5-KVX5CJdu&ODNQ.]Q"I2lly6Yd&d&s(\?TH^rd,HY5Sb J:lfB|>5 ;U}<z !1DJ6n}%\~k!DRauT'<|.X ]o)^gb)l60LU9o)>Q]Ogw__RFC5246&d8RFC6749$c5RFC4511B2 ISO29192de/DESae,AESgy)MQTTSupplementalPublication~n&NISTCSF#NSAB  FIPS1402jtPCIDSS~nNISTCSF SARBANESjtPCIDSS USEUSAFEHARB#gRFC5246#g RFC5246siUnicode!]_Figure_4.3_ P4http://en.wikipedia.org/wiki/User_Datagram_Protocol%eRFC6455#gRFC5246(bRFC7931_Table3.6_-_Payloady_Figure_3.30_-|X _Table_3.5_-x_Figure_3.27_-x_Figure_3.26_-x_Figure_3.25_- 2https://tools.oasis-open.org/issues/browse/MQTT-3 2https://tools.oasis-open.org/issues/browse/MQTT-3 2https://tools.oasis-open.org/issues/browse/MQTT-3|Y _Table_3.4_-x_Figure_3.23_-_Topic_wildcardsx_Figure_3.21_-|^ _Table_3.3_-|_ _Table_3.2_-{_Figure_3.11_-.|_Table_3.11_-|\p _Table_3.1_--]j_Figure_3.8_  O2https://tools.oasis-open.org/issues/browse/MQTT-3|ZF _Table_2.6_-|Y@ _Table_2.5_-|=_Table_2.4_Size|^4 _Table_2.2_-|^1 _Table_2.2_-|]. _Table_2.1_-&]+_Figure_2.2_-%](_Figure_2.1_-si%Unicodesi"Unicode'gRFC3629siUnicode1Z_Figure_1.1_StructuresiUnicode'gRFC36293http://export.gov/safeharbor/eu/eg_main_018365.aspK Fhttp://www.gpo.gov/fdsys/pkg/PLAW-107publ204/html/PLAW-107publ204.htm&< $http://www.ietf.org/rfc/rfc6960.txt!>$http://www.ietf.org/rfc/rfc6749.txt)<$http://www.ietf.org/rfc/rfc6066.txt-1$http://www.ietf.org/rfc/rfc5280.txt(>$http://www.ietf.org/rfc/rfc5077.txt+9$http://www.ietf.org/rfc/rfc4511.txt.?$http://www.ietf.org/rfc/rfc1928.txtB;9https://www.pcisecuritystandards.org/security_standards/`B4http://www.nsa.gov/ia/programs/suiteb_cryptography/ 0;http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf;vGhttp://www.nist.gov/itl/upload/preliminary-cybersecurity-framework.pdfJUIhttp://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html_Normative_References="_http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.htmlIAShttp://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56425\>http://standards.ieee.org/findstds/standard/802.1AR-2009.htmlH>http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf=http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf!h<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf4n#http://www.ietf.org/rfc/rfc793.txt+i(http://www.unicode.org/versions/latest/.?$http://www.ietf.org/rfc/rfc6455.txt+=$http://www.ietf.org/rfc/rfc5246.txt'?$http://www.ietf.org/rfc/rfc2119.txt%manchor-RFC2119& _ConformanceR_Using_WebSocket_as& _Security_Operational_behavior?_MQTT_Control_Packets?_MQTT_Control_Packet-_Introduction6_Toc3853494031_Toc3853493691_Toc3853493671_Toc3853493651_Toc3853493551_Toc3853493501_Toc3853493441y_Toc3853493401s_Toc3853493381m_Toc3853493341g_Toc3853493331a_Toc3853493301[_Toc3853493281U_Toc3853493251O_Toc3853493241I_Toc3853493221C_Toc3853493201=_Toc38534931817_Toc38534931411_Toc3853493131+_Toc3853493111%_Toc3853493091_Toc3853493061_Toc3853493010_Toc3853492990 _Toc3853492940_Toc3853492920_Toc3853492870_Toc3853492850_Toc3853492800_Toc3853492780_Toc3853492740_Toc3853492710_Toc3853492700_Toc3853492640_Toc3853492610_Toc3853492570_Toc3853492530_Toc3853492510_Toc3853492470_Toc3853492400_Toc3853492380_Toc3853492300_Toc3853492280_Toc3853492260_Toc3853492230_Toc3853492190_Toc3853492170_Toc3853492160}_Toc3853492130w_Toc3853492110q_Toc3853492090k_Toc3853492070e_Toc385349205[b_Figure_1.2_UTF-8_10\_Toc3853492007S_Toc4421809487M_Toc4421809477G_Toc4421809467A_Toc4421809457;_Toc44218094475_Toc4421809437/_Toc4421809427)_Toc4421809417#_Toc4421809407_Toc4421809397_Toc4421809387_Toc4421809377 _Toc4421809367_Toc4421809357_Toc4421809347_Toc4421809337_Toc4421809327_Toc4421809317_Toc4421809307_Toc4421809297_Toc4421809287_Toc4421809277_Toc4421809267_Toc4421809257_Toc4421809247_Toc4421809237_Toc4421809227_Toc4421809217_Toc4421809207_Toc4421809197_Toc4421809187_Toc4421809177_Toc4421809167_Toc4421809157_Toc4421809147_Toc4421809137{_Toc4421809127u_Toc4421809117o_Toc4421809107i_Toc4421809097c_Toc4421809087]_Toc4421809077W_Toc4421809067Q_Toc4421809057K_Toc4421809047E_Toc4421809037?_Toc44218090279_Toc44218090173_Toc4421809006-_Toc4421808996'_Toc4421808986!_Toc4421808976_Toc4421808966_Toc4421808956_Toc4421808946 _Toc4421808936_Toc4421808926_Toc4421808916_Toc4421808906_Toc4421808896_Toc4421808886_Toc4421808876_Toc4421808866_Toc4421808856_Toc4421808846_Toc4421808836_Toc4421808826_Toc4421808816_Toc4421808806_Toc4421808796_Toc4421808786_Toc4421808776_Toc4421808766_Toc4421808756_Toc4421808746_Toc4421808736_Toc4421808726_Toc4421808716_Toc4421808706y_Toc4421808696s_Toc4421808686m_Toc4421808676g_Toc4421808666a_Toc4421808656[_Toc4421808646U_Toc4421808636O_Toc4421808626I_Toc4421808616C_Toc4421808606=_Toc44218085967_Toc44218085861_Toc4421808576+_Toc4421808566%_Toc4421808556_Toc4421808546_Toc4421808536_Toc4421808526 _Toc4421808516_Toc4421808506_Toc4421808496_Toc4421808486_Toc4421808476_Toc4421808466_Toc4421808456_Toc4421808446_Toc4421808436_Toc4421808426_Toc4421808416_Toc4421808406_Toc4421808396_Toc4421808386_Toc4421808376_Toc4421808366_Toc4421808356_Toc4421808346_Toc4421808336_Toc4421808326_Toc4421808316_Toc4421808306_Toc4421808296_Toc4421808286}_Toc4421808276w_Toc4421808266q_Toc4421808256k_Toc4421808246e_Toc4421808236__Toc4421808226Y_Toc442180821 VT9https://www.oasis-open.org/policies-guidelines/trademarky{Qhttps://www.oasis-open.org/r7N3https://www.oasis-open.org/policies-guidelines/iprK=http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.htmlJH^http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.html6<E3https://www.oasis-open.org/committees/mqtt/ipr.php/'B,https://www.oasis-open.org/committees/mqtt/9?Hhttps://www.oasis-open.org/committees/comments/index.php?wg_abbrev=mqttZ<Ahttps://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt technical="9_http://docs.oasis-open.org/mqtt/mqtt-nist-cybersecurity/v1.0/mqtt-nist-cybersecurity-v1.0.htmlkv6Chttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html3Uhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os.htmls!0http://www.ibm.com/%-mailto:rahul.gupta@us.ibm.coms!*http://www.ibm.com/&v'mailto:Andrew_Banks@uk.ibm.coms!$http://www.ibm.com/C5!mailto:coppen@uk.ibm.comj  mailto:raphael.cohn@stormmq.com/',https://www.oasis-open.org/committees/mqtt/tb<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.pdf=http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html`i<http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.doc Bhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdfkv Chttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html  Bhttp://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.docZ]http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.pdfJ^http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.htmlQ]http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/errata01/os/mqtt-v3.1.1-errata01-os-complete.doc OASIS TCMQTT 3.1.1 Plus Errata 01Andrew Banks Rahul GuptaRaphael J CohnRichard Coppen Geoff Brown  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZkRoot Entry F 芩]mData ]#1TableNWordDocumentzSummaryInformation(DocumentSummaryInformation8{CompObjr  F Microsoft Word 97-2003 Document MSWordDocWord.Document.89q