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