idnits 2.17.00 (12 Aug 2021) /tmp/idnits5679/draft-ietf-xmpp-websocket-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2014) is 2804 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) ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP Working Group L. Stout, Ed. 3 Internet-Draft &yet 4 Intended status: Standards Track J. Moffitt 5 Expires: March 14, 2015 Mozilla 6 E. Cestari 7 cstar industries 8 September 10, 2014 10 An XMPP Sub-protocol for WebSocket 11 draft-ietf-xmpp-websocket-10 13 Abstract 15 This document defines a binding for the XMPP protocol over a 16 WebSocket transport layer. A WebSocket binding for XMPP provides 17 higher performance than the current HTTP binding for XMPP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 14, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. XMPP Sub-Protocol . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. WebSocket Messages . . . . . . . . . . . . . . . . . . . 4 58 3.3. XMPP Framing . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3.1. Framed XML Stream . . . . . . . . . . . . . . . . . . 5 60 3.3.2. Framed Stream Namespace . . . . . . . . . . . . . . . 5 61 3.3.3. Stream Frames . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Stream Initiation . . . . . . . . . . . . . . . . . . . . 6 63 3.5. Stream Errors . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Closing the Connection . . . . . . . . . . . . . . . . . 7 65 3.6.1. see-other-uri . . . . . . . . . . . . . . . . . . . . 8 66 3.7. Stream Restarts . . . . . . . . . . . . . . . . . . . . . 9 67 3.8. Pings and Keepalives . . . . . . . . . . . . . . . . . . 9 68 3.9. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.10. Stream Management . . . . . . . . . . . . . . . . . . . . 10 70 4. Discovering the WebSocket Connection Method . . . . . . . . . 10 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. WebSocket Subprotocol Name . . . . . . . . . . . . . . . 11 73 5.2. URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 7.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 79 Appendix B. XML Schema . . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 To date, applications using the Extensible Messaging and Presence 85 Protocol (XMPP) (see [RFC6120] and [RFC6121]) on the Web have made 86 use of BOSH (see [XEP-0124] and [XEP-0206]), an XMPP binding to HTTP. 87 BOSH is based on the HTTP long polling technique, and it suffers from 88 high transport overhead compared to XMPP's native binding to TCP. In 89 addition, there are a number of other known issues with long polling 90 [RFC6202], which have an impact on BOSH-based systems. 92 It would be much better in most circumstances to avoid tunneling XMPP 93 over HTTP long polled connections and instead use the XMPP protocol 94 directly. However, the APIs and sandbox that browsers have provided 95 do not allow this. The WebSocket protocol [RFC6455] exists to solve 96 these kinds of problems and is a bidirectional protocol that provides 97 a simple message-based framing layer, allowing for more robust and 98 efficient communication in web applications. 100 The WebSocket protocol enables two-way communication between a client 101 and a server, effectively emulating TCP at the application layer and 102 therefore overcoming many of the problems with existing long-polling 103 techniques for bidirectional HTTP. This document defines a WebSocket 104 sub-protocol for XMPP. 106 The WebSocket binding for XMPP is designed for use by browser-based 107 applications (e.g., XMPP clients written in JavaScript). These 108 applications typically are used to access the same information and 109 communication opportunities (e.g., the same XMPP "roster" of 110 contacts) as clients that access connect to an XMPP server over the 111 TCP binding defined in [RFC6120]. Although the only essential 112 difference is the underlying transport binding, relevant implications 113 (e.g., framing methods and discovery processes) are highlighted in 114 this specification. 116 2. Terminology 118 The basic unit of framing in the WebSocket protocol is called a 119 message. In XMPP, the basic unit is the stanza, which is a subset of 120 the first-level children of each document in an XMPP stream (see 121 Section 9 of [RFC6120]). XMPP also has a concept of messages, which 122 are stanzas with a top-level element of . In this 123 document, the word "message" will mean a WebSocket message, not an 124 XMPP message stanza, unless otherwise noted. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 3. XMPP Sub-Protocol 133 3.1. Handshake 135 The XMPP sub-protocol is used to transport XMPP over a WebSocket 136 connection. The client and server agree to this protocol during the 137 WebSocket handshake (see Section 1.3 of [RFC6455]). 139 During the WebSocket handshake, the client MUST include the value 140 'xmpp' in the list of protocols for the 'Sec-WebSocket-Protocol' 141 header. The reply from the server MUST also contain 'xmpp' in its 142 own 'Sec-WebSocket-Protocol' header in order for an XMPP sub-protocol 143 connection to be established. 145 If a client receives a handshake response that does not include 146 'xmpp' in the 'Sec-WebSocket-Protocol' header, then a XMPP sub- 147 protocol WebSocket connection was not established and the client MUST 148 close the WebSocket connection. 150 Once the handshake has successfully completed, WebSocket messages 151 sent or received MUST conform to the protocol defined in the rest of 152 this document. 154 The following is an example of a WebSocket handshake, followed by 155 opening an XMPP stream: 157 C: GET /xmpp-websocket HTTP/1.1 158 Host: example.com 159 Upgrade: websocket 160 Connection: Upgrade 161 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 162 Origin: http://example.com 163 ... 164 Sec-WebSocket-Protocol: xmpp 165 Sec-WebSocket-Version: 13 167 S: HTTP/1.1 101 Switching Protocols 168 Upgrade: websocket 169 Connection: Upgrade 170 ... 171 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 172 Sec-WebSocket-Protocol: xmpp 174 [WebSocket connection established] 176 C: 180 S: 186 3.2. WebSocket Messages 188 Data frame messages in the XMPP sub-protocol MUST be of the text type 189 and contain UTF-8 encoded data. 191 3.3. XMPP Framing 193 The framing method for the binding of XMPP to WebSocket differs from 194 the framing method for the TCP binding as defined in [RFC6120]; in 195 particular, the WebSocket binding adopts the message framing provided 196 by WebSocket to delineate the stream open and close headers, stanzas, 197 and other top-level stream elements. 199 3.3.1. Framed XML Stream 201 The start of a framed XML stream is marked by the use of an opening 202 "stream header" which is an element with the appropriate 203 attributes and namespace declarations (see Section 3.3.2). The 204 attributes of the element are the same as those of the 205 element defined defined for the 'http://etherx.jabber.org/ 206 streams' namespace in [RFC6120] and with the same semantics and 207 restrictions. 209 The end of a framed XML stream is denoted by the closing "stream 210 header" which is a element with its associated attributes 211 and namespace declarations (see Section 3.3.2). 213 The introduction of the and elements is motivated by 214 the parsable XML document framing restriction in Section 3.3.3. As a 215 consequence, note that a framed XML stream does not provided a 216 wrapping element encompassing the entirety of the 217 XML stream, as in [RFC6120]. 219 3.3.2. Framed Stream Namespace 221 The XML stream "headers" (the and elements) MUST be 222 qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing' (the 223 "framed stream namespace"). If this rule is violated, the entity 224 that receives the offending stream header MUST close the stream with 225 an error, which MUST be (see Section 4.9.3.10 of 226 [RFC6120]). 228 3.3.3. Stream Frames 230 The individual frames of a framed XML stream have a one-to-one 231 correspondence with WebSocket messages, and MUST be parsable as 232 standalone XML documents, complete with all relevant namespace and 233 language declarations. The inclusion of XML declarations, however, 234 is NOT RECOMMENDED, as WebSocket messages are already mandated to be 235 UTF-8 encoded. Inclusions of declarations would only add a constant 236 size overhead to each message. 238 The first character of each frame MUST be a '<' character. 240 Every XMPP stanza or other XML element (including the stream open and 241 close headers) sent directly over the XML stream MUST be sent in its 242 own frame. 244 Example of a WebSocket message that contains an independently 245 parsable XML document: 247 248 Every WebSocket message is parsable by itself. 249 251 Note that for stream features and errors, there is no parent context 252 element providing the "stream" namespace prefix as in [RFC6120], and 253 thus the stream prefix MUST be declared or use an unprefixed form: 255 256 257 259 -- OR -- 261 262 263 265 3.4. Stream Initiation 267 The first message sent after the WebSocket opening handshake MUST be 268 from the initiating entity, and MUST be an element qualified 269 by the 'urn:ietf:params:xml:ns:xmpp-framing' namespace and with the 270 same attributes mandated for the opening tag as described in 271 Section 4.7 of [RFC6120]. 273 The receiving entity MUST respond with either an element 274 (whose attributes match those described in Section 4.7 of [RFC6120]) 275 or a element (see Section 3.6.1). 277 An example of a successful stream initiation exchange: 279 C: 283 S: 289 Clients MUST NOT multiplex XMPP streams over the same WebSocket. 291 3.5. Stream Errors 293 Stream level errors in XMPP are fatal. Should such an error occur, 294 the server MUST send the stream error as a complete element in a 295 message to the client. 297 If the error occurs during the opening of a stream, the server MUST 298 send the initial open element response, followed by the stream level 299 error in a second WebSocket message frame. The server MUST then 300 close the connection as specified in Section 3.6. 302 3.6. Closing the Connection 304 The closing process for the XMPP sub-protocol mirrors that of the 305 XMPP TCP binding as defined in Section 4.4 of [RFC6120], except that 306 a element is used instead of the ending 307 tag. 309 Either the server or the client may close the connection at any time. 310 Before closing the connection, the closing party is expected to first 311 close the XMPP stream (if one has been opened) by sending a message 312 with the element, qualified by the "urn:ietf:params:xml:ns 313 :xmpp-framing" namespace. The stream is considered closed when a 314 corresponding element is received from the other party, and 315 the XMPP session is ended. 317 To then close the WebSocket connection, the closing party MUST 318 initiate the WebSocket closing handshake (see Section 7.1.2 of 319 [RFC6455]). 321 An example of ending an XMPP over WebSocket session by first closing 322 the XMPP stream layer and then the WebSocket connection layer: 324 Client (XMPP WSS) Server 325 | | | | 326 | | | | 329 | |<------------------------------------------------------------| | 330 | | | | 331 | | (XMPP Stream Closed) | | 332 | +-------------------------------------------------------------+ | 333 | | 334 | WS CLOSE FRAME | 335 |------------------------------------------------------------------>| 336 | WS CLOSE FRAME | 337 |<------------------------------------------------------------------| 338 | | 339 | (Connection Closed) | 340 +-------------------------------------------------------------------+ 342 If the WebSocket connection is closed or broken without the XMPP 343 stream having been closed first, then the XMPP stream is considered 344 implicitly closed and the XMPP session ended; however, if the use of 345 stream management resumption was negotiated (see [XEP-0198]), the 346 server SHOULD consider the XMPP session still alive for a period of 347 time based on server policy as specified in [XEP-0198]. 349 3.6.1. see-other-uri 351 If the server wishes at any point to instruct the client to move to a 352 different WebSocket endpoint (e.g., for load balancing purposes), 353 then a element is sent with the 'see-other-uri' attribute 354 set to the URI of the new connection endpoint (which MAY be for a 355 different transport method, such as BOSH (see [XEP-0124] and 356 [XEP-0206])). 358 Clients MUST NOT accept suggested endpoints with a lower security 359 context (e.g., moving from a 'wss://' endpoint to a 'ws://' or 'http: 360 //' endpoint). 362 An example of the server closing a stream and instructing the client 363 to connect at a different WebSocket endpoint: 365 S: 368 3.7. Stream Restarts 370 Whenever a stream restart is mandated (see Section 4.3.3 of 371 [RFC6120]), both the server and client streams are implicitly closed 372 and new streams MUST be opened, using the same process as in 373 Section 3.4. 375 The client MUST send a new stream element and MUST NOT send a 376 closing element. 378 An example of restarting the stream after successful SASL 379 negotiation: 381 S: 383 [Streams implicitly closed] 385 C: 389 3.8. Pings and Keepalives 391 Traditionally, XMPP servers and clients often send "whitespace 392 keepalives" (see Section 4.6.1 of [RFC6120]) between stanzas to 393 maintain an XML stream. However, for the XMPP sub-protocol each 394 message is required to start with a '<' character, and, as such, 395 whitespace keepalives MUST NOT be used. 397 As alternatives, the XMPP Ping extension [XEP-0199] and the XMPP 398 Stream Management extension [XEP-0198] provide pinging mechanisms. 399 Either of these extensions (or both) MAY be used to determine the 400 state of the connection. 402 Clients and servers MAY also use WebSocket ping control frames for 403 this purpose, but note that some environments, such as browsers, do 404 not provide access for generating or monitoring ping control frames. 406 3.9. Use of TLS 408 TLS cannot be used at the XMPP sub-protocol layer because the sub- 409 protocol does not allow for raw binary data to be sent. Instead, 410 when TLS is used, it MUST be enabled at the WebSocket layer using 411 secure WebSocket connections via the 'wss' URI scheme. (See 412 Section 10.6 of [RFC6455].) 414 Because TLS is to be provided outside of the XMPP sub-protocol layer, 415 a server MUST NOT advertise TLS as a stream feature (see Section 4.6 416 of [RFC6120]) when using the XMPP sub-protocol. Likewise, a client 417 MUST ignore any advertised TLS stream feature when using the XMPP 418 sub-protocol. 420 3.10. Stream Management 422 In order to alleviate the problems of temporary disconnections, the 423 client MAY use the XMPP Stream Management extension [XEP-0198] to 424 confirm when stanzas have been received by the server. 426 In particular, the client MAY use session resumption in [XEP-0198] to 427 recreate the same stream session state after a temporary network 428 unavailability or after navigating to a new URL in a browser. 430 4. Discovering the WebSocket Connection Method 432 Section 3 of [RFC6120] defines a procedure for connecting to an XMPP 433 server, including ways to discover the TCP/IP address and port of the 434 server using Domain Name System service (DNS SRV) records [RFC2782]. 435 When using the WebSocket binding as specified in this document 436 (instead of the TCP binding as specified in [RFC6120]), a client 437 needs an alternative way to discover information about the server's 438 connection methods, since web browsers and other WebSocket-capable 439 software applications typically cannot obtain such information from 440 the DNS. 442 The alternative lookup process uses Web Host Metadata [RFC6415] and 443 Web Linking [RFC5988], where the link relation type is "urn:xmpp:alt- 444 connections:websocket" as described in Discovering Alternate XMPP 445 Connection Methods [XEP-0156]. Conceptually, the host-meta lookup 446 process used for the WebSocket binding is analogous to the DNS SRV 447 lookup process used for the TCP binding. The process is as follows. 449 1. Send a request over secure HTTP to the path "/.well-known/host- 450 meta" at an HTTP origin [RFC6454] that matches the XMPP service 451 domain (e.g., a URL of "https://im.example.org/.well-known/host- 452 meta" if the XMPP service domain is "im.example.org"). 454 2. Retrieve a host-meta document specifying a link relation type of 455 "urn:xmpp:alt-connections:websocket", such as: 457 458 460 462 Servers MAY expose discovery information using host-meta documents, 463 and clients MAY use such information to determine the WebSocket 464 endpoint for a server. 466 In cases where the XMPP service domain does not match the discovered 467 web origin of the WebSocket endpoint, the Web-host metadata SHOULD be 468 used to establish trust between the XMPP server domain and the 469 WebSocket endpoint as long as the host-meta request and response 470 occurred over secure HTTP; this is especially relevant in multi- 471 tenant situations where the same WebSocket endpoint is serving 472 multiple XMPP domains (e.g., the XMPP service domains for both 473 "example.com" and "im.example.org" might be serviced by the same 474 WebSocket endpoint at "hosting.example.net"). See Section 6 for 475 related discussion. 477 5. IANA Considerations 479 5.1. WebSocket Subprotocol Name 481 This specification requests IANA to register the WebSocket XMPP sub- 482 protocol under the "WebSocket Subprotocol Name" Registry with the 483 following data: 485 Subprotocol Identifier: xmpp 487 Subprotocol Common Name: WebSocket Transport for the Extensible 488 Messaging and Presence Protocol (XMPP) 490 Subprotocol Definition: this document 492 5.2. URN Sub-Namespace 494 A URN sub-namespace for framing of Extensible Messaging and Presence 495 Protocol (XMPP) streams is defined as follows. 497 URI: urn:ietf:params:xml:ns:xmpp-framing 499 Specification: this document 501 Description: This is the XML namespace name for framing of 502 Extensible Messaging and Presence Protocol (XMPP) streams as 503 defined by RFC XXXX. 505 Registrant Contact: IESG 507 6. Security Considerations 509 The WebSocket binding for XMPP differs in several respects from the 510 TCP binding defined in [RFC6120]: 512 1. As described under Section 4 of this document, the method for 513 discovering a connection endpoint does not use DNS SRV records as 514 in the TCP binding, but instead uses Web Host Metadata files 515 retrieved via HTTPS from a URL at the XMPP service domain. From 516 a security standpoint, this is functionally equivalent to 517 resolution via DNS SRV records (and still relies on the DNS for 518 resolution of the XMPP source domain). 520 2. The method for authenticating a connection endpoint uses TLS 521 (typically with PKIX certificates) as in the TCP binding, but the 522 identity to be authenticated is the connection endpoint address 523 instead of the XMPP service domain; delegation from the XMPP 524 service domain to the connection endpoint address (if any) is 525 accomplished via the discovery method described under Section 4. 526 Thus the connection endpoint is still authenticated, and the 527 delegation is secure as long as the Web Host Metadata file is 528 retrieved via HTTPS. However, note that in practice this option 529 might not be employed when user agents are configured or deployed 530 for a particular delegated domain. 532 3. The framing method described under Section 3.3 follows the 533 WebSocket pattern by sending one top-level XML element per 534 WebSocket message, instead of using streaming XML as in the TCP 535 binding. However, the framing method has no impact on the 536 security properties of an XMPP session (e.g., end-to-end 537 encryption of XML stanzas can be accomplished just as easily with 538 WebSocket framing as with streaming XML). 540 4. In all other respects (e.g., user authentication via SASL, 541 allowable characters in XMPP addresses, and re-use of various 542 technologies such as Base 64, SASL mechanisms, UTF-8, and XML), 543 the WebSocket binding does not differ from the TCP binding, and 544 thus does not modify the security properties of the protocol. In 545 all these respects, the security considerations of [RFC6120] 546 apply directly to the WebSocket binding. 548 In order to ensure that communications over the WebSocket binding are 549 as secure as communications over the TCP binding, an operator needs 550 to (1) serve the Web Host Metadata file for the XMPP service domain 551 over secure HTTP ('https' URIs) only, (2) configure the WebSocket 552 connection endpoint to use Transport Layer Security ('wss' URIs) 553 only, and (3) deploy certificates that properly identify the XMPP 554 service domain and WebSocket connection endpoint for usages (1) and 555 (2), respectively. 557 Since application level TLS cannot be used (see Section 3.9), 558 applications need to protect the privacy of XMPP traffic at the 559 WebSocket or other appropriate layer. 561 Browser-based applications are not able to inspect and verify, at the 562 application layer, the certificate used for the WebSocket connection 563 to ensure that it corresponds to the domain specified as the 'to' 564 address of the XMPP stream. There are two cases: 566 1. If the XMPP service domain matches the origin for the WebSocket 567 connection, the relevant check is already performed by the 568 browser. For example, the XMPP service domain might be 569 "foo.example" and the WebSocket endpoint discovered for the link 570 relation type of "urn:xmpp:alt-connections:websocket" might be 571 "wss://foo.example/websocket". As long as the certificate 572 provided over WebSocket or HTTPS is verified according to the 573 rules defined for secure HTTP [RFC2818], then the browser will 574 report the successful establishment of a secure connection to the 575 application. (However, as noted, the application is still not 576 able to independently inspect and verify the certificate, and 577 needs to trust the browser; this is a limitation of existing 578 browser technologies, and thus cannot be worked around by 579 WebSocket applications.) 581 2. In situations where the user agent has to deal with delegation 582 and the domain of the XMPP server does not match the web origin 583 of the WebSocket endpoint (such as multi-tenant hosting 584 situations), the host-meta process described under Section 4 585 SHOULD be used to delegate trust from the XMPP server domain to 586 the WebSocket origin, as long as the host-meta request and 587 response occurred over secure HTTP (with appropriate certificate 588 verification as defined in [RFC2818]). 590 When presented with a new WebSocket endpoint via the 'see-other-uri' 591 attribute of a element, clients MUST NOT accept the 592 suggestion if the security context of the new endpoint is lower than 593 the current one in order to prevent downgrade attacks from a 'wss://' 594 endpoint to 'ws://'. 596 The Security Considerations for both WebSocket (see Section 10 of 597 [RFC6455]) and XMPP (see Section 13 of [RFC6120]) apply to the 598 WebSocket XMPP sub-protocol. 600 7. References 602 7.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 609 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 611 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 612 Protocol (XMPP): Core", RFC 6120, March 2011. 614 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC 615 6415, October 2011. 617 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 618 6455, December 2011. 620 7.2. Informative References 622 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 623 specifying the location of services (DNS SRV)", RFC 2782, 624 February 2000. 626 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 627 Protocol (XMPP): Instant Messaging and Presence", RFC 628 6121, March 2011. 630 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 631 "Known Issues and Best Practices for the Use of Long 632 Polling and Streaming in Bidirectional HTTP", RFC 6202, 633 April 2011. 635 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 636 2011. 638 [XEP-0124] 639 Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., and 640 L. Stout, "Bidirectional-streams Over Synchronous HTTP 641 (BOSH)", XSF XEP 0124, November 2013. 643 [XEP-0156] 644 Hildebrand, J., Saint-Andre, P., and L. Stout, 645 "Discovering Alternative XMPP Connection Methods", XSF XEP 646 0156, January 2014. 648 [XEP-0198] 649 Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F., 650 Cridland, D., and M. Wild, "Stream Management", XSF XEP 651 0198, June 2011. 653 [XEP-0199] 654 Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009. 656 [XEP-0206] 657 Paterson, I., Saint-Andre, P., and L. Stout, "XMPP Over 658 BOSH", XSF XEP 0206, November 2013. 660 [XML-SCHEMA] 661 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, 662 "XML Schema Part 1: Structures Second Edition", World Wide 663 Web Consortium Recommendation REC-xmlschema-1-20041028, 664 October 2004, 665 . 667 Appendix A. Acknowledgements 669 The authors wish to thank the following individuals for their 670 feedback: Andreas Guth, Bjoern Hoerhmann, Dave Cridland, Florian 671 Zeitz, Kurt Zeilenga, Matt Miller, Matthew Wild, Paul Aurich, Sergey 672 Dobrov, Waqas Hussain. 674 Dan Romascanu reviewed the document on behalf of the General Area 675 Review Team. 677 During IESG review, Barry Leiba Benoit Claise, Dan Romasanu, Jari 678 Arkko, Juergen Schoenwaelder, Spencer Dawkins, Stephen Farrell, Ted 679 Lemon, Kathleen Moriarty, Pete Resnick caught several issues that 680 needed to be addressed. 682 The authors gratefully acknowledge the assistance of Peter Saint- 683 Andre as document shepherd, Ben Campbell and Joe Hildebrand as the 684 working group chairs, and Richard Barnes as the sponsoring Area 685 Director. 687 Appendix B. XML Schema 689 The following schema formally defines the 'urn:ietf:params:xml:ns 690 :xmpp-framing' namespace used in this document, in conformance with 691 W3C XML Schema [XML-SCHEMA]. Because validation of XML streams and 692 stanzas is optional, this schema is not normative and is provided for 693 descriptive purposes only. 695 696 702 703 704 705 706 708 710 712 714 716 717 718 719 721 722 723 724 725 727 729 731 733 735 737 738 739 740 742 743 744 745 746 748 750 Authors' Addresses 752 Lance Stout (editor) 753 &yet 755 Email: lance@andyet.net 757 Jack Moffitt 758 Mozilla 760 Email: jack@metajack.im 762 Eric Cestari 763 cstar industries 765 Email: eric@cstar.io