metanorma-cli 1.5.15pre1 → 1.5.15.pre.alpha

Sign up to get free protection for your applications and to get access to all the features.
data/exe/rfc6350.xml ADDED
@@ -0,0 +1,3319 @@
1
+ <?xml version="1.0" encoding="US-ASCII"?>
2
+ <?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
3
+ <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
4
+ <?rfc comments="yes"?>
5
+ <?rfc rfcedstyle="yes"?>
6
+ <?rfc strict="yes"?>
7
+ <?rfc compact="yes"?>
8
+ <?rfc subcompact="no"?>
9
+ <?rfc toc="yes"?>
10
+ <?rfc tocdepth="4"?>
11
+ <?rfc symrefs="yes"?>
12
+ <?rfc sortrefs="yes"?>
13
+ <rfc ipr="pre5378Trust200902" obsoletes="2425, 2426, 4770" updates="2739" category="std" submissionType="IETF" number="6350">
14
+ <front>
15
+ <title abbrev="vCard">vCard Format Specification</title>
16
+ <author fullname="Simon Perreault" surname="Perreault" initials="S.">
17
+ <organization>Viagenie</organization>
18
+ <address>
19
+ <postal>
20
+ <street>2875 Laurier, suite D2-630</street>
21
+ <region>Quebec, QC</region>
22
+ <code>G1V 2M2</code>
23
+ <country>Canada</country>
24
+ </postal>
25
+ <phone>+1 418 656 9254</phone>
26
+ <email>simon.perreault@viagenie.ca</email>
27
+ <uri>http://www.viagenie.ca</uri>
28
+ </address>
29
+ </author>
30
+ <date month="August" year="2011"/>
31
+
32
+ <abstract>
33
+ <t>This document defines the vCard data format for representing and
34
+ exchanging a variety of information about individuals and other
35
+ entities (e.g., formatted and structured name and delivery addresses,
36
+ email address, multiple telephone numbers, photograph, logo, audio
37
+ clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and
38
+ updates RFC 2739.</t>
39
+ </abstract>
40
+ </front><middle>
41
+ <section anchor="section1" title="Introduction"><t>Electronic address books have become ubiquitous. Their increased
42
+ presence on portable, connected devices as well as the diversity of
43
+ platforms that exchange contact data call for a standard. This memo
44
+ defines the vCard format, which allows the capture and exchange of
45
+ information normally stored within an address book or directory
46
+ application.</t>
47
+ <t>A high-level overview of the differences from RFCs 2425 and 2426 can
48
+ be found in <xref target="appendixA"/>.</t></section>
49
+ <section anchor="section2" title="Conventions">
50
+ <t>The key words "<spanx style="strong">MUST</spanx>", "<spanx style="strong">MUST NOT</spanx>", "<spanx style="strong">REQUIRED</spanx>", "<spanx style="strong">SHALL</spanx>", "<spanx style="strong">SHALL NOT</spanx>",
51
+ "<spanx style="strong">SHOULD</spanx>", "<spanx style="strong">SHOULD NOT</spanx>", "<spanx style="strong">RECOMMENDED</spanx>", "<spanx style="strong">NOT RECOMMENDED</spanx>", "<spanx style="strong">MAY</spanx>", and
52
+ "<spanx style="strong">OPTIONAL</spanx>" in this document are to be interpreted as described in
53
+ cite:norm[RFC2119].</t>
54
+ </section>
55
+ <section anchor="section3" title="vCard Format Specification"><t>The text/vcard MIME content type (hereafter known as "vCard"; see
56
+ <xref target="section10_1"/>) contains contact information, typically pertaining to a
57
+ single contact or group of contacts. The content consists of one or
58
+ more lines in the format given below.</t>
59
+ <section anchor="section3_1" title="Charset">
60
+ <t>The charset (see cite:info[RFC3536] for internationalization terminology) for
61
+ vCard is UTF-8 as defined in cite:norm[RFC3629]. There is no way to override
62
+ this. It is invalid to specify a value other than "UTF-8" in the
63
+ "charset" MIME parameter (see <xref target="section10_1"/>).</t>
64
+ </section>
65
+ <section anchor="section3_2" title="Line Delimiting and Folding"><t>Individual lines within vCard are delimited by the cite:norm[RFC5322] line
66
+ break, which is a CRLF sequence (U+000D followed by U+000A). Long
67
+ logical lines of text can be split into a multiple-physical-line
68
+ representation using the following folding technique. Content lines
69
+ <spanx style="strong">SHOULD</spanx> be folded to a maximum width of 75 octets, excluding the line
70
+ break. Multi-octet characters <spanx style="strong">MUST</spanx> remain contiguous. The rationale
71
+ for this folding process can be found in cite:norm[RFC5322, suffix=", Section 2.1.1"].</t>
72
+ <t>A logical line <spanx style="strong">MAY</spanx> be continued on the next physical line anywhere
73
+ between two characters by inserting a CRLF immediately followed by a
74
+ single white space character (space (U+0020) or horizontal tab
75
+ (U+0009)). The folded line <spanx style="strong">MUST</spanx> contain at least one character. Any
76
+ sequence of CRLF followed immediately by a single white space
77
+ character is ignored (removed) when processing the content type. For
78
+ example, the line:</t>
79
+ <figure>
80
+ <artwork><![CDATA[
81
+ NOTE:This is a long description that exists on a long line.
82
+ ]]></artwork>
83
+ </figure>
84
+ <t>can be represented as:</t>
85
+ <figure>
86
+ <artwork><![CDATA[
87
+ NOTE:This is a long description
88
+ that exists on a long line.
89
+ ]]></artwork>
90
+ </figure>
91
+ <t>It could also be represented as:</t>
92
+ <figure>
93
+ <artwork><![CDATA[
94
+ NOTE:This is a long descrip
95
+ tion that exists o
96
+ n a long line.
97
+ ]]></artwork>
98
+ </figure>
99
+ <t>The process of moving from this folded multiple-line representation
100
+ of a property definition to its single-line representation is called
101
+ unfolding. Unfolding is accomplished by regarding CRLF immediately
102
+ followed by a white space character (namely, HTAB (U+0009) or SPACE
103
+ (U+0020)) as equivalent to no characters at all (i.e., the CRLF and
104
+ single white space character are removed).</t>
105
+ <t>Note: It is possible for very simple implementations to generate
106
+ improperly folded lines in the middle of a UTF-8 multi-octet
107
+ sequence. For this reason, implementations <spanx style="strong">SHOULD</spanx> unfold lines in
108
+ such a way as to properly restore the original sequence.</t>
109
+ <t>Note: Unfolding is done differently than in cite:norm[RFC5322]. Unfolding
110
+ in cite:norm[RFC5322] only removes the CRLF, not the space following it.</t>
111
+ <t>Folding is done after any content encoding of a type value.
112
+ Unfolding is done before any decoding of a type value in a content
113
+ line.</t></section>
114
+ <section anchor="section3_3" title="ABNF Format Definition"><t>The following ABNF uses the notation of cite:norm[RFC5234], which also defines
115
+ CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.</t>
116
+ <figure>
117
+ <artwork type="abnf"><![CDATA[
118
+ vcard-entity = 1*vcard
119
+
120
+ vcard = "BEGIN:VCARD" CRLF
121
+ "VERSION:4.0" CRLF
122
+ 1*contentline
123
+ "END:VCARD" CRLF
124
+ ; A vCard object MUST include the VERSION and FN properties.
125
+ ; VERSION MUST come immediately after BEGIN:VCARD.
126
+
127
+ contentline = [group "."] name *(";" param) ":" value CRLF
128
+ ; When parsing a content line, folded lines must first
129
+ ; be unfolded according to the unfolding procedure
130
+ ; described in Section 3.2.
131
+ ; When generating a content line, lines longer than 75
132
+ ; characters SHOULD be folded according to the folding
133
+ ; procedure described in Section 3.2.
134
+
135
+ group = 1*(ALPHA / DIGIT / "-")
136
+ name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME"
137
+ / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL"
138
+ / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE"
139
+ / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES"
140
+ / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP"
141
+ / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML"
142
+ / iana-token / x-name
143
+ ; Parsing of the param and value is based on the "name" as
144
+ ; defined in ABNF sections below.
145
+ ; Group and name are case-insensitive.
146
+
147
+ iana-token = 1*(ALPHA / DIGIT / "-")
148
+ ; identifier registered with IANA
149
+
150
+ x-name = "x-" 1*(ALPHA / DIGIT / "-")
151
+ ; Names that begin with "x-" or "X-" are
152
+ ; reserved for experimental use, not intended for released
153
+ ; products, or for use in bilateral agreements.
154
+
155
+ param = language-param / value-param / pref-param / pid-param
156
+ / type-param / geo-parameter / tz-parameter / sort-as-param
157
+ / calscale-param / any-param
158
+ ; Allowed parameters depend on property name.
159
+
160
+ param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE
161
+
162
+ any-param = (iana-token / x-name) "=" param-value *("," param-value)
163
+
164
+ NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4
165
+ ; UTF8-{2,3,4} are defined in [RFC3629]
166
+
167
+ QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
168
+ ; Any character except CTLs, DQUOTE
169
+
170
+ SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
171
+ ; Any character except CTLs, DQUOTE, ";", ":"
172
+
173
+ VALUE-CHAR = WSP / VCHAR / NON-ASCII
174
+ ; Any textual character
175
+ ]]></artwork>
176
+ </figure>
177
+ <t>A line that begins with a white space character is a continuation of
178
+ the previous line, as described in <xref target="section3_2"/>. The white space
179
+ character and immediately preceeding CRLF should be discarded when
180
+ reconstructing the original line. Note that this line-folding
181
+ convention differs from that found in cite:norm[RFC5322], in that the sequence
182
+ &lt;CRLF&gt;&lt;WSP&gt; found anywhere in the content indicates a continued line
183
+ and should be removed.</t>
184
+ <t>Property names and parameter names are case-insensitive (e.g., the
185
+ property name "fn" is the same as "FN" and "Fn"). Parameter values
186
+ <spanx style="strong">MAY</spanx> be case-sensitive or case-insensitive, depending on their
187
+ definition. Parameter values that are not explicitly defined as
188
+ being case-sensitive are case-insensitive. Based on experience with
189
+ vCard 3 interoperability, it is <spanx style="strong">RECOMMENDED</spanx> that property and
190
+ parameter names be upper-case on output.</t>
191
+ <t>The group construct is used to group related properties together.
192
+ The group name is a syntactic convention used to indicate that all
193
+ property names prefaced with the same group name <spanx style="strong">SHOULD</spanx> be grouped
194
+ together when displayed by an application. It has no other
195
+ significance. Implementations that do not understand or support
196
+ grouping <spanx style="strong">MAY</spanx> simply strip off any text before a "." to the left of
197
+ the type name and present the types and values as normal.</t>
198
+ <t>Property cardinalities are indicated using the following notation,
199
+ which is based on ABNF (see cite:norm[RFC5234, suffix=", Section 3.6"]):</t>
200
+ <texttable suppress-title="false" style="full">
201
+ <ttcol align="left">Cardinality</ttcol>
202
+ <ttcol align="left">Meaning</ttcol>
203
+ <c>1</c>
204
+ <c>Exactly one instance per vCard <spanx style="strong">MUST</spanx> be present.</c>
205
+ <c>*1</c>
206
+ <c>Exactly one instance per vCard <spanx style="strong">MAY</spanx> be present.</c>
207
+ <c>1*</c>
208
+ <c>One or more instances per vCard <spanx style="strong">MUST</spanx> be present.</c>
209
+ <c>*</c>
210
+ <c>One or more instances per vCard <spanx style="strong">MAY</spanx> be present.</c>
211
+ </texttable>
212
+ <t>Properties defined in a vCard instance may have multiple values
213
+ depending on the property cardinality. The general rule for encoding
214
+ multi-valued properties is to simply create a new content line for
215
+ each value (including the property name). However, it should be
216
+ noted that some value types support encoding multiple values in a
217
+ single content line by separating the values with a comma ",". This
218
+ approach has been taken for several of the content types defined
219
+ below (date, time, integer, float).</t></section>
220
+ <section anchor="section3_4" title="Property Value Escaping"><t>Some properties may contain one or more values delimited by a COMMA
221
+ character (U+002C). Therefore, a COMMA character in a value <spanx style="strong">MUST</spanx> be
222
+ escaped with a BACKSLASH character (U+005C), even for properties that
223
+ don&#8217;t allow multiple instances (for consistency).</t>
224
+ <t>Some properties (e.g., N and ADR) comprise multiple fields delimited
225
+ by a SEMICOLON character (U+003B). Therefore, a SEMICOLON in a field
226
+ of such a "compound" property <spanx style="strong">MUST</spanx> be escaped with a BACKSLASH
227
+ character. SEMICOLON characters in non-compound properties <spanx style="strong">MAY</spanx> be
228
+ escaped. On input, an escaped SEMICOLON character is never a field
229
+ separator. An unescaped SEMICOLON character may be a field
230
+ separator, depending on the property in which it appears.</t>
231
+ <t>Furthermore, some fields of compound properties may contain a list of
232
+ values delimited by a COMMA character. Therefore, a COMMA character
233
+ in one of a field&#8217;s values <spanx style="strong">MUST</spanx> be escaped with a BACKSLASH
234
+ character, even for fields that don&#8217;t allow multiple values (for
235
+ consistency). Compound properties allowing multiple instances <spanx style="strong">MUST NOT</spanx>
236
+ be encoded in a single content line.</t>
237
+ <t>Finally, BACKSLASH characters in values <spanx style="strong">MUST</spanx> be escaped with a
238
+ BACKSLASH character. NEWLINE (U+000A) characters in values <spanx style="strong">MUST</spanx> be
239
+ encoded by two characters: a BACKSLASH followed by either an 'n'
240
+ (U+006E) or an 'N' (U+004E).</t>
241
+ <t>In all other cases, escaping <spanx style="strong">MUST NOT</spanx> be used.</t></section></section>
242
+ <section anchor="section4" title="Property Value Data Types"><t>Standard value types are defined below.</t>
243
+ <figure>
244
+ <artwork type="abnf"><![CDATA[
245
+ value = text
246
+ / text-list
247
+ / date-list
248
+ / time-list
249
+ / date-time-list
250
+ / date-and-or-time-list
251
+ / timestamp-list
252
+ / boolean
253
+ / integer-list
254
+ / float-list
255
+ / URI ; from Section 3 of [RFC3986]
256
+ / utc-offset
257
+ / Language-Tag
258
+ / iana-valuespec
259
+ ; Actual value type depends on property name and VALUE parameter.
260
+
261
+ text = *TEXT-CHAR
262
+
263
+ TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
264
+ / %x21-2B / %x2D-5B / %x5D-7E
265
+ ; Backslashes, commas, and newlines must be encoded.
266
+
267
+ component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
268
+ / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
269
+ list-component = component *("," component)
270
+
271
+ text-list = text *("," text)
272
+ date-list = date *("," date)
273
+ time-list = time *("," time)
274
+ date-time-list = date-time *("," date-time)
275
+ date-and-or-time-list = date-and-or-time *("," date-and-or-time)
276
+ timestamp-list = timestamp *("," timestamp)
277
+ integer-list = integer *("," integer)
278
+ float-list = float *("," float)
279
+
280
+ boolean = "TRUE" / "FALSE"
281
+ integer = [sign] 1*DIGIT
282
+ float = [sign] 1*DIGIT ["." 1*DIGIT]
283
+
284
+ sign = "+" / "-"
285
+
286
+ year = 4DIGIT ; 0000-9999
287
+ month = 2DIGIT ; 01-12
288
+ day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year
289
+ hour = 2DIGIT ; 00-23
290
+ minute = 2DIGIT ; 00-59
291
+ second = 2DIGIT ; 00-58/59/60 depending on leap second
292
+ zone = utc-designator / utc-offset
293
+ utc-designator = %x5A ; uppercase "Z"
294
+
295
+ date = year [month day]
296
+ / year "-" month
297
+ / "--" month [day]
298
+ / "--" "-" day
299
+ date-noreduc = year month day
300
+ / "--" month day
301
+ / "--" "-" day
302
+ date-complete = year month day
303
+
304
+ time = hour [minute [second]] [zone]
305
+ / "-" minute [second] [zone]
306
+ / "-" "-" second [zone]
307
+ time-notrunc = hour [minute [second]] [zone]
308
+ time-complete = hour minute second [zone]
309
+
310
+
311
+ time-designator = %x54 ; uppercase "T"
312
+ date-time = date-noreduc time-designator time-notrunc
313
+ timestamp = date-complete time-designator time-complete
314
+
315
+ date-and-or-time = date-time / date / time-designator time
316
+
317
+ utc-offset = sign hour [minute]
318
+
319
+ Language-Tag = <Language-Tag, defined in [RFC5646], Section 2.1>
320
+
321
+ iana-valuespec = <value-spec, see Section 12>
322
+ ; a publicly defined valuetype format, registered
323
+ ; with IANA, as defined in Section 12 of this
324
+ ; document.
325
+ ]]></artwork>
326
+ </figure>
327
+ <section anchor="section4_1" title="TEXT"><t>"text": The "text" value type should be used to identify values that
328
+ contain human-readable text. As for the language, it is controlled
329
+ by the LANGUAGE property parameter defined in <xref target="section5_1"/>.</t>
330
+ <t>Examples for "text":</t>
331
+ <figure>
332
+ <artwork><![CDATA[
333
+ this is a text value
334
+ this is one value,this is another
335
+ this is a single value\, with a comma encoded
336
+ ]]></artwork>
337
+ </figure>
338
+ <t>A formatted text line break in a text value type <spanx style="strong">MUST</spanx> be represented
339
+ as the character sequence backslash (U+005C) followed by a Latin
340
+ small letter n (U+006E) or a Latin capital letter N (U+004E), that
341
+ is, "\n" or "\N".</t>
342
+ <t>For example, a multiple line NOTE value of:</t>
343
+ <figure>
344
+ <artwork><![CDATA[
345
+ Mythical Manager
346
+ Hyjinx Software Division
347
+ BabsCo, Inc.
348
+ ]]></artwork>
349
+ </figure>
350
+ <t>could be represented as:</t>
351
+ <figure>
352
+ <artwork><![CDATA[
353
+ NOTE:Mythical Manager\nHyjinx Software Division\n
354
+ BabsCo\, Inc.\n
355
+ ]]></artwork>
356
+ </figure>
357
+ <t>demonstrating the \n literal formatted line break technique, the
358
+ CRLF-followed-by-space line folding technique, and the backslash
359
+ escape technique.</t></section>
360
+ <section anchor="section4_2" title="URI"><t>"uri": The "uri" value type should be used to identify values that
361
+ are referenced by a Uniform Resource Identifier (URI) instead of
362
+ encoded in-line. These value references might be used if the value
363
+ is too large, or otherwise undesirable to include directly. The
364
+ format for the URI is as defined in cite:norm[RFC3986, prefix="Section 3 of "]. Note
365
+ that the value of a property of type "uri" is what the URI points to,
366
+ not the URI itself.</t>
367
+ <t>Examples for "uri":</t>
368
+ <figure>
369
+ <artwork><![CDATA[
370
+ http://www.example.com/my/picture.jpg
371
+ ldap://ldap.example.com/cn=babs%20jensen
372
+ ]]></artwork>
373
+ </figure></section>
374
+ <section anchor="section4_3" title="DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP"><t>"date", "time", "date-time", "date-and-or-time", and "timestamp":
375
+ Each of these value types is based on the definitions in
376
+ cite:norm[ISO.8601.2004]. Multiple such values can be specified using the
377
+ comma-separated notation.</t>
378
+ <t>Only the basic format is supported.</t>
379
+ <section anchor="section4_3_1" title="DATE"><t>A calendar date as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.1.2"].</t>
380
+ <t>Reduced accuracy, as specified in cite:norm[ISO.8601.2004, suffix=", Sections 4.1.2.3"] a)
381
+ and b), but not c), is permitted.</t>
382
+ <t>Expanded representation, as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.1.4"], is forbidden.</t>
383
+ <t>Truncated representation, as specified in cite:norm[ISO.8601.2000, suffix=", Sections 5.2.1.3"] d), e), and f), is permitted.</t>
384
+ <t>Examples for "date":</t>
385
+ <figure>
386
+ <artwork><![CDATA[
387
+ 19850412
388
+ 1985-04
389
+ 1985
390
+ --0412
391
+ ---12
392
+
393
+
394
+
395
+ ]]></artwork>
396
+ </figure>
397
+ <t>Note the use of YYYY-MM in the second example above. YYYYMM is
398
+ disallowed to prevent confusion with YYMMDD. Note also that
399
+ YYYY-MM-DD is disallowed since we are using the basic format instead
400
+ of the extended format.</t></section>
401
+ <section anchor="section4_3_2" title="TIME"><t>A time of day as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.2"].</t>
402
+ <t>Reduced accuracy, as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.2.2.3"],
403
+ is permitted.</t>
404
+ <t>Representation with decimal fraction, as specified in
405
+ cite:norm[ISO.8601.2004, suffix=", Section 4.2.2.4"], is forbidden.</t>
406
+ <t>The midnight hour is always represented by 00, never 24 (see
407
+ cite:norm[ISO.8601.2004, suffix=", Section 4.2.3"]).</t>
408
+ <t>Truncated representation, as specified in cite:norm[ISO.8601.2000, suffix=", Sections 5.3.1.4"] a), b), and c), is permitted.</t>
409
+ <t>Examples for "time":</t>
410
+ <figure>
411
+ <artwork><![CDATA[
412
+ 102200
413
+ 1022
414
+ 10
415
+ -2200
416
+ --00
417
+ 102200Z
418
+ 102200-0800
419
+ ]]></artwork>
420
+ </figure></section>
421
+ <section anchor="section4_3_3" title="DATE-TIME"><t>A date and time of day combination as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.3"].</t>
422
+ <t>Truncation of the date part, as specified in cite:norm[ISO.8601.2000, suffix=", Section 5.4.2"] c), is permitted.</t>
423
+ <t>Examples for "date-time":</t>
424
+ <figure>
425
+ <artwork><![CDATA[
426
+ 19961022T140000
427
+ --1022T1400
428
+ ---22T14
429
+ ]]></artwork>
430
+ </figure></section>
431
+ <section anchor="section4_3_4" title="DATE-AND-OR-TIME"><t>Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous
432
+ interpretation, a stand-alone TIME value is always preceded by a "T".</t>
433
+ <t>Examples for "date-and-or-time":</t>
434
+ <figure>
435
+ <artwork><![CDATA[
436
+ 19961022T140000
437
+ --1022T1400
438
+ ---22T14
439
+ 19850412
440
+ 1985-04
441
+ 1985
442
+ --0412
443
+ ---12
444
+ T102200
445
+ T1022
446
+ T10
447
+ T-2200
448
+ T--00
449
+ T102200Z
450
+ T102200-0800
451
+ ]]></artwork>
452
+ </figure></section>
453
+ <section anchor="section4_3_5" title="TIMESTAMP"><t>A complete date and time of day combination as specified in
454
+ cite:norm[ISO.8601.2004, suffix=", Section 4.3.2"].</t>
455
+ <t>Examples for "timestamp":</t>
456
+ <figure>
457
+ <artwork><![CDATA[
458
+ 19961022T140000
459
+ 19961022T140000Z
460
+ 19961022T140000-05
461
+ 19961022T140000-0500
462
+ ]]></artwork>
463
+ </figure></section></section>
464
+ <section anchor="section4_4" title="BOOLEAN"><t>"boolean": The "boolean" value type is used to express boolean
465
+ values. These values are case-insensitive.</t>
466
+ <t>
467
+ <list style="hanging">
468
+ <t hangText="Examples: "/>
469
+ </list>
470
+ </t>
471
+ <figure>
472
+ <artwork><![CDATA[
473
+ TRUE
474
+ false
475
+ True
476
+ ]]></artwork>
477
+ </figure></section>
478
+ <section anchor="section4_5" title="INTEGER"><t>"integer": The "integer" value type is used to express signed
479
+ integers in decimal format. If sign is not specified, the value is
480
+ assumed positive "+". Multiple "integer" values can be specified
481
+ using the comma-separated notation. The maximum value is
482
+ 9223372036854775807, and the minimum value is -9223372036854775808.
483
+ These limits correspond to a signed 64-bit integer using two&#8217;s-
484
+ complement arithmetic.</t>
485
+ <t>
486
+ <list style="hanging">
487
+ <t hangText="Examples: "/>
488
+ </list>
489
+ </t>
490
+ <figure>
491
+ <artwork><![CDATA[
492
+ 1234567890
493
+ -1234556790
494
+ +1234556790,432109876
495
+ ]]></artwork>
496
+ </figure></section>
497
+ <section anchor="section4_6" title="FLOAT"><t>"float": The "float" value type is used to express real numbers. If
498
+ sign is not specified, the value is assumed positive "+". Multiple
499
+ "float" values can be specified using the comma-separated notation.
500
+ Implementations <spanx style="strong">MUST</spanx> support a precision equal or better than that of
501
+ the IEEE "binary64" format cite:norm[IEEE.754.2008].</t>
502
+ <t>Note: Scientific notation is disallowed. Implementers wishing to
503
+ use their favorite language&#8217;s %f formatting should be careful.</t>
504
+ <t>
505
+ <list style="hanging">
506
+ <t hangText="Examples: "/>
507
+ </list>
508
+ </t>
509
+ <figure>
510
+ <artwork><![CDATA[
511
+ 20.30
512
+ 1000000.0000001
513
+ 1.333,3.14
514
+ ]]></artwork>
515
+ </figure></section>
516
+ <section anchor="section4_7" title="UTC-OFFSET"><t>"utc-offset": The "utc-offset" value type specifies that the property
517
+ value is a signed offset from UTC. This value type can be specified
518
+ in the TZ property.</t>
519
+ <t>The value type is an offset from Coordinated Universal Time (UTC).
520
+ It is specified as a positive or negative difference in units of
521
+ hours and minutes (e.g., +hhmm). The time is specified as a 24-hour
522
+ clock. Hour values are from 00 to 23, and minute values are from 00
523
+ to 59. Hour and minutes are 2 digits with high-order zeroes required
524
+ to maintain digit count. The basic format for ISO 8601 UTC offsets
525
+ <spanx style="strong">MUST</spanx> be used.</t></section>
526
+ <section anchor="section4_8" title="LANGUAGE-TAG">
527
+ <t>"language-tag": A single language tag, as defined in cite:norm[RFC5646].</t>
528
+ </section></section>
529
+ <section anchor="section5" title="Property Parameters"><t>A property can have attributes associated with it. These "property
530
+ parameters" contain meta-information about the property or the
531
+ property value. In some cases, the property parameter can be multi-
532
+ valued in which case the property parameter value elements are
533
+ separated by a COMMA (U+002C).</t>
534
+ <t>Property parameter value elements that contain the COLON (U+003A),
535
+ SEMICOLON (U+003B), or COMMA (U+002C) character separators <spanx style="strong">MUST</spanx> be
536
+ specified as quoted-string text values. Property parameter values
537
+ <spanx style="strong">MUST NOT</spanx> contain the DQUOTE (U+0022) character. The DQUOTE character
538
+ is used as a delimiter for parameter values that contain restricted
539
+ characters or URI text.</t>
540
+ <t>Applications <spanx style="strong">MUST</spanx> ignore x-param and iana-param values they don&#8217;t
541
+ recognize.</t>
542
+ <section anchor="section5_1" title="LANGUAGE"><t>The LANGUAGE property parameter is used to identify data in multiple
543
+ languages. There is no concept of "default" language, except as
544
+ specified by any "Content-Language" MIME header parameter that is
545
+ present cite:info[RFC3282]. The value of the LANGUAGE property parameter is a
546
+ language tag as defined in cite:norm[RFC5646, prefix="Section 2 of "].</t>
547
+ <t>
548
+ <list style="hanging">
549
+ <t hangText="Examples: "/>
550
+ </list>
551
+ </t>
552
+ <figure>
553
+ <artwork><![CDATA[
554
+ ROLE;LANGUAGE=tr:hoca
555
+ ]]></artwork>
556
+ </figure>
557
+ <t>
558
+ <list style="hanging">
559
+ <t hangText="ABNF: "/>
560
+ </list>
561
+ </t>
562
+ <figure>
563
+ <artwork type="abnf"><![CDATA[
564
+ language-param = "LANGUAGE=" Language-Tag
565
+ ; Language-Tag is defined in section 2.1 of RFC 5646
566
+
567
+ ]]></artwork>
568
+ </figure></section>
569
+ <section anchor="section5_2" title="VALUE"><t>The VALUE parameter is <spanx style="strong">OPTIONAL</spanx>, used to identify the value type
570
+ (data type) and format of the value. The use of these predefined
571
+ formats is encouraged even if the value parameter is not explicitly
572
+ used. By defining a standard set of value types and their formats,
573
+ existing parsing and processing code can be leveraged. The
574
+ predefined data type values <spanx style="strong">MUST NOT</spanx> be repeated in COMMA-separated
575
+ value lists except within the N, NICKNAME, ADR, and CATEGORIES
576
+ properties.</t>
577
+ <t>
578
+ <list style="hanging">
579
+ <t hangText="ABNF: "/>
580
+ </list>
581
+ </t>
582
+ <figure>
583
+ <artwork type="abnf"><![CDATA[
584
+ value-param = "VALUE=" value-type
585
+
586
+ value-type = "text"
587
+ / "uri"
588
+ / "date"
589
+ / "time"
590
+ / "date-time"
591
+ / "date-and-or-time"
592
+ / "timestamp"
593
+ / "boolean"
594
+ / "integer"
595
+ / "float"
596
+ / "utc-offset"
597
+ / "language-tag"
598
+ / iana-token ; registered as described in section 12
599
+ / x-name
600
+ ]]></artwork>
601
+ </figure></section>
602
+ <section anchor="section5_3" title="PREF"><t>The PREF parameter is <spanx style="strong">OPTIONAL</spanx> and is used to indicate that the
603
+ corresponding instance of a property is preferred by the vCard
604
+ author. Its value <spanx style="strong">MUST</spanx> be an integer between 1 and 100 that
605
+ quantifies the level of preference. Lower values correspond to a
606
+ higher level of preference, with 1 being most preferred.</t>
607
+ <t>When the parameter is absent, the default <spanx style="strong">MUST</spanx> be to interpret the
608
+ property instance as being least preferred.</t>
609
+ <t>Note that the value of this parameter is to be interpreted only in
610
+ relation to values assigned to other instances of the same property
611
+ in the same vCard. A given value, or the absence of a value, <spanx style="strong">MUST NOT</spanx>
612
+ be interpreted on its own.</t>
613
+ <t>This parameter <spanx style="strong">MAY</spanx> be applied to any property that allows multiple
614
+ instances.</t>
615
+ <t>
616
+ <list style="hanging">
617
+ <t hangText="ABNF: "/>
618
+ </list>
619
+ </t>
620
+ <figure>
621
+ <artwork type="abnf"><![CDATA[
622
+ pref-param = "PREF=" (1*2DIGIT / "100")
623
+ ; An integer between 1 and 100.
624
+ ]]></artwork>
625
+ </figure></section>
626
+ <section anchor="section5_4" title="ALTID"><t>The ALTID parameter is used to "tag" property instances as being
627
+ alternative representations of the same logical property. For
628
+ example, translations of a property in multiple languages generates
629
+ multiple property instances having different LANGUAGE (<xref target="section5_1"/>)
630
+ parameter that are tagged with the same ALTID value.</t>
631
+ <t>This parameter&#8217;s value is treated as an opaque string. Its sole
632
+ purpose is to be compared for equality against other ALTID parameter
633
+ values.</t>
634
+ <t>Two property instances are considered alternative representations of
635
+ the same logical property if and only if their names as well as the
636
+ value of their ALTID parameters are identical. Property instances
637
+ without the ALTID parameter <spanx style="strong">MUST NOT</spanx> be considered an alternative
638
+ representation of any other property instance. Values for the ALTID
639
+ parameter are not globally unique: they <spanx style="strong">MAY</spanx> be reused for different
640
+ property names.</t>
641
+ <t>Property instances having the same ALTID parameter value count as 1
642
+ toward cardinality. Therefore, since N (<xref target="section6_2_2"/>) has
643
+ cardinality *1 and TITLE (<xref target="section6_6_1"/>) has cardinality *, these
644
+ three examples would be legal:</t>
645
+ <figure>
646
+ <artwork><![CDATA[
647
+ N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
648
+ N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
649
+ (<U+XXXX> denotes a UTF8-encoded Unicode character.)
650
+ ]]></artwork>
651
+ </figure>
652
+ <figure>
653
+ <artwork><![CDATA[
654
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
655
+ TITLE;ALTID=1;LANGUAGE=en:Boss
656
+ ]]></artwork>
657
+ </figure>
658
+ <figure>
659
+ <artwork><![CDATA[
660
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
661
+ TITLE;ALTID=1;LANGUAGE=en:Boss
662
+ TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist
663
+ ]]></artwork>
664
+ </figure>
665
+ <t>while this one would not:</t>
666
+ <figure>
667
+ <artwork><![CDATA[
668
+ N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
669
+ N:Yamada;Taro;;;
670
+ (Two instances of the N property.)
671
+ ]]></artwork>
672
+ </figure>
673
+ <t>and these three would be legal but questionable:</t>
674
+ <figure>
675
+ <artwork><![CDATA[
676
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
677
+ TITLE;ALTID=2;LANGUAGE=en:Boss
678
+ (Should probably have the same ALTID value.)
679
+ ]]></artwork>
680
+ </figure>
681
+ <figure>
682
+ <artwork><![CDATA[
683
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
684
+ TITLE:LANGUAGE=en:Boss
685
+ (Second line should probably have ALTID=1.)
686
+ ]]></artwork>
687
+ </figure>
688
+ <figure>
689
+ <artwork><![CDATA[
690
+ N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
691
+ N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
692
+ N;ALTID=1;LANGUAGE=en:Smith;John;;;
693
+ (The last line should probably have ALTID=2. But that would be
694
+ illegal because N has cardinality *1.)
695
+ ]]></artwork>
696
+ </figure>
697
+ <t>The ALTID property <spanx style="strong">MAY</spanx> also be used in may contexts other than with
698
+ the LANGUAGE parameter. Here&#8217;s an example with two representations
699
+ of the same photo in different file formats:</t>
700
+ <figure>
701
+ <artwork><![CDATA[
702
+ PHOTO;ALTID=1:data:image/jpeg;base64,...
703
+ PHOTO;ALTID=1;data:image/jp2;base64,...
704
+
705
+
706
+
707
+ ]]></artwork>
708
+ </figure>
709
+ <t>
710
+ <list style="hanging">
711
+ <t hangText="ABNF: "/>
712
+ </list>
713
+ </t>
714
+ <figure>
715
+ <artwork type="abnf"><![CDATA[
716
+ altid-param = "ALTID=" param-value
717
+ ]]></artwork>
718
+ </figure></section>
719
+ <section anchor="section5_5" title="PID"><t>The PID parameter is used to identify a specific property among
720
+ multiple instances. It plays a role analogous to the UID property
721
+ (<xref target="section6_7_6"/>) on a per-property instead of per-vCard basis. It <spanx style="strong">MAY</spanx>
722
+ appear more than once in a given property. It <spanx style="strong">MUST NOT</spanx> appear on
723
+ properties that may have only one instance per vCard. Its value is
724
+ either a single small positive integer or a pair of small positive
725
+ integers separated by a dot. Multiple values may be encoded in a
726
+ single PID parameter by separating the values with a comma ",". See
727
+ <xref target="section7"/> for more details on its usage.</t>
728
+ <t>
729
+ <list style="hanging">
730
+ <t hangText="ABNF: "/>
731
+ </list>
732
+ </t>
733
+ <figure>
734
+ <artwork type="abnf"><![CDATA[
735
+ pid-param = "PID=" pid-value *("," pid-value)
736
+ pid-value = 1*DIGIT ["." 1*DIGIT]
737
+ ]]></artwork>
738
+ </figure></section>
739
+ <section anchor="section5_6" title="TYPE"><t>The TYPE parameter has multiple, different uses. In general, it is a
740
+ way of specifying class characteristics of the associated property.
741
+ Most of the time, its value is a comma-separated subset of a
742
+ predefined enumeration. In this document, the following properties
743
+ make use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL,
744
+ IMPP, LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES,
745
+ NOTE, SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE
746
+ parameter <spanx style="strong">MUST NOT</spanx> be applied on other properties defined in this
747
+ document.</t>
748
+ <t>The "work" and "home" values act like tags. The "work" value implies
749
+ that the property is related to an individual&#8217;s work place, while the
750
+ "home" value implies that the property is related to an individual&#8217;s
751
+ personal life. When neither "work" nor "home" is present, it is
752
+ implied that the property is related to both an individual&#8217;s work
753
+ place and personal life in the case that the KIND property&#8217;s value is
754
+ "individual", or to none in other cases.</t>
755
+ <t>
756
+ <list style="hanging">
757
+ <t hangText="ABNF: "/>
758
+ </list>
759
+ </t>
760
+ <figure>
761
+ <artwork type="abnf"><![CDATA[
762
+ type-param = "TYPE=" type-value *("," type-value)
763
+
764
+ type-value = "work" / "home" / type-param-tel
765
+ / type-param-related / iana-token / x-name
766
+ ; This is further defined in individual property sections.
767
+ ]]></artwork>
768
+ </figure></section>
769
+ <section anchor="section5_7" title="MEDIATYPE"><t>The MEDIATYPE parameter is used with properties whose value is a URI.
770
+ Its use is <spanx style="strong">OPTIONAL</spanx>. It provides a hint to the vCard consumer
771
+ application about the media type cite:norm[RFC2046] of the resource identified
772
+ by the URI. Some URI schemes do not need this parameter. For
773
+ example, the "data" scheme allows the media type to be explicitly
774
+ indicated as part of the URI cite:info[RFC2397]. Another scheme, "http",
775
+ provides the media type as part of the URI resolution process, with
776
+ the Content-Type HTTP header cite:info[RFC2616]. The MEDIATYPE parameter is
777
+ intended to be used with URI schemes that do not provide such
778
+ functionality (e.g., "ftp" cite:info[RFC1738]).</t>
779
+ <t>
780
+ <list style="hanging">
781
+ <t hangText="ABNF: "/>
782
+ </list>
783
+ </t>
784
+ <figure>
785
+ <artwork type="abnf"><![CDATA[
786
+ mediatype-param = "MEDIATYPE=" mediatype
787
+ mediatype = type-name "/" subtype-name *( ";" attribute "=" value )
788
+ ; "attribute" and "value" are from [RFC2045]
789
+ ; "type-name" and "subtype-name" are from [RFC4288]
790
+ ]]></artwork>
791
+ </figure>
792
+ <t>cite:norm[RFC2045, text="&lt;xref target='RFC2045' format='none'/&gt;"] cite:norm[RFC4288, text="&lt;xref target='RFC4288' format='none'/&gt;"]</t></section>
793
+ <section anchor="section5_8" title="CALSCALE"><t>The CALSCALE parameter is identical to the CALSCALE property in
794
+ iCalendar (see cite:norm[RFC5545, suffix=", Section 3.7.1"]). It is used to define the
795
+ calendar system in which a date or date-time value is expressed. The
796
+ only value specified by iCalendar is "gregorian", which stands for
797
+ the Gregorian system. It is the default when the parameter is
798
+ absent. Additional values may be defined in extension documents and
799
+ registered with IANA (see <xref target="section10_3_4"/>). A vCard implementation
800
+ <spanx style="strong">MUST</spanx> ignore properties with a CALSCALE parameter value that it does
801
+ not understand.</t>
802
+ <t>
803
+ <list style="hanging">
804
+ <t hangText="ABNF: "/>
805
+ </list>
806
+ </t>
807
+ <figure>
808
+ <artwork type="abnf"><![CDATA[
809
+ calscale-param = "CALSCALE=" calscale-value
810
+
811
+ calscale-value = "gregorian" / iana-token / x-name
812
+ ]]></artwork>
813
+ </figure></section>
814
+ <section anchor="section5_9" title="SORT-AS"><t>The "sort-as" parameter is used to specify the string to be used for
815
+ national-language-specific sorting. Without this information,
816
+ sorting algorithms could incorrectly sort this vCard within a
817
+ sequence of sorted vCards. When this property is present in a vCard,
818
+ then the given strings are used for sorting the vCard.</t>
819
+ <t>This parameter&#8217;s value is a comma-separated list that <spanx style="strong">MUST</spanx> have as
820
+ many or fewer elements as the corresponding property value has
821
+ components. This parameter&#8217;s value is case-sensitive.</t>
822
+ <t>
823
+ <list style="hanging">
824
+ <t hangText="ABNF: "/>
825
+ </list>
826
+ </t>
827
+ <figure>
828
+ <artwork type="abnf"><![CDATA[
829
+ sort-as-param = "SORT-AS=" sort-as-value
830
+
831
+ sort-as-value = param-value *("," param-value)
832
+ ]]></artwork>
833
+ </figure>
834
+ <t>Examples: For the case of surname and given name sorting, the
835
+ following examples define common sort string usage with the N
836
+ property.</t>
837
+ <figure>
838
+ <artwork><![CDATA[
839
+ FN:Rene van der Harten
840
+ N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N.
841
+ ]]></artwork>
842
+ </figure>
843
+ <figure>
844
+ <artwork><![CDATA[
845
+ FN:Robert Pau Shou Chang
846
+ N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;;
847
+ ]]></artwork>
848
+ </figure>
849
+ <figure>
850
+ <artwork><![CDATA[
851
+ FN:Osamu Koura
852
+ N;SORT-AS="Koura,Osamu":Koura;Osamu;;
853
+ ]]></artwork>
854
+ </figure>
855
+ <figure>
856
+ <artwork><![CDATA[
857
+ FN:Oscar del Pozo
858
+ N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;
859
+ ]]></artwork>
860
+ </figure>
861
+ <figure>
862
+ <artwork><![CDATA[
863
+ FN:Chistine d'Aboville
864
+ N;SORT-AS="Aboville,Christine":d'Aboville;Christine;;
865
+ ]]></artwork>
866
+ </figure>
867
+ <figure>
868
+ <artwork><![CDATA[
869
+ FN:H. James de Mann
870
+ N;SORT-AS="Mann,James":de Mann;Henry,James;;
871
+ ]]></artwork>
872
+ </figure>
873
+ <t>If sorted by surname, the results would be:</t>
874
+ <figure>
875
+ <artwork><![CDATA[
876
+ Christine d'Aboville
877
+ Rene van der Harten
878
+ Osamu Koura
879
+ H. James de Mann
880
+ Robert Pau Shou Chang
881
+ Oscar del Pozo
882
+ ]]></artwork>
883
+ </figure>
884
+ <t>If sorted by given name, the results would be:</t>
885
+ <figure>
886
+ <artwork><![CDATA[
887
+ Christine d'Aboville
888
+ H. James de Mann
889
+ Osamu Koura
890
+ Oscar del Pozo
891
+ Rene van der Harten
892
+ Robert Pau Shou Chang
893
+ ]]></artwork>
894
+ </figure></section>
895
+ <section anchor="section5_10" title="GEO"><t>The GEO parameter can be used to indicate global positioning
896
+ information that is specific to an address. Its value is the same as
897
+ that of the GEO property (see <xref target="section6_5_2"/>).</t>
898
+ <t>
899
+ <list style="hanging">
900
+ <t hangText="ABNF: "/>
901
+ </list>
902
+ </t>
903
+ <figure>
904
+ <artwork type="abnf"><![CDATA[
905
+ geo-parameter = "GEO=" DQUOTE URI DQUOTE
906
+ ]]></artwork>
907
+ </figure></section>
908
+ <section anchor="section5_11" title="TZ"><t>The TZ parameter can be used to indicate time zone information that
909
+ is specific to an address. Its value is the same as that of the TZ
910
+ property.</t>
911
+ <t>
912
+ <list style="hanging">
913
+ <t hangText="ABNF: "/>
914
+ </list>
915
+ </t>
916
+ <figure>
917
+ <artwork type="abnf"><![CDATA[
918
+ tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE)
919
+
920
+
921
+
922
+
923
+
924
+
925
+ ]]></artwork>
926
+ </figure></section></section>
927
+ <section anchor="section6" title="vCard Properties"><t>What follows is an enumeration of the standard vCard properties.</t>
928
+ <section anchor="section6_1" title="General Properties"><section anchor="section6_1_1" title="BEGIN">
929
+ <t>
930
+ <list style="hanging">
931
+ <t hangText="Purpose: ">To denote the beginning of a syntactic entity within a
932
+ text/vcard content-type.</t>
933
+ <t hangText="Value type: ">text</t>
934
+ <t hangText="Cardinality: ">1</t>
935
+ <t hangText="Special notes: ">The content entity <spanx style="strong">MUST</spanx> begin with the BEGIN property
936
+ with a value of "VCARD". The value is case-insensitive.<vspace blankLines="0"/>The BEGIN property is used in conjunction with the END property to
937
+ delimit an entity containing a related set of properties within a
938
+ text/vcard content-type. This construct can be used instead of
939
+ including multiple vCards as body parts inside of a multipart/
940
+ alternative MIME message. It is provided for applications that
941
+ wish to define content that can contain multiple entities within
942
+ the same text/vcard content-type or to define content that can be
943
+ identifiable outside of a MIME environment.</t>
944
+ <t hangText="ABNF: ">
945
+ <figure>
946
+ <artwork type="abnf"><![CDATA[
947
+ BEGIN-param = 0" " ; no parameter allowed
948
+ BEGIN-value = "VCARD"
949
+ ]]></artwork>
950
+ </figure>
951
+ </t>
952
+ <t hangText="Example: ">
953
+ <figure>
954
+ <artwork><![CDATA[
955
+ BEGIN:VCARD
956
+ ]]></artwork>
957
+ </figure>
958
+ </t>
959
+ </list>
960
+ </t>
961
+ </section>
962
+ <section anchor="section6_1_2" title="END"><t>
963
+ <list style="hanging">
964
+ <t hangText="Purpose: ">To denote the end of a syntactic entity within a text/vcard
965
+ content-type.</t>
966
+ <t hangText="Value type: ">text</t>
967
+ <t hangText="Cardinality: ">1</t>
968
+ <t hangText="Special notes: ">The content entity <spanx style="strong">MUST</spanx> end with the END type with a
969
+ value of "VCARD". The value is case-insensitive.<vspace blankLines="0"/>The END property is used in conjunction with the BEGIN property to
970
+ delimit an entity containing a related set of properties within a
971
+ text/vcard content-type. This construct can be used instead of or
972
+ in addition to wrapping separate sets of information inside
973
+ additional MIME headers. It is provided for applications that
974
+ wish to define content that can contain multiple entities within
975
+ the same text/vcard content-type or to define content that can be
976
+ identifiable outside of a MIME environment.</t>
977
+ <t hangText="ABNF: ">
978
+ <figure>
979
+ <artwork type="abnf"><![CDATA[
980
+ END-param = 0" " ; no parameter allowed
981
+ END-value = "VCARD"
982
+ ]]></artwork>
983
+ </figure>
984
+ </t>
985
+ <t hangText="Example: "/>
986
+ </list>
987
+ </t>
988
+ <figure>
989
+ <artwork><![CDATA[
990
+ END:VCARD
991
+ ]]></artwork>
992
+ </figure></section>
993
+ <section anchor="section6_1_3" title="SOURCE">
994
+ <t>
995
+ <list style="hanging">
996
+ <t hangText="Purpose: ">To identify the source of directory information contained
997
+ in the content type.</t>
998
+ <t hangText="Value type: ">uri</t>
999
+ <t hangText="Cardinality: ">*</t>
1000
+ <t hangText="Special notes: ">The SOURCE property is used to provide the means by
1001
+ which applications knowledgable in the given directory service
1002
+ protocol can obtain additional or more up-to-date information from
1003
+ the directory service. It contains a URI as defined in cite:norm[RFC3986]
1004
+ and/or other information referencing the vCard to which the
1005
+ information pertains. When directory information is available
1006
+ from more than one source, the sending entity can pick what it
1007
+ considers to be the best source, or multiple SOURCE properties can
1008
+ be included.</t>
1009
+ <t hangText="ABNF: ">
1010
+ <figure>
1011
+ <artwork type="abnf"><![CDATA[
1012
+ SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param
1013
+ / mediatype-param / any-param
1014
+ SOURCE-value = URI
1015
+ ]]></artwork>
1016
+ </figure>
1017
+ </t>
1018
+ <t hangText="Examples: "><figure>
1019
+ <artwork><![CDATA[
1020
+ SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US
1021
+ ]]></artwork>
1022
+ </figure>
1023
+ <figure>
1024
+ <artwork><![CDATA[
1025
+ SOURCE:http://directory.example.com/addressbooks/jdoe/
1026
+ Jean%20Dupont.vcf
1027
+ ]]></artwork>
1028
+ </figure></t>
1029
+ </list>
1030
+ </t>
1031
+ </section>
1032
+ <section anchor="section6_1_4" title="KIND"><t>
1033
+ <list style="hanging">
1034
+ <t hangText="Purpose: ">To specify the kind of object the vCard represents.</t>
1035
+ <t hangText="Value type: ">A single text value.</t>
1036
+ <t hangText="Cardinality: ">*1</t>
1037
+ <t hangText="Special notes: ">The value may be one of the following:</t>
1038
+ <t hangText="&quot;individual&quot; ">for a vCard representing a single person or entity.
1039
+ This is the default kind of vCard.</t>
1040
+ <t hangText="&quot;group&quot; ">for a vCard representing a group of persons or entities.
1041
+ The group&#8217;s member entities can be other vCards or other types
1042
+ of entities, such as email addresses or web sites. A group
1043
+ vCard will usually contain MEMBER properties to specify the
1044
+ members of the group, but it is not required to. A group vCard
1045
+ without MEMBER properties can be considered an abstract
1046
+ grouping, or one whose members are known empirically (perhaps
1047
+ "IETF Participants" or "Republican U.S. Senators").<vspace blankLines="0"/>All properties in a group vCard apply to the group as a whole,
1048
+ and not to any particular MEMBER. For example, an EMAIL
1049
+ property might specify the address of a mailing list associated
1050
+ with the group, and an IMPP property might refer to a group
1051
+ chat room.</t>
1052
+ <t hangText="&quot;org&quot; ">for a vCard representing an organization. An organization
1053
+ vCard will not (in fact, <spanx style="strong">MUST NOT</spanx>) contain MEMBER properties,
1054
+ and so these are something of a cross between "individual" and
1055
+ "group". An organization is a single entity, but not a person.
1056
+ It might represent a business or government, a department or
1057
+ division within a business or government, a club, an
1058
+ association, or the like.<vspace blankLines="0"/>All properties in an organization vCard apply to the
1059
+ organization as a whole, as is the case with a group vCard.
1060
+ For example, an EMAIL property might specify the address of a
1061
+ contact point for the organization.</t>
1062
+ <t hangText="&quot;location&quot; ">for a named geographical place. A location vCard will
1063
+ usually contain a GEO property, but it is not required to. A
1064
+ location vCard without a GEO property can be considered an
1065
+ abstract location, or one whose definition is known empirically
1066
+ (perhaps "New England" or "The Seashore").<vspace blankLines="0"/>All properties in a location vCard apply to the location
1067
+ itself, and not with any entity that might exist at that
1068
+ location. For example, in a vCard for an office building, an
1069
+ ADR property might give the mailing address for the building,
1070
+ and a TEL property might specify the telephone number of the
1071
+ receptionist.</t>
1072
+ <t hangText="An x-name. ">vCards <spanx style="strong">MAY</spanx> include private or experimental values for
1073
+ KIND. Remember that x-name values are not intended for general
1074
+ use and are unlikely to interoperate.</t>
1075
+ <t hangText="An iana-token. ">Additional values may be registered with IANA (see
1076
+ <xref target="section10_3_4"/>). A new value&#8217;s specification document <spanx style="strong">MUST</spanx>
1077
+ specify which properties make sense for that new kind of vCard
1078
+ and which do not.</t>
1079
+ </list>
1080
+ </t>
1081
+ <t>Implementations <spanx style="strong">MUST</spanx> support the specific string values defined
1082
+ above. If this property is absent, "individual" <spanx style="strong">MUST</spanx> be assumed
1083
+ as the default. If this property is present but the
1084
+ implementation does not understand its value (the value is an
1085
+ x-name or iana-token that the implementation does not support),
1086
+ the implementation <spanx style="strong">SHOULD</spanx> act in a neutral way, which usually
1087
+ means treating the vCard as though its kind were "individual".
1088
+ The presence of MEMBER properties <spanx style="strong">MAY</spanx>, however, be taken as an
1089
+ indication that the unknown kind is an extension of "group".</t>
1090
+ <t>Clients often need to visually distinguish contacts based on what
1091
+ they represent, and the KIND property provides a direct way for
1092
+ them to do so. For example, when displaying contacts in a list,
1093
+ an icon could be displayed next to each one, using distinctive
1094
+ icons for the different kinds; a client might use an outline of a
1095
+ single person to represent an "individual", an outline of multiple
1096
+ people to represent a "group", and so on. Alternatively, or in
1097
+ addition, a client might choose to segregate different kinds of
1098
+ vCards to different panes, tabs, or selections in the user
1099
+ interface.</t>
1100
+ <t>Some clients might also make functional distinctions among the
1101
+ kinds, ignoring "location" vCards for some purposes and
1102
+ considering only "location" vCards for others.</t>
1103
+ <t>When designing those sorts of visual and functional distinctions,
1104
+ client implementations have to decide how to fit unsupported kinds
1105
+ into the scheme. What icon is used for them? The one for
1106
+ "individual"? A unique one, such as an icon of a question mark?
1107
+ Which tab do they go into? It is beyond the scope of this
1108
+ specification to answer these questions, but these are things
1109
+ implementers need to consider.</t>
1110
+ <t>
1111
+ <list style="hanging">
1112
+ <t hangText="ABNF: ">
1113
+ <figure>
1114
+ <artwork type="abnf"><![CDATA[
1115
+ KIND-param = "VALUE=text" / any-param
1116
+ KIND-value = "individual" / "group" / "org" / "location"
1117
+ / iana-token / x-name
1118
+ ]]></artwork>
1119
+ </figure>
1120
+ </t>
1121
+ <t hangText="Example: "><vspace blankLines="0"/>This represents someone named Jane Doe working in the marketing
1122
+ department of the North American division of ABC Inc.
1123
+ <figure>
1124
+ <artwork><![CDATA[
1125
+ BEGIN:VCARD
1126
+ VERSION:4.0
1127
+ KIND:individual
1128
+ FN:Jane Doe
1129
+ ORG:ABC\, Inc.;North American Division;Marketing
1130
+ END:VCARD
1131
+ ]]></artwork>
1132
+ </figure>
1133
+ <vspace blankLines="0"/>This represents the department itself, commonly known as ABC
1134
+ Marketing.
1135
+ <figure>
1136
+ <artwork><![CDATA[
1137
+ BEGIN:VCARD
1138
+ VERSION:4.0
1139
+ KIND:org
1140
+ FN:ABC Marketing
1141
+ ORG:ABC\, Inc.;North American Division;Marketing
1142
+ END:VCARD
1143
+ ]]></artwork>
1144
+ </figure></t>
1145
+ </list>
1146
+ </t></section>
1147
+ <section anchor="section6_1_5" title="XML">
1148
+ <t>
1149
+ <list style="hanging">
1150
+ <t hangText="Purpose: ">To include extended XML-encoded vCard data in a plain
1151
+ vCard.</t>
1152
+ <t hangText="Value type: ">A single text value.</t>
1153
+ <t hangText="Cardinality: ">*</t>
1154
+ <t hangText="Special notes: ">The content of this property is a single XML 1.0
1155
+ cite:norm[W3C.REC-xml-20081126] element whose namespace <spanx style="strong">MUST</spanx> be explicitly
1156
+ specified using the xmlns attribute and <spanx style="strong">MUST NOT</spanx> be the vCard 4
1157
+ namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies
1158
+ that it cannot duplicate a standard vCard property.) The element
1159
+ is to be interpreted as if it was contained in a &lt;vcard&gt; element,
1160
+ as defined in cite:norm[RFC6351].<vspace blankLines="0"/>The fragment is subject to normal line folding and escaping, i.e.,
1161
+ replace all backslashes with "\\", then replace all newlines with
1162
+ "\n", then fold long lines.
1163
+ <vspace blankLines="0"/>Support for this property is <spanx style="strong">OPTIONAL</spanx>, but implementations of this
1164
+ specification <spanx style="strong">MUST</spanx> preserve instances of this property when
1165
+ propagating vCards.
1166
+ <vspace blankLines="0"/>See cite:norm[RFC6351] for more information on the intended use of this
1167
+ property.</t>
1168
+ <t hangText="ABNF: ">
1169
+ <figure>
1170
+ <artwork type="abnf"><![CDATA[
1171
+ XML-param = "VALUE=text" / altid-param
1172
+ XML-value = text
1173
+ ]]></artwork>
1174
+ </figure>
1175
+ </t>
1176
+ </list>
1177
+ </t>
1178
+ </section></section>
1179
+ <section anchor="section6_2" title="Identification Properties"><t>These types are used to capture information associated with the
1180
+ identification and naming of the entity associated with the vCard.</t>
1181
+ <section anchor="section6_2_1" title="FN">
1182
+ <t>
1183
+ <list style="hanging">
1184
+ <t hangText="Purpose: ">To specify the formatted text corresponding to the name of
1185
+ the object the vCard represents.</t>
1186
+ <t hangText="Value type: ">A single text value.</t>
1187
+ <t hangText="Cardinality: ">1*</t>
1188
+ <t hangText="Special notes: ">This property is based on the semantics of the X.520
1189
+ Common Name attribute cite:norm[CCITT.X520.1988]. The property <spanx style="strong">MUST</spanx> be
1190
+ present in the vCard object.</t>
1191
+ <t hangText="ABNF: ">
1192
+ <figure>
1193
+ <artwork type="abnf"><![CDATA[
1194
+ FN-param = "VALUE=text" / type-param / language-param / altid-param
1195
+ / pid-param / pref-param / any-param
1196
+ FN-value = text
1197
+ ]]></artwork>
1198
+ </figure>
1199
+ </t>
1200
+ <t hangText="Example: ">
1201
+ <figure>
1202
+ <artwork><![CDATA[
1203
+ FN:Mr. John Q. Public\, Esq.
1204
+ ]]></artwork>
1205
+ </figure>
1206
+ </t>
1207
+ </list>
1208
+ </t>
1209
+ </section>
1210
+ <section anchor="section6_2_2" title="N">
1211
+ <t>
1212
+ <list style="hanging">
1213
+ <t hangText="Purpose: ">To specify the components of the name of the object the
1214
+ vCard represents.</t>
1215
+ <t hangText="Value type: ">A single structured text value. Each component can have
1216
+ multiple values.</t>
1217
+ <t hangText="Cardinality: ">*1</t>
1218
+ <t hangText="Special note: ">The structured property value corresponds, in
1219
+ sequence, to the Family Names (also known as surnames), Given
1220
+ Names, Additional Names, Honorific Prefixes, and Honorific
1221
+ Suffixes. The text components are separated by the SEMICOLON
1222
+ character (U+003B). Individual text components can include
1223
+ multiple text values separated by the COMMA character (U+002C).
1224
+ This property is based on the semantics of the X.520 individual
1225
+ name attributes cite:norm[CCITT.X520.1988]. The property <spanx style="strong">SHOULD</spanx> be present
1226
+ in the vCard object when the name of the object the vCard
1227
+ represents follows the X.520 model.<vspace blankLines="0"/>The SORT-AS parameter <spanx style="strong">MAY</spanx> be applied to this property.</t>
1228
+ <t hangText="ABNF: ">
1229
+ <figure>
1230
+ <artwork type="abnf"><![CDATA[
1231
+ N-param = "VALUE=text" / sort-as-param / language-param
1232
+ / altid-param / any-param
1233
+ N-value = list-component 4(";" list-component)
1234
+ ]]></artwork>
1235
+ </figure>
1236
+ </t>
1237
+ <t hangText="Examples: ">
1238
+ <figure>
1239
+ <artwork><![CDATA[
1240
+ N:Public;John;Quinlan;Mr.;Esq.
1241
+
1242
+ N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
1243
+ ]]></artwork>
1244
+ </figure>
1245
+ </t>
1246
+ </list>
1247
+ </t>
1248
+ </section>
1249
+ <section anchor="section6_2_3" title="NICKNAME">
1250
+ <t>
1251
+ <list style="hanging">
1252
+ <t hangText="Purpose: ">To specify the text corresponding to the nickname of the
1253
+ object the vCard represents.</t>
1254
+ <t hangText="Value type: ">One or more text values separated by a COMMA character
1255
+ (U+002C).</t>
1256
+ <t hangText="Cardinality: ">*</t>
1257
+ <t hangText="Special note: ">The nickname is the descriptive name given instead of
1258
+ or in addition to the one belonging to the object the vCard
1259
+ represents. It can also be used to specify a familiar form of a
1260
+ proper name specified by the FN or N properties.</t>
1261
+ <t hangText="ABNF: ">
1262
+ <figure>
1263
+ <artwork type="abnf"><![CDATA[
1264
+ NICKNAME-param = "VALUE=text" / type-param / language-param
1265
+ / altid-param / pid-param / pref-param / any-param
1266
+ NICKNAME-value = text-list
1267
+ ]]></artwork>
1268
+ </figure>
1269
+ </t>
1270
+ <t hangText="Examples: ">
1271
+ <figure>
1272
+ <artwork><![CDATA[
1273
+ NICKNAME:Robbie
1274
+
1275
+ NICKNAME:Jim,Jimmie
1276
+
1277
+ NICKNAME;TYPE=work:Boss
1278
+ ]]></artwork>
1279
+ </figure>
1280
+ </t>
1281
+ </list>
1282
+ </t>
1283
+ </section>
1284
+ <section anchor="section6_2_4" title="PHOTO">
1285
+ <t>
1286
+ <list style="hanging">
1287
+ <t hangText="Purpose: ">To specify an image or photograph information that
1288
+ annotates some aspect of the object the vCard represents.</t>
1289
+ <t hangText="Value type: ">A single URI.</t>
1290
+ <t hangText="Cardinality: ">*</t>
1291
+ <t hangText="ABNF: ">
1292
+ <figure>
1293
+ <artwork type="abnf"><![CDATA[
1294
+ PHOTO-param = "VALUE=uri" / altid-param / type-param
1295
+ / mediatype-param / pref-param / pid-param / any-param
1296
+ PHOTO-value = URI
1297
+ ]]></artwork>
1298
+ </figure>
1299
+ </t>
1300
+ <t hangText="Examples: ">
1301
+ <figure>
1302
+ <artwork><![CDATA[
1303
+ PHOTO:http://www.example.com/pub/photos/jqpublic.gif
1304
+
1305
+ PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv
1306
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
1307
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
1308
+ <...remainder of base64-encoded data...>
1309
+ ]]></artwork>
1310
+ </figure>
1311
+ </t>
1312
+ </list>
1313
+ </t>
1314
+ </section>
1315
+ <section anchor="section6_2_5" title="BDAY">
1316
+ <t>
1317
+ <list style="hanging">
1318
+ <t hangText="Purpose: ">To specify the birth date of the object the vCard
1319
+ represents.</t>
1320
+ <t hangText="Value type: ">The default is a single date-and-or-time value. It can
1321
+ also be reset to a single text value.</t>
1322
+ <t hangText="Cardinality: ">*1</t>
1323
+ <t hangText="ABNF: ">
1324
+ <figure>
1325
+ <artwork type="abnf"><![CDATA[
1326
+ BDAY-param = BDAY-param-date / BDAY-param-text
1327
+ BDAY-value = date-and-or-time / text
1328
+ ; Value and parameter MUST match.
1329
+
1330
+ BDAY-param-date = "VALUE=date-and-or-time"
1331
+ BDAY-param-text = "VALUE=text" / language-param
1332
+
1333
+ BDAY-param =/ altid-param / calscale-param / any-param
1334
+ ; calscale-param can only be present when BDAY-value is
1335
+ ; date-and-or-time and actually contains a date or date-time.
1336
+ ]]></artwork>
1337
+ </figure>
1338
+ </t>
1339
+ <t hangText="Examples: ">
1340
+ <figure>
1341
+ <artwork><![CDATA[
1342
+ BDAY:19960415
1343
+ BDAY:--0415
1344
+ BDAY;19531015T231000Z
1345
+ BDAY;VALUE=text:circa 1800
1346
+ ]]></artwork>
1347
+ </figure>
1348
+ </t>
1349
+ </list>
1350
+ </t>
1351
+ </section>
1352
+ <section anchor="section6_2_6" title="ANNIVERSARY">
1353
+ <t>
1354
+ <list style="hanging">
1355
+ <t hangText="Purpose: ">The date of marriage, or equivalent, of the object the
1356
+ vCard represents.</t>
1357
+ <t hangText="Value type: ">The default is a single date-and-or-time value. It can
1358
+ also be reset to a single text value.</t>
1359
+ <t hangText="Cardinality: ">*1</t>
1360
+ <t hangText="ABNF: ">
1361
+ <figure>
1362
+ <artwork type="abnf"><![CDATA[
1363
+ ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text")
1364
+ ANNIVERSARY-value = date-and-or-time / text
1365
+ ; Value and parameter MUST match.
1366
+
1367
+ ANNIVERSARY-param =/ altid-param / calscale-param / any-param
1368
+ ; calscale-param can only be present when ANNIVERSARY-value is
1369
+ ; date-and-or-time and actually contains a date or date-time.
1370
+ ]]></artwork>
1371
+ </figure>
1372
+ </t>
1373
+ <t hangText="Examples: ">
1374
+ <figure>
1375
+ <artwork><![CDATA[
1376
+ ANNIVERSARY:19960415
1377
+ ]]></artwork>
1378
+ </figure>
1379
+ </t>
1380
+ </list>
1381
+ </t>
1382
+ </section>
1383
+ <section anchor="section6_2_7" title="GENDER">
1384
+ <t>
1385
+ <list style="hanging">
1386
+ <t hangText="Purpose: ">To specify the components of the sex and gender identity of
1387
+ the object the vCard represents.</t>
1388
+ <t hangText="Value type: ">A single structured value with two components. Each
1389
+ component has a single text value.</t>
1390
+ <t hangText="Cardinality: ">*1</t>
1391
+ <t hangText="Special notes: ">The components correspond, in sequence, to the sex
1392
+ (biological), and gender identity. Each component is optional.<list style="hanging">
1393
+ <t hangText="Sex component: ">A single letter. M stands for "male", F stands
1394
+ for "female", O stands for "other", N stands for "none or not
1395
+ applicable", U stands for "unknown".</t>
1396
+ <t hangText="Gender identity component: ">Free-form text.</t>
1397
+ </list></t>
1398
+ <t hangText="ABNF: ">
1399
+ <figure>
1400
+ <artwork type="abnf"><![CDATA[
1401
+ GENDER-param = "VALUE=text" / any-param
1402
+ GENDER-value = sex [";" text]
1403
+
1404
+ sex = "" / "M" / "F" / "O" / "N" / "U"
1405
+ ]]></artwork>
1406
+ </figure>
1407
+ </t>
1408
+ <t hangText="Examples: ">
1409
+ <figure>
1410
+ <artwork><![CDATA[
1411
+ GENDER:M
1412
+ GENDER:F
1413
+ GENDER:M;Fellow
1414
+ GENDER:F;grrrl
1415
+ GENDER:O;intersex
1416
+ GENDER:;it's complicated
1417
+ ]]></artwork>
1418
+ </figure>
1419
+ </t>
1420
+ </list>
1421
+ </t>
1422
+ </section></section>
1423
+ <section anchor="section6_3" title="Delivery Addressing Properties"><t>These types are concerned with information related to the delivery
1424
+ addressing or label for the vCard object.</t>
1425
+ <section anchor="section6_3_1" title="ADR"><t>
1426
+ <list style="hanging">
1427
+ <t hangText="Purpose: ">To specify the components of the delivery address for the
1428
+ vCard object.</t>
1429
+ <t hangText="Value type: ">A single structured text value, separated by the
1430
+ SEMICOLON character (U+003B).</t>
1431
+ <t hangText="Cardinality: ">*</t>
1432
+ <t hangText="Special notes: ">The structured type value consists of a sequence of
1433
+ address components. The component values <spanx style="strong">MUST</spanx> be specified in
1434
+ their corresponding position. The structured type value
1435
+ corresponds, in sequence, to<list style="empty">
1436
+ <t>the post office box;</t>
1437
+ <t>the extended address (e.g., apartment or suite number);</t>
1438
+ <t>the street address;</t>
1439
+ <t>the locality (e.g., city);</t>
1440
+ <t>the region (e.g., state or province);</t>
1441
+ <t>the postal code;</t>
1442
+ <t>the country name (full name in the language specified in
1443
+ <xref target="section5_1"/>).</t>
1444
+ </list></t>
1445
+ </list>
1446
+ </t>
1447
+ <t>When a component value is missing, the associated component
1448
+ separator <spanx style="strong">MUST</spanx> still be specified.</t>
1449
+ <t>Experience with vCard 3 has shown that the first two components
1450
+ (post office box and extended address) are plagued with many
1451
+ interoperability issues. To ensure maximal interoperability,
1452
+ their values <spanx style="strong">SHOULD</spanx> be empty.</t>
1453
+ <t>The text components are separated by the SEMICOLON character
1454
+ (U+003B). Where it makes semantic sense, individual text
1455
+ components can include multiple text values (e.g., a "street"
1456
+ component with multiple lines) separated by the COMMA character
1457
+ (U+002C).</t>
1458
+ <t>The property can include the "PREF" parameter to indicate the
1459
+ preferred delivery address when more than one address is
1460
+ specified.</t>
1461
+ <t>The GEO and TZ parameters <spanx style="strong">MAY</spanx> be used with this property.</t>
1462
+ <t>The property can also include a "LABEL" parameter to present a
1463
+ delivery address label for the address. Its value is a plain-text
1464
+ string representing the formatted address. Newlines are encoded
1465
+ as \n, as they are for property values.</t>
1466
+ <t>
1467
+ <list style="hanging">
1468
+ <t hangText="ABNF: ">
1469
+ <figure>
1470
+ <artwork type="abnf"><![CDATA[
1471
+ label-param = "LABEL=" param-value
1472
+
1473
+ ADR-param = "VALUE=text" / label-param / language-param
1474
+ / geo-parameter / tz-parameter / altid-param / pid-param
1475
+ / pref-param / type-param / any-param
1476
+
1477
+ ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
1478
+ ADR-component-street ";" ADR-component-locality ";"
1479
+ ADR-component-region ";" ADR-component-code ";"
1480
+ ADR-component-country
1481
+ ADR-component-pobox = list-component
1482
+ ADR-component-ext = list-component
1483
+ ADR-component-street = list-component
1484
+ ADR-component-locality = list-component
1485
+ ADR-component-region = list-component
1486
+ ADR-component-code = list-component
1487
+ ADR-component-country = list-component
1488
+ ]]></artwork>
1489
+ </figure>
1490
+ </t>
1491
+ <t hangText="Example: ">In this example, the post office box and the extended
1492
+ address are absent.<figure>
1493
+ <artwork><![CDATA[
1494
+ ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
1495
+ Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
1496
+ U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
1497
+ ]]></artwork>
1498
+ </figure></t>
1499
+ </list>
1500
+ </t></section></section>
1501
+ <section anchor="section6_4" title="Communications Properties"><t>These properties describe information about how to communicate with
1502
+ the object the vCard represents.</t>
1503
+ <section anchor="section6_4_1" title="TEL"><t>
1504
+ <list style="hanging">
1505
+ <t hangText="Purpose: ">To specify the telephone number for telephony communication
1506
+ with the object the vCard represents.</t>
1507
+ <t hangText="Value type: ">By default, it is a single free-form text value (for
1508
+ backward compatibility with vCard 3), but it <spanx style="strong">SHOULD</spanx> be reset to a
1509
+ URI value. It is expected that the URI scheme will be "tel", as
1510
+ specified in cite:norm[RFC3966], but other schemes <spanx style="strong">MAY</spanx> be used.</t>
1511
+ <t hangText="Cardinality: ">*</t>
1512
+ <t hangText="Special notes: ">This property is based on the X.520 Telephone Number
1513
+ attribute cite:norm[CCITT.X520.1988].<vspace blankLines="0"/>The property can include the "PREF" parameter to indicate a
1514
+ preferred-use telephone number.
1515
+ <vspace blankLines="0"/>The property can include the parameter "TYPE" to specify intended
1516
+ use for the telephone number. The predefined values for the TYPE
1517
+ parameter are:</t>
1518
+ </list>
1519
+ </t>
1520
+ <texttable suppress-title="false" style="full">
1521
+ <ttcol align="left">Value</ttcol>
1522
+ <ttcol align="left">Description</ttcol>
1523
+ <c>text</c>
1524
+ <c>Indicates that the telephone number supports text messages (SMS).</c>
1525
+ <c>voice</c>
1526
+ <c>Indicates a voice telephone number.</c>
1527
+ <c>fax</c>
1528
+ <c>Indicates a facsimile telephone number.</c>
1529
+ <c>cell</c>
1530
+ <c>Indicates a cellular or mobile telephone number.</c>
1531
+ <c>video</c>
1532
+ <c>Indicates a video conferencing telephone number.</c>
1533
+ <c>pager</c>
1534
+ <c>Indicates a paging device telephone number.</c>
1535
+ <c>textphone</c>
1536
+ <c>Indicates a telecommunication device for people with hearing or speech difficulties.</c>
1537
+ </texttable>
1538
+ <t>The default type is "voice". These type parameter values can be
1539
+ specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
1540
+ value list (e.g., TYPE="text,voice"). The default can be
1541
+ overridden to another set of values by specifying one or more
1542
+ alternate values. For example, the default TYPE of "voice" can be
1543
+ reset to a VOICE and FAX telephone number by the value list
1544
+ TYPE="voice,fax".</t>
1545
+ <t>If this property&#8217;s value is a URI that can also be used for
1546
+ instant messaging, the IMPP (<xref target="section6_4_3"/>) property <spanx style="strong">SHOULD</spanx> be
1547
+ used in addition to this property.</t>
1548
+ <t>
1549
+ <list style="hanging">
1550
+ <t hangText="ABNF: ">
1551
+ <figure>
1552
+ <artwork type="abnf"><![CDATA[
1553
+ TEL-param = TEL-text-param / TEL-uri-param
1554
+ TEL-value = TEL-text-value / TEL-uri-value
1555
+ ; Value and parameter MUST match.
1556
+
1557
+ TEL-text-param = "VALUE=text"
1558
+ TEL-text-value = text
1559
+
1560
+ TEL-uri-param = "VALUE=uri" / mediatype-param
1561
+ TEL-uri-value = URI
1562
+
1563
+ TEL-param =/ type-param / pid-param / pref-param / altid-param
1564
+ / any-param
1565
+
1566
+ type-param-tel = "text" / "voice" / "fax" / "cell" / "video"
1567
+ / "pager" / "textphone" / iana-token / x-name
1568
+ ; type-param-tel MUST NOT be used with a property other than TEL.
1569
+
1570
+ ]]></artwork>
1571
+ </figure>
1572
+ </t>
1573
+ <t hangText="Example: ">
1574
+ <figure>
1575
+ <artwork><![CDATA[
1576
+ TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
1577
+ TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67
1578
+ ]]></artwork>
1579
+ </figure>
1580
+ </t>
1581
+ </list>
1582
+ </t></section>
1583
+ <section anchor="section6_4_2" title="EMAIL">
1584
+ <t>
1585
+ <list style="hanging">
1586
+ <t hangText="Purpose: ">To specify the electronic mail address for communication
1587
+ with the object the vCard represents.</t>
1588
+ <t hangText="Value type: ">A single text value.</t>
1589
+ <t hangText="Cardinality: ">*</t>
1590
+ <t hangText="Special notes: ">The property can include tye "PREF" parameter to
1591
+ indicate a preferred-use email address when more than one is
1592
+ specified.<vspace blankLines="0"/>Even though the value is free-form UTF-8 text, it is likely to be
1593
+ interpreted by a Mail User Agent (MUA) as an "addr-spec", as
1594
+ defined in cite:norm[RFC5322, suffix=", Section 3.4.1"]. Readers should also be aware
1595
+ of the current work toward internationalized email addresses
1596
+ cite:info[RFC5335bis].</t>
1597
+ <t hangText="ABNF: ">
1598
+ <figure>
1599
+ <artwork type="abnf"><![CDATA[
1600
+ EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param
1601
+ / altid-param / any-param
1602
+ EMAIL-value = text
1603
+ ]]></artwork>
1604
+ </figure>
1605
+ </t>
1606
+ <t hangText="Example: ">
1607
+ <figure>
1608
+ <artwork><![CDATA[
1609
+ EMAIL;TYPE=work:jqpublic@xyz.example.com
1610
+
1611
+ EMAIL;PREF=1:jane_doe@example.com
1612
+ ]]></artwork>
1613
+ </figure>
1614
+ </t>
1615
+ </list>
1616
+ </t>
1617
+ </section>
1618
+ <section anchor="section6_4_3" title="IMPP">
1619
+ <t>
1620
+ <list style="hanging">
1621
+ <t hangText="Purpose: ">To specify the URI for instant messaging and presence
1622
+ protocol communications with the object the vCard represents.</t>
1623
+ <t hangText="Value type: ">A single URI.</t>
1624
+ <t hangText="Cardinality: ">*</t>
1625
+ <t hangText="Special notes: ">The property may include the "PREF" parameter to
1626
+ indicate that this is a preferred address and has the same
1627
+ semantics as the "PREF" parameter in a TEL property.<vspace blankLines="0"/>If this property&#8217;s value is a URI that can be used for voice
1628
+ and/or video, the TEL property (<xref target="section6_4_1"/>) <spanx style="strong">SHOULD</spanx> be used in
1629
+ addition to this property.
1630
+ <vspace blankLines="0"/>This property is adapted from cite:info[RFC4770], which is made obsolete by
1631
+ this document.</t>
1632
+ <t hangText="ABNF: ">
1633
+ <figure>
1634
+ <artwork type="abnf"><![CDATA[
1635
+ IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param
1636
+ / mediatype-param / altid-param / any-param
1637
+ IMPP-value = URI
1638
+ ]]></artwork>
1639
+ </figure>
1640
+ </t>
1641
+ <t hangText="Example: ">
1642
+ <figure>
1643
+ <artwork><![CDATA[
1644
+ IMPP;PREF=1:xmpp:alice@example.com
1645
+ ]]></artwork>
1646
+ </figure>
1647
+ </t>
1648
+ </list>
1649
+ </t>
1650
+ </section>
1651
+ <section anchor="section6_4_4" title="LANG">
1652
+ <t>
1653
+ <list style="hanging">
1654
+ <t hangText="Purpose: ">To specify the language(s) that may be used for contacting
1655
+ the entity associated with the vCard.</t>
1656
+ <t hangText="Value type: ">A single language-tag value.</t>
1657
+ <t hangText="Cardinality: ">*</t>
1658
+ <t hangText="ABNF: ">
1659
+ <figure>
1660
+ <artwork type="abnf"><![CDATA[
1661
+ LANG-param = "VALUE=language-tag" / pid-param / pref-param
1662
+ / altid-param / type-param / any-param
1663
+ LANG-value = Language-Tag
1664
+ ]]></artwork>
1665
+ </figure>
1666
+ </t>
1667
+ <t hangText="Example: ">
1668
+ <figure>
1669
+ <artwork><![CDATA[
1670
+ LANG;TYPE=work;PREF=1:en
1671
+ LANG;TYPE=work;PREF=2:fr
1672
+ LANG;TYPE=home:fr
1673
+ ]]></artwork>
1674
+ </figure>
1675
+ </t>
1676
+ </list>
1677
+ </t>
1678
+ </section></section>
1679
+ <section anchor="section6_5" title="Geographical Properties"><t>These properties are concerned with information associated with
1680
+ geographical positions or regions associated with the object the
1681
+ vCard represents.</t>
1682
+ <section anchor="section6_5_1" title="TZ">
1683
+ <t>
1684
+ <list style="hanging">
1685
+ <t hangText="Purpose: ">To specify information related to the time zone of the
1686
+ object the vCard represents.</t>
1687
+ <t hangText="Value type: ">The default is a single text value. It can also be
1688
+ reset to a single URI or utc-offset value.</t>
1689
+ <t hangText="Cardinality: ">*</t>
1690
+ <t hangText="Special notes: ">It is expected that names from the public-domain
1691
+ Olson database cite:info[TZ-DB] will be used, but this is not a
1692
+ restriction. See also cite:info[IANA-TZ].<vspace blankLines="0"/>Efforts are currently being directed at creating a standard URI
1693
+ scheme for expressing time zone information. Usage of such a
1694
+ scheme would ensure a high level of interoperability between
1695
+ implementations that support it.
1696
+ <vspace blankLines="0"/>Note that utc-offset values <spanx style="strong">SHOULD NOT</spanx> be used because the UTC
1697
+ offset varies with time&#8201;&#8212;&#8201;not just because of the usual daylight
1698
+ saving time shifts that occur in may regions, but often entire
1699
+ regions will "re-base" their overall offset. The actual offset
1700
+ may be +/- 1 hour (or perhaps a little more) than the one given.</t>
1701
+ <t hangText="ABNF: ">
1702
+ <figure>
1703
+ <artwork type="abnf"><![CDATA[
1704
+ TZ-param = "VALUE=" ("text" / "uri" / "utc-offset")
1705
+ TZ-value = text / URI / utc-offset
1706
+ ; Value and parameter MUST match.
1707
+
1708
+ TZ-param =/ altid-param / pid-param / pref-param / type-param
1709
+ / mediatype-param / any-param
1710
+ ]]></artwork>
1711
+ </figure>
1712
+ </t>
1713
+ <t hangText="Examples: ">
1714
+ <figure>
1715
+ <artwork><![CDATA[
1716
+ TZ:Raleigh/North America
1717
+
1718
+ TZ;VALUE=utc-offset:-0500
1719
+ ; Note: utc-offset format is NOT RECOMMENDED.
1720
+ ]]></artwork>
1721
+ </figure>
1722
+ </t>
1723
+ </list>
1724
+ </t>
1725
+ </section>
1726
+ <section anchor="section6_5_2" title="GEO">
1727
+ <t>
1728
+ <list style="hanging">
1729
+ <t hangText="Purpose: ">To specify information related to the global positioning of
1730
+ the object the vCard represents.</t>
1731
+ <t hangText="Value type: ">A single URI.</t>
1732
+ <t hangText="Cardinality: ">*</t>
1733
+ <t hangText="Special notes: ">The "geo" URI scheme cite:norm[RFC5870] is particularly well
1734
+ suited for this property, but other schemes <spanx style="strong">MAY</spanx> be used.</t>
1735
+ <t hangText="ABNF: ">
1736
+ <figure>
1737
+ <artwork type="abnf"><![CDATA[
1738
+ GEO-param = "VALUE=uri" / pid-param / pref-param / type-param
1739
+ / mediatype-param / altid-param / any-param
1740
+ GEO-value = URI
1741
+ ]]></artwork>
1742
+ </figure>
1743
+ </t>
1744
+ <t hangText="Example: ">
1745
+ <figure>
1746
+ <artwork><![CDATA[
1747
+ GEO:geo:37.386013,-122.082932
1748
+ ]]></artwork>
1749
+ </figure>
1750
+ </t>
1751
+ </list>
1752
+ </t>
1753
+ </section></section>
1754
+ <section anchor="section6_6" title="Organizational Properties"><t>These properties are concerned with information associated with
1755
+ characteristics of the organization or organizational units of the
1756
+ object that the vCard represents.</t>
1757
+ <section anchor="section6_6_1" title="TITLE"><t>
1758
+ <list style="hanging">
1759
+ <t hangText="Purpose: ">To specify the position or job of the object the vCard
1760
+ represents.</t>
1761
+ <t hangText="Value type: ">A single text value.</t>
1762
+ </list>
1763
+ </t>
1764
+ <t>Cardinality: *</t>
1765
+ <t>
1766
+ <list style="hanging">
1767
+ <t hangText="Special notes: ">This property is based on the X.520 Title attribute
1768
+ cite:norm[CCITT.X520.1988].</t>
1769
+ <t hangText="ABNF: ">
1770
+ <figure>
1771
+ <artwork type="abnf"><![CDATA[
1772
+ TITLE-param = "VALUE=text" / language-param / pid-param
1773
+ / pref-param / altid-param / type-param / any-param
1774
+ TITLE-value = text
1775
+ ]]></artwork>
1776
+ </figure>
1777
+ </t>
1778
+ <t hangText="Example: ">
1779
+ <figure>
1780
+ <artwork><![CDATA[
1781
+ TITLE:Research Scientist
1782
+ ]]></artwork>
1783
+ </figure>
1784
+ </t>
1785
+ </list>
1786
+ </t></section>
1787
+ <section anchor="section6_6_2" title="ROLE"><t>
1788
+ <list style="hanging">
1789
+ <t hangText="Purpose: ">To specify the function or part played in a particular
1790
+ situation by the object the vCard represents.</t>
1791
+ <t hangText="Value type: ">A single text value.</t>
1792
+ <t hangText="Cardinality: ">*</t>
1793
+ </list>
1794
+ </t>
1795
+ <t>Special notes: This property is based on the X.520 Business Category
1796
+ explanatory attribute cite:norm[CCITT.X520.1988]. This property is
1797
+ included as an organizational type to avoid confusion with the
1798
+ semantics of the TITLE property and incorrect usage of that
1799
+ property when the semantics of this property is intended.</t>
1800
+ <t>
1801
+ <list style="hanging">
1802
+ <t hangText="ABNF: ">
1803
+ <figure>
1804
+ <artwork type="abnf"><![CDATA[
1805
+ ROLE-param = "VALUE=text" / language-param / pid-param / pref-param
1806
+ / type-param / altid-param / any-param
1807
+ ROLE-value = text
1808
+ ]]></artwork>
1809
+ </figure>
1810
+ </t>
1811
+ <t hangText="Example: ">
1812
+ <figure>
1813
+ <artwork><![CDATA[
1814
+ ROLE:Project Leader
1815
+ ]]></artwork>
1816
+ </figure>
1817
+ </t>
1818
+ </list>
1819
+ </t></section>
1820
+ <section anchor="section6_6_3" title="LOGO">
1821
+ <t>
1822
+ <list style="hanging">
1823
+ <t hangText="Purpose: ">To specify a graphic image of a logo associated with the
1824
+ object the vCard represents.</t>
1825
+ <t hangText="Value type: ">A single URI.</t>
1826
+ <t hangText="Cardinality: ">*</t>
1827
+ <t hangText="ABNF: ">
1828
+ <figure>
1829
+ <artwork type="abnf"><![CDATA[
1830
+ LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param
1831
+ / type-param / mediatype-param / altid-param / any-param
1832
+ LOGO-value = URI
1833
+ ]]></artwork>
1834
+ </figure>
1835
+ </t>
1836
+ <t hangText="Examples: ">
1837
+ <figure>
1838
+ <artwork><![CDATA[
1839
+ LOGO:http://www.example.com/pub/logos/abccorp.jpg
1840
+
1841
+ LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc
1842
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
1843
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
1844
+ <...the remainder of base64-encoded data...>
1845
+ ]]></artwork>
1846
+ </figure>
1847
+ </t>
1848
+ </list>
1849
+ </t>
1850
+ </section>
1851
+ <section anchor="section6_6_4" title="ORG">
1852
+ <t>
1853
+ <list style="hanging">
1854
+ <t hangText="Purpose: ">To specify the organizational name and units associated
1855
+ with the vCard.</t>
1856
+ <t hangText="Value type: ">A single structured text value consisting of components
1857
+ separated by the SEMICOLON character (U+003B).</t>
1858
+ <t hangText="Cardinality: ">*</t>
1859
+ <t hangText="Special notes: ">The property is based on the X.520 Organization Name
1860
+ and Organization Unit attributes cite:norm[CCITT.X520.1988]. The property
1861
+ value is a structured type consisting of the organization name,
1862
+ followed by zero or more levels of organizational unit names.<vspace blankLines="0"/>The SORT-AS parameter <spanx style="strong">MAY</spanx> be applied to this property.</t>
1863
+ <t hangText="ABNF: ">
1864
+ <figure>
1865
+ <artwork type="abnf"><![CDATA[
1866
+ ORG-param = "VALUE=text" / sort-as-param / language-param
1867
+ / pid-param / pref-param / altid-param / type-param
1868
+ / any-param
1869
+ ORG-value = component *(";" component)
1870
+ ]]></artwork>
1871
+ </figure>
1872
+ </t>
1873
+ <t hangText="Example: ">A property value consisting of an organizational name,
1874
+ organizational unit #1 name, and organizational unit #2 name.<figure>
1875
+ <artwork><![CDATA[
1876
+ ORG:ABC\, Inc.;North American Division;Marketing
1877
+ ]]></artwork>
1878
+ </figure></t>
1879
+ </list>
1880
+ </t>
1881
+ </section>
1882
+ <section anchor="section6_6_5" title="MEMBER">
1883
+ <t>
1884
+ <list style="hanging">
1885
+ <t hangText="Purpose: ">To include a member in the group this vCard represents.</t>
1886
+ <t hangText="Value type: ">A single URI. It <spanx style="strong">MAY</spanx> refer to something other than a
1887
+ vCard object. For example, an email distribution list could
1888
+ employ the "mailto" URI scheme cite:info[RFC6068] for efficiency.</t>
1889
+ <t hangText="Cardinality: ">*</t>
1890
+ <t hangText="Special notes: ">This property <spanx style="strong">MUST NOT</spanx> be present unless the value of
1891
+ the KIND property is "group".</t>
1892
+ <t hangText="ABNF: ">
1893
+ <figure>
1894
+ <artwork type="abnf"><![CDATA[
1895
+ MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param
1896
+ / mediatype-param / any-param
1897
+ MEMBER-value = URI
1898
+ ]]></artwork>
1899
+ </figure>
1900
+ </t>
1901
+ <t hangText="Examples: ">
1902
+ <figure>
1903
+ <artwork><![CDATA[
1904
+ BEGIN:VCARD
1905
+ VERSION:4.0
1906
+ KIND:group
1907
+ FN:The Doe family
1908
+ MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
1909
+ MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
1910
+ END:VCARD
1911
+ BEGIN:VCARD
1912
+ VERSION:4.0
1913
+ FN:John Doe
1914
+ UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
1915
+ END:VCARD
1916
+ BEGIN:VCARD
1917
+ VERSION:4.0
1918
+ FN:Jane Doe
1919
+ UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
1920
+ END:VCARD
1921
+
1922
+ BEGIN:VCARD
1923
+ VERSION:4.0
1924
+ KIND:group
1925
+ FN:Funky distribution list
1926
+ MEMBER:mailto:subscriber1@example.com
1927
+ MEMBER:xmpp:subscriber2@example.com
1928
+ MEMBER:sip:subscriber3@example.com
1929
+ MEMBER:tel:+1-418-555-5555
1930
+ END:VCARD
1931
+ ]]></artwork>
1932
+ </figure>
1933
+ </t>
1934
+ </list>
1935
+ </t>
1936
+ </section>
1937
+ <section anchor="section6_6_6" title="RELATED">
1938
+ <t>
1939
+ <list style="hanging">
1940
+ <t hangText="Purpose: ">To specify a relationship between another entity and the
1941
+ entity represented by this vCard.</t>
1942
+ <t hangText="Value type: ">A single URI. It can also be reset to a single text
1943
+ value. The text value can be used to specify textual information.</t>
1944
+ <t hangText="Cardinality: ">*</t>
1945
+ <t hangText="Special notes: ">The TYPE parameter <spanx style="strong">MAY</spanx> be used to characterize the
1946
+ related entity. It contains a comma-separated list of values that
1947
+ are registered with IANA as described in <xref target="section10_2"/>. The
1948
+ registry is pre-populated with the values defined in cite:norm[xfn]. This
1949
+ document also specifies two additional values:<list style="hanging">
1950
+ <t hangText="agent: ">an entity who may sometimes act on behalf of the entity
1951
+ associated with the vCard.</t>
1952
+ <t hangText="emergency: ">indicates an emergency contact</t>
1953
+ </list></t>
1954
+ <t hangText="ABNF: ">
1955
+ <figure>
1956
+ <artwork type="abnf"><![CDATA[
1957
+ RELATED-param = RELATED-param-uri / RELATED-param-text
1958
+ RELATED-value = URI / text
1959
+ ; Parameter and value MUST match.
1960
+
1961
+ RELATED-param-uri = "VALUE=uri" / mediatype-param
1962
+ RELATED-param-text = "VALUE=text" / language-param
1963
+
1964
+ RELATED-param =/ pid-param / pref-param / altid-param / type-param
1965
+ / any-param
1966
+
1967
+ type-param-related = related-type-value *("," related-type-value)
1968
+ ; type-param-related MUST NOT be used with a property other than
1969
+ ; RELATED.
1970
+
1971
+ related-type-value = "contact" / "acquaintance" / "friend" / "met"
1972
+ / "co-worker" / "colleague" / "co-resident"
1973
+ / "neighbor" / "child" / "parent"
1974
+ / "sibling" / "spouse" / "kin" / "muse"
1975
+ / "crush" / "date" / "sweetheart" / "me"
1976
+ / "agent" / "emergency"
1977
+ ]]></artwork>
1978
+ </figure>
1979
+ </t>
1980
+ <t hangText="Examples: ">
1981
+ <figure>
1982
+ <artwork><![CDATA[
1983
+ RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
1984
+ RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf
1985
+ RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane
1986
+ Doe for any inquiries.
1987
+ ]]></artwork>
1988
+ </figure>
1989
+ </t>
1990
+ </list>
1991
+ </t>
1992
+ </section></section>
1993
+ <section anchor="section6_7" title="Explanatory Properties"><t>These properties are concerned with additional explanations, such as
1994
+ that related to informational notes or revisions specific to the
1995
+ vCard.</t>
1996
+ <section anchor="section6_7_1" title="CATEGORIES">
1997
+ <t>
1998
+ <list style="hanging">
1999
+ <t hangText="Purpose: ">To specify application category information about the
2000
+ vCard, also known as "tags".</t>
2001
+ <t hangText="Value type: ">One or more text values separated by a COMMA character
2002
+ (U+002C).</t>
2003
+ <t hangText="Cardinality: ">*</t>
2004
+ <t hangText="ABNF: ">
2005
+ <figure>
2006
+ <artwork type="abnf"><![CDATA[
2007
+ CATEGORIES-param = "VALUE=text" / pid-param / pref-param
2008
+ / type-param / altid-param / any-param
2009
+ CATEGORIES-value = text-list
2010
+ ]]></artwork>
2011
+ </figure>
2012
+ </t>
2013
+ <t hangText="Example: ">
2014
+ <figure>
2015
+ <artwork><![CDATA[
2016
+ CATEGORIES:TRAVEL AGENT
2017
+
2018
+ CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
2019
+ ]]></artwork>
2020
+ </figure>
2021
+ </t>
2022
+ </list>
2023
+ </t>
2024
+ </section>
2025
+ <section anchor="section6_7_2" title="NOTE"><t>
2026
+ <list style="hanging">
2027
+ <t hangText="Purpose: ">To specify supplemental information or a comment that is
2028
+ associated with the vCard.</t>
2029
+ <t hangText="Value type: ">A single text value.</t>
2030
+ <t hangText="Cardinality: ">*</t>
2031
+ </list>
2032
+ </t>
2033
+ <t>Special notes: The property is based on the X.520 Description
2034
+ attribute cite:norm[CCITT.X520.1988].</t>
2035
+ <t>
2036
+ <list style="hanging">
2037
+ <t hangText="ABNF: ">
2038
+ <figure>
2039
+ <artwork type="abnf"><![CDATA[
2040
+ NOTE-param = "VALUE=text" / language-param / pid-param / pref-param
2041
+ / type-param / altid-param / any-param
2042
+ NOTE-value = text
2043
+ ]]></artwork>
2044
+ </figure>
2045
+ </t>
2046
+ <t hangText="Example: ">
2047
+ <figure>
2048
+ <artwork><![CDATA[
2049
+ NOTE:This fax number is operational 0800 to 1715
2050
+ EST\, Mon-Fri.
2051
+ ]]></artwork>
2052
+ </figure>
2053
+ </t>
2054
+ </list>
2055
+ </t></section>
2056
+ <section anchor="section6_7_3" title="PRODID">
2057
+ <t>
2058
+ <list style="hanging">
2059
+ <t hangText="Purpose: ">To specify the identifier for the product that created the
2060
+ vCard object.</t>
2061
+ <t hangText="Type value: ">A single text value.</t>
2062
+ <t hangText="Cardinality: ">*1</t>
2063
+ <t hangText="Special notes: ">Implementations <spanx style="strong">SHOULD</spanx> use a method such as that
2064
+ specified for Formal Public Identifiers in cite:info[ISO9070] or for
2065
+ Universal Resource Names in cite:info[RFC3406] to ensure that the text
2066
+ value is unique.</t>
2067
+ <t hangText="ABNF: ">
2068
+ <figure>
2069
+ <artwork type="abnf"><![CDATA[
2070
+ PRODID-param = "VALUE=text" / any-param
2071
+ PRODID-value = text
2072
+ ]]></artwork>
2073
+ </figure>
2074
+ </t>
2075
+ <t hangText="Example: ">
2076
+ <figure>
2077
+ <artwork><![CDATA[
2078
+ PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
2079
+ ]]></artwork>
2080
+ </figure>
2081
+ </t>
2082
+ </list>
2083
+ </t>
2084
+ </section>
2085
+ <section anchor="section6_7_4" title="REV">
2086
+ <t>
2087
+ <list style="hanging">
2088
+ <t hangText="Purpose: ">To specify revision information about the current vCard.</t>
2089
+ <t hangText="Value type: ">A single timestamp value.</t>
2090
+ <t hangText="Cardinality: ">*1</t>
2091
+ <t hangText="Special notes: ">The value distinguishes the current revision of the
2092
+ information in this vCard for other renditions of the information.</t>
2093
+ <t hangText="ABNF: ">
2094
+ <figure>
2095
+ <artwork type="abnf"><![CDATA[
2096
+ REV-param = "VALUE=timestamp" / any-param
2097
+ REV-value = timestamp
2098
+ ]]></artwork>
2099
+ </figure>
2100
+ </t>
2101
+ <t hangText="Example: ">
2102
+ <figure>
2103
+ <artwork><![CDATA[
2104
+ REV:19951031T222710Z
2105
+ ]]></artwork>
2106
+ </figure>
2107
+ </t>
2108
+ </list>
2109
+ </t>
2110
+ </section>
2111
+ <section anchor="section6_7_5" title="SOUND">
2112
+ <t>
2113
+ <list style="hanging">
2114
+ <t hangText="Purpose: ">To specify a digital sound content information that
2115
+ annotates some aspect of the vCard. This property is often used
2116
+ to specify the proper pronunciation of the name property value of
2117
+ the vCard.</t>
2118
+ <t hangText="Value type: ">A single URI.</t>
2119
+ <t hangText="Cardinality: ">*</t>
2120
+ <t hangText="ABNF: ">
2121
+ <figure>
2122
+ <artwork type="abnf"><![CDATA[
2123
+ SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param
2124
+ / type-param / mediatype-param / altid-param
2125
+ / any-param
2126
+ SOUND-value = URI
2127
+ ]]></artwork>
2128
+ </figure>
2129
+ </t>
2130
+ <t hangText="Example: ">
2131
+ <figure>
2132
+ <artwork><![CDATA[
2133
+ SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com
2134
+
2135
+ SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh
2136
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
2137
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
2138
+ <...the remainder of base64-encoded data...>
2139
+ ]]></artwork>
2140
+ </figure>
2141
+ </t>
2142
+ </list>
2143
+ </t>
2144
+ </section>
2145
+ <section anchor="section6_7_6" title="UID">
2146
+ <t>
2147
+ <list style="hanging">
2148
+ <t hangText="Purpose: ">To specify a value that represents a globally unique
2149
+ identifier corresponding to the entity associated with the vCard.</t>
2150
+ <t hangText="Value type: ">A single URI value. It <spanx style="strong">MAY</spanx> also be reset to free-form
2151
+ text.</t>
2152
+ <t hangText="Cardinality: ">*1</t>
2153
+ <t hangText="Special notes: ">This property is used to uniquely identify the object
2154
+ that the vCard represents. The "uuid" URN namespace defined in
2155
+ cite:norm[RFC4122] is particularly well suited to this task, but other URI
2156
+ schemes <spanx style="strong">MAY</spanx> be used. Free-form text <spanx style="strong">MAY</spanx> also be used.</t>
2157
+ <t hangText="ABNF: ">
2158
+ <figure>
2159
+ <artwork type="abnf"><![CDATA[
2160
+ UID-param = UID-uri-param / UID-text-param
2161
+ UID-value = UID-uri-value / UID-text-value
2162
+ ; Value and parameter MUST match.
2163
+
2164
+ UID-uri-param = "VALUE=uri"
2165
+ UID-uri-value = URI
2166
+
2167
+ UID-text-param = "VALUE=text"
2168
+ UID-text-value = text
2169
+
2170
+ UID-param =/ any-param
2171
+ ]]></artwork>
2172
+ </figure>
2173
+ </t>
2174
+ <t hangText="Example: ">
2175
+ <figure>
2176
+ <artwork><![CDATA[
2177
+ UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
2178
+ ]]></artwork>
2179
+ </figure>
2180
+ </t>
2181
+ </list>
2182
+ </t>
2183
+ </section>
2184
+ <section anchor="section6_7_7" title="CLIENTPIDMAP">
2185
+ <t>
2186
+ <list style="hanging">
2187
+ <t hangText="Purpose: ">To give a global meaning to a local PID source identifier.</t>
2188
+ <t hangText="Value type: ">A semicolon-separated pair of values. The first field
2189
+ is a small integer corresponding to the second field of a PID
2190
+ parameter instance. The second field is a URI. The "uuid" URN
2191
+ namespace defined in cite:norm[RFC4122] is particularly well suited to this
2192
+ task, but other URI schemes <spanx style="strong">MAY</spanx> be used.</t>
2193
+ <t hangText="Cardinality: ">*</t>
2194
+ <t hangText="Special notes: ">PID source identifiers (the source identifier is the
2195
+ second field in a PID parameter instance) are small integers that
2196
+ only have significance within the scope of a single vCard
2197
+ instance. Each distinct source identifier present in a vCard <spanx style="strong">MUST</spanx>
2198
+ have an associated CLIENTPIDMAP. See <xref target="section7"/> for more details
2199
+ on the usage of CLIENTPIDMAP.<vspace blankLines="0"/>PID source identifiers <spanx style="strong">MUST</spanx> be strictly positive. Zero is not
2200
+ allowed.
2201
+ <vspace blankLines="0"/>As a special exception, the PID parameter <spanx style="strong">MUST NOT</spanx> be applied to
2202
+ this property.</t>
2203
+ <t hangText="ABNF: ">
2204
+ <figure>
2205
+ <artwork type="abnf"><![CDATA[
2206
+ CLIENTPIDMAP-param = any-param
2207
+ CLIENTPIDMAP-value = 1*DIGIT ";" URI
2208
+ ]]></artwork>
2209
+ </figure>
2210
+ </t>
2211
+ <t hangText="Example: ">
2212
+ <figure>
2213
+ <artwork><![CDATA[
2214
+ TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555
2215
+ EMAIL;PID=4.1,5.2:jdoe@example.com
2216
+ CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b
2217
+ CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5
2218
+ ]]></artwork>
2219
+ </figure>
2220
+ </t>
2221
+ </list>
2222
+ </t>
2223
+ </section>
2224
+ <section anchor="section6_7_8" title="URL">
2225
+ <t>
2226
+ <list style="hanging">
2227
+ <t hangText="Purpose: ">To specify a uniform resource locator associated with the
2228
+ object to which the vCard refers. Examples for individuals
2229
+ include personal web sites, blogs, and social networking site
2230
+ identifiers.</t>
2231
+ <t hangText="Cardinality: ">*</t>
2232
+ <t hangText="Value type: ">A single uri value.</t>
2233
+ <t hangText="ABNF: ">
2234
+ <figure>
2235
+ <artwork type="abnf"><![CDATA[
2236
+ URL-param = "VALUE=uri" / pid-param / pref-param / type-param
2237
+ / mediatype-param / altid-param / any-param
2238
+ URL-value = URI
2239
+ ]]></artwork>
2240
+ </figure>
2241
+ </t>
2242
+ <t hangText="Example: ">
2243
+ <figure>
2244
+ <artwork><![CDATA[
2245
+ URL:http://example.org/restaurant.french/~chezchic.html
2246
+ ]]></artwork>
2247
+ </figure>
2248
+ </t>
2249
+ </list>
2250
+ </t>
2251
+ </section>
2252
+ <section anchor="section6_7_9" title="VERSION">
2253
+ <t>
2254
+ <list style="hanging">
2255
+ <t hangText="Purpose: ">To specify the version of the vCard specification used to
2256
+ format this vCard.</t>
2257
+ <t hangText="Value type: ">A single text value.</t>
2258
+ <t hangText="Cardinality: ">1</t>
2259
+ <t hangText="Special notes: ">This property <spanx style="strong">MUST</spanx> be present in the vCard object,
2260
+ and it must appear immediately after BEGIN:VCARD. The value <spanx style="strong">MUST</spanx>
2261
+ be "4.0" if the vCard corresponds to this specification. Note
2262
+ that earlier versions of vCard allowed this property to be placed
2263
+ anywhere in the vCard object, or even to be absent.</t>
2264
+ <t hangText="ABNF: ">
2265
+ <figure>
2266
+ <artwork type="abnf"><![CDATA[
2267
+ VERSION-param = "VALUE=text" / any-param
2268
+ VERSION-value = "4.0"
2269
+ ]]></artwork>
2270
+ </figure>
2271
+ </t>
2272
+ <t hangText="Example: ">
2273
+ <figure>
2274
+ <artwork><![CDATA[
2275
+ VERSION:4.0
2276
+ ]]></artwork>
2277
+ </figure>
2278
+ </t>
2279
+ </list>
2280
+ </t>
2281
+ </section></section>
2282
+ <section anchor="section6_8" title="Security Properties"><t>These properties are concerned with the security of communication
2283
+ pathways or access to the vCard.</t>
2284
+ <section anchor="section6_8_1" title="KEY">
2285
+ <t>
2286
+ <list style="hanging">
2287
+ <t hangText="Purpose: ">To specify a public key or authentication certificate
2288
+ associated with the object that the vCard represents.</t>
2289
+ <t hangText="Value type: ">A single URI. It can also be reset to a text value.</t>
2290
+ <t hangText="Cardinality: ">*</t>
2291
+ <t hangText="ABNF: ">
2292
+ <figure>
2293
+ <artwork type="abnf"><![CDATA[
2294
+ KEY-param = KEY-uri-param / KEY-text-param
2295
+ KEY-value = KEY-uri-value / KEY-text-value
2296
+ ; Value and parameter MUST match.
2297
+
2298
+ KEY-uri-param = "VALUE=uri" / mediatype-param
2299
+ KEY-uri-value = URI
2300
+
2301
+ KEY-text-param = "VALUE=text"
2302
+ KEY-text-value = text
2303
+
2304
+ KEY-param =/ altid-param / pid-param / pref-param / type-param
2305
+ / any-param
2306
+ ]]></artwork>
2307
+ </figure>
2308
+ </t>
2309
+ <t hangText="Examples: ">
2310
+ <figure>
2311
+ <artwork><![CDATA[
2312
+ KEY:http://www.example.com/keys/jdoe.cer
2313
+
2314
+ KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe
2315
+
2316
+ KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE
2317
+ UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
2318
+ <... remainder of base64-encoded data ...>
2319
+ ]]></artwork>
2320
+ </figure>
2321
+ </t>
2322
+ </list>
2323
+ </t>
2324
+ </section></section>
2325
+ <section anchor="section6_9" title="Calendar Properties"><t>These properties are further specified in cite:norm[RFC2739].</t>
2326
+ <section anchor="secton6_9_1" title="FBURL">
2327
+ <t>
2328
+ <list style="hanging">
2329
+ <t hangText="Purpose: ">To specify the URI for the busy time associated with the
2330
+ object that the vCard represents.</t>
2331
+ <t hangText="Value type: ">A single URI value.</t>
2332
+ <t hangText="Cardinality: ">*</t>
2333
+ <t hangText="Special notes: ">Where multiple FBURL properties are specified, the
2334
+ default FBURL property is indicated with the PREF parameter. The
2335
+ FTP cite:info[RFC1738] or HTTP cite:info[RFC2616] type of URI points to an iCalendar
2336
+ cite:norm[RFC5545] object associated with a snapshot of the next few weeks
2337
+ or months of busy time data. If the iCalendar object is
2338
+ represented as a file or document, its file extension should be
2339
+ ".ifb".</t>
2340
+ <t hangText="ABNF: ">
2341
+ <figure>
2342
+ <artwork type="abnf"><![CDATA[
2343
+ FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param
2344
+ / mediatype-param / altid-param / any-param
2345
+ FBURL-value = URI
2346
+ ]]></artwork>
2347
+ </figure>
2348
+ </t>
2349
+ <t hangText="Examples: ">
2350
+ <figure>
2351
+ <artwork><![CDATA[
2352
+ FBURL;PREF=1:http://www.example.com/busy/janedoe
2353
+ FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb
2354
+ ]]></artwork>
2355
+ </figure>
2356
+ </t>
2357
+ </list>
2358
+ </t>
2359
+ </section>
2360
+ <section anchor="section6_9_2" title="CALADRURI">
2361
+ <t>
2362
+ <list style="hanging">
2363
+ <t hangText="Purpose: ">To specify the calendar user address cite:norm[RFC5545] to which a
2364
+ scheduling request cite:norm[RFC5546] should be sent for the object
2365
+ represented by the vCard.</t>
2366
+ <t hangText="Value type: ">A single URI value.</t>
2367
+ <t hangText="Cardinality: ">*</t>
2368
+ <t hangText="Special notes: ">Where multiple CALADRURI properties are specified,
2369
+ the default CALADRURI property is indicated with the PREF
2370
+ parameter.</t>
2371
+ <t hangText="ABNF: ">
2372
+ <figure>
2373
+ <artwork type="abnf"><![CDATA[
2374
+ CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param
2375
+ / mediatype-param / altid-param / any-param
2376
+ CALADRURI-value = URI
2377
+ ]]></artwork>
2378
+ </figure>
2379
+ </t>
2380
+ <t hangText="Example: ">
2381
+ <figure>
2382
+ <artwork><![CDATA[
2383
+ CALADRURI;PREF=1:mailto:janedoe@example.com
2384
+ CALADRURI:http://example.com/calendar/jdoe
2385
+ ]]></artwork>
2386
+ </figure>
2387
+ </t>
2388
+ </list>
2389
+ </t>
2390
+ </section>
2391
+ <section anchor="section6_9_3" title="CALURI">
2392
+ <t>
2393
+ <list style="hanging">
2394
+ <t hangText="Purpose: ">To specify the URI for a calendar associated with the
2395
+ object represented by the vCard.</t>
2396
+ <t hangText="Value type: ">A single URI value.</t>
2397
+ <t hangText="Cardinality: ">*</t>
2398
+ <t hangText="Special notes: ">Where multiple CALURI properties are specified, the
2399
+ default CALURI property is indicated with the PREF parameter. The
2400
+ property should contain a URI pointing to an iCalendar cite:norm[RFC5545]
2401
+ object associated with a snapshot of the user&#8217;s calendar store.
2402
+ If the iCalendar object is represented as a file or document, its
2403
+ file extension should be ".ics".</t>
2404
+ <t hangText="ABNF: ">
2405
+ <figure>
2406
+ <artwork type="abnf"><![CDATA[
2407
+ CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param
2408
+ / mediatype-param / altid-param / any-param
2409
+ CALURI-value = URI
2410
+ ]]></artwork>
2411
+ </figure>
2412
+ </t>
2413
+ <t hangText="Examples: ">
2414
+ <figure>
2415
+ <artwork><![CDATA[
2416
+ CALURI;PREF=1:http://cal.example.com/calA
2417
+ CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics
2418
+ ]]></artwork>
2419
+ </figure>
2420
+ </t>
2421
+ </list>
2422
+ </t>
2423
+ </section></section>
2424
+ <section anchor="section6_10" title="Extended Properties and Parameters">
2425
+ <t>The properties and parameters defined by this document can be
2426
+ extended. Non-standard, private properties and parameters with a
2427
+ name starting with "X-" may be defined bilaterally between two
2428
+ cooperating agents without outside registration or standardization.</t>
2429
+ </section></section>
2430
+ <section anchor="section7" title="Synchronization"><t>vCard data often needs to be synchronized between devices. In this
2431
+ context, synchronization is defined as the intelligent merging of two
2432
+ representations of the same object. vCard 4.0 includes mechanisms to
2433
+ aid this process.</t>
2434
+ <section anchor="section7_1" title="Mechanisms"><t>Two mechanisms are available: the UID property is used to match
2435
+ multiple instances of the same vCard, while the PID parameter is used
2436
+ to match multiple instances of the same property.</t>
2437
+ <t>The term "matching" is used here to mean recognizing that two
2438
+ instances are in fact representations of the same object. For
2439
+ example, a single vCard that is shared with someone results in two
2440
+ vCard instances. After they have evolved separately, they still
2441
+ represent the same object, and therefore may be matched by a
2442
+ synchronization engine.</t>
2443
+ <section anchor="section7_1_1" title="Matching vCard Instances"><t>vCard instances for which the UID properties (<xref target="section6_7_6"/>) are
2444
+ equivalent <spanx style="strong">MUST</spanx> be matched. Equivalence is determined as specified
2445
+ in cite:norm[RFC3986, suffix=", Section 6"].</t>
2446
+ <t>In all other cases, vCard instances <spanx style="strong">MAY</spanx> be matched at the discretion
2447
+ of the synchronization engine.</t></section>
2448
+ <section anchor="section7_1_2" title="Matching Property Instances"><t>Property instances belonging to unmatched vCards <spanx style="strong">MUST NOT</spanx> be matched.</t>
2449
+ <t>Property instances whose name (e.g., EMAIL, TEL, etc.) is not the
2450
+ same <spanx style="strong">MUST NOT</spanx> be matched.</t>
2451
+ <t>Property instances whose name is CLIENTPIDMAP are handled separately
2452
+ and <spanx style="strong">MUST NOT</spanx> be matched. The synchronization <spanx style="strong">MUST</spanx> ensure that there
2453
+ is consistency of CLIENTPIDMAPs among matched vCard instances.</t>
2454
+ <t>Property instances belonging to matched vCards, whose name is the
2455
+ same, and whose maximum cardinality is 1, <spanx style="strong">MUST</spanx> be matched.</t>
2456
+ <t>Property instances belonging to matched vCards, whose name is the
2457
+ same, and whose PID parameters match, <spanx style="strong">MUST</spanx> be matched. See
2458
+ <xref target="section7_1_3"/> for details on PID matching.</t>
2459
+ <t>In all other cases, property instances <spanx style="strong">MAY</spanx> be matched at the
2460
+ discretion of the synchronization engine.</t></section>
2461
+ <section anchor="section7_1_3" title="PID Matching"><t>Two PID values for which the first fields are equivalent represent
2462
+ the same local value.</t>
2463
+ <t>Two PID values representing the same local value and for which the
2464
+ second fields point to CLIENTPIDMAP properties whose second field
2465
+ URIs are equivalent (as specified in cite:norm[RFC3986, suffix=", Section 6"]) also
2466
+ represent the same global value.</t>
2467
+ <t>PID parameters for which at least one pair of their values represent
2468
+ the same global value <spanx style="strong">MUST</spanx> be matched.</t>
2469
+ <t>In all other cases, PID parameters <spanx style="strong">MAY</spanx> be matched at the discretion
2470
+ of the synchronization engine.</t>
2471
+ <t>For example, PID value "5.1", in the first vCard below, and PID value
2472
+ "5.2", in the second vCard below, represent the same global value.</t>
2473
+ <figure>
2474
+ <artwork><![CDATA[
2475
+ BEGIN:VCARD
2476
+ VERSION:4.0
2477
+ EMAIL;PID=4.2,5.1:jdoe@example.com
2478
+ CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
2479
+ CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
2480
+ END:VCARD
2481
+ ]]></artwork>
2482
+ </figure>
2483
+ <figure>
2484
+ <artwork><![CDATA[
2485
+ BEGIN:VCARD
2486
+ VERSION:4.0
2487
+ EMAIL;PID=5.1,5.2:john@example.com
2488
+ CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
2489
+ CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
2490
+ END:VCARD
2491
+ ]]></artwork>
2492
+ </figure></section></section>
2493
+ <section anchor="section7_2" title="Example"><section anchor="section7_2_1" title="Creation"><t>The following simple vCard is first created on a given device.</t>
2494
+ <figure>
2495
+ <artwork><![CDATA[
2496
+ BEGIN:VCARD
2497
+ VERSION:4.0
2498
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2499
+ FN;PID=1.1:J. Doe
2500
+ N:Doe;J.;;;
2501
+ EMAIL;PID=1.1:jdoe@example.com
2502
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2503
+ END:VCARD
2504
+ ]]></artwork>
2505
+ </figure>
2506
+ <t>This new vCard is assigned the UID
2507
+ "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating
2508
+ device. The FN and EMAIL properties are assigned the same local
2509
+ value of 1, and this value is given global context by associating it
2510
+ with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which
2511
+ represents the creating device. We are at liberty to reuse the same
2512
+ local value since instances of different properties will never be
2513
+ matched. The N property has no PID because it is forbidden by its
2514
+ maximum cardinality of 1.</t></section>
2515
+ <section anchor="section7_2_2" title="Initial Sharing">
2516
+ <t>This vCard is shared with a second device. Upon inspecting the UID
2517
+ property, the second device understands that this is a new vCard
2518
+ (i.e., unmatched) and thus the synchronization results in a simple
2519
+ copy.</t>
2520
+ </section>
2521
+ <section anchor="section7_2_3" title="Adding and Sharing a Property"><t>A new phone number is created on the first device, then the vCard is
2522
+ shared with the second device. This is what the second device
2523
+ receives:</t>
2524
+ <figure>
2525
+ <artwork><![CDATA[
2526
+ BEGIN:VCARD
2527
+ VERSION:4.0
2528
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2529
+ FN;PID=1.1:J. Doe
2530
+ N:Doe;J.;;;
2531
+ EMAIL;PID=1.1:jdoe@example.com
2532
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
2533
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2534
+ END:VCARD
2535
+ ]]></artwork>
2536
+ </figure>
2537
+ <t>Upon inspecting the UID property, the second device matches the vCard
2538
+ it received to the vCard that it already has stored. It then starts
2539
+ comparing the properties of the two vCards in same-named pairs.</t>
2540
+ <t>The FN properties are matched because the PID parameters have the
2541
+ same global value. Since the property value is the same, no update
2542
+ takes place.</t>
2543
+ <t>The N properties are matched automatically because their maximum
2544
+ cardinality is 1. Since the property value is the same, no update
2545
+ takes place.</t>
2546
+ <t>The EMAIL properties are matched because the PID parameters have the
2547
+ same global value. Since the property value is the same, no update
2548
+ takes place.</t>
2549
+ <t>The TEL property in the new vCard is not matched to any in the stored
2550
+ vCard because no property in the stored vCard has the same name.
2551
+ Therefore, this property is copied from the new vCard to the stored
2552
+ vCard.</t>
2553
+ <t>The CLIENTPIDMAP property is handled separately by the
2554
+ synchronization engine. It ensures that it is consistent with the
2555
+ stored one. If it was not, the results would be up to the
2556
+ synchronization engine, and thus undefined by this document.</t></section>
2557
+ <section anchor="section7_2_4" title="Simultaneous Editing"><t>A new email address and a new phone number are added to the vCard on
2558
+ each of the two devices, and then a new synchronization event
2559
+ happens. Here are the vCards that are communicated to each other:</t>
2560
+ <figure>
2561
+ <artwork><![CDATA[
2562
+ BEGIN:VCARD
2563
+ VERSION:4.0
2564
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2565
+ FN;PID=1.1:J. Doe
2566
+ N:Doe;J.;;;
2567
+ EMAIL;PID=1.1:jdoe@example.com
2568
+ EMAIL;PID=2.1:boss@example.com
2569
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
2570
+ TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
2571
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2572
+ END:VCARD
2573
+ ]]></artwork>
2574
+ </figure>
2575
+ <figure>
2576
+ <artwork><![CDATA[
2577
+ BEGIN:VCARD
2578
+ VERSION:4.0
2579
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2580
+ FN;PID=1.1:J. Doe
2581
+ N:Doe;J.;;;
2582
+ EMAIL;PID=1.1:jdoe@example.com
2583
+ EMAIL;PID=2.2:ceo@example.com
2584
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
2585
+ TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666
2586
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2587
+ CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
2588
+ END:VCARD
2589
+ ]]></artwork>
2590
+ </figure>
2591
+ <t>On the first device, the same PID source identifier (1) is reused for
2592
+ the new EMAIL and TEL properties. On the second device, a new source
2593
+ identifier (2) is generated, and a corresponding CLIENTPIDMAP
2594
+ property is created. It contains the second device&#8217;s identifier,
2595
+ "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee".</t>
2596
+ <t>The new EMAIL properties are unmatched on both sides since the PID
2597
+ global value is new in both cases. The sync thus results in a copy
2598
+ on both sides.</t>
2599
+ <t>Although the situation appears to be the same for the TEL properties,
2600
+ in this case, the synchronization engine is particularly smart and
2601
+ matches the two new TEL properties even though their PID global
2602
+ values are different. Note that in this case, the rules of
2603
+ <xref target="section7_1_2"/> state that two properties <spanx style="strong">MAY</spanx> be matched at the
2604
+ discretion of the synchronization engine. Therefore, the two
2605
+ properties are merged.</t>
2606
+ <t>All this results in the following vCard, which is stored on both
2607
+ devices:</t>
2608
+ <figure>
2609
+ <artwork><![CDATA[
2610
+ BEGIN:VCARD
2611
+ VERSION:4.0
2612
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2613
+ FN:J. Doe
2614
+ N:Doe;J.;;;
2615
+ EMAIL;PID=1.1:jdoe@example.com
2616
+ EMAIL;PID=2.1:boss@example.com
2617
+ EMAIL;PID=2.2:ceo@example.com
2618
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
2619
+ TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666
2620
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2621
+ CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
2622
+ END:VCARD
2623
+ ]]></artwork>
2624
+ </figure></section>
2625
+ <section anchor="section7_2_5" title="Global Context Simplification"><t>The two devices finish their synchronization procedure by simplifying
2626
+ their global contexts. Since they haven&#8217;t talked to any other
2627
+ device, the following vCard is for all purposes equivalent to the
2628
+ above. It is also shorter.</t>
2629
+ <figure>
2630
+ <artwork><![CDATA[
2631
+ BEGIN:VCARD
2632
+ VERSION:4.0
2633
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2634
+ FN:J. Doe
2635
+ N:Doe;J.;;;
2636
+ EMAIL;PID=1.1:jdoe@example.com
2637
+ EMAIL;PID=2.1:boss@example.com
2638
+ EMAIL;PID=3.1:ceo@example.com
2639
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
2640
+ TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
2641
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2642
+ END:VCARD
2643
+ ]]></artwork>
2644
+ </figure>
2645
+ <t>The details of global context simplification are unspecified by this
2646
+ document. They are left up to the synchronization engine. This
2647
+ example is merely intended to illustrate the possibility, which
2648
+ investigating would be, in the author&#8217;s opinion, worthwhile.</t></section></section></section>
2649
+ <section anchor="section8" title="Example: Author&#8217;s vCard">
2650
+ <figure>
2651
+ <artwork><![CDATA[
2652
+ BEGIN:VCARD
2653
+ VERSION:4.0
2654
+ FN:Simon Perreault
2655
+ N:Perreault;Simon;;;ing. jr,M.Sc.
2656
+ BDAY:--0203
2657
+ ANNIVERSARY:20090808T1430-0500
2658
+ GENDER:M
2659
+ LANG;PREF=1:fr
2660
+ LANG;PREF=2:en
2661
+ ORG;TYPE=work:Viagenie
2662
+ ADR;TYPE=work:;Suite D2-630;2875 Laurier;
2663
+ Quebec;QC;G1V 2M2;Canada
2664
+ TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
2665
+ TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501
2666
+ EMAIL;TYPE=work:simon.perreault@viagenie.ca
2667
+ GEO;TYPE=work:geo:46.772673,-71.282945
2668
+ KEY;TYPE=work;VALUE=uri:
2669
+ http://www.viagenie.ca/simon.perreault/simon.asc
2670
+ TZ:-0500
2671
+ URL;TYPE=home:http://nomis80.org
2672
+ END:VCARD
2673
+ ]]></artwork>
2674
+ </figure>
2675
+ </section>
2676
+ <section anchor="section9" title="Security Considerations">
2677
+ <t>
2678
+ <list style="symbols">
2679
+ <t>Internet mail is often used to transport vCards and is subject to
2680
+ many well-known security attacks, including monitoring, replay,
2681
+ and forgery. Care should be taken by any directory service in
2682
+ allowing information to leave the scope of the service itself,
2683
+ where any access controls or confidentiality can no longer be
2684
+ guaranteed. Applications should also take care to display
2685
+ directory data in a "safe" environment.</t>
2686
+ <t>vCards can carry cryptographic keys or certificates, as described
2687
+ in <xref target="section6_8_1"/>.</t>
2688
+ <t>vCards often carry information that can be sensitive (e.g.,
2689
+ birthday, address, and phone information). Although vCards have
2690
+ no inherent authentication or confidentiality provisions, they can
2691
+ easily be carried by any security mechanism that transfers MIME
2692
+ objects to address authentication or confidentiality (e.g., S/MIME
2693
+ cite:info[RFC5751], OpenPGP cite:info[RFC4880]). In cases where the confidentiality
2694
+ or authenticity of information contained in vCard is a concern,
2695
+ the vCard <spanx style="strong">SHOULD</spanx> be transported using one of these secure
2696
+ mechanisms. The KEY property (<xref target="section6_8_1"/>) can be used to
2697
+ transport the public key used by these mechanisms.</t>
2698
+ <t>The information in a vCard may become out of date. In cases where
2699
+ the vitality of data is important to an originator of a vCard, the
2700
+ SOURCE property (<xref target="section6_1_3"/>) <spanx style="strong">SHOULD</spanx> be specified. In addition,
2701
+ the "REV" type described in <xref target="section6_7_4"/> can be specified to
2702
+ indicate the last time that the vCard data was updated.</t>
2703
+ <t>Many vCard properties may be used to transport URIs. Please refer
2704
+ to cite:norm[RFC3986, suffix=", Section 7"], for considerations related to URIs.</t>
2705
+ </list>
2706
+ </t>
2707
+ </section>
2708
+ <section anchor="section10" title="IANA Considerations"><section anchor="section10_1" title="Media Type Registration"><t>IANA has registered the following Media Type (in
2709
+ <eref target="http://www.iana.org"/>) and marked the text/directory Media Type as
2710
+ DEPRECATED.</t>
2711
+ <t>
2712
+ <list style="hanging">
2713
+ <t hangText="To: ">ietf-types@iana.org</t>
2714
+ <t hangText="Subject: ">Registration of media type text/vcard</t>
2715
+ <t hangText="Type name: ">text</t>
2716
+ <t hangText="Subtype name: ">vcard</t>
2717
+ <t hangText="Required parameters: ">none</t>
2718
+ <t hangText="Optional parameters: ">version<vspace blankLines="0"/>The "version" parameter is to be interpreted identically as the
2719
+ VERSION vCard property. If this parameter is present, all vCards
2720
+ in a text/vcard body part <spanx style="strong">MUST</spanx> have a VERSION property with value
2721
+ identical to that of this MIME parameter.
2722
+ <vspace blankLines="0"/>"charset": as defined for text/plain cite:norm[RFC2046]; encodings other
2723
+ than UTF-8 cite:norm[RFC3629] <spanx style="strong">MUST NOT</spanx> be used.</t>
2724
+ <t hangText="Encoding considerations: ">8bit</t>
2725
+ <t hangText="Security considerations: ">See <xref target="section9"/>.</t>
2726
+ <t hangText="Interoperability considerations: ">The text/vcard media type is
2727
+ intended to identify vCard data of any version. There are older
2728
+ specifications of vCard cite:info[RFC2426] cite:info[vCard21] still in common use.
2729
+ While these formats are similar, they are not strictly compatible.
2730
+ In general, it is necessary to inspect the value of the VERSION
2731
+ property (see <xref target="section6_7_9"/>) for identifying the standard to which
2732
+ a given vCard object conforms.<vspace blankLines="0"/>In addition, the following media types are known to have been used
2733
+ to refer to vCard data. They should be considered deprecated in
2734
+ favor of text/vcard.
2735
+ <list style="symbols">
2736
+ <t>text/directory</t>
2737
+ <t>text/directory; profile=vcard</t>
2738
+ <t>text/x-vcard</t>
2739
+ </list></t>
2740
+ <t hangText="Published specification: ">RFC 6350</t>
2741
+ <t hangText="Applications that use this media type: ">They are numerous, diverse,
2742
+ and include mail user agents, instant messaging clients, address
2743
+ book applications, directory servers, and customer relationship
2744
+ management software.</t>
2745
+ <t hangText="Additional information: ">
2746
+ <list style="hanging">
2747
+ <t hangText="Magic number(s): "/>
2748
+ <t hangText="File extension(s): ">.vcf .vcard</t>
2749
+ <t hangText="Macintosh file type code(s): "/>
2750
+ </list>
2751
+ </t>
2752
+ <t hangText="Person &amp; email address to contact for further information: ">vCard
2753
+ discussion mailing list &lt;vcarddav@ietf.org&gt;</t>
2754
+ <t hangText="Intended usage: ">COMMON</t>
2755
+ <t hangText="Restrictions on usage: ">none</t>
2756
+ <t hangText="Author: ">Simon Perreault</t>
2757
+ <t hangText="Change controller: ">IETF</t>
2758
+ </list>
2759
+ </t></section>
2760
+ <section anchor="section10_2" title="Registering New vCard Elements"><t>This section defines the process for registering new or modified
2761
+ vCard elements (i.e., properties, parameters, value data types, and
2762
+ values) with IANA.</t>
2763
+ <section anchor="section10_2_1" title="Registration Procedure"><t>The IETF has created a mailing list, vcarddav@ietf.org, which can be
2764
+ used for public discussion of vCard element proposals prior to
2765
+ registration. Use of the mailing list is strongly encouraged. The
2766
+ IESG has appointed a designated expert who will monitor the
2767
+ vcarddav@ietf.org mailing list and review registrations.</t>
2768
+ <t>Registration of new vCard elements <spanx style="strong">MUST</spanx> be reviewed by the designated
2769
+ expert and published in an RFC. A Standards Track RFC is <spanx style="strong">REQUIRED</spanx>
2770
+ for the registration of new value data types that modify existing
2771
+ properties. A Standards Track RFC is also <spanx style="strong">REQUIRED</spanx> for registration
2772
+ of vCard elements that modify vCard elements previously documented in
2773
+ a Standards Track RFC.</t>
2774
+ <t>The registration procedure begins when a completed registration
2775
+ template, defined in the sections below, is sent to vcarddav@ietf.org
2776
+ and iana@iana.org. Within two weeks, the designated expert is
2777
+ expected to tell IANA and the submitter of the registration whether
2778
+ the registration is approved, approved with minor changes, or
2779
+ rejected with cause. When a registration is rejected with cause, it
2780
+ can be re-submitted if the concerns listed in the cause are
2781
+ addressed. Decisions made by the designated expert can be appealed
2782
+ to the IESG Applications Area Director, then to the IESG. They
2783
+ follow the normal appeals procedure for IESG decisions.</t>
2784
+ <t>Once the registration procedure concludes successfully, IANA creates
2785
+ or modifies the corresponding record in the vCard registry. The
2786
+ completed registration template is discarded.</t>
2787
+ <t>An RFC specifying new vCard elements <spanx style="strong">MUST</spanx> include the completed
2788
+ registration templates, which <spanx style="strong">MAY</spanx> be expanded with additional
2789
+ information. These completed templates are intended to go in the
2790
+ body of the document, not in the IANA Considerations section.</t>
2791
+ <t>Finally, note that there is an XML representation for vCard defined
2792
+ in cite:norm[RFC6351]. An XML representation <spanx style="strong">SHOULD</spanx> be defined for new vCard
2793
+ elements.</t></section>
2794
+ <section anchor="section10_2_2" title="Vendor Namespace"><t>The vendor namespace is used for vCard elements associated with
2795
+ commercially available products. "Vendor" or "producer" are
2796
+ construed as equivalent and very broadly in this context.</t>
2797
+ <t>A registration may be placed in the vendor namespace by anyone who
2798
+ needs to interchange files associated with the particular product.
2799
+ However, the registration formally belongs to the vendor or
2800
+ organization handling the vCard elements in the namespace being
2801
+ registered. Changes to the specification will be made at their
2802
+ request, as discussed in subsequent sections.</t>
2803
+ <t>vCard elements belonging to the vendor namespace will be
2804
+ distinguished by the "VND-" prefix. This is followed by an IANA-
2805
+ registered Private Enterprise Number (PEN), a dash, and a vCard
2806
+ element designation of the vendor&#8217;s choosing (e.g., "VND-123456-
2807
+ MUDPIE").</t>
2808
+ <t>While public exposure and review of vCard elements to be registered
2809
+ in the vendor namespace are not required, using the vcarddav@ietf.org
2810
+ mailing list for review is strongly encouraged to improve the quality
2811
+ of those specifications. Registrations in the vendor namespace may
2812
+ be submitted directly to the IANA.</t></section>
2813
+ <section anchor="section10_2_3" title="Registration Template for Properties"><t>A property is defined by completing the following template.</t>
2814
+ <t>
2815
+ <list style="hanging">
2816
+ <t hangText="Namespace: ">Empty for the global namespace, "VND-NNNN-" for a vendor-
2817
+ specific property (where NNNN is replaced by the vendor&#8217;s PEN).</t>
2818
+ <t hangText="Property name: ">The name of the property.</t>
2819
+ <t hangText="Purpose: ">The purpose of the property. Give a short but clear
2820
+ description.</t>
2821
+ <t hangText="Value type: ">Any of the valid value types for the property value
2822
+ needs to be specified. The default value type also needs to be
2823
+ specified.</t>
2824
+ <t hangText="Cardinality: ">See <xref target="section6"/>.</t>
2825
+ <t hangText="Property parameters: ">Any of the valid property parameters for the
2826
+ property <spanx style="strong">MUST</spanx> be specified.</t>
2827
+ <t hangText="Description: ">Any special notes about the property, how it is to be
2828
+ used, etc.</t>
2829
+ <t hangText="Format definition: ">The ABNF for the property definition needs to be
2830
+ specified.</t>
2831
+ <t hangText="Example(s): ">One or more examples of instances of the property need
2832
+ to be specified.</t>
2833
+ </list>
2834
+ </t></section>
2835
+ <section anchor="section10_2_4" title="Registration Template for Parameters"><t>A parameter is defined by completing the following template.</t>
2836
+ <t>
2837
+ <list style="hanging">
2838
+ <t hangText="Namespace: ">Empty for the global namespace, "VND-NNNN-" for a vendor-
2839
+ specific property (where NNNN is replaced by the vendor&#8217;s PEN).</t>
2840
+ <t hangText="Parameter name: ">The name of the parameter.</t>
2841
+ <t hangText="Purpose: ">The purpose of the parameter. Give a short but clear
2842
+ description.</t>
2843
+ <t hangText="Description: ">Any special notes about the parameter, how it is to be
2844
+ used, etc.</t>
2845
+ <t hangText="Format definition: ">The ABNF for the parameter definition needs to be
2846
+ specified.</t>
2847
+ <t hangText="Example(s): ">One or more examples of instances of the parameter need
2848
+ to be specified.</t>
2849
+ </list>
2850
+ </t></section>
2851
+ <section anchor="section10_2_5" title="Registration Template for Value Data Types"><t>A value data type is defined by completing the following template.</t>
2852
+ <t>
2853
+ <list style="hanging">
2854
+ <t hangText="Value name: ">The name of the value type.</t>
2855
+ <t hangText="Purpose: ">The purpose of the value type. Give a short but clear
2856
+ description.</t>
2857
+ <t hangText="Description: ">Any special notes about the value type, how it is to be
2858
+ used, etc.</t>
2859
+ <t hangText="Format definition: ">The ABNF for the value type definition needs to
2860
+ be specified.</t>
2861
+ <t hangText="Example(s): ">One or more examples of instances of the value type need
2862
+ to be specified.</t>
2863
+ </list>
2864
+ </t></section>
2865
+ <section anchor="section10_2_6" title="Registration Template for Values"><t>A value is defined by completing the following template.</t>
2866
+ <t>
2867
+ <list style="hanging">
2868
+ <t hangText="Value: ">The value literal.</t>
2869
+ <t hangText="Purpose: ">The purpose of the value. Give a short but clear
2870
+ description.</t>
2871
+ <t hangText="Conformance: ">The vCard properties and/or parameters that can take
2872
+ this value needs to be specified.</t>
2873
+ <t hangText="Example(s): ">One or more examples of instances of the value need to
2874
+ be specified.</t>
2875
+ </list>
2876
+ </t>
2877
+ <t>The following is a fictitious example of a registration of a vCard
2878
+ value:</t>
2879
+ <t>
2880
+ <list style="hanging">
2881
+ <t hangText="Value: ">supervisor</t>
2882
+ <t hangText="Purpose: ">It means that the related entity is the direct hierarchical
2883
+ superior (i.e., supervisor or manager) of the entity this vCard
2884
+ represents.</t>
2885
+ <t hangText="Conformance: ">This value can be used with the "TYPE" parameter
2886
+ applied on the "RELATED" property.</t>
2887
+ <t hangText="Example(s): ">
2888
+ <figure>
2889
+ <artwork><![CDATA[
2890
+ RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
2891
+ ]]></artwork>
2892
+ </figure>
2893
+ </t>
2894
+ </list>
2895
+ </t></section></section>
2896
+ <section anchor="section10_3" title="Initial vCard Elements Registries"><t>The IANA has created and will maintain the following registries for
2897
+ vCard elements with pointers to appropriate reference documents. The
2898
+ registries are grouped together under the heading "vCard Elements".</t>
2899
+ <section anchor="section10_3_1" title="Properties Registry"><t>The following table has been used to initialize the properties
2900
+ registry.</t>
2901
+ <texttable suppress-title="false" style="full">
2902
+ <ttcol align="left">Namespace</ttcol>
2903
+ <ttcol align="left">Property</ttcol>
2904
+ <ttcol align="left">Reference</ttcol>
2905
+ <c/>
2906
+ <c>SOURCE</c>
2907
+ <c>RFC 6350, Section 6.1.3</c>
2908
+ <c/>
2909
+ <c>KIND</c>
2910
+ <c>RFC 6350, Section 6.1.4</c>
2911
+ <c/>
2912
+ <c>XML</c>
2913
+ <c>RFC 6350, Section 6.1.5</c>
2914
+ <c/>
2915
+ <c>FN</c>
2916
+ <c>RFC 6350, Section 6.2.1</c>
2917
+ <c/>
2918
+ <c>N</c>
2919
+ <c>RFC 6350, Section 6.2.2</c>
2920
+ <c/>
2921
+ <c>NICKNAME</c>
2922
+ <c>RFC 6350, Section 6.2.3</c>
2923
+ <c/>
2924
+ <c>PHOTO</c>
2925
+ <c>RFC 6350, Section 6.2.4</c>
2926
+ <c/>
2927
+ <c>BDAY</c>
2928
+ <c>RFC 6350, Section 6.2.5</c>
2929
+ <c/>
2930
+ <c>ANNIVERSARY</c>
2931
+ <c>RFC 6350, Section 6.2.6</c>
2932
+ <c/>
2933
+ <c>GENDER</c>
2934
+ <c>RFC 6350, Section 6.2.7</c>
2935
+ <c/>
2936
+ <c>ADR</c>
2937
+ <c>RFC 6350, Section 6.3.1</c>
2938
+ <c/>
2939
+ <c>TEL</c>
2940
+ <c>RFC 6350, Section 6.4.1</c>
2941
+ <c/>
2942
+ <c>EMAIL</c>
2943
+ <c>RFC 6350, Section 6.4.2</c>
2944
+ <c/>
2945
+ <c>IMPP</c>
2946
+ <c>RFC 6350, Section 6.4.3</c>
2947
+ <c/>
2948
+ <c>LANG</c>
2949
+ <c>RFC 6350, Section 6.4.4</c>
2950
+ <c/>
2951
+ <c>TZ</c>
2952
+ <c>RFC 6350, Section 6.5.1</c>
2953
+ <c/>
2954
+ <c>GEO</c>
2955
+ <c>RFC 6350, Section 6.5.2</c>
2956
+ <c/>
2957
+ <c>TITLE</c>
2958
+ <c>RFC 6350, Section 6.6.1</c>
2959
+ <c/>
2960
+ <c>ROLE</c>
2961
+ <c>RFC 6350, Section 6.6.2</c>
2962
+ <c/>
2963
+ <c>LOGO</c>
2964
+ <c>RFC 6350, Section 6.6.3</c>
2965
+ <c/>
2966
+ <c>ORG</c>
2967
+ <c>RFC 6350, Section 6.6.4</c>
2968
+ <c/>
2969
+ <c>MEMBER</c>
2970
+ <c>RFC 6350, Section 6.6.5</c>
2971
+ <c/>
2972
+ <c>RELATED</c>
2973
+ <c>RFC 6350, Section 6.6.6</c>
2974
+ <c/>
2975
+ <c>CATEGORIES</c>
2976
+ <c>RFC 6350, Section 6.7.1</c>
2977
+ <c/>
2978
+ <c>NOTE</c>
2979
+ <c>RFC 6350, Section 6.7.2</c>
2980
+ <c/>
2981
+ <c>PRODID</c>
2982
+ <c>RFC 6350, Section 6.7.3</c>
2983
+ <c/>
2984
+ <c>REV</c>
2985
+ <c>RFC 6350, Section 6.7.4</c>
2986
+ <c/>
2987
+ <c>SOUND</c>
2988
+ <c>RFC 6350, Section 6.7.5</c>
2989
+ <c/>
2990
+ <c>UID</c>
2991
+ <c>RFC 6350, Section 6.7.6</c>
2992
+ <c/>
2993
+ <c>CLIENTPIDMAP</c>
2994
+ <c>RFC 6350, Section 6.7.7</c>
2995
+ <c/>
2996
+ <c>URL</c>
2997
+ <c>RFC 6350, Section 6.7.8</c>
2998
+ <c/>
2999
+ <c>VERSION</c>
3000
+ <c>RFC 6350, Section 6.7.9</c>
3001
+ <c/>
3002
+ <c>KEY</c>
3003
+ <c>RFC 6350, Section 6.8.1</c>
3004
+ <c/>
3005
+ <c>FBURL</c>
3006
+ <c>RFC 6350, Section 6.9.1</c>
3007
+ <c/>
3008
+ <c>CALADRURI</c>
3009
+ <c>RFC 6350, Section 6.9.2</c>
3010
+ <c/>
3011
+ <c>CALURI</c>
3012
+ <c>RFC 6350, Section 6.9.3</c>
3013
+ </texttable></section>
3014
+ <section anchor="section10_3_2" title="Parameters Registry"><t>The following table has been used to initialize the parameters
3015
+ registry.</t>
3016
+ <texttable suppress-title="false" style="full">
3017
+ <ttcol align="left">Namespace</ttcol>
3018
+ <ttcol align="left">Parameter</ttcol>
3019
+ <ttcol align="left">Reference</ttcol>
3020
+ <c/>
3021
+ <c>LANGUAGE</c>
3022
+ <c>RFC 6350, Section 5.1</c>
3023
+ <c/>
3024
+ <c>VALUE</c>
3025
+ <c>RFC 6350, Section 5.2</c>
3026
+ <c/>
3027
+ <c>PREF</c>
3028
+ <c>RFC 6350, Section 5.3</c>
3029
+ <c/>
3030
+ <c>ALTID</c>
3031
+ <c>RFC 6350, Section 5.4</c>
3032
+ <c/>
3033
+ <c>PID</c>
3034
+ <c>RFC 6350, Section 5.5</c>
3035
+ <c/>
3036
+ <c>TYPE</c>
3037
+ <c>RFC 6350, Section 5.6</c>
3038
+ <c/>
3039
+ <c>MEDIATYPE</c>
3040
+ <c>RFC 6350, Section 5.7</c>
3041
+ <c/>
3042
+ <c>CALSCALE</c>
3043
+ <c>RFC 6350, Section 5.8</c>
3044
+ <c/>
3045
+ <c>SORT-AS</c>
3046
+ <c>RFC 6350, Section 5.9</c>
3047
+ <c/>
3048
+ <c>GEO</c>
3049
+ <c>RFC 6350, Section 5.10</c>
3050
+ <c/>
3051
+ <c>TZ</c>
3052
+ <c>RFC 6350, Section 5.11</c>
3053
+ </texttable></section>
3054
+ <section anchor="section10_3_3" title="Value Data Types Registry"><t>The following table has been used to initialize the parameters
3055
+ registry.</t>
3056
+ <texttable suppress-title="false" style="full">
3057
+ <ttcol align="left">Value Data Type</ttcol>
3058
+ <ttcol align="left">Reference</ttcol>
3059
+ <c>BOOLEAN</c>
3060
+ <c>RFC 6350, Section 4.4</c>
3061
+ <c>DATE</c>
3062
+ <c>RFC 6350, Section 4.3.1</c>
3063
+ <c>DATE-AND-OR-TIME</c>
3064
+ <c>RFC 6350, Section 4.3.4</c>
3065
+ <c>DATE-TIME</c>
3066
+ <c>RFC 6350, Section 4.3.3</c>
3067
+ <c>FLOAT</c>
3068
+ <c>RFC 6350, Section 4.6</c>
3069
+ <c>INTEGER</c>
3070
+ <c>RFC 6350, Section 4.5</c>
3071
+ <c>LANGUAGE-TAG</c>
3072
+ <c>RFC 6350, Section 4.8</c>
3073
+ <c>TEXT</c>
3074
+ <c>RFC 6350, Section 4.1</c>
3075
+ <c>TIME</c>
3076
+ <c>RFC 6350, Section 4.3.2</c>
3077
+ <c>TIMESTAMP</c>
3078
+ <c>RFC 6350, Section 4.3.5</c>
3079
+ <c>URI</c>
3080
+ <c>RFC 6350, Section 4.2</c>
3081
+ <c>UTC-OFFSET</c>
3082
+ <c>RFC 6350, Section 4.7</c>
3083
+ </texttable></section>
3084
+ <section anchor="section10_3_4" title="Values Registries"><t>Separate tables are used for property and parameter values.</t>
3085
+ <t>The following table is to be used to initialize the property values
3086
+ registry.</t>
3087
+ <texttable suppress-title="false" style="full">
3088
+ <ttcol align="left">Property</ttcol>
3089
+ <ttcol align="left">Value</ttcol>
3090
+ <ttcol align="left">Reference</ttcol>
3091
+ <c>BEGIN</c>
3092
+ <c>VCARD</c>
3093
+ <c>RFC 6350, Section 6.1.1</c>
3094
+ <c>END</c>
3095
+ <c>VCARD</c>
3096
+ <c>RFC 6350, Section 6.1.2</c>
3097
+ <c>KIND</c>
3098
+ <c>individual</c>
3099
+ <c>RFC 6350, Section 6.1.4</c>
3100
+ <c>KIND</c>
3101
+ <c>group</c>
3102
+ <c>RFC 6350, Section 6.1.4</c>
3103
+ <c>KIND</c>
3104
+ <c>org</c>
3105
+ <c>RFC 6350, Section 6.1.4</c>
3106
+ <c>KIND</c>
3107
+ <c>location</c>
3108
+ <c>RFC 6350, Section 6.1.4</c>
3109
+ </texttable>
3110
+ <t>The following table has been used to initialize the parameter values
3111
+ registry.</t>
3112
+ <texttable suppress-title="false" style="full">
3113
+ <ttcol align="left">Property</ttcol>
3114
+ <ttcol align="left">Parameter</ttcol>
3115
+ <ttcol align="left">Value</ttcol>
3116
+ <ttcol align="left">Reference</ttcol>
3117
+ <c>FN, NICKNAME, PHOTO,
3118
+ ADR, TEL, EMAIL, IMPP,
3119
+ LANG, TZ, GEO, TITLE,
3120
+ ROLE, LOGO, ORG,
3121
+ RELATED, CATEGORIES,
3122
+ NOTE, SOUND, URL, KEY,
3123
+ FBURL, CALADRURI, and
3124
+ CALURI</c>
3125
+ <c>TYPE</c>
3126
+ <c>work</c>
3127
+ <c>RFC 6350, Section 5.6</c>
3128
+ <c>FN, NICKNAME, PHOTO,
3129
+ ADR, TEL, EMAIL, IMPP,
3130
+ LANG, TZ, GEO, TITLE,
3131
+ ROLE, LOGO, ORG,
3132
+ RELATED, CATEGORIES,
3133
+ NOTE, SOUND, URL, KEY,
3134
+ FBURL, CALADRURI, and
3135
+ CALURI</c>
3136
+ <c>TYPE</c>
3137
+ <c>home</c>
3138
+ <c>RFC 6350, Section 5.6</c>
3139
+ <c>TEL</c>
3140
+ <c>TYPE</c>
3141
+ <c>text</c>
3142
+ <c>RFC 6350, Section 6.4.1</c>
3143
+ <c>TEL</c>
3144
+ <c>TYPE</c>
3145
+ <c>voice</c>
3146
+ <c>RFC 6350, Section 6.4.1</c>
3147
+ <c>TEL</c>
3148
+ <c>TYPE</c>
3149
+ <c>fax</c>
3150
+ <c>RFC 6350, Section 6.4.1</c>
3151
+ <c>TEL</c>
3152
+ <c>TYPE</c>
3153
+ <c>cell</c>
3154
+ <c>RFC 6350, Section 6.4.1</c>
3155
+ <c>TEL</c>
3156
+ <c>TYPE</c>
3157
+ <c>video</c>
3158
+ <c>RFC 6350, Section 6.4.1</c>
3159
+ <c>TEL</c>
3160
+ <c>TYPE</c>
3161
+ <c>pager</c>
3162
+ <c>RFC 6350, Section 6.4.1</c>
3163
+ <c>TEL</c>
3164
+ <c>TYPE</c>
3165
+ <c>textphone</c>
3166
+ <c>RFC 6350, Section 6.4.1</c>
3167
+ <c>BDAY, ANNIVERSARY</c>
3168
+ <c>CALSCALE</c>
3169
+ <c>gregorian</c>
3170
+ <c>RFC 6350, Section 5.8</c>
3171
+ <c>RELATED</c>
3172
+ <c>TYPE</c>
3173
+ <c>contact</c>
3174
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3175
+ <c>RELATED</c>
3176
+ <c>TYPE</c>
3177
+ <c>acquaintance</c>
3178
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3179
+ <c>RELATED</c>
3180
+ <c>TYPE</c>
3181
+ <c>friend</c>
3182
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3183
+ <c>RELATED</c>
3184
+ <c>TYPE</c>
3185
+ <c>met</c>
3186
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3187
+ <c>RELATED</c>
3188
+ <c>TYPE</c>
3189
+ <c>co-worker</c>
3190
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3191
+ <c>RELATED</c>
3192
+ <c>TYPE</c>
3193
+ <c>colleague</c>
3194
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3195
+ <c>RELATED</c>
3196
+ <c>TYPE</c>
3197
+ <c>co-resident</c>
3198
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3199
+ <c>RELATED</c>
3200
+ <c>TYPE</c>
3201
+ <c>neighbor</c>
3202
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3203
+ <c>RELATED</c>
3204
+ <c>TYPE</c>
3205
+ <c>child</c>
3206
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3207
+ <c>RELATED</c>
3208
+ <c>TYPE</c>
3209
+ <c>parent</c>
3210
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3211
+ <c>RELATED</c>
3212
+ <c>TYPE</c>
3213
+ <c>sibling</c>
3214
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3215
+ <c>RELATED</c>
3216
+ <c>TYPE</c>
3217
+ <c>spouse</c>
3218
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3219
+ <c>RELATED</c>
3220
+ <c>TYPE</c>
3221
+ <c>kin</c>
3222
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3223
+ <c>RELATED</c>
3224
+ <c>TYPE</c>
3225
+ <c>muse</c>
3226
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3227
+ <c>RELATED</c>
3228
+ <c>TYPE</c>
3229
+ <c>crush</c>
3230
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3231
+ <c>RELATED</c>
3232
+ <c>TYPE</c>
3233
+ <c>date</c>
3234
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3235
+ <c>RELATED</c>
3236
+ <c>TYPE</c>
3237
+ <c>sweetheart</c>
3238
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3239
+ <c>RELATED</c>
3240
+ <c>TYPE</c>
3241
+ <c>me</c>
3242
+ <c>RFC 6350, Section 6.6.6 and cite:norm[xfn]</c>
3243
+ <c>RELATED</c>
3244
+ <c>TYPE</c>
3245
+ <c>agent</c>
3246
+ <c>RFC 6350, Section 6.6.6</c>
3247
+ <c>RELATED</c>
3248
+ <c>TYPE</c>
3249
+ <c>emergency</c>
3250
+ <c>RFC 6350, Section 6.6.6</c>
3251
+ </texttable></section></section></section>
3252
+ <section anchor="section11" title="Acknowledgments"><t>The authors would like to thank Tim Howes, Mark Smith, and Frank
3253
+ Dawson, the original authors of cite:info[RFC2425] and cite:info[RFC2426], Pete
3254
+ Resnick, who got this effort started and provided help along the way,
3255
+ as well as the following individuals who have participated in the
3256
+ drafting, review, and discussion of this memo:</t>
3257
+ <t>Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil
3258
+ Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie
3259
+ Hoeneisen, Bjoern Hoehrmann, Caleb Richardson, Chris Bryant, Chris
3260
+ Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale,
3261
+ Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian
3262
+ Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens,
3263
+ Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke,
3264
+ Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga, Lisa Dusseault,
3265
+ Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike
3266
+ Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter
3267
+ Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane
3268
+ Bortzmeyer, Tantek Celik, and Zoltan Ordogh.</t></section>
3269
+ </middle><back>
3270
+ <references title="Normative References"/>
3271
+ <references title="Informative References"/>
3272
+ <section anchor="appendixA" title="Differences from RFCs 2425 and 2426"><t>This appendix contains a high-level overview of the major changes
3273
+ that have been made in the vCard specification from RFCs 2425 and
3274
+ 2426. It is incomplete, as it only lists the most important changes.</t>
3275
+ <section anchor="appendixA_1" title="New Structure">
3276
+ <t>
3277
+ <list style="symbols">
3278
+ <t>cite:info[RFC2425] and cite:info[RFC2426] have been merged.</t>
3279
+ <t>vCard is now not only a MIME type but a stand-alone format.</t>
3280
+ <t>A proper MIME type registration form has been included.</t>
3281
+ <t>UTF-8 is now the only possible character set.</t>
3282
+ <t>New vCard elements can be registered from IANA.</t>
3283
+ </list>
3284
+ </t>
3285
+ </section>
3286
+ <section anchor="appendixA_2" title="Removed Features">
3287
+ <t>
3288
+ <list style="symbols">
3289
+ <t>The CONTEXT and CHARSET parameters are no more.</t>
3290
+ <t>The NAME, MAILER, LABEL, and CLASS properties are no more.</t>
3291
+ <t>The "intl", "dom", "postal", and "parcel" TYPE parameter values
3292
+ for the ADR property have been removed.</t>
3293
+ <t>In-line vCards (such as the value of the AGENT property) are no
3294
+ longer supported.</t>
3295
+ </list>
3296
+ </t>
3297
+ </section>
3298
+ <section anchor="appendixA_3" title="New Properties and Parameters">
3299
+ <t>
3300
+ <list style="symbols">
3301
+ <t>The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP
3302
+ properties have been added.</t>
3303
+ <t>cite:norm[RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI
3304
+ properties, has been merged in.</t>
3305
+ <t>cite:info[RFC4770], which defines the IMPP property, has been merged in.</t>
3306
+ <t>The "work" and "home" TYPE parameter values are now applicable to
3307
+ many more properties.</t>
3308
+ <t>The "pref" value of the TYPE parameter is now a parameter of its
3309
+ own, with a positive integer value indicating the level of
3310
+ preference.</t>
3311
+ <t>The ALTID and PID parameters have been added.</t>
3312
+ <t>The MEDIATYPE parameter has been added and replaces the TYPE
3313
+ parameter when it was used for indicating the media type of the
3314
+ property&#8217;s content.</t>
3315
+ </list>
3316
+ </t>
3317
+ </section></section>
3318
+ </back>
3319
+ </rfc>