-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrfc9554.xml
1313 lines (1240 loc) · 56.9 KB
/
rfc9554.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 rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" submissionType="IETF" category="std" consensus="true" xml:lang="en" docName="draft-ietf-calext-vcard-jscontact-extensions-11" number="9554" obsoletes="" updates="6350" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<front>
<!--[rfced] *AD, changes were submitted twice after the document was
initially approved. Please review the updates from version 10 to
version 12 and let us know if you approve. The updates can be
viewed in this diff file:
https://www.rfc-editor.org/authors/rfc9554-ad-diff.html
-->
<!--[rfced] Would it be correct to make "Extension" plural in the
document title since the document discusses several extensions?
If not, should "Extensions" be made singular in the short title
for consistency? Please review.
Document Title
Original:
vCard Format Extension for JSContact
Perhaps:
vCard Format Extensions for JSContact
...
Short Title
Original:
vCard JSContact Extensions
-->
<title abbrev="vCard JSContact Extensions">vCard Format Extensions for JSContact</title>
<seriesInfo name="RFC" value="9554"/>
<author initials="R." surname="Stepanek" fullname="Robert Stepanek">
<organization>Fastmail</organization>
<address>
<postal>
<extaddr>PO Box 234</extaddr>
<street>Collins St. West</street>
<city>Melbourne</city>
<region>VIC</region>
<code>8007</code>
<country>Australia</country>
</postal>
<email>rsto@fastmailteam.com</email>
</address>
</author>
<author initials="M." surname="Loffredo" fullname="Mario Loffredo">
<organization>IIT-CNR</organization>
<address>
<postal>
<street>Via Moruzzi, 1</street>
<city>Pisa</city>
<code>56124</code>
<country>Italy</country>
<region></region>
</postal>
<email>mario.loffredo@iit.cnr.it</email>
</address>
</author>
<date year="2024" month="March"/>
<area>art</area>
<workgroup>calext</workgroup>
<keyword>addressbook</keyword>
<keyword>contacts</keyword>
<keyword>cards</keyword>
<keyword>vCard</keyword>
<keyword>JSContact</keyword>
<abstract>
<t>
This document defines a set of new properties for vCard and extends the use of existing ones. Their primary purpose is to align the same set of features between the JSContact and vCard formats, but the new definitions also aim to be useful within just the vCard format. This document updates RFC 6350 ("vCard Format Specification").
</t>
</abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>
The JSContact <xref target="RFC9553"/> format aims to be an alternative to the
vCard <xref target="RFC6350"/> format for representation of contact and address book
data. As such, it introduces new semantics that are not covered in the current
definition of vCard and its various extensions. Converting contact data between
the two formats is defined in <xref target="RFC9555"/> with the goal of
not losing any semantics during conversion. To achieve this, this document
defines a new set of properties for vCard and extends existing definitions.
</t>
<section anchor="notational-conventions" numbered="true" toc="default">
<name>Notational Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="abnf-notations">
<name>ABNF Notations</name>
<t>The ABNF definitions in this document use the notations of <xref target="RFC5234"/>. ABNF rules not defined in this document are defined in either <xref target="RFC5234"/> (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT) or <xref target="RFC6350"/>.
</t>
</section>
</section>
<section>
<name>Updated Properties</name>
<section anchor="prop-adr">
<name>ADR</name>
<!--[rfced] For consistency and to match the companion documents, we
removed the quote marks from the "ADR" property, "N" property,
and "TYPE" parameter. Please let us know of any objections.
-->
<t>This specification modifies the definition of the ADR property. It extends its structured value with additional address components to better support the variety of international addresses. It separates the address parts, which currently are typically combined in street address component values, into distinct components.</t>
<t>Implementations <bcp14>SHOULD</bcp14> write a combined value of these components in the street address component for backwards compatibility, but they <bcp14>SHOULD</bcp14> ignore the street component during reads if the ADR property value contains any of the new components.</t>
<t>The following change is made to the first paragraph under "Special note", as originally specified in <xref target="RFC6350" sectionFormat="of" section="6.3.1"/>. The remaining paragraphs of that section in the original specification still apply.</t>
<t>
<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
Special note: The structured type value consists of a sequence of
address components. The component values <bcp14>MUST</bcp14> be specified in
their corresponding position. The structured type value
corresponds, in sequence, to the</t>
<ul spacing="compact" empty="true">
<li> post office box;</li>
<li> extended address (e.g., apartment or suite number);</li>
<li> street address;</li>
<li> locality (e.g., city);</li>
<li> region (e.g., state or province);</li>
<li> postal code;</li>
<li> country name (full name in the language specified in
<xref target="RFC6350" sectionFormat="of" section="5.1"/>);</li>
<li> room, suite number, or identifier;</li>
<li> apartment number, extension designation, or box number;</li>
<li> building floor or level;</li>
<li> street number;</li>
<li> street name;</li>
<li> building, tower, or condominium;</li>
<li> block name or number;</li>
<li> subdistrict;</li>
<li> district;</li>
<li> landmark or another publicly known prominent feature that can substitute the street name and number (e.g., "White House" and "Taj Mahal"); and </li>
<li> the cardinal direction or quadrant (e.g., "north").</li>
</ul>
<t>The following change is made to the definition of "ADR-value" under "ABNF", as originally specified in <xref target="RFC6350" sectionFormat="of" section="6.3.1"/>.</t>
<!-- [rfced] Please review whether the "type" attribute should be set for
all sourcecode elements in the XML file. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
contain an applicable type, then feel free to suggest a new one.
Also, it is acceptable to leave the "type" attribute not set. -->
<!--[rfced] When we attempted to validate the ABNF using <https://author-tools.ietf.org/abnf>, we received the following error.
Please review and let us know how we may fix this.
(130:0): error: Rule SCRIPT was already defined on line 123 of
parsing failed: 1 errors encountered
-->
<!--[rfced] The following three lines exceed the 72-character limit
within the sourcecode. Please review and let us know where you
prefer to place the line breaks.
Original
Section 2.1:
ADR-component-streetnumber ";" ADR-component-streetname ";" (2 characters over)
;;123 Main Street;Any Town;CA;91921-1234;U.S.A.;;123;Main Street;;;;;;; (4 over)
Section 4.6:
phonetic-value = "ipa" / "piny" / "jyut" / "script" / iana-token / x-name (7 over)
-->
<t>ABNF</t>
<sourcecode name="" type="abnf"><![CDATA[
ADR-value = ; defined in RFC 6350, Section 6.3.1.:
ADR-component-pobox ";"
ADR-component-ext ";"
ADR-component-street ";"
ADR-component-locality ";"
ADR-component-region ";"
ADR-component-code ";"
ADR-component-country ";"
; defined in this document:
ADR-component-room ";"
ADR-component-apartment ";"
ADR-component-floor ";"
ADR-component-streetnumber ";"
ADR-component-streetname ";"
ADR-component-building ";"
ADR-component-block ";"
ADR-component-subdistrict ";"
ADR-component-district ";"
ADR-component-landmark ";"
ADR-component-direction
ADR-component-pobox = list-component
ADR-component-ext = list-component
ADR-component-street = list-component
ADR-component-locality = list-component
ADR-component-region = list-component
ADR-component-code = list-component
ADR-component-country = list-component
ADR-component-room = list-component
ADR-component-apartment = list-component
ADR-component-floor = list-component
ADR-component-streetnumber = list-component
ADR-component-streetname = list-component
ADR-component-building = list-component
ADR-component-block = list-component
ADR-component-subdistrict = list-component
ADR-component-district = list-component
ADR-component-landmark = list-component
ADR-component-direction = list-component
]]></sourcecode>
<!--[rfced] We updated Section "6.2.2" to "6.3.1" in the following
text as Section "6.2.2" is not the correct section reference
(note that the second paragraph is included for context). Please
let us know of any objections.
Original:
The following change is made to the "Example" section, originally
specified in Section 6.2.2 of [RFC6350].
Example: In this example, the post office box and the extended address
components are absent. The street number and name are both added as
separate components and are combined in the street component for backwards
compatibility.
Current:
The following change is made under "Example", as originally
specified in Section 6.3.1 of [RFC6350].
Example: In this example, the post office box and the extended address
components are absent. The street number and name are both added as
separate components and are combined in the street component for
backwards compatibility.
-->
<t>The following change is made under "Example", as originally specified in <xref target="RFC6350" sectionFormat="of" section="6.3.1"/>.</t>
<t>Example: In this example, the post office box and the extended address components are absent. The street number and name are both added as separate components and are combined in the street component for backwards compatibility.</t>
<sourcecode name=""><![CDATA[
ADR;GEO="geo:12.3457,78.910":
;;123 Main Street;Any Town;CA;91921-1234;U.S.A
;;;;123;Main Street;;;;;;
]]></sourcecode>
</section>
<section anchor="prop-n">
<name>N</name>
<t>This specification modifies the definition of the N property. It extends its structured value with additional name components to better support international names and generation markers. In doing so, this also facilitates formatting N property values using the Unicode Common Locale Data Repository (CLDR) Person Name <xref target="CLDRPersonName"/> formatting standard.</t>
<t>One new component is for secondary surnames, because in some cultures, such secondary surname kinds are used to indicate the paternal and maternal family names or generational names indicating father or grandfather. Another new component indicates a generation ("II", "XVI") or parental relation ("Jr.", "Sr.").</t>
<t>Currently, implementations typically place secondary surnames in the family name component and generational markers in the honorific suffixes component. For backwards compatibility, implementations <bcp14>SHOULD</bcp14> add such values to both the newly defined components and their backwards-compatible counterpart. Reading N property values, implementations <bcp14>SHOULD</bcp14> ignore any value in the backwards-compatible component if an equal value is set in the new component accordingly. For example, a "Jr." that occurs in both honorific suffixes and generation should only be handled as a generational marker.</t>
<t>The following change is made to the first paragraph under "Special note", as originally specified in <xref target="RFC6350" sectionFormat="of" section="6.2.2"/>. The remaining paragraphs of that section in the original specification still apply.</t>
<!--[rfced] In Section 6.2.2 of RFC 6350, "Special note" is singular,
but Section 2.2 of this document uses the plural form. Should
"notes" be updated to "note" to match RFC 6350 as shown below, or
do you prefer the plural form?
Original:
Special notes: The structured property value corresponds, in
sequence, to the
Perhaps:
Special note: The structured property value corresponds, in
sequence, to the
-->
<t>Special note: The structured property value corresponds, in
sequence, to the</t>
<ul spacing="compact" empty="true">
<li>family names (also known as surnames);</li>
<li>given names;</li>
<li>additional names;</li>
<li>honorific prefixes;</li>
<li>honorific suffixes;</li>
<li>secondary surname; and</li>
<li>generation.</li>
</ul>
<t>The following change is made under "ABNF", as originally specified in <xref target="RFC6350" sectionFormat="of" section="6.2.2"/>.</t>
<t>ABNF</t>
<sourcecode name="" type="abnf"><![CDATA[
N-param = "VALUE=text" / sort-as-param / language-param
/ altid-param / any-param
N-value = list-component 6(";" list-component)
]]></sourcecode>
<t>The following change is made under "Examples", as originally specified in <xref target="RFC6350" section="6.2.2"/>.</t>
<t>Examples</t>
<sourcecode name=""><![CDATA[
N:Public;John;Quinlan;Mr.;Esq.
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.;;Jr.
]]></sourcecode>
<t>No change is required for the definition of the SORT-AS parameter, but the new components also apply for use with this parameter.</t>
</section>
</section>
<section anchor="new-properties">
<name>New Properties</name>
<section anchor="prop-created">
<name>CREATED</name>
<dl>
<dt>Property name:</dt>
<dd>CREATED</dd>
<dt>Purpose:</dt>
<dd>Defines the date and time when the vCard was created.</dd>
<dt>Value type:</dt>
<dd>A single timestamp value.</dd>
<dt>Cardinality:</dt>
<dd>*1</dd>
<dt>Property parameters:</dt>
<dd>VALUE</dd>
<dt>Description:</dt>
<dd>
This is the timestamp when the vCard was created. Copying the
vCard across systems does not count as a new creation nor
a new revision. Instead, the timestamp value typically
stays unchanged for the existence of the vCard.
</dd>
<dt>Format definition:</dt>
<dd>
<t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[
created = "CREATED" createdparam ":" timestamp
createdparam = *(
;
; The following are OPTIONAL
; but MUST NOT occur more than once.
;
(";" "VALUE" "=" "timestamp") /
;
; The following are OPTIONAL
; and MAY occur more than once.
;
(";" any-param)
;
)
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
CREATED:20220705T093412Z
CREATED;VALUE=TIMESTAMP:20211022T140000-05
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="prop-gramgender">
<name>GRAMGENDER</name>
<dl>
<dt>Property name:</dt>
<dd>GRAMGENDER</dd>
<dt>Purpose:</dt>
<dd>Defines which grammatical gender to use in salutations and other grammatical constructs.
</dd>
<dt>Value type:</dt>
<dd>A single text value that is restricted to an enumerated list of allowed values.</dd>
<dt>Cardinality:</dt>
<dd>*</dd>
<dt>Property parameters:</dt>
<dd>LANGUAGE</dd>
<dt>Description:</dt>
<dd>
<t>
This property defines the grammatical gender that the contact prefers
to be addressed by or referred to as in written or spoken form.
For example, the German language distinguishes by grammatical gender in salutations such as "Sehr geehrte" (feminine) and "Sehr geehrter" (masculine).
Multiple occurrences of this property
<bcp14>MUST</bcp14> be distinguished by the LANGUAGE parameter.
</t>
</dd>
<dt>Format definition:</dt>
<dd><t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[
gramgender = "GRAMGENDER" gramgender-param
":" gramgender-value
gramgender-param =
*(
;
; The following are OPTIONAL
; but MUST NOT occur more than once.
;
(";" language-param) /
;
; The following are OPTIONAL
; and MAY occur more than once.
;
(";" any-param)
;
)
gramgender-value = "animate" /
"common" /
"feminine" /
"inanimate" /
"masculine" /
"neuter" /
iana-token /
x-name
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
GRAMGENDER;LANGUAGE=de:masculine
GRAMGENDER:LANGUAGE=en:neuter
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="prop-language">
<name>LANGUAGE</name>
<dl>
<dt>Property name:</dt>
<dd>LANGUAGE</dd>
<dt>Purpose:</dt>
<dd>Defines the default language that human-readable text values in this vCard are assumed to be written in.</dd>
<dt>Value type:</dt>
<dd>A single Language-Tag value as defined in <xref target="RFC6350" sectionFormat="of" section="4"/>.</dd>
<dt>Cardinality:</dt>
<dd>*1</dd>
<dt>Property parameters:</dt>
<dd>The LANGUAGE parameter <bcp14>MUST NOT</bcp14> be assigned to this property.</dd>
<dt>Description:</dt>
<!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.
Please review carefully and let us know if the output is acceptable or if any
updates are needed.
Additionally, note that <tt> appears to be used inconsistently. For example,
some instances of "LANGUAGE" are enclosed with <tt> and some are not.
Please review the terms and let us know if any further updates are needed
for consistency.
-->
<dd>
This property defines the language that property values of type
TEXT are assumed to be written in for this vCard.
If a vCard property includes the LANGUAGE parameter, then the
parameter value has higher precedence than the LANGUAGE
property value.
</dd>
<dt>Format definition:</dt>
<dd>
<t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[
language-prop = "LANGUAGE" any-param ":" Language-Tag
; Language-Tag is defined in RFC 6350, Section 4.
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
LANGUAGE:de-AT
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="prop-pronouns">
<name>PRONOUNS</name>
<dl>
<dt>Property name:</dt>
<dd>PRONOUNS</dd>
<dt>Purpose:</dt>
<dd>
Defines the pronouns that shall be used
to refer to the entity represented by this vCard.
</dd>
<dt>Value type:</dt>
<dd>A single text value.</dd>
<dt>Cardinality:</dt>
<dd>*</dd>
<dt>Property parameters:</dt>
<dd>LANGUAGE, PREF, TYPE, ALTID</dd>
<dt>Description:</dt>
<dd>
This property contains the pronouns that the contact chooses to use for themselves.
The value is free-form text. These pronouns shall be used
when addressing or referring to the contact. Multiple occurrences of
this property <bcp14>MAY</bcp14> define pronouns for multiple languages,
preferences, and contexts. Multiple pronouns in the same language
<bcp14>SHOULD</bcp14> use the PREF parameter; otherwise, the order of
preference is implementation-specific.
</dd>
<dt>Format definition:</dt>
<dd>
<t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[
pronouns = "PRONOUNS" pronouns-param ":" text
pronouns-param =
*(
;
; The following are OPTIONAL
; but MUST NOT occur more than once.
;
(";" language-param) /
(";" pref-param) /
(";" type-param) /
(";" altid-param) /
;
; The following are OPTIONAL
; and MAY occur more than once.
;
(";" any-param)
;
)
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
PRONOUNS;LANGUAGE=en;PREF=1:xe/xir
PRONOUNS;LANGUAGE=en;PREF=2:they/them
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="prop-socialprofile">
<name>SOCIALPROFILE</name>
<dl>
<dt>Property name:</dt>
<dd>SOCIALPROFILE</dd>
<dt>Purpose:</dt>
<dd>Specifies the URI or username for social media profiles associated with the object the vCard represents.</dd>
<dt>Value type:</dt>
<dd>A single URI or TEXT value. The default value type is URI.</dd>
<dt>Cardinality:</dt>
<dd>*</dd>
<dt>Property parameters:</dt>
<dd>The SERVICE-TYPE parameter <bcp14>MUST</bcp14> be assigned to this property if the value type is TEXT, and it <bcp14>MAY</bcp14> be assigned if the value type is URI. In either case, it <bcp14>MUST NOT</bcp14> be assigned more than once.</dd>
<dt>Description:</dt>
<dd>
Several vCard address book implementations currently use an experimental X-SOCIALPROFILE property to store social media profiles for contacts. This specification provides an IANA-registered property for the same purpose. In addition to the typical use of this property with URI values, it also allows setting usernames for social media services as free-text TEXT values, in which case the service name <bcp14>MUST</bcp14> be provided as a parameter. Names <bcp14>MUST</bcp14> be considered equal if they match case-insensitively.
</dd>
<dt>Format definition:</dt>
<dd>
<t>This property is defined by the following notation:</t>
<sourcecode name="" type="abnf"><![CDATA[
socialpr = "SOCIALPROFILE" socialpr-param ":"
socialpr-value
socialpr-param = "VALUE=uri" / "VALUE=text" /
service-type-param / any-param
socialpr-value = URI / text
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo
SOCIALPROFILE:https://example.com/ietf
SOCIALPROFILE;SERVICE-TYPE=SomeSite;VALUE=text:peter94
]]></sourcecode>
</dd>
</dl>
</section>
</section>
<section anchor="new-parameters">
<name>New Parameters</name>
<section anchor="param-author">
<name>AUTHOR</name>
<dl>
<dt>Parameter name:</dt>
<dd>AUTHOR</dd>
<dt>Purpose:</dt>
<dd>Identifies the author of the associated property value.</dd>
<dt>Description:</dt>
<dd>
<t>This parameter <bcp14>MAY</bcp14> be set on any property where conveying authorship is desired. It identifies the author as a URI <xref target="RFC3986"/>. Since every valid URI includes the COLON (U+003A) character, the parameter value <bcp14>MUST</bcp14> be quoted. As an alternative or in addition to this parameter, the AUTHOR-NAME parameter allows naming an author as a free-text value (see <xref target="param-author-name"/>).</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
author-param = "AUTHOR" "=" DQUOTE URI DQUOTE
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
NOTE;AUTHOR="mailto:john@example.com":This is some note.
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-author-name">
<name>AUTHOR-NAME</name>
<dl>
<dt>Parameter name:</dt>
<dd>AUTHOR-NAME</dd>
<dt>Purpose:</dt>
<dd>Names the author of the associated property value.</dd>
<dt>Description:</dt>
<dd>
<t>This parameter <bcp14>MAY</bcp14> be set on any property where conveying authorship is desired. It names the author as a free-text value. The parameter value <bcp14>MUST NOT</bcp14> be empty.
<!--rfced] In the following, do implementations need to quote the name
part in order for the param-value to be valid, as shown below?
Also, is "name part" referring to the parameter? Please let us
know how we may update this sentence for clarity.
Original:
Implementations MUST take care to quote the name part,
if otherwise the part would not be a valid param-value
(see Section 3.3 of [RFC6350]).
Perhaps:
Implementations MUST take care to quote the name part
of the parameter; otherwise, it will not be a valid
param-value (see Section 3.3 of [RFC6350]).
-->
Implementations <bcp14>MUST</bcp14> take care to quote the name part, if otherwise the part would not be a valid "param-value" (see <xref target="RFC6350" sectionFormat="of" section="3.3"/>). As an alternative or in addition to this parameter, the AUTHOR parameter allows identifying an author by URI (see <xref target="param-author"/>).</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
author-name-param = "AUTHOR-NAME" "=" param-value ; not empty
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
NOTE;AUTHOR-NAME=John Doe:This is some note.
NOTE;AUTHOR-NAME="_:l33tHckr:_":A note by an unusual author name.
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-created">
<name>CREATED</name>
<dl>
<dt>Parameter name:</dt>
<dd>CREATED</dd>
<dt>Purpose:</dt>
<dd>Defines the date and time when a property was created in a vCard.</dd>
<dt>Description:</dt>
<dd>
<t>This parameter <bcp14>MAY</bcp14> be set on any property to define the point in time when the property was created. The value <bcp14>MUST</bcp14> be a valid TIMESTAMP value as defined in <xref target="RFC6350" sectionFormat="of" section="4.3.5"/>. Generally, updating a property value <bcp14>SHOULD NOT</bcp14> change the creation timestamp.</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
created-param = "CREATED" "=" param-value ;
; a valid TIMESTAMP of Section 4.3.5 of RFC 6350
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
NOTE;CREATED=20221122T151823Z:This is some note.
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-derived">
<name>DERIVED</name>
<dl>
<dt>Parameter name:</dt>
<dd>DERIVED</dd>
<dt>Purpose:</dt>
<dd>Specifies that the value of the associated property is derived from some other property values in the same vCard.</dd>
<dt>Description:</dt>
<dd>
<t>This property parameter <bcp14>SHOULD</bcp14> be specified on a property if the property value is derived from some other properties in the same vCard. When present with a value of "true", clients <bcp14>MUST NOT</bcp14> update the property.</t>
<t>As an example, an implementation may derive the value of the FN property from the name components of the N property. It indicates this fact by setting the DERIVED parameter on the FN property to "true".</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
derived-param = "DERIVED" "=" ("true" / "false")
; Default is false
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
N:;John;Quinlan;Mr.;
FN;DERIVED=TRUE:Mr. John Quinlan
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-label">
<name>LABEL</name>
<dl>
<dt>Parameter name:</dt>
<dd>LABEL</dd>
<dt>Purpose:</dt>
<dd>Used with the ADR property. Its value contains a formatted text representation of that address, e.g., for delivery.</dd>
<dt>Description:</dt>
<dd>
<t><xref target="RFC6350" sectionFormat="of" section="6.3.1"/> defines the ADR property, noting that the property can also include a LABEL parameter to present a delivery address label for the address. But this parameter was not included in the IANA "vCard Parameters" registry (<xref target="RFC6350" sectionFormat="of" section="10.3.2"/>) and, accordingly, is not a registered standard vCard element. This specification defines and registers the LABEL parameter for use with the ADR property as originally intended.</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
label-param = "LABEL" "=" param-value
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<t>The LABEL parameter as illustrated in the ADR property example in <xref target="RFC6350" sectionFormat="of" section="6.3.1"/>.</t>
<sourcecode name=""><![CDATA[
ADR;LABEL="Mr. John Q. Public, Esq.\nMail Drop: TNE QB\n123
Main Street\nAny Town, CA 91921-1234\nU.S.A.":
;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-phonetic">
<name>PHONETIC</name>
<dl>
<dt>Parameter name:</dt>
<dd>PHONETIC</dd>
<dt>Purpose:</dt>
<dd>Defines how to pronounce the value of another property in the same vCard.</dd>
<dt>Description:</dt>
<dd>
<t>This property parameter indicates that the value of its property contains the phonetic representation of another same-named property in the same vCard. Exemplary uses are defining how to pronounce Japanese names and romanizing Mandarin or Cantonese names and address components.</t>
<t>The parameter value indicates the phonetic system and <bcp14>MUST</bcp14> be one of the values enumerated in the IANA <xref target="iana-vcard-param-values">"vCard Parameter Values" registry</xref>. This specification defines the following values:</t>
<!--[rfced] FYI: We listed the following terms in alphabetical order
to match how they are listed in Table 4 (Section 7.4) and the
"vCard Parameter Values" registry
<https://www.iana.org/assignments/vcard-elements/>.
Original:
ipa: denotes the International Phonetic Alphabet [IPA].
piny: denotes the Standard Mandarin romanization system "Hanyu Pinyin".
jyut: denotes the Cantonese romanization system "Jyutping".
script: denotes the unknown phonetic system. The SCRIPT (Section 4.8)
parameter MUST be set in addition to the PHONETIC parameter.
Current:
ipa: denotes the International Phonetic Alphabet [IPA].
jyut: denotes the Cantonese romanization system "Jyutping".
piny: denotes the Standard Mandarin romanization system "Hanyu Pinyin".
script: denotes the unknown phonetic system. The SCRIPT (Section 4.8)
parameter MUST be set in addition to the PHONETIC parameter.
-->
<dl>
<dt>"ipa":</dt><dd> denotes the <xref target="IPA">International Phonetic Alphabet</xref>.</dd>
<dt>"jyut":</dt><dd> denotes the Cantonese romanization system "Jyutping".</dd>
<dt>"piny":</dt><dd> denotes the Standard Mandarin romanization system "Hanyu Pinyin".</dd>
<dt>"script":</dt><dd> denotes the unknown phonetic system. The <xref target="param-script">SCRIPT</xref> parameter <bcp14>MUST</bcp14> be set in addition to the PHONETIC parameter.</dd>
</dl>
<t>The value type of the property on which the PHONETIC parameter is set <bcp14>MUST</bcp14> be of the same type as its related property. If a component value is set in the property on which the PHONETIC parameter is set, then a component value also <bcp14>MUST</bcp14> be set at that same position in the related property. On the other hand, not every component value in the related property needs to have a phonetic representation.</t>
<t>The ALTID (<xref target="RFC6350" sectionFormat="of" section="5.4"/>) parameter <bcp14>MUST</bcp14> be set with equal values on both the related property and the property having the PHONETIC parameter set.
<!--[rfced] Should "MAY not" be updated as "MUST NOT" in the
following? Please review.
Original:
If more than one same-named property
has both the PHONETIC parameter set and an equal ALTID parameter
value, then at most one of these properties MAY not have the
LANGUAGE parameter set and all others MUST have the LANGUAGE
parameter set.
Perhaps:
If more than one same-named property
has both the PHONETIC parameter set and an equal ALTID parameter
value, then at most, one of these properties MUST NOT have the
LANGUAGE parameter set, and all others MUST have the LANGUAGE
parameter set.
-->
If more than one same-named property has both the PHONETIC parameter set and an equal ALTID parameter value, then at most, one of these properties <bcp14>MAY</bcp14> not have the LANGUAGE parameter set, and all others <bcp14>MUST</bcp14> have the LANGUAGE parameter set. The LANGUAGE parameters <bcp14>MUST NOT</bcp14> have equal values. The LANGUAGE parameter value <bcp14>SHOULD NOT</bcp14> contain a script subtag in its Language-Tag value, and any such subtag <bcp14>MUST</bcp14> be ignored in favor of the <xref target="param-script">SCRIPT</xref> parameter value.</t>
<t>This specification defines the PHONETIC parameter for use with the ADR and N properties.</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
phonetic-param = "PHONETIC=" phonetic-value
phonetic-value = "ipa" / "piny" / "jyut" / "script" /
iana-token / x-name
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
N;ALTID=1;LANGUAGE=zh-Hant:孫;中山;文,逸仙;;;;
N;ALTID=1;PHONETIC=jyut;
SCRIPT=Latn;LANGUAGE=yue:syun1;zung1saan1;man4,jat6sin1;;;;
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-propid">
<name>PROP-ID</name>
<dl>
<dt>Parameter name:</dt>
<dd>PROP-ID</dd>
<dt>Purpose:</dt>
<dd>Identifies a property among all its siblings of the same property name.</dd>
<dt>Description:</dt>
<dd>
<t>
This parameter uniquely identifies a property among all of its siblings with the same name within a vCard. A valid PROP-ID value must be of 1 and a maximum of 255 octets in size, and it <bcp14>MUST</bcp14> only contain the ASCII alphanumeric characters ("A-Za-z0-9"), hyphen (-), and underscore ("_"). The identifier's only purpose is to uniquely identify siblings; its value has no other meaning. If an application makes use of PROP-ID, it <bcp14>SHOULD</bcp14> assign a unique identifier to each sibling property of the same name within their embedding component. The same identifier <bcp14>MAY</bcp14> be used for properties of a different name, and it <bcp14>MAY</bcp14> also be assigned to a same-named property that is not a sibling.
</t>
<t>
Resolving duplicate identifier conflicts is specific to the application. Similarly, handling properties where some but not all siblings have a PROP-ID assigned is application-specific.
</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
prop-id-param = "PROP-ID" "=" 1*255(ALPHA / DIGIT / "-"/ "_")
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
PHOTO;PROP-ID=p827:data:image/jpeg;base64,MIICajCCAdOgAwIBAg
<...remainder of base64-encoded data...>
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-script">
<name>SCRIPT</name>
<dl>
<dt>Parameter name:</dt>
<dd>SCRIPT</dd>
<dt>Purpose:</dt>
<dd>Defines the script that a property value is written in.</dd>
<dt>Description:</dt>
<dd>
<t>This parameter allows defining a script for a property value without also defining a language as the LANGUAGE parameter would. The value <bcp14>MUST</bcp14> be a script subtag as defined in <xref target="RFC5646" sectionFormat="of" section="2.2.3"/>. This specification makes use of the SCRIPT parameter in combination with the <xref target="param-phonetic">PHONETIC</xref> parameter. </t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
script-param = 4ALPHA
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
SCRIPT=Latn
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-service-type">
<name>SERVICE-TYPE</name>
<dl>
<dt>Parameter name:</dt>
<dd>SERVICE-TYPE</dd>
<dt>Purpose:</dt>
<dd>Defines the online service name associated with a messaging or social media profile.</dd>
<dt>Description:</dt>
<dd>
<t>This parameter <bcp14>MAY</bcp14> be specified on an IMPP or a SOCIALPROFILE property to name the online service associated with that property value. Its value is case-sensitive; its letter cases <bcp14>MUST</bcp14> be preserved.</t>
<t>Several vCard address book implementations currently use an experimental X-SERVICE-TYPE parameter. This specification provides an IANA-registered parameter for the same purpose.</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
service-type-param = "SERVICE-TYPE" "=" param-value
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
SOCIALPROFILE;SERVICE-TYPE=Mastodon:https://example.com/@foo
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="param-username">
<name>USERNAME</name>
<dl>
<dt>Parameter name:</dt>
<dd>USERNAME</dd>
<dt>Purpose:</dt>
<dd>Defines a username such as the user of a messaging or social media service.</dd>
<dt>Description:</dt>
<dd>
<t>This parameter <bcp14>MAY</bcp14> be specified on an IMPP or a SOCIALPROFILE property to name the user with that property value. Its value is case-sensitive; its letter cases <bcp14>MUST</bcp14> be preserved. The IMPP or SOCIALPROFILE value type <bcp14>MUST</bcp14> be URI.</t>
</dd>
<dt>Format definition:</dt>
<dd>
<sourcecode name="" type="abnf"><![CDATA[
username-param = "USERNAME" "=" param-value
]]></sourcecode>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
SOCIALPROFILE;USERNAME="The Foo":https://example.com/@foo
]]></sourcecode>
</dd>
</dl>
</section>
</section>
<section anchor="new-values">
<name>New Values</name>
<section anchor="value-adr-type-billing">
<name>Billing Address Type Value</name>
<dl>
<dt>Value:</dt>
<dd>billing</dd>
<dt>Purpose:</dt>
<dd>Indicates using this address for billing, e.g., to send invoices to.</dd>
<dt>Conformance:</dt>
<dd>
<t>This value can be used with the TYPE parameter applied on the ADR property.</t>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
ADR;TYPE=billing:;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
]]></sourcecode>
</dd>
</dl>
</section>
<section anchor="value-adr-type-delivery">
<name>Delivery Address Type Value</name>
<dl>
<dt>Value:</dt>
<dd>delivery</dd>
<dt>Purpose:</dt>
<dd>Indicates using this address for delivery, e.g., to send packages to.</dd>
<dt>Conformance:</dt>
<dd>
<t>This value can be used with the TYPE parameter applied on the ADR property.</t>
</dd>
<dt>Example(s):</dt>
<dd>
<sourcecode name=""><![CDATA[
ADR;TYPE=delivery:;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
]]></sourcecode>
</dd>
</dl>
</section>
</section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This specification extends "vCard Format Specification" <xref target="RFC6350"/>. The same security considerations as outlined in <xref target="RFC6350" sectionFormat="of" section="9"/> apply.</t>
</section>
<section anchor="IANA">
<name>IANA Considerations</name>
<section>
<name>Changes to the vCard Properties Registry</name>
<section>
<name>New vCard Property Definitions</name>
<t>IANA has added the following entries to the "vCard Properties" registry, as defined in <xref target="RFC6350" sectionFormat="of" section="10.3.1"/>.</t>
<table anchor="new_properties">
<name>New vCard Properties</name>
<thead>
<tr>
<th align="left">Namespace</th>
<th align="left">Property</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td/>
<td align="left">CREATED</td>
<td align="left">RFC 9554, <xref target="prop-created"/></td>
</tr>
<tr>
<td/>
<td align="left">GRAMGENDER</td>
<td align="left">RFC 9554, <xref target="prop-gramgender"/></td>
</tr>
<tr>
<td/>
<td align="left">LANGUAGE</td>
<td align="left">RFC 9554, <xref target="prop-language"/></td>
</tr>
<tr>
<td/>
<td align="left">PRONOUNS</td>
<td align="left">RFC 9554, <xref target="prop-pronouns"/></td>
</tr>
<tr>