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