mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-08-20 22:50:22 +00:00
4147 lines
137 KiB
Text
4147 lines
137 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
Internet Engineering Task Force (IETF) S. Perreault
|
||
Request for Comments: 6350 Viagenie
|
||
Obsoletes: 2425, 2426, 4770 August 2011
|
||
Updates: 2739
|
||
Category: Standards Track
|
||
ISSN: 2070-1721
|
||
|
||
|
||
vCard Format Specification
|
||
|
||
Abstract
|
||
|
||
This document defines the vCard data format for representing and
|
||
exchanging a variety of information about individuals and other
|
||
entities (e.g., formatted and structured name and delivery addresses,
|
||
email address, multiple telephone numbers, photograph, logo, audio
|
||
clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and
|
||
updates RFC 2739.
|
||
|
||
Status of This Memo
|
||
|
||
This is an Internet Standards Track document.
|
||
|
||
This document is a product of the Internet Engineering Task Force
|
||
(IETF). It represents the consensus of the IETF community. It has
|
||
received public review and has been approved for publication by the
|
||
Internet Engineering Steering Group (IESG). Further information on
|
||
Internet Standards is available in Section 2 of RFC 5741.
|
||
|
||
Information about the current status of this document, any errata,
|
||
and how to provide feedback on it may be obtained at
|
||
http://www.rfc-editor.org/info/rfc6350.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2011 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document. Code Components extracted from this document must
|
||
include Simplified BSD License text as described in Section 4.e of
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 1]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
This document may contain material from IETF Documents or IETF
|
||
Contributions published or made publicly available before November
|
||
10, 2008. The person(s) controlling the copyright in some of this
|
||
material may not have granted the IETF Trust the right to allow
|
||
modifications of such material outside the IETF Standards Process.
|
||
Without obtaining an adequate license from the person(s) controlling
|
||
the copyright in such materials, this document may not be modified
|
||
outside the IETF Standards Process, and derivative works of it may
|
||
not be created outside the IETF Standards Process, except to format
|
||
it for publication as an RFC or to translate it into languages other
|
||
than English.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
3. vCard Format Specification . . . . . . . . . . . . . . . . . . 5
|
||
3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 5
|
||
3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 6
|
||
3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9
|
||
4. Property Value Data Types . . . . . . . . . . . . . . . . . . 9
|
||
4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||
4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 12
|
||
4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||
4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 13
|
||
4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14
|
||
4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 14
|
||
4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||
4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15
|
||
4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 15
|
||
4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 15
|
||
4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16
|
||
5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16
|
||
5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16
|
||
5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
|
||
5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
|
||
5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18
|
||
5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
|
||
5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
|
||
5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 20
|
||
5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 20
|
||
5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21
|
||
5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
|
||
5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 2]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23
|
||
6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23
|
||
6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23
|
||
6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 23
|
||
6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24
|
||
6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25
|
||
6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 27
|
||
6.2. Identification Properties . . . . . . . . . . . . . . . . 28
|
||
6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 28
|
||
6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 29
|
||
6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 29
|
||
6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 30
|
||
6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 30
|
||
6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 31
|
||
6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 32
|
||
6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 32
|
||
6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 32
|
||
6.4. Communications Properties . . . . . . . . . . . . . . . . 34
|
||
6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34
|
||
6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 36
|
||
6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 36
|
||
6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 37
|
||
6.5. Geographical Properties . . . . . . . . . . . . . . . . . 37
|
||
6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 37
|
||
6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 38
|
||
6.6. Organizational Properties . . . . . . . . . . . . . . . . 39
|
||
6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 39
|
||
6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 39
|
||
6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 40
|
||
6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40
|
||
6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 41
|
||
6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 42
|
||
6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 43
|
||
6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 43
|
||
6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 44
|
||
6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 44
|
||
6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 45
|
||
6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 45
|
||
6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 46
|
||
6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47
|
||
6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 47
|
||
6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 48
|
||
6.8. Security Properties . . . . . . . . . . . . . . . . . . . 48
|
||
6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 48
|
||
6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 49
|
||
6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 49
|
||
6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 50
|
||
6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 50
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 3]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
6.10. Extended Properties and Parameters . . . . . . . . . . . . 51
|
||
7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 51
|
||
7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 51
|
||
7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 51
|
||
7.1.2. Matching Property Instances . . . . . . . . . . . . . 52
|
||
7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 52
|
||
7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 53
|
||
7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 53
|
||
7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 53
|
||
7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 54
|
||
7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 54
|
||
7.2.5. Global Context Simplification . . . . . . . . . . . . 56
|
||
8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 56
|
||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
|
||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
|
||
10.1. Media Type Registration . . . . . . . . . . . . . . . . . 58
|
||
10.2. Registering New vCard Elements . . . . . . . . . . . . . . 59
|
||
10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 59
|
||
10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 60
|
||
10.2.3. Registration Template for Properties . . . . . . . . . 61
|
||
10.2.4. Registration Template for Parameters . . . . . . . . . 61
|
||
10.2.5. Registration Template for Value Data Types . . . . . . 62
|
||
10.2.6. Registration Template for Values . . . . . . . . . . . 62
|
||
10.3. Initial vCard Elements Registries . . . . . . . . . . . . 63
|
||
10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64
|
||
10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 65
|
||
10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 65
|
||
10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66
|
||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
|
||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
|
||
12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
|
||
12.2. Informative References . . . . . . . . . . . . . . . . . . 71
|
||
Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 73
|
||
A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73
|
||
A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 73
|
||
A.3. New Properties and Parameters . . . . . . . . . . . . . . 73
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 4]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
1. Introduction
|
||
|
||
Electronic address books have become ubiquitous. Their increased
|
||
presence on portable, connected devices as well as the diversity of
|
||
platforms that exchange contact data call for a standard. This memo
|
||
defines the vCard format, which allows the capture and exchange of
|
||
information normally stored within an address book or directory
|
||
application.
|
||
|
||
A high-level overview of the differences from RFCs 2425 and 2426 can
|
||
be found in Appendix A.
|
||
|
||
2. Conventions
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
||
"OPTIONAL" in this document are to be interpreted as described in
|
||
[RFC2119].
|
||
|
||
3. vCard Format Specification
|
||
|
||
The text/vcard MIME content type (hereafter known as "vCard"; see
|
||
Section 10.1) contains contact information, typically pertaining to a
|
||
single contact or group of contacts. The content consists of one or
|
||
more lines in the format given below.
|
||
|
||
3.1. Charset
|
||
|
||
The charset (see [RFC3536] for internationalization terminology) for
|
||
vCard is UTF-8 as defined in [RFC3629]. There is no way to override
|
||
this. It is invalid to specify a value other than "UTF-8" in the
|
||
"charset" MIME parameter (see Section 10.1).
|
||
|
||
3.2. Line Delimiting and Folding
|
||
|
||
Individual lines within vCard are delimited by the [RFC5322] line
|
||
break, which is a CRLF sequence (U+000D followed by U+000A). Long
|
||
logical lines of text can be split into a multiple-physical-line
|
||
representation using the following folding technique. Content lines
|
||
SHOULD be folded to a maximum width of 75 octets, excluding the line
|
||
break. Multi-octet characters MUST remain contiguous. The rationale
|
||
for this folding process can be found in [RFC5322], Section 2.1.1.
|
||
|
||
A logical line MAY be continued on the next physical line anywhere
|
||
between two characters by inserting a CRLF immediately followed by a
|
||
single white space character (space (U+0020) or horizontal tab
|
||
(U+0009)). The folded line MUST contain at least one character. Any
|
||
sequence of CRLF followed immediately by a single white space
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 5]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
character is ignored (removed) when processing the content type. For
|
||
example, the line:
|
||
|
||
NOTE:This is a long description that exists on a long line.
|
||
|
||
can be represented as:
|
||
|
||
NOTE:This is a long description
|
||
that exists on a long line.
|
||
|
||
It could also be represented as:
|
||
|
||
NOTE:This is a long descrip
|
||
tion that exists o
|
||
n a long line.
|
||
|
||
The process of moving from this folded multiple-line representation
|
||
of a property definition to its single-line representation is called
|
||
unfolding. Unfolding is accomplished by regarding CRLF immediately
|
||
followed by a white space character (namely, HTAB (U+0009) or SPACE
|
||
(U+0020)) as equivalent to no characters at all (i.e., the CRLF and
|
||
single white space character are removed).
|
||
|
||
Note: It is possible for very simple implementations to generate
|
||
improperly folded lines in the middle of a UTF-8 multi-octet
|
||
sequence. For this reason, implementations SHOULD unfold lines in
|
||
such a way as to properly restore the original sequence.
|
||
|
||
Note: Unfolding is done differently than in [RFC5322]. Unfolding
|
||
in [RFC5322] only removes the CRLF, not the space following it.
|
||
|
||
Folding is done after any content encoding of a type value.
|
||
Unfolding is done before any decoding of a type value in a content
|
||
line.
|
||
|
||
3.3. ABNF Format Definition
|
||
|
||
The following ABNF uses the notation of [RFC5234], which also defines
|
||
CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.
|
||
|
||
vcard-entity = 1*vcard
|
||
|
||
vcard = "BEGIN:VCARD" CRLF
|
||
"VERSION:4.0" CRLF
|
||
1*contentline
|
||
"END:VCARD" CRLF
|
||
; A vCard object MUST include the VERSION and FN properties.
|
||
; VERSION MUST come immediately after BEGIN:VCARD.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 6]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
contentline = [group "."] name *(";" param) ":" value CRLF
|
||
; When parsing a content line, folded lines must first
|
||
; be unfolded according to the unfolding procedure
|
||
; described in Section 3.2.
|
||
; When generating a content line, lines longer than 75
|
||
; characters SHOULD be folded according to the folding
|
||
; procedure described in Section 3.2.
|
||
|
||
group = 1*(ALPHA / DIGIT / "-")
|
||
name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME"
|
||
/ "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL"
|
||
/ "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE"
|
||
/ "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES"
|
||
/ "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP"
|
||
/ "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML"
|
||
/ iana-token / x-name
|
||
; Parsing of the param and value is based on the "name" as
|
||
; defined in ABNF sections below.
|
||
; Group and name are case-insensitive.
|
||
|
||
iana-token = 1*(ALPHA / DIGIT / "-")
|
||
; identifier registered with IANA
|
||
|
||
x-name = "x-" 1*(ALPHA / DIGIT / "-")
|
||
; Names that begin with "x-" or "X-" are
|
||
; reserved for experimental use, not intended for released
|
||
; products, or for use in bilateral agreements.
|
||
|
||
param = language-param / value-param / pref-param / pid-param
|
||
/ type-param / geo-parameter / tz-parameter / sort-as-param
|
||
/ calscale-param / any-param
|
||
; Allowed parameters depend on property name.
|
||
|
||
param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE
|
||
|
||
any-param = (iana-token / x-name) "=" param-value *("," param-value)
|
||
|
||
NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4
|
||
; UTF8-{2,3,4} are defined in [RFC3629]
|
||
|
||
QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
|
||
; Any character except CTLs, DQUOTE
|
||
|
||
SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
|
||
; Any character except CTLs, DQUOTE, ";", ":"
|
||
|
||
VALUE-CHAR = WSP / VCHAR / NON-ASCII
|
||
; Any textual character
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 7]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
A line that begins with a white space character is a continuation of
|
||
the previous line, as described in Section 3.2. The white space
|
||
character and immediately preceeding CRLF should be discarded when
|
||
reconstructing the original line. Note that this line-folding
|
||
convention differs from that found in [RFC5322], in that the sequence
|
||
<CRLF><WSP> found anywhere in the content indicates a continued line
|
||
and should be removed.
|
||
|
||
Property names and parameter names are case-insensitive (e.g., the
|
||
property name "fn" is the same as "FN" and "Fn"). Parameter values
|
||
MAY be case-sensitive or case-insensitive, depending on their
|
||
definition. Parameter values that are not explicitly defined as
|
||
being case-sensitive are case-insensitive. Based on experience with
|
||
vCard 3 interoperability, it is RECOMMENDED that property and
|
||
parameter names be upper-case on output.
|
||
|
||
The group construct is used to group related properties together.
|
||
The group name is a syntactic convention used to indicate that all
|
||
property names prefaced with the same group name SHOULD be grouped
|
||
together when displayed by an application. It has no other
|
||
significance. Implementations that do not understand or support
|
||
grouping MAY simply strip off any text before a "." to the left of
|
||
the type name and present the types and values as normal.
|
||
|
||
Property cardinalities are indicated using the following notation,
|
||
which is based on ABNF (see [RFC5234], Section 3.6):
|
||
|
||
+-------------+--------------------------------------------------+
|
||
| Cardinality | Meaning |
|
||
+-------------+--------------------------------------------------+
|
||
| 1 | Exactly one instance per vCard MUST be present. |
|
||
| *1 | Exactly one instance per vCard MAY be present. |
|
||
| 1* | One or more instances per vCard MUST be present. |
|
||
| * | One or more instances per vCard MAY be present. |
|
||
+-------------+--------------------------------------------------+
|
||
|
||
Properties defined in a vCard instance may have multiple values
|
||
depending on the property cardinality. The general rule for encoding
|
||
multi-valued properties is to simply create a new content line for
|
||
each value (including the property name). However, it should be
|
||
noted that some value types support encoding multiple values in a
|
||
single content line by separating the values with a comma ",". This
|
||
approach has been taken for several of the content types defined
|
||
below (date, time, integer, float).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 8]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
3.4. Property Value Escaping
|
||
|
||
Some properties may contain one or more values delimited by a COMMA
|
||
character (U+002C). Therefore, a COMMA character in a value MUST be
|
||
escaped with a BACKSLASH character (U+005C), even for properties that
|
||
don't allow multiple instances (for consistency).
|
||
|
||
Some properties (e.g., N and ADR) comprise multiple fields delimited
|
||
by a SEMICOLON character (U+003B). Therefore, a SEMICOLON in a field
|
||
of such a "compound" property MUST be escaped with a BACKSLASH
|
||
character. SEMICOLON characters in non-compound properties MAY be
|
||
escaped. On input, an escaped SEMICOLON character is never a field
|
||
separator. An unescaped SEMICOLON character may be a field
|
||
separator, depending on the property in which it appears.
|
||
|
||
Furthermore, some fields of compound properties may contain a list of
|
||
values delimited by a COMMA character. Therefore, a COMMA character
|
||
in one of a field's values MUST be escaped with a BACKSLASH
|
||
character, even for fields that don't allow multiple values (for
|
||
consistency). Compound properties allowing multiple instances MUST
|
||
NOT be encoded in a single content line.
|
||
|
||
Finally, BACKSLASH characters in values MUST be escaped with a
|
||
BACKSLASH character. NEWLINE (U+000A) characters in values MUST be
|
||
encoded by two characters: a BACKSLASH followed by either an 'n'
|
||
(U+006E) or an 'N' (U+004E).
|
||
|
||
In all other cases, escaping MUST NOT be used.
|
||
|
||
4. Property Value Data Types
|
||
|
||
Standard value types are defined below.
|
||
|
||
value = text
|
||
/ text-list
|
||
/ date-list
|
||
/ time-list
|
||
/ date-time-list
|
||
/ date-and-or-time-list
|
||
/ timestamp-list
|
||
/ boolean
|
||
/ integer-list
|
||
/ float-list
|
||
/ URI ; from Section 3 of [RFC3986]
|
||
/ utc-offset
|
||
/ Language-Tag
|
||
/ iana-valuespec
|
||
; Actual value type depends on property name and VALUE parameter.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 9]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
text = *TEXT-CHAR
|
||
|
||
TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
|
||
/ %x21-2B / %x2D-5B / %x5D-7E
|
||
; Backslashes, commas, and newlines must be encoded.
|
||
|
||
component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
|
||
/ %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
|
||
list-component = component *("," component)
|
||
|
||
text-list = text *("," text)
|
||
date-list = date *("," date)
|
||
time-list = time *("," time)
|
||
date-time-list = date-time *("," date-time)
|
||
date-and-or-time-list = date-and-or-time *("," date-and-or-time)
|
||
timestamp-list = timestamp *("," timestamp)
|
||
integer-list = integer *("," integer)
|
||
float-list = float *("," float)
|
||
|
||
boolean = "TRUE" / "FALSE"
|
||
integer = [sign] 1*DIGIT
|
||
float = [sign] 1*DIGIT ["." 1*DIGIT]
|
||
|
||
sign = "+" / "-"
|
||
|
||
year = 4DIGIT ; 0000-9999
|
||
month = 2DIGIT ; 01-12
|
||
day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year
|
||
hour = 2DIGIT ; 00-23
|
||
minute = 2DIGIT ; 00-59
|
||
second = 2DIGIT ; 00-58/59/60 depending on leap second
|
||
zone = utc-designator / utc-offset
|
||
utc-designator = %x5A ; uppercase "Z"
|
||
|
||
date = year [month day]
|
||
/ year "-" month
|
||
/ "--" month [day]
|
||
/ "--" "-" day
|
||
date-noreduc = year month day
|
||
/ "--" month day
|
||
/ "--" "-" day
|
||
date-complete = year month day
|
||
|
||
time = hour [minute [second]] [zone]
|
||
/ "-" minute [second] [zone]
|
||
/ "-" "-" second [zone]
|
||
time-notrunc = hour [minute [second]] [zone]
|
||
time-complete = hour minute second [zone]
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 10]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
time-designator = %x54 ; uppercase "T"
|
||
date-time = date-noreduc time-designator time-notrunc
|
||
timestamp = date-complete time-designator time-complete
|
||
|
||
date-and-or-time = date-time / date / time-designator time
|
||
|
||
utc-offset = sign hour [minute]
|
||
|
||
Language-Tag = <Language-Tag, defined in [RFC5646], Section 2.1>
|
||
|
||
iana-valuespec = <value-spec, see Section 12>
|
||
; a publicly defined valuetype format, registered
|
||
; with IANA, as defined in Section 12 of this
|
||
; document.
|
||
|
||
4.1. TEXT
|
||
|
||
"text": The "text" value type should be used to identify values that
|
||
contain human-readable text. As for the language, it is controlled
|
||
by the LANGUAGE property parameter defined in Section 5.1.
|
||
|
||
Examples for "text":
|
||
|
||
this is a text value
|
||
this is one value,this is another
|
||
this is a single value\, with a comma encoded
|
||
|
||
A formatted text line break in a text value type MUST be represented
|
||
as the character sequence backslash (U+005C) followed by a Latin
|
||
small letter n (U+006E) or a Latin capital letter N (U+004E), that
|
||
is, "\n" or "\N".
|
||
|
||
For example, a multiple line NOTE value of:
|
||
|
||
Mythical Manager
|
||
Hyjinx Software Division
|
||
BabsCo, Inc.
|
||
|
||
could be represented as:
|
||
|
||
NOTE:Mythical Manager\nHyjinx Software Division\n
|
||
BabsCo\, Inc.\n
|
||
|
||
demonstrating the \n literal formatted line break technique, the
|
||
CRLF-followed-by-space line folding technique, and the backslash
|
||
escape technique.
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 11]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
4.2. URI
|
||
|
||
"uri": The "uri" value type should be used to identify values that
|
||
are referenced by a Uniform Resource Identifier (URI) instead of
|
||
encoded in-line. These value references might be used if the value
|
||
is too large, or otherwise undesirable to include directly. The
|
||
format for the URI is as defined in Section 3 of [RFC3986]. Note
|
||
that the value of a property of type "uri" is what the URI points to,
|
||
not the URI itself.
|
||
|
||
Examples for "uri":
|
||
|
||
http://www.example.com/my/picture.jpg
|
||
ldap://ldap.example.com/cn=babs%20jensen
|
||
|
||
4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP
|
||
|
||
"date", "time", "date-time", "date-and-or-time", and "timestamp":
|
||
Each of these value types is based on the definitions in
|
||
[ISO.8601.2004]. Multiple such values can be specified using the
|
||
comma-separated notation.
|
||
|
||
Only the basic format is supported.
|
||
|
||
4.3.1. DATE
|
||
|
||
A calendar date as specified in [ISO.8601.2004], Section 4.1.2.
|
||
|
||
Reduced accuracy, as specified in [ISO.8601.2004], Sections 4.1.2.3
|
||
a) and b), but not c), is permitted.
|
||
|
||
Expanded representation, as specified in [ISO.8601.2004], Section
|
||
4.1.4, is forbidden.
|
||
|
||
Truncated representation, as specified in [ISO.8601.2000], Sections
|
||
5.2.1.3 d), e), and f), is permitted.
|
||
|
||
Examples for "date":
|
||
|
||
19850412
|
||
1985-04
|
||
1985
|
||
--0412
|
||
---12
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 12]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Note the use of YYYY-MM in the second example above. YYYYMM is
|
||
disallowed to prevent confusion with YYMMDD. Note also that
|
||
YYYY-MM-DD is disallowed since we are using the basic format instead
|
||
of the extended format.
|
||
|
||
4.3.2. TIME
|
||
|
||
A time of day as specified in [ISO.8601.2004], Section 4.2.
|
||
|
||
Reduced accuracy, as specified in [ISO.8601.2004], Section 4.2.2.3,
|
||
is permitted.
|
||
|
||
Representation with decimal fraction, as specified in
|
||
[ISO.8601.2004], Section 4.2.2.4, is forbidden.
|
||
|
||
The midnight hour is always represented by 00, never 24 (see
|
||
[ISO.8601.2004], Section 4.2.3).
|
||
|
||
Truncated representation, as specified in [ISO.8601.2000], Sections
|
||
5.3.1.4 a), b), and c), is permitted.
|
||
|
||
Examples for "time":
|
||
|
||
102200
|
||
1022
|
||
10
|
||
-2200
|
||
--00
|
||
102200Z
|
||
102200-0800
|
||
|
||
4.3.3. DATE-TIME
|
||
|
||
A date and time of day combination as specified in [ISO.8601.2004],
|
||
Section 4.3.
|
||
|
||
Truncation of the date part, as specified in [ISO.8601.2000], Section
|
||
5.4.2 c), is permitted.
|
||
|
||
Examples for "date-time":
|
||
|
||
19961022T140000
|
||
--1022T1400
|
||
---22T14
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 13]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
4.3.4. DATE-AND-OR-TIME
|
||
|
||
Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous
|
||
interpretation, a stand-alone TIME value is always preceded by a "T".
|
||
|
||
Examples for "date-and-or-time":
|
||
|
||
19961022T140000
|
||
--1022T1400
|
||
---22T14
|
||
19850412
|
||
1985-04
|
||
1985
|
||
--0412
|
||
---12
|
||
T102200
|
||
T1022
|
||
T10
|
||
T-2200
|
||
T--00
|
||
T102200Z
|
||
T102200-0800
|
||
|
||
4.3.5. TIMESTAMP
|
||
|
||
A complete date and time of day combination as specified in
|
||
[ISO.8601.2004], Section 4.3.2.
|
||
|
||
Examples for "timestamp":
|
||
|
||
19961022T140000
|
||
19961022T140000Z
|
||
19961022T140000-05
|
||
19961022T140000-0500
|
||
|
||
4.4. BOOLEAN
|
||
|
||
"boolean": The "boolean" value type is used to express boolean
|
||
values. These values are case-insensitive.
|
||
|
||
Examples:
|
||
|
||
TRUE
|
||
false
|
||
True
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 14]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
4.5. INTEGER
|
||
|
||
"integer": The "integer" value type is used to express signed
|
||
integers in decimal format. If sign is not specified, the value is
|
||
assumed positive "+". Multiple "integer" values can be specified
|
||
using the comma-separated notation. The maximum value is
|
||
9223372036854775807, and the minimum value is -9223372036854775808.
|
||
These limits correspond to a signed 64-bit integer using two's-
|
||
complement arithmetic.
|
||
|
||
Examples:
|
||
|
||
1234567890
|
||
-1234556790
|
||
+1234556790,432109876
|
||
|
||
4.6. FLOAT
|
||
|
||
"float": The "float" value type is used to express real numbers. If
|
||
sign is not specified, the value is assumed positive "+". Multiple
|
||
"float" values can be specified using the comma-separated notation.
|
||
Implementations MUST support a precision equal or better than that of
|
||
the IEEE "binary64" format [IEEE.754.2008].
|
||
|
||
Note: Scientific notation is disallowed. Implementers wishing to
|
||
use their favorite language's %f formatting should be careful.
|
||
|
||
Examples:
|
||
|
||
20.30
|
||
1000000.0000001
|
||
1.333,3.14
|
||
|
||
4.7. UTC-OFFSET
|
||
|
||
"utc-offset": The "utc-offset" value type specifies that the property
|
||
value is a signed offset from UTC. This value type can be specified
|
||
in the TZ property.
|
||
|
||
The value type is an offset from Coordinated Universal Time (UTC).
|
||
It is specified as a positive or negative difference in units of
|
||
hours and minutes (e.g., +hhmm). The time is specified as a 24-hour
|
||
clock. Hour values are from 00 to 23, and minute values are from 00
|
||
to 59. Hour and minutes are 2 digits with high-order zeroes required
|
||
to maintain digit count. The basic format for ISO 8601 UTC offsets
|
||
MUST be used.
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 15]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
4.8. LANGUAGE-TAG
|
||
|
||
"language-tag": A single language tag, as defined in [RFC5646].
|
||
|
||
5. Property Parameters
|
||
|
||
A property can have attributes associated with it. These "property
|
||
parameters" contain meta-information about the property or the
|
||
property value. In some cases, the property parameter can be multi-
|
||
valued in which case the property parameter value elements are
|
||
separated by a COMMA (U+002C).
|
||
|
||
Property parameter value elements that contain the COLON (U+003A),
|
||
SEMICOLON (U+003B), or COMMA (U+002C) character separators MUST be
|
||
specified as quoted-string text values. Property parameter values
|
||
MUST NOT contain the DQUOTE (U+0022) character. The DQUOTE character
|
||
is used as a delimiter for parameter values that contain restricted
|
||
characters or URI text.
|
||
|
||
Applications MUST ignore x-param and iana-param values they don't
|
||
recognize.
|
||
|
||
5.1. LANGUAGE
|
||
|
||
The LANGUAGE property parameter is used to identify data in multiple
|
||
languages. There is no concept of "default" language, except as
|
||
specified by any "Content-Language" MIME header parameter that is
|
||
present [RFC3282]. The value of the LANGUAGE property parameter is a
|
||
language tag as defined in Section 2 of [RFC5646].
|
||
|
||
Examples:
|
||
|
||
ROLE;LANGUAGE=tr:hoca
|
||
|
||
ABNF:
|
||
|
||
language-param = "LANGUAGE=" Language-Tag
|
||
; Language-Tag is defined in section 2.1 of RFC 5646
|
||
|
||
5.2. VALUE
|
||
|
||
The VALUE parameter is OPTIONAL, used to identify the value type
|
||
(data type) and format of the value. The use of these predefined
|
||
formats is encouraged even if the value parameter is not explicitly
|
||
used. By defining a standard set of value types and their formats,
|
||
existing parsing and processing code can be leveraged. The
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 16]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
predefined data type values MUST NOT be repeated in COMMA-separated
|
||
value lists except within the N, NICKNAME, ADR, and CATEGORIES
|
||
properties.
|
||
|
||
ABNF:
|
||
|
||
value-param = "VALUE=" value-type
|
||
|
||
value-type = "text"
|
||
/ "uri"
|
||
/ "date"
|
||
/ "time"
|
||
/ "date-time"
|
||
/ "date-and-or-time"
|
||
/ "timestamp"
|
||
/ "boolean"
|
||
/ "integer"
|
||
/ "float"
|
||
/ "utc-offset"
|
||
/ "language-tag"
|
||
/ iana-token ; registered as described in section 12
|
||
/ x-name
|
||
|
||
5.3. PREF
|
||
|
||
The PREF parameter is OPTIONAL and is used to indicate that the
|
||
corresponding instance of a property is preferred by the vCard
|
||
author. Its value MUST be an integer between 1 and 100 that
|
||
quantifies the level of preference. Lower values correspond to a
|
||
higher level of preference, with 1 being most preferred.
|
||
|
||
When the parameter is absent, the default MUST be to interpret the
|
||
property instance as being least preferred.
|
||
|
||
Note that the value of this parameter is to be interpreted only in
|
||
relation to values assigned to other instances of the same property
|
||
in the same vCard. A given value, or the absence of a value, MUST
|
||
NOT be interpreted on its own.
|
||
|
||
This parameter MAY be applied to any property that allows multiple
|
||
instances.
|
||
|
||
ABNF:
|
||
|
||
pref-param = "PREF=" (1*2DIGIT / "100")
|
||
; An integer between 1 and 100.
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 17]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
5.4. ALTID
|
||
|
||
The ALTID parameter is used to "tag" property instances as being
|
||
alternative representations of the same logical property. For
|
||
example, translations of a property in multiple languages generates
|
||
multiple property instances having different LANGUAGE (Section 5.1)
|
||
parameter that are tagged with the same ALTID value.
|
||
|
||
This parameter's value is treated as an opaque string. Its sole
|
||
purpose is to be compared for equality against other ALTID parameter
|
||
values.
|
||
|
||
Two property instances are considered alternative representations of
|
||
the same logical property if and only if their names as well as the
|
||
value of their ALTID parameters are identical. Property instances
|
||
without the ALTID parameter MUST NOT be considered an alternative
|
||
representation of any other property instance. Values for the ALTID
|
||
parameter are not globally unique: they MAY be reused for different
|
||
property names.
|
||
|
||
Property instances having the same ALTID parameter value count as 1
|
||
toward cardinality. Therefore, since N (Section 6.2.2) has
|
||
cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these
|
||
three examples would be legal:
|
||
|
||
N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
|
||
N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
|
||
(<U+XXXX> denotes a UTF8-encoded Unicode character.)
|
||
|
||
TITLE;ALTID=1;LANGUAGE=fr:Patron
|
||
TITLE;ALTID=1;LANGUAGE=en:Boss
|
||
|
||
TITLE;ALTID=1;LANGUAGE=fr:Patron
|
||
TITLE;ALTID=1;LANGUAGE=en:Boss
|
||
TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist
|
||
|
||
while this one would not:
|
||
|
||
N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
|
||
N:Yamada;Taro;;;
|
||
(Two instances of the N property.)
|
||
|
||
and these three would be legal but questionable:
|
||
|
||
TITLE;ALTID=1;LANGUAGE=fr:Patron
|
||
TITLE;ALTID=2;LANGUAGE=en:Boss
|
||
(Should probably have the same ALTID value.)
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 18]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
TITLE;ALTID=1;LANGUAGE=fr:Patron
|
||
TITLE:LANGUAGE=en:Boss
|
||
(Second line should probably have ALTID=1.)
|
||
|
||
N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
|
||
N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
|
||
N;ALTID=1;LANGUAGE=en:Smith;John;;;
|
||
(The last line should probably have ALTID=2. But that would be
|
||
illegal because N has cardinality *1.)
|
||
|
||
The ALTID property MAY also be used in may contexts other than with
|
||
the LANGUAGE parameter. Here's an example with two representations
|
||
of the same photo in different file formats:
|
||
|
||
PHOTO;ALTID=1:data:image/jpeg;base64,...
|
||
PHOTO;ALTID=1;data:image/jp2;base64,...
|
||
|
||
ABNF:
|
||
|
||
altid-param = "ALTID=" param-value
|
||
|
||
5.5. PID
|
||
|
||
The PID parameter is used to identify a specific property among
|
||
multiple instances. It plays a role analogous to the UID property
|
||
(Section 6.7.6) on a per-property instead of per-vCard basis. It MAY
|
||
appear more than once in a given property. It MUST NOT appear on
|
||
properties that may have only one instance per vCard. Its value is
|
||
either a single small positive integer or a pair of small positive
|
||
integers separated by a dot. Multiple values may be encoded in a
|
||
single PID parameter by separating the values with a comma ",". See
|
||
Section 7 for more details on its usage.
|
||
|
||
ABNF:
|
||
|
||
pid-param = "PID=" pid-value *("," pid-value)
|
||
pid-value = 1*DIGIT ["." 1*DIGIT]
|
||
|
||
5.6. TYPE
|
||
|
||
The TYPE parameter has multiple, different uses. In general, it is a
|
||
way of specifying class characteristics of the associated property.
|
||
Most of the time, its value is a comma-separated subset of a
|
||
predefined enumeration. In this document, the following properties
|
||
make use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL,
|
||
IMPP, LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES,
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 19]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
NOTE, SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE
|
||
parameter MUST NOT be applied on other properties defined in this
|
||
document.
|
||
|
||
The "work" and "home" values act like tags. The "work" value implies
|
||
that the property is related to an individual's work place, while the
|
||
"home" value implies that the property is related to an individual's
|
||
personal life. When neither "work" nor "home" is present, it is
|
||
implied that the property is related to both an individual's work
|
||
place and personal life in the case that the KIND property's value is
|
||
"individual", or to none in other cases.
|
||
|
||
ABNF:
|
||
|
||
type-param = "TYPE=" type-value *("," type-value)
|
||
|
||
type-value = "work" / "home" / type-param-tel
|
||
/ type-param-related / iana-token / x-name
|
||
; This is further defined in individual property sections.
|
||
|
||
5.7. MEDIATYPE
|
||
|
||
The MEDIATYPE parameter is used with properties whose value is a URI.
|
||
Its use is OPTIONAL. It provides a hint to the vCard consumer
|
||
application about the media type [RFC2046] of the resource identified
|
||
by the URI. Some URI schemes do not need this parameter. For
|
||
example, the "data" scheme allows the media type to be explicitly
|
||
indicated as part of the URI [RFC2397]. Another scheme, "http",
|
||
provides the media type as part of the URI resolution process, with
|
||
the Content-Type HTTP header [RFC2616]. The MEDIATYPE parameter is
|
||
intended to be used with URI schemes that do not provide such
|
||
functionality (e.g., "ftp" [RFC1738]).
|
||
|
||
ABNF:
|
||
|
||
mediatype-param = "MEDIATYPE=" mediatype
|
||
mediatype = type-name "/" subtype-name *( ";" attribute "=" value )
|
||
; "attribute" and "value" are from [RFC2045]
|
||
; "type-name" and "subtype-name" are from [RFC4288]
|
||
|
||
5.8. CALSCALE
|
||
|
||
The CALSCALE parameter is identical to the CALSCALE property in
|
||
iCalendar (see [RFC5545], Section 3.7.1). It is used to define the
|
||
calendar system in which a date or date-time value is expressed. The
|
||
only value specified by iCalendar is "gregorian", which stands for
|
||
the Gregorian system. It is the default when the parameter is
|
||
absent. Additional values may be defined in extension documents and
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 20]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
registered with IANA (see Section 10.3.4). A vCard implementation
|
||
MUST ignore properties with a CALSCALE parameter value that it does
|
||
not understand.
|
||
|
||
ABNF:
|
||
|
||
calscale-param = "CALSCALE=" calscale-value
|
||
|
||
calscale-value = "gregorian" / iana-token / x-name
|
||
|
||
5.9. SORT-AS
|
||
|
||
The "sort-as" parameter is used to specify the string to be used for
|
||
national-language-specific sorting. Without this information,
|
||
sorting algorithms could incorrectly sort this vCard within a
|
||
sequence of sorted vCards. When this property is present in a vCard,
|
||
then the given strings are used for sorting the vCard.
|
||
|
||
This parameter's value is a comma-separated list that MUST have as
|
||
many or fewer elements as the corresponding property value has
|
||
components. This parameter's value is case-sensitive.
|
||
|
||
ABNF:
|
||
|
||
sort-as-param = "SORT-AS=" sort-as-value
|
||
|
||
sort-as-value = param-value *("," param-value)
|
||
|
||
Examples: For the case of surname and given name sorting, the
|
||
following examples define common sort string usage with the N
|
||
property.
|
||
|
||
FN:Rene van der Harten
|
||
N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N.
|
||
|
||
FN:Robert Pau Shou Chang
|
||
N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;;
|
||
|
||
FN:Osamu Koura
|
||
N;SORT-AS="Koura,Osamu":Koura;Osamu;;
|
||
|
||
FN:Oscar del Pozo
|
||
N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;
|
||
|
||
FN:Chistine d'Aboville
|
||
N;SORT-AS="Aboville,Christine":d'Aboville;Christine;;
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 21]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
FN:H. James de Mann
|
||
N;SORT-AS="Mann,James":de Mann;Henry,James;;
|
||
|
||
If sorted by surname, the results would be:
|
||
|
||
Christine d'Aboville
|
||
Rene van der Harten
|
||
Osamu Koura
|
||
H. James de Mann
|
||
Robert Pau Shou Chang
|
||
Oscar del Pozo
|
||
|
||
If sorted by given name, the results would be:
|
||
|
||
Christine d'Aboville
|
||
H. James de Mann
|
||
Osamu Koura
|
||
Oscar del Pozo
|
||
Rene van der Harten
|
||
Robert Pau Shou Chang
|
||
|
||
5.10. GEO
|
||
|
||
The GEO parameter can be used to indicate global positioning
|
||
information that is specific to an address. Its value is the same as
|
||
that of the GEO property (see Section 6.5.2).
|
||
|
||
ABNF:
|
||
|
||
geo-parameter = "GEO=" DQUOTE URI DQUOTE
|
||
|
||
5.11. TZ
|
||
|
||
The TZ parameter can be used to indicate time zone information that
|
||
is specific to an address. Its value is the same as that of the TZ
|
||
property.
|
||
|
||
ABNF:
|
||
|
||
tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 22]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
6. vCard Properties
|
||
|
||
What follows is an enumeration of the standard vCard properties.
|
||
|
||
6.1. General Properties
|
||
|
||
6.1.1. BEGIN
|
||
|
||
Purpose: To denote the beginning of a syntactic entity within a
|
||
text/vcard content-type.
|
||
|
||
Value type: text
|
||
|
||
Cardinality: 1
|
||
|
||
Special notes: The content entity MUST begin with the BEGIN property
|
||
with a value of "VCARD". The value is case-insensitive.
|
||
|
||
The BEGIN property is used in conjunction with the END property to
|
||
delimit an entity containing a related set of properties within a
|
||
text/vcard content-type. This construct can be used instead of
|
||
including multiple vCards as body parts inside of a multipart/
|
||
alternative MIME message. It is provided for applications that
|
||
wish to define content that can contain multiple entities within
|
||
the same text/vcard content-type or to define content that can be
|
||
identifiable outside of a MIME environment.
|
||
|
||
ABNF:
|
||
|
||
BEGIN-param = 0" " ; no parameter allowed
|
||
BEGIN-value = "VCARD"
|
||
|
||
Example:
|
||
|
||
BEGIN:VCARD
|
||
|
||
6.1.2. END
|
||
|
||
Purpose: To denote the end of a syntactic entity within a text/vcard
|
||
content-type.
|
||
|
||
Value type: text
|
||
|
||
Cardinality: 1
|
||
|
||
Special notes: The content entity MUST end with the END type with a
|
||
value of "VCARD". The value is case-insensitive.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 23]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
The END property is used in conjunction with the BEGIN property to
|
||
delimit an entity containing a related set of properties within a
|
||
text/vcard content-type. This construct can be used instead of or
|
||
in addition to wrapping separate sets of information inside
|
||
additional MIME headers. It is provided for applications that
|
||
wish to define content that can contain multiple entities within
|
||
the same text/vcard content-type or to define content that can be
|
||
identifiable outside of a MIME environment.
|
||
|
||
ABNF:
|
||
|
||
END-param = 0" " ; no parameter allowed
|
||
END-value = "VCARD"
|
||
|
||
Example:
|
||
|
||
END:VCARD
|
||
|
||
6.1.3. SOURCE
|
||
|
||
Purpose: To identify the source of directory information contained
|
||
in the content type.
|
||
|
||
Value type: uri
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The SOURCE property is used to provide the means by
|
||
which applications knowledgable in the given directory service
|
||
protocol can obtain additional or more up-to-date information from
|
||
the directory service. It contains a URI as defined in [RFC3986]
|
||
and/or other information referencing the vCard to which the
|
||
information pertains. When directory information is available
|
||
from more than one source, the sending entity can pick what it
|
||
considers to be the best source, or multiple SOURCE properties can
|
||
be included.
|
||
|
||
ABNF:
|
||
|
||
SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param
|
||
/ mediatype-param / any-param
|
||
SOURCE-value = URI
|
||
|
||
Examples:
|
||
|
||
SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 24]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
SOURCE:http://directory.example.com/addressbooks/jdoe/
|
||
Jean%20Dupont.vcf
|
||
|
||
6.1.4. KIND
|
||
|
||
Purpose: To specify the kind of object the vCard represents.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: *1
|
||
|
||
Special notes: The value may be one of the following:
|
||
|
||
"individual" for a vCard representing a single person or entity.
|
||
This is the default kind of vCard.
|
||
|
||
"group" for a vCard representing a group of persons or entities.
|
||
The group's member entities can be other vCards or other types
|
||
of entities, such as email addresses or web sites. A group
|
||
vCard will usually contain MEMBER properties to specify the
|
||
members of the group, but it is not required to. A group vCard
|
||
without MEMBER properties can be considered an abstract
|
||
grouping, or one whose members are known empirically (perhaps
|
||
"IETF Participants" or "Republican U.S. Senators").
|
||
|
||
All properties in a group vCard apply to the group as a whole,
|
||
and not to any particular MEMBER. For example, an EMAIL
|
||
property might specify the address of a mailing list associated
|
||
with the group, and an IMPP property might refer to a group
|
||
chat room.
|
||
|
||
"org" for a vCard representing an organization. An organization
|
||
vCard will not (in fact, MUST NOT) contain MEMBER properties,
|
||
and so these are something of a cross between "individual" and
|
||
"group". An organization is a single entity, but not a person.
|
||
It might represent a business or government, a department or
|
||
division within a business or government, a club, an
|
||
association, or the like.
|
||
|
||
All properties in an organization vCard apply to the
|
||
organization as a whole, as is the case with a group vCard.
|
||
For example, an EMAIL property might specify the address of a
|
||
contact point for the organization.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 25]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
"location" for a named geographical place. A location vCard will
|
||
usually contain a GEO property, but it is not required to. A
|
||
location vCard without a GEO property can be considered an
|
||
abstract location, or one whose definition is known empirically
|
||
(perhaps "New England" or "The Seashore").
|
||
|
||
All properties in a location vCard apply to the location
|
||
itself, and not with any entity that might exist at that
|
||
location. For example, in a vCard for an office building, an
|
||
ADR property might give the mailing address for the building,
|
||
and a TEL property might specify the telephone number of the
|
||
receptionist.
|
||
|
||
An x-name. vCards MAY include private or experimental values for
|
||
KIND. Remember that x-name values are not intended for general
|
||
use and are unlikely to interoperate.
|
||
|
||
An iana-token. Additional values may be registered with IANA (see
|
||
Section 10.3.4). A new value's specification document MUST
|
||
specify which properties make sense for that new kind of vCard
|
||
and which do not.
|
||
|
||
Implementations MUST support the specific string values defined
|
||
above. If this property is absent, "individual" MUST be assumed
|
||
as the default. If this property is present but the
|
||
implementation does not understand its value (the value is an
|
||
x-name or iana-token that the implementation does not support),
|
||
the implementation SHOULD act in a neutral way, which usually
|
||
means treating the vCard as though its kind were "individual".
|
||
The presence of MEMBER properties MAY, however, be taken as an
|
||
indication that the unknown kind is an extension of "group".
|
||
|
||
Clients often need to visually distinguish contacts based on what
|
||
they represent, and the KIND property provides a direct way for
|
||
them to do so. For example, when displaying contacts in a list,
|
||
an icon could be displayed next to each one, using distinctive
|
||
icons for the different kinds; a client might use an outline of a
|
||
single person to represent an "individual", an outline of multiple
|
||
people to represent a "group", and so on. Alternatively, or in
|
||
addition, a client might choose to segregate different kinds of
|
||
vCards to different panes, tabs, or selections in the user
|
||
interface.
|
||
|
||
Some clients might also make functional distinctions among the
|
||
kinds, ignoring "location" vCards for some purposes and
|
||
considering only "location" vCards for others.
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 26]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
When designing those sorts of visual and functional distinctions,
|
||
client implementations have to decide how to fit unsupported kinds
|
||
into the scheme. What icon is used for them? The one for
|
||
"individual"? A unique one, such as an icon of a question mark?
|
||
Which tab do they go into? It is beyond the scope of this
|
||
specification to answer these questions, but these are things
|
||
implementers need to consider.
|
||
|
||
ABNF:
|
||
|
||
KIND-param = "VALUE=text" / any-param
|
||
KIND-value = "individual" / "group" / "org" / "location"
|
||
/ iana-token / x-name
|
||
|
||
Example:
|
||
|
||
This represents someone named Jane Doe working in the marketing
|
||
department of the North American division of ABC Inc.
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
KIND:individual
|
||
FN:Jane Doe
|
||
ORG:ABC\, Inc.;North American Division;Marketing
|
||
END:VCARD
|
||
|
||
This represents the department itself, commonly known as ABC
|
||
Marketing.
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
KIND:org
|
||
FN:ABC Marketing
|
||
ORG:ABC\, Inc.;North American Division;Marketing
|
||
END:VCARD
|
||
|
||
6.1.5. XML
|
||
|
||
Purpose: To include extended XML-encoded vCard data in a plain
|
||
vCard.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The content of this property is a single XML 1.0
|
||
[W3C.REC-xml-20081126] element whose namespace MUST be explicitly
|
||
specified using the xmlns attribute and MUST NOT be the vCard 4
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 27]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies
|
||
that it cannot duplicate a standard vCard property.) The element
|
||
is to be interpreted as if it was contained in a <vcard> element,
|
||
as defined in [RFC6351].
|
||
|
||
The fragment is subject to normal line folding and escaping, i.e.,
|
||
replace all backslashes with "\\", then replace all newlines with
|
||
"\n", then fold long lines.
|
||
|
||
Support for this property is OPTIONAL, but implementations of this
|
||
specification MUST preserve instances of this property when
|
||
propagating vCards.
|
||
|
||
See [RFC6351] for more information on the intended use of this
|
||
property.
|
||
|
||
ABNF:
|
||
|
||
XML-param = "VALUE=text" / altid-param
|
||
XML-value = text
|
||
|
||
6.2. Identification Properties
|
||
|
||
These types are used to capture information associated with the
|
||
identification and naming of the entity associated with the vCard.
|
||
|
||
6.2.1. FN
|
||
|
||
Purpose: To specify the formatted text corresponding to the name of
|
||
the object the vCard represents.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: 1*
|
||
|
||
Special notes: This property is based on the semantics of the X.520
|
||
Common Name attribute [CCITT.X520.1988]. The property MUST be
|
||
present in the vCard object.
|
||
|
||
ABNF:
|
||
|
||
FN-param = "VALUE=text" / type-param / language-param / altid-param
|
||
/ pid-param / pref-param / any-param
|
||
FN-value = text
|
||
|
||
Example:
|
||
|
||
FN:Mr. John Q. Public\, Esq.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 28]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
6.2.2. N
|
||
|
||
Purpose: To specify the components of the name of the object the
|
||
vCard represents.
|
||
|
||
Value type: A single structured text value. Each component can have
|
||
multiple values.
|
||
|
||
Cardinality: *1
|
||
|
||
Special note: The structured property value corresponds, in
|
||
sequence, to the Family Names (also known as surnames), Given
|
||
Names, Additional Names, Honorific Prefixes, and Honorific
|
||
Suffixes. The text components are separated by the SEMICOLON
|
||
character (U+003B). Individual text components can include
|
||
multiple text values separated by the COMMA character (U+002C).
|
||
This property is based on the semantics of the X.520 individual
|
||
name attributes [CCITT.X520.1988]. The property SHOULD be present
|
||
in the vCard object when the name of the object the vCard
|
||
represents follows the X.520 model.
|
||
|
||
The SORT-AS parameter MAY be applied to this property.
|
||
|
||
ABNF:
|
||
|
||
N-param = "VALUE=text" / sort-as-param / language-param
|
||
/ altid-param / any-param
|
||
N-value = list-component 4(";" list-component)
|
||
|
||
Examples:
|
||
|
||
N:Public;John;Quinlan;Mr.;Esq.
|
||
|
||
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
|
||
|
||
6.2.3. NICKNAME
|
||
|
||
Purpose: To specify the text corresponding to the nickname of the
|
||
object the vCard represents.
|
||
|
||
Value type: One or more text values separated by a COMMA character
|
||
(U+002C).
|
||
|
||
Cardinality: *
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 29]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Special note: The nickname is the descriptive name given instead of
|
||
or in addition to the one belonging to the object the vCard
|
||
represents. It can also be used to specify a familiar form of a
|
||
proper name specified by the FN or N properties.
|
||
|
||
ABNF:
|
||
|
||
NICKNAME-param = "VALUE=text" / type-param / language-param
|
||
/ altid-param / pid-param / pref-param / any-param
|
||
NICKNAME-value = text-list
|
||
|
||
Examples:
|
||
|
||
NICKNAME:Robbie
|
||
|
||
NICKNAME:Jim,Jimmie
|
||
|
||
NICKNAME;TYPE=work:Boss
|
||
|
||
6.2.4. PHOTO
|
||
|
||
Purpose: To specify an image or photograph information that
|
||
annotates some aspect of the object the vCard represents.
|
||
|
||
Value type: A single URI.
|
||
|
||
Cardinality: *
|
||
|
||
ABNF:
|
||
|
||
PHOTO-param = "VALUE=uri" / altid-param / type-param
|
||
/ mediatype-param / pref-param / pid-param / any-param
|
||
PHOTO-value = URI
|
||
|
||
Examples:
|
||
|
||
PHOTO:http://www.example.com/pub/photos/jqpublic.gif
|
||
|
||
PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv
|
||
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
|
||
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
|
||
<...remainder of base64-encoded data...>
|
||
|
||
6.2.5. BDAY
|
||
|
||
Purpose: To specify the birth date of the object the vCard
|
||
represents.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 30]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Value type: The default is a single date-and-or-time value. It can
|
||
also be reset to a single text value.
|
||
|
||
Cardinality: *1
|
||
|
||
ABNF:
|
||
|
||
BDAY-param = BDAY-param-date / BDAY-param-text
|
||
BDAY-value = date-and-or-time / text
|
||
; Value and parameter MUST match.
|
||
|
||
BDAY-param-date = "VALUE=date-and-or-time"
|
||
BDAY-param-text = "VALUE=text" / language-param
|
||
|
||
BDAY-param =/ altid-param / calscale-param / any-param
|
||
; calscale-param can only be present when BDAY-value is
|
||
; date-and-or-time and actually contains a date or date-time.
|
||
|
||
Examples:
|
||
|
||
BDAY:19960415
|
||
BDAY:--0415
|
||
BDAY;19531015T231000Z
|
||
BDAY;VALUE=text:circa 1800
|
||
|
||
6.2.6. ANNIVERSARY
|
||
|
||
Purpose: The date of marriage, or equivalent, of the object the
|
||
vCard represents.
|
||
|
||
Value type: The default is a single date-and-or-time value. It can
|
||
also be reset to a single text value.
|
||
|
||
Cardinality: *1
|
||
|
||
ABNF:
|
||
|
||
ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text")
|
||
ANNIVERSARY-value = date-and-or-time / text
|
||
; Value and parameter MUST match.
|
||
|
||
ANNIVERSARY-param =/ altid-param / calscale-param / any-param
|
||
; calscale-param can only be present when ANNIVERSARY-value is
|
||
; date-and-or-time and actually contains a date or date-time.
|
||
|
||
Examples:
|
||
|
||
ANNIVERSARY:19960415
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 31]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
6.2.7. GENDER
|
||
|
||
Purpose: To specify the components of the sex and gender identity of
|
||
the object the vCard represents.
|
||
|
||
Value type: A single structured value with two components. Each
|
||
component has a single text value.
|
||
|
||
Cardinality: *1
|
||
|
||
Special notes: The components correspond, in sequence, to the sex
|
||
(biological), and gender identity. Each component is optional.
|
||
|
||
Sex component: A single letter. M stands for "male", F stands
|
||
for "female", O stands for "other", N stands for "none or not
|
||
applicable", U stands for "unknown".
|
||
|
||
Gender identity component: Free-form text.
|
||
|
||
ABNF:
|
||
|
||
GENDER-param = "VALUE=text" / any-param
|
||
GENDER-value = sex [";" text]
|
||
|
||
sex = "" / "M" / "F" / "O" / "N" / "U"
|
||
|
||
Examples:
|
||
|
||
GENDER:M
|
||
GENDER:F
|
||
GENDER:M;Fellow
|
||
GENDER:F;grrrl
|
||
GENDER:O;intersex
|
||
GENDER:;it's complicated
|
||
|
||
6.3. Delivery Addressing Properties
|
||
|
||
These types are concerned with information related to the delivery
|
||
addressing or label for the vCard object.
|
||
|
||
6.3.1. ADR
|
||
|
||
Purpose: To specify the components of the delivery address for the
|
||
vCard object.
|
||
|
||
Value type: A single structured text value, separated by the
|
||
SEMICOLON character (U+003B).
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 32]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The structured type value consists of a sequence of
|
||
address components. The component values MUST be specified in
|
||
their corresponding position. The structured type value
|
||
corresponds, in sequence, to
|
||
the post office box;
|
||
the extended address (e.g., apartment or suite number);
|
||
the street address;
|
||
the locality (e.g., city);
|
||
the region (e.g., state or province);
|
||
the postal code;
|
||
the country name (full name in the language specified in
|
||
Section 5.1).
|
||
|
||
When a component value is missing, the associated component
|
||
separator MUST still be specified.
|
||
|
||
Experience with vCard 3 has shown that the first two components
|
||
(post office box and extended address) are plagued with many
|
||
interoperability issues. To ensure maximal interoperability,
|
||
their values SHOULD be empty.
|
||
|
||
The text components are separated by the SEMICOLON character
|
||
(U+003B). Where it makes semantic sense, individual text
|
||
components can include multiple text values (e.g., a "street"
|
||
component with multiple lines) separated by the COMMA character
|
||
(U+002C).
|
||
|
||
The property can include the "PREF" parameter to indicate the
|
||
preferred delivery address when more than one address is
|
||
specified.
|
||
|
||
The GEO and TZ parameters MAY be used with this property.
|
||
|
||
The property can also include a "LABEL" parameter to present a
|
||
delivery address label for the address. Its value is a plain-text
|
||
string representing the formatted address. Newlines are encoded
|
||
as \n, as they are for property values.
|
||
|
||
ABNF:
|
||
|
||
label-param = "LABEL=" param-value
|
||
|
||
ADR-param = "VALUE=text" / label-param / language-param
|
||
/ geo-parameter / tz-parameter / altid-param / pid-param
|
||
/ pref-param / type-param / any-param
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 33]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
|
||
ADR-component-street ";" ADR-component-locality ";"
|
||
ADR-component-region ";" ADR-component-code ";"
|
||
ADR-component-country
|
||
ADR-component-pobox = list-component
|
||
ADR-component-ext = list-component
|
||
ADR-component-street = list-component
|
||
ADR-component-locality = list-component
|
||
ADR-component-region = list-component
|
||
ADR-component-code = list-component
|
||
ADR-component-country = list-component
|
||
|
||
Example: In this example, the post office box and the extended
|
||
address are absent.
|
||
|
||
ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
|
||
Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
|
||
U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
|
||
|
||
6.4. Communications Properties
|
||
|
||
These properties describe information about how to communicate with
|
||
the object the vCard represents.
|
||
|
||
6.4.1. TEL
|
||
|
||
Purpose: To specify the telephone number for telephony communication
|
||
with the object the vCard represents.
|
||
|
||
Value type: By default, it is a single free-form text value (for
|
||
backward compatibility with vCard 3), but it SHOULD be reset to a
|
||
URI value. It is expected that the URI scheme will be "tel", as
|
||
specified in [RFC3966], but other schemes MAY be used.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: This property is based on the X.520 Telephone Number
|
||
attribute [CCITT.X520.1988].
|
||
|
||
The property can include the "PREF" parameter to indicate a
|
||
preferred-use telephone number.
|
||
|
||
The property can include the parameter "TYPE" to specify intended
|
||
use for the telephone number. The predefined values for the TYPE
|
||
parameter are:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 34]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
+-----------+-------------------------------------------------------+
|
||
| Value | Description |
|
||
+-----------+-------------------------------------------------------+
|
||
| text | Indicates that the telephone number supports text |
|
||
| | messages (SMS). |
|
||
| voice | Indicates a voice telephone number. |
|
||
| fax | Indicates a facsimile telephone number. |
|
||
| cell | Indicates a cellular or mobile telephone number. |
|
||
| video | Indicates a video conferencing telephone number. |
|
||
| pager | Indicates a paging device telephone number. |
|
||
| textphone | Indicates a telecommunication device for people with |
|
||
| | hearing or speech difficulties. |
|
||
+-----------+-------------------------------------------------------+
|
||
|
||
The default type is "voice". These type parameter values can be
|
||
specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
|
||
value list (e.g., TYPE="text,voice"). The default can be
|
||
overridden to another set of values by specifying one or more
|
||
alternate values. For example, the default TYPE of "voice" can be
|
||
reset to a VOICE and FAX telephone number by the value list
|
||
TYPE="voice,fax".
|
||
|
||
If this property's value is a URI that can also be used for
|
||
instant messaging, the IMPP (Section 6.4.3) property SHOULD be
|
||
used in addition to this property.
|
||
|
||
ABNF:
|
||
|
||
TEL-param = TEL-text-param / TEL-uri-param
|
||
TEL-value = TEL-text-value / TEL-uri-value
|
||
; Value and parameter MUST match.
|
||
|
||
TEL-text-param = "VALUE=text"
|
||
TEL-text-value = text
|
||
|
||
TEL-uri-param = "VALUE=uri" / mediatype-param
|
||
TEL-uri-value = URI
|
||
|
||
TEL-param =/ type-param / pid-param / pref-param / altid-param
|
||
/ any-param
|
||
|
||
type-param-tel = "text" / "voice" / "fax" / "cell" / "video"
|
||
/ "pager" / "textphone" / iana-token / x-name
|
||
; type-param-tel MUST NOT be used with a property other than TEL.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 35]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Example:
|
||
|
||
TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
|
||
TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67
|
||
|
||
6.4.2. EMAIL
|
||
|
||
Purpose: To specify the electronic mail address for communication
|
||
with the object the vCard represents.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The property can include tye "PREF" parameter to
|
||
indicate a preferred-use email address when more than one is
|
||
specified.
|
||
|
||
Even though the value is free-form UTF-8 text, it is likely to be
|
||
interpreted by a Mail User Agent (MUA) as an "addr-spec", as
|
||
defined in [RFC5322], Section 3.4.1. Readers should also be aware
|
||
of the current work toward internationalized email addresses
|
||
[RFC5335bis].
|
||
|
||
ABNF:
|
||
|
||
EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param
|
||
/ altid-param / any-param
|
||
EMAIL-value = text
|
||
|
||
Example:
|
||
|
||
EMAIL;TYPE=work:jqpublic@xyz.example.com
|
||
|
||
EMAIL;PREF=1:jane_doe@example.com
|
||
|
||
6.4.3. IMPP
|
||
|
||
Purpose: To specify the URI for instant messaging and presence
|
||
protocol communications with the object the vCard represents.
|
||
|
||
Value type: A single URI.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The property may include the "PREF" parameter to
|
||
indicate that this is a preferred address and has the same
|
||
semantics as the "PREF" parameter in a TEL property.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 36]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
If this property's value is a URI that can be used for voice
|
||
and/or video, the TEL property (Section 6.4.1) SHOULD be used in
|
||
addition to this property.
|
||
|
||
This property is adapted from [RFC4770], which is made obsolete by
|
||
this document.
|
||
|
||
ABNF:
|
||
|
||
IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param
|
||
/ mediatype-param / altid-param / any-param
|
||
IMPP-value = URI
|
||
|
||
Example:
|
||
|
||
IMPP;PREF=1:xmpp:alice@example.com
|
||
|
||
6.4.4. LANG
|
||
|
||
Purpose: To specify the language(s) that may be used for contacting
|
||
the entity associated with the vCard.
|
||
|
||
Value type: A single language-tag value.
|
||
|
||
Cardinality: *
|
||
|
||
ABNF:
|
||
|
||
LANG-param = "VALUE=language-tag" / pid-param / pref-param
|
||
/ altid-param / type-param / any-param
|
||
LANG-value = Language-Tag
|
||
|
||
Example:
|
||
|
||
LANG;TYPE=work;PREF=1:en
|
||
LANG;TYPE=work;PREF=2:fr
|
||
LANG;TYPE=home:fr
|
||
|
||
6.5. Geographical Properties
|
||
|
||
These properties are concerned with information associated with
|
||
geographical positions or regions associated with the object the
|
||
vCard represents.
|
||
|
||
6.5.1. TZ
|
||
|
||
Purpose: To specify information related to the time zone of the
|
||
object the vCard represents.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 37]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Value type: The default is a single text value. It can also be
|
||
reset to a single URI or utc-offset value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: It is expected that names from the public-domain
|
||
Olson database [TZ-DB] will be used, but this is not a
|
||
restriction. See also [IANA-TZ].
|
||
|
||
Efforts are currently being directed at creating a standard URI
|
||
scheme for expressing time zone information. Usage of such a
|
||
scheme would ensure a high level of interoperability between
|
||
implementations that support it.
|
||
|
||
Note that utc-offset values SHOULD NOT be used because the UTC
|
||
offset varies with time -- not just because of the usual daylight
|
||
saving time shifts that occur in may regions, but often entire
|
||
regions will "re-base" their overall offset. The actual offset
|
||
may be +/- 1 hour (or perhaps a little more) than the one given.
|
||
|
||
ABNF:
|
||
|
||
TZ-param = "VALUE=" ("text" / "uri" / "utc-offset")
|
||
TZ-value = text / URI / utc-offset
|
||
; Value and parameter MUST match.
|
||
|
||
TZ-param =/ altid-param / pid-param / pref-param / type-param
|
||
/ mediatype-param / any-param
|
||
|
||
Examples:
|
||
|
||
TZ:Raleigh/North America
|
||
|
||
TZ;VALUE=utc-offset:-0500
|
||
; Note: utc-offset format is NOT RECOMMENDED.
|
||
|
||
6.5.2. GEO
|
||
|
||
Purpose: To specify information related to the global positioning of
|
||
the object the vCard represents.
|
||
|
||
Value type: A single URI.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The "geo" URI scheme [RFC5870] is particularly well
|
||
suited for this property, but other schemes MAY be used.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 38]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
ABNF:
|
||
|
||
GEO-param = "VALUE=uri" / pid-param / pref-param / type-param
|
||
/ mediatype-param / altid-param / any-param
|
||
GEO-value = URI
|
||
|
||
Example:
|
||
|
||
GEO:geo:37.386013,-122.082932
|
||
|
||
6.6. Organizational Properties
|
||
|
||
These properties are concerned with information associated with
|
||
characteristics of the organization or organizational units of the
|
||
object that the vCard represents.
|
||
|
||
6.6.1. TITLE
|
||
|
||
Purpose: To specify the position or job of the object the vCard
|
||
represents.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: This property is based on the X.520 Title attribute
|
||
[CCITT.X520.1988].
|
||
|
||
ABNF:
|
||
|
||
TITLE-param = "VALUE=text" / language-param / pid-param
|
||
/ pref-param / altid-param / type-param / any-param
|
||
TITLE-value = text
|
||
|
||
Example:
|
||
|
||
TITLE:Research Scientist
|
||
|
||
6.6.2. ROLE
|
||
|
||
Purpose: To specify the function or part played in a particular
|
||
situation by the object the vCard represents.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: *
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 39]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Special notes: This property is based on the X.520 Business Category
|
||
explanatory attribute [CCITT.X520.1988]. This property is
|
||
included as an organizational type to avoid confusion with the
|
||
semantics of the TITLE property and incorrect usage of that
|
||
property when the semantics of this property is intended.
|
||
|
||
ABNF:
|
||
|
||
ROLE-param = "VALUE=text" / language-param / pid-param / pref-param
|
||
/ type-param / altid-param / any-param
|
||
ROLE-value = text
|
||
|
||
Example:
|
||
|
||
ROLE:Project Leader
|
||
|
||
6.6.3. LOGO
|
||
|
||
Purpose: To specify a graphic image of a logo associated with the
|
||
object the vCard represents.
|
||
|
||
Value type: A single URI.
|
||
|
||
Cardinality: *
|
||
|
||
ABNF:
|
||
|
||
LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param
|
||
/ type-param / mediatype-param / altid-param / any-param
|
||
LOGO-value = URI
|
||
|
||
Examples:
|
||
|
||
LOGO:http://www.example.com/pub/logos/abccorp.jpg
|
||
|
||
LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc
|
||
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
|
||
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
|
||
<...the remainder of base64-encoded data...>
|
||
|
||
6.6.4. ORG
|
||
|
||
Purpose: To specify the organizational name and units associated
|
||
with the vCard.
|
||
|
||
Value type: A single structured text value consisting of components
|
||
separated by the SEMICOLON character (U+003B).
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 40]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The property is based on the X.520 Organization Name
|
||
and Organization Unit attributes [CCITT.X520.1988]. The property
|
||
value is a structured type consisting of the organization name,
|
||
followed by zero or more levels of organizational unit names.
|
||
|
||
The SORT-AS parameter MAY be applied to this property.
|
||
|
||
ABNF:
|
||
|
||
ORG-param = "VALUE=text" / sort-as-param / language-param
|
||
/ pid-param / pref-param / altid-param / type-param
|
||
/ any-param
|
||
ORG-value = component *(";" component)
|
||
|
||
Example: A property value consisting of an organizational name,
|
||
organizational unit #1 name, and organizational unit #2 name.
|
||
|
||
ORG:ABC\, Inc.;North American Division;Marketing
|
||
|
||
6.6.5. MEMBER
|
||
|
||
Purpose: To include a member in the group this vCard represents.
|
||
|
||
Value type: A single URI. It MAY refer to something other than a
|
||
vCard object. For example, an email distribution list could
|
||
employ the "mailto" URI scheme [RFC6068] for efficiency.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: This property MUST NOT be present unless the value of
|
||
the KIND property is "group".
|
||
|
||
ABNF:
|
||
|
||
MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param
|
||
/ mediatype-param / any-param
|
||
MEMBER-value = URI
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 41]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Examples:
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
KIND:group
|
||
FN:The Doe family
|
||
MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
|
||
MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
|
||
END:VCARD
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
FN:John Doe
|
||
UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
|
||
END:VCARD
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
FN:Jane Doe
|
||
UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
|
||
END:VCARD
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
KIND:group
|
||
FN:Funky distribution list
|
||
MEMBER:mailto:subscriber1@example.com
|
||
MEMBER:xmpp:subscriber2@example.com
|
||
MEMBER:sip:subscriber3@example.com
|
||
MEMBER:tel:+1-418-555-5555
|
||
END:VCARD
|
||
|
||
6.6.6. RELATED
|
||
|
||
Purpose: To specify a relationship between another entity and the
|
||
entity represented by this vCard.
|
||
|
||
Value type: A single URI. It can also be reset to a single text
|
||
value. The text value can be used to specify textual information.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The TYPE parameter MAY be used to characterize the
|
||
related entity. It contains a comma-separated list of values that
|
||
are registered with IANA as described in Section 10.2. The
|
||
registry is pre-populated with the values defined in [xfn]. This
|
||
document also specifies two additional values:
|
||
|
||
agent: an entity who may sometimes act on behalf of the entity
|
||
associated with the vCard.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 42]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
emergency: indicates an emergency contact
|
||
|
||
ABNF:
|
||
|
||
RELATED-param = RELATED-param-uri / RELATED-param-text
|
||
RELATED-value = URI / text
|
||
; Parameter and value MUST match.
|
||
|
||
RELATED-param-uri = "VALUE=uri" / mediatype-param
|
||
RELATED-param-text = "VALUE=text" / language-param
|
||
|
||
RELATED-param =/ pid-param / pref-param / altid-param / type-param
|
||
/ any-param
|
||
|
||
type-param-related = related-type-value *("," related-type-value)
|
||
; type-param-related MUST NOT be used with a property other than
|
||
; RELATED.
|
||
|
||
related-type-value = "contact" / "acquaintance" / "friend" / "met"
|
||
/ "co-worker" / "colleague" / "co-resident"
|
||
/ "neighbor" / "child" / "parent"
|
||
/ "sibling" / "spouse" / "kin" / "muse"
|
||
/ "crush" / "date" / "sweetheart" / "me"
|
||
/ "agent" / "emergency"
|
||
|
||
Examples:
|
||
|
||
RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
|
||
RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf
|
||
RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane
|
||
Doe for any inquiries.
|
||
|
||
6.7. Explanatory Properties
|
||
|
||
These properties are concerned with additional explanations, such as
|
||
that related to informational notes or revisions specific to the
|
||
vCard.
|
||
|
||
6.7.1. CATEGORIES
|
||
|
||
Purpose: To specify application category information about the
|
||
vCard, also known as "tags".
|
||
|
||
Value type: One or more text values separated by a COMMA character
|
||
(U+002C).
|
||
|
||
Cardinality: *
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 43]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
ABNF:
|
||
|
||
CATEGORIES-param = "VALUE=text" / pid-param / pref-param
|
||
/ type-param / altid-param / any-param
|
||
CATEGORIES-value = text-list
|
||
|
||
Example:
|
||
|
||
CATEGORIES:TRAVEL AGENT
|
||
|
||
CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
|
||
|
||
6.7.2. NOTE
|
||
|
||
Purpose: To specify supplemental information or a comment that is
|
||
associated with the vCard.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: The property is based on the X.520 Description
|
||
attribute [CCITT.X520.1988].
|
||
|
||
ABNF:
|
||
|
||
NOTE-param = "VALUE=text" / language-param / pid-param / pref-param
|
||
/ type-param / altid-param / any-param
|
||
NOTE-value = text
|
||
|
||
Example:
|
||
|
||
NOTE:This fax number is operational 0800 to 1715
|
||
EST\, Mon-Fri.
|
||
|
||
6.7.3. PRODID
|
||
|
||
Purpose: To specify the identifier for the product that created the
|
||
vCard object.
|
||
|
||
Type value: A single text value.
|
||
|
||
Cardinality: *1
|
||
|
||
Special notes: Implementations SHOULD use a method such as that
|
||
specified for Formal Public Identifiers in [ISO9070] or for
|
||
Universal Resource Names in [RFC3406] to ensure that the text
|
||
value is unique.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 44]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
ABNF:
|
||
|
||
PRODID-param = "VALUE=text" / any-param
|
||
PRODID-value = text
|
||
|
||
Example:
|
||
|
||
PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
|
||
|
||
6.7.4. REV
|
||
|
||
Purpose: To specify revision information about the current vCard.
|
||
|
||
Value type: A single timestamp value.
|
||
|
||
Cardinality: *1
|
||
|
||
Special notes: The value distinguishes the current revision of the
|
||
information in this vCard for other renditions of the information.
|
||
|
||
ABNF:
|
||
|
||
REV-param = "VALUE=timestamp" / any-param
|
||
REV-value = timestamp
|
||
|
||
Example:
|
||
|
||
REV:19951031T222710Z
|
||
|
||
6.7.5. SOUND
|
||
|
||
Purpose: To specify a digital sound content information that
|
||
annotates some aspect of the vCard. This property is often used
|
||
to specify the proper pronunciation of the name property value of
|
||
the vCard.
|
||
|
||
Value type: A single URI.
|
||
|
||
Cardinality: *
|
||
|
||
ABNF:
|
||
|
||
SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param
|
||
/ type-param / mediatype-param / altid-param
|
||
/ any-param
|
||
SOUND-value = URI
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 45]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Example:
|
||
|
||
SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com
|
||
|
||
SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh
|
||
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
|
||
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
|
||
<...the remainder of base64-encoded data...>
|
||
|
||
6.7.6. UID
|
||
|
||
Purpose: To specify a value that represents a globally unique
|
||
identifier corresponding to the entity associated with the vCard.
|
||
|
||
Value type: A single URI value. It MAY also be reset to free-form
|
||
text.
|
||
|
||
Cardinality: *1
|
||
|
||
Special notes: This property is used to uniquely identify the object
|
||
that the vCard represents. The "uuid" URN namespace defined in
|
||
[RFC4122] is particularly well suited to this task, but other URI
|
||
schemes MAY be used. Free-form text MAY also be used.
|
||
|
||
ABNF:
|
||
|
||
UID-param = UID-uri-param / UID-text-param
|
||
UID-value = UID-uri-value / UID-text-value
|
||
; Value and parameter MUST match.
|
||
|
||
UID-uri-param = "VALUE=uri"
|
||
UID-uri-value = URI
|
||
|
||
UID-text-param = "VALUE=text"
|
||
UID-text-value = text
|
||
|
||
UID-param =/ any-param
|
||
|
||
Example:
|
||
|
||
UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 46]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
6.7.7. CLIENTPIDMAP
|
||
|
||
Purpose: To give a global meaning to a local PID source identifier.
|
||
|
||
Value type: A semicolon-separated pair of values. The first field
|
||
is a small integer corresponding to the second field of a PID
|
||
parameter instance. The second field is a URI. The "uuid" URN
|
||
namespace defined in [RFC4122] is particularly well suited to this
|
||
task, but other URI schemes MAY be used.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: PID source identifiers (the source identifier is the
|
||
second field in a PID parameter instance) are small integers that
|
||
only have significance within the scope of a single vCard
|
||
instance. Each distinct source identifier present in a vCard MUST
|
||
have an associated CLIENTPIDMAP. See Section 7 for more details
|
||
on the usage of CLIENTPIDMAP.
|
||
|
||
PID source identifiers MUST be strictly positive. Zero is not
|
||
allowed.
|
||
|
||
As a special exception, the PID parameter MUST NOT be applied to
|
||
this property.
|
||
|
||
ABNF:
|
||
|
||
CLIENTPIDMAP-param = any-param
|
||
CLIENTPIDMAP-value = 1*DIGIT ";" URI
|
||
|
||
Example:
|
||
|
||
TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555
|
||
EMAIL;PID=4.1,5.2:jdoe@example.com
|
||
CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b
|
||
CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5
|
||
|
||
6.7.8. URL
|
||
|
||
Purpose: To specify a uniform resource locator associated with the
|
||
object to which the vCard refers. Examples for individuals
|
||
include personal web sites, blogs, and social networking site
|
||
identifiers.
|
||
|
||
Cardinality: *
|
||
|
||
Value type: A single uri value.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 47]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
ABNF:
|
||
|
||
URL-param = "VALUE=uri" / pid-param / pref-param / type-param
|
||
/ mediatype-param / altid-param / any-param
|
||
URL-value = URI
|
||
|
||
Example:
|
||
|
||
URL:http://example.org/restaurant.french/~chezchic.html
|
||
|
||
6.7.9. VERSION
|
||
|
||
Purpose: To specify the version of the vCard specification used to
|
||
format this vCard.
|
||
|
||
Value type: A single text value.
|
||
|
||
Cardinality: 1
|
||
|
||
Special notes: This property MUST be present in the vCard object,
|
||
and it must appear immediately after BEGIN:VCARD. The value MUST
|
||
be "4.0" if the vCard corresponds to this specification. Note
|
||
that earlier versions of vCard allowed this property to be placed
|
||
anywhere in the vCard object, or even to be absent.
|
||
|
||
ABNF:
|
||
|
||
VERSION-param = "VALUE=text" / any-param
|
||
VERSION-value = "4.0"
|
||
|
||
Example:
|
||
|
||
VERSION:4.0
|
||
|
||
6.8. Security Properties
|
||
|
||
These properties are concerned with the security of communication
|
||
pathways or access to the vCard.
|
||
|
||
6.8.1. KEY
|
||
|
||
Purpose: To specify a public key or authentication certificate
|
||
associated with the object that the vCard represents.
|
||
|
||
Value type: A single URI. It can also be reset to a text value.
|
||
|
||
Cardinality: *
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 48]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
ABNF:
|
||
|
||
KEY-param = KEY-uri-param / KEY-text-param
|
||
KEY-value = KEY-uri-value / KEY-text-value
|
||
; Value and parameter MUST match.
|
||
|
||
KEY-uri-param = "VALUE=uri" / mediatype-param
|
||
KEY-uri-value = URI
|
||
|
||
KEY-text-param = "VALUE=text"
|
||
KEY-text-value = text
|
||
|
||
KEY-param =/ altid-param / pid-param / pref-param / type-param
|
||
/ any-param
|
||
|
||
Examples:
|
||
|
||
KEY:http://www.example.com/keys/jdoe.cer
|
||
|
||
KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe
|
||
|
||
KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE
|
||
UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
|
||
<... remainder of base64-encoded data ...>
|
||
|
||
6.9. Calendar Properties
|
||
|
||
These properties are further specified in [RFC2739].
|
||
|
||
6.9.1. FBURL
|
||
|
||
Purpose: To specify the URI for the busy time associated with the
|
||
object that the vCard represents.
|
||
|
||
Value type: A single URI value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: Where multiple FBURL properties are specified, the
|
||
default FBURL property is indicated with the PREF parameter. The
|
||
FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar
|
||
[RFC5545] object associated with a snapshot of the next few weeks
|
||
or months of busy time data. If the iCalendar object is
|
||
represented as a file or document, its file extension should be
|
||
".ifb".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 49]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
ABNF:
|
||
|
||
FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param
|
||
/ mediatype-param / altid-param / any-param
|
||
FBURL-value = URI
|
||
|
||
Examples:
|
||
|
||
FBURL;PREF=1:http://www.example.com/busy/janedoe
|
||
FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb
|
||
|
||
6.9.2. CALADRURI
|
||
|
||
Purpose: To specify the calendar user address [RFC5545] to which a
|
||
scheduling request [RFC5546] should be sent for the object
|
||
represented by the vCard.
|
||
|
||
Value type: A single URI value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: Where multiple CALADRURI properties are specified,
|
||
the default CALADRURI property is indicated with the PREF
|
||
parameter.
|
||
|
||
ABNF:
|
||
|
||
CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param
|
||
/ mediatype-param / altid-param / any-param
|
||
CALADRURI-value = URI
|
||
|
||
Example:
|
||
|
||
CALADRURI;PREF=1:mailto:janedoe@example.com
|
||
CALADRURI:http://example.com/calendar/jdoe
|
||
|
||
6.9.3. CALURI
|
||
|
||
Purpose: To specify the URI for a calendar associated with the
|
||
object represented by the vCard.
|
||
|
||
Value type: A single URI value.
|
||
|
||
Cardinality: *
|
||
|
||
Special notes: Where multiple CALURI properties are specified, the
|
||
default CALURI property is indicated with the PREF parameter. The
|
||
property should contain a URI pointing to an iCalendar [RFC5545]
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 50]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
object associated with a snapshot of the user's calendar store.
|
||
If the iCalendar object is represented as a file or document, its
|
||
file extension should be ".ics".
|
||
|
||
ABNF:
|
||
|
||
CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param
|
||
/ mediatype-param / altid-param / any-param
|
||
CALURI-value = URI
|
||
|
||
Examples:
|
||
|
||
CALURI;PREF=1:http://cal.example.com/calA
|
||
CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics
|
||
|
||
6.10. Extended Properties and Parameters
|
||
|
||
The properties and parameters defined by this document can be
|
||
extended. Non-standard, private properties and parameters with a
|
||
name starting with "X-" may be defined bilaterally between two
|
||
cooperating agents without outside registration or standardization.
|
||
|
||
7. Synchronization
|
||
|
||
vCard data often needs to be synchronized between devices. In this
|
||
context, synchronization is defined as the intelligent merging of two
|
||
representations of the same object. vCard 4.0 includes mechanisms to
|
||
aid this process.
|
||
|
||
7.1. Mechanisms
|
||
|
||
Two mechanisms are available: the UID property is used to match
|
||
multiple instances of the same vCard, while the PID parameter is used
|
||
to match multiple instances of the same property.
|
||
|
||
The term "matching" is used here to mean recognizing that two
|
||
instances are in fact representations of the same object. For
|
||
example, a single vCard that is shared with someone results in two
|
||
vCard instances. After they have evolved separately, they still
|
||
represent the same object, and therefore may be matched by a
|
||
synchronization engine.
|
||
|
||
7.1.1. Matching vCard Instances
|
||
|
||
vCard instances for which the UID properties (Section 6.7.6) are
|
||
equivalent MUST be matched. Equivalence is determined as specified
|
||
in [RFC3986], Section 6.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 51]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
In all other cases, vCard instances MAY be matched at the discretion
|
||
of the synchronization engine.
|
||
|
||
7.1.2. Matching Property Instances
|
||
|
||
Property instances belonging to unmatched vCards MUST NOT be matched.
|
||
|
||
Property instances whose name (e.g., EMAIL, TEL, etc.) is not the
|
||
same MUST NOT be matched.
|
||
|
||
Property instances whose name is CLIENTPIDMAP are handled separately
|
||
and MUST NOT be matched. The synchronization MUST ensure that there
|
||
is consistency of CLIENTPIDMAPs among matched vCard instances.
|
||
|
||
Property instances belonging to matched vCards, whose name is the
|
||
same, and whose maximum cardinality is 1, MUST be matched.
|
||
|
||
Property instances belonging to matched vCards, whose name is the
|
||
same, and whose PID parameters match, MUST be matched. See
|
||
Section 7.1.3 for details on PID matching.
|
||
|
||
In all other cases, property instances MAY be matched at the
|
||
discretion of the synchronization engine.
|
||
|
||
7.1.3. PID Matching
|
||
|
||
Two PID values for which the first fields are equivalent represent
|
||
the same local value.
|
||
|
||
Two PID values representing the same local value and for which the
|
||
second fields point to CLIENTPIDMAP properties whose second field
|
||
URIs are equivalent (as specified in [RFC3986], Section 6) also
|
||
represent the same global value.
|
||
|
||
PID parameters for which at least one pair of their values represent
|
||
the same global value MUST be matched.
|
||
|
||
In all other cases, PID parameters MAY be matched at the discretion
|
||
of the synchronization engine.
|
||
|
||
For example, PID value "5.1", in the first vCard below, and PID value
|
||
"5.2", in the second vCard below, represent the same global value.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 52]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
EMAIL;PID=4.2,5.1:jdoe@example.com
|
||
CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
|
||
CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
|
||
END:VCARD
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
EMAIL;PID=5.1,5.2:john@example.com
|
||
CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
|
||
CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
|
||
END:VCARD
|
||
|
||
7.2. Example
|
||
|
||
7.2.1. Creation
|
||
|
||
The following simple vCard is first created on a given device.
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
|
||
FN;PID=1.1:J. Doe
|
||
N:Doe;J.;;;
|
||
EMAIL;PID=1.1:jdoe@example.com
|
||
CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
|
||
END:VCARD
|
||
|
||
This new vCard is assigned the UID
|
||
"urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating
|
||
device. The FN and EMAIL properties are assigned the same local
|
||
value of 1, and this value is given global context by associating it
|
||
with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which
|
||
represents the creating device. We are at liberty to reuse the same
|
||
local value since instances of different properties will never be
|
||
matched. The N property has no PID because it is forbidden by its
|
||
maximum cardinality of 1.
|
||
|
||
7.2.2. Initial Sharing
|
||
|
||
This vCard is shared with a second device. Upon inspecting the UID
|
||
property, the second device understands that this is a new vCard
|
||
(i.e., unmatched) and thus the synchronization results in a simple
|
||
copy.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 53]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
7.2.3. Adding and Sharing a Property
|
||
|
||
A new phone number is created on the first device, then the vCard is
|
||
shared with the second device. This is what the second device
|
||
receives:
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
|
||
FN;PID=1.1:J. Doe
|
||
N:Doe;J.;;;
|
||
EMAIL;PID=1.1:jdoe@example.com
|
||
TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
|
||
CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
|
||
END:VCARD
|
||
|
||
Upon inspecting the UID property, the second device matches the vCard
|
||
it received to the vCard that it already has stored. It then starts
|
||
comparing the properties of the two vCards in same-named pairs.
|
||
|
||
The FN properties are matched because the PID parameters have the
|
||
same global value. Since the property value is the same, no update
|
||
takes place.
|
||
|
||
The N properties are matched automatically because their maximum
|
||
cardinality is 1. Since the property value is the same, no update
|
||
takes place.
|
||
|
||
The EMAIL properties are matched because the PID parameters have the
|
||
same global value. Since the property value is the same, no update
|
||
takes place.
|
||
|
||
The TEL property in the new vCard is not matched to any in the stored
|
||
vCard because no property in the stored vCard has the same name.
|
||
Therefore, this property is copied from the new vCard to the stored
|
||
vCard.
|
||
|
||
The CLIENTPIDMAP property is handled separately by the
|
||
synchronization engine. It ensures that it is consistent with the
|
||
stored one. If it was not, the results would be up to the
|
||
synchronization engine, and thus undefined by this document.
|
||
|
||
7.2.4. Simultaneous Editing
|
||
|
||
A new email address and a new phone number are added to the vCard on
|
||
each of the two devices, and then a new synchronization event
|
||
happens. Here are the vCards that are communicated to each other:
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 54]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
|
||
FN;PID=1.1:J. Doe
|
||
N:Doe;J.;;;
|
||
EMAIL;PID=1.1:jdoe@example.com
|
||
EMAIL;PID=2.1:boss@example.com
|
||
TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
|
||
TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
|
||
CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
|
||
END:VCARD
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
|
||
FN;PID=1.1:J. Doe
|
||
N:Doe;J.;;;
|
||
EMAIL;PID=1.1:jdoe@example.com
|
||
EMAIL;PID=2.2:ceo@example.com
|
||
TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
|
||
TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666
|
||
CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
|
||
CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
|
||
END:VCARD
|
||
|
||
On the first device, the same PID source identifier (1) is reused for
|
||
the new EMAIL and TEL properties. On the second device, a new source
|
||
identifier (2) is generated, and a corresponding CLIENTPIDMAP
|
||
property is created. It contains the second device's identifier,
|
||
"urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee".
|
||
|
||
The new EMAIL properties are unmatched on both sides since the PID
|
||
global value is new in both cases. The sync thus results in a copy
|
||
on both sides.
|
||
|
||
Although the situation appears to be the same for the TEL properties,
|
||
in this case, the synchronization engine is particularly smart and
|
||
matches the two new TEL properties even though their PID global
|
||
values are different. Note that in this case, the rules of
|
||
Section 7.1.2 state that two properties MAY be matched at the
|
||
discretion of the synchronization engine. Therefore, the two
|
||
properties are merged.
|
||
|
||
All this results in the following vCard, which is stored on both
|
||
devices:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 55]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
|
||
FN:J. Doe
|
||
N:Doe;J.;;;
|
||
EMAIL;PID=1.1:jdoe@example.com
|
||
EMAIL;PID=2.1:boss@example.com
|
||
EMAIL;PID=2.2:ceo@example.com
|
||
TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
|
||
TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666
|
||
CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
|
||
CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
|
||
END:VCARD
|
||
|
||
7.2.5. Global Context Simplification
|
||
|
||
The two devices finish their synchronization procedure by simplifying
|
||
their global contexts. Since they haven't talked to any other
|
||
device, the following vCard is for all purposes equivalent to the
|
||
above. It is also shorter.
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
|
||
FN:J. Doe
|
||
N:Doe;J.;;;
|
||
EMAIL;PID=1.1:jdoe@example.com
|
||
EMAIL;PID=2.1:boss@example.com
|
||
EMAIL;PID=3.1:ceo@example.com
|
||
TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
|
||
TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
|
||
CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
|
||
END:VCARD
|
||
|
||
The details of global context simplification are unspecified by this
|
||
document. They are left up to the synchronization engine. This
|
||
example is merely intended to illustrate the possibility, which
|
||
investigating would be, in the author's opinion, worthwhile.
|
||
|
||
8. Example: Author's vCard
|
||
|
||
BEGIN:VCARD
|
||
VERSION:4.0
|
||
FN:Simon Perreault
|
||
N:Perreault;Simon;;;ing. jr,M.Sc.
|
||
BDAY:--0203
|
||
ANNIVERSARY:20090808T1430-0500
|
||
GENDER:M
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 56]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
LANG;PREF=1:fr
|
||
LANG;PREF=2:en
|
||
ORG;TYPE=work:Viagenie
|
||
ADR;TYPE=work:;Suite D2-630;2875 Laurier;
|
||
Quebec;QC;G1V 2M2;Canada
|
||
TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
|
||
TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501
|
||
EMAIL;TYPE=work:simon.perreault@viagenie.ca
|
||
GEO;TYPE=work:geo:46.772673,-71.282945
|
||
KEY;TYPE=work;VALUE=uri:
|
||
http://www.viagenie.ca/simon.perreault/simon.asc
|
||
TZ:-0500
|
||
URL;TYPE=home:http://nomis80.org
|
||
END:VCARD
|
||
|
||
9. Security Considerations
|
||
|
||
o Internet mail is often used to transport vCards and is subject to
|
||
many well-known security attacks, including monitoring, replay,
|
||
and forgery. Care should be taken by any directory service in
|
||
allowing information to leave the scope of the service itself,
|
||
where any access controls or confidentiality can no longer be
|
||
guaranteed. Applications should also take care to display
|
||
directory data in a "safe" environment.
|
||
|
||
o vCards can carry cryptographic keys or certificates, as described
|
||
in Section 6.8.1.
|
||
|
||
o vCards often carry information that can be sensitive (e.g.,
|
||
birthday, address, and phone information). Although vCards have
|
||
no inherent authentication or confidentiality provisions, they can
|
||
easily be carried by any security mechanism that transfers MIME
|
||
objects to address authentication or confidentiality (e.g., S/MIME
|
||
[RFC5751], OpenPGP [RFC4880]). In cases where the confidentiality
|
||
or authenticity of information contained in vCard is a concern,
|
||
the vCard SHOULD be transported using one of these secure
|
||
mechanisms. The KEY property (Section 6.8.1) can be used to
|
||
transport the public key used by these mechanisms.
|
||
|
||
o The information in a vCard may become out of date. In cases where
|
||
the vitality of data is important to an originator of a vCard, the
|
||
SOURCE property (Section 6.1.3) SHOULD be specified. In addition,
|
||
the "REV" type described in Section 6.7.4 can be specified to
|
||
indicate the last time that the vCard data was updated.
|
||
|
||
o Many vCard properties may be used to transport URIs. Please refer
|
||
to [RFC3986], Section 7, for considerations related to URIs.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 57]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
10. IANA Considerations
|
||
|
||
10.1. Media Type Registration
|
||
|
||
IANA has registered the following Media Type (in
|
||
<http://www.iana.org/>) and marked the text/directory Media Type as
|
||
DEPRECATED.
|
||
|
||
To: ietf-types@iana.org
|
||
|
||
Subject: Registration of media type text/vcard
|
||
|
||
Type name: text
|
||
|
||
Subtype name: vcard
|
||
|
||
Required parameters: none
|
||
|
||
Optional parameters: version
|
||
|
||
The "version" parameter is to be interpreted identically as the
|
||
VERSION vCard property. If this parameter is present, all vCards
|
||
in a text/vcard body part MUST have a VERSION property with value
|
||
identical to that of this MIME parameter.
|
||
|
||
"charset": as defined for text/plain [RFC2046]; encodings other
|
||
than UTF-8 [RFC3629] MUST NOT be used.
|
||
|
||
Encoding considerations: 8bit
|
||
|
||
Security considerations: See Section 9.
|
||
|
||
Interoperability considerations: The text/vcard media type is
|
||
intended to identify vCard data of any version. There are older
|
||
specifications of vCard [RFC2426][vCard21] still in common use.
|
||
While these formats are similar, they are not strictly compatible.
|
||
In general, it is necessary to inspect the value of the VERSION
|
||
property (see Section 6.7.9) for identifying the standard to which
|
||
a given vCard object conforms.
|
||
|
||
In addition, the following media types are known to have been used
|
||
to refer to vCard data. They should be considered deprecated in
|
||
favor of text/vcard.
|
||
|
||
* text/directory
|
||
* text/directory; profile=vcard
|
||
* text/x-vcard
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 58]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Published specification: RFC 6350
|
||
|
||
Applications that use this media type: They are numerous, diverse,
|
||
and include mail user agents, instant messaging clients, address
|
||
book applications, directory servers, and customer relationship
|
||
management software.
|
||
|
||
Additional information:
|
||
|
||
Magic number(s):
|
||
|
||
File extension(s): .vcf .vcard
|
||
|
||
Macintosh file type code(s):
|
||
|
||
Person & email address to contact for further information: vCard
|
||
discussion mailing list <vcarddav@ietf.org>
|
||
|
||
Intended usage: COMMON
|
||
|
||
Restrictions on usage: none
|
||
|
||
Author: Simon Perreault
|
||
|
||
Change controller: IETF
|
||
|
||
10.2. Registering New vCard Elements
|
||
|
||
This section defines the process for registering new or modified
|
||
vCard elements (i.e., properties, parameters, value data types, and
|
||
values) with IANA.
|
||
|
||
10.2.1. Registration Procedure
|
||
|
||
The IETF has created a mailing list, vcarddav@ietf.org, which can be
|
||
used for public discussion of vCard element proposals prior to
|
||
registration. Use of the mailing list is strongly encouraged. The
|
||
IESG has appointed a designated expert who will monitor the
|
||
vcarddav@ietf.org mailing list and review registrations.
|
||
|
||
Registration of new vCard elements MUST be reviewed by the designated
|
||
expert and published in an RFC. A Standards Track RFC is REQUIRED
|
||
for the registration of new value data types that modify existing
|
||
properties. A Standards Track RFC is also REQUIRED for registration
|
||
of vCard elements that modify vCard elements previously documented in
|
||
a Standards Track RFC.
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 59]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
The registration procedure begins when a completed registration
|
||
template, defined in the sections below, is sent to vcarddav@ietf.org
|
||
and iana@iana.org. Within two weeks, the designated expert is
|
||
expected to tell IANA and the submitter of the registration whether
|
||
the registration is approved, approved with minor changes, or
|
||
rejected with cause. When a registration is rejected with cause, it
|
||
can be re-submitted if the concerns listed in the cause are
|
||
addressed. Decisions made by the designated expert can be appealed
|
||
to the IESG Applications Area Director, then to the IESG. They
|
||
follow the normal appeals procedure for IESG decisions.
|
||
|
||
Once the registration procedure concludes successfully, IANA creates
|
||
or modifies the corresponding record in the vCard registry. The
|
||
completed registration template is discarded.
|
||
|
||
An RFC specifying new vCard elements MUST include the completed
|
||
registration templates, which MAY be expanded with additional
|
||
information. These completed templates are intended to go in the
|
||
body of the document, not in the IANA Considerations section.
|
||
|
||
Finally, note that there is an XML representation for vCard defined
|
||
in [RFC6351]. An XML representation SHOULD be defined for new vCard
|
||
elements.
|
||
|
||
10.2.2. Vendor Namespace
|
||
|
||
The vendor namespace is used for vCard elements associated with
|
||
commercially available products. "Vendor" or "producer" are
|
||
construed as equivalent and very broadly in this context.
|
||
|
||
A registration may be placed in the vendor namespace by anyone who
|
||
needs to interchange files associated with the particular product.
|
||
However, the registration formally belongs to the vendor or
|
||
organization handling the vCard elements in the namespace being
|
||
registered. Changes to the specification will be made at their
|
||
request, as discussed in subsequent sections.
|
||
|
||
vCard elements belonging to the vendor namespace will be
|
||
distinguished by the "VND-" prefix. This is followed by an IANA-
|
||
registered Private Enterprise Number (PEN), a dash, and a vCard
|
||
element designation of the vendor's choosing (e.g., "VND-123456-
|
||
MUDPIE").
|
||
|
||
While public exposure and review of vCard elements to be registered
|
||
in the vendor namespace are not required, using the vcarddav@ietf.org
|
||
mailing list for review is strongly encouraged to improve the quality
|
||
of those specifications. Registrations in the vendor namespace may
|
||
be submitted directly to the IANA.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 60]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
10.2.3. Registration Template for Properties
|
||
|
||
A property is defined by completing the following template.
|
||
|
||
Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor-
|
||
specific property (where NNNN is replaced by the vendor's PEN).
|
||
|
||
Property name: The name of the property.
|
||
|
||
Purpose: The purpose of the property. Give a short but clear
|
||
description.
|
||
|
||
Value type: Any of the valid value types for the property value
|
||
needs to be specified. The default value type also needs to be
|
||
specified.
|
||
|
||
Cardinality: See Section 6.
|
||
|
||
Property parameters: Any of the valid property parameters for the
|
||
property MUST be specified.
|
||
|
||
Description: Any special notes about the property, how it is to be
|
||
used, etc.
|
||
|
||
Format definition: The ABNF for the property definition needs to be
|
||
specified.
|
||
|
||
Example(s): One or more examples of instances of the property need
|
||
to be specified.
|
||
|
||
10.2.4. Registration Template for Parameters
|
||
|
||
A parameter is defined by completing the following template.
|
||
|
||
Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor-
|
||
specific property (where NNNN is replaced by the vendor's PEN).
|
||
|
||
Parameter name: The name of the parameter.
|
||
|
||
Purpose: The purpose of the parameter. Give a short but clear
|
||
description.
|
||
|
||
Description: Any special notes about the parameter, how it is to be
|
||
used, etc.
|
||
|
||
Format definition: The ABNF for the parameter definition needs to be
|
||
specified.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 61]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Example(s): One or more examples of instances of the parameter need
|
||
to be specified.
|
||
|
||
10.2.5. Registration Template for Value Data Types
|
||
|
||
A value data type is defined by completing the following template.
|
||
|
||
Value name: The name of the value type.
|
||
|
||
Purpose: The purpose of the value type. Give a short but clear
|
||
description.
|
||
|
||
Description: Any special notes about the value type, how it is to be
|
||
used, etc.
|
||
|
||
Format definition: The ABNF for the value type definition needs to
|
||
be specified.
|
||
|
||
Example(s): One or more examples of instances of the value type need
|
||
to be specified.
|
||
|
||
10.2.6. Registration Template for Values
|
||
|
||
A value is defined by completing the following template.
|
||
|
||
Value: The value literal.
|
||
|
||
Purpose: The purpose of the value. Give a short but clear
|
||
description.
|
||
|
||
Conformance: The vCard properties and/or parameters that can take
|
||
this value needs to be specified.
|
||
|
||
Example(s): One or more examples of instances of the value need to
|
||
be specified.
|
||
|
||
The following is a fictitious example of a registration of a vCard
|
||
value:
|
||
|
||
Value: supervisor
|
||
|
||
Purpose: It means that the related entity is the direct hierarchical
|
||
superior (i.e., supervisor or manager) of the entity this vCard
|
||
represents.
|
||
|
||
Conformance: This value can be used with the "TYPE" parameter
|
||
applied on the "RELATED" property.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 62]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Example(s):
|
||
|
||
RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
|
||
|
||
10.3. Initial vCard Elements Registries
|
||
|
||
The IANA has created and will maintain the following registries for
|
||
vCard elements with pointers to appropriate reference documents. The
|
||
registries are grouped together under the heading "vCard Elements".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 63]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
10.3.1. Properties Registry
|
||
|
||
The following table has been used to initialize the properties
|
||
registry.
|
||
|
||
+-----------+--------------+-------------------------+
|
||
| Namespace | Property | Reference |
|
||
+-----------+--------------+-------------------------+
|
||
| | SOURCE | RFC 6350, Section 6.1.3 |
|
||
| | KIND | RFC 6350, Section 6.1.4 |
|
||
| | XML | RFC 6350, Section 6.1.5 |
|
||
| | FN | RFC 6350, Section 6.2.1 |
|
||
| | N | RFC 6350, Section 6.2.2 |
|
||
| | NICKNAME | RFC 6350, Section 6.2.3 |
|
||
| | PHOTO | RFC 6350, Section 6.2.4 |
|
||
| | BDAY | RFC 6350, Section 6.2.5 |
|
||
| | ANNIVERSARY | RFC 6350, Section 6.2.6 |
|
||
| | GENDER | RFC 6350, Section 6.2.7 |
|
||
| | ADR | RFC 6350, Section 6.3.1 |
|
||
| | TEL | RFC 6350, Section 6.4.1 |
|
||
| | EMAIL | RFC 6350, Section 6.4.2 |
|
||
| | IMPP | RFC 6350, Section 6.4.3 |
|
||
| | LANG | RFC 6350, Section 6.4.4 |
|
||
| | TZ | RFC 6350, Section 6.5.1 |
|
||
| | GEO | RFC 6350, Section 6.5.2 |
|
||
| | TITLE | RFC 6350, Section 6.6.1 |
|
||
| | ROLE | RFC 6350, Section 6.6.2 |
|
||
| | LOGO | RFC 6350, Section 6.6.3 |
|
||
| | ORG | RFC 6350, Section 6.6.4 |
|
||
| | MEMBER | RFC 6350, Section 6.6.5 |
|
||
| | RELATED | RFC 6350, Section 6.6.6 |
|
||
| | CATEGORIES | RFC 6350, Section 6.7.1 |
|
||
| | NOTE | RFC 6350, Section 6.7.2 |
|
||
| | PRODID | RFC 6350, Section 6.7.3 |
|
||
| | REV | RFC 6350, Section 6.7.4 |
|
||
| | SOUND | RFC 6350, Section 6.7.5 |
|
||
| | UID | RFC 6350, Section 6.7.6 |
|
||
| | CLIENTPIDMAP | RFC 6350, Section 6.7.7 |
|
||
| | URL | RFC 6350, Section 6.7.8 |
|
||
| | VERSION | RFC 6350, Section 6.7.9 |
|
||
| | KEY | RFC 6350, Section 6.8.1 |
|
||
| | FBURL | RFC 6350, Section 6.9.1 |
|
||
| | CALADRURI | RFC 6350, Section 6.9.2 |
|
||
| | CALURI | RFC 6350, Section 6.9.3 |
|
||
+-----------+--------------+-------------------------+
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 64]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
10.3.2. Parameters Registry
|
||
|
||
The following table has been used to initialize the parameters
|
||
registry.
|
||
|
||
+-----------+-----------+------------------------+
|
||
| Namespace | Parameter | Reference |
|
||
+-----------+-----------+------------------------+
|
||
| | LANGUAGE | RFC 6350, Section 5.1 |
|
||
| | VALUE | RFC 6350, Section 5.2 |
|
||
| | PREF | RFC 6350, Section 5.3 |
|
||
| | ALTID | RFC 6350, Section 5.4 |
|
||
| | PID | RFC 6350, Section 5.5 |
|
||
| | TYPE | RFC 6350, Section 5.6 |
|
||
| | MEDIATYPE | RFC 6350, Section 5.7 |
|
||
| | CALSCALE | RFC 6350, Section 5.8 |
|
||
| | SORT-AS | RFC 6350, Section 5.9 |
|
||
| | GEO | RFC 6350, Section 5.10 |
|
||
| | TZ | RFC 6350, Section 5.11 |
|
||
+-----------+-----------+------------------------+
|
||
|
||
10.3.3. Value Data Types Registry
|
||
|
||
The following table has been used to initialize the parameters
|
||
registry.
|
||
|
||
+------------------+-------------------------+
|
||
| Value Data Type | Reference |
|
||
+------------------+-------------------------+
|
||
| BOOLEAN | RFC 6350, Section 4.4 |
|
||
| DATE | RFC 6350, Section 4.3.1 |
|
||
| DATE-AND-OR-TIME | RFC 6350, Section 4.3.4 |
|
||
| DATE-TIME | RFC 6350, Section 4.3.3 |
|
||
| FLOAT | RFC 6350, Section 4.6 |
|
||
| INTEGER | RFC 6350, Section 4.5 |
|
||
| LANGUAGE-TAG | RFC 6350, Section 4.8 |
|
||
| TEXT | RFC 6350, Section 4.1 |
|
||
| TIME | RFC 6350, Section 4.3.2 |
|
||
| TIMESTAMP | RFC 6350, Section 4.3.5 |
|
||
| URI | RFC 6350, Section 4.2 |
|
||
| UTC-OFFSET | RFC 6350, Section 4.7 |
|
||
+------------------+-------------------------+
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 65]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
10.3.4. Values Registries
|
||
|
||
Separate tables are used for property and parameter values.
|
||
|
||
The following table is to be used to initialize the property values
|
||
registry.
|
||
|
||
+----------+------------+-------------------------+
|
||
| Property | Value | Reference |
|
||
+----------+------------+-------------------------+
|
||
| BEGIN | VCARD | RFC 6350, Section 6.1.1 |
|
||
| END | VCARD | RFC 6350, Section 6.1.2 |
|
||
| KIND | individual | RFC 6350, Section 6.1.4 |
|
||
| KIND | group | RFC 6350, Section 6.1.4 |
|
||
| KIND | org | RFC 6350, Section 6.1.4 |
|
||
| KIND | location | RFC 6350, Section 6.1.4 |
|
||
+----------+------------+-------------------------+
|
||
|
||
The following table has been used to initialize the parameter values
|
||
registry.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 66]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
+------------------------+-----------+--------------+---------------+
|
||
| Property | Parameter | Value | Reference |
|
||
+------------------------+-----------+--------------+---------------+
|
||
| FN, NICKNAME, PHOTO, | TYPE | work | RFC 6350, |
|
||
| ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
|
||
| LANG, TZ, GEO, TITLE, | | | |
|
||
| ROLE, LOGO, ORG, | | | |
|
||
| RELATED, CATEGORIES, | | | |
|
||
| NOTE, SOUND, URL, KEY, | | | |
|
||
| FBURL, CALADRURI, and | | | |
|
||
| CALURI | | | |
|
||
| FN, NICKNAME, PHOTO, | TYPE | home | RFC 6350, |
|
||
| ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
|
||
| LANG, TZ, GEO, TITLE, | | | |
|
||
| ROLE, LOGO, ORG, | | | |
|
||
| RELATED, CATEGORIES, | | | |
|
||
| NOTE, SOUND, URL, KEY, | | | |
|
||
| FBURL, CALADRURI, and | | | |
|
||
| CALURI | | | |
|
||
| TEL | TYPE | text | RFC 6350, |
|
||
| | | | Section 6.4.1 |
|
||
| TEL | TYPE | voice | RFC 6350, |
|
||
| | | | Section 6.4.1 |
|
||
| TEL | TYPE | fax | RFC 6350, |
|
||
| | | | Section 6.4.1 |
|
||
| TEL | TYPE | cell | RFC 6350, |
|
||
| | | | Section 6.4.1 |
|
||
| TEL | TYPE | video | RFC 6350, |
|
||
| | | | Section 6.4.1 |
|
||
| TEL | TYPE | pager | RFC 6350, |
|
||
| | | | Section 6.4.1 |
|
||
| TEL | TYPE | textphone | RFC 6350, |
|
||
| | | | Section 6.4.1 |
|
||
| BDAY, ANNIVERSARY | CALSCALE | gregorian | RFC 6350, |
|
||
| | | | Section 5.8 |
|
||
| RELATED | TYPE | contact | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | acquaintance | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | friend | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | met | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 67]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
| RELATED | TYPE | co-worker | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | colleague | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | co-resident | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | neighbor | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | child | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | parent | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | sibling | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | spouse | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | kin | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | muse | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | crush | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | date | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | sweetheart | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | me | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| | | | and [xfn] |
|
||
| RELATED | TYPE | agent | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
| RELATED | TYPE | emergency | RFC 6350, |
|
||
| | | | Section 6.6.6 |
|
||
+------------------------+-----------+--------------+---------------+
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 68]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
11. Acknowledgments
|
||
|
||
The authors would like to thank Tim Howes, Mark Smith, and Frank
|
||
Dawson, the original authors of [RFC2425] and [RFC2426], Pete
|
||
Resnick, who got this effort started and provided help along the way,
|
||
as well as the following individuals who have participated in the
|
||
drafting, review, and discussion of this memo:
|
||
|
||
Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil
|
||
Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie
|
||
Hoeneisen, Bjoern Hoehrmann, Caleb Richardson, Chris Bryant, Chris
|
||
Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale,
|
||
Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian
|
||
Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens,
|
||
Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke,
|
||
Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga, Lisa Dusseault,
|
||
Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike
|
||
Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter
|
||
Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane
|
||
Bortzmeyer, Tantek Celik, and Zoltan Ordogh.
|
||
|
||
12. References
|
||
|
||
12.1. Normative References
|
||
|
||
[CCITT.X520.1988]
|
||
International Telephone and Telegraph Consultative
|
||
Committee, "Information Technology - Open Systems
|
||
Interconnection - The Directory: Selected Attribute
|
||
Types", CCITT Recommendation X.520, November 1988.
|
||
|
||
[IEEE.754.2008]
|
||
Institute of Electrical and Electronics Engineers,
|
||
"Standard for Binary Floating-Point Arithmetic",
|
||
IEEE Standard 754, August 2008.
|
||
|
||
[ISO.8601.2000]
|
||
International Organization for Standardization, "Data
|
||
elements and interchange formats - Information interchange
|
||
- Representation of dates and times", ISO Standard 8601,
|
||
December 2000.
|
||
|
||
[ISO.8601.2004]
|
||
International Organization for Standardization, "Data
|
||
elements and interchange formats - Information interchange
|
||
- Representation of dates and times", ISO Standard 8601,
|
||
December 2004.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 69]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||
Extensions (MIME) Part One: Format of Internet Message
|
||
Bodies", RFC 2045, November 1996.
|
||
|
||
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||
Extensions (MIME) Part Two: Media Types", RFC 2046,
|
||
November 1996.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar
|
||
Attributes for vCard and LDAP", RFC 2739, January 2000.
|
||
|
||
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
|
||
10646", STD 63, RFC 3629, November 2003.
|
||
|
||
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
|
||
RFC 3966, December 2004.
|
||
|
||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
||
Resource Identifier (URI): Generic Syntax", STD 66,
|
||
RFC 3986, January 2005.
|
||
|
||
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
|
||
Unique IDentifier (UUID) URN Namespace", RFC 4122,
|
||
July 2005.
|
||
|
||
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
|
||
Registration Procedures", BCP 13, RFC 4288, December 2005.
|
||
|
||
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", STD 68, RFC 5234, January 2008.
|
||
|
||
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
|
||
October 2008.
|
||
|
||
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
|
||
Core Object Specification (iCalendar)", RFC 5545,
|
||
September 2009.
|
||
|
||
[RFC5546] Daboo, C., "iCalendar Transport-Independent
|
||
Interoperability Protocol (iTIP)", RFC 5546,
|
||
December 2009.
|
||
|
||
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
|
||
Languages", BCP 47, RFC 5646, September 2009.
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 70]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
|
||
Identifier for Geographic Locations ('geo' URI)",
|
||
RFC 5870, June 2010.
|
||
|
||
[RFC6351] Perreault, S., "xCard: vCard XML Representation",
|
||
RFC 6351, August 2011.
|
||
|
||
[W3C.REC-xml-20081126]
|
||
Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J.,
|
||
and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
|
||
Edition)", World Wide Web Consortium Recommendation REC-
|
||
xml-20081126, November 2008,
|
||
<http://www.w3.org/TR/2008/REC-xml-20081126>.
|
||
|
||
[xfn] Celik, T., Mullenweg, M., and E. Meyer, "XFN 1.1 profile",
|
||
<http://gmpg.org/xfn/11>.
|
||
|
||
12.2. Informative References
|
||
|
||
[IANA-TZ] Lear, E. and P. Eggert, "IANA Procedures for Maintaining
|
||
the Timezone Database", Work in Progress, May 2011.
|
||
|
||
[ISO9070] International Organization for Standardization,
|
||
"Information Processing - SGML support facilities -
|
||
Registration Procedures for Public Text Owner
|
||
Identifiers", ISO 9070, April 1991.
|
||
|
||
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
|
||
Resource Locators (URL)", RFC 1738, December 1994.
|
||
|
||
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
|
||
August 1998.
|
||
|
||
[RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
|
||
for Directory Information", RFC 2425, September 1998.
|
||
|
||
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
|
||
RFC 2426, September 1998.
|
||
|
||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
|
||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
|
||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
|
||
|
||
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
|
||
May 2002.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 71]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
|
||
"Uniform Resource Names (URN) Namespace Definition
|
||
Mechanisms", BCP 66, RFC 3406, October 2002.
|
||
|
||
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in
|
||
the IETF", RFC 3536, May 2003.
|
||
|
||
[RFC4770] Jennings, C. and J. Reschke, Ed., "vCard Extensions for
|
||
Instant Messaging (IM)", RFC 4770, January 2007.
|
||
|
||
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
|
||
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
|
||
|
||
[RFC5335bis]
|
||
Yang, A. and S. Steele, "Internationalized Email Headers",
|
||
Work in Progress, July 2011.
|
||
|
||
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
|
||
Mail Extensions (S/MIME) Version 3.2 Message
|
||
Specification", RFC 5751, January 2010.
|
||
|
||
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
|
||
URI Scheme", RFC 6068, October 2010.
|
||
|
||
[TZ-DB] Olson, A., "Time zone code and data",
|
||
<ftp://elsie.nci.nih.gov/pub/>.
|
||
|
||
[vCard21] Internet Mail Consortium, "vCard - The Electronic Business
|
||
Card Version 2.1", September 1996.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 72]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
Appendix A. Differences from RFCs 2425 and 2426
|
||
|
||
This appendix contains a high-level overview of the major changes
|
||
that have been made in the vCard specification from RFCs 2425 and
|
||
2426. It is incomplete, as it only lists the most important changes.
|
||
|
||
A.1. New Structure
|
||
|
||
o [RFC2425] and [RFC2426] have been merged.
|
||
|
||
o vCard is now not only a MIME type but a stand-alone format.
|
||
|
||
o A proper MIME type registration form has been included.
|
||
|
||
o UTF-8 is now the only possible character set.
|
||
|
||
o New vCard elements can be registered from IANA.
|
||
|
||
A.2. Removed Features
|
||
|
||
o The CONTEXT and CHARSET parameters are no more.
|
||
|
||
o The NAME, MAILER, LABEL, and CLASS properties are no more.
|
||
|
||
o The "intl", "dom", "postal", and "parcel" TYPE parameter values
|
||
for the ADR property have been removed.
|
||
|
||
o In-line vCards (such as the value of the AGENT property) are no
|
||
longer supported.
|
||
|
||
A.3. New Properties and Parameters
|
||
|
||
o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP
|
||
properties have been added.
|
||
|
||
o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI
|
||
properties, has been merged in.
|
||
|
||
o [RFC4770], which defines the IMPP property, has been merged in.
|
||
|
||
o The "work" and "home" TYPE parameter values are now applicable to
|
||
many more properties.
|
||
|
||
o The "pref" value of the TYPE parameter is now a parameter of its
|
||
own, with a positive integer value indicating the level of
|
||
preference.
|
||
|
||
o The ALTID and PID parameters have been added.
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 73]
|
||
|
||
RFC 6350 vCard August 2011
|
||
|
||
|
||
o The MEDIATYPE parameter has been added and replaces the TYPE
|
||
parameter when it was used for indicating the media type of the
|
||
property's content.
|
||
|
||
Author's Address
|
||
|
||
Simon Perreault
|
||
Viagenie
|
||
2875 Laurier, suite D2-630
|
||
Quebec, QC G1V 2M2
|
||
Canada
|
||
|
||
Phone: +1 418 656 9254
|
||
EMail: simon.perreault@viagenie.ca
|
||
URI: http://www.viagenie.ca
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Perreault Standards Track [Page 74]
|
||
|