-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxep-0292.xml
1677 lines (1556 loc) · 71.9 KB
/
xep-0292.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>vCard4 Over XMPP</title>
<abstract>This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format.</abstract>
&LEGALNOTICE;
<number>0292</number>
<status>Experimental</status>
<lastcall>2019-02-19</lastcall>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>RFC 6350</spec>
<spec>RFC 6351</spec>
</dependencies>
<supersedes>
<spec>XEP-0054</spec>
</supersedes>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&stpeter;
<author>
<firstname>Samantha</firstname>
<surname>Mizzi</surname>
<email>samizzi@cisco.com</email>
<jid>samizzi@cisco.com</jid>
</author>
<revision>
<version>0.12.0</version>
<date>2023-03-14</date>
<initials>spw</initials>
<remark><p>Removes raw-IQ mode and specifies the reuse of PEP</p></remark>
</revision>
<revision>
<version>0.11</version>
<date>2020-06-08</date>
<initials>ka</initials>
<remark><p>Recommend use of contact bare JIDs for item IDs</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2013-09-12</date>
<initials>psa</initials>
<remark><p>Added information about determining support; corrected the XSLT; corrected data: URL example and added reference to RFC 2397; corrected mapping of middle name property.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2011-10-09</date>
<initials>psa</initials>
<remark><p>Described how to use the vCard format for storing private data about one's contacts; added XMPP Registrar considerations.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2011-08-31</date>
<initials>psa</initials>
<remark><p>Updated to reflect RFC 6350, RFC 6351, and draft-ietf-vcarddav-kind-app.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2011-07-10</date>
<initials>psa</initials>
<remark><p>Updated to reflect draft-saintandre-vcarddav-thing-02.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2011-06-27</date>
<initials>sm/psa</initials>
<remark><p>Clarified status of VERSION and TZ properties.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2011-06-24</date>
<initials>psa</initials>
<remark><p>Corrected XSLT script; provided detailed examples of the vcard-temp and vCard4 XML formats.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2011-06-20</date>
<initials>psa</initials>
<remark><p>Defined provisional mapping from vcard-temp to vCard4.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2011-04-07</date>
<initials>psa</initials>
<remark><p>Updated to track base vCard4 specs; defined IQ transport, with pubsub for notifications; added examples for server vCards; described several problematic aspects of mapping from vcard-temp.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2011-04-07</date>
<initials>psa</initials>
<remark><p>Updated to track base vCard4 specs; defined IQ transport, with pubsub for notifications; added examples for server vCards; specified mapping from vcard-temp.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2011-03-02</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.5</version>
<date>2011-02-28</date>
<initials>psa</initials>
<remark><p>Corrected more errors in the examples.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2011-02-25</date>
<initials>psa</initials>
<remark><p>Corrected some errors in the examples.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2011-02-12</date>
<initials>psa</initials>
<remark><p>Third draft.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2011-01-31</date>
<initials>srm</initials>
<remark><p>Second draft.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2010-11-30</date>
<initials>srm</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Since 1999, the Jabber/XMPP community has used an interim, unofficial XML representation of vCard data for personal contacts, called &xep0054;. Recently, the IETF has upgraded vCard from vCard3 to vCard 4 (&rfc6350;), and at the same time has defined an official XML format for vCard4 (&rfc6351;). This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. Primarily this document defines the encapsulation method itself; secondarily it also defines transport methods and a mapping to the vcard-temp format for migration by clients and servers.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This specification was designed with the following requirements in mind.</p>
<ol>
<li>Reuse vCard4 as defined in <cite>RFC 6350</cite>.</li>
<li>Reuse the vCard4 XML format as defined in <cite>RFC 6351</cite>.</li>
<li>Ensure that clients and servers can easily migrate from vcard-temp to the new encapsulation format.</li>
<li>Notify interested parties of changes to vCard data using standard XMPP extensions, specifically &xep0163;.</li>
<li>Support vCards for non-human entities such as XMPP servers and &xep0045; rooms.</li>
<li>Enable XMPP servers to store vCard4 XML data in LDAP directories if desired.</li>
</ol>
</section1>
<section1 topic='Reuse of vCard4' anchor='reuse'>
<p>Because there is now an XML namespace for the official vCard format, we can simply re-use that namespace: "urn:ietf:params:xml:ns:vcard-4.0".</p>
<p>The vCard XML format defined at the IETF specifies that the root element is <vcards/>, where the only defined child element is <vcard/>. For use in XMPP, we specify that the root element shall be <vcard/>, not <vcards/>.</p>
</section1>
<section1 topic='Self vCards' anchor='public'>
<p>This section describes the use of the vCard format for self-publication and retrieval of publicly-accessible information about any entity on an XMPP network, thus fulfilling all the use cases of the old vcard-temp format.</p>
<section2 topic='PEP Publication and Retrieval' anchor='self-iq'>
<p>The primary method for publishing and retrieving vCards is via &xep0222; using the node name 'urn:xmpp:vcard4'.</p>
<section3 topic='Retrieval' anchor='self-pep-retrieval'>
<p>An XMPP entity retrieves the vCard of another entity (or itself) by sending a PEP-get to the target entity for the 'urn:xmpp:vcard4' node.</p>
<example caption="vCard Retrieval Request"><![CDATA[
<iq from='samizzi@cisco.com/foo'
id='bx81v356'
to='stpeter@jabber.org'
type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:vcard4'/>
</pubsub>
</iq>
]]></example>
<p>If a vCard exists for the target entity, the responsible entity (e.g., the XMPP server that hosts the account for a bare JID) MUST return the data in an IQ-result:</p>
<example caption="Server Returns vCard"><![CDATA[
<iq from='stpeter@jabber.org'
id='bx81v356'
to='samizzi@cisco.com/foo'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:vcard4'>
<item id='e0bf7714-a8dd-4749-8a18-e1979525b0d5'>
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<fn><text>Peter Saint-Andre</text></fn>
<n><surname>Saint-Andre</surname><given>Peter</given><additional></additional></n>
<nickname><text>stpeter</text></nickname>
<nickname><text>psa</text></nickname>
<photo><uri>https://stpeter.im/images/stpeter_oscon.jpg</uri></photo>
<bday><date>1966-08-06</date></bday>
<adr>
<parameters>
<type><text>work</text><text>voice</text></type>
<pref><integer>1</integer></pref>
</parameters>
<ext>Suite 600</ext>
<street>1899 Wynkoop Street</street>
<locality>Denver</locality>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</adr>
<adr>
<parameters><type><text>home</text></type></parameters>
<ext></ext>
<street></street>
<locality>Parker</locality>
<region>CO</region>
<code>80138</code>
<country>USA</country>
</adr>
<tel>
<parameters>
<type><text>work</text><text>voice</text></type>
<pref><integer>1</integer></pref>
</parameters>
<uri>tel:+1-303-308-3282</uri>
</tel>
<tel>
<parameters><type><text>work</text><text>fax</text></type></parameters>
<uri>tel:+1-303-308-3219</uri>
</tel>
<tel>
<parameters>
<type><text>cell</text><text>voice</text><text>text</text></type>
</parameters>
<uri>tel:+1-720-256-6756</uri>
</tel>
<tel>
<parameters><type><text>home</text><text>voice</text></type></parameters>
<uri>tel:+1-303-555-1212</uri>
</tel>
<geo><uri>geo:39.59,-105.01</uri></geo>
<title><text>Executive Director</text></title>
<role><text>Patron Saint</text></role>
<org>
<parameters><type><text>work</text></type></parameters>
<text>XMPP Standards Foundation</text>
</org>
<url><uri>https://stpeter.im/</uri></url>
<note>
<text>
More information about me is located on my
personal website: https://stpeter.im/
</text>
</note>
<gender><sex><text>M</text></sex></gender>
<lang>
<parameters><pref>1</pref></parameters>
<language-tag>en</language-tag>
</lang>
<email>
<parameters><type><text>work</text></type></parameters>
<text>psaintan@cisco.com</text>
</email>
<email>
<parameters><type><text>home</text></type></parameters>
<text>stpeter@jabber.org</text>
</email>
<impp>
<parameters><type><text>work</text></type></parameters>
<uri>xmpp:psaintan@cisco.com</uri>
</impp>
<impp>
<parameters><type><text>home</text></type></parameters>
<uri>xmpp:stpeter@jabber.org</uri>
</impp>
<key>
<uri>https://stpeter.im/stpeter.asc</uri>
</key>
</vcard>
</item>
</items>
</pubsub>
</iq>
]]></example>
</section3>
<section3 topic='Publication' anchor='self-iq-publication'>
<p>An XMPP entity publishes or updates its vCard by doing a PEP publish to its own 'urn:xmpp:vcard4' node. The publication request needs to include the entire vCard, not a "diff" against the prior data (if any).</p>
<example caption="vCard Publication Request"><![CDATA[
<iq from='stpeter@jabber.org/squire
id='h3vz319m'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:vcard4'>
<item>
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'>
[...]
</vcard>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<p>If no error occurs, the responsible entity returns an IQ-result.</p>
<example caption="Server Acknowledges Publication"><![CDATA[
<iq from='stpeter@jabber.org'
id='bx81v356'
to='stpeter@jabber.org/squire'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:vcard4'>
<item id='1e3fdd90-f542-41d3-82ae-33d183467a7a'/>
</publish>
</pubsub>
</iq>
]]></example>
<p>Note: An entity MAY have authorization to update the vCard of another entity (e.g., a server administrator might have authorization to modify the server's vCard).</p>
</section3>
</section2>
<section2 topic='Event Notifications' anchor='self-pubsub'>
<p>&xep0163; also provides a way to subscribe to events. It can be used to automatically generate event notifications when a user's vCard is modified.</p>
<section3 topic='Subscribing to vCard Notifications' anchor='self-pubsub-subscribe'>
<p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:</p>
<ol>
<li>Implicitly subscribe by advertising support for "urn:xmpp:vcard4+notify" in her &xep0115; data. Romeo's PEP service then automatically sends vCard updates to her when it receives presence from her, until and unless she sends presence of type unavailable or stops advertising an interest in vCard updates. This is in accordance with &xep0060;, section 6.1.</li>
<li>Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service might send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).</li>
</ol>
</section3>
<section3 topic='Receiving a vCard Notification'>
<p>Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet.</p>
<example caption="Receiving a vCard publication/update"><![CDATA[
<message from='romeo@montague.lit'
to='juliet@capulet.lit'
type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:vcard4'>
<item id='1e3fdd90-f542-41d3-82ae-33d183467a7a'/>
</items>
</event>
</message>
]]></example>
<p>Note: There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard as described earlier).</p>
</section3>
</section2>
</section1>
<section1 topic='Contact vCards' anchor='contacts'>
<p>In addition to enabling the publication and retrieval of vCards about any entity on an XMPP network, the vCard format can also be used to store information about an entity's contacts.</p>
<section2 topic='Format' anchor='contacts-format'>
<p>A contact is simply a vCard about someone else (or something else, in the case of automated entities). If the other person or entity is in the user's roster &rfc6121;, the vCard SHOULD contain the Jabber ID of the person or entity. This enables a user to store information about the contact outside of the roster, thus obviating the need for changes or extensions to the roster namespace itself (as in &xep0145;).</p>
<example caption="Contact"><![CDATA[
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<fn><text>Samantha Mizzi</text></fn>
<n>
<surname>Mizzi</surname>
<given>Samantha</given>
<additional></additional>
</n>
<nickname><text>Sam</text></nickname>
<nickname><text>samizzi</text></nickname>
<geo><uri>geo:39.59,-105.01</uri></geo>
<org>
<parameters><type><text>work</text></type></parameters>
<text>Cisco</text>
</org>
<note>
<text>
My co-author on XEP-0292. She's cool!
</text>
</note>
<impp>
<parameters><type><text>work</text></type></parameters>
<uri>xmpp:samizzi@cisco.com</uri>
</impp>
</vcard>
]]></example>
</section2>
<section2 topic='Storage' anchor='contacts-storage'>
<p>Because contact vCards are private information, they are best stored using &xep0223;. The canonical location is a well-known pubsub node "urn:xmpp:contacts". In accordance with <cite>XEP-0223</cite>, this node MUST have an access type of "whitelist" by default. When a client stores items at this node, it MUST include an ItemID set to the bare JID of the contact.</p>
<example caption='Storing a Contact vCard'><![CDATA[
<iq from='stpeter@stpeter.im/squire' type='set' id='h3vs7163'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:contacts'>
<item id='samizzi@cisco.com'>
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<fn><text>Samantha Mizzi</text></fn>
<n>
<surname>Mizzi</surname>
<given>Samantha</given>
<additional></additional>
</n>
<nickname><text>Sam</text></nickname>
<nickname><text>samizzi</text></nickname>
<geo><uri>geo:39.59,-105.01</uri></geo>
<org>
<parameters><type><text>work</text></type></parameters>
<text>Cisco</text>
</org>
<note>
<text>
My co-author on XEP-0292. She's cool!
</text>
</note>
<impp>
<parameters><type><text>work</text></type></parameters>
<uri>xmpp:samizzi@cisco.com</uri>
</impp>
</vcard>
</item>
</publish>
<publish-options>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#publish-options</value>
</field>
<field var='pubsub#persist_items'>
<value>true</value>
</field>
<field var='pubsub#access_model'>
<value>whitelist</value>
</field>
</x>
</publish-options>
</pubsub>
</iq>
]]></example>
<p>When a contact's vCard is stored in a private node, it is pushed out to all of the user's resources that have included in their entity capabilities (XEP-0115) data a service discovery feature of "urn:xmpp:contacts+notify" (in the following example those resources are "squire" and "roundabout").</p>
<example caption='Publisher resources receive event notification'><![CDATA[
<message from='stpeter@stpeter.im'
to='stpeter@stpeter.im/squire'
type='headline'
id='ka92g1b5'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:contacts'>
<item id='samizzi@cisco.com'>
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<fn><text>Samantha Mizzi</text></fn>
<n>
<surname>Mizzi</surname>
<given>Samantha</given>
<additional></additional>
</n>
<nickname><text>Sam</text></nickname>
<nickname><text>samizzi</text></nickname>
<geo><uri>geo:39.59,-105.01</uri></geo>
<org>
<parameters><type><text>work</text></type></parameters>
<text>Cisco</text>
</org>
<note>
<text>
My co-author on XEP-0292. She's cool!
</text>
</note>
<impp>
<parameters><type><text>work</text></type></parameters>
<uri>xmpp:samizzi@cisco.com</uri>
</impp>
</vcard>
</item>
</items>
</event>
</message>
<message from='stpeter@stpeter.im'
to='stpeter@stpeter.im/roundabout'
type='headline'
id='pty14x69'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:contacts'>
<item id='samizzi@cisco.com'>
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<fn><text>Samantha Mizzi</text></fn>
<n>
<surname>Mizzi</surname>
<given>Samantha</given>
<additional></additional>
</n>
<nickname><text>Sam</text></nickname>
<nickname><text>samizzi</text></nickname>
<geo><uri>geo:39.59,-105.01</uri></geo>
<org>
<parameters><type><text>work</text></type></parameters>
<text>Cisco</text>
</org>
<note>
<text>
My co-author on XEP-0292. She's cool!
</text>
</note>
<impp>
<parameters><type><text>work</text></type></parameters>
<uri>xmpp:samizzi@cisco.com</uri>
</impp>
</vcard>
</item>
</items>
</event>
</message>
]]></example>
</section2>
</section1>
<section1 topic='vCards of Automated Entities' anchor='apps'>
<p>Traditionally, vCards have been used on the XMPP network for entities other than human users, e.g. by XMPP servers and chatrooms. When such automated entities use vCards, it is RECOMMENDED to specify a value of "application" for the vCard4 KIND property &rfc6473;, as illustrated in the following example:</p>
<example caption="vCard for a Thing"><![CDATA[
<iq from='jabber.org'
id='yhx51c35'
to='samizzi@cisco.com/foo'
type='result'>
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'>
<fn><text>jabber.org IM service</text></fn>
<url><uri>http://www.jabber.org/</uri></url>
<lang>
<parameters><pref>1</pref></parameters>
<language-tag>en</language-tag>
</lang>
<email><text>xmpp@jabber.org</text></email>
<impp><uri>xmpp:jabber.org</uri></impp>
<logo><uri>http://www.jabber.org/images/logo.png</uri></logo>
<geo><uri>geo:42.25,-91.05</uri></geo>
<tz><text>America/Chicago</text></tz>
<kind><text>application</text></kind>
</vcard>
</iq>
]]></example>
</section1>
<section1 topic='Determining Support' anchor='disco'>
<p>If an XMPP client or server supports the vCard4 namespace, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:ietf:params:xml:ns:vcard-4.0":</p>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='stpeter@jabber.org/squire'
to='samizzi@cisco.com/foo'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
from='samizzi@cisco.com/foo'
to='stpeter@jabber.org/squire'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:ietf:params:xml:ns:vcard-4.0'/>
...
</query>
</iq>
]]></example>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The vCard information published to one's XMPP server is world-readable; therefore, users should exercise due caution when determining what information to include (e.g., street addresses, personal telephone numbers, or email addresses).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document does not require interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-nodes'>
<p>The ®ISTRAR; shall include 'urn:xmpp:contact' and 'urn:xmpp:vcard4' in its registry of Nodes for Service Discovery and Publish-Subscribe at &NODES;.</p>
</section2>
</section1>
<section1 topic='Mapping from vcard-temp to vCard4' anchor='mapping'>
<p>This section provides a more detailed description of mapping vcard-temp properties to vcard4 properties.</p>
<section2 topic='Properties Defined in vcard-temp but not in vCard3 or vCard4' anchor='mapping-temponly'>
<section3 topic='DESC' anchor='mapping-temponly-desc'>
<p>The vcard-temp specification defined a <DESC/> element. This element was not part of the vCard3 schema. Mapping the vcard-temp <DESC/> element to the vCard4 NOTE property is appropriate.</p>
<example caption="Deprecated DESC element"><![CDATA[
<DESC>
More information about me is located on my
personal website: https://stpeter.im/
</DESC>
]]></example>
<example caption="NOTE property"><![CDATA[
<note>
<text>
More information about me is located on my
personal website: https://stpeter.im/
</text>
</note>
]]></example>
</section3>
<section3 topic='JABBERID' anchor='mapping-temponly-jabberid'>
<p>The vcard-temp specification defined a <JABBERID/> element:</p>
<example caption="Deprecated JABBERID element"><![CDATA[
<JABBERID>stpeter@jabber.org</JABBERID>
]]></example>
<p>Although the JABBERID field was not part of the vCard3 schema and was simply hacked into vcard-temp, &rfc4770; defined an IMPP property for instant messaging and presence addresses, which was ported to vCard4. In the vCard4 XML format, the IMPP property for a JabberID would be as follows.</p>
<example caption="IMPP property"><![CDATA[
<impp>
<uri>xmpp:stpeter@jabber.org</uri>
</impp>
]]></example>
</section3>
<section3 topic='MIDDLE' anchor='mapping-temponly-middle'>
<p>The vcard-temp specification defined a <MIDDLE/> element as the third allowable element within the <N/> ("name") element. This element was not part of the vCard3 schema, although the Dawson drafts did contain an <other/> element in the third position of child elements within the <n/> element. It is appropriate to map the vcard-temp <MIDDLE/> element to the vCard4 "Additional Name" part of the "N" structured property value, which in xCard is the <additional/> child of the <n/> element.</p>
</section3>
</section2>
<section2 topic='Properties Defined Incorrectly in vcard-temp' anchor='mapping-incorrect'>
<p>Several of the properties in vcard-temp are defined differently in vCard3. In fact, the definitions even differ from those provisionally made in the so-called "Dawson drafts" from which vcard-temp was supposedly derived (for reference, the last of these is archived at <<link url='http://www.watersprings.org/pub/id/draft-dawson-vcard-xml-dtd-03.txt'>http://www.watersprings.org/pub/id/draft-dawson-vcard-xml-dtd-03.txt</link>>). The reasons for these discrepancies are unknown. However, care must be taken in correctly mapping these properties from vcard-temp to vCard4.</p>
<section3 topic='KEY' anchor='mapping-incorrect-key'>
<p>The DTD in <cite>XEP-0054</cite> provided this definition for the KEY element:</p>
<code><![CDATA[
<!ELEMENT KEY (TYPE?, CRED)>
]]></code>
<p>However, the DTD in the final Dawson draft provided the following definition:</p>
<code><![CDATA[
<!ELEMENT key (extref | b64bin)>
]]></code>
<p>The relevant RelaxNG definition in vCard4 XML is as follows:</p>
<code><![CDATA[
property-key = element key {
(value-uri | value-text)
}
]]></code>
<p>The source of the spurious <TYPE/> and <CRED/> elements is unknown. The vcard-temp <CRED/> element is mapped to the vCard4 value-text construction.</p>
</section3>
<section3 topic='SOUND' anchor='mapping-incorrect-sound'>
<p>The DTD in <cite>XEP-0054</cite> provided this definition for the SOUND element:</p>
<code><![CDATA[
<!ELEMENT SOUND (PHONETIC | BINVAL | EXTVAL)>
]]></code>
<p>However, the DTD in the final Dawson draft provided the following definition:</p>
<code><![CDATA[
<!ELEMENT sound (extref | b64bin)>
]]></code>
<p>The source of the spurious vcard-temp <PHONETIC/> element is unknown. However, it does not exist in vCard4 and therefore is simply discarded when mapping. The vcard-temp <BINVAL/> element is mapped to the vCard4 b64bin construction and the vcard-temp <EXTVAL/> element is mapped to the vCard4 extref construction.</p>
</section3>
<section3 topic='VERSION' anchor='mapping-incorrect-version'>
<p>As explained in <cite>XEP-0054</cite>, the <VERSION/> element from the final Dawson draft was not used in vcard-temp; instead, the vcard-temp protocol used a 'version' attribute (in fact the Dawson drafts were inconsistent, since the DTD defined a <VERSION/> element and the body of the specification used a 'version' attribute).</p>
</section3>
</section2>
<section2 topic='Properties Defined Differently in vcard-temp, vCard3, and vCard4' anchor='mapping-different'>
<p>The following properties are defined differently in vcard-temp and vCard4. As a result, the mappings are workable but might not preserve all information that could have been contained in vcard-temp data.</p>
<section3 topic='ADR' anchor='mapping-different-adr'>
<p>The following address type values allowed in vCard3 were removed from vCard4:</p>
<ul>
<li>DOM</li>
<li>INTL</li>
<li>PARCEL</li>
<li>POSTAL</li>
</ul>
</section3>
<section3 topic='AGENT' anchor='mapping-different-agent'>
<p>In vCard3 and vcard-temp, the AGENT property was allowed to contain the inline vCard of someone who could act as an agent for the primary owner of the referenced vCard. In vCard4, inline vCards are disallowed. Therefore only pointers to external vCard objects are now allowed, by means of a URI.</p>
</section3>
<section3 topic='ORG' anchor='mapping-different-org'>
<p>The ORGUNIT property was removed from vCard4, with the result that the ORGNAME property becomes the only child of ORG.</p>
</section3>
<section3 topic='SORT-STRING' anchor='mapping-different-sortstring'>
<p>The SORT-STRING property from vCard3 was renamed to SORT-AS in vCard4.</p>
</section3>
<section3 topic='TEL' anchor='mapping-different-tel'>
<p>The following telephony type values allowed in vCard3 were removed from vCard4:</p>
<ul>
<li>BBS</li>
<li>ISDN</li>
<li>MODEM</li>
<li>MSG</li>
<li>PCS</li>
</ul>
<p>In addition, in vCard4 the telephone number is represented as a tel: URI, not by means of a NUMBER property.</p>
</section3>
</section2>
<section2 topic='Properties Defined Similarly in vcard-temp, vCard3, and vCard4' anchor='mapping-similar'>
<p>The following properties are defined similarly in vcard-temp, vCard3, and vCard4. The mappings are fairly straightforward (a future version of this document might provide more detailed narrative descriptions of the mappings).</p>
<ul>
<li>BDAY</li>
<li>CATEGORIES</li>
<li>EMAIL</li>
<li>FN</li>
<li>GEO</li>
<li>LOGO</li>
<li>N</li>
<li>NICKNAME</li>
<li>NOTE</li>
<li>PHOTO (mapped to a 'data:' URI in vCard4, see &rfc2397;)</li>
<li>PRODID</li>
<li>REV</li>
<li>ROLE</li>
<li>TITLE</li>
<li>TZ</li>
<li>UID</li>
<li>URL</li>
</ul>
</section2>
<section2 topic='Properties Defined in vCard3 but Removed from vCard4' anchor='mapping-removed'>
<p>The following properties were defined in vCard3 but were removed from vCard4:</p>
<ul>
<li>CLASS</li>
<li>LABEL</li>
<li>MAILER</li>
</ul>
<p>There is no mapping from these properties to vCard4.</p>
</section2>
</section1>
<section1 topic='Migration Tools' anchor='migration'>
<p>This section contains three tools that are intended to help developers in migrating from vcard-temp to vCard4 XML:</p>
<ol>
<li>An Extensible Stylesheet Language Transformation (XSLT) script for automatically translating the vcard-temp XML format into the vCard4 XML format.</li>
<li>An example of vcard-temp data that uses most of the elements defined in <cite>XEP-0054</cite> that can be mapped to vCard4 properties (note that some of these elements were never used in practice).</li>
<li>An example of vCard4 XML data showing the transformation of the vcard-temp example using the XSLT stylesheet.</li>
</ol>
<p>The tools are <strong>purely informational</strong> and are not a normative part of this specification.</p>
<section2 topic='Extensible Stylesheet Language Transformation (XSLT) from vcard-temp to vCard4' anchor='migration-xslt'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<!--
Copyright (c) 1999 - 2021 XMPP Standards Foundation
Permission is hereby granted, free of charge, to any
person obtaining a copy of this software and
associated documentation files (the "Software"), to
deal in the Software without restriction, including
without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom
the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice
shall be included in all copies or substantial portions
of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
-->
<!-- Author: stpeter@jabber.org -->
<!-- Version: 0.0.3 -->
<!-- Last Updated: 2012-09-12 -->
<xsl:stylesheet
xmlns='urn:ietf:params:xml:ns:vcard-4.0'
xmlns:xsl='http://www.w3.org/1999/XSL/Transform'
version='1.0'>
<xsl:output method='xml'/>
<xsl:template match='/'>
<vcard>
<!-- BEGIN VARIABLES -->
<!-- in case we need them, count instances of the vcard-temp
elements per the DTD in XEP-0054 -->
<xsl:variable name='FN.count' select='count(/vCard/FN)'/>
<xsl:variable name='N.count' select='count(/vCard/N)'/>
<xsl:variable name='NICKNAME.count' select='count(/vCard/NICKNAME)'/>
<xsl:variable name='PHOTO.count' select='count(/vCard/PHOTO)'/>
<xsl:variable name='BDAY.count' select='count(/vCard/BDAY)'/>
<xsl:variable name='ADR.count' select='count(/vCard/ADR)'/>
<xsl:variable name='LABEL.count' select='count(/vCard/LABEL)'/>
<xsl:variable name='TEL.count' select='count(/vCard/TEL)'/>
<xsl:variable name='EMAIL.count' select='count(/vCard/EMAIL)'/>
<xsl:variable name='JABBERID.count' select='count(/vCard/JABBERID)'/>
<xsl:variable name='MAILER.count' select='count(/vCard/MAILER)'/>
<xsl:variable name='TZ.count' select='count(/vCard/TZ)'/>
<xsl:variable name='GEO.count' select='count(/vCard/GEO)'/>
<xsl:variable name='TITLE.count' select='count(/vCard/TITLE)'/>
<xsl:variable name='ROLE.count' select='count(/vCard/ROLE)'/>
<xsl:variable name='LOGO.count' select='count(/vCard/LOGO)'/>
<xsl:variable name='AGENT.count' select='count(/vCard/AGENT)'/>
<xsl:variable name='ORG.count' select='count(/vCard/ORG)'/>
<xsl:variable name='CATEGORIES.count' select='count(/vCard/CATEGORIES)'/>
<xsl:variable name='NOTE.count' select='count(/vCard/NOTE)'/>
<xsl:variable name='PRODID.count' select='count(/vCard/PRODID)'/>
<xsl:variable name='REV.count' select='count(/vCard/REV)'/>
<xsl:variable name='SORT-STRING.count' select='count(/vCard/SORT-STRING)'/>
<xsl:variable name='SOUND.count' select='count(/vCard/SOUND)'/>
<xsl:variable name='UID.count' select='count(/vCard/UID)'/>
<xsl:variable name='URL.count' select='count(/vCard/URL)'/>
<xsl:variable name='CLASS.count' select='count(/vCard/CLASS)'/>
<xsl:variable name='KEY.count' select='count(/vCard/KEY)'/>
<xsl:variable name='DESC.count' select='count(/vCard/DESC)'/>
<!-- END VARIABLES -->
<!-- BEGIN VCARD4 OUTPUT -->
<!-- FN is required -->
<fn><text><xsl:value-of select='/vCard/FN'/></text></fn>
<!-- N is required -->
<xsl:apply-templates select='/vCard/N'/>
<!-- NICKNAME can be included one or more times -->
<xsl:for-each select='/vCard/NICKNAME'>
<nickname><text><xsl:value-of select='.'/></text></nickname>
</xsl:for-each>
<!-- PHOTO can be included one or more times -->
<!-- content is either a pointer to a URL or inline binary,
which is mapped to a data: URI in vCard4 -->
<xsl:for-each select='/vCard/PHOTO'>
<xsl:variable name='PHOTO.ext' select='count(EXTVAL)'/>
<xsl:variable name='PHOTO.type' select='TYPE'/>
<xsl:choose>
<xsl:when test='$PHOTO.ext=1'>
<photo><uri><xsl:value-of select='EXTVAL'/></uri></photo>
</xsl:when>
<xsl:otherwise>
<photo>
<uri>
<xsl:text>data:</xsl:text><xsl:value-of select='TYPE'/><xsl:text>;</xsl:text><xsl:value-of select='BINVAL'/>
</uri>
</photo>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
<!-- BDAY can be included once -->
<xsl:if test='$BDAY.count=1'>
<bday><date><xsl:value-of select='/vCard/BDAY'/></date></bday>
</xsl:if>
<!-- ADR can be included one or more times -->
<xsl:apply-templates select='/vCard/ADR'/>
<!-- NOTE: vcard-temp allowed a LABEL element,
but it was removed from vCard4 -->
<!-- one or more TEL elements can be included -->
<xsl:apply-templates select='/vCard/TEL'/>
<!-- one or more EMAIL elements can be included -->
<xsl:apply-templates select='/vCard/EMAIL'/>
<!-- JABBERID can be included one or more times -->
<!-- we map this to the vCard4 IMPP property -->
<xsl:for-each select='/vCard/JABBERID'>
<impp><uri><xsl:text>xmpp:</xsl:text><xsl:value-of select='.'/></uri></impp>
</xsl:for-each>
<!-- NOTE: vcard-temp allowed a MAILER element,
but it was removed from vCard4 -->
<!-- one or more TZ elements can be included -->
<xsl:for-each select='/vCard/TZ'>
<tz><text><xsl:value-of select='.'/></text></tz>
</xsl:for-each>
<!-- one or more GEO elements can be included -->
<xsl:for-each select='/vCard/GEO'>
<geo><uri><xsl:text>geo:</xsl:text><xsl:value-of select='LAT'/><xsl:text>,</xsl:text><xsl:value-of select='LON'/></uri></geo>
</xsl:for-each>
<!-- one or more TITLE elements can be included -->
<xsl:for-each select='/vCard/TITLE'>
<title><text><xsl:value-of select='.'/></text></title>
</xsl:for-each>
<!-- one or more ROLE elements can be included -->
<xsl:for-each select='/vCard/ROLE'>
<role><text><xsl:value-of select='.'/></text></role>
</xsl:for-each>
<!-- one or more LOGO elements can be included -->
<!-- content is either a pointer to a URL or inline binary,
which is mapped to a data: URI in vCard4 -->
<xsl:for-each select='/vCard/LOGO'>
<xsl:variable name='LOGO.ext' select='count(EXTVAL)'/>
<xsl:variable name='LOGO.type' select='TYPE'/>
<xsl:choose>
<xsl:when test='$LOGO.ext=1'>
<logo><uri><xsl:value-of select='EXTVAL'/></uri></logo>
</xsl:when>
<xsl:otherwise>
<logo>
<uri><xsl:text>data:</xsl:text><xsl:value-of select='TYPE'/><xsl:text>;base64,</xsl:text><xsl:value-of select='BINVAL'/>
</uri>
</logo>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
<!-- one or more AGENT elements can be included -->
<!-- however, inline vcards are not supported in vCard4 -->
<!-- the relevant vCard4 property is RELATED -->
<!-- only EXTVAL is supported now via URIs -->
<!-- NOTE: this element was probably unused in vcard-temp -->
<xsl:for-each select='/vCard/AGENT'>
<xsl:variable name='AGENT.ext' select='count(EXTVAL)'/>
<xsl:if test='$AGENT.ext=1'>
<agent><uri><xsl:value-of select='EXTVAL'/></uri></agent>
</xsl:if>
</xsl:for-each>
<!-- one or more ORG elements can be included -->
<!-- NOTE: ORGUNIT is no longer used in vcard4 -->
<xsl:for-each select='/vCard/ORG'>
<org>
<xsl:variable name='ORGNAME.count' select='count(ORGNAME)'/>
<xsl:if test='$ORGNAME.count=1'>
<text><xsl:value-of select='ORGNAME'/></text>
</xsl:if>
</org>
</xsl:for-each>
<!-- one or more CATEGORIES elements can be included -->
<!-- NOTE: this element was probably unused in vcard-temp -->
<xsl:for-each select='/vCard/CATEGORIES'>
<categories><text><xsl:value-of select='.'/></text></categories>
</xsl:for-each>
<!-- one or more NOTE elements can be included -->
<!-- NOTE: this element was probably unused in vcard-temp -->
<xsl:for-each select='/vCard/NOTE'>
<note><text><xsl:value-of select='.'/></text></note>
</xsl:for-each>
<!-- PRODID can be included exactly once -->
<!-- NOTE: this element was probably unused in vcard-temp -->
<xsl:if test='$PRODID.count=1'>
<prodid><text><xsl:value-of select='.'/></text></prodid>
</xsl:if>
<!-- REV can be included exactly once -->
<!-- NOTE: this element was probably unused in vcard-temp -->
<xsl:if test='$REV.count=1'>
<rev><timestamp><xsl:value-of select='.'/></timestamp></rev>
</xsl:if>
<!-- one or more SORT-STRING elements can be included -->
<!-- this element maps to SORT-AS in vCard4 -->
<xsl:for-each select='/vCard/SORT-STRING'>
<sort-as><xsl:value-of select='.'/></sort-as>
</xsl:for-each>
<!-- one or more SOUND elements can be included -->
<!-- NOTE: for some reason, vcard-temp allowed a <PHONETIC/>
child element, but that was not documented in the
original Dawson I-Ds and is not supported in vCard4 -->
<xsl:for-each select='/vCard/SOUND'>
<xsl:variable name='SOUND.ext' select='count(EXTVAL)'/>
<xsl:variable name='SOUND.bin' select='count(BINVAL)'/>
<xsl:choose>
<xsl:when test='$SOUND.ext=1'>
<sound><uri><xsl:value-of select='EXTVAL'/></uri></sound>
</xsl:when>
<xsl:when test='$SOUND.ext=1'>
<sound>
<uri><xsl:text>data:audio/basic;base64,</xsl:text><xsl:value-of select='BINVAL'/>
</uri>
</sound>
</xsl:when>
<xsl:otherwise>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
<!-- UID can be included exactly once -->
<xsl:if test='$UID.count=1'>
<uid><uri><xsl:value-of select='/vCard/UID'/></uri></uid>
</xsl:if>
<!-- URL can be included one or more times -->
<xsl:for-each select='/vCard/URL'>