-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxep-0130.xml
1059 lines (1045 loc) · 53.7 KB
/
xep-0130.xml
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
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Waiting Lists</title>
<abstract>This document defines an XMPP protocol extension that enables a user to add a non-IM user to a waiting list and be informed when the contact creates an IM account.</abstract>
&LEGALNOTICE;
<number>0130</number>
<status>Deprecated</status>
<type>Historical</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0094</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>waitinglist</shortname>
<schemaloc>
<url>http://www.xmpp.org/schemas/waitinglist.xsd</url>
</schemaloc>
<expires>2012-10-18</expires>
&stpeter;
<author>
<firstname>Yehezkel</firstname>
<surname>Dallal</surname>
<email>yehezkeld@followap.com</email>
</author>
<author>
<firstname>Alexandre</firstname>
<surname>Nolle</surname>
<email>anolle@francetelecom.com</email>
</author>
<author>
<firstname>Jean-Louis</firstname>
<surname>Seguineau</surname>
<email>jean-louis.seguineau@antepo.com</email>
<jid>jlseguineau@im.antepo.com</jid>
</author>
<author>
<firstname>Mark</firstname>
<surname>Troyer</surname>
<email>mtroyer@jabber.com</email>
<jid>mtroyer@corp.jabber.com</jid>
</author>
&val;
<revision>
<version>1.4.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>1.4</version>
<date>2012-04-18</date>
<initials>psa</initials>
<remark><p>Changed status to Deprecated, per a vote of the XMPP Council.</p></remark>
</revision>
<revision>
<version>1.3</version>
<date>2006-09-13</date>
<initials>psa</initials>
<remark>Clarified alternate flow for main use case; corrected order of errors and JID pushes; specified that item removal is always the responsibility of the IM user; removed remote-server-not-found example (use item-not-found instead).</remark>
</revision>
<revision>
<version>1.2</version>
<date>2006-01-24</date>
<initials>psa</initials>
<remark>Adjusted remote-server-timeout flow to recommend IQ result followed by JID push message.</remark>
</revision>
<revision>
<version>1.1</version>
<date>2005-11-30</date>
<initials>psa</initials>
<remark>Harmonized root element specification with implemented usage, reversing change made in version 0.5.</remark>
</revision>
<revision>
<version>1.0</version>
<date>2005-08-26</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Active.</remark>
</revision>
<revision>
<version>0.6</version>
<date>2005-08-16</date>
<initials>psa</initials>
<remark>Added error case for remote server timeout; specified client and service responsibilities regarding removal of waiting list items in error cases.</remark>
</revision>
<revision>
<version>0.5</version>
<date>2005-05-16</date>
<initials>psa</initials>
<remark>Corrected schema and IQ examples by changing root element for namespace from <query/> to <waitlist/> (this had been used for message examples but not IQ examples).</remark>
</revision>
<revision>
<version>0.4</version>
<date>2005-04-01</date>
<initials>psa</initials>
<remark>Changed document type to Informational; corrected Remote Server Error example to use &remoteserver; rather than &unavailable;; added service discovery identity to XMPP Registrar Considerations; corrected text regarding registration of service discovery features; corrected some small errors in the text, examples, and schema.</remark>
</revision>
<revision>
<version>0.3</version>
<date>2004-09-27</date>
<initials>psa</initials>
<remark>Corrected error syntax used when Contact URI is not handled by any InteropPartner.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2004-09-03</date>
<initials>psa</initials>
<remark>Added alternate flow for situation in which Contact URI is not handled by any InteropPartner; changed headline message type for JID pushes from SHOULD to MAY; clarified semantics of item ID; added name child of item; corrected and updated the XML schema; updated examples to use XMPP error conditions.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2004-03-18</date>
<initials>psa</initials>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.10</version>
<date>2003-09-03</date>
<initials>psa</initials>
<remark>Fixed several small errors in the examples.</remark>
</revision>
<revision>
<version>0.0.9</version>
<date>2003-08-22</date>
<initials>psa</initials>
<remark>Specified optional use of message type 'headline'; fixed one small error in the examples.</remark>
</revision>
<revision>
<version>0.0.8</version>
<date>2003-07-23</date>
<initials>psa</initials>
<remark>Changed client-server push mechanism to use <message/> rather than <iq/>, since client may not be online; allowed IQ result to include waitlist information if known; added more detailed disco#info lookup to support discovery of URI types supported.</remark>
</revision>
<revision>
<version>0.0.7</version>
<date>2003-07-02</date>
<initials>psa</initials>
<remark>Modified to use a generic <uri scheme=''/> element.</remark>
</revision>
<revision>
<version>0.0.6</version>
<date>2003-06-26</date>
<initials>psa</initials>
<remark>Refactored protocol to use IQ sets that are "pushed" to the component or client (similar to XMPP rosters); added service discovery and agents support; made text more generic; simplified error handling; change name to "Waiting Lists".</remark>
</revision>
<revision>
<version>0.0.5</version>
<date>2003-06-24</date>
<initials>psa</initials>
<remark>Added remove use case and protocol; added XML schema.</remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2003-06-19</date>
<initials>psa</initials>
<remark>Specified protocol.</remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2003-06-18</date>
<initials>psa</initials>
<remark>Simplified requirements; defined main use case.</remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2003-06-16</date>
<initials>psa</initials>
<remark>Converted to XML format; formalized use case definitions; minor editorial changes.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2003-06-10</date>
<initials>an</initials>
<remark>First draft.</remark>
</revision>
</header>
<section1 topic="Introduction" anchor='intro'>
<p>An IM user may want to be informed when a contact creates an IM account. If the user knows some information about the contact (e.g., a phone number or email address), the user's service can use that information to place the contact on a "waiting list", then inform the user when the contact creates an IM account. This document defines an extension to &xmppcore; and &xmppim; that enables such "waiting list" functionality, including the ability to add contacts on other domains if service providers agree to interoperate (e.g., to add a contact who uses a different mobile telephony service provider).</p>
<p><em>Note: The protocol defined herein is currently in use at several large service providers in Europe. Others are welcome to use the protocol.</em></p>
</section1>
<section1 topic="Glossary" anchor='glossary'>
<dl>
<di>
<dt>Contact</dt>
<dd>A person with whom an IM User seeks to communicate, identified by a URI such as <tel:PhoneNumber> (see &rfc3966;) or <mailto:EmailAddress> (see &rfc2368;).</dd>
</di>
<di>
<dt>Customer</dt>
<dd>A person who is contracted for services with a ServiceProvider.</dd>
</di>
<di>
<dt>IM User</dt>
<dd>Any Customer who has registered for instant messaging services.</dd>
</di>
<di>
<dt>InteropPartner</dt>
<dd>Any company that agrees to interoperate using the protocol defined herein.</dd>
</di>
<di>
<dt>JID</dt>
<dd>The unique identifier of an IM User in the XMPP protocol. Outside the context of an IM session, a JID is of the form &BAREJID; ("bare JID"); within the context of an IM session, a JID is of the form &FULLJID; ("full JID").</dd>
</di>
<di>
<dt>ServiceProvider</dt>
<dd>A company that provides telephony or email services to a Customer.</dd>
</di>
<di>
<dt>URI</dt>
<dd>A Uniform Resource Identifier as defined in &rfc3986;. Specific URI schemes that may be useful in this specification include 'tel:', 'mailto:', and 'sip:', but any URI scheme may be used.</dd>
</di>
<di>
<dt>Waiting List</dt>
<dd>A list of Contacts whom an entity (IM User or InteropPartner) is waiting to hear about regarding their status as instant messaging users.</dd>
</di>
<di>
<dt>WaitingListService</dt>
<dd>An XMPP service that maintains Waiting lists for IM Users and/or InteropPartners.</dd>
</di>
</dl>
</section1>
<section1 topic="Requirements" anchor='reqs'>
<p>This protocol is designed so that an IM User can:</p>
<ol>
<li>Request the user's current Waiting List</li>
<li>Add a Contact to a local WaitingList (based on some URI associated with the Contact)</li>
<li>Receive notification from a local WaitingListService if the Contact has (or subsequently creates) an IM account</li>
<li>Remove a Contact from the Waiting List</li>
</ol>
<p>In addition, this protocol is designed so that a ServiceProvider can:</p>
<ol>
<li>Request the service's current WaitingList</li>
<li>Add a Contact to a WaitingList at an InteroPartner (based on some URI associated with the Contact)</li>
<li>Receive notification from the InteropPartner if the Contact has (or subsequently creates) an IM account</li>
<li>Remove a Contact from the Waiting List</li>
</ol>
</section1>
<section1 topic="Use Cases" anchor='usecases'>
<section2 topic="IM User Retrieves Current WaitingList" anchor='imuser-retrieve'>
<p>Before adding or removing Contacts from its WaitingList, an IM User SHOULD retrieve its current WaitingList. The activity flow is as follows:</p>
<section3 topic="Primary Flow" anchor='imuser-retrieve-primary'>
<ol>
<li>IM User discovers WaitingListService hosted by ServiceProvider [A1]; it is RECOMMENDED to do this immediately after logging in.</li>
<li>IM User requests current WaitingList from WaitingListService.</li>
<li>WaitingListService returns WaitingList to IM User, including any items for which JIDs have been discovered. [A2]</li>
</ol>
</section3>
<section3 topic="Alternate Flows" anchor='imuser-retrieve-alt'>
<ol>
<li>ServiceProvider does not host a WaitingListService:
<ol>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>IM User does not have a Waiting List:
<ol>
<li>WaitingListService returns ¬found; error to IM User.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
</ol>
</section3>
</section2>
<section2 topic="IM User Adds Contact to WaitingList" anchor='imuser-add'>
<p>An IM User may know a URI for a Contact (e.g., a phone number or email address) but not the Contact's JID. In order to subscribe to the Contact's presence or otherwise communicate with the Contact over an instant messaging system, the IM User first needs to discover the Contact's JID based on a URI for the Contact. However, the Contact may not yet have an IM account. Because the IM User may therefore need to wait until the Contact creates an account, the IM User needs to add the Contact to a WaitingList. The activity flow is as follows:</p>
<section3 topic="Primary Flow" anchor='imuser-add-primary'>
<ol>
<li>IM User completes <link url='#imuser-retrieve'>IM User Retrieves Current WaitingList</link> use case.</li>
<li>IM User requests addition of Contact to WaitingList based on Contact's URI.</li>
<li>WaitingListService determines that the URI scheme is supported. [A1]</li>
<li>WaitingListService determines that the information provided is a valid URI for that URI scheme. [A2]</li>
<li>WaitingListService determines that Contact's URI does not belong to a person served by ServiceProvider. [A3]</li>
<li>WaitingListService acknowledges addition of Contact to IM User's WaitingList.</li>
<li>WaitingListService discovers WaitingListServices hosted by one or more InteropPartners.</li>
<li>WaitingListService queries one or more InteropPartner's WaitingListServices for JID associated with URI.</li>
<li>InteropPartner's WaitingListService determines that Contact's URI belongs to a person served by that partner. [A4]</li>
<li>InteropPartner's WaitingListService determines that Contact is an IM User. [A5]</li>
<li>InteropPartner's WaitingListService informs ServiceProvider's WaitingListService of JID associated with Contact's URI. [A6] [A10]</li>
<li>ServiceProvider's WaitingListService informs IM User of Contact's JID. [A8]</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
<li>Use Case Ends.</li>
</ol>
</section3>
<section3 topic="Alternate Flows" anchor='imuser-add-alt'>
<ol>
<li>The URI scheme is not supported:
<ol>
<li>WaitingListService sends &badrequest; error to IM User and does not add contact to WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>The information provided is not a valid URI:
<ol>
<li>WaitingListService sends ¬acceptable; error to IM User and does not add contact to WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>URI belongs to person served by ServiceProvider:
<ol>
<li>WaitingListService determines that Contact is an IM User registered with ServiceProvider [A7].</li>
<li>WaitingListService informs IM User of Contact's JID. [A9]</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
<li>Use Case Ends.</li>
</ol>
</li>
<li>URI does not belong to a person served by InteropPartner:
<ol>
<li>InteropPartner sends ¬found; error to WaitingListService.</li>
<li>If all InteropPartners queried return ¬found; error, WaitingListService sends ¬found; error (or local equivalent) to IM User.</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>Contact is not an IM User registered with InteropPartner:
<ol>
<li>InteropPartner records and acknowledges WaitingListService's request for JID associated with URI.</li>
<li>OPTIONALLY, InteropPartner invites Contact to register as an IM User.</li>
<li>Contact registers.</li>
<li>InteropPartner informs Service Provider's WaitingListService of JID associated with Contact's URI.</li>
<li>ServiceProvider's WaitingListService informs all IM Users who requested JID associated with Contact's URI.</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
<li>Use Case Ends.</li>
</ol>
</li>
<li>InteropPartner refuses to provide service to ServiceProvider:
<ol>
<li>InteropPartner's WaitingListService sends ¬authorized; error to ServiceProvider's WaitingListService.</li>
<li>If all other InteropPartners also return errors, WaitingListService returns ¬found; error to IM User.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>Contact is not an IM User registered with ServiceProvider:
<ol>
<li>WaitingListService records IM User's request for JID associated with URI.</li>
<li>OPTIONALLY, WaitingListService invites Contact to register as an IM User.</li>
<li>Contact registers.</li>
<li>WaitingListService informs all IM Users who requested JID associated with Contact's URI.</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
<li>Use Case Ends.</li>
</ol>
</li>
<li>Contact's URI is not handled by any ServiceProvider:
<ol>
<li>WaitingListService informs all IM Users who requested JID associated with Contact's URI that no InteropPartner services Contact's URI.</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>IM User completes <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
<li>All Users Remove Contact from Their WaitingLists
<ol>
<li>ServiceProvider's WaitingListService removes item from WaitingList at InteropPartner's WaitingListService.</li>
<li>Use Case Ends unsuccessfully.</li>
</ol>
</li>
</ol>
</section3>
</section2>
<section2 topic="IM User Removes Contact from WaitingList" anchor='imuser-remove'>
<p>An IM User should remove a contact from the WaitingList after the <link url='#imuser-add'>IM User Adds Contact to WaitingList</link> use case ends (either successfully or unsuccessfully), and may remove a contact from the WaitingList at any other time.</p>
<section3 topic="Primary Flow" anchor='imuser-remove-primary'>
<ol>
<li>IM User sends removal request to WaitingListService.</li>
<li>WaitingListService removes IM User's request for JID associated with URI.</li>
<li>WaitingListService informs IM User of successful removal [A1].</li>
<li>WaitingListService sends removal request to appropriate InteropPartner's WaitingListService [A2].</li>
<li>InteropPartner's WaitingListService determines that URI belongs to a person served by that partner.</li>
<li>InteropPartner's WaitingListService removes ServiceProvider's WaitingListService's request for JID.</li>
<li>InteropPartner's WaitingListService informs ServiceProvider's WaitingListService of successful removal.</li>
<li>Use Case Ends.</li>
</ol>
</section3>
<section3 topic="Alternate Flows" anchor='imuser-remove-alt'>
<ol>
<li>IM User never requested JID associated with URI:
<ol>
<li>WaitingListService sends ¬found; error to IM User.</li>
<li>Use Case Ends.</li>
</ol>
</li>
<li>Contact URI is served by WaitingListService or IM User was not the only person who requested the JID:
<ol>
<li>Use Case Ends.</li>
</ol>
</li>
</ol>
</section3>
</section2>
</section1>
<section1 topic="Protocol" anchor='protocol'>
<section2 topic="IM User Interaction With WaitingListService" anchor='protocol-imuser'>
<p>
<em>This section of the document is provided for the sake of domains that implement XMPP as their local protocol; domains that implement another protocol will use their service-specific protocol to complete the user-to-domain interaction.</em>
</p>
<section3 topic="IM User Retrieves Current WaitingList" anchor='protocol-imuser-retrieve'>
<p>It is RECOMMENDED for an IM User's client to retrieve the WaitingList immediately after logging in. However, first it must discover its local WaitingListService. An IM User MAY use either &xep0030; or the deprecated &xep0094; protocol.</p>
<example caption="IM User Discovers WaitingListService by Sending Agent Information Request to its Server"><![CDATA[
<iq type='get' id='agent1'>
<query xmlns='jabber:iq:agents'/>
</iq>
]]></example>
<example caption="Server Returns Address of its WaitingListService"><![CDATA[
<iq type='result' id='agent1'>
<query xmlns='jabber:iq:agents'>
...
<agent jid='waitlist.service-provider.com'>
<name>Waiting List Service</name>
<service>waitinglist</service>
</agent>
...
</query>
</iq>
]]></example>
<example caption="IM User Discovers WaitingListService by Sending Service Discovery Request to its Server"><![CDATA[
<iq type='get' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
]]></example>
<example caption="Server Returns Address of its WaitingListService"><![CDATA[
<iq type='result' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#items'>
...
<item jid='waitlist.service-provider.com'
name='Waiting List Service'/>
...
</query>
</iq>
]]></example>
<example caption="IM User Queries WaitingListService for Detailed Information"><![CDATA[
<iq type='get'
from='user@service-provider.com/resource'
to='waitlist.service-provider.com'
id='disco2'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>The WaitingListService SHOULD return detailed information about the service it provides, including the URI schemes it supports (see also the <link url='#registrar-features'>Service Discovery Features</link> section of this document).</p>
<example caption="WaitingListService Returns Detailed Information"><![CDATA[
<iq type='result'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='disco2'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='directory' type='waitinglist'/>
<feature var='http://jabber.org/protocol/waitinglist'/>
<feature var='http://jabber.org/protocol/waitinglist/schemes/mailto'/>
<feature var='http://jabber.org/protocol/waitinglist/schemes/tel'/>
</query>
</iq>
]]></example>
<p>Once an IM User has discovered the WaitingListService, the user's client SHOULD request its current Waiting List. This is done by sending an IQ-get to the WaitingListService containing an empty <query/> element qualified by the 'http://jabber.org/protocol/waitinglist' namespace:</p>
<example caption="IM User Requests its Current WaitingList"><![CDATA[
<iq type='get'
from='user@service-provider.com/resource'
to='waitlist.service-provider.com'
id='request1'>
<query xmlns='http://jabber.org/protocol/waitinglist'/>
</iq>
]]></example>
<p>Upon request, the WaitingListService MUST return the current WaitingList to the IM User:</p>
<example caption="WaitingListService Returns WaitingList to IM User"><![CDATA[
<iq type='result'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='request1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='12345'>
<uri scheme='tel'>3033083282</uri>
<name>PSA</name>
</item>
<item id='23456'>
<uri scheme='mailto'>editor@xmpp.org</uri>
<name>XMPP Extensions Editor</name>
</item>
</query>
</iq>
]]></example>
<p>Each ItemID MUST be unique within the scope of the client's WaitingList items. The value of the ItemID is an opaque string; an implementation MAY assign semantic meaning to the ItemID (e.g., id="John Smith (mobile)" rather than id="12345"), but such meaning is implementation-specific and outside the scope of the protocol defined herein. The user MAY include a <name/> element containing a natural-language name for the Contact.</p>
<p>The WaitingList MAY contain an item for which a JID has been discovered.</p>
<example caption="IM User Asks for its WaitingList including Newly Discovered JID"><![CDATA[
<iq type='get'
from='user@service-provider.com/resource'
to='waitlist.service-provider.com'
id='jidask1'>
<query xmlns='http://jabber.org/protocol/waitinglist'/>
</iq>
<iq type='result'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='jidask1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='12345' jid='stpeter@jabber.org'>
<uri scheme='tel'>3033083282</uri>
<name>PSA</name>
</item>
<item id='23456'>
<uri scheme='mailto'>editor@xmpp.org</uri>
<name>XMPP Extensions Editor</name>
</item>
</query>
</iq>
]]></example>
</section3>
<section3 topic="IM User Adds Contact to WaitingList" anchor='protocol-imuser-add'>
<p>Once an IM User's client has discovered the WaitingListService and requested the user's WaitingList, the user can add Contacts to the WaitingList based on the Contact's URI. (Note: This document uses the example of phone numbers via the 'tel' URI scheme, but the same rules apply to WaitingList items based on email addresses or other URI schemes.)</p>
<example caption="IM User Requests Addition of Contact to WaitingList"><![CDATA[
<iq type='set'
to='waitlist.service-provider.com'
id='waitinglist1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>contact-number</uri>
<name>contact-name</name>
</item>
</query>
</iq>
]]></example>
<p>As described below, various error conditions may occur. (For information about error syntax, refer to <cite>RFC 6120</cite> and &xep0086;.)</p>
<p>If the IM User provided a URI whose scheme is not supported, WaitingListService MUST return a &badrequest; error to the IM User and MUST NOT add the Contact to the WaitingList.</p>
<example caption='WaitingListService Returns &badrequest; Error to IM User'><![CDATA[
<iq type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='waitinglist1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tag'>shakespeare.lit,2005-08:waitlist1</uri>
<name>contact-name</name>
</item>
</query>
<error code='400' type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If the IM User included a JID in the request, WaitingListService MUST return a &badrequest; error to IM User and MUST NOT add the Contact to the WaitingList. (Note: A WaitingListService MUST NOT return a non-XMPP URI to an IM User based on the Contact's JID; see the <link url='#security'>Security Considerations</link> section of this document.)</p>
<example caption='WaitingListService Returns &badrequest; Error to IM User'><![CDATA[
<iq type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='waitinglist1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item jid='some-jid'>
<uri scheme='tel'>contact-number</uri>
<name>contact-name</name>
</item>
</query>
<error code='400' type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If the IM User provided an invalid URI (e.g., a phone number with too many digits or an email address with no '@' character), WaitingListService MUST return a ¬acceptable; error to the IM User and MUST NOT add the Contact to the WaitingList.</p>
<example caption='WaitingListService Returns ¬acceptable; Error to IM User'><![CDATA[
<iq type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='waitinglist1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>+1234563033083283</uri>
<name>contact-name</name>
</item>
</query>
<error code='406' type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If one of the foregoing errors was generated (all of which have a type of "modify"), IM User SHOULD modify the request and re-submit it.</p>
<p>If none of the "modify" errors was generated, WaitingListService MUST inform the IM User that the request was successfully received, including a unique ID number for the new WaitingList item.</p>
<example caption="WaitingListService Informs IM User that Request was Received"><![CDATA[
<iq type='result'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='waitinglist1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'/>
</query>
</iq>
]]></example>
<p>If none of the "modify" errors was generated and WaitingListService knows Contact JID when the IQ result is returned to the user (e.g., because Contact is served by ServiceProvider), WaitingListService MAY include the WaitingList item in the IQ result: <note>Even if WaitingListService returns Contact JID in the IQ-result, it MUST also send a "JID push" message.</note></p>
<example caption="WaitingListService Returns IQ Result to IM User (With Contact JID)"><![CDATA[
<iq type='result'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='waitinglist1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567' jid='contact@service-provider.com'>
<uri scheme='tel'>contact-number</uri>
<name>contact-name</name>
</item>
</query>
</iq>
]]></example>
<p>If none of the "modify" errors was generated and WaitingListService does not know Contact JID when the IQ result is returned to the user, it needs to contact InteropPartners in order to determine if the Contact is associated with one of the InteropPartners. Thus before it returns the Contact JID to the IM User, it needs to wait for the one of the InteropPartners to return Contact JID or for all of the InteropPartners to return errors.</p>
<p>If all of the InteropPartners return an error of type "cancel" (typically ¬found; and/or ¬authorized;) to WaitingListService, WaitingListService MUST return an ¬found; error (or local equivalent) to the IM User (and IM User SHOULD complete <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case).</p>
<example caption='WaitingListService Returns ¬found; Error to IM User'><![CDATA[
<message
type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='waitinglist1'>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>+1234563033083283</uri>
<name>contact-name</name>
</item>
</waitlist>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
]]></example>
<p>If the connection to at least one of the InteropPartners times out (a &timeout; error), WaitingListService MUST return an IQ-result as described above (indicating that the request was received) and resend the request to the InteropPartners that timed out. If connections continue to time out (over some configurable time period and for some configurable number of retries), WaitingListService SHOULD then return a &timeout; error to IM User via a "JID push" message as shown below.</p>
<p>If InterPartner's WaitingListService knows the Contact JID, it sends it to ServiceProvider's WaitingListService as shown in the <link url='#protocol-service-add'>ServiceProvider's WaitingListService Adds Contact to WaitingList</link> section of this document.</p>
<p>If WaitingListService knows Contact JID (or learns Contact JID from InteropPartner), it MUST inform IM User through a "JID push" message, which consists of a message stanza that contains a <waitlist/> element qualified by the 'http://jabber.org/protocol/waitinglist' namespace:
<note>When waiting list information is included in a message stanza, the root element for the 'http://jabber.org/protocol/waitinglist' namespace is <waitlist/> rather than <query/> (as used within IQ stanzas). This disparity is historical and tracks the protocol syntax that was most widely implemented, as defined in version 0.4 of this specification. In the interest of interoperability, the IQ usage was changed back to <query/> in version 1.1 of this specification. If this document were not historical, the root element usage would be harmonized to use only the <waitlist/> element.</note>
</p>
<example caption="WaitingListService Pushes Contact's JID to IM User"><![CDATA[
<message
from='waitlist.service-provider.com'
to='user@service-provider.com'>
<body>This message contains a WaitingList item.</body>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567' jid='contact@service-provider.com'>
<uri scheme='tel'>contact-number</uri>
<name>contact-name</name>
</item>
</waitlist>
</message>
]]></example>
<p>Note: The JID push uses an XMPP <message/> stanza because the WaitingListService has no knowledge of the user's presence and therefore cannot assume that an &IQ; stanza will be received by the user at a specific resource.</p>
<p>If WaitingListService learns that Contact's URI is not handled by any InteropPartner, it MUST inform IM User through a "JID push" message:</p>
<example caption="WaitingListService Informs IM User that No InteropPartner Handles Contact's URI"><![CDATA[
<message
from='waitlist.service-provider.com'
to='user@service-provider.com'>
<body>Sorry, we cannot find this contact.</body>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'
jid='contact@service-provider.com'
type='error'>
<uri scheme='tel'>contact-number</uri>
<name>contact-name</name>
<error code='404'
type='cancel'
xmlns='jabber:client'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</item>
</waitlist>
</message>
]]></example>
<p>After receiving the "JID push" message, IM User SHOULD complete the <link url='#imuser-remove'>IM User Removes Contact from WaitingList</link> use case.</p>
</section3>
<section3 topic="IM User Removes Contact from WaitingList" anchor='protocol-imuser-remove'>
<p>In order to remove the item from the WaitingList, the IM User MUST complete the <link url='#imuser-remove'>Remove Contact from WaitingList</link> use case.</p>
<example caption="IM User Sends Removal Request to WaitingListService"><![CDATA[
<iq type='set'
from='user@service-provider.com/resource'
to='waitlist.service-provider.com'
id='remove1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'>
<remove/>
</item>
</query>
</iq>
]]></example>
<p>If WaitingListService previously recorded request, WaitingListService removes request from list and returns result to IM User.</p>
<example caption="WaitingListService Returns Result to IM User"><![CDATA[
<iq type='result'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='remove1'/>
]]></example>
<p>If WaitingListService did not previously record this request, WaitingListService MUST return an ¬found; error to the IM User.</p>
<example caption='WaitingListService Returns ¬found; Error to IM User'><![CDATA[
<iq type='error' id='remove1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'>
<remove/>
</item>
</query>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
</section3>
</section2>
<section2 topic="WaitingListService Interaction With InteropPartners" anchor='protocol-service'>
<p>
<em>This section of the document describes the inter-domain protocol for communication between WaitingListServices. The protocol defined in this section MUST be implemented by ServiceProviders.</em>
</p>
<p>A ServiceProvider's WaitingListService MUST be configured with a list of permitted InteropPartner's WaitingListServices with which it communicates. Therefore service discovery SHOULD NOT be necessary. However, if necessary it MAY use either the <cite>Agent Information</cite> protocol or the <cite>Service Discovery</cite> protocol as described in the following examples.</p>
<p>Note: The InteropPartner's WaitingListService is not required to be hosted by InteropPartner, and could be hosted by a third party (e.g., a neutral phone number translation service). In this case, InteropPartner would simply advertise 'waitlist.third-party.com' as its WaitingListService.</p>
<section3 topic="ServiceProvider's WaitingListService Retrieves Current WaitingList" anchor='protocol-service-retrieve'>
<example caption="ServiceProvider Discovers InteropPartner's WaitingListService by Sending Agent Information Request to InteropPartner"><![CDATA[
<iq type='get'
from='waitlist.service-provider.com'
to='interop-partner.com'
id='agent2'>
<query xmlns='jabber:iq:agents'/>
</iq>
]]></example>
<example caption="InteropPartner Returns Address of its WaitingListService"><![CDATA[
<iq type='result'
from='interop-partner.com'
to='waitlist.service-provider.com'
id='agent2'>
<query xmlns='jabber:iq:agents'>
...
<agent jid='waitlist.interop-partner.com'>
<name>Waiting List Service</name>
<service>waitinglist</service>
</agent>
...
</query>
</iq>
]]></example>
<example caption="ServiceProvider Discovers InteropPartner's WaitingListService by Sending Service Discovery Request to InteropPartner"><![CDATA[
<iq type='get'
from='waitlist.service-provider.com'
to='interop-partner.com'
id='disco3'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
]]></example>
<example caption="InteropPartner Returns Address of its WaitingListService"><![CDATA[
<iq type='result' id='disco3'>
<query xmlns='http://jabber.org/protocol/disco#items'>
...
<item jid='waitlist.service-provider.com'
name='Waiting List Service'/>
...
</query>
</iq>
]]></example>
<example caption="Service Provider Queries InteropPartner's WaitingListService for Detailed Information"><![CDATA[
<iq type='get'
from='waitlist.service-provider.com'
to='waitlist.interop-partner.com'
id='disco4'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="InteropPartner's WaitingListService Returns Detailed Information"><![CDATA[
<iq type='result'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='disco4'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='directory'
type='waitinglist'/>
<feature var='http://jabber.org/protocol/waitinglist'/>
</query>
</iq>
]]></example>
</section3>
<section3 topic="ServiceProvider's WaitingListService Adds Contact to WaitingList" anchor='protocol-service-add'>
<p>Once a ServiceProvider's WaitingListService has discovered the InteropPartner's WaitingListService and requested its WaitingList, the ServiceProvider's WaitingListService can add items to its WaitingList based on URI.</p>
<example caption="ServiceProvider's WaitingListService Adds New Item to WaitingList"><![CDATA[
<iq type='set'
from='waitlist.service-provider.com'
to='waitlist.interop-partner.com'
id='waitinglist2'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>contact-number</uri>
</item>
</query>
</iq>
]]></example>
<p>If InteropPartner refuses to provide service to ServiceProvider, it MUST return a ¬authorized; error to the ServiceProvider:</p>
<example caption='InteropPartner Returns ¬authorized; Error to ServiceProvider'><![CDATA[
<iq type='error'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='waitinglist2'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>contact-number</uri>
</item>
</query>
<error code='401' type='cancel'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If Contact's URI is not associated with a person served by this InteropPartner, the InteropPartner MUST return an ¬found; error to the ServiceProvider.</p>
<example caption='InteropPartner Returns ¬found; Error to ServiceProvider'><![CDATA[
<iq type='error'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='waitinglist2'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>contact-number</uri>
</item>
</query>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If ServiceProvider's WaitingListService receives ¬authorized; and/or ¬found; errors from all InteropPartners, it returns a ¬found; error to IM User:</p>
<example caption='WaitingListService Returns ¬found; Error to IM User'><![CDATA[
<message
type='error'
from='waitlist.service-provider.com'
to='user@service-provider.com/resource'
id='waitinglist1'>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>+1234563033083283</uri>
<name>contact-name</name>
</item>
</waitlist>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
]]></example>
<p>If Contact's URI is associated with a person served by this InteropPartner, InteropPartner MUST return acknowledgement of the WaitingList addition to the ServiceProvider's WaitingListService.</p>
<example caption="InteropPartner's WaitingListService Acknowledges Receipt"><![CDATA[
<iq type='result'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='waitinglist2'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'/>
</query>
</iq>
]]></example>
<p>If Contact is an IM User served by InteropPartner, InteropPartner's WaitingListService pushes Contact's JID to ServiceProvider's WaitingListService.</p>
<example caption="InteropPartner's WaitingListService Pushes Contact's JID to ServiceProvider's WaitingListService"><![CDATA[
<iq type='set'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='jidpush1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567' jid='user@domain'>
<uri scheme='tel'>contact-number</uri>
</item>
</query>
</iq>
]]></example>
<example caption="ServiceProvider's WaitingListService Acknowledges Receipt of JID Push"><![CDATA[
<iq type='result'
from='waitlist.service-provider.com'
to='waitlist.interop-partner.com'
id='jidpush1'/>
]]></example>
<p>After receiving acknowledgement (but not before), InteropPartner's WaitingListService MUST remove that item from the WaitingList for the ServiceProvider's WaitingListService.</p>
</section3>
<section3 topic="ServiceProvider's WaitingListService Removes Contact from WaitingList" anchor='protocol-service-remove'>
<example caption="ServiceProvider Requests Removal of Item from WaitingList"><![CDATA[
<iq type='set'
from='waitlist.service-provider.com'
to='waitlist.interop-partner.com'
id='remove2'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'>
<remove/>
</item>
</query>
</iq>
]]></example>
<p>If item exists on WaitingList, InteropPartner's WaitingListService removes item from list and returns result to ServiceProvider's WaitingListService.</p>
<example caption="InteropPartner Returns Result to ServiceProvider"><![CDATA[
<iq type='result'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='remove2'/>
]]></example>
<p>If item does not exist on WaitingList, InteropPartner's WaitingListService MUST return an ¬found; error to the ServiceProvider's WaitingListService.</p>
<example caption='InteropPartner Returns ¬found; Error to ServiceProvider'><![CDATA[
<iq type='error'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='remove2'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567'>
<remove/>
</item>
</query>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
</section3>
</section2>
</section1>
<section1 topic="Implementation Notes" anchor='impl'>
<ol>
<li><p>Protocols and mechanisms for inviting a Contact to register as an IM User are out of scope for this document and shall be determined by each InteropPartner individually.</p></li>
<li><p>A ServiceProvider's WaitingListService MUST record which of its IM Users have requested the JID associated with Contact's URI, and an InteropPartner's WaitingListService MUST record that Service Provider's WaitingListService (not User) has requested JID associated with Contact's URI. Therefore when Contact registers, InteropPartner's WaitingListService informs its local users as well as ServiceProvider's WaitingListService, and ServiceProvider's WaitingListService informs its local users.</p></li>
<li><p>The InteropPartner's WaitingListService is not required to be hosted by InteropPartner, and could be hosted by a third party (e.g., a neutral phone number translation service). In this case, InteropPartner would simply advertise 'waitlist.third-party.com' as its WaitingListService.</p></li>
<li><p>Once an IM User learns a Contact's JID, the IM User MAY send a normal subscription request to the Contact, setting the "to" address to Contact's JID. This interaction is defined in the base XMPP specifications and is out of scope for this document.</p></li>
<li><p>For historical reasons, implementations MUST support the older <cite>Agent Information</cite> protocol (XEP-0094) and SHOULD support <cite>Service Discovery</cite> (XEP-0030). Note well that the <cite>Agent Information</cite> protocol will eventually be deprecated in favor of <cite>Service Discovery</cite>.</p></li>
<li><p>An IM User's client receives WaitingList information either through a "JID push" message (received from WaitingListService at any time) or in the IQ result received after requesting the WaitingList (since one or more of the WaitingList items may contain a JID). (The same rule applies to a ServiceProvider's WaitingListService that receives an IQ set from an InteropPartner's WaitingListService.)</p></li>
<li><p>When an IM User logs in, the user's client SHOULD request the current WaitingList.</p></li>
<li><p>Although the examples in this document show the hostname of the WaitingListService as 'waitlist.third-party.com' (etc.), this is for convenience only; the hostname MAY be any valid DNS hostname.</p></li>
<li><p>When sending JID pushes, an implementation MAY specify a message type of 'headline', which in some deployments will prevent such messages from being stored offline for later delivery.</p></li>
<li><p>It can happen that WaitingListService does not receive a reply from InteropPartner within a certain amount of time or the connection to InteropPartner times out. Because such behavior is often transient, WaitingListService MAY attempt to reconnect and then resend the request (although any retry logic to handle these cases is a matter of implementation). However, WaitingListService SHOULD NOT return an ¬found; error to IM User unless it knows definitively that the Contact's InteropPartner is permanently unavailable, since returning an ¬found; error in response to temporary connection timeouts is likely to be misleading.</p></li>
</ol>
</section1>
<section1 topic="Security Considerations" anchor='security'>
<p>A ServiceProvider's WaitingListService MUST be configured with a list of permitted InteropPartners with which it communicates. The WaitingListService SHOULD NOT communicate with any InteropPartners that are not on the list.</p>
<p>Requesting JIDs via WaitingLists is not bidirectional; i.e., a service MUST NOT allow an IM User to discover a Contact's non-XMPP URI based on the Contact's JID.</p>
<p>A service MAY require a Contact to approve the disclosure of the Contact's JID, either as a global preference or for each request; however, this is a local policy matter.</p>
</section1>
<section1 topic="IANA Considerations" anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic="XMPP Registrar Considerations" anchor='registrar'>
<section2 topic="Protocol Namespaces" anchor='registrar-ns'>
<p>The ®ISTRAR; includes 'http://jabber.org/protocol/waitinglist' in its registry of protocol namespaces.</p>
</section2>
<section2 topic="Service Discovery Identities" anchor='registrar-identities'>
<p>The Jabber Registar includes a type of "waitinglist" in the "directory" category in its registry of service discovery identities.</p>
</section2>
<section2 topic="Service Discovery Features" anchor='registrar-features'>
<p>The XMPP Registrar includes supported URI schemes in its registry of service discovery features. These features shall be of the form 'http://jabber.org/protocol/waitlist/schemes/SCHEME-NAME'.</p>
<p>This document registers the following two namespace names for URI schemes, but others MAY be registered in the future using standard registration procedures:</p>
<ul>
<li>http://jabber.org/protocol/waitlist/schemes/mailto</li>
<li>http://jabber.org/protocol/waitlist/schemes/tel</li>
</ul>
</section2>
</section1>
<section1 topic="XML Schema" anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/waitinglist'
xmlns='http://jabber.org/protocol/waitinglist'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0130: http://www.xmpp.org/extensions/xep-0130.html
</xs:documentation>
</xs:annotation>
<xs:import namespace='jabber:client'
schemaLocation='http://xmpp.org/schemas/jabber-client.xsd'/>
<xs:annotation>
<xs:documentation>
Note: there are two allowable root elements for the
'http://jabber.org/protocol/waitinglist' namespace,
query and waitlist. The query element is used within
IQ stanzas and the waitlist element is used within
message stanzas. See XEP-0130 for details.
</xs:documentation>
</xs:annotation>
<xs:element name='waitlist'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='query'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='item'>
<xs:complexType>