diff options
Diffstat (limited to 'doc/rfc/rfc6350.txt')
| -rw-r--r-- | doc/rfc/rfc6350.txt | 4147 |
1 files changed, 4147 insertions, 0 deletions
diff --git a/doc/rfc/rfc6350.txt b/doc/rfc/rfc6350.txt new file mode 100644 index 0000000..d853cbc --- /dev/null +++ b/doc/rfc/rfc6350.txt @@ -0,0 +1,4147 @@ + + + + + + +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] + |