1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) L. Stout, Ed.
Request for Comments: 7395 &yet
Category: Standards Track J. Moffitt
ISSN: 2070-1721 Mozilla
E. Cestari
cstar industries
October 2014
<span class="h1">An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for</span>
<span class="h1">WebSocket</span>
Abstract
This document defines a binding for the Extensible Messaging and
Presence Protocol (XMPP) over a WebSocket transport layer. A
WebSocket binding for XMPP provides higher performance than the
current HTTP binding for XMPP.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7395">http://www.rfc-editor.org/info/rfc7395</a>.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Stout, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. XMPP Subprotocol ................................................<a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Handshake ..................................................<a href="#page-3">3</a>
<a href="#section-3.2">3.2</a>. WebSocket Messages .........................................<a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. XMPP Framing ...............................................<a href="#page-5">5</a>
<a href="#section-3.3.1">3.3.1</a>. Framed XML Stream ...................................<a href="#page-5">5</a>
<a href="#section-3.3.2">3.3.2</a>. Framed Stream Namespace .............................<a href="#page-5">5</a>
<a href="#section-3.3.3">3.3.3</a>. Stream Frames .......................................<a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Stream Initiation ..........................................<a href="#page-6">6</a>
<a href="#section-3.5">3.5</a>. Stream Errors ..............................................<a href="#page-7">7</a>
<a href="#section-3.6">3.6</a>. Closing the Connection .....................................<a href="#page-7">7</a>
<a href="#section-3.6.1">3.6.1</a>. see-other-uri .......................................<a href="#page-8">8</a>
<a href="#section-3.7">3.7</a>. Stream Restarts ............................................<a href="#page-9">9</a>
<a href="#section-3.8">3.8</a>. Pings and Keepalives .......................................<a href="#page-9">9</a>
<a href="#section-3.9">3.9</a>. Use of TLS .................................................<a href="#page-9">9</a>
<a href="#section-3.10">3.10</a>. Stream Management ........................................<a href="#page-10">10</a>
<a href="#section-4">4</a>. Discovering the WebSocket Connection Method ....................<a href="#page-10">10</a>
<a href="#section-5">5</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-5.1">5.1</a>. WebSocket Subprotocol Name ................................<a href="#page-11">11</a>
<a href="#section-5.2">5.2</a>. URN Sub-namespace .........................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-14">14</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-14">14</a>
<a href="#appendix-A">Appendix A</a>. XML Schema ............................................<a href="#page-16">16</a>
Acknowledgements ..................................................<a href="#page-17">17</a>
Authors' Addresses ................................................<a href="#page-18">18</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
To date, applications using the Extensible Messaging and Presence
Protocol (XMPP) (see [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] and [<a href="./rfc6121" title=""Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence"">RFC6121</a>]) on the Web have made
use of Bidirectional-streams Over Synchronous HTTP (BOSH) (see
[<a href="#ref-XEP-0124" title=""Bidirectional-streams Over Synchronous HTTP (BOSH)"">XEP-0124</a>] and [<a href="#ref-XEP-0206" title=""XMPP Over BOSH"">XEP-0206</a>]), an XMPP binding to HTTP. BOSH is based
on the HTTP "long polling" technique, and it suffers from high
transport overhead compared to XMPP's native binding to TCP. In
addition, there are a number of other known issues with long polling
[<a href="./rfc6202" title=""Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP"">RFC6202</a>] that have an impact on BOSH-based systems.
In most circumstances, it would be much better to avoid tunneling
XMPP over HTTP long-polled connections and instead use XMPP directly.
However, the APIs and sandbox that browsers have provided do not
allow this. The WebSocket protocol [<a href="./rfc6455" title=""The WebSocket Protocol"">RFC6455</a>] exists to solve these
<span class="grey">Stout, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
kinds of problems and is a bidirectional protocol that provides a
simple message-based framing layer, allowing for more robust and
efficient communication in web applications.
The WebSocket protocol enables two-way communication between a client
and a server, effectively emulating TCP at the application layer and,
therefore, overcoming many of the problems with existing long-polling
techniques for bidirectional HTTP. This document defines a WebSocket
subprotocol for XMPP.
The WebSocket binding for XMPP is designed for use by browser-based
applications (e.g., XMPP clients written in JavaScript). Typically,
these applications are used to access the same information and
communication opportunities (e.g., the same XMPP "roster" of
contacts) as clients that connect to an XMPP server over the TCP
binding defined in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]. Although the only essential difference
is the underlying transport binding, relevant implications (e.g.,
framing methods and discovery processes) are highlighted in this
specification.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The basic unit of framing in the WebSocket protocol is called a
"message". In XMPP, the basic unit is the stanza, which is a subset
of the first-level children of each document in an XMPP stream (see
<a href="./rfc6120#section-9">Section 9 of [RFC6120]</a>). XMPP also has a concept of messages, which
are stanzas with a top-level element of <message/>. In this
document, the word "message" will mean a WebSocket message, not an
XMPP message stanza (unless otherwise noted).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. XMPP Subprotocol</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Handshake</span>
The XMPP subprotocol is used to transport XMPP over a WebSocket
connection. The client and server agree to this protocol during the
WebSocket handshake (see <a href="./rfc6455#section-1.3">Section 1.3 of [RFC6455]</a>).
During the WebSocket handshake, the client MUST include the value
'xmpp' in the list of protocols for the 'Sec-WebSocket-Protocol'
header. The reply from the server MUST also contain 'xmpp' in its
own 'Sec-WebSocket-Protocol' header in order for an XMPP subprotocol
connection to be established.
<span class="grey">Stout, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
If a client receives a handshake response that does not include
'xmpp' in the 'Sec-WebSocket-Protocol' header, then an XMPP
subprotocol WebSocket connection was not established and the client
MUST close the WebSocket connection.
Once the handshake has successfully completed, WebSocket messages
sent or received MUST conform to the protocol defined in the rest of
this document.
The following is an example of a WebSocket handshake, followed by
opening an XMPP stream:
C: GET /xmpp-websocket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
...
Sec-WebSocket-Protocol: xmpp
Sec-WebSocket-Version: 13
S: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
...
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: xmpp
[WebSocket connection established]
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. WebSocket Messages</span>
Data frame messages in the XMPP subprotocol MUST be of the text type
and contain UTF-8 encoded data.
<span class="grey">Stout, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. XMPP Framing</span>
The framing method for the binding of XMPP to WebSocket differs from
the framing method for the TCP binding as defined in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]; in
particular, the WebSocket binding adopts the message framing provided
by WebSocket to delineate the stream open and close headers, stanzas,
and other top-level stream elements.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Framed XML Stream</span>
The start of a framed XML stream is marked by the use of an opening
"stream header", which is an <open/> element with the appropriate
attributes and namespace declarations (see <a href="#section-3.3.2">Section 3.3.2</a>). The
attributes of the <open/> element are the same as those of the
<stream/> element defined for the 'http://etherx.jabber.org/streams'
namespace [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] and with the same semantics and restrictions.
The end of a framed XML stream is denoted by the closing "stream
header", which is a <close/> element with its associated attributes
and namespace declarations (see <a href="#section-3.3.2">Section 3.3.2</a>).
The introduction of the <open/> and <close/> elements is motivated by
the parsable XML document framing restriction in <a href="#section-3.3.3">Section 3.3.3</a>. As a
consequence, note that a framed XML stream does not provide a
wrapping <stream:stream/> [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] element encompassing the entirety
of the XML stream.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Framed Stream Namespace</span>
The XML stream headers (the <open/> and <close/> elements) MUST be
qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing' (the
"framed stream namespace"). If this rule is violated, the entity
that receives the offending stream header MUST close the stream with
an error, which MUST be <invalid-namespace> (see <a href="./rfc6120#section-4.9.3.10">Section 4.9.3.10 of
[RFC6120]</a>).
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. Stream Frames</span>
The individual frames of a framed XML stream have a one-to-one
correspondence with WebSocket messages and MUST be parsable as
standalone XML documents, complete with all relevant namespace and
language declarations. The inclusion of XML declarations, however,
is NOT RECOMMENDED, as WebSocket messages are already mandated to be
UTF-8 encoded. Including declarations in each message would only
increase the framing overhead of each message.
The first character of each frame MUST be a '<' character.
<span class="grey">Stout, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
Every XMPP stanza or other XML element (including the stream open and
close headers) sent directly over the XML stream MUST be sent in its
own frame.
Example of a WebSocket message that contains an independently
parsable XML document:
<message xmlns="jabber:client" xml:lang="en">
<body>Every WebSocket message is parsable by itself.</body>
</message>
Note that for stream features and errors, there is no parent context
element providing the "stream" namespace prefix as in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>], and
thus the stream prefix MUST be declared or use an unprefixed form:
<stream:features xmlns:stream="http://etherx.jabber.org/streams">
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
</stream:features>
-- OR --
<error xmlns="http://etherx.jabber.org/streams">
<host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</error>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Stream Initiation</span>
The first message sent after the WebSocket opening handshake MUST be
from the initiating entity and MUST be an <open/> element qualified
by the 'urn:ietf:params:xml:ns:xmpp-framing' namespace and with the
same attributes mandated for the <stream> opening tag as described in
<a href="./rfc6120#section-4.7">Section 4.7 of [RFC6120]</a>.
The receiving entity MUST respond with either an <open/> element
(whose attributes match those described in <a href="./rfc6120#section-4.7">Section 4.7 of [RFC6120]</a>)
or a <close/> element (see <a href="#section-3.6.1">Section 3.6.1</a>).
<span class="grey">Stout, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
An example of a successful stream initiation exchange:
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
Clients MUST NOT multiplex XMPP streams over the same WebSocket.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Stream Errors</span>
Stream-level errors in XMPP are fatal. Should such an error occur,
the server MUST send the stream error as a complete element in a
message to the client.
If the error occurs during the opening of a stream, the server MUST
send the initial open element response, followed by the stream-level
error in a second WebSocket message frame. The server MUST then
close the connection as specified in <a href="#section-3.6">Section 3.6</a>.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Closing the Connection</span>
The closing process for the XMPP subprotocol mirrors that of the XMPP
TCP binding as defined in <a href="./rfc6120#section-4.4">Section 4.4 of [RFC6120]</a>, except that a
<close/> element is used instead of the ending </stream:stream> tag.
Either the server or the client may close the connection at any time.
Before closing the connection, the closing party is expected to first
close the XMPP stream (if one has been opened) by sending a message
with the <close/> element, qualified by the
"urn:ietf:params:xml:ns:xmpp-framing" namespace. The stream is
considered closed when a corresponding <close/> element is received
from the other party, and the XMPP session is ended.
To then close the WebSocket connection, the closing party MUST
initiate the WebSocket closing handshake (see <a href="./rfc6455#section-7.1.2">Section 7.1.2 of
[RFC6455]</a>).
<span class="grey">Stout, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
An example of ending an XMPP-over-WebSocket session by first closing
the XMPP stream layer and then the WebSocket connection layer:
Client (XMPP WSS) Server
| | | |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |------------------------------------------------------------>| |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |<------------------------------------------------------------| |
| | | |
| | (XMPP Stream Closed) | |
| +-------------------------------------------------------------+ |
| |
| WS CLOSE FRAME |
|------------------------------------------------------------------>|
| WS CLOSE FRAME |
|<------------------------------------------------------------------|
| |
| (Connection Closed) |
+-------------------------------------------------------------------+
If the WebSocket connection is closed or broken without the XMPP
stream having been closed first, then the XMPP stream is considered
implicitly closed and the XMPP session ended; however, if the use of
stream management resumption was negotiated (see [<a href="#ref-XEP-0198" title=""Stream Management"">XEP-0198</a>]), the
server SHOULD consider the XMPP session still alive for a period of
time based on server policy as specified in [<a href="#ref-XEP-0198" title=""Stream Management"">XEP-0198</a>].
<span class="h4"><a class="selflink" id="section-3.6.1" href="#section-3.6.1">3.6.1</a>. see-other-uri</span>
At any point, if the server wishes to instruct the client to move to
a different WebSocket endpoint (e.g., for load-balancing purposes),
then a <close/> element is sent with the 'see-other-uri' attribute
set to the URI of the new connection endpoint (which MAY be for a
different transport method, such as BOSH (see [<a href="#ref-XEP-0124" title=""Bidirectional-streams Over Synchronous HTTP (BOSH)"">XEP-0124</a>] and
[<a href="#ref-XEP-0206" title=""XMPP Over BOSH"">XEP-0206</a>])).
Clients MUST NOT accept suggested endpoints with a lower security
context (e.g., moving from a 'wss://' endpoint to a 'ws://' or
'http://' endpoint).
An example of the server closing a stream and instructing the client
to connect at a different WebSocket endpoint:
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
see-other-uri="wss://otherendpoint.example/xmpp-bind" />
<span class="grey">Stout, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Stream Restarts</span>
Whenever a stream restart is mandated (see <a href="./rfc6120#section-4.3.3">Section 4.3.3 of
[RFC6120]</a>), both the server and client streams are implicitly closed
and new streams MUST be opened, using the same process as in
<a href="#section-3.4">Section 3.4</a>.
The client MUST send a new stream <open/> element and MUST NOT send a
closing <close/> element.
An example of restarting the stream after successful Simple
Authentication and Security Layer (SASL) negotiation:
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
[Streams implicitly closed]
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Pings and Keepalives</span>
Traditionally, XMPP servers and clients often send "whitespace
keepalives" (see <a href="./rfc6120#section-4.6.1">Section 4.6.1 of [RFC6120]</a>) between stanzas to
maintain an XML stream. However, for the XMPP subprotocol each
message is required to start with a '<' character, and, as such,
whitespace keepalives MUST NOT be used.
As alternatives, the XMPP Ping extension [<a href="#ref-XEP-0199" title=""XMPP Ping"">XEP-0199</a>] and the XMPP
Stream Management extension [<a href="#ref-XEP-0198" title=""Stream Management"">XEP-0198</a>] provide pinging mechanisms.
Either of these extensions (or both) MAY be used to determine the
state of the connection.
Clients and servers MAY also use WebSocket ping control frames for
this purpose, but note that some environments, such as browsers, do
not provide access for generating or monitoring ping control frames.
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. Use of TLS</span>
Transport Layer Security (TLS) cannot be used at the XMPP subprotocol
layer because the subprotocol does not allow for raw binary data to
be sent. Instead, when TLS is used, it MUST be enabled at the
WebSocket layer using secure WebSocket connections via the 'wss' URI
scheme. (See <a href="./rfc6455#section-10.6">Section 10.6 of [RFC6455]</a>.)
<span class="grey">Stout, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
Because TLS is to be provided outside of the XMPP subprotocol layer,
a server MUST NOT advertise TLS as a stream feature (see <a href="./rfc6120#section-4.6">Section 4.6
of [RFC6120]</a>) when using the XMPP subprotocol. Likewise, a client
MUST ignore any advertised TLS stream feature when using the XMPP
subprotocol.
<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a>. Stream Management</span>
In order to alleviate the problems of temporary disconnections, the
client MAY use the XMPP Stream Management extension [<a href="#ref-XEP-0198" title=""Stream Management"">XEP-0198</a>] to
confirm when stanzas have been received by the server.
In particular, the client MAY use session resumption as described in
[<a href="#ref-XEP-0198" title=""Stream Management"">XEP-0198</a>] to recreate the same stream session state after a
temporary network unavailability or after navigating to a new URL in
a browser.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Discovering the WebSocket Connection Method</span>
<a href="./rfc6120#section-3">Section 3 of [RFC6120]</a> defines a procedure for connecting to an XMPP
server, including ways to discover the TCP/IP address and port of the
server using Domain Name System service (DNS SRV) records [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>].
When using the WebSocket binding as specified in this document
(instead of the TCP binding as specified in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]), a client
needs an alternative way to discover information about the server's
connection methods, since web browsers and other WebSocket-capable
software applications typically cannot obtain such information from
the DNS.
The alternative lookup process uses Web-host Metadata [<a href="./rfc6415" title=""Web Host Metadata"">RFC6415</a>] and
Web Linking [<a href="./rfc5988" title=""Web Linking"">RFC5988</a>], where the link relation type is
"urn:xmpp:alt-connections:websocket" as described in "Discovering
Alternative XMPP Connection Methods" [<a href="#ref-XEP-0156" title=""Discovering Alternative XMPP Connection Methods"">XEP-0156</a>]. Conceptually, the
host-meta lookup process used for the WebSocket binding is analogous
to the DNS SRV lookup process used for the TCP binding. The process
is as follows.
1. Send a request over secure HTTP to the path
"/.well-known/host-meta" at an HTTP origin [<a href="./rfc6454" title=""The Web Origin Concept"">RFC6454</a>] that matches
the XMPP service domain (e.g., a URL of
"https://im.example.org/.well-known/host-meta" if the XMPP
service domain is "im.example.org").
<span class="grey">Stout, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
2. Retrieve a host-meta document specifying a link relation type of
"urn:xmpp:alt-connections:websocket", such as:
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel="urn:xmpp:alt-connections:websocket"
href="wss://im.example.org:443/ws" />
</XRD>
Servers MAY expose discovery information using host-meta documents,
and clients MAY use such information to determine the WebSocket
endpoint for a server.
In cases where the XMPP service domain does not match the discovered
web origin of the WebSocket endpoint, the Web-host Metadata SHOULD be
used to establish trust between the XMPP server domain and the
WebSocket endpoint as long as the host-meta request and response
occurred over secure HTTP; this is especially relevant in multi-
tenant situations where the same WebSocket endpoint is serving
multiple XMPP domains (e.g., the XMPP service domains for both
"example.com" and "im.example.org" might be serviced by the same
WebSocket endpoint at "hosting.example.net"). See <a href="#section-6">Section 6</a> for
related discussion.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. WebSocket Subprotocol Name</span>
IANA has registered the WebSocket XMPP subprotocol in the "WebSocket
Subprotocol Name Registry", with the following data:
Subprotocol Identifier: xmpp
Subprotocol Common Name: WebSocket Transport for the Extensible
Messaging and Presence Protocol (XMPP)
Subprotocol Definition: this document
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. URN Sub-namespace</span>
A URN sub-namespace for framing of Extensible Messaging and Presence
Protocol (XMPP) streams is defined as follows.
URI: urn:ietf:params:xml:ns:xmpp-framing
Specification: this document
<span class="grey">Stout, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
Description: This is the XML namespace name for framing of
Extensible Messaging and Presence Protocol (XMPP) streams as
defined by <a href="./rfc7395">RFC 7395</a>.
Registrant Contact: IESG <iesg@ietf.org>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The WebSocket binding for XMPP differs in several respects from the
TCP binding defined in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]:
1. As described in <a href="#section-4">Section 4</a> of this document, the method for
discovering a connection endpoint does not use DNS SRV records as
in the TCP binding but instead uses Web-host Metadata files
retrieved via HTTPS from a URL at the XMPP service domain. From
a security standpoint, this is functionally equivalent to
resolution via DNS SRV records (and still relies on the DNS for
resolution of the XMPP source domain).
2. The method for authenticating a connection endpoint uses TLS
(typically with PKIX certificates) as in the TCP binding, but the
identity to be authenticated is the connection endpoint address
instead of the XMPP service domain; delegation from the XMPP
service domain to the connection endpoint address (if any) is
accomplished via the discovery method described in <a href="#section-4">Section 4</a>.
Thus, the connection endpoint is still authenticated, and the
delegation is secure as long as the Web-host Metadata file is
retrieved via HTTPS. However, note that, in practice, this
option might not be employed when user agents are configured or
deployed for a particular delegated domain.
3. The framing method described in <a href="#section-3.3">Section 3.3</a> follows the WebSocket
pattern by sending one top-level XML element per WebSocket
message, instead of using streaming XML as in the TCP binding.
However, the framing method has no impact on the security
properties of an XMPP session (e.g., end-to-end encryption of XML
stanzas can be accomplished just as easily with WebSocket framing
as with streaming XML).
4. In all other respects (e.g., user authentication via SASL,
allowable characters in XMPP addresses, and reuse of various
technologies such as Base 64, SASL mechanisms, UTF-8, and XML),
the WebSocket binding does not differ from the TCP binding and,
thus, does not modify the security properties of the protocol.
In all these respects, the security considerations of [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]
apply directly to the WebSocket binding.
<span class="grey">Stout, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
In order to ensure that communications over the WebSocket binding are
as secure as communications over the TCP binding, an operator needs
to (1) serve the Web-host Metadata file for the XMPP service domain
over secure HTTP ('https' URIs) only, (2) configure the WebSocket
connection endpoint to use TLS ('wss' URIs) only, and (3) deploy
certificates that properly identify the XMPP service domain and
WebSocket connection endpoint for usages (1) and (2), respectively.
Since application-level TLS cannot be used (see <a href="#section-3.9">Section 3.9</a>),
applications need to protect the privacy of XMPP traffic at the
WebSocket or other appropriate layer.
Browser-based applications are not able to inspect and verify, at the
application layer, the certificate used for the WebSocket connection
to ensure that it corresponds to the domain specified as the 'to'
address of the XMPP stream. There are two cases:
1. If the XMPP service domain matches the origin for the WebSocket
connection, the relevant check is already performed by the
browser. For example, the XMPP service domain might be
"foo.example", and the WebSocket endpoint discovered for the link
relation type of "urn:xmpp:alt-connections:websocket" might be
"wss://foo.example/websocket". As long as the certificate
provided over WebSocket or HTTPS is verified according to the
rules defined for secure HTTP [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>], then the browser will
report the successful establishment of a secure connection to the
application. (However, as noted, the application is still not
able to independently inspect and verify the certificate, and
needs to trust the browser; this is a limitation of existing
browser technologies and thus cannot be worked around by
WebSocket applications.)
2. In situations where the user agent has to deal with delegation
and the domain of the XMPP server does not match the web origin
of the WebSocket endpoint (such as multi-tenant hosting
situations), the host-meta process described in <a href="#section-4">Section 4</a> SHOULD
be used to delegate trust from the XMPP server domain to the
WebSocket origin, as long as the host-meta request and response
occurred over secure HTTP (with appropriate certificate
verification as defined in [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>]).
When presented with a new WebSocket endpoint via the 'see-other-uri'
attribute of a <close/> element, clients MUST NOT accept the
suggestion if the security context of the new endpoint is lower than
the current one in order to prevent downgrade attacks from a 'wss://'
endpoint to 'ws://'.
<span class="grey">Stout, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
The security considerations for both WebSocket (see <a href="./rfc6455#section-10">Section 10 of
[RFC6455]</a>) and XMPP (see <a href="./rfc6120#section-13">Section 13 of [RFC6120]</a>) apply to the
WebSocket XMPP subprotocol.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>, May 2000,
<<a href="http://www.rfc-editor.org/info/rfc2818">http://www.rfc-editor.org/info/rfc2818</a>>.
[<a id="ref-RFC5988">RFC5988</a>] Nottingham, M., "Web Linking", <a href="./rfc5988">RFC 5988</a>, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc5988">http://www.rfc-editor.org/info/rfc5988</a>>.
[<a id="ref-RFC6120">RFC6120</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", <a href="./rfc6120">RFC 6120</a>, March 2011,
<<a href="http://www.rfc-editor.org/info/rfc6120">http://www.rfc-editor.org/info/rfc6120</a>>.
[<a id="ref-RFC6415">RFC6415</a>] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", <a href="./rfc6415">RFC</a>
<a href="./rfc6415">6415</a>, October 2011,
<<a href="http://www.rfc-editor.org/info/rfc6415">http://www.rfc-editor.org/info/rfc6415</a>>.
[<a id="ref-RFC6455">RFC6455</a>] Fette, I. and A. Melnikov, "The WebSocket Protocol", <a href="./rfc6455">RFC</a>
<a href="./rfc6455">6455</a>, December 2011,
<<a href="http://www.rfc-editor.org/info/rfc6455">http://www.rfc-editor.org/info/rfc6455</a>>.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC2782">RFC2782</a>] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", <a href="./rfc2782">RFC 2782</a>,
February 2000, <<a href="http://www.rfc-editor.org/info/rfc2782">http://www.rfc-editor.org/info/rfc2782</a>>.
[<a id="ref-RFC6121">RFC6121</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", <a href="./rfc6121">RFC</a>
<a href="./rfc6121">6121</a>, March 2011,
<<a href="http://www.rfc-editor.org/info/rfc6121">http://www.rfc-editor.org/info/rfc6121</a>>.
[<a id="ref-RFC6202">RFC6202</a>] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", <a href="./rfc6202">RFC 6202</a>,
April 2011, <<a href="http://www.rfc-editor.org/info/rfc6202">http://www.rfc-editor.org/info/rfc6202</a>>.
[<a id="ref-RFC6454">RFC6454</a>] Barth, A., "The Web Origin Concept", <a href="./rfc6454">RFC 6454</a>,
December 2011, <<a href="http://www.rfc-editor.org/info/rfc6454">http://www.rfc-editor.org/info/rfc6454</a>>.
<span class="grey">Stout, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
[<a id="ref-XEP-0124">XEP-0124</a>] Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J.,
Stout, L., and W. Tilanus, "Bidirectional-streams Over
Synchronous HTTP (BOSH)", XSF XEP 0124, April 2014.
[<a id="ref-XEP-0156">XEP-0156</a>] Hildebrand, J., Saint-Andre, P., and L. Stout,
"Discovering Alternative XMPP Connection Methods",
XSF XEP 0156, January 2014.
[<a id="ref-XEP-0198">XEP-0198</a>] Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F.,
Cridland, D., and M. Wild, "Stream Management",
XSF XEP 0198, June 2011.
[<a id="ref-XEP-0199">XEP-0199</a>] Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009.
[<a id="ref-XEP-0206">XEP-0206</a>] Paterson, I., Saint-Andre, P., Stout, L., and W. Tilanus,
"XMPP Over BOSH", XSF XEP 0206, April 2014.
[<a id="ref-XML-SCHEMA">XML-SCHEMA</a>]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028">http://www.w3.org/TR/2004/REC-xmlschema-1-20041028</a>>.
<span class="grey">Stout, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. XML Schema</span>
The following schema formally defines the
'urn:ietf:params:xml:ns:xmpp-framing' namespace used in this
document, in conformance with W3C XML Schema [<a href="#ref-XML-SCHEMA">XML-SCHEMA</a>]. Because
validation of XML streams and stanzas is optional, this schema is not
normative and is provided for descriptive purposes only.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-framing'
xmlns='urn:ietf:params:xml:ns:xmpp-framing'
elementFormDefault='unqualified'>
<xs:element name='open'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<span class="grey">Stout, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
<xs:element name='close'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='see-other-uri' type='xs:anyURI'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Acknowledgements
The authors wish to thank the following individuals for their
feedback: Andreas Guth, Bjoern Hoerhmann, Dave Cridland, Florian
Zeitz, Kurt Zeilenga, Matt Miller, Matthew Wild, Paul Aurich, Sergey
Dobrov, and Waqas Hussain.
Dan Romascanu reviewed the document on behalf of the General Area
Review Team.
During IESG review, Barry Leiba, Benoit Claise, Dan Romascanu, Jari
Arkko, Juergen Schoenwaelder, Spencer Dawkins, Stephen Farrell, Ted
Lemon, Kathleen Moriarty, and Pete Resnick caught several issues that
needed to be addressed.
The authors gratefully acknowledge the assistance of Peter Saint-
Andre as document shepherd, Ben Campbell and Joe Hildebrand as the
working group chairs, and Richard Barnes as the sponsoring Area
Director.
<span class="grey">Stout, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7395">RFC 7395</a> XMPP over WebSocket October 2014</span>
Authors' Addresses
Lance Stout (editor)
&yet
EMail: lance@andyet.net
Jack Moffitt
Mozilla
EMail: jack@metajack.im
Eric Cestari
cstar industries
EMail: eric@cstar.io
Stout, et al. Standards Track [Page 18]
</pre>
|
