-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxep-0154.xml
1967 lines (1961 loc) · 93.7 KB
/
xep-0154.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>User Profile</title>
<abstract>This document specifies how to represent and manage profile data about IM users and other XMPP entities using the XMPP Data Forms extension.</abstract>
&LEGALNOTICE;
<number>0154</number>
<status>Deferred</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0004</spec>
<spec>XEP-0060</spec>
<spec>XEP-0068</spec>
<spec>XEP-0163</spec>
</dependencies>
<supersedes>
<spec>XEP-0054</spec>
</supersedes>
<supersededby/>
<shortname>TO-BE-ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.6.1</version>
<date>2021-03-04</date>
<initials>mw</initials>
<remark><p>Cross-document editorial adjustments for inclusive language.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2008-04-18</date>
<initials>psa</initials>
<remark><p>Updated to reflect stable PEP protocol; added OpenID field; specified XML schema; changed namespace to conform to XMPP Registrar procedures.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2006-08-02</date>
<initials>psa</initials>
<remark><p>Updated to reflect changes to XEP-0163; added some mappings to the eduPerson object class.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2006-01-16</date>
<initials>psa</initials>
<remark><p>Defined data management methods using IQ and the PEP subset of pubsub; added various data fields from LDAP; changed namespace from profiledata to profile.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2005-11-11</date>
<initials>psa</initials>
<remark><p>Added postaladdress, fav_chatrooms, alt_contact, teams; added various security-related fields.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2005-07-25</date>
<initials>psa</initials>
<remark><p>Added mappings to common LDAP schemas.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2005-06-16</date>
<initials>psa</initials>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.5</version>
<date>2005-06-13</date>
<initials>psa</initials>
<remark><p>Defined how to handle vCard types such as home vs. work addresses.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2005-04-07</date>
<initials>psa</initials>
<remark><p>Reworked field standardization; added support for telephony addresses, electronic addresses, and organizational data.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2005-03-11</date>
<initials>psa</initials>
<remark><p>Added open issues.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2005-01-06</date>
<initials>psa</initials>
<remark><p>Explained requirements and design decisions in more detail, especially with regard to extensibility; split photo into two elements (data and URL).</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2004-11-10</date>
<initials>psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>It is widely acknowledged within the Jabber/XMPP community that the &xep0054; specification (<cite>XEP-0054</cite>) has outlived its usefulness. There are several reasons for this conclusion:</p>
<ol>
<li><cite>XEP-0054</cite> is not fully consistent with the Internet-Draft on which it was based.</li>
<li>The Internet-Draft on which it was based was never approved by the IETF.</li>
<li>Because of confusion over aspects of the vcard-temp specification, there exist incompatible implementations.</li>
<li>vCard (&rfc2426;) captures only a limited set of information.</li>
<li>vCard (even in its XML representation <note>For links to the experimental XML representation of vCard, see <cite>XEP-0054</cite>.</note>) is not easily extensible, leading those who develop profiles for specialized communities to "roll their own" protocols, to the detriment of interoperability.</li>
<li>vCard data tends to be monolithic (the basic unit of information is the full vCard, not parts thereof).</li>
<li>The publication model for XEP-0054 is to set the full vCard, rather than only the parts that need to be modified.</li>
<li>The retrieval model for XEP-0054 is to get the full vCard, rather than only the parts that have been modified.</li>
</ol>
<p>Given the weaknesses of vCard, there is interest across the broader Internet community in replacing vCard with something more modern and extensible. Unfortunately, no other standards development organization has developed an alternative to vCard. Part of the challenge is that quite detailed ontologies have been developed that might replace parts of the vCard specification (e.g., the <cite>Extensible Name and Address Language</cite> <note>See <<link url='http://xml.coverpages.org/xnal.html'>http://xml.coverpages.org/xnal.html</link>>.</note> developed by &OASIS;) while less-formal ontologies are being used to represent other parts of the problem space (e.g., &foaf;). The relevant protocols are in flux and it is unclear when (or even if) stability will emerge.</p>
<p>Because of the unsettled landspace and the strong desire within the Jabber/XMPP community to move beyond XEP-0054, this document specifies methods for the representation of profile data in terms of the &xep0004; protocol (further qualified using the standardization concepts specified in &xep0068;) and for the management of profile data using standard IQ request-response semantics as well as, for more frequently-modified data, &xep0060; semantics (specifically the simplified subset of those semantics specified in &xep0163;). The rationale behind these design decisions is provided below.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following requirements for data management:</p>
<ol>
<li>Enable an entity to publish profile data about itself.</li>
<li>Enable requesting entities to retrieve profile data about other entities.</li>
</ol>
<p>This document addresses the following requirements for data representation:</p>
<ol>
<li>Specify how to represent profile data in an XMPP-friendly manner for communication over the wire.</li>
<li>Ensure that the protocol is extensible (e.g., not limited to existing vCard fields).
<note>The extensibility requirement is critically important, because it would be best if the protocol specified herein could be used to represent data used within specialized communities. Examples of such communities include dating services, multiplayer gaming networks, IM services provided by portals and ISPs, and expert-location systems within large corporations. While such communities might use part or all of some common set of data fields (such as fields that map to familiar vCard elements), each community might also want to represent quite disparate kinds of information (dating criteria, favorite games, contact preferences, areas of expertise, and the like). Furthermore, data might be used to profile network actors that are not persons (e.g., bots, services, and other software agents). Therefore, the ideal proposal will provide an extensible framework for representing profile data and will not limit itself to representing the relatively small set of data fields covered by the vCard format.</note>
</li>
<li>Where possible, map profile data fields to existing vCard fields and other common formats.</li>
</ol>
</section1>
<section1 topic='Concepts and Approach' anchor='approach'>
<section2 topic='Data Management' anchor='approach-management'>
<p>There are several possible approaches to representing profile data for communication over XMPP networks, including the following:</p>
<ol>
<li>
<p><strong>IQ (request-and-response) semantics.</strong></p>
<p>In the simplest case, an entity may store its own profile data and provide only the complete profile and only on request, using the request-response semantics of the XMPP &IQ; stanza type. This model is most appropriate for stable entities that are always online and whose profile data does not change frequently, such as servers and server-side components (entities that are not always online or that frequently modify their profile data, such as IM users, may prefer to publish their information to entities that are always online, such as an IM user's server). While it may seem desirable to embed profile data in the responses an entity provides to service discovery information requests using &xep0128;, it is likely that profile data will be quite extensive; therefore, we define a standalone "wrapper" element for profile data, qualified by the 'urn:xmpp:tmp:profile' namespace &NSNOTE;.</p>
</li>
<li>
<p><strong>Pubsub (publish-and-subscribe) semantics.</strong></p>
<p>A more complex model is for an entity to publish its profile data to a publish-subscribe node or nodes and allow other entities to subscribe to that node or nodes, thus receiving notifications whenever the profiled entity updates its data. This model is more appropriate for entities that modify their profile data on a regular basis or when other entities wish to be informed when the profile data changes. Because this model will most likely be used most often by IM users and other intermittently-connected network endpoints, we use the simplified subset of the XMPP publish-subscribe extension defined in <cite>XEP-0163</cite> to implement this model.</p>
</li>
</ol>
</section2>
<section2 topic='Data Representation' anchor='approach-representation'>
<p>As with data management, there are several possible approaches to representing profile data for communication over XMPP networks, including the following:</p>
<ul>
<li>
<p><strong>Structured data formats, such as &xep0080; and &xep0112;.</strong></p>
<p>Such data formats have the advantage of being human-readable. However:</p>
<ol>
<li>They are not easily extensible: developers of specialized community services would need to write their own structured data formats, even to add one new field.</li>
<li>They are not easy to map to backend data storage facilities (e.g., database administrators generally would prefer to have generic database schemas and re-usable code for parsing the XML wire protocol into the database fields).</li>
<li>They would require specialized interface handlers for each data structure, rather than a generic interface handler.</li>
</ol>
</li>
<li>
<p><strong>A format represented by means of &w3rdf;.</strong></p>
<p>An argument could be made that RDF is a reasonable approach for representing profile data for communication over the XMPP network; however, such an argument will not be made in the current proposal. The author has considered RDF and has concluded that there are several reasons why RDF is undesirable as an XMPP wire protocol:</p>
<ol>
<li>RDF exists in an XML representation but the semantics of RDF impose a more complex conceptual structure (data triples) than does XML; this is sub-optimal since unnecessary complexity is to be avoided (see &xep0134;).</li>
<li>RDF requires a specialized parser rather than the normal XML parser that comes standard with all XMPP implementations.</li>
<li>As long as it is possible to define a consistent mapping of profile data to RDF representations, it should be straightforward to convert the XMPP data formats into those RDF representations if desired (e.g., to output a FOAF file).</li>
</ol>
</li>
<li>
<p><strong>A format represented by means of Data Forms (XEP-0004).</strong></p>
<p>The Data Forms protocol defined in XEP-0004 has several advantages for use over XMPP:</p>
<ol>
<li>It can be parsed using an off-the-shelf XML parser.</li>
<li>It is already widely deployed in existing Jabber/XMPP clients, servers, and components.</li>
<li>The data forms protocol is easily extensible.</li>
<li>The Jabber/XMPP community possesses consistent methods for profiling and scoping data forms (as specified in <cite>XEP-0068</cite>).</li>
<li>Data forms have a generic schema that is easy to map to common data storage mechanisms (usually databases).</li>
<li>Data forms provide a consistent abstraction layer for XMPP applications, thus shielding them from changes in the profile data formats being defined by other Internet projects and standards development organizations.</li>
<li>The use of data forms as the medium of representation for communication over the wire does not prevent applications from storing backend profile data in some other underlying format (e.g., RDF or a database).</li>
</ol>
</li>
</ul>
<p>Therefore, this proposal specifies that profile data shall be represented in data forms scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile' &NSNOTE;, in accordance with the field standardization methods defined in <cite>XEP-0068</cite>. For the sake of interoperability, profile data fields that will be in common use SHOULD be registered with the ®ISTRAR; (although they may or may not be defined in a XMPP Extension Protocol specification). Profile data fields that are intended to be used only within the context of a specialized application MAY remain unregistered, but unregistered fields MUST begin with the string "x-" in accordance with Section 3.4 of <cite>XEP-0068</cite>. <note>Alternatively, specialized applications MAY define separate FORM_TYPEs for their particular data elements.</note></p>
<p>The following is a simple and incomplete example of profile data represented via the Data Forms protocol, containing two registered data fields and one unregistered field:</p>
<example caption='A Basic Example'><![CDATA[
<profile xmlns='urn:xmpp:tmp:profile'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:tmp:profile</value>
</field>
<field var='common_name'>
<value>Peter Saint-Andre</value>
</field>
<field var='nickname'>
<value>stpeter</value>
</field>
<field var='x-favorite_painters'>
<value>Joaquin Sorolla</value>
<value>Jan Vermeer</value>
</field>
</x>
</profile>
]]></example>
<p>By specifying that all fields are scoped by a FORM_TYPE of 'urn:xmpp:tmp:profile', this proposal does not mean to imply that all profile data will or should be gathered in one data form. In reality, most such data will probably be gathered at the time of registration either at a website or via a "wizard" interface that breaks the process into smaller bundles (such as "Basic Personal Data", "Physical Location", "Internet Addresses", "Hobbies and Interests", and "Favorite Things"). The use of one FORM_TYPE is simply meant to scope the data fields so that each field is unique within the context of profile data. Any form that uses these fields along with a FORM_TYPE of 'urn:xmpp:tmp:profile' is of the "profile type" (i.e., is a specific instance of that type), which does not limit the number of forms that can be of that type.</p>
<p>However, scoping all data fields with a single FORM_TYPE implies it is necessary to define separate data fields for similar kinds of information. For example, the vCard specification (<cite>RFC 2426</cite>) defines "types" for certains kinds of data, such as email addresses, telephone numbers, and physical addresses, making it possible to specify that a telephone number corresponds to a fax machine or mobile phone or that a physical address corresponds to one's home or work location. In the Data Forms representation, any desired piece of information (e.g., work phone) must be represented with a separate data field.</p>
<p>In order to address most (if not all) of the pieces of information described in existing profile specifications, this document defines a great number of data fields. Even so, the data fields specified herein are not exhaustive, and it is expected that additional fields will be registered in the future through the mechanisms specified in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
</section2>
</section1>
<section1 topic='Producer Use Cases' anchor='producer'>
<section2 topic='Publishing a Full Profile' anchor='producer-full'>
<p>In order to publish a full profile, an entity sends an IQ-set to its server with a child element of <profile/> containing the full profile information.</p>
<example caption='Entity publishes full profile'><![CDATA[
<iq type='set' id='setfull'>
<profile xmlns='urn:xmpp:tmp:profile'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:tmp:profile</value>
</field>
<field var='nickname'>
<value>Hamlet</value>
</field>
<field var='country'>
<value>DK</value>
</field>
<field var='locality'>
<value>Elsinore</value>
</field>
<field var='email'>
<value>hamlet@denmark.lit</value>
</field>
</x>
</profile>
</iq>
]]></example>
<p>If the server can successfully process the request and host the full profile, it MUST return an IQ-result:</p>
<example caption='Server acknowledges success'><![CDATA[
<iq type='result' to='hamlet@denmark.lit/elsinore' id='setfull'/>
]]></example>
<p>Otherwise it MUST return an error. If the server does not support the profile data functionality, the error MUST be &unavailable;.</p>
</section2>
<section2 topic='Updating One or More Profile Fields' anchor='producer-pub'>
<p>In order to update selected fields in a public profile, an entity simply publishes the modified fields (not the entire profile) to a pubsub node of "urn:xmpp:tmp:profile" at its server using the PEP subset of the publish-subscribe extension, as specified in <cite>XEP-0163</cite>.</p>
<example caption='Account owner publishes profile field(s)'><![CDATA[
<iq type='set' id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:tmp:profile'>
<item>
<profile xmlns='urn:xmpp:tmp:profile'>
<x xmlns='jabber:x:data' type='result'>
<field var='weblog'>
<value>http://www.denmark.lit/blogs/princely_musings</value>
</field>
</x>
</profile>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<p>The PEP service then MUST send notifications containing the updated field(s) to the node subscribers:</p>
<example caption='Server generates notifications'><![CDATA[
<message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:tmp:profile'>
<item>
<profile xmlns='urn:xmpp:tmp:profile'>
<x xmlns='jabber:x:data' type='result'>
<field var='weblog'>
<value>http://www.denmark.lit/blogs/princely_musings</value>
</field>
</x>
</profile>
</item>
</items>
</event>
</message>
.
.
.
]]></example>
<p>If the field(s) published are "public", the publisher SHOULD then repost the full profile as described above in order to keep the full profile in sync.</p>
<p>Note: The account owner MAY decide to effectively maintain two profile subsets: public profile fields (posted via the "full profile" protocol) and restricted profile fields (published only via PEP). If so, the client MUST keep track of which fields are in the public profile subset and which fields are in the restricted profile subset, and MUST NOT update the full profile if the account owner has updated a field in the restricted profile set.</p>
</section2>
</section1>
<section1 topic='Consumer Use Cases' anchor='consumer'>
<section2 topic='Discovering Support' anchor='consumer-disco'>
<p>If an entity can provide profile data directly using the standalone 'urn:xmpp:tmp:profile' namespace, it SHOULD advertise that feature in response to &xep0030; information requests:</p>
<example caption='A request for service discovery information'><![CDATA[
<iq type='get'
from='bard@shakespeare.lit/globe'
to='hamlet@denmark.lit'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A service discovery information response'><![CDATA[
<iq type='result'
from='hamlet@denmark.lit'
to='bard@shakespeare.lit/globe'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='account' type='registered'/>
<identity category='pubsub' type='pep'/>
...
<feature var='urn:xmpp:tmp:profile'/>
...
</query>
</iq>
]]></example>
<p>Note: Because the foregoing request was sent to the bare JID <hamlet@denmark.lit>, the response is provided by the <denmark.lit> server on behalf of the registered account. The answer indicates that the server can provide profile data on behalf of the registered account and that it supports the personal eventing profile of XMPP Publish-Subscribe.</p>
</section2>
<section2 topic='Requesting Full Profile' anchor='consumer-full'>
<p>In order to request the full profile, the requesting entity sends an IQ-get to the providing entity's JID, where the request contains an empty <profile/> element qualified by the 'urn:xmpp:tmp:profile' namespace. In this example, the request is sent to a server, not a user (any XMPP entity can have a profile, including servers, gateways, &xep0045; rooms, and the like):</p>
<example caption='A request for profile data'><![CDATA[
<iq type='get'
from='hamlet@denmark.lit/elsinore'
to='shakespeare.lit'
id='iq1'>
<profile xmlns='urn:xmpp:tmp:profile'/>
</iq>
]]></example>
<p>The server then replies:</p>
<example caption='A basic profile data response'><![CDATA[
<iq type='result'
from='shakespeare.lit'
to='hamlet@denmark.lit/elsinore'
id='iq1'>
<profile xmlns='urn:xmpp:tmp:profile'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:tmp:profile</value>
</field>
<field var='common_name'>
<value>shakespeare.lit IM server</value>
</field>
<field var='country'>
<value>UK</value>
</field>
<field var='region'>
<value>England</value>
</field>
<field var='locality'>
<value>London</value>
</field>
<field var='area'>
<value>Bankside</value>
</field>
<field var='street'>
<value>21 New Globe Walk</value>
</field>
<field var='postalcode'>
<value>SE1 9DT</value>
</field>
<field var='lat'>
<value>51.5076</value>
</field>
<field var='lon'>
<value>-0.0953</value>
</field>
<field var='landline_phone'>
<value>+44 20 7902 1400</value>
</field>
<field var='fax'>
<value>+44 20 7902 1401</value>
</field>
<field var='building'>
<value>Globe Theatre</value>
</field>
<field var='email'>
<value>admin@shakespeare.lit</value>
</field>
</x>
</profile>
</iq>
]]></example>
<p>If a server supports stored profile data for user accounts that it hosts, a requesting entity can request the full profile for such an account:</p>
<example caption='A request for hosted profile data'><![CDATA[
<iq type='get'
from='bard@shakespeare.lit/globe'
to='hamlet@denmark.lit'
id='iq2'>
<profile xmlns='urn:xmpp:tmp:profile'/>
</iq>
]]></example>
<p>If the requesting entity is not allowed to retrieve hosted profiles (e.g., because it is not on a list of entities permitted to "spider" the server's users), the server SHOULD return a &unavailable; error:</p>
<example caption='Server returns service unavailable error'><![CDATA[
<iq type='error'
from='hamlet@denmark.lit'
to='bard@shakespeare.lit/globe'
id='iq2'>
<profile xmlns='urn:xmpp:tmp:profile'/>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>If the requested account does not exist or has not published profile data, the server also SHOULD return a &unavailable; error.</p>
<p>Otherwise, the server SHOULD return the profile for the hosted account.</p>
<example caption='Server returns profile data'><![CDATA[
<iq type='result'
from='hamlet@denmark.lit'
to='bard@shakespeare.lit/globe'
id='iq2'>
<profile xmlns='urn:xmpp:tmp:profile'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:tmp:profile</value>
</field>
<field var='nickname'>
<value>Hamlet</value>
</field>
<field var='country'>
<value>DK</value>
</field>
<field var='locality'>
<value>Elsinore</value>
</field>
<field var='email'>
<value>hamlet@denmark.lit</value>
</field>
<field var='weblog'>
<value>http://www.denmark.lit/blogs/princely_musings</value>
</field>
</x>
</profile>
</iq>
]]></example>
</section2>
<section2 topic='Receiving Profile Updates' anchor='consumer-sub'>
<p>In order to receive updated fields for a contact's profile, an entity shall encapsulate a feature of "urn:xmpp:tmp:profile+notify" in its &xep0115; data. If the contact's server supports the personal eventing profile of XMPP Publish-Subscribe as described in <cite>XEP-0163</cite>, the entity will receive notifications whenever the contact sends updated profile fields to the profile node:</p>
<example caption='Entity receives notification'><![CDATA[
<message to='francisco@denmark.lit' from='hamlet@denmark.lit/elsinore' type='headline' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:tmp:profile'>
<item>
<profile xmlns='urn:xmpp:tmp:profile'>
<x xmlns='jabber:x:data' type='result'>
<field var='weblog'>
<value>http://www.denmark.lit/blogs/princely_musings</value>
</field>
</x>
</profile>
</item>
</items>
</event>
</message>
]]></example>
<p>It is the responsibility of the receiving entity to correctly process the notification and update the local representation of the contact's profile information.</p>
</section2>
</section1>
<section1 topic='Data Representation' anchor='fields'>
<p>The following subsections specify common fields for defining various aspects of a person, which shall form the initial submission to the XMPP Registrar; many of these fields map to elements specified in vCard, xNAL, FOAF, LDAP (see &rfc2252;, &rfc2256;, and &rfc2798;) <note>This specification does not require that profile data fields mapped to LDAP fields must adhere to the X.500 data types that are re-used by LDAP. However, implementations MAY enforce those data types if desired.</note>, and LDAP object classes such as Person, organizationalPerson, inetOrgPerson, and eduPerson.</p>
<section2 topic='Name Data Aspects' anchor='fields-name'>
<p>Mappings are provided to vCard, LDAP, xNAL, and FOAF.</p>
<section3 topic='Display Name' anchor='display_name'>
<p>A display name is a version of a person's name intended for display in a user interface. Sometimes also called a "full name" or "formatted name".</p>
<p>The Data Forms field that represents a display name is "display_name".</p>
<p>This field maps to:</p>
<ul>
<li>vCard FN</li>
<li>LDAP displayName</li>
<li>FOAF name</li>
</ul>
<example caption='Display Name'><![CDATA[
<field var='display_name'>
<value>Peter Saint-Andre</value>
</field>
]]></example>
</section3>
<section3 topic='Familiar Name' anchor='familiar_name'>
<p>A familiar name is a shortened or modified form of someone's given name that may be used in somewhat informal contexts or that is preferred by the person (e.g., "Chuck" instead of "Charles").</p>
<p>The Data Forms field that represents a familiar name is "familiar_name".</p>
<p>This field maps to:</p>
<ul>
<li>eduPersonNickname</li>
</ul>
<example caption='Familiar Name'><![CDATA[
<field var='familiar_name'>
<value>Pete</value>
</field>
]]></example>
</section3>
<section3 topic='Family Name' anchor='family_name'>
<p>A family name is that part of a person's name which signifies the person's primary family association. Sometimes also called a "last name" or "surname".</p>
<p>The Data Forms field that represents a family name is "family_name".</p>
<p>This field maps to:</p>
<ul>
<li>vCard FAMILY</li>
<li>LDAP sn</li>
<li>xNAL LastName</li>
<li>FOAF family_name</li>
<li>FOAF surname</li>
</ul>
<example caption='Family Name'><![CDATA[
<field var='family_name'>
<value>Saint-Andre</value>
</field>
]]></example>
</section3>
<section3 topic='Given Name' anchor='given_name'>
<p>A given name is that part of a person's name which signifies the person's primary individual identity. Sometimes also called a "first name" or (in some countries) a "Christian name".</p>
<p>The Data Forms field that represents a given name is "given_name".</p>
<p>This field maps to:</p>
<ul>
<li>vCard GIVEN</li>
<li>LDAP givenName</li>
<li>xNAL FirstName</li>
<li>FOAF first_name</li>
<li>FOAF givenname</li>
</ul>
<example caption='Given Name'><![CDATA[
<field var='given_name'>
<value>J.</value>
</field>
]]></example>
</section3>
<section3 topic='Middle Name' anchor='middle_name'>
<p>A middle name is that part of a person's name which signifies the person's secondary individual identity. Sometimes also called a "middle initial".</p>
<p>The Data Forms field that represents a middle name is "middle_name".</p>
<p>This field maps to:</p>
<ul>
<li>vCard MIDDLE</li>
<li>xNAL MiddleName</li>
</ul>
<example caption='Middle Name'><![CDATA[
<field var='middle_name'>
<value>Peter</value>
</field>
]]></example>
</section3>
<section3 topic='Name Prefix' anchor='name_prefix'>
<p>A name prefix is that part of a person's name which prepends the person's full name (e.g., Mr or Dr). Sometimes also called an "honorific" or "title".</p>
<p>The Data Forms field that represents a name prefix is "name_prefix".</p>
<p>This field maps to:</p>
<ul>
<li>vCard PREFIX</li>
<li>xNAL Title</li>
<li>FOAF title</li>
</ul>
<example caption='Name Prefix'><![CDATA[
<field var='name_prefix'>
<value>Mr</value>
</field>
]]></example>
</section3>
<section3 topic='Name Suffix' anchor='name_suffix'>
<p>A name suffix is that part of a person's name which is appended to the person's full name (e.g., Jr or Esq).</p>
<p>The Data Forms field that represents a name suffix is "name_suffix".</p>
<p>This field maps to:</p>
<ul>
<li>vCard SUFFIX</li>
<li>xNAL GeneralSuffix</li>
</ul>
<example caption='Name Suffix'><![CDATA[
<field var='name_suffix'>
<value>Esq</value>
</field>
]]></example>
</section3>
<section3 topic='Nickname' anchor='nickname'>
<p>A nickname is a global, memorable (but not unique) friendly or informal name chosen by the owner of a JID. The purpose of a nickname is to associate a distinctive mapping between the person's unique JID and non-unique nickname. A nickname is normally used in online contexts (e.g., in chatrooms) that are less formal than real life (where a person's <link url='#familiar_name'>Familiar Name</link> would be more appropriate). Sometimes also called an "alias". A person SHOULD specify only one nickname (i.e., not more than one).</p>
<p>The Data Forms field that represents a nickname is "nickname".</p>
<p>This field maps to:</p>
<ul>
<li>vCard NICKNAME</li>
<li>xNAL Alias</li>
<li>FOAF nick</li>
</ul>
<example caption='Nickname'><![CDATA[
<field var='nickname'>
<value>stpeter</value>
</field>
]]></example>
</section3>
<section3 topic='Patronymic' anchor='patronymic'>
<p>In some cultures, one's name includes a part that is derived from the given name of one's father; this part of one's name is called a "patronymic".</p>
<p>The Data Forms field that represents a patronymic is "patronymic".</p>
<example caption='A Patronymic'><![CDATA[
<field var='patronymic'>
<value>Ivanovich</value>
</field>
]]></example>
</section3>
</section2>
<section2 topic='Physical Address Data Aspects' anchor='fields-physicaladdress'>
<p>Mappings are provided to vCard, xNAL, and XEP-0112 (&xep0112;).</p>
<section3 topic='Country' anchor='country'>
<p>A country is the sovereign nation in which a person is located. Sometimes also called a "nation".</p>
<p>The Data Forms fields that represent a country are "country", "home_country", and "work_country" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard COUNTRY (or XEP-0054 CTRY), optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP c</li>
<li>xNAL CountryName</li>
<li>XEP-0112 country</li>
</ul>
<example caption='Country'><![CDATA[
<field var='country'>
<value>USA</value>
</field>
]]></example>
</section3>
<section3 topic='Region' anchor='region'>
<p>A region is a second-level administrative unit within the nation in which a person is located. Sometimes also called a "province", "state", or "administrative area".</p>
<p>The Data Forms field that represents a region is "region".</p>
<p>The Data Forms fields that represent a region are "home_region" and "work_region" for home addresses and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard REGION, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP st</li>
<li>xNAL AdministrativeAreaName</li>
<li>XEP-0112 region</li>
</ul>
<example caption='Region'><![CDATA[
<field var='region'>
<value>New York</value>
</field>
]]></example>
</section3>
<section3 topic='Locality' anchor='locality'>
<p>A locality is a defined place within the region in which a person is located. Sometimes also called a "city", "town", or "village".</p>
<p>The Data Forms fields that represent a locality are "locality", "home_locality", and "work_locality" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard LOCALITY, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP l</li>
<li>xNAL LocalityName</li>
<li>XEP-0112 locality</li>
</ul>
<example caption='Locality'><![CDATA[
<field var='locality'>
<value>New York City</value>
</field>
]]></example>
</section3>
<section3 topic='Area' anchor='area'>
<p>An area is a sub-division within the locality in which a person is located. Sometimes also called a "neighborhood", "suburb", "district", or "section".</p>
<p>The Data Forms fields that represent a area are "area", "home_area", and "work_area" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>xNAL DependentLocalityName</li>
<li>XEP-0112 area</li>
</ul>
<example caption='Area'><![CDATA[
<field var='area'>
<value>Manhattan</value>
</field>
]]></example>
</section3>
<section3 topic='Street' anchor='street'>
<p>A street is the street address (number plus street name, or two street names at an intersection) at which a person is located, or a postal box number for physical mail delivery. Sometimes also called a "street address".</p>
<p>The Data Forms fields that represent a street are "street", "home_street", and "work_street" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard STREET, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP street</li>
<li>xNAL ThoroughfareNumber + ThoroughfareName</li>
<li>XEP-0112 street</li>
</ul>
<example caption='Street'><![CDATA[
<field var='street'>
<value>Fifth Avenue and 34th Street</value>
</field>
]]></example>
</section3>
<section3 topic='Building' anchor='building'>
<p>A building is the name for a specific structure on a street or within an area.</p>
<p>The Data Forms fields that represent a building are "building", "home_building", and "work_building" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<li>xNAL BuildingName</li>
<li>XEP-0112 building</li>
</ul>
<example caption='Building'><![CDATA[
<field var='building'>
<value>Empire State Building</value>
</field>
]]></example>
</section3>
<section3 topic='Floor' anchor='floor'>
<p>A floor is a named or numbered floor or level within a building. Sometimes also called a "level", "block", or "suite".</p>
<p>The Data Forms fields that represent a floor are "floor", "home_floor", and "work_floor" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<li>xNAL SubPremiseNumber</li>
<li>XEP-0112 floor</li>
</ul>
<example caption='Floor'><![CDATA[
<field var='floor'>
<value>102</value>
</field>
]]></example>
</section3>
<section3 topic='Room' anchor='room'>
<p>A room is a named or numbered subdivision of a floor. Sometimes also called a "unit" or "apartment".</p>
<p>The Data Forms fields that represent a room are "room", "home_room", and "work_room" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard EXTADR, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP roomNumber</li>
<li>xNAL SubPremiseNumber</li>
<li>XEP-0112 room</li>
</ul>
<example caption='Room'><![CDATA[
<field var='room'>
<value>Observatory</value>
</field>
]]></example>
</section3>
<section3 topic='Postal Box' anchor='postalbox'>
<p>A postal box is a set of numeric or alphanumeric characters used to identify a mailbox at a postal delivery center.</p>
<p>The Data Forms fields that represent a postal box are "postalbox", "home_postalbox", and "work_postalbox" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard POBOX, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP postOfficeBox</li>
</ul>
<example caption='Postal Box'><![CDATA[
<field var='postalbox'>
<value>1641</value>
</field>
]]></example>
</section3>
<section3 topic='Postal Code' anchor='postalcode'>
<p>A postal code is a set of numeric or alphanumeric characters used to identify an area for postal delivery. Sometimes also called a "ZIP code" (in the U.S.).</p>
<p>The Data Forms fields that represent a postal code are "postalcode", "home_postalcode", and "work_postalcode" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard PCODE, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP postalCode</li>
<li>xNAL PostalCodeNumber</li>
<li>XEP-0112 postalcode</li>
</ul>
<example caption='Postal Code'><![CDATA[
<field var='postalcode'>
<value>10002</value>
</field>
]]></example>
</section3>
<section3 topic='Postal Address' anchor='postaladdress'>
<p>A postal address is a free-form mailing address, which may be easier to enter (or, in some cultural contexts, more appropriate) than the atomic address parts such as street, floor, etc.</p>
<p>The Data Forms fields that represent a postal address are "postaladdress", "home_postaladdress", and "work_postaladdress" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>LDAP postalAddress, homePostalAddress</li>
</ul>
<example caption='Postal Address'><![CDATA[
<field var='work_postaladdress'>
<value>1899 Wynkoop Street</value>
<value>Suite 600</value>
<value>Denver, CO 80202</value>
<value>USA</value>
</field>
]]></example>
</section3>
</section2>
<section2 topic='Geolocation Data Aspects' anchor='fields-geoloc'>
<p>Mappings are provided to vCard and XEP-0080 (&xep0080;).</p>
<section3 topic='Altitude' anchor='alt'>
<p>Altitude is a person's height or depth in relationship to sea level, where positive altitude is meters above sea level and negative altitude is meters below sea level.</p>
<p>The Data Forms field that represents altitude is "alt".</p>
<p>This field maps to:</p>
<ul>
<li>XEP-0080 alt</li>
</ul>
<example caption='Altitude'><![CDATA[
<field var='alt'>
<value>1609</value>
</field>
]]></example>
</section3>
<section3 topic='Latitude' anchor='lat'>
<p>Latitude is a person's latitude in relation to the equator, where positive latitude is north of the equator and negative latitude is south of the equator.</p>
<p>The Data Forms field that represents latitude is "lat".</p>
<p>This field maps to:</p>
<ul>
<li>vCard LAT</li>
<li>XEP-0080 lat</li>
</ul>
<example caption='Latitude'><![CDATA[
<field var='lat'>
<value>39.75477</value>
</field>
]]></example>
</section3>
<section3 topic='Longitude' anchor='lon'>
<p>Longitude is a person's longitude in relation to the equator, where positive longitude is east of the meridian and negative longitude is west of the equator.</p>
<p>The Data Forms field that represents longitude is "lon".</p>
<p>This field maps to:</p>
<ul>
<li>vCard LON</li>
<li>XEP-0080 lon</li>
</ul>
<example caption='Latitude'><![CDATA[
<field var='lon'>
<value>-104.99768</value>
</field>
]]></example>
</section3>
</section2>
<section2 topic='Telephony Address Data Aspects' anchor='fields-tel'>
<section3 topic='Fax Number' anchor='fax'>
<p>A fax number is a number for a machine that handles fascimile transmissions.</p>
<p>The Data Forms fields that represent a fax number are "fax", "home_fax", and "work_fax" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL (+ "FAX" modifier), optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP facsimileTelephoneNumber</li>
</ul>
<example caption='Fax Number'><![CDATA[
<field var='fax'>
<value>303-308-3215</value>
</field>
]]></example>
</section3>
<section3 topic='Landline Telephone Number' anchor='landline'>
<p>A landline telephone number is a number for a traditional "PSTN" or "POTS" telephone.</p>
<p>The Data Forms fields that represent a landline telephone number are "landline", "home_landline", and "work_landline" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL, optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP telephoneNumber</li>
<li>FOAF phone</li>
</ul>
<example caption='Landline Telephone Number'><![CDATA[
<field var='landline_phone'>
<value>303-308-3282</value>
</field>
]]></example>
</section3>
<section3 topic='Mobile Telephone Number' anchor='mobile'>
<p>A mobile telephone number is a number for a mobile phone or cell phone on a wireless network.</p>
<p>The Data Forms fields that represent a mobile telephone number are "mobile", "home_mobile", and "work_mobile" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL (+ "CELL" modifier), optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP mobile</li>
<li>FOAF phone</li>
</ul>
<example caption='Mobile Telephone Number'><![CDATA[
<field var='mobile_phone'>
<value>303-555-1212</value>
</field>
]]></example>
</section3>
<section3 topic='Pager Number' anchor='pager'>
<p>A pager number is a number for a dedicated alphanumeric paging device.</p>
<p>The Data Forms fields that represent a pager number are "pager", "home_pager", and "work_pager" for generic addresses, home addresses, and work addresses respectively.</p>
<p>This field maps to:</p>
<ul>
<li>vCard TEL (+ "PAGER" modifier), optionally supplemented with the "HOME" or "WORK" type</li>
<li>LDAP pager</li>
</ul>
<example caption='Pager Number'><![CDATA[
<field var='pager'>
<value>303-555-1212</value>
</field>
]]></example>
</section3>
<section3 topic='SIP Address' anchor='sip_address'>
<p>A SIP address is a sip: or sips: URI at which a person can be contacted for Voice over Internet Protocol (VoIP) communications.</p>
<p>The Data Forms field that represents a SIP address is "sip_address".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<example caption='SIP Address'><![CDATA[
<field var='sip_address'>
<value>sip:stpeter@sipspeare.lit</value>
</field>
]]></example>
</section3>
<section3 topic='Skype Address' anchor='skype_address'>
<p>A Skype address is an address on the popular Skype system for Voice over Internet Protocol (VoIP) communications.</p>
<p>The Data Forms field that represents a Skype address is "skype_address".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<example caption='Skype Address'><![CDATA[
<field var='skype_address'>
<value>SomeSkypeUser</value>
</field>
]]></example>
</section3>
<section3 topic='Videophone Address' anchor='video_phone'>
<p>A videophone address is an address used for for H.323 video conferencing systems.</p>
<p>The Data Forms field that represents a videophone address is "video_phone".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<example caption='Videophone Address'><![CDATA[
<field var='video_phone'>
<value>foo</value>
</field>
]]></example>
</section3>
</section2>
<section2 topic='Electronic Address Data Aspects' anchor='fields-net'>
<section3 topic='AIM Screen Name' anchor='aim_id'>
<p>An AIM screen name is an address at which a person or other entity can be contacted on the AOL Instant Messenger service.</p>
<p>The Data Forms field that represents an AIM screen name is "aim_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF aimChatID</li>
</ul>
<example caption='AIM Screen Name'><![CDATA[
<field var='aim_id'>
<value>psaintandre</value>
</field>
]]></example>
</section3>
<section3 topic='Email Address' anchor='email'>
<p>An email address is the value of a mailto: URI at which a person or other entity can be contacted using standard electronic mail protocols.</p>
<p>The Data Forms field that represents longitude is "email".</p>
<p>This field maps to:</p>
<ul>
<li>vCard EMAIL</li>
<li>LDAP mail</li>
</ul>
<example caption='Email address'><![CDATA[
<field var='email'>
<value>stpeter@jabber.org</value>
<value>stpeter@gmail.com</value>
</field>
]]></example>
</section3>
<section3 topic='ICQ Number' anchor='icq_id'>
<p>An ICQ number is an address at which a person or other entity can be contacted on the ICQ instant messaging service.</p>
<p>The Data Forms field that represents an ICQ number is "icq_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF icqChatID</li>
</ul>
<example caption='ICQ number'><![CDATA[
<field var='icq_id'>
<value>70902454</value>
</field>
]]></example>
</section3>
<section3 topic='Jabber ID' anchor='jid'>
<p>A Jabber ID is the value of an xmpp: URI at which a person or other entity can be contacted over a Jabber/XMPP network.</p>
<p>The Data Forms field that represents a Jabber ID is "jid".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF jabberID</li>
</ul>
<example caption='Jabber ID'><![CDATA[
<field var='jid'>
<value>stpeter@jabber.org</value>
<value>peter@saint-andre.com</value>
</field>
]]></example>
</section3>
<section3 topic='MSN Address' anchor='msn_id'>
<p>An MSN address is address at which a person or other entity can be contacted on the MSN instant messaging service.</p>
<p>The Data Forms field that represents an MSN address is "msn_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF msnChatID</li>
</ul>
<example caption='MSN Address'><![CDATA[
<field var='msn_id'>
<value>petersaintandre@hotmail.com</value>
</field>
]]></example>
</section3>
<section3 topic='Yahoo ID' anchor='yahoo_id'>
<p>A Yahoo ID is address at which a person or other entity can be contacted on the Yahoo! Instant Messenger service.</p>
<p>The Data Forms field that represents a Yahoo ID is "yahoo_id".</p>
<p>This field maps to:</p>
<ul>
<li>FOAF yahooChatID</li>
</ul>
<example caption='Yahoo ID'><![CDATA[
<field var='yahoo_id'>
<value>psaintandre</value>
</field>
]]></example>
</section3>
</section2>
<section2 topic='World Wide Web Resource Aspects' anchor='fields-www'>
<section3 topic='Avatar URL' anchor='avatar_url'>
<p>An avatar is an often fanciful representation of a user's desired self-image or persona (e.g., in the context of a game). An avatar is usually not intended to be an accurate picture of the user's actual physical appearance (that is handled by the photo_url and photo_data fields).</p>
<p>An avatar can come in two forms: the avatar data itself, or a URL for a avatar.</p>
<p>The Data Forms field that represents the URL for an avatar is "avatar_url".</p>
<p>This field does not map to data in vCard or any other profile representation format.</p>
<example caption='Avatar URL'><![CDATA[
<field var='avatar_url'>
<value>http://www.saint-andre.com/images/stpeter_small.jpg</value>
</field>
]]></example>
</section3>
<section3 topic='Biographical URL' anchor='bio'>
<p>A biographical URL is the value of an http: URI at which can be found biographical information about a person.</p>
<p>The Data Forms field that represents a biographical URL is "bio".</p>
<example caption='Biographical URL'><![CDATA[
<field var='bio'>
<value>http://www.xmpp.org/xsf/people/stpeter.shtml</value>
<value>http://www.saint-andre.com/me/</value>
</field>
]]></example>
</section3>
<section3 topic='FOAF URL' anchor='foaf_url'>
<p>A FOAF URL is the value of an http: URI at which can be found a "friend of a friend" (FOAF) file about a person or entity.</p>
<p>The Data Forms field that represents a FOAF URL is "foaf_url".</p>