idnits 2.17.1 draft-hapner-hybi-messagebroker-subprotocol-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 34 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-hybi-thewebsocketprotocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 13, 2012) is 4267 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'GPBE' is defined on line 571, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GPBE' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Hapner, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track C. Suconic 5 Expires: February 14, 2013 redhat 6 August 13, 2012 8 The MessageBroker WebSocket Subprotocol 9 draft-hapner-hybi-messagebroker-subprotocol-03 11 Abstract 13 The WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol] provides 14 a subprotocol extension facility. The MessageBroker WebSocket 15 Subprotocol (MBWS) is a WebSocket Subprotocol used by messaging 16 clients to send messages to, and receive messages from an internet 17 message broker (herein called a message broker). A message broker is 18 a messaging intermediary that queues messages sent by its clients for 19 asynchronous delivery to its clients. 21 Messages are addressed to message-broker-specific address names. 22 Clients send messages to addresses and consume messages from 23 addresses. Clients do not send messages directly to other clients. 25 Message brokers provide a range of functionality that is outside the 26 scope of MBWS. Typically an internet message broker provides a REST 27 API for working with this functionality; such as configuring client 28 credentials; setting client access controls; configuring address 29 routing; etc. 31 MBWS limits its scope to the definition of a WebSocket subprotocol 32 that provides a full duplex, reliable message transport protocol 33 between message brokers and their clients; and, between message 34 brokers. 36 Since reliable message transport is often independent of a broker's 37 particular features, MBWS can be used as the message transport 38 protocol for a wide range of message brokers. 40 The MBWS subprotocol defines a binary message frame and a text 41 message frame. Both types of frame carry the same protocol; however, 42 the protocol bindings differ slightly. The binary frame is a 43 WebSocket binary message that contains an MBWS binary header followed 44 by a binary message body. The text frame is a WebSocket UTF-8 text 45 message that contains an MBWS text header followed by a text message 46 body. 48 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on February 14, 2013. 64 Copyright Notice 66 Copyright (c) 2012 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. MBWS Functionality . . . . . . . . . . . . . . . . . . . . . . 4 83 2.1. Connection Recovery . . . . . . . . . . . . . . . . . . . 5 84 2.1.1. MBWS Connections . . . . . . . . . . . . . . . . . . . 5 85 2.1.2. MBWS Connect . . . . . . . . . . . . . . . . . . . . . 5 86 2.1.3. MBWS Message Sequencing . . . . . . . . . . . . . . . 6 87 2.1.4. MBWS Reconnect . . . . . . . . . . . . . . . . . . . . 6 88 2.1.5. MBWS Prepare-to-close . . . . . . . . . . . . . . . . 7 89 2.1.6. MBLWS Connections . . . . . . . . . . . . . . . . . . 8 90 2.1.7. Message Metadata . . . . . . . . . . . . . . . . . . . 8 91 2.1.7.1. Address List . . . . . . . . . . . . . . . . . . . 8 92 2.1.7.1.1. Undeliverable Messages . . . . . . . . . . . . 8 93 2.1.7.2. Content-Type . . . . . . . . . . . . . . . . . . . 9 94 2.1.7.3. Property List . . . . . . . . . . . . . . . . . . 9 95 3. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 9 96 3.1. Sec-WebSocket-Protocol Field . . . . . . . . . . . . . . . 9 97 3.2. Client Identity . . . . . . . . . . . . . . . . . . . . . 9 98 3.3. Message Security . . . . . . . . . . . . . . . . . . . . . 9 99 3.4. Empty Protocol Values . . . . . . . . . . . . . . . . . . 10 100 4. MBWS/MBLWS Protocol ABNF . . . . . . . . . . . . . . . . . . . 10 101 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11 102 5.1. MBWS Connection Recovery Scenario . . . . . . . . . . . . 11 103 5.2. MBLWS Session Scenario . . . . . . . . . . . . . . . . . . 12 104 6. Issues Outside the Scope of this Document . . . . . . . . . . 12 105 6.1. Messaging Scope . . . . . . . . . . . . . . . . . . . . . 12 106 6.2. Message Acknowledgement Interval . . . . . . . . . . . . . 13 107 6.3. Synchronous Messaging . . . . . . . . . . . . . . . . . . 13 108 6.4. End-to-End Reliability . . . . . . . . . . . . . . . . . . 13 109 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 112 1. Introduction 114 The WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol] provides 115 a subprotocol extension facility. The MessageBroker WebSocket 116 Subprotocol (MBWS) is a WebSocket Subprotocol used by messaging 117 clients to send messages to, and receive messages from an internet 118 message broker (herein called a message broker). A message broker is 119 a messaging intermediary that queues messages sent by its clients for 120 asynchronous delivery to its clients. 122 Messages are addressed to message-broker-specific address names. 123 Clients send messages to addresses and consume messages from 124 addresses. Clients do not send messages directly to other clients. 126 Message brokers provide a range of functionality that is outside the 127 scope of MBWS. Typically an internet message broker provides a REST 128 API for working with this functionality; such as configuring client 129 credentials; setting client access controls; configuring address 130 routing; etc. 132 MBWS limits its scope to the definition of a WebSocket subprotocol 133 that provides a full duplex, reliable message transport protocol 134 between message brokers and their clients; and, between message 135 brokers. 137 Since reliable message transport is often independent of a broker's 138 particular features, MBWS can be used as the message transport 139 protocol for a wide range of message brokers. 141 The MBWS subprotocol defines a binary message frame and a text 142 message frame. Both types of frame carry the same protocol; however, 143 the protocol bindings differ slightly. The binary frame is a 144 WebSocket binary message that contains an MBWS binary header followed 145 by a binary message body. The text frame is a WebSocket UTF-8 text 146 message that contains an MBWS text header followed by a text message 147 body. 149 2. MBWS Functionality 151 MBWS subprotocol defines two capabilities: 152 o Connection Recovery - the ability to support a logical, reliable 153 connection that spans a sequence of WebSocket sessions 154 o Message Metadata - the ability to annotate a WebSocket message 155 with metadata to support the functionality of a message broker 157 This document defines two subprotocols - MessageBroker WebSocket 158 Subprotocol (MBWS) and MessageBrokerLight WebSocket Subprotocol 159 (MBLWS). MBWS supports both Connection Recovery and Message 160 Metadata. MBLWS supports only Message Metadata. 162 The protocol description defines the logical MBWS and MBLWS 163 subprotocols. The protocol ABNF [RFC5234] defines the binding of 164 these protocols to MBWS binary frames and text frames. MBLWS uses 165 the same frames as MBWS. 167 2.1. Connection Recovery 169 If a WebSocket session fails, the protocol does not define how the 170 parties resolve what messages have been received and what messages 171 have been lost. In many cases, this is not an issue; however, 172 message brokers typically provide once-and-only-once QoS and 173 WebSocket alone is not sufficient to support this. 175 MBWS defines a Connection Recovery subprotocol that allows a message 176 broker client whose connection's session has failed to create a new 177 WebSocket session that extends the connection and reliably 178 resynchronizes its full duplex message transport such that no 179 messages are lost or duplicated. 181 2.1.1. MBWS Connections 183 MBWS defines a connection that spans a sequence of one or more 184 WebSocket sessions. During the time period between the failure of 185 one of its sessions and the creation of its next session, its parties 186 must maintain the state required to recover the connection. Since 187 messages may be lost when a session fails, this state must contain a 188 window of recently sent messages. MBWS provides support for 189 identifying connections; maintaining recently sent message windows; 190 recovering a connection on a new session; and, resynchronizing a 191 recovered connection's message transport. 193 2.1.2. MBWS Connect 195 When a client requests a new MBWS connection it sends a Connect frame 196 with an empty connection name. The server must respond with a 197 Connect frame containing the name of a new connection. The MBWS 198 client must retain this connection name so that it can be used later 199 to recover this connection if this connection's current WebSocket 200 session were to fail. It is recommended but not required that 201 connection name be a URN. 203 Connection's are identified by a combination of client origin and 204 connection name. Only the client origin that opened the connection 205 can recover the connection. 207 An MBWS connection is closed by an MBWS Prepare-to-close followed by 208 a WebSocket close. 210 2.1.3. MBWS Message Sequencing 212 MBWS requires clients and message brokers to use an implicit sequence 213 numbering protocol for the messages transported by a connection. 214 Each direction of transport defines a separate sequence. The first 215 message sent by each endpoint is sequence number 1, the next is 2, 216 etc. Since both parties are guaranteed to see the messages in the 217 order sent, no explicit exchange of sequence numbers is required. 219 Both parties must acknowledge receipt of messages they receive. This 220 is done by sending an Acknowledge control frame with the sequence 221 number of the last message reliably received. When a sending 222 endpoint receives an Acknowledge control frame from its receiving 223 endpoint, the sending endpoint can delete from its message recovery 224 window all messages with sequence numbers less than or equal to the 225 Acknowledge sequence number. 227 If an MBWS session abnormally terminates, both the client and server 228 should retain the state of the MBWS connection so that it can be 229 resynchronized and continued on a new session. The client of a 230 failed MBWS connection session has the option of reconnecting and 231 continuing the existing connection; or, creating a new connection. 232 Upon receipt of a new connection request, a server will clear the 233 state of an existing MBWS connection if such exists. Upon receipt of 234 reconnect request, a server will, if possible, resynchronize and 235 continue the existing connection. 237 2.1.4. MBWS Reconnect 239 A client requests a connection reconnect by sending a Connect frame 240 containing the name of the connection to be reconnected followed by a 241 list of three message sequence numbers. The first sequence number 242 (CSLR) is that of the last message the client has received. The 243 second (CSLW) and third (CSUW) sequence numbers define the respective 244 lower and upper bounds of the sequence numbers of the messages in the 245 client's retained message window. Upon receipt of this Connect 246 frame, the server determines if it can reconnect based on the 247 following criteria: 248 1. The connection name must match the client's current MBWS 249 connection name. 250 2. CSLR+1 must be the sequence number of a message the server can 251 reinitiate sending with (i.e. either the message with this 252 sequence number is in the connection's retained messsage window 253 or it is the sequence number of the next unsent message). 255 3. The message sequence number of the message the server last 256 received (SSLR) is in the range of CSLW-1 to CSUW. 258 If all three criteria are met the reconnect succeeds and the server 259 responds with a Connect frame containing the reconnected connection 260 name and one sequence number (SSLR) which is that of the last message 261 received by the server. Message transport then resumes with the 262 client sending the SSLR+1 message and the server sending the CSLR+1 263 message. 265 If the criteria are not met, the reconnect request fails and the 266 server treats it as though it were a connect request and responds 267 with a connect response. The client recognizes that its reconnect 268 request has been converted into a connect request because the 269 response contains a connection name that does not match that in the 270 client's reconnect request 272 2.1.5. MBWS Prepare-to-close 274 MBWS adds a Prepare-to-close phase that immediately precedes the 275 WebSocket close phase. This is done to allow both endpoints to 276 acknowledge the receipt of the last message sent to them prior to 277 initiating WebSocket close. The endpoints must retain the MBWS 278 connection state until the WebSocket close has completed. Once the 279 connection has entered the WebSocket close phase, the ability to 280 Reconnect is unreliable; however, by this point both endpoints have 281 acknowledged all messages sent and the failure of a Reconnect request 282 will not result in messages being lost or duplicated. The steps of 283 the MBWS Prepare-to-close phase are as follows: 284 1. Endpoint-1 sends a Prepare-to-close control frame which signals 285 that it has sent its last message and will initiate a WebSocket 286 close when the prepare-to-close phase is complete. 287 2. Endpoint-2 receives the Prepare-to-close control frame. It then 288 sends an Acknowledge control frame with the sequence number of 289 the last message it has received. This is done whether or not 290 this message sequence number has been acknowledged previously. 291 3. Endpoint-2 sends its last message, if any, followed by a Prepare- 292 to-close control frame. 293 4. Endpoint-1 receives the last messages in transit, if any, 294 followed by the Prepare-to-close control frame. It then sends an 295 Acknowledge control frame with the sequence number of the last 296 message it has received. This is done whether or not this 297 message sequence number has been acknowledged previously. 298 5. Endpoint-1 initiates a WebSocket close by sending a WebSocket 299 close control frame. 301 It is possible and acceptable that both endpoints initiate Prepare- 302 to-close at nearly the same time. If so, this may result in both 303 endpoints initiating a WebSocket close at nearly the same time. 305 2.1.6. MBLWS Connections 307 An MBLWS client does not use Connect, Acknowledge or Prepare-to-close 308 control frames. Message transport begins immediately after the 309 WebSocket upgrade request has been accepted by the server. MBLWS 310 does not support connection recovery. MBLWS connections do not span 311 WebSocket sessions. If an MBLWS connection's WebSocket session fails 312 or is closed, the connection is closed. 314 2.1.7. Message Metadata 316 MBWS and MBLWS define a message header containing three metadata 317 elements. In order, these are Address List, Content-Type and 318 Property List. 320 2.1.7.1. Address List 322 For messages sent by a client to a broker, the Address List contains 323 the list of destination Addresses to which to send the message. 324 Empty Addresses are ignored. For messages delivered by a message 325 broker to a client, Address List contains the single address from 326 which the message originated, .i.e if a client receives the same 327 message from multiple addresses it will receive each as a separate 328 message. 330 It is recommended but not required that address value be a URN. 332 The format and semantics of Address is message broker dependent and 333 is outside the scope of MBWS. For instance, some brokers may treat 334 Address as a strictly local name; other brokers may support a more 335 global form of addressing. Broker-specific message routing semantics 336 determine how a destination Address's messages are to be routed and 337 how message's origination Address is determined. This includes 338 defining the meaning of an empty destination Address List and an 339 empty origination Address. 341 2.1.7.1.1. Undeliverable Messages 343 A messages's Address may not be known to a broker. MBWS does not 344 define how such dead-letters are handled once they are received by a 345 message broker. MBWS requires a message broker to acknowledge every 346 message sent to it, whether or not it can deliver it. 348 2.1.7.2. Content-Type 350 Immediately following Address List, a message header contains a 351 Content-Type. Its value is a UTF-8 string containing the MIME 352 discrete type [RFC2045] that describes the message's content. 353 Content-Type may be empty. 355 2.1.7.3. Property List 357 Immediately following Content-Type, a message header contains a 358 Property List. This list contains zero or more Properties. Each 359 Property is a Name/Value pair with each being a UTF-8 string. MBWS 360 does not define the semantics of Properties. 362 3. Additional Issues 364 3.1. Sec-WebSocket-Protocol Field 366 Sec-WebSocket-Protocol Field Values 368 +------------------+ 369 | Value | 370 +------------------+ 371 | MBWS.huawei.com | 372 | MBLWS.huawei.com | 373 +------------------+ 375 WebSocket defines the subprotocol negotiation process. This starts 376 with a client including the Sec-WebSocket-Protocol Field with one or 377 more subprotocol names in its WebSocket upgrade request. The table 378 above specifies the values for the two subprotocols defined in this 379 document. 381 3.2. Client Identity 383 WebSocket uses the HTTP origin model to identify clients. MBWS uses 384 the same client identity model. 386 3.3. Message Security 388 WebSocket supports TLS and MBWS/MBLWS recommends, but does not 389 require, its use. In addition to providing better security, the use 390 of TLS and port 443 insures that MBWS connections avoid the overhead 391 and latency of having to traverse web proxies. 393 3.4. Empty Protocol Values 395 In several places, this document refers to an 'empty' UTF-8 string 396 element. In MBWS, UTF-8 string protocol elements are length- 397 delimited. An 'empty' element is one with a zero valued length 398 delimiter. 400 4. MBWS/MBLWS Protocol ABNF 402 mbws-frame = binary-frame / text-frame 403 ;the frame used with a WS binary message 404 binary-frame = 405 binary-connect-frame / binary-acknowledge-frame / binary-prepare-to-close-frame / binary-message-frame 406 binary-connect-frame = 407 binary-connect-frame-id binary-connection-name binary-message-sequence-number-list 408 binary-connect-frame-id = %x01 409 binary-connection-name = binary-string 410 binary-message-sequence-number-list = 411 binary-list-length *binary-message-sequence-number 412 binary-acknowledge-frame = 413 binary-acknowledge-frame-id binary-message-sequence-number 414 binary-acknowledge-frame-id = %x02 415 binary-message-sequence-number = varint 416 binary-prepare-to-close-frame = binary-prepare-to-close-frame-id 417 binary-prepare-to-close-frame-id = %x03 418 binary-message-frame = 419 binary-message-frame-id binary-message-header binary-message-body 420 binary-message-frame-id = %x03 421 binary-message-header = 422 binary-address-list binary-content-type binary-property-list 423 binary-address-list = binary-list-length *binary-address 424 binary-address = binary-string 425 binary-content-type = binary-string 426 binary-property-list = binary-list-length *binary-property 427 binary-property = binary-property-name binary-property-value 428 binary-property-name = binary-string 429 binary-property-value = binary-string 430 binary-message-body = *OCTET 431 ;the frame used with a WS text message 432 text-frame = 433 text-connect-frame / text-acknowledge-frame / text-prepare-to-close-frame / text-message-frame 434 text-connect-frame = 435 text-connect-frame-id text-connection-name text-message-sequence-number-list 436 text-connect-frame-id = %x31 SP 437 text-connection-name = text-string 438 text-message-sequence-number-list = 439 text-list-length *text-message-sequence-number 440 text-acknowledge-frame = 441 text-acknowledge-frame-id text-message-sequence-number 442 text-acknowledge-frame-id = %x32 SP 443 text-message-sequence-number = text-int 444 text-prepare-to-close-frame = text-prepare-to-close-frame-id 445 text-prepare-to-close-frame-id = %x33 SP 446 text-message-frame = 447 text-message-frame-id text-message-header text-message-body 448 text-message-frame-id = %x33 SP 449 text-message-header = 450 text-address-list text-content-type text-property-list 451 text-address-list = text-list-length *text-address 452 text-address = text-string 453 text-content-type = text-string 454 text-property-list = text-list-length *text-property 455 text-property = text-property-name text-property-value 456 text-property-name = text-string 457 text-property-value = text-string 458 text-message-body = UTF8-string 459 ;UTF8 encoded character string 460 UTF8-string = *(OCTET) 461 ;Google Protocol Buffers base 128 varint 462 varint = 1*8(OCTET) 463 ;the number of characters in a UTF8 string 464 binary-string-length = varint 465 binary-string = binary-string-length UTF8-string 466 ;the number of entries in a list 467 binary-list-length = varint 468 text-int = DIGIT *DIGIT SP 469 ;the number of characters in a UTF8 string 470 text-string-length = text-int 471 text-string = text-string-length UTF8-string 472 ;the number of entries in a list 473 text-list-length = text-int ;the number of entries in a list 475 Figure 1 477 5. Scenarios 479 5.1. MBWS Connection Recovery Scenario 481 1. Broker provides 'ws:' and/or 'wss:' URIs for accepting MBWS 482 connections. 483 2. Client establishes an HTTP session with Broker; identifies 484 itself using HTTP client origin; and, authenticates itself using 485 HTTP authentication. 487 3. If successful, Client requests HTTP upgrade to MBWS Subprotocol. 488 4. If upgrade successful, Client sends Connect frame with empty 489 connection name. 490 5. Broker responds with Connect frame containing a new connection 491 name. 492 6. Broker starts streaming messages to client; and, Client starts 493 streaming messages to Broker. 494 7. Client and Broker periodically acknowledge receipt of each 495 other's messages using Acknowledge control frames. 496 8. Client or Broker may initiate session close as defined by 497 WebSocket. 498 9. If session abnormally terminates, client recovers connection by 499 executing (1) through (3) and then continues with (10) 500 10. Client sends Connect frame containing the connection name it 501 wishes to recover and the CSLR, CSLW and CSUW message sequence 502 numbers. 503 11. Broker responds with Connect frame. If Connect frame contains a 504 new connection name, broker has rejected recovery and opened a 505 new connection, processing continues with (6). If Connect frame 506 contains the recovery connection name and SSLR sequence number, 507 Broker has accepted recovery. 508 12. Processing continues at (6) with the Client initiating sending 509 with the SSLR+1 message; and, the Broker initiating sending with 510 the CSLR+1 message. 512 5.2. MBLWS Session Scenario 514 1. Broker provides 'ws:' and/or 'wss:' URIs for accepting MBLWS 515 sessions. 516 2. Client establishes an HTTP session with Broker; identifies itself 517 using HTTP client origin; and, authenticates itself using HTTP 518 authentication. 519 3. If successful, Client requests HTTP upgrade to MBWS Subprotocol. 520 4. If upgrade successful, Broker starts streaming available messages 521 to client; and, Client starts streaming messages to Broker. 522 5. Client or Broker may initiate session close as defined by 523 WebSocket. 525 6. Issues Outside the Scope of this Document 527 _This section is non-normative._ 529 6.1. Messaging Scope 531 Message brokers provide message-broker-specific functionality for 532 routing, queueing, forwarding, filtering, transporting, etc. 533 messages. This results in the broker delivering specific messages to 534 specific clients. This document defines how a message broker uses 535 the subprotocols defined here to transport messages to/from a client. 536 All other message broker functionality is outside the scope of this 537 document. 539 6.2. Message Acknowledgement Interval 541 The parties of an MBWS connection decide when to send Acknowledge 542 control frames. Typically these are sent after some number of 543 messages have been received or some time interval has elapsed within 544 which at least one message has been received. The choice of 545 acknowledgement interval is outside the scope of this document. 547 6.3. Synchronous Messaging 549 Message brokers have a history of supporting synchronous messaging 550 where clients make blocking calls to send and to receive messages. 551 WebSocket and MBWS are natively asynchronous messaging protocols. 552 MBWS is optimized for asynchronous, full duplex message transport. 553 It has not been designed for synchronous messaging. 555 6.4. End-to-End Reliability 557 The responsibility for reliable message delivery over a MBWS 558 connection is not the responsibility of the message broker alone - it 559 is only achieved when both clients and brokers implement recovery of 560 MBWS connections. The degree to which clients and message brokers 561 are able to recover from failure is outside the scope of this 562 document. 564 7. References 566 [I-D.ietf-hybi-thewebsocketprotocol] 567 Fette, I. and A. Melnikov, "The WebSocket protocol", 568 draft-ietf-hybi-thewebsocketprotocol-17 (work in 569 progress), September 2011. 571 [GPBE] "Google Protocol Buffers Encoding ". 574 [RFC2045] Freed, N. and Borenstein, N., "Multipurpose Internet Mail 575 Extensions (MIME) Part One: Format of Internet Message 576 Bodies", November 1966. 578 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 579 Specifications: ABNF", January 2008. 581 Authors' Addresses 583 Mark Hapner (editor) 584 Huawei 586 Email: mhapner@huawei.com 588 Clebert Suconic 589 redhat 591 Email: csuconic@redhat.com