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
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
|
<pre>Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7247 &yet
Category: Standards Track A. Houri
ISSN: 2070-1721 IBM
J. Hildebrand
Cisco Systems, Inc.
May 2014
<span class="h1">Interworking between the Session Initiation Protocol (SIP) and the</span>
<span class="h1">Extensible Messaging and Presence Protocol (XMPP):</span>
<span class="h1">Architecture, Addresses, and Error Handling</span>
Abstract
As a foundation for the definition of bidirectional protocol mappings
between the Session Initiation Protocol (SIP) and the Extensible
Messaging and Presence Protocol (XMPP), this document specifies the
architectural assumptions underlying such mappings as well as the
mapping of addresses and error conditions.
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/rfc7247">http://www.rfc-editor.org/info/rfc7247</a>.
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Intended Audience ...............................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. Architectural Assumptions .......................................<a href="#page-4">4</a>
<a href="#section-5">5</a>. Interdomain Federation ..........................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. Address Mapping .................................................<a href="#page-7">7</a>
<a href="#section-6.1">6.1</a>. Overview ...................................................<a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Local Part Mapping .........................................<a href="#page-9">9</a>
<a href="#section-6.3">6.3</a>. Instance-Specific Mapping .................................<a href="#page-11">11</a>
<a href="#section-6.4">6.4</a>. SIP to XMPP ...............................................<a href="#page-11">11</a>
<a href="#section-6.5">6.5</a>. XMPP to SIP ...............................................<a href="#page-12">12</a>
<a href="#section-7">7</a>. Error Mapping ..................................................<a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. XMPP to SIP ...............................................<a href="#page-15">15</a>
<a href="#section-7.2">7.2</a>. SIP to XMPP ...............................................<a href="#page-17">17</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-20">20</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-21">21</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-21">21</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-22">22</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgements ......................................<a href="#page-24">24</a>
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The IETF has worked on two signaling technologies that can be used
for multimedia session negotiation, instant messaging, presence,
capabilities discovery, notifications, and other functions served by
real-time communication applications:
o The Session Initiation Protocol [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>], along with various SIP
extensions developed within the SIP for Instant Messaging and
Presence Leveraging Extensions (SIMPLE) Working Group.
o The Extensible Messaging and Presence Protocol [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>], along
with various XMPP extensions developed by the IETF as well as by
the XMPP Standards Foundation (XSF).
Because these technologies are widely deployed, it is important to
clearly define mappings between them for the sake of interworking.
This document provides the basis for a series of SIP-XMPP
interworking specifications by defining architectural assumptions,
address translation methods, and error condition mappings. Other
documents in this series define mappings for presence, messaging, and
media sessions.
The guidelines in this series are based on implementation and
deployment experience, and they describe techniques that have worked
well in the field with existing systems. In practice, interworking
has been achieved through direct protocol mappings, not through
mapping to an abstract model as described in, for example, [<a href="./rfc3859" title=""Common Profile for Presence (CPP)"">RFC3859</a>]
and [<a href="./rfc3860" title=""Common Profile for Instant Messaging (CPIM)"">RFC3860</a>]. Therefore, this series describes the direct mapping
approach in enough detail for developers of new implementations to
achieve practical interworking between SIP systems and XMPP systems.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Intended Audience</span>
The documents in this series are intended for use by software
developers who have an existing system based on one of these
technologies (e.g., SIP) and would like to enable communication from
that existing system to systems based on the other technology (e.g.,
XMPP). With regard to this document, we assume that readers are
familiar with the core specifications for both SIP and XMPP; with
regard to the other documents in this series, we assume that readers
are familiar with this document as well as with the relevant SIP and
XMPP extensions.
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
A number of terms used here are explained in [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] and [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>].
Several examples use the "XML Notation" from the Internationalized
Resource Identifier (IRI) specification [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>] to represent
Unicode characters outside the ASCII range (e.g., the string "ue"
stands for the Unicode character [<a href="#ref-UNICODE" title=""The Unicode Standard, Version 6.3"">UNICODE</a>] LATIN SMALL LETTER U WITH
DIAERESIS, U+00FC).
In architectural diagrams, SIP traffic is shown using arrows such as
"***>", whereas XMPP traffic is shown using arrows such as "...>".
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-4" href="#section-4">4</a>. Architectural Assumptions</span>
Protocol translation between SIP and XMPP could occur in a number of
different entities, depending on the architecture of real-time
communication deployments. For example, protocol translation could
occur within a multiprotocol server (which uses protocol-specific
connection managers to initiate traffic to and accept traffic from
clients or other servers natively using SIP/SIMPLE, XMPP, etc.),
within a multiprotocol client (which enables a user to establish
connections natively with various servers using SIP/SIMPLE, XMPP,
etc.), or within a gateway that acts as a dedicated protocol
translator (which takes one protocol as input and provides another
protocol as output).
This document assumes that the protocol translation will occur within
a gateway, specifically:
o When information needs to flow from an XMPP-based system to a SIP-
based system, protocol translation will occur within an "XMPP-to-
SIP gateway" that translates XMPP syntax and semantics on behalf
of an "XMPP server" (together, these two logical functions
comprise an "XMPP service").
o When information needs to flow from a SIP-based system to an XMPP-
based system, protocol translation will occur within a "SIP-to-
XMPP gateway" that translates SIP syntax and semantics on behalf
of a "SIP server" (together, these two logical functions comprise
a "SIP service").
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
Naturally, these logical functions could occur in one and the same
actual entity; we differentiate between them mainly for explanatory
purposes (although, in practice, such gateways are indeed fairly
common).
Note: This assumption is not meant to discourage protocol
translation within multiprotocol clients or servers; instead, this
assumption is followed mainly to clarify the discussion and
examples so that the protocol translation principles can be more
easily understood and can be applied by client and server
implementors with appropriate modifications to the examples and
terminology.
This document assumes that a gateway will translate directly from one
protocol to the other. For the sake of the examples, we further
assume that protocol translation will occur within a gateway in the
source domain, so that information generated by the user of an XMPP
system will be translated by a gateway within the trust domain of
that XMPP system, and information generated by the user of a SIP
system will be translated by a gateway within the trust domain of
that SIP system. However, nothing in this document ought to be taken
as recommending against protocol translation at the destination
domain.
An architectural diagram for a possible gateway deployment is shown
below, where the entities have the following significance and the "#"
character is used to show the boundary of a trust domain:
o romeo@example.net -- a SIP user.
o example.net -- a SIP server with an associated gateway ("S2X GW")
to XMPP.
o juliet@example.com -- an XMPP user.
o example.com -- an XMPP server with an associated gateway ("X2S
GW") to SIP.
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
#########################################################
# #
# +-----+ #
# | S2X | #
# +-------------+ GW |<...........>+-------------+ #
# | SIP Server +-----+ | XMPP Server | #
# | example.net | +-----+ example.com | #
# +-------------+<***********>| X2S +-------------+ #
# * | GW | : #
# * +-----+ : #
# * : #
# romeo@example.net juliet@example.com #
# #
#########################################################
Legend:
XMPP = ... or :
SIP = *
Figure 1: Possible Gateway Deployment Architecture
Note that bidirectional communication between the SIP server and the
XMPP server can be established over either SIP or XMPP. If the XMPP
user initiates the interaction, then the XMPP server would invoke its
XMPP-to-SIP gateway; thus, the communication would occur over SIP.
If the SIP user initiates the interaction, then the SIP server would
invoke its SIP-to-XMPP gateway; thus, the communication would occur
over XMPP.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Interdomain Federation</span>
The architectural assumptions underlying this document imply that
communication between a SIP system and an XMPP system will take place
using interdomain federation: the SIP server invokes its associated
SIP-to-XMPP gateway, which communicates with the XMPP server using
native XMPP server-to-server methods; similarly, the XMPP server
invokes its associated XMPP-to-SIP gateway, which communicates with
the SIP server using native SIP server-to-server methods.
When an XMPP server receives an XMPP stanza whose 'to' address
specifies or includes a domain other than the domain of the XMPP
server, it needs to determine whether the destination domain
communicates via XMPP or SIP. To do so, it performs one or more DNS
SRV lookups [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>] for "_xmpp-server" records as specified in
[<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]. If the response returns a hostname, the XMPP server can
attempt XMPP communication. If not, it can determine the appropriate
location for SIP communication at the target domain using the
procedures specified in [<a href="./rfc3263" title=""Session Initiation Protocol (SIP): Locating SIP Servers"">RFC3263</a>].
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
Similarly, when a SIP server receives a SIP message whose Request-URI
or To header specifies or includes a domain other than the domain of
the SIP server, it needs to determine whether the destination domain
communicates via SIP or XMPP. To do so, it uses the procedures
specified in [<a href="./rfc3263" title=""Session Initiation Protocol (SIP): Locating SIP Servers"">RFC3263</a>]. If that response returns a hostname, the SIP
server can attempt SIP communication. If not, it can perform one or
more DNS SRV lookups [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>] for "_xmpp-server" records as
specified in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>].
In both cases, the server in question might have previously
determined that the foreign domain communicates via SIP or XMPP, in
which case it would not need to perform the relevant DNS lookups.
The caching of such information is a matter of implementation and
local service policy and is therefore out of scope for this document.
Existing SIP and XMPP server implementations do not typically include
the ability to communicate using the other technology (XMPP for SIP
implementations, SIP for XMPP implementations). One common
architectural pattern is to associate a gateway with the core server
implementation (e.g., in XMPP such a gateway might be called a
"connection manager"). How exactly such a gateway interacts with the
core server to complete tasks such as address lookups and
communication with systems that use the other technology is a matter
of implementation (e.g., the gateway might be an add-on module that
is trusted by the core server to act as a fallback delivery mechanism
if the remote domain does not support the server's native
communication technology).
Because [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] specifies a binding of XMPP to TCP, a gateway from
SIP to XMPP will need to support TCP as the underlying transport
protocol. By contrast, as specified in [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>], either TCP or UDP
can be used as the underlying transport for SIP messages, and a given
SIP deployment might support only UDP; therefore, a gateway from XMPP
to SIP might need to communicate with a SIP server using either TCP
or UDP.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Address Mapping</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Overview</span>
The basic SIP address format is a 'sip' or 'sips' URI as specified in
[<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]. When a SIP entity supports extensions for instant
messaging it might be identified by an 'im' URI as specified in the
Common Profile for Instant Messaging [<a href="./rfc3860" title=""Common Profile for Instant Messaging (CPIM)"">RFC3860</a>] (see [<a href="./rfc3428" title=""Session Initiation Protocol (SIP) Extension for Instant Messaging"">RFC3428</a>]), and
when a SIP entity supports extensions for presence it might be
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
identified by a 'pres' URI as specified in the Common Profile for
Presence [<a href="./rfc3859" title=""Common Profile for Presence (CPP)"">RFC3859</a>] (see [<a href="./rfc3856" title=""A Presence Event Package for the Session Initiation Protocol (SIP)"">RFC3856</a>]). SIP entities typically also
support the 'tel' URI scheme [<a href="./rfc3966" title=""The tel URI for Telephone Numbers"">RFC3966</a>] and might support other URI
schemes as well.
The XMPP address format is specified in [<a href="./rfc6122" title=""Extensible Messaging and Presence Protocol (XMPP): Address Format"">RFC6122</a>] (although note that
XMPP URIs [<a href="./rfc5122" title=""Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)"">RFC5122</a>] are not used natively on the XMPP network); in
addition, [<a href="./rfc6121" title=""Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence"">RFC6121</a>] encourages instant messaging and presence
applications of XMPP to also support 'im' and 'pres' URIs as
specified in [<a href="./rfc3860" title=""Common Profile for Instant Messaging (CPIM)"">RFC3860</a>] and [<a href="./rfc3859" title=""Common Profile for Presence (CPP)"">RFC3859</a>], respectively, although such
support might simply involve leaving resolution of such addresses up
to an XMPP server.
In this document we primarily describe mappings for addresses of the
form <user@domain>; however, we also provide guidelines for mapping
the addresses of specific user agent instances, which take the form
of Globally Routable User Agent URIs (GRUUs) in SIP and
"resourceparts" in XMPP. Mapping of protocol-specific identifiers
(such as telephone numbers) is out of scope for this specification.
In addition, we have ruled the mapping of domain names as out of
scope for now, since that is a matter for the Domain Name System;
specifically, the issue for interworking between SIP and XMPP relates
to the translation of fully internationalized domain names (IDNs)
into non-internationalized domain names (IDNs are not allowed in the
SIP address format but are allowed in the XMPP address via
Internationalized Domain Names in Applications; see [<a href="./rfc6122" title=""Extensible Messaging and Presence Protocol (XMPP): Address Format"">RFC6122</a>] and
[<a href="#ref-XMPP-ADDRESS-FORMAT">XMPP-ADDRESS-FORMAT</a>]). Therefore, in the following sections we
focus primarily on the local part of an address (these are called
variously "usernames", "instant inboxes", "presentities", and
"localparts" in the protocols at issue), secondarily on the instance-
specific part of an address, and not at all on the domain-name part
of an address.
The 'sip'/'sips', 'im'/'pres', and XMPP address schemes allow
different sets of characters (although all three allow alphanumeric
characters and disallow both spaces and control characters). In some
cases, characters allowed in one scheme are disallowed in others;
these characters need to be mapped appropriately in order to ensure
interworking across systems.
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Local Part Mapping</span>
The local part of a 'sip'/'sips' URI inherits from the "userinfo"
rule in [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] with several changes; here we discuss the SIP
"user" rule only (using ABNF as defined in [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]):
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
Here we make the simplifying assumption that the local part of an
'im'/'pres' URI inherits from the "dot-atom-text" rule in [<a href="./rfc5322" title=""Internet Message Format"">RFC5322</a>]
rather than the more complicated "local-part" rule:
dot-atom-text = 1*atext *("." 1*atext)
atext = ALPHA / DIGIT / ; Any character except
"!" / "#" / "$" / ; controls, SP, and
"%" / "&" / "'" / ; specials. Used for
"*" / "+" / "-" / ; atoms.
"/" / "=" / "?" /
"^" / "_" / "`" /
"{" / "|" / "}" /
"~"
The local part of an XMPP address allows any ASCII character except
space, controls, and the " & ' / : < > @ characters.
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
To summarize the foregoing information, the following table lists the
allowed and disallowed characters in the local part of identifiers
for each protocol (aside from the alphanumeric, space, and control
characters), in order by hexadecimal character number (where each "A"
row shows the allowed characters and each "D" row shows the
disallowed characters).
+---+----------------------------------+
| SIP/SIPS CHARACTERS |
+---+----------------------------------+
| A | ! $ &'()*+,-./ ; = ? _ ~ |
| D | "# % : < > @[\]^ `{|} |
+---+----------------------------------+
| IM/PRES CHARACTERS |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| XMPP CHARACTERS |
+---+----------------------------------+
| A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ |
| D | " &' /: < > @ |
+---+----------------------------------+
Table 1: Allowed and Disallowed Characters
When transforming the local part of an address from one address
format to another, an application SHOULD proceed as follows:
1. Unescape any escaped characters in the source address (e.g., from
SIP to XMPP unescape "%23" to "#" per [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>], and from XMPP to
SIP unescape "\27" to "'" per [<a href="#ref-XEP-0106" title=""JID Escaping"">XEP-0106</a>]).
2. Leave unmodified any characters that are allowed in the
destination scheme.
3. Escape any characters that are allowed in the source scheme but
reserved in the destination scheme, as escaping is defined for
the destination scheme. In particular:
* Where the destination scheme is a URI (i.e., an 'im', 'pres',
'sip', or 'sips' URI), each reserved character MUST be
percent-encoded to "%hexhex" as specified in <a href="./rfc3986#section-2.5">Section 2.5 of
[RFC3986]</a> (e.g., when transforming from XMPP to SIP, encode
"#" as "%23").
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
* Where the destination scheme is a native XMPP address, each
reserved character MUST be encoded to "\hexhex" as specified
in [<a href="#ref-XEP-0106" title=""JID Escaping"">XEP-0106</a>] (e.g., when transforming from SIP to XMPP,
encode "'" as "\27").
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Instance-Specific Mapping</span>
The meaning of a resourcepart in XMPP (i.e., the portion of a Jabber
ID (JID) after the slash character, such as "foo" in
"user@example.com/foo") matches that of a Globally Routable User
Agent URI (GRUU) in SIP [<a href="./rfc5627" title=""Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)"">RFC5627</a>]. In both cases, these constructs
identify a particular device associated with the bare JID
("localpart@domainpart") of an XMPP entity or with the Address of
Record (AOR) of a SIP entity. Therefore, it is reasonable to map the
value of a "gr" URI parameter to an XMPP resourcepart and vice versa.
The mapping described here does not apply to temporary GRUUs -- only
to GRUUs associated with an Address of Record.
The "gr" URI parameter in SIP can contain only characters from the
ASCII range (although characters outside the ASCII range can be
percent-encoded in accordance with [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]), whereas an XMPP
resourcepart can contain nearly any Unicode character [<a href="#ref-UNICODE" title=""The Unicode Standard, Version 6.3"">UNICODE</a>].
Therefore, Unicode characters outside the ASCII range need to be
mapped to characters in the ASCII range, as described below.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. SIP to XMPP</span>
The following is a high-level algorithm for mapping a 'sip', 'sips',
'im', or 'pres' URI to an XMPP address:
1. Remove URI scheme.
2. Split at the first '@' character into local part and hostname
(mapping the latter is out of scope).
3. Translate any percent-encoded strings ("%hexhex") to percent-
decoded octets.
4. Treat result as a UTF-8 string.
5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f",
respectively in order to properly handle the characters
disallowed in XMPP addresses but allowed in 'sip'/'sips' URIs and
'im'/'pres' URIs as shown in Table 1 above (this is consistent
with [<a href="#ref-XEP-0106" title=""JID Escaping"">XEP-0106</a>]).
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
6. Apply Nodeprep profile of stringprep [<a href="./rfc3454" title=""Preparation of Internationalized Strings ("">RFC3454</a>] or its replacement
(see [<a href="./rfc6122" title=""Extensible Messaging and Presence Protocol (XMPP): Address Format"">RFC6122</a>] and [<a href="#ref-XMPP-ADDRESS-FORMAT">XMPP-ADDRESS-FORMAT</a>]) for canonicalization
(OPTIONAL).
7. Recombine local part with mapped hostname to form a bare JID
("localpart@domainpart").
8. If the (SIP) address contained a "gr" URI parameter, append a
slash character "/" and the "gr" value to the bare JID to form a
full JID ("localpart@domainpart/resourcepart").
Several examples follow, illustrating steps 3, 5, and 8 described
above.
+----------------------------+--------------------------+
| SIP URI | XMPP Address |
+----------------------------+--------------------------+
| sip:f%C3%BC@sip.example | f&#xFC;@sip.example |
+----------------------------+--------------------------+
| sip:o'malley@sip.example | o\27malley@sip.example |
+----------------------------+--------------------------+
| sip:foo@sip.example;gr=bar | foo@sip.example/bar |
+----------------------------+--------------------------+
In the first example, the string "%C3%BC" is a percent-encoded
representation of the UTF-8-encoded Unicode character LATIN SMALL
LETTER U WITH DIAERESIS (U+00FC), whereas the string "&#xFC;" is the
same character shown for documentation purposes using the XML
Notation defined in [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>] (in XMPP, it would be sent directly as
a UTF-8-encoded Unicode character and not percent-encoded as in a SIP
URI to comply with the URI syntax defined in [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]).
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. XMPP to SIP</span>
The following is a high-level algorithm for mapping an XMPP address
to a 'sip', 'sips', 'im', or 'pres' URI:
1. Split XMPP address into localpart (mapping described in remaining
steps), domainpart (hostname; mapping is out of scope), and
resourcepart (specifier for particular device or connection, for
which an OPTIONAL mapping is described below).
2. Apply Nodeprep profile of stringprep [<a href="./rfc3454" title=""Preparation of Internationalized Strings ("">RFC3454</a>] or its replacement
(see [<a href="./rfc6122" title=""Extensible Messaging and Presence Protocol (XMPP): Address Format"">RFC6122</a>] and [<a href="#ref-XMPP-ADDRESS-FORMAT">XMPP-ADDRESS-FORMAT</a>]) for canonicalization of
the XMPP localpart (OPTIONAL).
3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/",
respectively (this is consistent with [<a href="#ref-XEP-0106" title=""JID Escaping"">XEP-0106</a>]).
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
4. Determine if the foreign domain supports 'im' and 'pres' URIs
(discovered via [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>] lookup as specified in [<a href="./rfc6121" title=""Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence"">RFC6121</a>]), else
assume that the foreign domain supports 'sip'/'sips' URIs.
5. If converting into 'im' or 'pres' URI, for each byte, if the byte
is in the set (),.;[\] or is a UTF-8 character outside the ASCII
range, then percent-encode that byte to "%hexhex" format. If
converting into 'sip' or 'sips' URI, for each byte, if the byte
is in the set #%[\]^`{|} or is a UTF-8 character outside the
ASCII range, then percent-encode that byte to "%hexhex" format.
6. Combine resulting local part with mapped hostname to form
local@domain address.
7. Prepend with the string 'im:' (for XMPP <message/> stanzas) or
'pres:' (for XMPP <presence/> stanzas) if foreign domain supports
these, else prepend with the string 'sip:' or 'sips:' according
to local service policy.
8. If the XMPP address included a resourcepart and the destination
URI scheme is 'sip' or 'sips', optionally append the slash
character '/' and then append the resourcepart (making sure to
percent-encode any UTF-8 characters outside the ASCII range) as
the "gr" URI parameter.
Several examples follow, illustrating steps 3, 5, and 8 described
above.
+---------------------------+---------------------------------+
| XMPP Address | SIP URI |
+---------------------------+---------------------------------+
| m\26m@xmpp.example | sip:m&m@xmpp.example |
| tsch&#xFC;ss@xmpp.example | sip:tsch%C3%BCss@xmpp.example |
| baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux |
+---------------------------+---------------------------------+
As above, in the first example the string "&#xFC;" is the Unicode
character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC) shown for
documentation purposes using the XML Notation defined in [<a href="./rfc3987" title=""Internationalized Resource Identifiers (IRIs)"">RFC3987</a>]
(in XMPP, it would be sent directly as a UTF-8-encoded Unicode
character and not percent-encoded, whereas the string "%C3%BC" is a
percent-encoded representation of the same character.
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Error Mapping</span>
Various differences between XMPP error conditions and SIP response
codes make it hard to provide a comprehensive and consistent mapping
between the protocols:
o Whereas the set of XMPP error conditions is fixed in the core XMPP
specification (and supplemented where needed by application-
specific extensions), the set of SIP response codes is more open
to change, as evidenced by the IANA registry of SIP response
codes.
o XMPP has defined fewer error conditions related to stanza handling
(22 are defined in [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]) than SIP has defined response codes
related to message handling (at the date of this writing, 71 SIP
response codes are registered with IANA as defined in [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]
and numerous SIP extensions).
o In many cases, the SIP response codes are more specific than the
XMPP error conditions (e.g., from an XMPP perspective the SIP
codes "413 Request Entity Too Large" and "414 Request-URI Too
Long" are simply two different types of response to the same bad
request, and the SIP codes "415 Unsupported Media Type" and "416
Unsupported URI Scheme" are two different responses to a request
that is not acceptable).
o SIP differentiates between responses about a particular endpoint
or resource (the 4xx series) and responses about a user, i.e., all
of a user's endpoints or resources (the 6xx series). There is no
such distinction in XMPP, since the same error condition can be
returned in relation to the "bare JID" (localpart@domainpart) of a
user or the "full JID" (localpart@domainpart/resourcepart) of a
particular endpoint or resource, depending on the 'to' address of
the original request.
As a result of these and other factors, the mapping of error
conditions and response codes is more of an art than a science. This
document provides suggested mappings, but implementations are free to
deviate from these mappings if needed. Also, because no XMPP error
conditions are equivalent to the provisional (1xx) and successful
(2xx) response codes in SIP, this document suggests mappings only for
the SIP redirection (3xx), request failure (4xx), server failure
(5xx), and global failure (6xx) response code families.
Supplementary information about SIP response codes can be expressed
in the "Reason-Phrase" in the Status-Line header, and detailed
information about XMPP error conditions can be expressed in the
<text/> child of the <error/> element. Although the semantics of
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
these constructs are specified in a slightly different way, it is
reasonable for a gateway to map these constructs to each other if
they are found in a SIP response or XMPP error stanza.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. XMPP to SIP</span>
The mapping of specific XMPP error conditions to SIP response codes
SHOULD be as described in the following table.
+------------------------------+---------------------+
| XMPP Error Condition | SIP Response Code |
+------------------------------+---------------------+
| <bad-request/> | 400 |
+------------------------------+---------------------+
| <conflict/> | 400 |
+------------------------------+---------------------+
| <feature-not-implemented/> | 405 or 501 (1) |
+------------------------------+---------------------+
| <forbidden/> | 403 or 603 (2) |
+------------------------------+---------------------+
| <gone/> | 301 or 410 (3) |
+------------------------------+---------------------+
| <internal-server-error/> | 500 |
+------------------------------+---------------------+
| <item-not-found/> | 404 or 604 (2) |
+------------------------------+---------------------+
| <jid-malformed/> | 400 |
+------------------------------+---------------------+
| <not-acceptable/> | 406 or 606 (2) |
+------------------------------+---------------------+
| <not-allowed/> | 403 |
+------------------------------+---------------------+
| <not-authorized/> | 401 |
+------------------------------+---------------------+
| <policy-violation/> | 403 |
+------------------------------+---------------------+
| <recipient-unavailable/> | 480 or 600 (2) |
+------------------------------+---------------------+
| <redirect/> | 302 |
+------------------------------+---------------------+
| <registration-required/> | 407 |
+------------------------------+---------------------+
| <remote-server-not-found/> | 404 or 408 (4) |
+------------------------------+---------------------+
| <remote-server-timeout/> | 408 |
+------------------------------+---------------------+
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
+------------------------------+---------------------+
| <resource-constraint/> | 500 |
+------------------------------+---------------------+
| <service-unavailable/> | see note (5) below |
+------------------------------+---------------------+
| <subscription-required/> | 400 |
+------------------------------+---------------------+
| <undefined-condition/> | 400 |
+------------------------------+---------------------+
| <unexpected-request/> | 491 or 400 |
+------------------------------+---------------------+
Table 2: Mapping of XMPP Error Conditions to SIP Response Codes
(1) If the error relates to a "full JID" (localpart@domainpart/
resourcepart), the SIP 405 response code is RECOMMENDED. If the
error relates to a "bare JID" (localpart@domainpart), the SIP
501 response code is RECOMMENDED.
(2) If the error relates to a "full JID" (localpart@domainpart/
resourcepart), the SIP response code from the 4xx series is
RECOMMENDED. If the error relates to a "bare JID"
(localpart@domainpart), the SIP response code from the 6xx
series is RECOMMENDED.
(3) If the <gone/> element includes XML character data specifying
the new address, the error MUST be mapped to SIP 301; if not, it
MUST be mapped to SIP 410.
(4) The XMPP <remote-server-not-found/> error can mean that the
remote server either (a) does not exist or (b) cannot be
resolved. SIP has two different response codes here: 404 to
cover (a) and 408 to cover (b).
(5) The XMPP <service-unavailable/> error condition is widely used
to inform the requesting entity that the intended recipient does
not support the relevant feature, to signal that a server cannot
perform the requested service either generally or in relation to
a particular user, and to avoid disclosing whether a given
account exists at all. This is quite different from the
semantics of the SIP 503 Service Unavailable response code,
which is used to signal that communication with a server is
impossible (e.g., even if the XMPP <service-unavailable/> error
condition is returned in relation to a specific user, the SIP
503 response code will be interpreted as applying to all future
requests to this server, not just requests for the specific
user). Therefore, mapping the XMPP <service-unavailable/> error
condition to the SIP 503 Service Unavailable response code is
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
NOT RECOMMENDED. Although no precise mapping is available, the
SIP 403 Forbidden and 405 Method Not Allowed response codes are
closest in meaning to the XMPP <service-unavailable/> error
condition.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. SIP to XMPP</span>
The mapping of SIP response codes to XMPP error conditions SHOULD be
as described in the following table. If a gateway encounters a SIP
response code that is not listed below, it SHOULD map a 3xx-series
code to <redirect/>, a 4xx-series code to <bad-request/>, a 5xx-
series code to <internal-server-error>, and a 6xx-series code to
<recipient-unavailable/>.
+---------------------+---------------------------------+
| SIP Response Code | XMPP Error Condition |
+---------------------+---------------------------------+
| 3xx | <redirect/> |
+---------------------+---------------------------------+
| 300 | <redirect/> |
+---------------------+---------------------------------+
| 301 | <gone/> (1) |
+---------------------+---------------------------------+
| 302 | <redirect/> |
+---------------------+---------------------------------+
| 305 | <redirect/> |
+---------------------+---------------------------------+
| 380 | <not-acceptable/> |
+---------------------+---------------------------------+
| 4xx | <bad-request/> |
+---------------------+---------------------------------+
| 400 | <bad-request/> |
+---------------------+---------------------------------+
| 401 | <not-authorized/> |
+---------------------+---------------------------------+
| 402 | <bad-request/> (2) |
+---------------------+---------------------------------+
| 403 | <forbidden/> (3) |
+---------------------+---------------------------------+
| 404 | <item-not-found/> (4) |
+---------------------+---------------------------------+
| 405 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 406 | <not-acceptable/> |
+---------------------+---------------------------------+
| 407 | <registration-required/> |
+---------------------+---------------------------------+
<span class="grey">Saint-Andre, 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="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
+---------------------+---------------------------------+
| 408 | <remote-server-timeout/> (5) |
+---------------------+---------------------------------+
| 410 | <gone/> (1) |
+---------------------+---------------------------------+
| 413 | <policy-violation/> |
+---------------------+---------------------------------+
| 414 | <policy-violation/> |
+---------------------+---------------------------------+
| 415 | <not-acceptable/> |
+---------------------+---------------------------------+
| 416 | <not-acceptable/> |
+---------------------+---------------------------------+
| 420 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 421 | <not-acceptable/> |
+---------------------+---------------------------------+
| 423 | <resource-constraint/> |
+---------------------+---------------------------------+
| 430 | <recipient-unavailable/> (6) |
+---------------------+---------------------------------+
| 439 | <feature-not-implemented/> (6) |
+---------------------+---------------------------------+
| 440 | <policy-violation/> (7) |
+---------------------+---------------------------------+
| 480 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 481 | <item-not-found/> |
+---------------------+---------------------------------+
| 482 | <not-acceptable/> |
+---------------------+---------------------------------+
| 483 | <not-acceptable/> |
+---------------------+---------------------------------+
| 484 | <item-not-found/> |
+---------------------+---------------------------------+
| 485 | <item-not-found/> |
+---------------------+---------------------------------+
| 486 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 487 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 488 | <not-acceptable/> |
+---------------------+---------------------------------+
| 489 | <policy-violation/> (8) |
+---------------------+---------------------------------+
| 491 | <unexpected-request/> |
+---------------------+---------------------------------+
<span class="grey">Saint-Andre, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
+---------------------+---------------------------------+
| 493 | <bad-request/> |
+---------------------+---------------------------------+
| 5xx | <internal-server-error/> |
+---------------------+---------------------------------+
| 500 | <internal-server-error/> |
+---------------------+---------------------------------+
| 501 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 502 | <remote-server-not-found/> |
+---------------------+---------------------------------+
| 503 | <internal-server-error/> (9) |
+---------------------+---------------------------------+
| 504 | <remote-server-timeout/> |
+---------------------+---------------------------------+
| 505 | <not-acceptable/> |
+---------------------+---------------------------------+
| 513 | <policy-violation/> |
+---------------------+---------------------------------+
| 6xx | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 600 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 603 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 604 | <item-not-found/> |
+---------------------+---------------------------------+
| 606 | <not-acceptable/> |
+---------------------+---------------------------------+
Table 3: Mapping of SIP Response Codes to XMPP Error Conditions
(1) When mapping SIP 301 to XMPP <gone/>, the <gone/> element MUST
include XML character data specifying the new address. When
mapping SIP 410 to XMPP <gone/>, the <gone/> element MUST NOT
include XML character data specifying a new address.
(2) The XMPP <payment-required/> error condition was removed in
[<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>]. Therefore, a mapping to XMPP <bad-request/> is
suggested instead.
(3) Depending on the scenario, other possible translations for
SIP 403 are <not-allowed/> and <policy-violation/>.
(4) Depending on the scenario, another possible translation for
SIP 404 is <remote-server-not-found/>.
<span class="grey">Saint-Andre, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
(5) Depending on the scenario, another possible translation for
SIP 408 is <remote-server-not-found/>.
(6) Codes 430 and 439 are defined in [<a href="./rfc5626" title=""Managing Client- Initiated Connections in the Session Initiation Protocol (SIP)"">RFC5626</a>].
(7) Code 440 is defined in [<a href="./rfc5393" title=""Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies"">RFC5393</a>].
(8) Code 489 is defined in [<a href="./rfc6665" title=""SIP-Specific Event Notification"">RFC6665</a>].
(9) Regarding the semantic mismatch between XMPP
<service-unavailable/> and SIP code 503, see note (5) in
<a href="#section-7.1">Section 7.1</a> of this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Detailed security considerations for SIP and XMPP are given in
[<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] and [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>], respectively.
To protect information sent between SIP and XMPP systems, deployed
gateways SHOULD use Transport Layer Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] when
communicating over TCP and Datagram Transport Layer Security (DTLS)
[<a href="./rfc6347" title=""Datagram Transport Layer Security Version 1.2"">RFC6347</a>] when communicating over UDP.
As specified in <a href="./rfc3261#section-26.4.4">Section 26.4.4 of [RFC3261]</a> and updated by [<a href="./rfc5630" title=""The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)"">RFC5630</a>],
a To header or a Request-URI containing a Session Initiation Protocol
Secure (SIPS) URI is used to indicate that all hops in a
communication path need to be protected using TLS. Because XMPP
lacks a way to signal that all hops need to be protected, if the To
header or Request-URI of a SIP message is a SIPS URI then the SIP-to-
XMPP gateway MUST NOT translate the SIP message into an XMPP stanza
and MUST NOT route it to the destination XMPP server (there might be
exceptions to such a policy, such as explicit agreement among two
operators to enforce per-hop security, but currently they are quite
rare).
A gateway between SIP and XMPP (in either direction) effectively acts
as a SIP back-to-back user agent ("B2BUA"). The amplification
vulnerability described in [<a href="./rfc5393" title=""Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies"">RFC5393</a>] can manifest itself with B2BUAs
(see also [<a href="#ref-B2BUA-LOOP-DETECT">B2BUA-LOOP-DETECT</a>]), and a gateway SHOULD implement the
loop-detection methods defined in that specification to help mitigate
the possibility of amplification attacks. Note that although it
would be possible to signal the Max-Forwards and Max-Breadth SIP
headers over XMPP using the Stanza Headers and Internet Metadata
(SHIM) extension [<a href="#ref-XEP-0131" title=""Stanza Headers and Internet Metadata"">XEP-0131</a>], that extension is not widely
implemented; therefore, defenses against excessive looping and
amplification attacks when messages pass back and forth through SIP
and XMPP networks are out of scope for this document. However, it
<span class="grey">Saint-Andre, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
ought to be addressed in the future, and implementations are strongly
encouraged to incorporate appropriate countermeasures wherever
possible.
The ability to use a wide range of Unicode characters [<a href="#ref-UNICODE" title=""The Unicode Standard, Version 6.3"">UNICODE</a>] can
lead to security issues, especially the possibility of user confusion
over identifiers containing visually similar characters (also called
"confusable characters" or "confusables"). The PRECIS framework
specification [<a href="#ref-PRECIS" title=""PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols"">PRECIS</a>] describes some of these security issues, and
additional guidance can be found in [<a href="#ref-UTS39" title=""Unicode Technical Standard #39: Unicode Security Mechanisms"">UTS39</a>].
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.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 id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
June 2002.
[<a id="ref-RFC3263">RFC3263</a>] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", <a href="./rfc3263">RFC 3263</a>,
June 2002.
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
<a href="./rfc3986">RFC 3986</a>, January 2005.
[<a id="ref-RFC3987">RFC3987</a>] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", <a href="./rfc3987">RFC 3987</a>, January 2005.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5393">RFC5393</a>] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,
"Addressing an Amplification Vulnerability in Session
Initiation Protocol (SIP) Forking Proxies", <a href="./rfc5393">RFC 5393</a>,
December 2008.
[<a id="ref-RFC5627">RFC5627</a>] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", <a href="./rfc5627">RFC 5627</a>, October 2009.
<span class="grey">Saint-Andre, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
[<a id="ref-RFC5630">RFC5630</a>] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", <a href="./rfc5630">RFC 5630</a>, October 2009.
[<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 id="ref-RFC6122">RFC6122</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", <a href="./rfc6122">RFC 6122</a>, March 2011.
[<a id="ref-RFC6347">RFC6347</a>] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", <a href="./rfc6347">RFC 6347</a>, January 2012.
[<a id="ref-UNICODE">UNICODE</a>] The Unicode Consortium, "The Unicode Standard,
Version 6.3", 2013,
<<a href="http://www.unicode.org/versions/Unicode6.3.0/">http://www.unicode.org/versions/Unicode6.3.0/</a>>.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-B2BUA-LOOP-DETECT">B2BUA-LOOP-DETECT</a>]
Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for
Session Initiation Protocol (SIP) Back-to-Back User Agents
(B2BUAs)", Work in Progress, February 2014.
[<a id="ref-PRECIS">PRECIS</a>] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation and Comparison of Internationalized Strings in
Application Protocols", Work in Progress, April 2014.
[<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 id="ref-RFC3428">RFC3428</a>] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", <a href="./rfc3428">RFC 3428</a>, December 2002.
[<a id="ref-RFC3454">RFC3454</a>] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", <a href="./rfc3454">RFC 3454</a>,
December 2002.
[<a id="ref-RFC3856">RFC3856</a>] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", <a href="./rfc3856">RFC 3856</a>, August 2004.
[<a id="ref-RFC3859">RFC3859</a>] Peterson, J., "Common Profile for Presence (CPP)",
<a href="./rfc3859">RFC 3859</a>, August 2004.
[<a id="ref-RFC3860">RFC3860</a>] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", <a href="./rfc3860">RFC 3860</a>, August 2004.
<span class="grey">Saint-Andre, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
[<a id="ref-RFC3966">RFC3966</a>] Schulzrinne, H., "The tel URI for Telephone Numbers",
<a href="./rfc3966">RFC 3966</a>, December 2004.
[<a id="ref-RFC5122">RFC5122</a>] Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)",
<a href="./rfc5122">RFC 5122</a>, February 2008.
[<a id="ref-RFC5322">RFC5322</a>] Resnick, P., Ed., "Internet Message Format", <a href="./rfc5322">RFC 5322</a>,
October 2008.
[<a id="ref-RFC5626">RFC5626</a>] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", <a href="./rfc5626">RFC 5626</a>, October 2009.
[<a id="ref-RFC6121">RFC6121</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
<a href="./rfc6121">RFC 6121</a>, March 2011.
[<a id="ref-RFC6665">RFC6665</a>] Roach, A., "SIP-Specific Event Notification", <a href="./rfc6665">RFC 6665</a>,
July 2012.
[<a id="ref-UTS39">UTS39</a>] The Unicode Consortium, "Unicode Technical Standard #39:
Unicode Security Mechanisms", November 2013,
<<a href="http://unicode.org/reports/tr39/">http://unicode.org/reports/tr39/</a>>.
[<a id="ref-XEP-0106">XEP-0106</a>] Hildebrand, J. and P. Saint-Andre, "JID Escaping",
XSF XEP 0106, June 2007,
<<a href="http://www.xmpp.org/extensions/xep-0106.html">http://www.xmpp.org/extensions/xep-0106.html</a>>.
[<a id="ref-XEP-0131">XEP-0131</a>] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and
Internet Metadata", XSF XEP 0131, July 2006,
<<a href="http://xmpp.org/extensions/xep-0131.html">http://xmpp.org/extensions/xep-0131.html</a>>.
[<a id="ref-XMPP-ADDRESS-FORMAT">XMPP-ADDRESS-FORMAT</a>]
Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", Work in Progress,
March 2014.
<span class="grey">Saint-Andre, et al. Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7247">RFC 7247</a> SIP-XMPP Interworking: Core May 2014</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acknowledgements</span>
The authors wish to thank the following individuals for their
feedback: Mary Barnes, Dave Cridland, Dave Crocker, Mike De Vries,
Fabio Forno, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge,
Markus Isomaki, Olle Johansson, Paul Kyzivat, Salvatore Loreto,
Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks.
Dan Romascanu reviewed the document on behalf of the General Area
Review Team.
During IESG review, Stephen Farrell, Ted Lemon, Pete Resnick, and
Sean Turner caught several issues that needed to be addressed.
The authors gratefully acknowledge the assistance of Markus Isomaki
and Yana Stamcheva as the working group chairs and Gonzalo Camarillo
as the sponsoring Area Director.
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
employing him during his work on earlier versions of this document.
Authors' Addresses
Peter Saint-Andre
&yet
EMail: ietf@stpeter.im
Avshalom Houri
IBM
Rorberg Building, Pekris 3
Rehovot 76123
Israel
EMail: avshalom@il.ibm.com
Joe Hildebrand
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
EMail: jhildebr@cisco.com
Saint-Andre, et al. Standards Track [Page 24]
</pre>
|
