idnits 2.17.1 draft-ietf-xmpp-websocket-09.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 (August 11, 2014) is 3543 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) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** 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: February 12, 2015 Mozilla 6 E. Cestari 7 cstar industries 8 August 11, 2014 10 An XMPP Sub-protocol for WebSocket 11 draft-ietf-xmpp-websocket-09 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 February 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 7.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 79 Appendix B. XML Schema . . . . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 web origin 467 of the WebSocket endpoint, the Web-host metadata MAY be used to 468 establish trust between the XMPP server domain and the WebSocket 469 endpoint as long as the host-meta request and response occurred over 470 secure HTTP; this is especially relevant in multi-tenant situations 471 where the same WebSocket endpoint is serving multiple XMPP domains 472 (e.g., the XMPP service domains for both "example.com" and 473 "im.example.org" might be serviced by the same WebSocket endpoint at 474 "hosting.example.net"). See Section 6 for related discussion. 476 5. IANA Considerations 478 5.1. WebSocket Subprotocol Name 480 This specification requests IANA to register the WebSocket XMPP sub- 481 protocol under the "WebSocket Subprotocol Name" Registry with the 482 following data: 484 Subprotocol Identifier: xmpp 486 Subprotocol Common Name: WebSocket Transport for the Extensible 487 Messaging and Presence Protocol (XMPP) 489 Subprotocol Definition: this document 491 5.2. URN Sub-Namespace 493 A URN sub-namespace for framing of Extensible Messaging and Presence 494 Protocol (XMPP) streams is defined as follows. 496 URI: urn:ietf:params:xml:ns:xmpp-framing 498 Specification: this document 500 Description: This is the XML namespace name for framing of 501 Extensible Messaging and Presence Protocol (XMPP) streams as 502 defined by RFC XXXX. 504 Registrant Contact: IESG 506 6. Security Considerations 508 Since application level TLS cannot be used (see Section 3.9), 509 applications need to protect the privacy of XMPP traffic at the 510 WebSocket or other appropriate layer. 512 Browser-based applications are not able to inspect and verify, at the 513 application layer, the certificate used for the WebSocket connection 514 to ensure that it corresponds to the domain specified as the 'to' 515 address of the XMPP stream. There are two cases: 517 1. If the XMPP service domain matches the origin for the WebSocket 518 connection, the relevant check is already performed by the 519 browser. For example, the XMPP service domain might be 520 "foo.example" and the WebSocket endpoint discovered for the link 521 relation type of "urn:xmpp:alt-connections:websocket" might be 522 "wss://foo.example/websocket". As long as the certificate 523 provided over WebSocket or HTTPS is verified according to the 524 rules defined for secure HTTP [RFC2818], then the browser will 525 report the successful establishment of a secure connection to the 526 application. (However, as noted, the application is still not 527 able to independently inspect and verify the certificate, and 528 needs to trust the browser; this is a limitation of existing 529 browser technologies, and thus cannot be worked around by 530 WebSocket applications.) 532 2. In situations where the domain of the XMPP server does not match 533 the web origin of the WebSocket endpoint (such as multi-tenant 534 hosting situations, the host-meta process described under 535 Section 4) MAY be used to delegate trust from the XMPP server 536 domain to the WebSocket origin, as long as the host-meta request 537 and response occurred over secure HTTP (with appropriate 538 certificate verification as defined in [RFC2818]). 540 When presented with a new WebSocket endpoint via the 'see-other-uri' 541 attribute of a element, clients MUST NOT accept the 542 suggestion if the security context of the new endpoint is lower than 543 the current one in order to prevent downgrade attacks from a 'wss://' 544 endpoint to 'ws://'. 546 The Security Considerations for both WebSocket (see Section 10 of 547 [RFC6455]) and XMPP (see Section 13 of [RFC6120]) apply to the 548 WebSocket XMPP sub-protocol. 550 7. References 552 7.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 559 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 561 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 562 Protocol (XMPP): Core", RFC 6120, March 2011. 564 [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC 565 6415, October 2011. 567 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 568 6455, December 2011. 570 7.2. Informative References 572 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 573 specifying the location of services (DNS SRV)", RFC 2782, 574 February 2000. 576 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 577 Protocol (XMPP): Instant Messaging and Presence", RFC 578 6121, March 2011. 580 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 581 "Known Issues and Best Practices for the Use of Long 582 Polling and Streaming in Bidirectional HTTP", RFC 6202, 583 April 2011. 585 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 586 2011. 588 [XEP-0124] 589 Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., and 590 L. Stout, "Bidirectional-streams Over Synchronous HTTP 591 (BOSH)", XSF XEP 0124, November 2013. 593 [XEP-0156] 594 Hildebrand, J., Saint-Andre, P., and L. Stout, 595 "Discovering Alternative XMPP Connection Methods", XSF XEP 596 0156, January 2014. 598 [XEP-0198] 599 Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F., 600 Cridland, D., and M. Wild, "Stream Management", XSF XEP 601 0198, June 2011. 603 [XEP-0199] 604 Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009. 606 [XEP-0206] 607 Paterson, I., Saint-Andre, P., and L. Stout, "XMPP Over 608 BOSH", XSF XEP 0206, November 2013. 610 [XML-SCHEMA] 611 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, 612 "XML Schema Part 1: Structures Second Edition", World Wide 613 Web Consortium Recommendation REC-xmlschema-1-20041028, 614 October 2004, 615 . 617 Appendix A. Acknowledgements 619 The authors wish to thank the following individuals for their 620 feedback: Andreas Guth, Bjoern Hoerhmann, Dave Cridland, Florian 621 Zeitz, Kurt Zeilenga, Matt Miller, Matthew Wild, Paul Aurich, Sergey 622 Dobrov, Waqas Hussain. 624 Dan Romascanu reviewed the document on behalf of the General Area 625 Review Team. 627 During IESG review, Barry Leiba Benoit Claise, Dan Romasanu, Jari 628 Arkko, Juergen Schoenwaelder, Spencer Dawkins, Stephen Farrell, Ted 629 Lemon, Kathleen Moriarty, Pete Resnick caught several issues that 630 needed to be addressed. 632 The authors gratefully acknowledge the assistance of Peter Saint- 633 Andre as document shepherd, Ben Campbell and Joe Hildebrand as the 634 working group chairs, and Richard Barnes as the sponsoring Area 635 Director. 637 Appendix B. XML Schema 639 The following schema formally defines the 'urn:ietf:params:xml:ns 640 :xmpp-framing' namespace used in this document, in conformance with 641 W3C XML Schema [XML-SCHEMA]. Because validation of XML streams and 642 stanzas is optional, this schema is not normative and is provided for 643 descriptive purposes only. 645 646 652 653 654 655 656 658 660 662 664 666 667 668 669 671 672 673 674 675 677 679 681 683 685 687 688 689 690 692 693 694 695 696 698 700 Authors' Addresses 702 Lance Stout (editor) 703 &yet 705 Email: lance@andyet.net 707 Jack Moffitt 708 Mozilla 710 Email: jack@metajack.im 712 Eric Cestari 713 cstar industries 715 Email: eric@cstar.io