7 Internet Engineering Task Force (IETF) S. Perreault
8 Request for Comments: 6350 Viagenie
9 Obsoletes: 2425, 2426, 4770 August 2011
11 Category: Standards Track
15 vCard Format Specification
19 This document defines the vCard data format for representing and
20 exchanging a variety of information about individuals and other
21 entities (e.g., formatted and structured name and delivery addresses,
22 email address, multiple telephone numbers, photograph, logo, audio
23 clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc6350.
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
58 Perreault Standards Track [Page 1]
60 RFC 6350 vCard August 2011
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
78 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
79 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 5
80 3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 5
81 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 5
82 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 6
83 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9
84 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 9
85 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
86 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
87 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 12
88 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 12
89 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13
90 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 13
91 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14
92 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 14
93 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14
94 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15
95 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 15
96 4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 15
97 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16
98 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16
99 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16
100 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
101 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
102 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18
103 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
104 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
105 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 20
106 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 20
107 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21
108 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
109 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
114 Perreault Standards Track [Page 2]
116 RFC 6350 vCard August 2011
119 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23
120 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23
121 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23
122 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 23
123 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24
124 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25
125 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 27
126 6.2. Identification Properties . . . . . . . . . . . . . . . . 28
127 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 28
128 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 29
129 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 29
130 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 30
131 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 30
132 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 31
133 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 32
134 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 32
135 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 32
136 6.4. Communications Properties . . . . . . . . . . . . . . . . 34
137 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34
138 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 36
139 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 36
140 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 37
141 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 37
142 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 37
143 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 38
144 6.6. Organizational Properties . . . . . . . . . . . . . . . . 39
145 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 39
146 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 39
147 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 40
148 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40
149 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 41
150 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 42
151 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 43
152 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 43
153 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 44
154 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 44
155 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 45
156 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 45
157 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 46
158 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47
159 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 47
160 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 48
161 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 48
162 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 48
163 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 49
164 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 49
165 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 50
166 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 50
170 Perreault Standards Track [Page 3]
172 RFC 6350 vCard August 2011
175 6.10. Extended Properties and Parameters . . . . . . . . . . . . 51
176 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 51
177 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 51
178 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 51
179 7.1.2. Matching Property Instances . . . . . . . . . . . . . 52
180 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 52
181 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 53
182 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 53
183 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 53
184 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 54
185 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 54
186 7.2.5. Global Context Simplification . . . . . . . . . . . . 56
187 8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 56
188 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
189 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
190 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 58
191 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 59
192 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 59
193 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 60
194 10.2.3. Registration Template for Properties . . . . . . . . . 61
195 10.2.4. Registration Template for Parameters . . . . . . . . . 61
196 10.2.5. Registration Template for Value Data Types . . . . . . 62
197 10.2.6. Registration Template for Values . . . . . . . . . . . 62
198 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 63
199 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64
200 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 65
201 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 65
202 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66
203 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
204 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
205 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
206 12.2. Informative References . . . . . . . . . . . . . . . . . . 71
207 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 73
208 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73
209 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 73
210 A.3. New Properties and Parameters . . . . . . . . . . . . . . 73
226 Perreault Standards Track [Page 4]
228 RFC 6350 vCard August 2011
233 Electronic address books have become ubiquitous. Their increased
234 presence on portable, connected devices as well as the diversity of
235 platforms that exchange contact data call for a standard. This memo
236 defines the vCard format, which allows the capture and exchange of
237 information normally stored within an address book or directory
240 A high-level overview of the differences from RFCs 2425 and 2426 can
241 be found in Appendix A.
245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
247 "OPTIONAL" in this document are to be interpreted as described in
250 3. vCard Format Specification
252 The text/vcard MIME content type (hereafter known as "vCard"; see
253 Section 10.1) contains contact information, typically pertaining to a
254 single contact or group of contacts. The content consists of one or
255 more lines in the format given below.
259 The charset (see [RFC3536] for internationalization terminology) for
260 vCard is UTF-8 as defined in [RFC3629]. There is no way to override
261 this. It is invalid to specify a value other than "UTF-8" in the
262 "charset" MIME parameter (see Section 10.1).
264 3.2. Line Delimiting and Folding
266 Individual lines within vCard are delimited by the [RFC5322] line
267 break, which is a CRLF sequence (U+000D followed by U+000A). Long
268 logical lines of text can be split into a multiple-physical-line
269 representation using the following folding technique. Content lines
270 SHOULD be folded to a maximum width of 75 octets, excluding the line
271 break. Multi-octet characters MUST remain contiguous. The rationale
272 for this folding process can be found in [RFC5322], Section 2.1.1.
274 A logical line MAY be continued on the next physical line anywhere
275 between two characters by inserting a CRLF immediately followed by a
276 single white space character (space (U+0020) or horizontal tab
277 (U+0009)). The folded line MUST contain at least one character. Any
278 sequence of CRLF followed immediately by a single white space
282 Perreault Standards Track [Page 5]
284 RFC 6350 vCard August 2011
287 character is ignored (removed) when processing the content type. For
290 NOTE:This is a long description that exists on a long line.
292 can be represented as:
294 NOTE:This is a long description
295 that exists on a long line.
297 It could also be represented as:
299 NOTE:This is a long descrip
303 The process of moving from this folded multiple-line representation
304 of a property definition to its single-line representation is called
305 unfolding. Unfolding is accomplished by regarding CRLF immediately
306 followed by a white space character (namely, HTAB (U+0009) or SPACE
307 (U+0020)) as equivalent to no characters at all (i.e., the CRLF and
308 single white space character are removed).
310 Note: It is possible for very simple implementations to generate
311 improperly folded lines in the middle of a UTF-8 multi-octet
312 sequence. For this reason, implementations SHOULD unfold lines in
313 such a way as to properly restore the original sequence.
315 Note: Unfolding is done differently than in [RFC5322]. Unfolding
316 in [RFC5322] only removes the CRLF, not the space following it.
318 Folding is done after any content encoding of a type value.
319 Unfolding is done before any decoding of a type value in a content
322 3.3. ABNF Format Definition
324 The following ABNF uses the notation of [RFC5234], which also defines
325 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.
327 vcard-entity = 1*vcard
329 vcard = "BEGIN:VCARD" CRLF
333 ; A vCard object MUST include the VERSION and FN properties.
334 ; VERSION MUST come immediately after BEGIN:VCARD.
338 Perreault Standards Track [Page 6]
340 RFC 6350 vCard August 2011
343 contentline = [group "."] name *(";" param) ":" value CRLF
344 ; When parsing a content line, folded lines must first
345 ; be unfolded according to the unfolding procedure
346 ; described in Section 3.2.
347 ; When generating a content line, lines longer than 75
348 ; characters SHOULD be folded according to the folding
349 ; procedure described in Section 3.2.
351 group = 1*(ALPHA / DIGIT / "-")
352 name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME"
353 / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL"
354 / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE"
355 / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES"
356 / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP"
357 / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML"
358 / iana-token / x-name
359 ; Parsing of the param and value is based on the "name" as
360 ; defined in ABNF sections below.
361 ; Group and name are case-insensitive.
363 iana-token = 1*(ALPHA / DIGIT / "-")
364 ; identifier registered with IANA
366 x-name = "x-" 1*(ALPHA / DIGIT / "-")
367 ; Names that begin with "x-" or "X-" are
368 ; reserved for experimental use, not intended for released
369 ; products, or for use in bilateral agreements.
371 param = language-param / value-param / pref-param / pid-param
372 / type-param / geo-parameter / tz-parameter / sort-as-param
373 / calscale-param / any-param
374 ; Allowed parameters depend on property name.
376 param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE
378 any-param = (iana-token / x-name) "=" param-value *("," param-value)
380 NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4
381 ; UTF8-{2,3,4} are defined in [RFC3629]
383 QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
384 ; Any character except CTLs, DQUOTE
386 SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
387 ; Any character except CTLs, DQUOTE, ";", ":"
389 VALUE-CHAR = WSP / VCHAR / NON-ASCII
390 ; Any textual character
394 Perreault Standards Track [Page 7]
396 RFC 6350 vCard August 2011
399 A line that begins with a white space character is a continuation of
400 the previous line, as described in Section 3.2. The white space
401 character and immediately preceeding CRLF should be discarded when
402 reconstructing the original line. Note that this line-folding
403 convention differs from that found in [RFC5322], in that the sequence
404 <CRLF><WSP> found anywhere in the content indicates a continued line
405 and should be removed.
407 Property names and parameter names are case-insensitive (e.g., the
408 property name "fn" is the same as "FN" and "Fn"). Parameter values
409 MAY be case-sensitive or case-insensitive, depending on their
410 definition. Parameter values that are not explicitly defined as
411 being case-sensitive are case-insensitive. Based on experience with
412 vCard 3 interoperability, it is RECOMMENDED that property and
413 parameter names be upper-case on output.
415 The group construct is used to group related properties together.
416 The group name is a syntactic convention used to indicate that all
417 property names prefaced with the same group name SHOULD be grouped
418 together when displayed by an application. It has no other
419 significance. Implementations that do not understand or support
420 grouping MAY simply strip off any text before a "." to the left of
421 the type name and present the types and values as normal.
423 Property cardinalities are indicated using the following notation,
424 which is based on ABNF (see [RFC5234], Section 3.6):
426 +-------------+--------------------------------------------------+
427 | Cardinality | Meaning |
428 +-------------+--------------------------------------------------+
429 | 1 | Exactly one instance per vCard MUST be present. |
430 | *1 | Exactly one instance per vCard MAY be present. |
431 | 1* | One or more instances per vCard MUST be present. |
432 | * | One or more instances per vCard MAY be present. |
433 +-------------+--------------------------------------------------+
435 Properties defined in a vCard instance may have multiple values
436 depending on the property cardinality. The general rule for encoding
437 multi-valued properties is to simply create a new content line for
438 each value (including the property name). However, it should be
439 noted that some value types support encoding multiple values in a
440 single content line by separating the values with a comma ",". This
441 approach has been taken for several of the content types defined
442 below (date, time, integer, float).
450 Perreault Standards Track [Page 8]
452 RFC 6350 vCard August 2011
455 3.4. Property Value Escaping
457 Some properties may contain one or more values delimited by a COMMA
458 character (U+002C). Therefore, a COMMA character in a value MUST be
459 escaped with a BACKSLASH character (U+005C), even for properties that
460 don't allow multiple instances (for consistency).
462 Some properties (e.g., N and ADR) comprise multiple fields delimited
463 by a SEMICOLON character (U+003B). Therefore, a SEMICOLON in a field
464 of such a "compound" property MUST be escaped with a BACKSLASH
465 character. SEMICOLON characters in non-compound properties MAY be
466 escaped. On input, an escaped SEMICOLON character is never a field
467 separator. An unescaped SEMICOLON character may be a field
468 separator, depending on the property in which it appears.
470 Furthermore, some fields of compound properties may contain a list of
471 values delimited by a COMMA character. Therefore, a COMMA character
472 in one of a field's values MUST be escaped with a BACKSLASH
473 character, even for fields that don't allow multiple values (for
474 consistency). Compound properties allowing multiple instances MUST
475 NOT be encoded in a single content line.
477 Finally, BACKSLASH characters in values MUST be escaped with a
478 BACKSLASH character. NEWLINE (U+000A) characters in values MUST be
479 encoded by two characters: a BACKSLASH followed by either an 'n'
480 (U+006E) or an 'N' (U+004E).
482 In all other cases, escaping MUST NOT be used.
484 4. Property Value Data Types
486 Standard value types are defined below.
493 / date-and-or-time-list
498 / URI ; from Section 3 of [RFC3986]
502 ; Actual value type depends on property name and VALUE parameter.
506 Perreault Standards Track [Page 9]
508 RFC 6350 vCard August 2011
513 TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
514 / %x21-2B / %x2D-5B / %x5D-7E
515 ; Backslashes, commas, and newlines must be encoded.
517 component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
518 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
519 list-component = component *("," component)
521 text-list = text *("," text)
522 date-list = date *("," date)
523 time-list = time *("," time)
524 date-time-list = date-time *("," date-time)
525 date-and-or-time-list = date-and-or-time *("," date-and-or-time)
526 timestamp-list = timestamp *("," timestamp)
527 integer-list = integer *("," integer)
528 float-list = float *("," float)
530 boolean = "TRUE" / "FALSE"
531 integer = [sign] 1*DIGIT
532 float = [sign] 1*DIGIT ["." 1*DIGIT]
536 year = 4DIGIT ; 0000-9999
537 month = 2DIGIT ; 01-12
538 day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year
539 hour = 2DIGIT ; 00-23
540 minute = 2DIGIT ; 00-59
541 second = 2DIGIT ; 00-58/59/60 depending on leap second
542 zone = utc-designator / utc-offset
543 utc-designator = %x5A ; uppercase "Z"
545 date = year [month day]
549 date-noreduc = year month day
552 date-complete = year month day
554 time = hour [minute [second]] [zone]
555 / "-" minute [second] [zone]
556 / "-" "-" second [zone]
557 time-notrunc = hour [minute [second]] [zone]
558 time-complete = hour minute second [zone]
562 Perreault Standards Track [Page 10]
564 RFC 6350 vCard August 2011
567 time-designator = %x54 ; uppercase "T"
568 date-time = date-noreduc time-designator time-notrunc
569 timestamp = date-complete time-designator time-complete
571 date-and-or-time = date-time / date / time-designator time
573 utc-offset = sign hour [minute]
575 Language-Tag = <Language-Tag, defined in [RFC5646], Section 2.1>
577 iana-valuespec = <value-spec, see Section 12>
578 ; a publicly defined valuetype format, registered
579 ; with IANA, as defined in Section 12 of this
584 "text": The "text" value type should be used to identify values that
585 contain human-readable text. As for the language, it is controlled
586 by the LANGUAGE property parameter defined in Section 5.1.
591 this is one value,this is another
592 this is a single value\, with a comma encoded
594 A formatted text line break in a text value type MUST be represented
595 as the character sequence backslash (U+005C) followed by a Latin
596 small letter n (U+006E) or a Latin capital letter N (U+004E), that
599 For example, a multiple line NOTE value of:
602 Hyjinx Software Division
605 could be represented as:
607 NOTE:Mythical Manager\nHyjinx Software Division\n
610 demonstrating the \n literal formatted line break technique, the
611 CRLF-followed-by-space line folding technique, and the backslash
618 Perreault Standards Track [Page 11]
620 RFC 6350 vCard August 2011
625 "uri": The "uri" value type should be used to identify values that
626 are referenced by a Uniform Resource Identifier (URI) instead of
627 encoded in-line. These value references might be used if the value
628 is too large, or otherwise undesirable to include directly. The
629 format for the URI is as defined in Section 3 of [RFC3986]. Note
630 that the value of a property of type "uri" is what the URI points to,
635 http://www.example.com/my/picture.jpg
636 ldap://ldap.example.com/cn=babs%20jensen
638 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP
640 "date", "time", "date-time", "date-and-or-time", and "timestamp":
641 Each of these value types is based on the definitions in
642 [ISO.8601.2004]. Multiple such values can be specified using the
643 comma-separated notation.
645 Only the basic format is supported.
649 A calendar date as specified in [ISO.8601.2004], Section 4.1.2.
651 Reduced accuracy, as specified in [ISO.8601.2004], Sections 4.1.2.3
652 a) and b), but not c), is permitted.
654 Expanded representation, as specified in [ISO.8601.2004], Section
657 Truncated representation, as specified in [ISO.8601.2000], Sections
658 5.2.1.3 d), e), and f), is permitted.
674 Perreault Standards Track [Page 12]
676 RFC 6350 vCard August 2011
679 Note the use of YYYY-MM in the second example above. YYYYMM is
680 disallowed to prevent confusion with YYMMDD. Note also that
681 YYYY-MM-DD is disallowed since we are using the basic format instead
682 of the extended format.
686 A time of day as specified in [ISO.8601.2004], Section 4.2.
688 Reduced accuracy, as specified in [ISO.8601.2004], Section 4.2.2.3,
691 Representation with decimal fraction, as specified in
692 [ISO.8601.2004], Section 4.2.2.4, is forbidden.
694 The midnight hour is always represented by 00, never 24 (see
695 [ISO.8601.2004], Section 4.2.3).
697 Truncated representation, as specified in [ISO.8601.2000], Sections
698 5.3.1.4 a), b), and c), is permitted.
712 A date and time of day combination as specified in [ISO.8601.2004],
715 Truncation of the date part, as specified in [ISO.8601.2000], Section
716 5.4.2 c), is permitted.
718 Examples for "date-time":
730 Perreault Standards Track [Page 13]
732 RFC 6350 vCard August 2011
735 4.3.4. DATE-AND-OR-TIME
737 Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous
738 interpretation, a stand-alone TIME value is always preceded by a "T".
740 Examples for "date-and-or-time":
760 A complete date and time of day combination as specified in
761 [ISO.8601.2004], Section 4.3.2.
763 Examples for "timestamp":
772 "boolean": The "boolean" value type is used to express boolean
773 values. These values are case-insensitive.
786 Perreault Standards Track [Page 14]
788 RFC 6350 vCard August 2011
793 "integer": The "integer" value type is used to express signed
794 integers in decimal format. If sign is not specified, the value is
795 assumed positive "+". Multiple "integer" values can be specified
796 using the comma-separated notation. The maximum value is
797 9223372036854775807, and the minimum value is -9223372036854775808.
798 These limits correspond to a signed 64-bit integer using two's-
799 complement arithmetic.
805 +1234556790,432109876
809 "float": The "float" value type is used to express real numbers. If
810 sign is not specified, the value is assumed positive "+". Multiple
811 "float" values can be specified using the comma-separated notation.
812 Implementations MUST support a precision equal or better than that of
813 the IEEE "binary64" format [IEEE.754.2008].
815 Note: Scientific notation is disallowed. Implementers wishing to
816 use their favorite language's %f formatting should be careful.
826 "utc-offset": The "utc-offset" value type specifies that the property
827 value is a signed offset from UTC. This value type can be specified
830 The value type is an offset from Coordinated Universal Time (UTC).
831 It is specified as a positive or negative difference in units of
832 hours and minutes (e.g., +hhmm). The time is specified as a 24-hour
833 clock. Hour values are from 00 to 23, and minute values are from 00
834 to 59. Hour and minutes are 2 digits with high-order zeroes required
835 to maintain digit count. The basic format for ISO 8601 UTC offsets
842 Perreault Standards Track [Page 15]
844 RFC 6350 vCard August 2011
849 "language-tag": A single language tag, as defined in [RFC5646].
851 5. Property Parameters
853 A property can have attributes associated with it. These "property
854 parameters" contain meta-information about the property or the
855 property value. In some cases, the property parameter can be multi-
856 valued in which case the property parameter value elements are
857 separated by a COMMA (U+002C).
859 Property parameter value elements that contain the COLON (U+003A),
860 SEMICOLON (U+003B), or COMMA (U+002C) character separators MUST be
861 specified as quoted-string text values. Property parameter values
862 MUST NOT contain the DQUOTE (U+0022) character. The DQUOTE character
863 is used as a delimiter for parameter values that contain restricted
864 characters or URI text.
866 Applications MUST ignore x-param and iana-param values they don't
871 The LANGUAGE property parameter is used to identify data in multiple
872 languages. There is no concept of "default" language, except as
873 specified by any "Content-Language" MIME header parameter that is
874 present [RFC3282]. The value of the LANGUAGE property parameter is a
875 language tag as defined in Section 2 of [RFC5646].
879 ROLE;LANGUAGE=tr:hoca
883 language-param = "LANGUAGE=" Language-Tag
884 ; Language-Tag is defined in section 2.1 of RFC 5646
888 The VALUE parameter is OPTIONAL, used to identify the value type
889 (data type) and format of the value. The use of these predefined
890 formats is encouraged even if the value parameter is not explicitly
891 used. By defining a standard set of value types and their formats,
892 existing parsing and processing code can be leveraged. The
898 Perreault Standards Track [Page 16]
900 RFC 6350 vCard August 2011
903 predefined data type values MUST NOT be repeated in COMMA-separated
904 value lists except within the N, NICKNAME, ADR, and CATEGORIES
909 value-param = "VALUE=" value-type
923 / iana-token ; registered as described in section 12
928 The PREF parameter is OPTIONAL and is used to indicate that the
929 corresponding instance of a property is preferred by the vCard
930 author. Its value MUST be an integer between 1 and 100 that
931 quantifies the level of preference. Lower values correspond to a
932 higher level of preference, with 1 being most preferred.
934 When the parameter is absent, the default MUST be to interpret the
935 property instance as being least preferred.
937 Note that the value of this parameter is to be interpreted only in
938 relation to values assigned to other instances of the same property
939 in the same vCard. A given value, or the absence of a value, MUST
940 NOT be interpreted on its own.
942 This parameter MAY be applied to any property that allows multiple
947 pref-param = "PREF=" (1*2DIGIT / "100")
948 ; An integer between 1 and 100.
954 Perreault Standards Track [Page 17]
956 RFC 6350 vCard August 2011
961 The ALTID parameter is used to "tag" property instances as being
962 alternative representations of the same logical property. For
963 example, translations of a property in multiple languages generates
964 multiple property instances having different LANGUAGE (Section 5.1)
965 parameter that are tagged with the same ALTID value.
967 This parameter's value is treated as an opaque string. Its sole
968 purpose is to be compared for equality against other ALTID parameter
971 Two property instances are considered alternative representations of
972 the same logical property if and only if their names as well as the
973 value of their ALTID parameters are identical. Property instances
974 without the ALTID parameter MUST NOT be considered an alternative
975 representation of any other property instance. Values for the ALTID
976 parameter are not globally unique: they MAY be reused for different
979 Property instances having the same ALTID parameter value count as 1
980 toward cardinality. Therefore, since N (Section 6.2.2) has
981 cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these
982 three examples would be legal:
984 N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
985 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
986 (<U+XXXX> denotes a UTF8-encoded Unicode character.)
988 TITLE;ALTID=1;LANGUAGE=fr:Patron
989 TITLE;ALTID=1;LANGUAGE=en:Boss
991 TITLE;ALTID=1;LANGUAGE=fr:Patron
992 TITLE;ALTID=1;LANGUAGE=en:Boss
993 TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist
995 while this one would not:
997 N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
999 (Two instances of the N property.)
1001 and these three would be legal but questionable:
1003 TITLE;ALTID=1;LANGUAGE=fr:Patron
1004 TITLE;ALTID=2;LANGUAGE=en:Boss
1005 (Should probably have the same ALTID value.)
1010 Perreault Standards Track [Page 18]
1012 RFC 6350 vCard August 2011
1015 TITLE;ALTID=1;LANGUAGE=fr:Patron
1016 TITLE:LANGUAGE=en:Boss
1017 (Second line should probably have ALTID=1.)
1019 N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
1020 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
1021 N;ALTID=1;LANGUAGE=en:Smith;John;;;
1022 (The last line should probably have ALTID=2. But that would be
1023 illegal because N has cardinality *1.)
1025 The ALTID property MAY also be used in may contexts other than with
1026 the LANGUAGE parameter. Here's an example with two representations
1027 of the same photo in different file formats:
1029 PHOTO;ALTID=1:data:image/jpeg;base64,...
1030 PHOTO;ALTID=1;data:image/jp2;base64,...
1034 altid-param = "ALTID=" param-value
1038 The PID parameter is used to identify a specific property among
1039 multiple instances. It plays a role analogous to the UID property
1040 (Section 6.7.6) on a per-property instead of per-vCard basis. It MAY
1041 appear more than once in a given property. It MUST NOT appear on
1042 properties that may have only one instance per vCard. Its value is
1043 either a single small positive integer or a pair of small positive
1044 integers separated by a dot. Multiple values may be encoded in a
1045 single PID parameter by separating the values with a comma ",". See
1046 Section 7 for more details on its usage.
1050 pid-param = "PID=" pid-value *("," pid-value)
1051 pid-value = 1*DIGIT ["." 1*DIGIT]
1055 The TYPE parameter has multiple, different uses. In general, it is a
1056 way of specifying class characteristics of the associated property.
1057 Most of the time, its value is a comma-separated subset of a
1058 predefined enumeration. In this document, the following properties
1059 make use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL,
1060 IMPP, LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES,
1066 Perreault Standards Track [Page 19]
1068 RFC 6350 vCard August 2011
1071 NOTE, SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE
1072 parameter MUST NOT be applied on other properties defined in this
1075 The "work" and "home" values act like tags. The "work" value implies
1076 that the property is related to an individual's work place, while the
1077 "home" value implies that the property is related to an individual's
1078 personal life. When neither "work" nor "home" is present, it is
1079 implied that the property is related to both an individual's work
1080 place and personal life in the case that the KIND property's value is
1081 "individual", or to none in other cases.
1085 type-param = "TYPE=" type-value *("," type-value)
1087 type-value = "work" / "home" / type-param-tel
1088 / type-param-related / iana-token / x-name
1089 ; This is further defined in individual property sections.
1093 The MEDIATYPE parameter is used with properties whose value is a URI.
1094 Its use is OPTIONAL. It provides a hint to the vCard consumer
1095 application about the media type [RFC2046] of the resource identified
1096 by the URI. Some URI schemes do not need this parameter. For
1097 example, the "data" scheme allows the media type to be explicitly
1098 indicated as part of the URI [RFC2397]. Another scheme, "http",
1099 provides the media type as part of the URI resolution process, with
1100 the Content-Type HTTP header [RFC2616]. The MEDIATYPE parameter is
1101 intended to be used with URI schemes that do not provide such
1102 functionality (e.g., "ftp" [RFC1738]).
1106 mediatype-param = "MEDIATYPE=" mediatype
1107 mediatype = type-name "/" subtype-name *( ";" attribute "=" value )
1108 ; "attribute" and "value" are from [RFC2045]
1109 ; "type-name" and "subtype-name" are from [RFC4288]
1113 The CALSCALE parameter is identical to the CALSCALE property in
1114 iCalendar (see [RFC5545], Section 3.7.1). It is used to define the
1115 calendar system in which a date or date-time value is expressed. The
1116 only value specified by iCalendar is "gregorian", which stands for
1117 the Gregorian system. It is the default when the parameter is
1118 absent. Additional values may be defined in extension documents and
1122 Perreault Standards Track [Page 20]
1124 RFC 6350 vCard August 2011
1127 registered with IANA (see Section 10.3.4). A vCard implementation
1128 MUST ignore properties with a CALSCALE parameter value that it does
1133 calscale-param = "CALSCALE=" calscale-value
1135 calscale-value = "gregorian" / iana-token / x-name
1139 The "sort-as" parameter is used to specify the string to be used for
1140 national-language-specific sorting. Without this information,
1141 sorting algorithms could incorrectly sort this vCard within a
1142 sequence of sorted vCards. When this property is present in a vCard,
1143 then the given strings are used for sorting the vCard.
1145 This parameter's value is a comma-separated list that MUST have as
1146 many or fewer elements as the corresponding property value has
1147 components. This parameter's value is case-sensitive.
1151 sort-as-param = "SORT-AS=" sort-as-value
1153 sort-as-value = param-value *("," param-value)
1155 Examples: For the case of surname and given name sorting, the
1156 following examples define common sort string usage with the N
1159 FN:Rene van der Harten
1160 N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N.
1162 FN:Robert Pau Shou Chang
1163 N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;;
1166 N;SORT-AS="Koura,Osamu":Koura;Osamu;;
1169 N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;
1171 FN:Chistine d'Aboville
1172 N;SORT-AS="Aboville,Christine":d'Aboville;Christine;;
1178 Perreault Standards Track [Page 21]
1180 RFC 6350 vCard August 2011
1184 N;SORT-AS="Mann,James":de Mann;Henry,James;;
1186 If sorted by surname, the results would be:
1188 Christine d'Aboville
1192 Robert Pau Shou Chang
1195 If sorted by given name, the results would be:
1197 Christine d'Aboville
1202 Robert Pau Shou Chang
1206 The GEO parameter can be used to indicate global positioning
1207 information that is specific to an address. Its value is the same as
1208 that of the GEO property (see Section 6.5.2).
1212 geo-parameter = "GEO=" DQUOTE URI DQUOTE
1216 The TZ parameter can be used to indicate time zone information that
1217 is specific to an address. Its value is the same as that of the TZ
1222 tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE)
1234 Perreault Standards Track [Page 22]
1236 RFC 6350 vCard August 2011
1241 What follows is an enumeration of the standard vCard properties.
1243 6.1. General Properties
1247 Purpose: To denote the beginning of a syntactic entity within a
1248 text/vcard content-type.
1254 Special notes: The content entity MUST begin with the BEGIN property
1255 with a value of "VCARD". The value is case-insensitive.
1257 The BEGIN property is used in conjunction with the END property to
1258 delimit an entity containing a related set of properties within a
1259 text/vcard content-type. This construct can be used instead of
1260 including multiple vCards as body parts inside of a multipart/
1261 alternative MIME message. It is provided for applications that
1262 wish to define content that can contain multiple entities within
1263 the same text/vcard content-type or to define content that can be
1264 identifiable outside of a MIME environment.
1268 BEGIN-param = 0" " ; no parameter allowed
1269 BEGIN-value = "VCARD"
1277 Purpose: To denote the end of a syntactic entity within a text/vcard
1284 Special notes: The content entity MUST end with the END type with a
1285 value of "VCARD". The value is case-insensitive.
1290 Perreault Standards Track [Page 23]
1292 RFC 6350 vCard August 2011
1295 The END property is used in conjunction with the BEGIN property to
1296 delimit an entity containing a related set of properties within a
1297 text/vcard content-type. This construct can be used instead of or
1298 in addition to wrapping separate sets of information inside
1299 additional MIME headers. It is provided for applications that
1300 wish to define content that can contain multiple entities within
1301 the same text/vcard content-type or to define content that can be
1302 identifiable outside of a MIME environment.
1306 END-param = 0" " ; no parameter allowed
1315 Purpose: To identify the source of directory information contained
1316 in the content type.
1322 Special notes: The SOURCE property is used to provide the means by
1323 which applications knowledgable in the given directory service
1324 protocol can obtain additional or more up-to-date information from
1325 the directory service. It contains a URI as defined in [RFC3986]
1326 and/or other information referencing the vCard to which the
1327 information pertains. When directory information is available
1328 from more than one source, the sending entity can pick what it
1329 considers to be the best source, or multiple SOURCE properties can
1334 SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param
1335 / mediatype-param / any-param
1340 SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US
1346 Perreault Standards Track [Page 24]
1348 RFC 6350 vCard August 2011
1351 SOURCE:http://directory.example.com/addressbooks/jdoe/
1356 Purpose: To specify the kind of object the vCard represents.
1358 Value type: A single text value.
1362 Special notes: The value may be one of the following:
1364 "individual" for a vCard representing a single person or entity.
1365 This is the default kind of vCard.
1367 "group" for a vCard representing a group of persons or entities.
1368 The group's member entities can be other vCards or other types
1369 of entities, such as email addresses or web sites. A group
1370 vCard will usually contain MEMBER properties to specify the
1371 members of the group, but it is not required to. A group vCard
1372 without MEMBER properties can be considered an abstract
1373 grouping, or one whose members are known empirically (perhaps
1374 "IETF Participants" or "Republican U.S. Senators").
1376 All properties in a group vCard apply to the group as a whole,
1377 and not to any particular MEMBER. For example, an EMAIL
1378 property might specify the address of a mailing list associated
1379 with the group, and an IMPP property might refer to a group
1382 "org" for a vCard representing an organization. An organization
1383 vCard will not (in fact, MUST NOT) contain MEMBER properties,
1384 and so these are something of a cross between "individual" and
1385 "group". An organization is a single entity, but not a person.
1386 It might represent a business or government, a department or
1387 division within a business or government, a club, an
1388 association, or the like.
1390 All properties in an organization vCard apply to the
1391 organization as a whole, as is the case with a group vCard.
1392 For example, an EMAIL property might specify the address of a
1393 contact point for the organization.
1402 Perreault Standards Track [Page 25]
1404 RFC 6350 vCard August 2011
1407 "location" for a named geographical place. A location vCard will
1408 usually contain a GEO property, but it is not required to. A
1409 location vCard without a GEO property can be considered an
1410 abstract location, or one whose definition is known empirically
1411 (perhaps "New England" or "The Seashore").
1413 All properties in a location vCard apply to the location
1414 itself, and not with any entity that might exist at that
1415 location. For example, in a vCard for an office building, an
1416 ADR property might give the mailing address for the building,
1417 and a TEL property might specify the telephone number of the
1420 An x-name. vCards MAY include private or experimental values for
1421 KIND. Remember that x-name values are not intended for general
1422 use and are unlikely to interoperate.
1424 An iana-token. Additional values may be registered with IANA (see
1425 Section 10.3.4). A new value's specification document MUST
1426 specify which properties make sense for that new kind of vCard
1429 Implementations MUST support the specific string values defined
1430 above. If this property is absent, "individual" MUST be assumed
1431 as the default. If this property is present but the
1432 implementation does not understand its value (the value is an
1433 x-name or iana-token that the implementation does not support),
1434 the implementation SHOULD act in a neutral way, which usually
1435 means treating the vCard as though its kind were "individual".
1436 The presence of MEMBER properties MAY, however, be taken as an
1437 indication that the unknown kind is an extension of "group".
1439 Clients often need to visually distinguish contacts based on what
1440 they represent, and the KIND property provides a direct way for
1441 them to do so. For example, when displaying contacts in a list,
1442 an icon could be displayed next to each one, using distinctive
1443 icons for the different kinds; a client might use an outline of a
1444 single person to represent an "individual", an outline of multiple
1445 people to represent a "group", and so on. Alternatively, or in
1446 addition, a client might choose to segregate different kinds of
1447 vCards to different panes, tabs, or selections in the user
1450 Some clients might also make functional distinctions among the
1451 kinds, ignoring "location" vCards for some purposes and
1452 considering only "location" vCards for others.
1458 Perreault Standards Track [Page 26]
1460 RFC 6350 vCard August 2011
1463 When designing those sorts of visual and functional distinctions,
1464 client implementations have to decide how to fit unsupported kinds
1465 into the scheme. What icon is used for them? The one for
1466 "individual"? A unique one, such as an icon of a question mark?
1467 Which tab do they go into? It is beyond the scope of this
1468 specification to answer these questions, but these are things
1469 implementers need to consider.
1473 KIND-param = "VALUE=text" / any-param
1474 KIND-value = "individual" / "group" / "org" / "location"
1475 / iana-token / x-name
1479 This represents someone named Jane Doe working in the marketing
1480 department of the North American division of ABC Inc.
1486 ORG:ABC\, Inc.;North American Division;Marketing
1489 This represents the department itself, commonly known as ABC
1496 ORG:ABC\, Inc.;North American Division;Marketing
1501 Purpose: To include extended XML-encoded vCard data in a plain
1504 Value type: A single text value.
1508 Special notes: The content of this property is a single XML 1.0
1509 [W3C.REC-xml-20081126] element whose namespace MUST be explicitly
1510 specified using the xmlns attribute and MUST NOT be the vCard 4
1514 Perreault Standards Track [Page 27]
1516 RFC 6350 vCard August 2011
1519 namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies
1520 that it cannot duplicate a standard vCard property.) The element
1521 is to be interpreted as if it was contained in a <vcard> element,
1522 as defined in [RFC6351].
1524 The fragment is subject to normal line folding and escaping, i.e.,
1525 replace all backslashes with "\\", then replace all newlines with
1526 "\n", then fold long lines.
1528 Support for this property is OPTIONAL, but implementations of this
1529 specification MUST preserve instances of this property when
1532 See [RFC6351] for more information on the intended use of this
1537 XML-param = "VALUE=text" / altid-param
1540 6.2. Identification Properties
1542 These types are used to capture information associated with the
1543 identification and naming of the entity associated with the vCard.
1547 Purpose: To specify the formatted text corresponding to the name of
1548 the object the vCard represents.
1550 Value type: A single text value.
1554 Special notes: This property is based on the semantics of the X.520
1555 Common Name attribute [CCITT.X520.1988]. The property MUST be
1556 present in the vCard object.
1560 FN-param = "VALUE=text" / type-param / language-param / altid-param
1561 / pid-param / pref-param / any-param
1566 FN:Mr. John Q. Public\, Esq.
1570 Perreault Standards Track [Page 28]
1572 RFC 6350 vCard August 2011
1577 Purpose: To specify the components of the name of the object the
1580 Value type: A single structured text value. Each component can have
1585 Special note: The structured property value corresponds, in
1586 sequence, to the Family Names (also known as surnames), Given
1587 Names, Additional Names, Honorific Prefixes, and Honorific
1588 Suffixes. The text components are separated by the SEMICOLON
1589 character (U+003B). Individual text components can include
1590 multiple text values separated by the COMMA character (U+002C).
1591 This property is based on the semantics of the X.520 individual
1592 name attributes [CCITT.X520.1988]. The property SHOULD be present
1593 in the vCard object when the name of the object the vCard
1594 represents follows the X.520 model.
1596 The SORT-AS parameter MAY be applied to this property.
1600 N-param = "VALUE=text" / sort-as-param / language-param
1601 / altid-param / any-param
1602 N-value = list-component 4(";" list-component)
1606 N:Public;John;Quinlan;Mr.;Esq.
1608 N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
1612 Purpose: To specify the text corresponding to the nickname of the
1613 object the vCard represents.
1615 Value type: One or more text values separated by a COMMA character
1626 Perreault Standards Track [Page 29]
1628 RFC 6350 vCard August 2011
1631 Special note: The nickname is the descriptive name given instead of
1632 or in addition to the one belonging to the object the vCard
1633 represents. It can also be used to specify a familiar form of a
1634 proper name specified by the FN or N properties.
1638 NICKNAME-param = "VALUE=text" / type-param / language-param
1639 / altid-param / pid-param / pref-param / any-param
1640 NICKNAME-value = text-list
1648 NICKNAME;TYPE=work:Boss
1652 Purpose: To specify an image or photograph information that
1653 annotates some aspect of the object the vCard represents.
1655 Value type: A single URI.
1661 PHOTO-param = "VALUE=uri" / altid-param / type-param
1662 / mediatype-param / pref-param / pid-param / any-param
1667 PHOTO:http://www.example.com/pub/photos/jqpublic.gif
1669 PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv
1670 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
1671 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
1672 <...remainder of base64-encoded data...>
1676 Purpose: To specify the birth date of the object the vCard
1682 Perreault Standards Track [Page 30]
1684 RFC 6350 vCard August 2011
1687 Value type: The default is a single date-and-or-time value. It can
1688 also be reset to a single text value.
1694 BDAY-param = BDAY-param-date / BDAY-param-text
1695 BDAY-value = date-and-or-time / text
1696 ; Value and parameter MUST match.
1698 BDAY-param-date = "VALUE=date-and-or-time"
1699 BDAY-param-text = "VALUE=text" / language-param
1701 BDAY-param =/ altid-param / calscale-param / any-param
1702 ; calscale-param can only be present when BDAY-value is
1703 ; date-and-or-time and actually contains a date or date-time.
1709 BDAY;19531015T231000Z
1710 BDAY;VALUE=text:circa 1800
1714 Purpose: The date of marriage, or equivalent, of the object the
1717 Value type: The default is a single date-and-or-time value. It can
1718 also be reset to a single text value.
1724 ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text")
1725 ANNIVERSARY-value = date-and-or-time / text
1726 ; Value and parameter MUST match.
1728 ANNIVERSARY-param =/ altid-param / calscale-param / any-param
1729 ; calscale-param can only be present when ANNIVERSARY-value is
1730 ; date-and-or-time and actually contains a date or date-time.
1734 ANNIVERSARY:19960415
1738 Perreault Standards Track [Page 31]
1740 RFC 6350 vCard August 2011
1745 Purpose: To specify the components of the sex and gender identity of
1746 the object the vCard represents.
1748 Value type: A single structured value with two components. Each
1749 component has a single text value.
1753 Special notes: The components correspond, in sequence, to the sex
1754 (biological), and gender identity. Each component is optional.
1756 Sex component: A single letter. M stands for "male", F stands
1757 for "female", O stands for "other", N stands for "none or not
1758 applicable", U stands for "unknown".
1760 Gender identity component: Free-form text.
1764 GENDER-param = "VALUE=text" / any-param
1765 GENDER-value = sex [";" text]
1767 sex = "" / "M" / "F" / "O" / "N" / "U"
1776 GENDER:;it's complicated
1778 6.3. Delivery Addressing Properties
1780 These types are concerned with information related to the delivery
1781 addressing or label for the vCard object.
1785 Purpose: To specify the components of the delivery address for the
1788 Value type: A single structured text value, separated by the
1789 SEMICOLON character (U+003B).
1794 Perreault Standards Track [Page 32]
1796 RFC 6350 vCard August 2011
1801 Special notes: The structured type value consists of a sequence of
1802 address components. The component values MUST be specified in
1803 their corresponding position. The structured type value
1804 corresponds, in sequence, to
1805 the post office box;
1806 the extended address (e.g., apartment or suite number);
1808 the locality (e.g., city);
1809 the region (e.g., state or province);
1811 the country name (full name in the language specified in
1814 When a component value is missing, the associated component
1815 separator MUST still be specified.
1817 Experience with vCard 3 has shown that the first two components
1818 (post office box and extended address) are plagued with many
1819 interoperability issues. To ensure maximal interoperability,
1820 their values SHOULD be empty.
1822 The text components are separated by the SEMICOLON character
1823 (U+003B). Where it makes semantic sense, individual text
1824 components can include multiple text values (e.g., a "street"
1825 component with multiple lines) separated by the COMMA character
1828 The property can include the "PREF" parameter to indicate the
1829 preferred delivery address when more than one address is
1832 The GEO and TZ parameters MAY be used with this property.
1834 The property can also include a "LABEL" parameter to present a
1835 delivery address label for the address. Its value is a plain-text
1836 string representing the formatted address. Newlines are encoded
1837 as \n, as they are for property values.
1841 label-param = "LABEL=" param-value
1843 ADR-param = "VALUE=text" / label-param / language-param
1844 / geo-parameter / tz-parameter / altid-param / pid-param
1845 / pref-param / type-param / any-param
1850 Perreault Standards Track [Page 33]
1852 RFC 6350 vCard August 2011
1855 ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
1856 ADR-component-street ";" ADR-component-locality ";"
1857 ADR-component-region ";" ADR-component-code ";"
1858 ADR-component-country
1859 ADR-component-pobox = list-component
1860 ADR-component-ext = list-component
1861 ADR-component-street = list-component
1862 ADR-component-locality = list-component
1863 ADR-component-region = list-component
1864 ADR-component-code = list-component
1865 ADR-component-country = list-component
1867 Example: In this example, the post office box and the extended
1870 ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
1871 Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
1872 U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
1874 6.4. Communications Properties
1876 These properties describe information about how to communicate with
1877 the object the vCard represents.
1881 Purpose: To specify the telephone number for telephony communication
1882 with the object the vCard represents.
1884 Value type: By default, it is a single free-form text value (for
1885 backward compatibility with vCard 3), but it SHOULD be reset to a
1886 URI value. It is expected that the URI scheme will be "tel", as
1887 specified in [RFC3966], but other schemes MAY be used.
1891 Special notes: This property is based on the X.520 Telephone Number
1892 attribute [CCITT.X520.1988].
1894 The property can include the "PREF" parameter to indicate a
1895 preferred-use telephone number.
1897 The property can include the parameter "TYPE" to specify intended
1898 use for the telephone number. The predefined values for the TYPE
1906 Perreault Standards Track [Page 34]
1908 RFC 6350 vCard August 2011
1911 +-----------+-------------------------------------------------------+
1912 | Value | Description |
1913 +-----------+-------------------------------------------------------+
1914 | text | Indicates that the telephone number supports text |
1915 | | messages (SMS). |
1916 | voice | Indicates a voice telephone number. |
1917 | fax | Indicates a facsimile telephone number. |
1918 | cell | Indicates a cellular or mobile telephone number. |
1919 | video | Indicates a video conferencing telephone number. |
1920 | pager | Indicates a paging device telephone number. |
1921 | textphone | Indicates a telecommunication device for people with |
1922 | | hearing or speech difficulties. |
1923 +-----------+-------------------------------------------------------+
1925 The default type is "voice". These type parameter values can be
1926 specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
1927 value list (e.g., TYPE="text,voice"). The default can be
1928 overridden to another set of values by specifying one or more
1929 alternate values. For example, the default TYPE of "voice" can be
1930 reset to a VOICE and FAX telephone number by the value list
1933 If this property's value is a URI that can also be used for
1934 instant messaging, the IMPP (Section 6.4.3) property SHOULD be
1935 used in addition to this property.
1939 TEL-param = TEL-text-param / TEL-uri-param
1940 TEL-value = TEL-text-value / TEL-uri-value
1941 ; Value and parameter MUST match.
1943 TEL-text-param = "VALUE=text"
1944 TEL-text-value = text
1946 TEL-uri-param = "VALUE=uri" / mediatype-param
1949 TEL-param =/ type-param / pid-param / pref-param / altid-param
1952 type-param-tel = "text" / "voice" / "fax" / "cell" / "video"
1953 / "pager" / "textphone" / iana-token / x-name
1954 ; type-param-tel MUST NOT be used with a property other than TEL.
1962 Perreault Standards Track [Page 35]
1964 RFC 6350 vCard August 2011
1969 TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
1970 TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67
1974 Purpose: To specify the electronic mail address for communication
1975 with the object the vCard represents.
1977 Value type: A single text value.
1981 Special notes: The property can include tye "PREF" parameter to
1982 indicate a preferred-use email address when more than one is
1985 Even though the value is free-form UTF-8 text, it is likely to be
1986 interpreted by a Mail User Agent (MUA) as an "addr-spec", as
1987 defined in [RFC5322], Section 3.4.1. Readers should also be aware
1988 of the current work toward internationalized email addresses
1993 EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param
1994 / altid-param / any-param
1999 EMAIL;TYPE=work:jqpublic@xyz.example.com
2001 EMAIL;PREF=1:jane_doe@example.com
2005 Purpose: To specify the URI for instant messaging and presence
2006 protocol communications with the object the vCard represents.
2008 Value type: A single URI.
2012 Special notes: The property may include the "PREF" parameter to
2013 indicate that this is a preferred address and has the same
2014 semantics as the "PREF" parameter in a TEL property.
2018 Perreault Standards Track [Page 36]
2020 RFC 6350 vCard August 2011
2023 If this property's value is a URI that can be used for voice
2024 and/or video, the TEL property (Section 6.4.1) SHOULD be used in
2025 addition to this property.
2027 This property is adapted from [RFC4770], which is made obsolete by
2032 IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param
2033 / mediatype-param / altid-param / any-param
2038 IMPP;PREF=1:xmpp:alice@example.com
2042 Purpose: To specify the language(s) that may be used for contacting
2043 the entity associated with the vCard.
2045 Value type: A single language-tag value.
2051 LANG-param = "VALUE=language-tag" / pid-param / pref-param
2052 / altid-param / type-param / any-param
2053 LANG-value = Language-Tag
2057 LANG;TYPE=work;PREF=1:en
2058 LANG;TYPE=work;PREF=2:fr
2061 6.5. Geographical Properties
2063 These properties are concerned with information associated with
2064 geographical positions or regions associated with the object the
2069 Purpose: To specify information related to the time zone of the
2070 object the vCard represents.
2074 Perreault Standards Track [Page 37]
2076 RFC 6350 vCard August 2011
2079 Value type: The default is a single text value. It can also be
2080 reset to a single URI or utc-offset value.
2084 Special notes: It is expected that names from the public-domain
2085 Olson database [TZ-DB] will be used, but this is not a
2086 restriction. See also [IANA-TZ].
2088 Efforts are currently being directed at creating a standard URI
2089 scheme for expressing time zone information. Usage of such a
2090 scheme would ensure a high level of interoperability between
2091 implementations that support it.
2093 Note that utc-offset values SHOULD NOT be used because the UTC
2094 offset varies with time -- not just because of the usual daylight
2095 saving time shifts that occur in may regions, but often entire
2096 regions will "re-base" their overall offset. The actual offset
2097 may be +/- 1 hour (or perhaps a little more) than the one given.
2101 TZ-param = "VALUE=" ("text" / "uri" / "utc-offset")
2102 TZ-value = text / URI / utc-offset
2103 ; Value and parameter MUST match.
2105 TZ-param =/ altid-param / pid-param / pref-param / type-param
2106 / mediatype-param / any-param
2110 TZ:Raleigh/North America
2112 TZ;VALUE=utc-offset:-0500
2113 ; Note: utc-offset format is NOT RECOMMENDED.
2117 Purpose: To specify information related to the global positioning of
2118 the object the vCard represents.
2120 Value type: A single URI.
2124 Special notes: The "geo" URI scheme [RFC5870] is particularly well
2125 suited for this property, but other schemes MAY be used.
2130 Perreault Standards Track [Page 38]
2132 RFC 6350 vCard August 2011
2137 GEO-param = "VALUE=uri" / pid-param / pref-param / type-param
2138 / mediatype-param / altid-param / any-param
2143 GEO:geo:37.386013,-122.082932
2145 6.6. Organizational Properties
2147 These properties are concerned with information associated with
2148 characteristics of the organization or organizational units of the
2149 object that the vCard represents.
2153 Purpose: To specify the position or job of the object the vCard
2156 Value type: A single text value.
2160 Special notes: This property is based on the X.520 Title attribute
2165 TITLE-param = "VALUE=text" / language-param / pid-param
2166 / pref-param / altid-param / type-param / any-param
2171 TITLE:Research Scientist
2175 Purpose: To specify the function or part played in a particular
2176 situation by the object the vCard represents.
2178 Value type: A single text value.
2186 Perreault Standards Track [Page 39]
2188 RFC 6350 vCard August 2011
2191 Special notes: This property is based on the X.520 Business Category
2192 explanatory attribute [CCITT.X520.1988]. This property is
2193 included as an organizational type to avoid confusion with the
2194 semantics of the TITLE property and incorrect usage of that
2195 property when the semantics of this property is intended.
2199 ROLE-param = "VALUE=text" / language-param / pid-param / pref-param
2200 / type-param / altid-param / any-param
2209 Purpose: To specify a graphic image of a logo associated with the
2210 object the vCard represents.
2212 Value type: A single URI.
2218 LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param
2219 / type-param / mediatype-param / altid-param / any-param
2224 LOGO:http://www.example.com/pub/logos/abccorp.jpg
2226 LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc
2227 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
2228 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
2229 <...the remainder of base64-encoded data...>
2233 Purpose: To specify the organizational name and units associated
2236 Value type: A single structured text value consisting of components
2237 separated by the SEMICOLON character (U+003B).
2242 Perreault Standards Track [Page 40]
2244 RFC 6350 vCard August 2011
2249 Special notes: The property is based on the X.520 Organization Name
2250 and Organization Unit attributes [CCITT.X520.1988]. The property
2251 value is a structured type consisting of the organization name,
2252 followed by zero or more levels of organizational unit names.
2254 The SORT-AS parameter MAY be applied to this property.
2258 ORG-param = "VALUE=text" / sort-as-param / language-param
2259 / pid-param / pref-param / altid-param / type-param
2261 ORG-value = component *(";" component)
2263 Example: A property value consisting of an organizational name,
2264 organizational unit #1 name, and organizational unit #2 name.
2266 ORG:ABC\, Inc.;North American Division;Marketing
2270 Purpose: To include a member in the group this vCard represents.
2272 Value type: A single URI. It MAY refer to something other than a
2273 vCard object. For example, an email distribution list could
2274 employ the "mailto" URI scheme [RFC6068] for efficiency.
2278 Special notes: This property MUST NOT be present unless the value of
2279 the KIND property is "group".
2283 MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param
2284 / mediatype-param / any-param
2298 Perreault Standards Track [Page 41]
2300 RFC 6350 vCard August 2011
2309 MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
2310 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
2315 UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
2320 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
2326 FN:Funky distribution list
2327 MEMBER:mailto:subscriber1@example.com
2328 MEMBER:xmpp:subscriber2@example.com
2329 MEMBER:sip:subscriber3@example.com
2330 MEMBER:tel:+1-418-555-5555
2335 Purpose: To specify a relationship between another entity and the
2336 entity represented by this vCard.
2338 Value type: A single URI. It can also be reset to a single text
2339 value. The text value can be used to specify textual information.
2343 Special notes: The TYPE parameter MAY be used to characterize the
2344 related entity. It contains a comma-separated list of values that
2345 are registered with IANA as described in Section 10.2. The
2346 registry is pre-populated with the values defined in [xfn]. This
2347 document also specifies two additional values:
2349 agent: an entity who may sometimes act on behalf of the entity
2350 associated with the vCard.
2354 Perreault Standards Track [Page 42]
2356 RFC 6350 vCard August 2011
2359 emergency: indicates an emergency contact
2363 RELATED-param = RELATED-param-uri / RELATED-param-text
2364 RELATED-value = URI / text
2365 ; Parameter and value MUST match.
2367 RELATED-param-uri = "VALUE=uri" / mediatype-param
2368 RELATED-param-text = "VALUE=text" / language-param
2370 RELATED-param =/ pid-param / pref-param / altid-param / type-param
2373 type-param-related = related-type-value *("," related-type-value)
2374 ; type-param-related MUST NOT be used with a property other than
2377 related-type-value = "contact" / "acquaintance" / "friend" / "met"
2378 / "co-worker" / "colleague" / "co-resident"
2379 / "neighbor" / "child" / "parent"
2380 / "sibling" / "spouse" / "kin" / "muse"
2381 / "crush" / "date" / "sweetheart" / "me"
2382 / "agent" / "emergency"
2386 RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
2387 RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf
2388 RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane
2389 Doe for any inquiries.
2391 6.7. Explanatory Properties
2393 These properties are concerned with additional explanations, such as
2394 that related to informational notes or revisions specific to the
2399 Purpose: To specify application category information about the
2400 vCard, also known as "tags".
2402 Value type: One or more text values separated by a COMMA character
2410 Perreault Standards Track [Page 43]
2412 RFC 6350 vCard August 2011
2417 CATEGORIES-param = "VALUE=text" / pid-param / pref-param
2418 / type-param / altid-param / any-param
2419 CATEGORIES-value = text-list
2423 CATEGORIES:TRAVEL AGENT
2425 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
2429 Purpose: To specify supplemental information or a comment that is
2430 associated with the vCard.
2432 Value type: A single text value.
2436 Special notes: The property is based on the X.520 Description
2437 attribute [CCITT.X520.1988].
2441 NOTE-param = "VALUE=text" / language-param / pid-param / pref-param
2442 / type-param / altid-param / any-param
2447 NOTE:This fax number is operational 0800 to 1715
2452 Purpose: To specify the identifier for the product that created the
2455 Type value: A single text value.
2459 Special notes: Implementations SHOULD use a method such as that
2460 specified for Formal Public Identifiers in [ISO9070] or for
2461 Universal Resource Names in [RFC3406] to ensure that the text
2466 Perreault Standards Track [Page 44]
2468 RFC 6350 vCard August 2011
2473 PRODID-param = "VALUE=text" / any-param
2478 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
2482 Purpose: To specify revision information about the current vCard.
2484 Value type: A single timestamp value.
2488 Special notes: The value distinguishes the current revision of the
2489 information in this vCard for other renditions of the information.
2493 REV-param = "VALUE=timestamp" / any-param
2494 REV-value = timestamp
2498 REV:19951031T222710Z
2502 Purpose: To specify a digital sound content information that
2503 annotates some aspect of the vCard. This property is often used
2504 to specify the proper pronunciation of the name property value of
2507 Value type: A single URI.
2513 SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param
2514 / type-param / mediatype-param / altid-param
2522 Perreault Standards Track [Page 45]
2524 RFC 6350 vCard August 2011
2529 SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com
2531 SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh
2532 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
2533 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
2534 <...the remainder of base64-encoded data...>
2538 Purpose: To specify a value that represents a globally unique
2539 identifier corresponding to the entity associated with the vCard.
2541 Value type: A single URI value. It MAY also be reset to free-form
2546 Special notes: This property is used to uniquely identify the object
2547 that the vCard represents. The "uuid" URN namespace defined in
2548 [RFC4122] is particularly well suited to this task, but other URI
2549 schemes MAY be used. Free-form text MAY also be used.
2553 UID-param = UID-uri-param / UID-text-param
2554 UID-value = UID-uri-value / UID-text-value
2555 ; Value and parameter MUST match.
2557 UID-uri-param = "VALUE=uri"
2560 UID-text-param = "VALUE=text"
2561 UID-text-value = text
2563 UID-param =/ any-param
2567 UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
2578 Perreault Standards Track [Page 46]
2580 RFC 6350 vCard August 2011
2585 Purpose: To give a global meaning to a local PID source identifier.
2587 Value type: A semicolon-separated pair of values. The first field
2588 is a small integer corresponding to the second field of a PID
2589 parameter instance. The second field is a URI. The "uuid" URN
2590 namespace defined in [RFC4122] is particularly well suited to this
2591 task, but other URI schemes MAY be used.
2595 Special notes: PID source identifiers (the source identifier is the
2596 second field in a PID parameter instance) are small integers that
2597 only have significance within the scope of a single vCard
2598 instance. Each distinct source identifier present in a vCard MUST
2599 have an associated CLIENTPIDMAP. See Section 7 for more details
2600 on the usage of CLIENTPIDMAP.
2602 PID source identifiers MUST be strictly positive. Zero is not
2605 As a special exception, the PID parameter MUST NOT be applied to
2610 CLIENTPIDMAP-param = any-param
2611 CLIENTPIDMAP-value = 1*DIGIT ";" URI
2615 TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555
2616 EMAIL;PID=4.1,5.2:jdoe@example.com
2617 CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b
2618 CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5
2622 Purpose: To specify a uniform resource locator associated with the
2623 object to which the vCard refers. Examples for individuals
2624 include personal web sites, blogs, and social networking site
2629 Value type: A single uri value.
2634 Perreault Standards Track [Page 47]
2636 RFC 6350 vCard August 2011
2641 URL-param = "VALUE=uri" / pid-param / pref-param / type-param
2642 / mediatype-param / altid-param / any-param
2647 URL:http://example.org/restaurant.french/~chezchic.html
2651 Purpose: To specify the version of the vCard specification used to
2654 Value type: A single text value.
2658 Special notes: This property MUST be present in the vCard object,
2659 and it must appear immediately after BEGIN:VCARD. The value MUST
2660 be "4.0" if the vCard corresponds to this specification. Note
2661 that earlier versions of vCard allowed this property to be placed
2662 anywhere in the vCard object, or even to be absent.
2666 VERSION-param = "VALUE=text" / any-param
2667 VERSION-value = "4.0"
2673 6.8. Security Properties
2675 These properties are concerned with the security of communication
2676 pathways or access to the vCard.
2680 Purpose: To specify a public key or authentication certificate
2681 associated with the object that the vCard represents.
2683 Value type: A single URI. It can also be reset to a text value.
2690 Perreault Standards Track [Page 48]
2692 RFC 6350 vCard August 2011
2697 KEY-param = KEY-uri-param / KEY-text-param
2698 KEY-value = KEY-uri-value / KEY-text-value
2699 ; Value and parameter MUST match.
2701 KEY-uri-param = "VALUE=uri" / mediatype-param
2704 KEY-text-param = "VALUE=text"
2705 KEY-text-value = text
2707 KEY-param =/ altid-param / pid-param / pref-param / type-param
2712 KEY:http://www.example.com/keys/jdoe.cer
2714 KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe
2716 KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE
2717 UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
2718 <... remainder of base64-encoded data ...>
2720 6.9. Calendar Properties
2722 These properties are further specified in [RFC2739].
2726 Purpose: To specify the URI for the busy time associated with the
2727 object that the vCard represents.
2729 Value type: A single URI value.
2733 Special notes: Where multiple FBURL properties are specified, the
2734 default FBURL property is indicated with the PREF parameter. The
2735 FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar
2736 [RFC5545] object associated with a snapshot of the next few weeks
2737 or months of busy time data. If the iCalendar object is
2738 represented as a file or document, its file extension should be
2746 Perreault Standards Track [Page 49]
2748 RFC 6350 vCard August 2011
2753 FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param
2754 / mediatype-param / altid-param / any-param
2759 FBURL;PREF=1:http://www.example.com/busy/janedoe
2760 FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb
2764 Purpose: To specify the calendar user address [RFC5545] to which a
2765 scheduling request [RFC5546] should be sent for the object
2766 represented by the vCard.
2768 Value type: A single URI value.
2772 Special notes: Where multiple CALADRURI properties are specified,
2773 the default CALADRURI property is indicated with the PREF
2778 CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param
2779 / mediatype-param / altid-param / any-param
2780 CALADRURI-value = URI
2784 CALADRURI;PREF=1:mailto:janedoe@example.com
2785 CALADRURI:http://example.com/calendar/jdoe
2789 Purpose: To specify the URI for a calendar associated with the
2790 object represented by the vCard.
2792 Value type: A single URI value.
2796 Special notes: Where multiple CALURI properties are specified, the
2797 default CALURI property is indicated with the PREF parameter. The
2798 property should contain a URI pointing to an iCalendar [RFC5545]
2802 Perreault Standards Track [Page 50]
2804 RFC 6350 vCard August 2011
2807 object associated with a snapshot of the user's calendar store.
2808 If the iCalendar object is represented as a file or document, its
2809 file extension should be ".ics".
2813 CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param
2814 / mediatype-param / altid-param / any-param
2819 CALURI;PREF=1:http://cal.example.com/calA
2820 CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics
2822 6.10. Extended Properties and Parameters
2824 The properties and parameters defined by this document can be
2825 extended. Non-standard, private properties and parameters with a
2826 name starting with "X-" may be defined bilaterally between two
2827 cooperating agents without outside registration or standardization.
2831 vCard data often needs to be synchronized between devices. In this
2832 context, synchronization is defined as the intelligent merging of two
2833 representations of the same object. vCard 4.0 includes mechanisms to
2838 Two mechanisms are available: the UID property is used to match
2839 multiple instances of the same vCard, while the PID parameter is used
2840 to match multiple instances of the same property.
2842 The term "matching" is used here to mean recognizing that two
2843 instances are in fact representations of the same object. For
2844 example, a single vCard that is shared with someone results in two
2845 vCard instances. After they have evolved separately, they still
2846 represent the same object, and therefore may be matched by a
2847 synchronization engine.
2849 7.1.1. Matching vCard Instances
2851 vCard instances for which the UID properties (Section 6.7.6) are
2852 equivalent MUST be matched. Equivalence is determined as specified
2853 in [RFC3986], Section 6.
2858 Perreault Standards Track [Page 51]
2860 RFC 6350 vCard August 2011
2863 In all other cases, vCard instances MAY be matched at the discretion
2864 of the synchronization engine.
2866 7.1.2. Matching Property Instances
2868 Property instances belonging to unmatched vCards MUST NOT be matched.
2870 Property instances whose name (e.g., EMAIL, TEL, etc.) is not the
2871 same MUST NOT be matched.
2873 Property instances whose name is CLIENTPIDMAP are handled separately
2874 and MUST NOT be matched. The synchronization MUST ensure that there
2875 is consistency of CLIENTPIDMAPs among matched vCard instances.
2877 Property instances belonging to matched vCards, whose name is the
2878 same, and whose maximum cardinality is 1, MUST be matched.
2880 Property instances belonging to matched vCards, whose name is the
2881 same, and whose PID parameters match, MUST be matched. See
2882 Section 7.1.3 for details on PID matching.
2884 In all other cases, property instances MAY be matched at the
2885 discretion of the synchronization engine.
2889 Two PID values for which the first fields are equivalent represent
2890 the same local value.
2892 Two PID values representing the same local value and for which the
2893 second fields point to CLIENTPIDMAP properties whose second field
2894 URIs are equivalent (as specified in [RFC3986], Section 6) also
2895 represent the same global value.
2897 PID parameters for which at least one pair of their values represent
2898 the same global value MUST be matched.
2900 In all other cases, PID parameters MAY be matched at the discretion
2901 of the synchronization engine.
2903 For example, PID value "5.1", in the first vCard below, and PID value
2904 "5.2", in the second vCard below, represent the same global value.
2914 Perreault Standards Track [Page 52]
2916 RFC 6350 vCard August 2011
2921 EMAIL;PID=4.2,5.1:jdoe@example.com
2922 CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
2923 CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
2928 EMAIL;PID=5.1,5.2:john@example.com
2929 CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
2930 CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
2937 The following simple vCard is first created on a given device.
2941 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2944 EMAIL;PID=1.1:jdoe@example.com
2945 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2948 This new vCard is assigned the UID
2949 "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating
2950 device. The FN and EMAIL properties are assigned the same local
2951 value of 1, and this value is given global context by associating it
2952 with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which
2953 represents the creating device. We are at liberty to reuse the same
2954 local value since instances of different properties will never be
2955 matched. The N property has no PID because it is forbidden by its
2956 maximum cardinality of 1.
2958 7.2.2. Initial Sharing
2960 This vCard is shared with a second device. Upon inspecting the UID
2961 property, the second device understands that this is a new vCard
2962 (i.e., unmatched) and thus the synchronization results in a simple
2970 Perreault Standards Track [Page 53]
2972 RFC 6350 vCard August 2011
2975 7.2.3. Adding and Sharing a Property
2977 A new phone number is created on the first device, then the vCard is
2978 shared with the second device. This is what the second device
2983 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
2986 EMAIL;PID=1.1:jdoe@example.com
2987 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
2988 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
2991 Upon inspecting the UID property, the second device matches the vCard
2992 it received to the vCard that it already has stored. It then starts
2993 comparing the properties of the two vCards in same-named pairs.
2995 The FN properties are matched because the PID parameters have the
2996 same global value. Since the property value is the same, no update
2999 The N properties are matched automatically because their maximum
3000 cardinality is 1. Since the property value is the same, no update
3003 The EMAIL properties are matched because the PID parameters have the
3004 same global value. Since the property value is the same, no update
3007 The TEL property in the new vCard is not matched to any in the stored
3008 vCard because no property in the stored vCard has the same name.
3009 Therefore, this property is copied from the new vCard to the stored
3012 The CLIENTPIDMAP property is handled separately by the
3013 synchronization engine. It ensures that it is consistent with the
3014 stored one. If it was not, the results would be up to the
3015 synchronization engine, and thus undefined by this document.
3017 7.2.4. Simultaneous Editing
3019 A new email address and a new phone number are added to the vCard on
3020 each of the two devices, and then a new synchronization event
3021 happens. Here are the vCards that are communicated to each other:
3026 Perreault Standards Track [Page 54]
3028 RFC 6350 vCard August 2011
3033 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
3036 EMAIL;PID=1.1:jdoe@example.com
3037 EMAIL;PID=2.1:boss@example.com
3038 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
3039 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
3040 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
3045 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
3048 EMAIL;PID=1.1:jdoe@example.com
3049 EMAIL;PID=2.2:ceo@example.com
3050 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
3051 TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666
3052 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
3053 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
3056 On the first device, the same PID source identifier (1) is reused for
3057 the new EMAIL and TEL properties. On the second device, a new source
3058 identifier (2) is generated, and a corresponding CLIENTPIDMAP
3059 property is created. It contains the second device's identifier,
3060 "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee".
3062 The new EMAIL properties are unmatched on both sides since the PID
3063 global value is new in both cases. The sync thus results in a copy
3066 Although the situation appears to be the same for the TEL properties,
3067 in this case, the synchronization engine is particularly smart and
3068 matches the two new TEL properties even though their PID global
3069 values are different. Note that in this case, the rules of
3070 Section 7.1.2 state that two properties MAY be matched at the
3071 discretion of the synchronization engine. Therefore, the two
3072 properties are merged.
3074 All this results in the following vCard, which is stored on both
3082 Perreault Standards Track [Page 55]
3084 RFC 6350 vCard August 2011
3089 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
3092 EMAIL;PID=1.1:jdoe@example.com
3093 EMAIL;PID=2.1:boss@example.com
3094 EMAIL;PID=2.2:ceo@example.com
3095 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
3096 TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666
3097 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
3098 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
3101 7.2.5. Global Context Simplification
3103 The two devices finish their synchronization procedure by simplifying
3104 their global contexts. Since they haven't talked to any other
3105 device, the following vCard is for all purposes equivalent to the
3106 above. It is also shorter.
3110 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
3113 EMAIL;PID=1.1:jdoe@example.com
3114 EMAIL;PID=2.1:boss@example.com
3115 EMAIL;PID=3.1:ceo@example.com
3116 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
3117 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
3118 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
3121 The details of global context simplification are unspecified by this
3122 document. They are left up to the synchronization engine. This
3123 example is merely intended to illustrate the possibility, which
3124 investigating would be, in the author's opinion, worthwhile.
3126 8. Example: Author's vCard
3131 N:Perreault;Simon;;;ing. jr,M.Sc.
3133 ANNIVERSARY:20090808T1430-0500
3138 Perreault Standards Track [Page 56]
3140 RFC 6350 vCard August 2011
3145 ORG;TYPE=work:Viagenie
3146 ADR;TYPE=work:;Suite D2-630;2875 Laurier;
3147 Quebec;QC;G1V 2M2;Canada
3148 TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
3149 TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501
3150 EMAIL;TYPE=work:simon.perreault@viagenie.ca
3151 GEO;TYPE=work:geo:46.772673,-71.282945
3152 KEY;TYPE=work;VALUE=uri:
3153 http://www.viagenie.ca/simon.perreault/simon.asc
3155 URL;TYPE=home:http://nomis80.org
3158 9. Security Considerations
3160 o Internet mail is often used to transport vCards and is subject to
3161 many well-known security attacks, including monitoring, replay,
3162 and forgery. Care should be taken by any directory service in
3163 allowing information to leave the scope of the service itself,
3164 where any access controls or confidentiality can no longer be
3165 guaranteed. Applications should also take care to display
3166 directory data in a "safe" environment.
3168 o vCards can carry cryptographic keys or certificates, as described
3171 o vCards often carry information that can be sensitive (e.g.,
3172 birthday, address, and phone information). Although vCards have
3173 no inherent authentication or confidentiality provisions, they can
3174 easily be carried by any security mechanism that transfers MIME
3175 objects to address authentication or confidentiality (e.g., S/MIME
3176 [RFC5751], OpenPGP [RFC4880]). In cases where the confidentiality
3177 or authenticity of information contained in vCard is a concern,
3178 the vCard SHOULD be transported using one of these secure
3179 mechanisms. The KEY property (Section 6.8.1) can be used to
3180 transport the public key used by these mechanisms.
3182 o The information in a vCard may become out of date. In cases where
3183 the vitality of data is important to an originator of a vCard, the
3184 SOURCE property (Section 6.1.3) SHOULD be specified. In addition,
3185 the "REV" type described in Section 6.7.4 can be specified to
3186 indicate the last time that the vCard data was updated.
3188 o Many vCard properties may be used to transport URIs. Please refer
3189 to [RFC3986], Section 7, for considerations related to URIs.
3194 Perreault Standards Track [Page 57]
3196 RFC 6350 vCard August 2011
3199 10. IANA Considerations
3201 10.1. Media Type Registration
3203 IANA has registered the following Media Type (in
3204 <http://www.iana.org/>) and marked the text/directory Media Type as
3207 To: ietf-types@iana.org
3209 Subject: Registration of media type text/vcard
3215 Required parameters: none
3217 Optional parameters: version
3219 The "version" parameter is to be interpreted identically as the
3220 VERSION vCard property. If this parameter is present, all vCards
3221 in a text/vcard body part MUST have a VERSION property with value
3222 identical to that of this MIME parameter.
3224 "charset": as defined for text/plain [RFC2046]; encodings other
3225 than UTF-8 [RFC3629] MUST NOT be used.
3227 Encoding considerations: 8bit
3229 Security considerations: See Section 9.
3231 Interoperability considerations: The text/vcard media type is
3232 intended to identify vCard data of any version. There are older
3233 specifications of vCard [RFC2426][vCard21] still in common use.
3234 While these formats are similar, they are not strictly compatible.
3235 In general, it is necessary to inspect the value of the VERSION
3236 property (see Section 6.7.9) for identifying the standard to which
3237 a given vCard object conforms.
3239 In addition, the following media types are known to have been used
3240 to refer to vCard data. They should be considered deprecated in
3241 favor of text/vcard.
3244 * text/directory; profile=vcard
3250 Perreault Standards Track [Page 58]
3252 RFC 6350 vCard August 2011
3255 Published specification: RFC 6350
3257 Applications that use this media type: They are numerous, diverse,
3258 and include mail user agents, instant messaging clients, address
3259 book applications, directory servers, and customer relationship
3260 management software.
3262 Additional information:
3266 File extension(s): .vcf .vcard
3268 Macintosh file type code(s):
3270 Person & email address to contact for further information: vCard
3271 discussion mailing list <vcarddav@ietf.org>
3273 Intended usage: COMMON
3275 Restrictions on usage: none
3277 Author: Simon Perreault
3279 Change controller: IETF
3281 10.2. Registering New vCard Elements
3283 This section defines the process for registering new or modified
3284 vCard elements (i.e., properties, parameters, value data types, and
3287 10.2.1. Registration Procedure
3289 The IETF has created a mailing list, vcarddav@ietf.org, which can be
3290 used for public discussion of vCard element proposals prior to
3291 registration. Use of the mailing list is strongly encouraged. The
3292 IESG has appointed a designated expert who will monitor the
3293 vcarddav@ietf.org mailing list and review registrations.
3295 Registration of new vCard elements MUST be reviewed by the designated
3296 expert and published in an RFC. A Standards Track RFC is REQUIRED
3297 for the registration of new value data types that modify existing
3298 properties. A Standards Track RFC is also REQUIRED for registration
3299 of vCard elements that modify vCard elements previously documented in
3300 a Standards Track RFC.
3306 Perreault Standards Track [Page 59]
3308 RFC 6350 vCard August 2011
3311 The registration procedure begins when a completed registration
3312 template, defined in the sections below, is sent to vcarddav@ietf.org
3313 and iana@iana.org. Within two weeks, the designated expert is
3314 expected to tell IANA and the submitter of the registration whether
3315 the registration is approved, approved with minor changes, or
3316 rejected with cause. When a registration is rejected with cause, it
3317 can be re-submitted if the concerns listed in the cause are
3318 addressed. Decisions made by the designated expert can be appealed
3319 to the IESG Applications Area Director, then to the IESG. They
3320 follow the normal appeals procedure for IESG decisions.
3322 Once the registration procedure concludes successfully, IANA creates
3323 or modifies the corresponding record in the vCard registry. The
3324 completed registration template is discarded.
3326 An RFC specifying new vCard elements MUST include the completed
3327 registration templates, which MAY be expanded with additional
3328 information. These completed templates are intended to go in the
3329 body of the document, not in the IANA Considerations section.
3331 Finally, note that there is an XML representation for vCard defined
3332 in [RFC6351]. An XML representation SHOULD be defined for new vCard
3335 10.2.2. Vendor Namespace
3337 The vendor namespace is used for vCard elements associated with
3338 commercially available products. "Vendor" or "producer" are
3339 construed as equivalent and very broadly in this context.
3341 A registration may be placed in the vendor namespace by anyone who
3342 needs to interchange files associated with the particular product.
3343 However, the registration formally belongs to the vendor or
3344 organization handling the vCard elements in the namespace being
3345 registered. Changes to the specification will be made at their
3346 request, as discussed in subsequent sections.
3348 vCard elements belonging to the vendor namespace will be
3349 distinguished by the "VND-" prefix. This is followed by an IANA-
3350 registered Private Enterprise Number (PEN), a dash, and a vCard
3351 element designation of the vendor's choosing (e.g., "VND-123456-
3354 While public exposure and review of vCard elements to be registered
3355 in the vendor namespace are not required, using the vcarddav@ietf.org
3356 mailing list for review is strongly encouraged to improve the quality
3357 of those specifications. Registrations in the vendor namespace may
3358 be submitted directly to the IANA.
3362 Perreault Standards Track [Page 60]
3364 RFC 6350 vCard August 2011
3367 10.2.3. Registration Template for Properties
3369 A property is defined by completing the following template.
3371 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor-
3372 specific property (where NNNN is replaced by the vendor's PEN).
3374 Property name: The name of the property.
3376 Purpose: The purpose of the property. Give a short but clear
3379 Value type: Any of the valid value types for the property value
3380 needs to be specified. The default value type also needs to be
3383 Cardinality: See Section 6.
3385 Property parameters: Any of the valid property parameters for the
3386 property MUST be specified.
3388 Description: Any special notes about the property, how it is to be
3391 Format definition: The ABNF for the property definition needs to be
3394 Example(s): One or more examples of instances of the property need
3397 10.2.4. Registration Template for Parameters
3399 A parameter is defined by completing the following template.
3401 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor-
3402 specific property (where NNNN is replaced by the vendor's PEN).
3404 Parameter name: The name of the parameter.
3406 Purpose: The purpose of the parameter. Give a short but clear
3409 Description: Any special notes about the parameter, how it is to be
3412 Format definition: The ABNF for the parameter definition needs to be
3418 Perreault Standards Track [Page 61]
3420 RFC 6350 vCard August 2011
3423 Example(s): One or more examples of instances of the parameter need
3426 10.2.5. Registration Template for Value Data Types
3428 A value data type is defined by completing the following template.
3430 Value name: The name of the value type.
3432 Purpose: The purpose of the value type. Give a short but clear
3435 Description: Any special notes about the value type, how it is to be
3438 Format definition: The ABNF for the value type definition needs to
3441 Example(s): One or more examples of instances of the value type need
3444 10.2.6. Registration Template for Values
3446 A value is defined by completing the following template.
3448 Value: The value literal.
3450 Purpose: The purpose of the value. Give a short but clear
3453 Conformance: The vCard properties and/or parameters that can take
3454 this value needs to be specified.
3456 Example(s): One or more examples of instances of the value need to
3459 The following is a fictitious example of a registration of a vCard
3464 Purpose: It means that the related entity is the direct hierarchical
3465 superior (i.e., supervisor or manager) of the entity this vCard
3468 Conformance: This value can be used with the "TYPE" parameter
3469 applied on the "RELATED" property.
3474 Perreault Standards Track [Page 62]
3476 RFC 6350 vCard August 2011
3481 RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
3483 10.3. Initial vCard Elements Registries
3485 The IANA has created and will maintain the following registries for
3486 vCard elements with pointers to appropriate reference documents. The
3487 registries are grouped together under the heading "vCard Elements".
3530 Perreault Standards Track [Page 63]
3532 RFC 6350 vCard August 2011
3535 10.3.1. Properties Registry
3537 The following table has been used to initialize the properties
3540 +-----------+--------------+-------------------------+
3541 | Namespace | Property | Reference |
3542 +-----------+--------------+-------------------------+
3543 | | SOURCE | RFC 6350, Section 6.1.3 |
3544 | | KIND | RFC 6350, Section 6.1.4 |
3545 | | XML | RFC 6350, Section 6.1.5 |
3546 | | FN | RFC 6350, Section 6.2.1 |
3547 | | N | RFC 6350, Section 6.2.2 |
3548 | | NICKNAME | RFC 6350, Section 6.2.3 |
3549 | | PHOTO | RFC 6350, Section 6.2.4 |
3550 | | BDAY | RFC 6350, Section 6.2.5 |
3551 | | ANNIVERSARY | RFC 6350, Section 6.2.6 |
3552 | | GENDER | RFC 6350, Section 6.2.7 |
3553 | | ADR | RFC 6350, Section 6.3.1 |
3554 | | TEL | RFC 6350, Section 6.4.1 |
3555 | | EMAIL | RFC 6350, Section 6.4.2 |
3556 | | IMPP | RFC 6350, Section 6.4.3 |
3557 | | LANG | RFC 6350, Section 6.4.4 |
3558 | | TZ | RFC 6350, Section 6.5.1 |
3559 | | GEO | RFC 6350, Section 6.5.2 |
3560 | | TITLE | RFC 6350, Section 6.6.1 |
3561 | | ROLE | RFC 6350, Section 6.6.2 |
3562 | | LOGO | RFC 6350, Section 6.6.3 |
3563 | | ORG | RFC 6350, Section 6.6.4 |
3564 | | MEMBER | RFC 6350, Section 6.6.5 |
3565 | | RELATED | RFC 6350, Section 6.6.6 |
3566 | | CATEGORIES | RFC 6350, Section 6.7.1 |
3567 | | NOTE | RFC 6350, Section 6.7.2 |
3568 | | PRODID | RFC 6350, Section 6.7.3 |
3569 | | REV | RFC 6350, Section 6.7.4 |
3570 | | SOUND | RFC 6350, Section 6.7.5 |
3571 | | UID | RFC 6350, Section 6.7.6 |
3572 | | CLIENTPIDMAP | RFC 6350, Section 6.7.7 |
3573 | | URL | RFC 6350, Section 6.7.8 |
3574 | | VERSION | RFC 6350, Section 6.7.9 |
3575 | | KEY | RFC 6350, Section 6.8.1 |
3576 | | FBURL | RFC 6350, Section 6.9.1 |
3577 | | CALADRURI | RFC 6350, Section 6.9.2 |
3578 | | CALURI | RFC 6350, Section 6.9.3 |
3579 +-----------+--------------+-------------------------+
3586 Perreault Standards Track [Page 64]
3588 RFC 6350 vCard August 2011
3591 10.3.2. Parameters Registry
3593 The following table has been used to initialize the parameters
3596 +-----------+-----------+------------------------+
3597 | Namespace | Parameter | Reference |
3598 +-----------+-----------+------------------------+
3599 | | LANGUAGE | RFC 6350, Section 5.1 |
3600 | | VALUE | RFC 6350, Section 5.2 |
3601 | | PREF | RFC 6350, Section 5.3 |
3602 | | ALTID | RFC 6350, Section 5.4 |
3603 | | PID | RFC 6350, Section 5.5 |
3604 | | TYPE | RFC 6350, Section 5.6 |
3605 | | MEDIATYPE | RFC 6350, Section 5.7 |
3606 | | CALSCALE | RFC 6350, Section 5.8 |
3607 | | SORT-AS | RFC 6350, Section 5.9 |
3608 | | GEO | RFC 6350, Section 5.10 |
3609 | | TZ | RFC 6350, Section 5.11 |
3610 +-----------+-----------+------------------------+
3612 10.3.3. Value Data Types Registry
3614 The following table has been used to initialize the parameters
3617 +------------------+-------------------------+
3618 | Value Data Type | Reference |
3619 +------------------+-------------------------+
3620 | BOOLEAN | RFC 6350, Section 4.4 |
3621 | DATE | RFC 6350, Section 4.3.1 |
3622 | DATE-AND-OR-TIME | RFC 6350, Section 4.3.4 |
3623 | DATE-TIME | RFC 6350, Section 4.3.3 |
3624 | FLOAT | RFC 6350, Section 4.6 |
3625 | INTEGER | RFC 6350, Section 4.5 |
3626 | LANGUAGE-TAG | RFC 6350, Section 4.8 |
3627 | TEXT | RFC 6350, Section 4.1 |
3628 | TIME | RFC 6350, Section 4.3.2 |
3629 | TIMESTAMP | RFC 6350, Section 4.3.5 |
3630 | URI | RFC 6350, Section 4.2 |
3631 | UTC-OFFSET | RFC 6350, Section 4.7 |
3632 +------------------+-------------------------+
3642 Perreault Standards Track [Page 65]
3644 RFC 6350 vCard August 2011
3647 10.3.4. Values Registries
3649 Separate tables are used for property and parameter values.
3651 The following table is to be used to initialize the property values
3654 +----------+------------+-------------------------+
3655 | Property | Value | Reference |
3656 +----------+------------+-------------------------+
3657 | BEGIN | VCARD | RFC 6350, Section 6.1.1 |
3658 | END | VCARD | RFC 6350, Section 6.1.2 |
3659 | KIND | individual | RFC 6350, Section 6.1.4 |
3660 | KIND | group | RFC 6350, Section 6.1.4 |
3661 | KIND | org | RFC 6350, Section 6.1.4 |
3662 | KIND | location | RFC 6350, Section 6.1.4 |
3663 +----------+------------+-------------------------+
3665 The following table has been used to initialize the parameter values
3698 Perreault Standards Track [Page 66]
3700 RFC 6350 vCard August 2011
3703 +------------------------+-----------+--------------+---------------+
3704 | Property | Parameter | Value | Reference |
3705 +------------------------+-----------+--------------+---------------+
3706 | FN, NICKNAME, PHOTO, | TYPE | work | RFC 6350, |
3707 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
3708 | LANG, TZ, GEO, TITLE, | | | |
3709 | ROLE, LOGO, ORG, | | | |
3710 | RELATED, CATEGORIES, | | | |
3711 | NOTE, SOUND, URL, KEY, | | | |
3712 | FBURL, CALADRURI, and | | | |
3714 | FN, NICKNAME, PHOTO, | TYPE | home | RFC 6350, |
3715 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
3716 | LANG, TZ, GEO, TITLE, | | | |
3717 | ROLE, LOGO, ORG, | | | |
3718 | RELATED, CATEGORIES, | | | |
3719 | NOTE, SOUND, URL, KEY, | | | |
3720 | FBURL, CALADRURI, and | | | |
3722 | TEL | TYPE | text | RFC 6350, |
3723 | | | | Section 6.4.1 |
3724 | TEL | TYPE | voice | RFC 6350, |
3725 | | | | Section 6.4.1 |
3726 | TEL | TYPE | fax | RFC 6350, |
3727 | | | | Section 6.4.1 |
3728 | TEL | TYPE | cell | RFC 6350, |
3729 | | | | Section 6.4.1 |
3730 | TEL | TYPE | video | RFC 6350, |
3731 | | | | Section 6.4.1 |
3732 | TEL | TYPE | pager | RFC 6350, |
3733 | | | | Section 6.4.1 |
3734 | TEL | TYPE | textphone | RFC 6350, |
3735 | | | | Section 6.4.1 |
3736 | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFC 6350, |
3737 | | | | Section 5.8 |
3738 | RELATED | TYPE | contact | RFC 6350, |
3739 | | | | Section 6.6.6 |
3741 | RELATED | TYPE | acquaintance | RFC 6350, |
3742 | | | | Section 6.6.6 |
3744 | RELATED | TYPE | friend | RFC 6350, |
3745 | | | | Section 6.6.6 |
3747 | RELATED | TYPE | met | RFC 6350, |
3748 | | | | Section 6.6.6 |
3754 Perreault Standards Track [Page 67]
3756 RFC 6350 vCard August 2011
3759 | RELATED | TYPE | co-worker | RFC 6350, |
3760 | | | | Section 6.6.6 |
3762 | RELATED | TYPE | colleague | RFC 6350, |
3763 | | | | Section 6.6.6 |
3765 | RELATED | TYPE | co-resident | RFC 6350, |
3766 | | | | Section 6.6.6 |
3768 | RELATED | TYPE | neighbor | RFC 6350, |
3769 | | | | Section 6.6.6 |
3771 | RELATED | TYPE | child | RFC 6350, |
3772 | | | | Section 6.6.6 |
3774 | RELATED | TYPE | parent | RFC 6350, |
3775 | | | | Section 6.6.6 |
3777 | RELATED | TYPE | sibling | RFC 6350, |
3778 | | | | Section 6.6.6 |
3780 | RELATED | TYPE | spouse | RFC 6350, |
3781 | | | | Section 6.6.6 |
3783 | RELATED | TYPE | kin | RFC 6350, |
3784 | | | | Section 6.6.6 |
3786 | RELATED | TYPE | muse | RFC 6350, |
3787 | | | | Section 6.6.6 |
3789 | RELATED | TYPE | crush | RFC 6350, |
3790 | | | | Section 6.6.6 |
3792 | RELATED | TYPE | date | RFC 6350, |
3793 | | | | Section 6.6.6 |
3795 | RELATED | TYPE | sweetheart | RFC 6350, |
3796 | | | | Section 6.6.6 |
3798 | RELATED | TYPE | me | RFC 6350, |
3799 | | | | Section 6.6.6 |
3801 | RELATED | TYPE | agent | RFC 6350, |
3802 | | | | Section 6.6.6 |
3803 | RELATED | TYPE | emergency | RFC 6350, |
3804 | | | | Section 6.6.6 |
3805 +------------------------+-----------+--------------+---------------+
3810 Perreault Standards Track [Page 68]
3812 RFC 6350 vCard August 2011
3817 The authors would like to thank Tim Howes, Mark Smith, and Frank
3818 Dawson, the original authors of [RFC2425] and [RFC2426], Pete
3819 Resnick, who got this effort started and provided help along the way,
3820 as well as the following individuals who have participated in the
3821 drafting, review, and discussion of this memo:
3823 Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil
3824 Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie
3825 Hoeneisen, Bjoern Hoehrmann, Caleb Richardson, Chris Bryant, Chris
3826 Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale,
3827 Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian
3828 Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens,
3829 Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke,
3830 Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga, Lisa Dusseault,
3831 Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike
3832 Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter
3833 Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane
3834 Bortzmeyer, Tantek Celik, and Zoltan Ordogh.
3838 12.1. Normative References
3841 International Telephone and Telegraph Consultative
3842 Committee, "Information Technology - Open Systems
3843 Interconnection - The Directory: Selected Attribute
3844 Types", CCITT Recommendation X.520, November 1988.
3847 Institute of Electrical and Electronics Engineers,
3848 "Standard for Binary Floating-Point Arithmetic",
3849 IEEE Standard 754, August 2008.
3852 International Organization for Standardization, "Data
3853 elements and interchange formats - Information interchange
3854 - Representation of dates and times", ISO Standard 8601,
3858 International Organization for Standardization, "Data
3859 elements and interchange formats - Information interchange
3860 - Representation of dates and times", ISO Standard 8601,
3866 Perreault Standards Track [Page 69]
3868 RFC 6350 vCard August 2011
3871 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
3872 Extensions (MIME) Part One: Format of Internet Message
3873 Bodies", RFC 2045, November 1996.
3875 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
3876 Extensions (MIME) Part Two: Media Types", RFC 2046,
3879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3880 Requirement Levels", BCP 14, RFC 2119, March 1997.
3882 [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar
3883 Attributes for vCard and LDAP", RFC 2739, January 2000.
3885 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
3886 10646", STD 63, RFC 3629, November 2003.
3888 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
3889 RFC 3966, December 2004.
3891 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
3892 Resource Identifier (URI): Generic Syntax", STD 66,
3893 RFC 3986, January 2005.
3895 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
3896 Unique IDentifier (UUID) URN Namespace", RFC 4122,
3899 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
3900 Registration Procedures", BCP 13, RFC 4288, December 2005.
3902 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
3903 Specifications: ABNF", STD 68, RFC 5234, January 2008.
3905 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
3908 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
3909 Core Object Specification (iCalendar)", RFC 5545,
3912 [RFC5546] Daboo, C., "iCalendar Transport-Independent
3913 Interoperability Protocol (iTIP)", RFC 5546,
3916 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
3917 Languages", BCP 47, RFC 5646, September 2009.
3922 Perreault Standards Track [Page 70]
3924 RFC 6350 vCard August 2011
3927 [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
3928 Identifier for Geographic Locations ('geo' URI)",
3929 RFC 5870, June 2010.
3931 [RFC6351] Perreault, S., "xCard: vCard XML Representation",
3932 RFC 6351, August 2011.
3934 [W3C.REC-xml-20081126]
3935 Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J.,
3936 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
3937 Edition)", World Wide Web Consortium Recommendation REC-
3938 xml-20081126, November 2008,
3939 <http://www.w3.org/TR/2008/REC-xml-20081126>.
3941 [xfn] Celik, T., Mullenweg, M., and E. Meyer, "XFN 1.1 profile",
3942 <http://gmpg.org/xfn/11>.
3944 12.2. Informative References
3946 [IANA-TZ] Lear, E. and P. Eggert, "IANA Procedures for Maintaining
3947 the Timezone Database", Work in Progress, May 2011.
3949 [ISO9070] International Organization for Standardization,
3950 "Information Processing - SGML support facilities -
3951 Registration Procedures for Public Text Owner
3952 Identifiers", ISO 9070, April 1991.
3954 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
3955 Resource Locators (URL)", RFC 1738, December 1994.
3957 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
3960 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
3961 for Directory Information", RFC 2425, September 1998.
3963 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
3964 RFC 2426, September 1998.
3966 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3967 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3968 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3970 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
3978 Perreault Standards Track [Page 71]
3980 RFC 6350 vCard August 2011
3983 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
3984 "Uniform Resource Names (URN) Namespace Definition
3985 Mechanisms", BCP 66, RFC 3406, October 2002.
3987 [RFC3536] Hoffman, P., "Terminology Used in Internationalization in
3988 the IETF", RFC 3536, May 2003.
3990 [RFC4770] Jennings, C. and J. Reschke, Ed., "vCard Extensions for
3991 Instant Messaging (IM)", RFC 4770, January 2007.
3993 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
3994 Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
3997 Yang, A. and S. Steele, "Internationalized Email Headers",
3998 Work in Progress, July 2011.
4000 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
4001 Mail Extensions (S/MIME) Version 3.2 Message
4002 Specification", RFC 5751, January 2010.
4004 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
4005 URI Scheme", RFC 6068, October 2010.
4007 [TZ-DB] Olson, A., "Time zone code and data",
4008 <ftp://elsie.nci.nih.gov/pub/>.
4010 [vCard21] Internet Mail Consortium, "vCard - The Electronic Business
4011 Card Version 2.1", September 1996.
4034 Perreault Standards Track [Page 72]
4036 RFC 6350 vCard August 2011
4039 Appendix A. Differences from RFCs 2425 and 2426
4041 This appendix contains a high-level overview of the major changes
4042 that have been made in the vCard specification from RFCs 2425 and
4043 2426. It is incomplete, as it only lists the most important changes.
4047 o [RFC2425] and [RFC2426] have been merged.
4049 o vCard is now not only a MIME type but a stand-alone format.
4051 o A proper MIME type registration form has been included.
4053 o UTF-8 is now the only possible character set.
4055 o New vCard elements can be registered from IANA.
4057 A.2. Removed Features
4059 o The CONTEXT and CHARSET parameters are no more.
4061 o The NAME, MAILER, LABEL, and CLASS properties are no more.
4063 o The "intl", "dom", "postal", and "parcel" TYPE parameter values
4064 for the ADR property have been removed.
4066 o In-line vCards (such as the value of the AGENT property) are no
4069 A.3. New Properties and Parameters
4071 o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP
4072 properties have been added.
4074 o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI
4075 properties, has been merged in.
4077 o [RFC4770], which defines the IMPP property, has been merged in.
4079 o The "work" and "home" TYPE parameter values are now applicable to
4080 many more properties.
4082 o The "pref" value of the TYPE parameter is now a parameter of its
4083 own, with a positive integer value indicating the level of
4086 o The ALTID and PID parameters have been added.
4090 Perreault Standards Track [Page 73]
4092 RFC 6350 vCard August 2011
4095 o The MEDIATYPE parameter has been added and replaces the TYPE
4096 parameter when it was used for indicating the media type of the
4103 2875 Laurier, suite D2-630
4107 Phone: +1 418 656 9254
4108 EMail: simon.perreault@viagenie.ca
4109 URI: http://www.viagenie.ca
4146 Perreault Standards Track [Page 74]
projects / friendica-addons.git / blob