mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-09-12 09:45:12 +00:00
4148 lines
137 KiB
Text
4148 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]
|
|||
|
|