idnits 2.17.1 draft-ietf-vcarddav-vcardrev-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2425, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2426, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4770, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2739, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 481 has weird spacing: '... [month day]...' == Line 485 has weird spacing: '... month day...' == Line 486 has weird spacing: '... month day...' == Line 488 has weird spacing: '... month day...' == Line 494 has weird spacing: '... = hour minut...' == (1 more instance...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2739, updated by this document, for RFC5378 checks: 1998-08-14) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 6, 2011) is 4769 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-vcarddav-vcardxml-08 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-13) exists of draft-ietf-eai-rfc5335bis-10 -- Obsolete informational reference (is this intentional?): RFC 2425 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 4770 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault 3 Internet-Draft Viagenie 4 Obsoletes: 2425, 2426, 4770 April 6, 2011 5 (if approved) 6 Updates: 2739 (if approved) 7 Intended status: Standards Track 8 Expires: October 8, 2011 10 vCard Format Specification 11 draft-ietf-vcarddav-vcardrev-17 13 Abstract 15 This document defines the vCard data format for representing and 16 exchanging a variety of information about individuals and other 17 entities (e.g., formatted and structured name and delivery addresses, 18 email address, multiple telephone numbers, photograph, logo, audio 19 clips, etc.). 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on October 8, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 6 76 3.1. Character Set . . . . . . . . . . . . . . . . . . . . . . 6 77 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 6 78 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 7 79 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9 80 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 10 81 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 13 84 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 14 87 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14 88 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 15 89 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 4.7. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16 93 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16 94 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 21 101 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23 106 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23 107 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23 108 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24 110 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25 111 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 28 112 6.2. Identification Properties . . . . . . . . . . . . . . . . 28 113 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 29 115 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 30 116 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 30 117 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 31 118 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 32 119 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 32 120 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 33 121 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 33 122 6.4. Communications Properties . . . . . . . . . . . . . . . . 34 123 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34 124 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 36 125 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 37 126 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 37 127 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 38 128 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 38 129 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 39 130 6.6. Organizational Properties . . . . . . . . . . . . . . . . 39 131 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 39 132 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 40 133 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 41 134 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 41 135 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 42 136 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 43 137 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 44 138 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 44 139 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 45 140 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 45 141 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 46 142 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 46 143 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 47 144 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47 145 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 48 146 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 49 147 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 49 148 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 49 149 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 50 150 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 50 151 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 51 152 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 51 153 6.10. Extended Properties and Parameters . . . . . . . . . . . . 52 154 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 52 155 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 52 156 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 52 157 7.1.2. Matching Property Instances . . . . . . . . . . . . . 53 158 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 53 159 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 54 160 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 54 161 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 54 162 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 55 163 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 55 164 7.2.5. Global Context Simplification . . . . . . . . . . . . 57 165 8. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 58 166 9. Security Considerations . . . . . . . . . . . . . . . . . . . 58 167 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 168 10.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 59 169 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 60 170 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 61 171 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 61 172 10.2.3. Registration Template for Properties . . . . . . . . . 62 173 10.2.4. Registration Template for Parameters . . . . . . . . . 63 174 10.2.5. Registration Template for Value Data Types . . . . . . 63 175 10.2.6. Registration Template for Values . . . . . . . . . . . 63 176 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 64 177 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64 178 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 65 179 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 66 180 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66 181 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 182 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 183 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69 184 12.2. Informative References . . . . . . . . . . . . . . . . . . 72 185 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 73 186 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73 187 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 74 188 A.3. New Properties and Parameters . . . . . . . . . . . . . . 74 189 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 74 190 Appendix B. Change Log (to be removed by RFC Editor prior to 191 publication) . . . . . . . . . . . . . . . . . . . . 75 192 B.1. Changes in -17 . . . . . . . . . . . . . . . . . . . . . . 75 193 B.2. Changes in -16 . . . . . . . . . . . . . . . . . . . . . . 76 194 B.3. Changes in -15 . . . . . . . . . . . . . . . . . . . . . . 76 195 B.4. Changes in -14 . . . . . . . . . . . . . . . . . . . . . . 77 196 B.5. Changes in -13 . . . . . . . . . . . . . . . . . . . . . . 77 197 B.6. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 78 198 B.7. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 79 199 B.8. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 79 200 B.9. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 80 201 B.10. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 80 202 B.11. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 81 203 B.12. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 81 204 B.13. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 82 205 B.14. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 82 206 B.15. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 83 207 B.16. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 83 208 B.17. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 83 209 B.18. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 84 211 1. Introduction 213 Electronic address books have become ubiquitous. Their increased 214 presence on portable, connected devices as well as the diversity of 215 platforms exchanging contact data call for a standard. This memo 216 defines the vCard format, which allows the capture and exchange of 217 information normally stored within an address book or directory 218 application. 220 2. Conventions 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 3. vCard Format Specification 228 The text/vcard MIME content type (hereafter known as "vCard", see 229 Section 10.1) contains contact information, typically pertaining to a 230 single contact or group of contacts. The content consists of one or 231 more lines in the format given below. 233 3.1. Character Set 235 The character set for vCard is UTF-8 as defined in [RFC3629]. There 236 is no way to override this. It is invalid to specify a different 237 character set in the "charset" MIME parameter (see Section 10.1). 239 3.2. Line Delimiting and Folding 241 Individual lines within vCard are delimited by the [RFC5322] line 242 break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII 243 decimal 10). Long logical lines of text can be split into a 244 multiple-physical-line representation using the following folding 245 technique. Content lines SHOULD be folded to a maximum width of 75 246 octets, excluding the line break. Multi-octet characters MUST remain 247 contiguous. The rationale for this folding process can be found in 248 [RFC5322], Section 2.1.1. 250 A logical line MAY be continued on the next physical line anywhere 251 between two characters by inserting a CRLF immediately followed by a 252 single white space character (space, ASCII decimal 32, or horizontal 253 tab, ASCII decimal 9). The folded line MUST contain at least one 254 character. Any sequence of CRLF followed immediately by a single 255 white space character is ignored (removed) when processing the 256 content type. For example the line: 258 NOTE:This is a long description that exists on a long line. 260 can be represented as: 262 NOTE:This is a long description 263 that exists on a long line. 265 It could also be represented as: 267 NOTE:This is a long descrip 268 tion that exists o 269 n a long line. 271 The process of moving from this folded multiple-line representation 272 of a property definition to its single line representation is called 273 unfolding. Unfolding is accomplished by regarding CRLF immediately 274 followed by a white space character (namely HTAB ASCII decimal 9 or 275 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., 276 the CRLF and single white space character are removed). 278 Note: It is possible for very simple implementations to generate 279 improperly folded lines in the middle of a UTF-8 multi-octet 280 sequence. For this reason, implementations SHOULD unfold lines in 281 such a way as to properly restore the original sequence. 283 Note: Unfolding is done differently than in [RFC5322]. Unfolding 284 in [RFC5322] only removes the CRLF, not the space following it. 286 Folding is done after any content encoding of a type value. 287 Unfolding is done before any decoding of a type value in a content 288 line. 290 3.3. ABNF Format Definition 292 The following ABNF uses the notation of [RFC5234], which also defines 293 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. 295 vcard-entity = 1*(vcard) 297 vcard = "BEGIN" ":" "VCARD" CRLF 298 "VERSION" ":" "4.0" CRLF 299 1*contentline 300 "END" ":" "VCARD" CRLF 301 ; A vCard object MUST include the VERSION and FN properties. 302 ; VERSION MUST come immediately after BEGIN:VCARD. 304 contentline = [group "."] name *(";" param) ":" value CRLF 305 ; When parsing a content line, folded lines must first 306 ; be unfolded according to the unfolding procedure 307 ; described above. 309 ; When generating a content line, lines longer than 75 310 ; characters SHOULD be folded according to the folding 311 ; procedure described above. 313 group = 1*(ALPHA / DIGIT / "-") 314 name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME" 315 / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / / "TEL" 316 / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE" 317 / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES" 318 / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP" 319 / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML" 320 / iana-token / x-name 321 ; Parsing of the param and value is based on the "name" as 322 ; defined in ABNF sections below. 323 ; Group and name are case-insensitive. 325 iana-token = 1*(ALPHA / DIGIT / "-") 326 ; identifier registered with IANA 328 x-name = "x-" 1*(ALPHA / DIGIT / "-") 329 ; Names that begin with "x-" or "X-" are 330 ; reserved for experimental use, not intended for released 331 ; products, or for use in bilateral agreements. 333 param = language-param / value-param / pref-param / pid-param 334 / type-param / geo-param / tz-param / sort-as-param 335 / calscale-param / version-param / any-param 336 ; Allowed parameters depend on property name. 338 param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE 340 any-param = (iana-token / x-name) "=" param-value *("," param-value) 342 NON-ASCII = %x80-FF 343 ; Use is restricted by UTF-8 345 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII 346 ; Any character except CTLs, DQUOTE 348 SAFE-CHAR = WSP / %x21 / %x23-39 / %x3C-7E / NON-ASCII 349 ; Any character except CTLs, DQUOTE, ";", ":" 351 VALUE-CHAR = WSP / VCHAR / NON-ASCII 352 ; Any textual character 354 A line that begins with a white space character is a continuation of 355 the previous line, as described above. The white space character and 356 immediately preceeding CRLF should be discarded when reconstructing 357 the original line. Note that this line-folding convention differs 358 from that found in [RFC5322], in that the sequence found 359 anywhere in the content indicates a continued line and should be 360 removed. 362 Property names and parameter names are case insensitive (e.g., the 363 property name "fn" is the same as "FN" and "Fn"). Parameter values 364 MAY be case sensitive or case insensitive, depending on their 365 definition. Based on experience with vCard 3 interoperability, it is 366 RECOMMENDED that property and parameter names be upper-case on 367 output. 369 The group construct is used to group related properties together. 370 The group name is a syntactic convention used to indicate that all 371 property names prefaced with the same group name SHOULD be grouped 372 together when displayed by an application. It has no other 373 significance. Implementations that do not understand or support 374 grouping MAY simply strip off any text before a "." to the left of 375 the type name and present the types and values as normal. 377 Property cardinalities are indicated using the following notation, 378 which is based on ABNF (see [RFC5234], section 3.6): 380 +-------------+--------------------------------------------------+ 381 | Cardinality | Meaning | 382 +-------------+--------------------------------------------------+ 383 | 1 | Exactly one instance per vCard MUST be present. | 384 | *1 | Exactly one instance per vCard MAY be present. | 385 | 1* | One or more instances per vCard MUST be present. | 386 | * | One or more instances per vCard MAY be present. | 387 +-------------+--------------------------------------------------+ 389 Properties defined in a vCard instance may have multiple values 390 depending on the property cardinality. The general rule for encoding 391 multi-valued properties is to simply create a new content line for 392 each value (including the property name). However, it should be 393 noted that some value types support encoding multiple values in a 394 single content line by separating the values with a comma ",". This 395 approach has been taken for several of the content types defined 396 below (date, time, integer, float). 398 3.4. Property Value Escaping 400 Some properties may contain one or more values delimited by a COMMA 401 character (ASCII decimal 44). Therefore, a COMMA character in a 402 value MUST be escaped with a BACKSLASH character (ASCII decimal 92), 403 even for properties that don't allow multiple instances (for 404 consistency). 406 Some properties (e.g. N and ADR) comprise multiple fields delimited 407 by a SEMI-COLON character (ASCII decimal 59). Therefore, a SEMI- 408 COLON in a field of such a "compound" property MUST be escaped with a 409 BACKSLASH character. SEMI-COLON characters in non-compound 410 properties MAY be escaped. On input, an escaped SEMI-COLON character 411 is never a field separator. An unescaped SEMI-COLON character may be 412 a field separator, depending on the property in which it appears. 414 Furthermore, some fields of compound properties may contain a list of 415 values delimited by a COMMA character. Therefore, a COMMA character 416 in one of a field's values MUST be escaped with a BACKSLASH 417 character, even for fields that don't allow multiple values (for 418 consistency). Compound properties allowing multiple instances MUST 419 NOT be encoded in a single content line. 421 Finally, BACKSLASH characters in values MUST be escaped with a 422 BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values 423 MUST be encoded by two characters: a BACKSLASH followed by an 'n' 424 (ASCII decimal 110). 426 In all other cases, escaping MUST NOT be used. 428 4. Property Value Data Types 430 Standard value types are defined below. 432 value = text 433 / text-list 434 / date-list 435 / time-list 436 / date-time-list 437 / date-and-or-time-list 438 / timestamp-list 439 / boolean 440 / integer-list 441 / float-list 442 / URI ; from Section 3 of [RFC3986] 443 / iana-valuespec 444 ; Actual value type depends on property name and VALUE parameter. 446 text = *TEXT-CHAR 448 TEXT-CHAR = "\\" / "\," / "\n" 449 / 450 ; Backslashes, commas, and newlines must be encoded. 452 component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII 453 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E 455 list-component = component *("," component) 457 text-list = text *("," text) 458 date-list = date *("," date) 459 time-list = time *("," time) 460 date-time-list = date-time *("," date-time) 461 date-and-or-time-list = date-and-or-time *("," date-and-or-time) 462 timestamp-list = timestamp *("," timestamp) 463 integer-list = integer *("," integer) 464 float-list = float *("," float) 466 boolean = "TRUE" / "FALSE" 467 integer = [sign] 1*DIGIT 468 float = [sign] 1*DIGIT ["." 1*DIGIT] 470 sign = "+" / "-" 472 year = 4DIGIT ; 0000-9999 473 month = 2DIGIT ; 01-12 474 day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year 475 hour = 2DIGIT ; 00-23 476 minute = 2DIGIT ; 00-59 477 second = 2DIGIT ; 00-58/59/60 depending on leap second 478 zone = utc-designator / utc-offset 479 utc-designator = %d90 ; uppercase "Z" 481 date = year [month day] 482 / year "-" month 483 / "--" month [day] 484 / "--" "-" day 485 date-noreduc = year month day 486 / "--" month day 487 / "--" "-" day 488 date-complete = year month day 490 time = hour [minute [second]] [zone] 491 / "-" minute [second] [zone] 492 / "-" "-" second [zone] 493 time-notrunc = hour [minute [second]] [zone] 494 time-complete = hour minute second [zone] 496 time-designator = %d84 ; uppercase "T" 497 date-time = date-noreduc time-designator time-notrunc 498 timestamp = date-complete time-designator time-complete 500 date-and-or-time = date-time / date / time-designator time 502 utc-offset = sign hour [minute] 503 Language-Tag = 505 iana-valuespec = 506 ; a publicly-defined valuetype format, registered 507 ; with IANA, as defined in section 12 of this 508 ; document 510 4.1. TEXT 512 "text": The "text" value type should be used to identify values that 513 contain human-readable text. As for the language, it is controlled 514 by the LANGUAGE property parameter defined in Section 5.1. 516 Examples for "text": 518 this is a text value 519 this is one value,this is another 520 this is a single value\, with a comma encoded 522 A formatted text line break in a text value type MUST be represented 523 as the character sequence backslash (ASCII decimal 92) followed by a 524 Latin small letter n (ASCII decimal 110) or a Latin capital letter N 525 (ASCII decimal 78), that is "\n" or "\N". 527 For example a multiple line NOTE value of: 529 Mythical Manager 530 Hyjinx Software Division 531 BabsCo, Inc. 533 could be represented as: 535 NOTE:Mythical Manager\nHyjinx Software Division\n 536 BabsCo\, Inc.\n 538 demonstrating the \n literal formatted line break technique, the 539 CRLF-followed-by-space line folding technique, and the backslash 540 escape technique. 542 4.2. URI 544 "uri": The "uri" value type should be used to identify values that 545 are referenced by a URI (including a Content-ID URI), instead of 546 encoded in-line. These value references might be used if the value 547 is too large, or otherwise undesirable to include directly. The 548 format for the URI is as defined in Section 3 of [RFC3986]. Note 549 that the value of a property of type "uri" is what the URI points to, 550 not the URI itself. 552 Examples for "uri": 554 http://www.example.com/my/picture.jpg 555 ldap://ldap.example.com/cn=babs%20jensen 557 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP 559 "date", "time", "date-time", and "timestamp": Each of these value 560 types is based on the definitions in [ISO.8601.2004] standard. 561 Multiple such values can be specified using the comma-separated 562 notation. 564 Only the basic format is supported. 566 4.3.1. DATE 568 A calendar date as specified in [ISO.8601.2004] section 4.1.2. 570 Reduced accuracy, as specified in [ISO.8601.2004] sections 4.1.2.3 a) 571 and b), but not c), is permitted. 573 Expanded representation, as specified in [ISO.8601.2004] section 574 4.1.4, is forbidden. 576 Truncated representation, as specified in [ISO.8601.2000] sections 577 5.2.1.3 d), e), and f), is permitted. 579 Examples for "date": 581 19850412 582 1985-04 583 1985 584 --0412 585 ---12 587 Note the use of YYYY-MM in the second example above. YYYYMM is 588 disallowed to prevent confusion with YYMMDD. Note also that 589 YYYY-MM-DD is disallowed since we are using the basic format instead 590 of the extended format. 592 4.3.2. TIME 594 A time of day as specified in [ISO.8601.2004] section 4.2. 596 Reduced accuracy, as specified in [ISO.8601.2004] section 4.2.2.3, is 597 permitted. 599 Representation with decimal fraction, as specified in [ISO.8601.2004] 600 section 4.2.2.4, is forbidden. 602 The midnight hour is always represented by 00, never 24 (see 603 [ISO.8601.2004] section 4.2.3). 605 Truncated representation, as specified in [ISO.8601.2000] sections 606 5.3.1.4 a), b), and c), is permitted. 608 Examples for "time": 610 102200 611 1022 612 10 613 -2200 614 --00 615 102200Z 616 102200-0800 618 4.3.3. DATE-TIME 620 A date and time of day combination as specified in [ISO.8601.2004] 621 section 4.3. 623 Truncation of the date part, as specified in [ISO.8601.2000] section 624 5.4.2 c), is permitted. 626 Examples for "date-time": 628 19961022T140000 629 --1022T1400 630 ---22T14 632 4.3.4. DATE-AND-OR-TIME 634 Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous 635 interpretation, a standalone TIME value is always preceded by a "T". 637 Examples for "date-and-or-time": 639 19961022T140000 640 --1022T1400 641 ---22T14 642 19850412 643 1985-04 644 1985 645 --0412 646 ---12 647 T102200 648 T1022 649 T10 650 T-2200 651 T--00 652 T102200Z 653 T102200-0800 655 4.3.5. TIMESTAMP 657 A complete date and time of day combination as specified in 658 [ISO.8601.2004] section 4.3.2. 660 Examples for "timestamp": 662 19961022T140000 663 19961022T140000Z 664 19961022T140000-05 665 19961022T140000-0500 667 4.4. BOOLEAN 669 "boolean": The "boolean" value type is used to express boolean 670 values. These values are case insensitive. 672 Examples: 674 TRUE 675 false 676 True 678 4.5. INTEGER 680 "integer": The "integer" value type is used to express signed 681 integers in decimal format. If sign is not specified, the value is 682 assumed positive "+". Multiple "integer" values can be specified 683 using the comma-separated notation. 685 Examples: 687 1234567890 688 -1234556790 689 +1234556790,432109876 691 4.6. FLOAT 693 "float": The "float" value type is used to express real numbers. If 694 sign is not specified, the value is assumed positive "+". Multiple 695 "float" values can be specified using the comma-separated notation. 697 Note: Scientific notation is disallowed. Implementors wishing to 698 use their favorite language's %f formatting should be careful. 700 Examples: 702 20.30 703 1000000.0000001 704 1.333,3.14 706 4.7. LANGUAGE-TAG 708 "language-tag": A single language tag, as defined in [RFC5646]. 710 5. Property Parameters 712 A property can have attributes associated with it. These "property 713 parameters" contain meta-information about the property or the 714 property value. In some cases the property parameter can be multi- 715 valued in which case the property parameter value elements are 716 separated by a COMMA (US-ASCII decimal 44). 718 Property parameter value elements that contain the COLON (US-ASCII 719 decimal 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII 720 decimal 44) character separators MUST be specified as quoted-string 721 text values. Property parameter values MUST NOT contain the DQUOTE 722 (US-ASCII decimal 34) character. The DQUOTE character is used as a 723 delimiter for parameter values that contain restricted characters or 724 URI text. 726 Applications MUST ignore x-param and iana-param values they don't 727 recognize. 729 5.1. LANGUAGE 731 The LANGUAGE property parameter is used to identify data in multiple 732 languages. There is no concept of "default" language, except as 733 specified by any "Content-Language" MIME header parameter that is 734 present [RFC3282]. The value of the LANGUAGE property parameter is a 735 language tag as defined in Section 2 of [RFC5646]. 737 Examples: 739 ROLE;LANGUAGE=tr:hoca 741 ABNF: 743 language-param = "LANGUAGE=" Language-Tag 744 ; Language-Tag is defined in section 2.1 of RFC 5646 746 5.2. VALUE 748 The VALUE parameter is optional, and is used to identify the value 749 type (data type) and format of the value. The use of these 750 predefined formats is encouraged even if the value parameter is not 751 explicitly used. By defining a standard set of value types and their 752 formats, existing parsing and processing code can be leveraged. The 753 predefined data type values MUST NOT be repeated in COMMA separated 754 value lists except within the N, NICKNAME, ADR and CATEGORIES 755 properties. 757 ABNF: 759 value-param = "VALUE=" value-type 761 value-type = "text" 762 / "uri" 763 / "date" 764 / "time" 765 / "date-time" 766 / "timestamp" 767 / "boolean" 768 / "integer" 769 / "float" 770 / "language-tag" 771 / "utc-offset" 772 / iana-token ; registered as described in section 12 773 / x-name 775 5.3. PREF 777 The PREF parameter is optional, and is used to indicate that the 778 corresponding instance of a property is preferred by the vCard 779 author. Its value MUST be an integer between 1 and 100 that 780 quantifies the level of preference. Lower values correspond to a 781 higher level of preference, 1 being most preferred. 783 When the parameter is absent, the default MUST be to interpret the 784 property instance as being least preferred. 786 Note that the value of this parameter is to be interpreted only in 787 relation to values assigned to other instances of the same property 788 in the same vCard. A given value, or the absence of a value, MUST 789 NOT be interpreted on its own. 791 This parameter MAY be applied to any property that allows multiple 792 instances. 794 ABNF: 796 pref-param = "PREF=" (1*2DIGIT / "100") 797 ; An integer between 1 and 100. 799 5.4. ALTID 801 The ALTID parameter is used to "tag" property instances as being 802 alternative representations of the same logical property. For 803 example, translations of a property in multiple languages generates 804 multiple property instances having different LANGUAGE (Section 5.1) 805 parameter which are tagged with the same ALTID value. 807 This parameter's value is treated as an opaque string. Its sole 808 purpose is to be compared for equality against other ALTID parameter 809 values. 811 Two property instances are considered alternative representations of 812 the same logical property if and only if their names as well as the 813 value of their ALTID parameters are identical. Property instances 814 without the ALTID parameter MUST NOT be considered an alternative 815 representation of any other property instance. Values for the ALTID 816 parameter are not globally unique: they MAY be reused for different 817 property names. 819 Property instances having the same ALTID parameter value count as 1 820 toward cardinality. Therefore, since N (Section 6.2.2) has 821 cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these 822 three examples would be legal: 824 N;ALTID=1;LANGUAGE=jp:;;;; 825 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 826 ( denotes a UTF8-encoded Unicode character.) 828 TITLE;ALTID=1;LANGUAGE=fr:Patron 829 TITLE;ALTID=1;LANGUAGE=en:Boss 831 TITLE;ALTID=1;LANGUAGE=fr:Patron 832 TITLE;ALTID=1;LANGUAGE=en:Boss 833 TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist 835 while this one would not: 837 N;ALTID=1;LANGUAGE=jp:;;;; 838 N:Yamada;Taro;;; 839 (Two instances of the N property.) 841 and these three would be legal but questionable: 843 TITLE;ALTID=1;LANGUAGE=fr:Patron 844 TITLE;ALTID=2;LANGUAGE=en:Boss 845 (Should probably have the same ALTID value.) 847 TITLE;ALTID=1;LANGUAGE=fr:Patron 848 TITLE:LANGUAGE=en:Boss 849 (Second line should probably have ALTID=1.) 851 N;ALTID=1;LANGUAGE=jp:;;;; 852 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 853 N;ALTID=1;LANGUAGE=en:Smith;John;;; 854 (The last line should probably have ALTID=2. But that would be 855 illegal because N has cardinality *1.) 857 The ALTID property MAY also be used in may contexts other than with 858 the LANGUAGE parameter. Here's an example with two representations 859 of the same photo in different file formats: 861 PHOTO;ALTID=1:data:image/jpeg;base64,... 862 PHOTO;ALTID=1;data:image/jp2;base64,... 864 ABNF: 866 altid-param = "ALTID=" param-value 868 5.5. PID 870 The PID parameter is used to identify a specific property among 871 multiple instances. It plays a role analogous to the UID property 872 (Section 6.7.6) on a per-property instead of per-vCard basis. It MAY 873 appear more than once in a given property. It MUST NOT appear on 874 properties that may have only one instance per vCard. Its value is 875 either a single small positive integer, or a pair of small positive 876 integers separated by a dot. Multiple values may be encoded in a 877 single PID parameter by separating the values with a comma ",". See 878 Section 7 for more details on its usage. 880 ABNF: 882 pid-param = "PID=" pid-value *("," pid-value) 883 pid-value = 1*DIGIT ["." 1*DIGIT] 885 5.6. TYPE 887 The TYPE parameter has multiple, different uses. In general, it is a 888 way of specifying class characteristics of the associated property. 889 Most of the time, its value is a comma-separated subset of a pre- 890 defined enumeration. In this document, the following properties make 891 use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL, IMPP, 892 LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES, NOTE, 893 SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE parameter 894 MUST NOT be applied on other properties defined in this document. 896 The "work" and "home" values act like tags. The "work" value implies 897 that the property is related to an individual's work place, while the 898 "home" value implies that the property is related to an individual's 899 personal life. When neither "work" nor "home" is present, it is 900 implied that the property is related to both an individual's work 901 place and personal life in the case that the KIND property's value is 902 "individual", or to none in other cases. 904 ABNF: 906 type-param = "TYPE=" type-value *("," type-value) 908 type-value = "work" / "home" / type-param-tel 909 / type-param-related / iana-token / x-name 910 ; This is further defined in individual property sections. 912 5.7. MEDIATYPE 914 The MEDIATYPE parameter is used with properties whose value is a URI. 915 Its use is OPTIONAL. It provides a hint to the vCard consumer 916 application about the media type of the resource identified by the 917 URI. Some URI schemes do not need this parameter. For example, the 918 "data" scheme allows the media type to be explicitly indicated as 919 part of the URI [RFC2397]. Another scheme, "http", provides the 920 media type as part of the URI resolution process, with the Content- 921 Type HTTP header [RFC2616]. The MEDIATYPE parameter is intended to 922 be used with URI schemes that do not provide such functionality (e.g. 923 "ftp" [RFC1738]). 925 ABNF: 927 mediatype-param = "MEDIATYPE=" mediatype 928 mediatype = type "/" subtype *( ";" attribute "=" value ) 929 ; "type", "subtype", "attribute", and "value" are from [RFC2045]. 931 5.8. CALSCALE 933 The CALSCALE parameter is identical to the CALSCALE property in 934 iCalendar (see [RFC5545], section 3.7.1). It is used to define the 935 calendar system in which a date or date-time value is expressed. The 936 only value specified by iCalendar is "gregorian", which stands for 937 the Gregorian system. It is the default when the parameter is 938 absent. Additional values may be defined in extension documents and 939 registered from IANA (see Section 10.3.4). A vCard implementation 940 MUST ignore properties with a CALSCALE parameter value that it does 941 not understand. 943 ABNF: 945 calscale-param = "CALSCALE=" calscale-value 947 calscale-value = "gregorian" / iana-token / x-name 949 5.9. SORT-AS 951 The "sort-as" parameter is used to specify the string to be used for 952 national-language-specific sorting. Without this information, 953 sorting algorithms could incorrectly sort this vCard within a 954 sequence of sorted vCards. When this property is present in a vCard, 955 then the given strings are used for sorting the vCard. 957 This parameter's value is a comma-separated list which MUST have as 958 many or less elements as the corresponding property value has 959 components. 961 ABNF: 963 sort-as-param = "SORT-AS=" sort-as-value 965 sort-as-value = param-value *("," param-value) 967 Examples: For the case of surname and given name sorting, the 968 following examples define common sort string usage with the N 969 property. 971 FN:Rene van der Harten 972 N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N. 974 FN:Robert Pau Shou Chang 975 N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;; 977 FN:Osamu Koura 978 N;SORT-AS="Koura,Osamu":Koura;Osamu;; 980 FN:Oscar del Pozo 981 N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;; 983 FN:Chistine d'Aboville 984 N;SORT-AS="Aboville,Christine":d'Aboville;Christine;; 986 FN:H. James de Mann 987 N;SORT-AS="Mann,James":de Mann;Henry,James;; 989 If sorted by surname the results would be: 991 Christine d'Aboville 992 Rene van der Harten 993 Osamu Koura 994 H. James de Mann 995 Robert Pau Shou Chang 996 Oscar del Pozo 998 If sorted by given name the results would be: 1000 Christine d'Aboville 1001 H. James de Mann 1002 Osamu Koura 1003 Oscar del Pozo 1004 Rene van der Harten 1005 Robert Pau Shou Chang 1007 5.10. GEO 1009 The GEO parameter can be used to indicate global positioning 1010 information that is specific to an address. Its value is the same as 1011 that of the GEO property (see Section 6.5.2). 1013 ABNF: 1015 geo-param = "GEO=" DQUOTE uri DQUOTE 1017 5.11. TZ 1019 The TZ parameter can be used to indicate time zone information that 1020 is specific to an address. Its value is the same as that of the TZ 1021 property. 1023 ABNF: 1025 tz-param = "TZ=" (param-value / DQUOTE uri DQUOTE) 1027 6. vCard Properties 1029 What follows is an enumeration of the standard vCard properties. 1031 6.1. General Properties 1033 6.1.1. BEGIN 1035 Purpose: To denote the beginning of a syntactic entity within a 1036 text/vcard content-type. 1038 Value type: text 1040 Cardinality: 1 1042 Special notes: The content entity MUST begin with the BEGIN property 1043 with a value of "VCARD". The value is case-insensitive. 1045 The BEGIN property is used in conjunction with the END property to 1046 delimit an entity containing a related set of properties within an 1047 text/vcard content-type. This construct can be used instead of or 1048 in addition to wrapping separate sets of information inside 1049 additional MIME headers. It is provided for applications that 1050 wish to define content that can contain multiple entities within 1051 the same text/vcard content-type or to define content that can be 1052 identifiable outside of a MIME environment. 1054 ABNF: 1056 BEGIN-param = ; no parameter allowed 1057 BEGIN-value = "VCARD" 1059 Example: 1061 BEGIN:VCARD 1063 6.1.2. END 1065 Purpose: To denote the end of a syntactic entity within a text/vcard 1066 content-type. 1068 Value type: text 1070 Cardinality: 1 1072 Special notes: The content entity MUST end with the END type with a 1073 value of "VCARD". The value is case-insensitive. 1075 The END property is used in conjunction with the BEGIN property to 1076 delimit an entity containing a related set of properties within an 1077 text/vcard content-type. This construct can be used instead of or 1078 in addition to wrapping separate sets of information inside 1079 additional MIME headers. It is provided for applications that 1080 wish to define content that can contain multiple entities within 1081 the same text/vcard content-type or to define content that can be 1082 identifiable outside of a MIME environment. 1084 ABNF: 1086 END-param = ; no parameter allowed 1087 END-value = "VCARD" 1089 Example: 1091 END:VCARD 1093 6.1.3. SOURCE 1095 Purpose: To identify the source of directory information contained 1096 in the content type. 1098 Value type: uri 1099 Cardinality: * 1101 Special notes: The SOURCE property is used to provide the means by 1102 which applications knowledgable in the given directory service 1103 protocol can obtain additional or more up-to-date information from 1104 the directory service. It contains a URI as defined in [RFC3986] 1105 and/or other information referencing the vCard to which the 1106 information pertains. When directory information is available 1107 from more than one source, the sending entity can pick what it 1108 considers to be the best source, or multiple SOURCE properties can 1109 be included. 1111 ABNF: 1113 SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param 1114 / mediatype-param / any-param 1115 SOURCE-value = uri 1117 Examples: 1119 SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US 1121 SOURCE:http://directory.example.com/addressbooks/jdoe/ 1122 Jean%20Dupont.vcf 1124 6.1.4. KIND 1126 Purpose: To specify the kind of object the vCard represents. 1128 Value type: A single text value. 1130 Cardinality: *1 1132 Special notes: The value may be one of the following: 1134 * for a vCard representing a single person or entity. This is 1135 the default kind of vCard. 1137 * for a vCard representing a group of persons or entities. The 1138 group's member entities can be other vCards or other types of 1139 entities, such as email addresses or web sites. A group vCard 1140 will usually contain MEMBER properties to specify the members 1141 of the group, but it is not required to. A group vCard without 1142 MEMBER properties can be considered an abstract grouping, or 1143 one whose members are known empirically (perhaps "IETF 1144 Participants" or "Republican U.S. Senators"). 1146 * All properties in a group vCard apply to the group as a whole, 1147 and not to any particular MEMBER. For example, an EMAIL 1148 property might specify the address of a mailing list associated 1149 with the group, and an IMPP property might refer to a group 1150 chat room. 1152 * for a vCard representing an organization. An organization 1153 vCard will not (in fact, MUST NOT) contain MEMBER properties, 1154 and so these are something of a cross between "individual" and 1155 "group". An organization is a single entity, but not a person. 1156 It might represent a business or government, a department or 1157 division within a business or government, a club, an 1158 association, or the like. 1160 * All properties in an organization vCard apply to the 1161 organization as a whole, as is the case with a group vCard. 1162 For example, an EMAIL property might specify the address of a 1163 contact point for the organization. 1165 * for a named geographical place. A location vCard will usually 1166 contain a GEO property, but it is not required to. A location 1167 vCard without a GEO property can be considered an abstract 1168 location, or one whose definition is known empirically (perhaps 1169 "New England" or "The Seashore"). 1171 * All properties in an location vCard apply to the location 1172 itself, and not with any entity that might exist at that 1173 location. For example, in a vCard for an office building, an 1174 ADR property might give the mailing address for the building, 1175 and a TEL property might specify the telephone number of the 1176 receptionist. 1178 * vCards MAY include private or experimental values for KIND. 1179 Remember that x-name values are not intended for general use, 1180 and are unlikely to interoperate. 1182 * Additional values may be registered with IANA (see 1183 Section 10.3.4). A new value's specification document MUST 1184 specify which properties make sense for that new kind of vCard, 1185 and which do not. 1187 Implementations MUST support the specific string values defined 1188 above. If this property is absent, "individual" MUST be assumed 1189 as the default. If this property is present but the 1190 implementation does not understand its value (the value is an 1191 x-name or iana-token that the implementation does not support), 1192 the implementation SHOULD act in a neutral way, which usually 1193 means treating the vCard as though its kind were "individual". 1195 The presence of MEMBER properties MAY, however, be taken as an 1196 indication that the unknown kind is an extension of "group". 1198 Clients often need to visually distinguish contacts based on what 1199 they represent, and the KIND property provides a direct way for 1200 them to do so. For example, when displaying contacts in a list, 1201 an icon could be displayed next to each one, using distinctive 1202 icons for the different kinds; a client might use an outline of a 1203 single person to represent an "individual", an outline of multiple 1204 people to represent a "group", and so on. Alternatively, or in 1205 addition, a client might choose to segregate different kinds of 1206 vCards to different panes, tabs, or selections in the user 1207 interface. 1209 Some clients might also make functional distinctions among the 1210 kinds, ignoring "location" vCards for some purposes and 1211 considering only "location" vCards for others. 1213 When designing those sorts of visual and functional distinctions, 1214 client implementations have to decide how to fit unsupported kinds 1215 into the scheme. What icon is used for them? The one for 1216 "individual"? A unique one, such as an icon of a question-mark? 1217 Which tab do they go into? It is beyond the scope of this 1218 specification to answer these questions, but these are things 1219 implementors need to consider. 1221 ABNF: 1223 KIND-param = "VALUE=text" / any-param 1224 KIND-value = "individual" / "group" / "org" / "location" 1225 / iana-token / x-name 1227 Example: 1229 This represents someone named Jane Doe working in the marketing 1230 department of the North American division of ABC Inc. 1232 BEGIN:VCARD 1233 VERSION:4.0 1234 KIND:individual 1235 FN:Jane Doe 1236 ORG:ABC\, Inc.;North American Division;Marketing 1237 END:VCARD 1239 This represents the department itself, commonly known as ABC 1240 Marketing. 1242 BEGIN:VCARD 1243 VERSION:4.0 1244 KIND:org 1245 FN:ABC Marketing 1246 ORG:ABC\, Inc.;North American Division;Marketing 1247 END:VCARD 1249 6.1.5. XML 1251 Purpose: To include extended XML-encoded vCard data in a plain 1252 vCard. 1254 Value type: A single text value. 1256 Cardinality: * 1258 Special notes: The content of this property is a single XML 1.0 1259 [W3C.REC-xml-20081126] element whose namespace MUST be explicitly 1260 specified using the xmlns attribute and MUST NOT be the vCard 4 1261 namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies 1262 that it cannot duplicate a standard vCard property.) The element 1263 is to be interpreted as if it was contained in a element, 1264 as defined in [I-D.ietf-vcarddav-vcardxml]. 1266 The fragment is subject to normal line folding and escaping, i.e. 1267 replace all backslashes with "\\", then replace all newlines with 1268 "\n", then fold long lines. 1270 Support for this property is OPTIONAL, but implementations of this 1271 specification MUST preserve instances of this property when 1272 propagating vCards. 1274 See [I-D.ietf-vcarddav-vcardxml] for more information on the 1275 intended use of this property. 1277 ABNF: 1279 XML-param = "VALUE=text" / altid-param 1280 XML-value = text 1282 6.2. Identification Properties 1284 These types are used to capture information associated with the 1285 identification and naming of the entity associated with the vCard. 1287 6.2.1. FN 1289 Purpose: To specify the formatted text corresponding to the name of 1290 the object the vCard represents. 1292 Value type: A single text value. 1294 Cardinality: 1* 1296 Special notes: This property is based on the semantics of the X.520 1297 Common Name attribute. The property MUST be present in the vCard 1298 object. 1300 ABNF: 1302 FN-param = "VALUE=text" / type-param / language-param / altid-param 1303 / pid-param / pref-param / any-param 1304 FN-value = text 1306 Example: 1308 FN:Mr. John Q. Public\, Esq. 1310 6.2.2. N 1312 Purpose: To specify the components of the name of the object the 1313 vCard represents. 1315 Value type: A single structured text value. Each component can have 1316 multiple values. 1318 Cardinality: *1 1320 Special note: The structured property value corresponds, in 1321 sequence, to the Family Names (also known as surnames), Given 1322 Names, Additional Names, Honorific Prefixes, and Honorific 1323 Suffixes. The text components are separated by the SEMI-COLON 1324 character (ASCII decimal 59). Individual text components can 1325 include multiple text values separated by the COMMA character 1326 (ASCII decimal 44). This property is based on the semantics of 1327 the X.520 individual name attributes. The property SHOULD be 1328 present in the vCard object when the name of the object the vCard 1329 represents follows the X.520 model. 1331 The SORT-AS parameter MAY be applied to this property. 1333 ABNF: 1335 N-param = "VALUE=text" / sort-as-param / language-param 1336 / altid-param / any-param 1337 N-value = list-component 4(";" list-component) 1339 Examples: 1341 N:Public;John;Quinlan;Mr.;Esq. 1343 N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P. 1345 6.2.3. NICKNAME 1347 Purpose: To specify the text corresponding to the nickname of the 1348 object the vCard represents. 1350 Value type: One or more text values separated by a COMMA character 1351 (ASCII decimal 44). 1353 Cardinality: * 1355 Special note: The nickname is the descriptive name given instead of 1356 or in addition to the one belonging to a the object the vCard 1357 represents. It can also be used to specify a familiar form of a 1358 proper name specified by the FN or N properties. 1360 ABNF: 1362 NICKNAME-param = "VALUE=text" / type-param / language-param 1363 / altid-param / pid-param / pref-param / any-param 1364 NICKNAME-value = text-list 1366 Examples: 1368 NICKNAME:Robbie 1370 NICKNAME:Jim,Jimmie 1372 NICKNAME;TYPE=work:Boss 1374 6.2.4. PHOTO 1376 Purpose: To specify an image or photograph information that 1377 annotates some aspect of the object the vCard represents. 1379 Value type: A single URI. 1381 Cardinality: * 1383 ABNF: 1385 PHOTO-param = "VALUE=uri" / altid-param / type-param 1386 / mediatype-param 1387 PHOTO-value = uri 1389 Examples: 1391 PHOTO:http://www.example.com/pub/photos/jqpublic.gif 1393 PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv 1394 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1395 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1396 <...remainder of base64-encoded data...> 1398 6.2.5. BDAY 1400 Purpose: To specify the birth date of the object the vCard 1401 represents. 1403 Value type: The default is a single date-and-or-time value. It can 1404 also be reset to a single text value. 1406 Cardinality: *1 1408 ABNF: 1410 BDAY-param = BDAY-param-date / BDAY-param-text 1411 BDAY-value = date-and-or-time / text 1412 ; Value and parameter MUST match. 1414 BDAY-param-date = "VALUE=date-and-or-time" 1415 BDAY-param-text = "VALUE=text" / language-param 1417 BDAY-param =/ altid-param / calscale-param / any-param 1418 ; calscale-param can only be present when BDAY-value is 1419 ; date-and-or-time and actually contains a date or date-time. 1421 Examples: 1423 BDAY:19960415 1424 BDAY:--0415 1425 BDAY;19531015T231000Z 1426 BDAY;VALUE=text:circa 1800 1428 6.2.6. ANNIVERSARY 1430 Purpose: The date of marriage, or equivalent, of the object the 1431 vCard represents. 1433 Value type: The default is a single date-and-or-time value. It can 1434 also be reset to a single text value. 1436 Cardinality: *1 1438 ABNF: 1440 ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text") 1441 ANNIVERSARY-value = date-and-or-time / text 1442 ; Value and parameter MUST match. 1444 ANNIVERSARY-param =/ altid-param / calscale-param / any-param 1445 ; calscale-param can only be present when ANNIVERSARY-value is 1446 ; date-and-or-time and actually contains a date or date-time. 1448 Examples: 1450 ANNIVERSARY:19960415 1452 6.2.7. GENDER 1454 Purpose: To specify the components of the sex and gender identity of 1455 the object the vCard represents. 1457 Value type: A single structured value with two components. Each 1458 component has a single text value. 1460 Cardinality: *1 1462 Special notes: The components correspond, in sequence, to the sex 1463 (biological), and gender identity. Each component is optional. 1465 Sex component: A single letter. M stands for "male", F stands 1466 for "female", O stands for "other", N stands for "none or not 1467 applicable", U stands for "unknown". 1469 Gender identity component: Free-form text. 1471 ABNF: 1473 GENDER-param = "VALUE=text" / any-param 1474 GENDER-value = sex [";" text] 1475 sex = "" / "M" / "F" / "O" / "N" / "U" 1477 Examples: 1479 GENDER:M 1480 GENDER:F 1481 GENDER:M;Fellow 1482 GENDER:F;Bird 1483 GENDER:O;intersex 1484 GENDER:;queer 1486 6.3. Delivery Addressing Properties 1488 These types are concerned with information related to the delivery 1489 addressing or label for the vCard object. 1491 6.3.1. ADR 1493 Purpose: To specify the components of the delivery address for the 1494 vCard object. 1496 Value type: A single structured text value, separated by the SEMI- 1497 COLON character (ASCII decimal 59). 1499 Cardinality: * 1501 Special notes: The structured type value consists of a sequence of 1502 address components. The component values MUST be specified in 1503 their corresponding position. The structured type value 1504 corresponds, in sequence, to the post office box; the extended 1505 address (e.g. apartment or suite number); the street address; the 1506 locality (e.g., city); the region (e.g., state or province); the 1507 postal code; the country name (full name in the language specified 1508 in Section 5.1). When a component value is missing, the 1509 associated component separator MUST still be specified. 1511 Experience with vCard 3 has shown that the first two components 1512 (post office box and extended address) are plagued with many 1513 interoperability issues. To ensure maximal interoperability, 1514 their values SHOULD be empty. 1516 The text components are separated by the SEMI-COLON character 1517 (ASCII decimal 59). Where it makes semantic sense, individual 1518 text components can include multiple text values (e.g., a "street" 1519 component with multiple lines) separated by the COMMA character 1520 (ASCII decimal 44). 1522 The property can include the "PREF" parameter to indicate the 1523 preferred delivery address when more than one address is 1524 specified. 1526 The GEO and TZ parameters MAY be used with this property. 1528 The property can also include a "LABEL" parameter to present a 1529 delivery delivery address label for the address. Its value is a 1530 plain-text string representing the formatted address. Newlines 1531 are encoded as \n, as they are for property values. 1533 ABNF: 1535 label-param = "LABEL=" param-value 1537 ADR-param = "VALUE=text" / label-param / language-param / geo-param 1538 / tz-param / altid-param / pid-param / pref-param 1539 / type-param / any-param 1540 ADR-value = ADR-component-pobox ";" ADR-component-ext ";" 1541 ADR-component-street ";" ADR-component-locality ";" 1542 ADR-component-region ";" ADR-component-code ";" 1543 ADR-component-country 1544 ADR-component-pobox = list-component 1545 ADR-component-ext = list-component 1546 ADR-component-street = list-component 1547 ADR-component-locality = list-component 1548 ADR-component-region = list-component 1549 ADR-component-code = list-component 1550 ADR-component-country = list-component 1552 Example: In this example the post office box and the extended address 1553 are absent. 1555 ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n 1556 Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n 1557 U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A. 1559 6.4. Communications Properties 1561 These properties describe information about how to communicate with 1562 the object the vCard represents. 1564 6.4.1. TEL 1565 Purpose: To specify the telephone number for telephony communication 1566 with the object the vCard represents. 1568 Value type: By default it is a single free-form text value (for 1569 backward compatibility with vCard 3), but it SHOULD be reset to a 1570 URI value. It is expected that the URI scheme will be "tel", as 1571 specified in [RFC3966], but other schemes MAY be used. 1573 Cardinality: * 1575 Special notes: This property is based on the X.520 Telephone Number 1576 attribute. 1578 The property can include the "PREF" parameter to indicate a 1579 preferred-use telephone number. 1581 The property can include the parameter "TYPE" to specify intended 1582 use for the telephone number. The predefined values for the TYPE 1583 parameter are: 1585 +-----------+-------------------------------------------------------+ 1586 | Value | Description | 1587 +-----------+-------------------------------------------------------+ 1588 | text | Indicates that the telephone number supports text | 1589 | | messages (SMS). | 1590 | voice | Indicates a voice telephone number. | 1591 | fax | Indicates a facsimile telephone number. | 1592 | cell | Indicates a cellular or mobile telephone number. | 1593 | video | Indicates a video conferencing telephone number. | 1594 | pager | Indicates a paging device telephone number. | 1595 | textphone | Indicates a telecommunication device for people with | 1596 | | hearing or speech difficulties.. | 1597 +-----------+-------------------------------------------------------+ 1599 The default type is "voice". These type parameter values can be 1600 specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a 1601 value list (e.g., TYPE="text,voice"). The default can be 1602 overridden to another set of values by specifying one or more 1603 alternate values. For example, the default TYPE of "voice" can be 1604 reset to a VOICE and FAX telephone number by the value list 1605 TYPE="voice,fax". 1607 If this property's value is a URI that can also be used for 1608 instant messaging, the IMPP (Section 6.4.3) property SHOULD be 1609 used in addition to this property. 1611 ABNF: 1613 TEL-param = TEL-text-param / TEL-uri-param 1614 TEL-value = TEL-text-value / TEL-uri-value 1615 ; Value and parameter MUST match 1617 TEL-text-param = "VALUE=text" 1618 TEL-text-value = text 1620 TEL-uri-param = "VALUE=uri" / mediatype-param 1621 TEL-uri-value = uri 1623 TEL-param =/ type-param / pid-param / pref-param / altid-param 1624 / any-param 1626 type-param-tel = "text" / "voice" / "fax" / "cell" / "video" 1627 / "pager" / "textphone" / iana-token / x-name 1628 ; type-param-tel MUST NOT be used with a property other than TEL. 1630 Example: 1632 TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555 1633 TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67 1635 6.4.2. EMAIL 1637 Purpose: To specify the electronic mail address for communication 1638 with the object the vCard represents. 1640 Value type: A single text value. 1642 Cardinality: * 1644 Special notes: The property can include tye "PREF" parameter to 1645 indicate a preferred-use email address when more than one is 1646 specified. 1648 Even though the value is free-form UTF-8 text, it is likely to be 1649 interpreted by an MUA as an "addr-spec", as defined in [RFC5322], 1650 section 3.4.1. Readers should also be aware of the current work 1651 toward internationalized email addresses 1652 [I-D.ietf-eai-rfc5335bis]. 1654 ABNF: 1656 EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param 1657 / altid-param / any-param 1658 EMAIL-value = text 1660 Example: 1662 EMAIL;TYPE=work:jqpublic@xyz.example.com 1664 EMAIL;PREF=1:jane_doe@example.com 1666 6.4.3. IMPP 1668 Purpose: To specify the URI for instant messaging and presence 1669 protocol communications with the object the vCard represents. 1671 Value type: A single URI. 1673 Cardinality: * 1675 Special notes: The property may include the "PREF" parameter to 1676 indicate that this is a preferred address and has the same 1677 semantics as the "PREF" parameter in a TEL property. 1679 If this property's value is a URI that can be used for voice 1680 and/or video, the TEL property (Section 6.4.1) SHOULD be used in 1681 addition to this property. 1683 This property is adapted from [RFC4770], which is made obsolete by 1684 this document. 1686 ABNF: 1688 IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param 1689 / mediatype-param / altid-param / any-param 1690 IMPP-value = uri 1692 Example: 1694 IMPP;PREF=1:xmpp:alice@example.com 1696 6.4.4. LANG 1698 Purpose: To specify the language(s) that may be used for contacting 1699 the entity associated with the vCard. 1701 Value type: A single language-tag value. 1703 Cardinality: * 1704 ABNF: 1706 LANG-param = "VALUE=language-tag" / pid-param / pref-param 1707 / altid-param / type-param / any-param 1708 LANG-value = Language-Tag 1710 Example: 1712 LANG;TYPE=work;PREF=1:en 1713 LANG;TYPE=work;PREF=2:fr 1714 LANG;TYPE=home:fr 1716 6.5. Geographical Properties 1718 These properties are concerned with information associated with 1719 geographical positions or regions associated with the object the 1720 vCard represents. 1722 6.5.1. TZ 1724 Purpose: To specify information related to the time zone of the 1725 object the vCard represents. 1727 Value type: The default is a single text value. It can also be 1728 reset to a single URI or utc-offset value. 1730 Cardinality: * 1732 Special notes: It is expected that names from the public-domain 1733 Olson database [TZ-DB] will be used, but this is not a 1734 restriction. 1736 Efforts are currently being directed at creating a standard URI 1737 scheme for expressing time zone information. Usage of such a 1738 scheme would ensure a high level of interoperability between 1739 implementations that support it. 1741 Note that utc-offset values SHOULD NOT be used because the UTC 1742 offset varies with time - not just because of the usual daylight 1743 saving time shifts that occur in may regions, but often entire 1744 regions will "re-base" their overall offset. The actual offset 1745 may be +/- 1 hour (or perhaps a little more) than the one given. 1747 ABNF: 1749 TZ-param = "VALUE=" ("text" / "uri" / "utc-offset") 1750 TZ-value = text / uri / utc-offset 1751 ; Value and parameter MUST match 1753 TZ-param =/ altid-param / pid-param / pref-param / type-param 1754 / mediatype-param / any-param 1756 Examples: 1758 TZ:Raleigh/North America 1760 TZ;VALUE=utc-offset:-0500 1761 ; Note: utc-offset format is NOT RECOMMENDED. 1763 6.5.2. GEO 1765 Purpose: To specify information related to the global positioning of 1766 the object the vCard represents. 1768 Value type: A single URI. 1770 Cardinality: * 1772 Special notes: The "geo" URI scheme [RFC5870] is particularly well- 1773 suited for this property, but other schemes MAY be used. 1775 ABNF: 1777 GEO-param = "VALUE=uri" / pid-param / pref-param / type-param 1778 / mediatype-param / altid-param / any-param 1779 GEO-value = uri 1781 Example: 1783 GEO:geo:37.386013,-122.082932 1785 6.6. Organizational Properties 1787 These properties are concerned with information associated with 1788 characteristics of the organization or organizational units of the 1789 object that the vCard represents. 1791 6.6.1. TITLE 1792 Purpose: To specify the position or job of the object the vCard 1793 represents. 1795 Value type: A single text value. 1797 Cardinality: * 1799 Special notes: This property is based on the X.520 Title attribute. 1801 ABNF: 1803 TITLE-param = "VALUE=text" / language-param / pid-param 1804 / pref-param / altid-param / type-param / any-param 1805 TITLE-value = text 1807 Example: 1809 TITLE:Research Scientist 1811 6.6.2. ROLE 1813 Purpose: To specify the function or part played in a particular 1814 situation by the object the vCard represents. 1816 Value type: A single text value. 1818 Cardinality: * 1820 Special notes: This property is based on the X.520 Business Category 1821 explanatory attribute. This property is included as an 1822 organizational type to avoid confusion with the semantics of the 1823 TITLE property and incorrect usage of that property when the 1824 semantics of this property is intended. 1826 ABNF: 1828 ROLE-param = "VALUE=text" / language-param / pid-param / pref-param 1829 / type-param / altid-param / any-param 1830 ROLE-value = text 1832 Example: 1834 ROLE:Project Leader 1836 6.6.3. LOGO 1838 Purpose: To specify a graphic image of a logo associated with the 1839 object the vCard represents. 1841 Value type: A single URI. 1843 Cardinality: * 1845 ABNF: 1847 LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param 1848 / type-param / mediatype-param / altid-param / any-param 1849 LOGO-value = uri 1851 Examples: 1853 LOGO:http://www.example.com/pub/logos/abccorp.jpg 1855 LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc 1856 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1857 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1858 <...the remainder of base64-encoded data...> 1860 6.6.4. ORG 1862 Purpose: To specify the organizational name and units associated 1863 with the vCard. 1865 Value type: A single structured text value consisting of components 1866 separated by the SEMI-COLON character (ASCII decimal 59). 1868 Cardinality: * 1870 Special notes: The property is based on the X.520 Organization Name 1871 and Organization Unit attributes. The property value is a 1872 structured type consisting of the organization name, followed by 1873 zero or more levels of organizational unit names. 1875 The SORT-AS parameter MAY be applied to this property. 1877 ABNF: 1879 ORG-param = "VALUE=text" / sort-as-param / language-param 1880 / pid-param / pref-param / altid-param / type-param 1881 / any-param 1882 ORG-value = component *(";" component) 1884 Example: A property value consisting of an organizational name, 1885 organizational unit #1 name and organizational unit #2 name. 1887 ORG:ABC\, Inc.;North American Division;Marketing 1889 6.6.5. MEMBER 1891 Purpose: To include a member in the group this vCard represents. 1893 Value type: A single URI. It MAY refer to something other than a 1894 vCard object. For example, an e-mail distribution list could 1895 employ the "mailto" URI scheme [RFC6068] for efficiency. 1897 Cardinality: * 1899 Special notes: This property MUST NOT be present unless the value of 1900 the KIND property is "group". 1902 ABNF: 1904 MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param 1905 / mediatype-param / any-param 1906 MEMBER-value = uri 1908 Examples: 1910 BEGIN:VCARD 1911 VERSION:4.0 1912 KIND:group 1913 FN:The Doe family 1914 MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1915 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1916 END:VCARD 1917 BEGIN:VCARD 1918 VERSION:4.0 1919 FN:John Doe 1920 UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1921 END:VCARD 1922 BEGIN:VCARD 1923 VERSION:4.0 1924 FN:Jane Doe 1925 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1926 END:VCARD 1927 BEGIN:VCARD 1928 VERSION:4.0 1929 KIND:group 1930 FN:Funky distribution list 1931 MEMBER:mailto:subscriber1@example.com 1932 MEMBER:xmpp:subscriber2@example.com 1933 MEMBER:sip:subscriber3@example.com 1934 MEMBER:tel:+1-418-555-5555 1935 END:VCARD 1937 6.6.6. RELATED 1939 Purpose: To specify a relationship between another entity and the 1940 entity represented by this vCard. 1942 Value type: A single URI. It can also be reset to a single text 1943 value. The text value can be used to specify textual information. 1945 Cardinality: * 1947 Special notes: The TYPE parameter MAY be used to characterize the 1948 related entity. It contains a comma-separated list of values that 1949 are registered from IANA as described in Section 10.2. The 1950 registry is pre-populated with the values defined in [xfn]. This 1951 document also specifies two additional values: 1953 agent: an entity who may sometimes act on behalf of the entity 1954 associated with the vCard. 1956 emergency: indicates an emergency contact 1958 ABNF: 1960 RELATED-param = RELATED-param-uri / RELATED-param-text 1961 RELATED-value = uri / text 1962 ; Parameter and value MUST match. 1964 RELATED-param-uri = "VALUE=uri" / mediatype-param 1965 RELATED-param-text = "VALUE=text" / language-param 1967 RELATED-param =/ pid-param / pref-param / altid-param / type-param 1968 / any-param 1970 type-param-related = related-type-value *("," related-type-value) 1971 ; type-param-related MUST NOT be used with a property other than 1972 ; RELATED. 1974 related-type-value = "contact" / "acquaintance" / "friend" / "met" 1975 / "co-worker" / "colleague" / "co-resident" 1976 / "neighbor" / "child" / "parent" 1977 / "sibling" / "spouse" / "kin" / "muse" 1978 / "crush" / "date" / "sweetheart" / "me" 1979 / "agent" / "emergency" 1981 Examples: 1983 RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1984 RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf 1985 RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane 1986 Doe for any inquiries. 1988 6.7. Explanatory Properties 1990 These properties are concerned with additional explanations, such as 1991 that related to informational notes or revisions specific to the 1992 vCard. 1994 6.7.1. CATEGORIES 1996 Purpose: To specify application category information about the 1997 vCard. Also known as "tags". 1999 Value type: One or more text values separated by a COMMA character 2000 (ASCII decimal 44). 2002 Cardinality: * 2004 ABNF: 2006 CATEGORIES-param = "VALUE=text" / pid-param / pref-param 2007 / type-param / altid-param / any-param 2009 CATEGORIES-value = text-list 2011 Example: 2013 CATEGORIES:TRAVEL AGENT 2015 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY 2017 6.7.2. NOTE 2019 Purpose: To specify supplemental information or a comment that is 2020 associated with the vCard. 2022 Value type: A single text value. 2024 Cardinality: * 2026 Special notes: The property is based on the X.520 Description 2027 attribute. 2029 ABNF: 2031 NOTE-param = "VALUE=text" / language-param / pid-param / pref-param 2032 / type-param / altid-param / any-param 2033 NOTE-value = text 2035 Example: 2037 NOTE:This fax number is operational 0800 to 1715 2038 EST\, Mon-Fri. 2040 6.7.3. PRODID 2042 Purpose: To specify the identifier for the product that created the 2043 vCard object. 2045 Type value: A single text value. 2047 Cardinality: *1 2049 Special notes: Implementations SHOULD use a method such as that 2050 specified for Formal Public Identifiers in [ISO9070] or for 2051 Universal Resource Names in [RFC3406] to ensure that the text 2052 value is unique. 2054 ABNF: 2056 PRODID-param = "VALUE=text" / any-param 2057 PRODID-value = text 2059 Example: 2061 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN 2063 6.7.4. REV 2065 Purpose: To specify revision information about the current vCard. 2067 Value type: A single timestamp value. 2069 Cardinality: *1 2071 Special notes: The value distinguishes the current revision of the 2072 information in this vCard for other renditions of the information. 2074 ABNF: 2076 REV-param = "VALUE=timestamp" / any-param 2077 REV-value = timestamp 2079 Example: 2081 REV:19951031T222710Z 2083 6.7.5. SOUND 2085 Purpose: To specify a digital sound content information that 2086 annotates some aspect of the vCard. This property is often used 2087 to specify the proper pronunciation of the name property value of 2088 the vCard. 2090 Value type: A single URI. 2092 Cardinality: * 2094 ABNF: 2096 SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param 2097 / type-param / mediatype-param / altid-param 2098 / any-param 2099 SOUND-value = uri 2101 Example: 2103 SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com 2105 SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh 2106 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 2107 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 2108 <...the remainder of base64-encoded data...> 2110 6.7.6. UID 2112 Purpose: To specify a value that represents a globally unique 2113 identifier corresponding to the entity associated with the vCard. 2115 Value type: A single URI value. It MAY also be reset to free-form 2116 text. 2118 Cardinality: *1 2120 Special notes: This property is used to uniquely identify the object 2121 that the vCard represents. The "uuid" URN namespace defined in 2122 [RFC4122] is particularly well-suited to this task, but other URI 2123 schemes MAY be used. Free-form text MAY also be used. 2125 ABNF: 2127 UID-param = UID-uri-param / UID-text-param 2128 UID-value = UID-uri-value / UID-text-value 2129 ; Value and parameter MUST match. 2131 UID-uri-param = "VALUE=uri" 2132 UID-uri-value = uri 2134 UID-text-param = "VALUE=text" 2135 UID-text-value = text 2137 UID-param =/ any-param 2139 Example: 2141 UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2143 6.7.7. CLIENTPIDMAP 2145 Purpose: To give a global meaning to a local PID source identifier. 2147 Value type: A semicolon-separated pair of values. The first field 2148 is a small integer corresponding to the second field of a PID 2149 parameter instance. The second field is a URI. The "uuid" URN 2150 namespace defined in [RFC4122] is particularly well-suited to this 2151 task, but other URI schemes MAY be used. 2153 Cardinality: * 2155 Special notes: PID source identifiers (the source identifier is the 2156 second field in a PID parameter instance) are small integers that 2157 only have significance within the scope of a single vCard 2158 instance. Each distinct source identifier present in a vCard MUST 2159 have an associated CLIENTPIDMAP. See Section 7 for more details 2160 on the usage of CLIENTPIDMAP. 2162 PID source identifiers MUST be strictly positive. Zero is not 2163 allowed. 2165 As a special exception, the PID parameter MUST NOT be applied to 2166 this property. 2168 ABNF: 2170 CLIENTPIDMAP-param = any-param 2171 CLIENTPIDMAP-value = 1*DIGIT ";" uri 2173 Example: 2175 TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555 2176 EMAIL;PID=4.1,5.2:jdoe@example.com 2177 CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b 2178 CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5 2180 6.7.8. URL 2182 Purpose: To specify a uniform resource locator associated with the 2183 object that the vCard refers to. Examples for individuals include 2184 personal web sites, blogs, and social networking site identifiers. 2186 Cardinality: * 2188 Value type: A single uri value. 2190 ABNF: 2192 URL-param = "VALUE=uri" / pid-param / pref-param / type-param 2193 / mediatype-param / altid-param / any-param 2194 URL-value = uri 2196 Example: 2198 URL:http://example.org/restaurant.french/~chezchic.html 2200 6.7.9. VERSION 2202 Purpose: To specify the version of the vCard specification used to 2203 format this vCard. 2205 Value type: A single text value. 2207 Cardinality: 1 2209 Special notes: This property MUST be present in the vCard object, 2210 and it must appear immediately after BEGIN:VCARD. The value MUST 2211 be "4.0" if the vCard corresponds to this specification. Note 2212 that earlier versions of vCard allowed this property to be placed 2213 anywhere in the vCard object, or even to be absent. 2215 ABNF: 2217 VERSION-param = "VALUE=text" / any-param 2218 VERSION-value = "4.0" 2220 Example: 2222 VERSION:4.0 2224 6.8. Security Properties 2226 These properties are concerned with the security of communication 2227 pathways or access to the vCard. 2229 6.8.1. KEY 2231 Purpose: To specify a public key or authentication certificate 2232 associated with the object that the vCard represents. 2234 Value type: A single URI. It can also be reset to a text value. 2236 Cardinality: * 2238 ABNF: 2240 KEY-param = KEY-uri-param / KEY-text-param 2241 KEY-value = KEY-uri-value / KEY-text-value 2242 ; Value and parameter MUST match. 2244 KEY-uri-param = "VALUE=uri" / mediatype-param 2245 KEY-uri-value = uri 2247 KEY-text-param = "VALUE=text" 2248 KEY-text-value = text 2250 KEY-param =/ altid-param / pid-param / pref-param / type-param 2251 / any-param 2253 Examples: 2255 KEY:http://www.example.com/keys/jdoe 2257 KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe 2259 KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE 2260 UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l 2261 <... remainder of base64-encoded data ...> 2263 6.9. Calendar Properties 2265 These properties are further specified in [RFC2739]. 2267 6.9.1. FBURL 2269 Purpose: To specify the URI for the busy time associated with the 2270 object that the vCard represents. 2272 Value type: A single URI value. 2274 Cardinality: * 2276 Special notes: Where multiple FBURL properties are specified, the 2277 default FBURL property is indicated with the PREF parameter. The 2278 FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar 2279 [RFC5545] object associated with a snapshot of the next few weeks 2280 or months of busy time data. If the iCalendar object is 2281 represented as a file or document, its file extension should be 2282 ".ifb". 2284 ABNF: 2286 FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param 2287 / mediatype-param / altid-param / any-param 2289 FBURL-value = uri 2291 Examples: 2293 FBURL;PREF=1:http://www.example.com/busy/janedoe 2294 FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb 2296 6.9.2. CALADRURI 2298 Purpose: To specify the calendar user address [RFC5545] to which a 2299 scheduling request [RFC5546] should be sent for the object 2300 represented by the vCard. 2302 Value type: A single URI value. 2304 Cardinality: * 2306 Special notes: Where multiple CALADRURI properties are specified, 2307 the default CALADRURI property is indicated with the PREF 2308 parameter. 2310 ABNF: 2312 CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2313 / mediatype-param / altid-param / any-param 2314 CALADRURI-value = uri 2316 Example: 2318 CALADRURI;PREF=1:mailto:janedoe@example.com 2319 CALADRURI:http://example.com/calendar/jdoe 2321 6.9.3. CALURI 2323 Purpose: To specify the URI for a calendar associated with the 2324 object represented by the vCard. 2326 Value type: A single URI value. 2328 Cardinality: * 2330 Special notes: Where multiple CALURI properties are specified, the 2331 default CALURI property is indicated with the PREF parameter. The 2332 property should contain a URI pointing to an iCalendar [RFC5545] 2333 object associated with a snapshot of the user's calendar store. 2334 If the iCalendar object is represented as a file or document, its 2335 file extension should be ".ics". 2337 ABNF: 2339 CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2340 / mediatype-param / altid-param / any-param 2341 CALURI-value = uri 2343 Examples: 2345 CALURI;PREF=1:http://cal.example.com/calA 2346 CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics 2348 6.10. Extended Properties and Parameters 2350 The properties and parameters defined by this document can be 2351 extended. Non-standard, private properties and parameters with a 2352 name starting with "X-" may be defined bilaterally between two 2353 cooperating agents without outside registration or standardization. 2355 7. Synchronization 2357 vCard data often needs to be synchronized between devices. In this 2358 context, synchronization is defined as the intelligent merging of two 2359 representations of the same object. vCard 4.0 includes mechanisms to 2360 aid this process. 2362 7.1. Mechanisms 2364 Two mechanisms are available: the UID property is used to match 2365 multiple instances of the same vCard, while the PID parameter is used 2366 to match multiple instances of the same property. 2368 The term "matching" is used here to mean recognizing that two 2369 instances are in fact representations of the same object. For 2370 example, a single vCard that is shared with someone results in two 2371 vCard instances. After they have evolved separately, they still 2372 represent the same object, and therefore may be matched by a 2373 synchronization engine. 2375 7.1.1. Matching vCard Instances 2377 vCard instances for which the UID properties (Section 6.7.6) are 2378 equivalent MUST be matched. Equivalence is determined as specified 2379 in [RFC3986], Section 6. 2381 In all other cases, vCard instances MAY be matched at the discretion 2382 of the synchronization engine. 2384 7.1.2. Matching Property Instances 2386 Property instances belonging to unmatched vCards MUST NOT be matched. 2388 Property instances whose name (e.g. EMAIL, TEL, etc.) is not the 2389 same MUST NOT be matched. 2391 Property instances whose name is CLIENTPIDMAP are handled separately 2392 and MUST NOT be matched. The synchronization MUST ensure that there 2393 is consistency of CLIENTPIDMAPs among matched vCard instances. 2395 Property instances belonging to matched vCards, whose name is the 2396 same, and whose maximum cardinality is 1 MUST be matched. 2398 Property instances belonging to matched vCards, whose name is the 2399 same, and whose PID parameters match MUST be matched. See 2400 Section 7.1.3 for details on PID matching. 2402 In all other cases, property instances MAY be matched at the 2403 discretion of the synchronization engine. 2405 7.1.3. PID Matching 2407 Two PID values for which the first fields are equivalent represent 2408 the same local value. 2410 Two PID values representing the same local value and for which the 2411 second fields point to CLIENTPIDMAP properties whose second field 2412 URIs are equivalent (as specified in [RFC3986], Section 6) also 2413 represent the same global value. 2415 PID parameters for which at least one pair of their values represent 2416 the same global value MUST be matched. 2418 In all other cases, PID parameters MAY be matched at the discretion 2419 of the synchronization engine. 2421 For example, PID value "5.1", in the first vCard below, and PID value 2422 "5.2", in the second vCard below, represent the same global value. 2424 BEGIN:VCARD 2425 VERSION:4.0 2426 EMAIL;PID=4.2,5.1:jdoe@example.com 2427 CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2428 CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc 2429 END:VCARD 2431 BEGIN:VCARD 2432 VERSION:4.0 2433 EMAIL;PID=5.1,5.2:john@example.com 2434 CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d 2435 CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2436 END:VCARD 2438 7.2. Example 2440 7.2.1. Creation 2442 The following simple vCard is first created on a given device. 2444 BEGIN:VCARD 2445 VERSION:4.0 2446 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2447 FN;PID=1.1:J. Doe 2448 N:Doe;J.;;; 2449 EMAIL;PID=1.1:jdoe@example.com 2450 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2451 END:VCARD 2453 This new vCard is assigned the UID 2454 "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating 2455 device. The FN and EMAIL properties are assigned the same local 2456 value of 1, and this value is given global context by associating it 2457 with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which 2458 represents the creating device. We are at liberty to reuse the same 2459 local value since instances of different properties will never be 2460 matched. The N property has no PID because it is forbidden by its 2461 maximum cardinality of 1. 2463 7.2.2. Initial Sharing 2465 This vCard is shared with a second device. Upon inspecting the UID 2466 property, the second device understands that this is a new vCard 2467 (i.e. unmatched) and thus the synchronization results in a simple 2468 copy. 2470 7.2.3. Adding and Sharing a Property 2472 A new phone number is created on the first device, then the vCard is 2473 shared with the second device. This is what the second device 2474 receives: 2476 BEGIN:VCARD 2477 VERSION:4.0 2478 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2479 FN;PID=1.1:J. Doe 2480 N:Doe;J.;;; 2481 EMAIL;PID=1.1:jdoe@example.com 2482 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2483 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2484 END:VCARD 2486 Upon inspecting the UID property, the second device matches the vCard 2487 it received to the vCard that it already has stored. It then starts 2488 comparing the properties of the two vCards in same-named pairs. 2490 The FN properties are matched because the PID parameters have the 2491 same global value. Since the property value is the same, no update 2492 takes place. 2494 The N properties are matched automatically because their maximum 2495 cardinality is 1. Since the property value is the same, no update 2496 takes place. 2498 The EMAIL properties are matched because the PID parameters have the 2499 same global value. Since the property value is the same, no update 2500 takes place. 2502 The TEL property in the new vCard is not matched to any in the stored 2503 vCard because no property in the stored vCard has the same name. 2504 Therefore, this property is copied from the new vCard to the stored 2505 vCard. 2507 The CLIENTPIDMAP property is handled separately by the 2508 synchronization engine. It ensures that it is consistent with the 2509 stored one. If it was not, the results would be up to the 2510 synchronization engine, and thus undefined by this document. 2512 7.2.4. Simultaneous Editing 2514 A new email address and a new phone number are added to the vCard on 2515 each of the two devices, and then a new synchronization event 2516 happens. Here are the vCards that are communicated to each other: 2518 BEGIN:VCARD 2519 VERSION:4.0 2520 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2521 FN;PID=1.1:J. Doe 2522 N:Doe;J.;;; 2523 EMAIL;PID=1.1:jdoe@example.com 2524 EMAIL;PID=2.1:boss@example.com 2525 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2526 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2527 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2528 END:VCARD 2530 BEGIN:VCARD 2531 VERSION:4.0 2532 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2533 FN;PID=1.1:J. Doe 2534 N:Doe;J.;;; 2535 EMAIL;PID=1.1:jdoe@example.com 2536 EMAIL;PID=2.2:ceo@example.com 2537 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2538 TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666 2539 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2540 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2541 END:VCARD 2543 On the first device, the same PID source identifier (1) is reused for 2544 the new EMAIL and TEL properties. On the second device, a new source 2545 identifier (2) is generated, and a corresponding CLIENTPIDMAP 2546 property is created. It contains the second device's identifier, 2547 "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee". 2549 The new EMAIL properties are unmatched on both sides since the PID 2550 global value is new in both cases. The sync thus results in a copy 2551 on both sides. 2553 Although the situation appears to be the same for the TEL properties, 2554 in this case the synchronization engine is particularly smart and 2555 matches the two new TEL properties even though their PID global 2556 values are different. Note that in this case, the rules of section 2557 Section 7.1.2 state that two properties MAY be matched at the 2558 discretion of the synchronization engine. Therefore, the two 2559 properties are merged. 2561 All this results in the following vCard which is stored on both 2562 devices: 2564 BEGIN:VCARD 2565 VERSION:4.0 2566 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2567 FN:J. Doe 2568 N:Doe;J.;;; 2569 EMAIL;PID=1.1:jdoe@example.com 2570 EMAIL;PID=2.1:boss@example.com 2571 EMAIL;PID=2.2:ceo@example.com 2572 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2573 TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666 2574 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2575 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2576 END:VCARD 2578 7.2.5. Global Context Simplification 2580 The two devices finish their synchronization procedure by simplifying 2581 their global contexts. Since they haven't talked to any other 2582 device, the following vCard is for all purposes equivalent to the 2583 above. It is also shorter. 2585 BEGIN:VCARD 2586 VERSION:4.0 2587 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2588 FN:J. Doe 2589 N:Doe;J.;;; 2590 EMAIL;PID=1.1:jdoe@example.com 2591 EMAIL;PID=2.1:boss@example.com 2592 EMAIL;PID=3.1:ceo@example.com 2593 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2594 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2595 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2596 END:VCARD 2598 The details of global context simplification are unspecified by this 2599 document. They are left up to the synchronization engine. This 2600 example is merely intended to illustrate the possibility, which 2601 investigating would be, in the authors' opinion, worthwhile. 2603 8. Example: Authors' vCards 2605 BEGIN:VCARD 2606 VERSION:4.0 2607 FN:Simon Perreault 2608 N:Perreault;Simon;;;ing. jr,M.Sc. 2609 BDAY:--0203 2610 ANNIVERSARY:20090808T1430-0500 2611 GENDER:M 2612 LANG;PREF=1:fr 2613 LANG;PREF=2:en 2614 ORG;TYPE=work:Viagenie 2615 ADR;TYPE=work:;Suite D2-630;2875 Laurier; 2616 Quebec;QC;G1V 2M2;Canada 2617 TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102 2618 TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501 2619 EMAIL;TYPE=work:simon.perreault@viagenie.ca 2620 GEO;TYPE=work:geo:46.772673,-71.282945 2621 KEY;TYPE=work;VALUE=uri: 2622 http://www.viagenie.ca/simon.perreault/simon.asc 2623 TZ:-0500 2624 END:VCARD 2626 BEGIN:VCARD 2627 VERSION:4.0 2628 FN:Pete Resnick 2629 N:Resnick;Pete;;; 2630 GENDER:M 2631 ORG;TYPE=work:QUALCOMM Incorporated 2632 ADR;TYPE=work:;;5775 Morehouse Drive;San Diego;CA;92121-1714;US 2633 TEL;VALUE=uri;TYPE="work,voice":tel:+1-858-651-4478 2634 EMAIL;TYPE=work:presnick@qualcomm.com 2635 URL;TYPE=work:http://www.qualcomm.com/~presnick/ 2636 END:VCARD 2638 9. Security Considerations 2640 o Internet mail is often used to transport vCards and is subject to 2641 many well known security attacks, including monitoring, replay, 2642 and forgery. Care should be taken by any directory service in 2643 allowing information to leave the scope of the service itself, 2644 where any access controls or confidentiality can no longer be 2645 guaranteed. Applications should also take care to display 2646 directory data in a "safe" environment 2648 o vCards can carry cryptographic keys or certificates, as described 2649 in Section 6.8.1. 2651 o The vCard objects have no inherent authentication or privacy, but 2652 can easily be carried by any security mechanism that transfers 2653 MIME objects with authentication or privacy (e.g. S/MIME 2654 [RFC5751], OpenPGP [RFC4880]). In cases where the threat of 2655 "spoofed" vCard information is a concern, the vCard SHOULD BE 2656 transported using one of these secure mechanisms. 2658 o The information in a vCard may become out of date. In cases where 2659 the vitality of data is important to an originator of a vCard, the 2660 SOURCE property (Section 6.1.3) SHOULD be specified. In addition, 2661 the "REV" type described in section Section 6.7.4 can be specified 2662 to indicate the last time that the vCard data was updated. 2664 10. IANA Considerations 2666 10.1. MIME Type Registration 2668 IANA is asked to register the following MIME Media Type (in 2669 ). 2671 To: ietf-types@iana.org 2673 Subject: Registration of media type text/vcard 2675 Type name: text 2677 Subtype name: vcard 2679 Required parameters: none 2681 Optional parameters: version 2683 The "version" parameter is to be interpreted identically as the 2684 VERSION vCard property. If this parameter is present, all vCards 2685 in a text/vcard body part MUST have a VERSION property with value 2686 identical to that of this MIME parameter. 2688 "charset": as defined for text/plain [RFC2046]; encodings other 2689 than UTF-8 [RFC3629] MUST NOT be used. 2691 Encoding considerations: 8bit 2693 Security considerations: See Section 9. 2695 Interoperability considerations: The text/vcard media type is 2696 intended to identify vCard data of any version. There are older 2697 specifications of vCard [RFC2426][vCard21] still in common use. 2698 While these formats are similar, they are not strictly compatible. 2700 In general, it is necessary to inspect the value of the VERSION 2701 property (see Section 6.7.9) for identifying the standard to which 2702 a given vCard object conforms. 2704 In addition, the following media types are known to have been used 2705 to refer to vCard data. They should be considered deprecated in 2706 favor of text/vcard. 2708 * text/directory 2710 * text/directory; profile=vcard 2712 * text/x-vcard 2714 Published specification: draft-ietf-vcarddav-vcardrev-17 2716 Applications that use this media type: They are numerous, diverse, 2717 and include mail user agents, instant messaging clients, address 2718 book applications, directory servers, customer relationship 2719 management software. 2721 Additional information: 2723 Magic number(s): 2725 File extension(s): .vcf .vcard 2727 Macintosh file type code(s): 2729 Person & email address to contact for further information: Simon 2730 Perreault 2732 Intended usage: COMMON 2734 Restrictions on usage: none 2736 Author: Simon Perreault and Pete Resnick 2738 Change controller: IETF 2740 10.2. Registering New vCard Elements 2742 This section defines the process for registering new or modified 2743 vCard elements (i.e. properties, parameters, value data types, and 2744 values) with IANA. It does not contain any immediate IANA actions. 2746 10.2.1. Registration Procedure 2748 The IETF will create a mailing list, vcard@ietf.org [1], which can be 2749 used for public discussion of vCard element proposals prior to 2750 registration. Use of the mailing list is strongly encouraged. The 2751 IESG will appoint a designated expert who will monitor the 2752 vcard@ietf.org [1] mailing list and review registrations. 2754 Registration of new vCard elements MUST be reviewed by the designated 2755 expert and published in an RFC. A Standard Tracks RFC is REQUIRED 2756 for the registration of new value data types that modify existing 2757 properties. A Standard Tracks RFC is also REQUIRED for registration 2758 of vCard elements that modify vCard elements previously documented in 2759 a Standard Tracks RFC. 2761 The registration procedure begins when a completed registration 2762 template, defined in the sections below, is sent to 2763 vcard@ietf.org [1] and iana@iana.org [2]. The designated expert is 2764 expected to tell IANA and the submitter of the registration within 2765 two weeks whether the registration is approved, approved with minor 2766 changes, or rejected with cause. When a registration is rejected 2767 with cause, it can be re-submitted if the concerns listed in the 2768 cause are addressed. Decisions made by the designated expert can be 2769 appealed to the IESG Applications Area Director, then to the IESG. 2770 They follow the normal appeals procedure for IESG decisions. 2772 Once the registration procedure concludes successfully, IANA creates 2773 or modifies the corresponding record in the vCard registry. The 2774 completed registration template is discarded. 2776 An RFC specifying new vCard elements MUST include the completed 2777 registration templates, which MAY be expanded with additional 2778 information. These completed templates will go in the body of the 2779 document, and SHOULD NOT be included or repeated in the IANA 2780 Considerations section. 2782 Finally, note that there is an XML representation for vCard defined 2783 in [I-D.ietf-vcarddav-vcardxml]. An XML representation SHOULD be 2784 defined for new vCard objects. 2786 10.2.2. Vendor Namespace 2788 The vendor namespace is used for vCard elements associated with 2789 commercially available products. "Vendor" or "producer" are 2790 construed as equivalent and very broadly in this context. 2792 A registration may be placed in the vendor namespace by anyone who 2793 needs to interchange files associated with the particular product. 2795 However, the registration formally belongs to the vendor or 2796 organization handling the vCard elements in the namespace being 2797 registered. Changes to the specification will be made at their 2798 request, as discussed in subsequent sections. 2800 vCard elements belonging to the vendor namespace will be 2801 distinguished by the "VND-" prefix. This is followed by an IANA- 2802 registered Private Enterprise Number (PEN), a dash, and a vCard 2803 element designation of the vendor's choosing (e.g., "VND-123456- 2804 MUDPIE"). 2806 While public exposure and review of vCard elements to be registered 2807 in the vendor namespace is not required, using the vcard@ietf.org [1] 2808 mailing list for review is strongly encouraged to improve the quality 2809 of those specifications. Registrations in the vendor namespace may 2810 be submitted directly to the IANA. 2812 10.2.3. Registration Template for Properties 2814 A property is defined by completing the following template. 2816 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2817 specific property (where NNNN is replaced by the vendor's PEN). 2819 Property name: The name of the property. 2821 Purpose: The purpose of the property. Give a short but clear 2822 description. 2824 Value type: Any of the valid value types for the property value 2825 needs to be specified. The default value type also needs to be 2826 specified. 2828 Cardinality: See Section 6. 2830 Property parameters: Any of the valid property parameters for the 2831 property MUST be specified. 2833 Description: Any special notes about the property, how it is to be 2834 used, etc. 2836 Format definition: The ABNF for the property definition needs to be 2837 specified. 2839 Example(s): One or more examples of instances of the property needs 2840 to be specified. 2842 10.2.4. Registration Template for Parameters 2844 A parameter is defined by completing the following template. 2846 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2847 specific property (where NNNN is replaced by the vendor's PEN). 2849 Parameter name: The name of the parameter. 2851 Purpose: The purpose of the parameter. Give a short but clear 2852 description. 2854 Description: Any special notes about the parameter, how it is to be 2855 used, etc. 2857 Format definition: The ABNF for the parameter definition needs to be 2858 specified. 2860 Example(s): One or more examples of instances of the parameter needs 2861 to be specified. 2863 10.2.5. Registration Template for Value Data Types 2865 A value data type is defined by completing the following template. 2867 Value name: The name of the value type. 2869 Purpose: The purpose of the value type. Give a short but clear 2870 description. 2872 Description: Any special notes about the value type, how it is to be 2873 used, etc. 2875 Format definition: The ABNF for the value type definition needs to 2876 be specified. 2878 Example(s): One or more examples of instances of the value type 2879 needs to be specified. 2881 10.2.6. Registration Template for Values 2883 A value is defined by completing the following template. 2885 Value: The value literal. 2887 Purpose: The purpose of the value. Give a short but clear 2888 description. 2890 Conformance: The vCard properties and/or parameters that can take 2891 this value needs to be specified. 2893 Example(s): One or more examples of instances of the value needs to 2894 be specified. 2896 The following is a fictitious example of a registration of a vCard 2897 value: 2899 Value: supervisor 2901 Purpose: It means that the related entity is the direct hierarchical 2902 superior (i.e. supervisor or manager) of the entity this vCard 2903 represents. 2905 Conformance: This value can be used with the "TYPE" parameter 2906 applied on the "RELATED" property. 2908 Example(s): 2910 RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2912 10.3. Initial vCard Elements Registries 2914 The IANA is requested to create and maintain the following registries 2915 for vCard elements with pointers to appropriate reference documents. 2916 The registries will be grouped together under the heading "vCard 2917 Elements". 2919 10.3.1. Properties Registry 2921 The following table is to be used to initialize the properties 2922 registry. 2924 +-----------+--------------+------------------------+ 2925 | Namespace | Property | Reference | 2926 +-----------+--------------+------------------------+ 2927 | | SOURCE | RFCXXXX, Section 6.1.3 | 2928 | | KIND | RFCXXXX, Section 6.1.4 | 2929 | | XML | RFCXXXX, Section 6.1.5 | 2930 | | FN | RFCXXXX, Section 6.2.1 | 2931 | | N | RFCXXXX, Section 6.2.2 | 2932 | | NICKNAME | RFCXXXX, Section 6.2.3 | 2933 | | PHOTO | RFCXXXX, Section 6.2.4 | 2934 | | BDAY | RFCXXXX, Section 6.2.5 | 2935 | | ANNIVERSARY | RFCXXXX, Section 6.2.6 | 2936 | | GENDER | RFCXXXX, Section 6.2.7 | 2937 | | ADR | RFCXXXX, Section 6.3.1 | 2938 | | TEL | RFCXXXX, Section 6.4.1 | 2939 | | EMAIL | RFCXXXX, Section 6.4.2 | 2940 | | IMPP | RFCXXXX, Section 6.4.3 | 2941 | | LANG | RFCXXXX, Section 6.4.4 | 2942 | | TZ | RFCXXXX, Section 6.5.1 | 2943 | | GEO | RFCXXXX, Section 6.5.2 | 2944 | | TITLE | RFCXXXX, Section 6.6.1 | 2945 | | ROLE | RFCXXXX, Section 6.6.2 | 2946 | | LOGO | RFCXXXX, Section 6.6.3 | 2947 | | ORG | RFCXXXX, Section 6.6.4 | 2948 | | MEMBER | RFCXXXX, Section 6.6.5 | 2949 | | RELATED | RFCXXXX, Section 6.6.6 | 2950 | | CATEGORIES | RFCXXXX, Section 6.7.1 | 2951 | | NOTE | RFCXXXX, Section 6.7.2 | 2952 | | PRODID | RFCXXXX, Section 6.7.3 | 2953 | | REV | RFCXXXX, Section 6.7.4 | 2954 | | SOUND | RFCXXXX, Section 6.7.5 | 2955 | | UID | RFCXXXX, Section 6.7.6 | 2956 | | CLIENTPIDMAP | RFCXXXX, Section 6.7.7 | 2957 | | URL | RFCXXXX, Section 6.7.8 | 2958 | | VERSION | RFCXXXX, Section 6.7.9 | 2959 | | KEY | RFCXXXX, Section 6.8.1 | 2960 | | FBURL | RFCXXXX, Section 6.9.1 | 2961 | | CALADRURI | RFCXXXX, Section 6.9.2 | 2962 | | CALURI | RFCXXXX, Section 6.9.3 | 2963 +-----------+--------------+------------------------+ 2965 10.3.2. Parameters Registry 2967 The following table is to be used to initialize the parameters 2968 registry. 2970 +-----------+-----------+-----------------------+ 2971 | Namespace | Parameter | Reference | 2972 +-----------+-----------+-----------------------+ 2973 | | LANGUAGE | RFCXXXX, Section 5.1 | 2974 | | VALUE | RFCXXXX, Section 5.2 | 2975 | | PREF | RFCXXXX, Section 5.3 | 2976 | | ALTID | RFCXXXX, Section 5.4 | 2977 | | PID | RFCXXXX, Section 5.5 | 2978 | | TYPE | RFCXXXX, Section 5.6 | 2979 | | MEDIATYPE | RFCXXXX, Section 5.7 | 2980 | | CALSCALE | RFCXXXX, Section 5.8 | 2981 | | SORT-AS | RFCXXXX, Section 5.9 | 2982 | | GEO | RFCXXXX, Section 5.10 | 2983 | | TZ | RFCXXXX, Section 5.11 | 2984 +-----------+-----------+-----------------------+ 2986 10.3.3. Value Data Types Registry 2988 The following table is to be used to initialize the parameters 2989 registry. 2991 +------------------+------------------------+ 2992 | Value Data Type | Reference | 2993 +------------------+------------------------+ 2994 | BOOLEAN | RFCXXXX, Section 4.4 | 2995 | DATE | RFCXXXX, Section 4.3.1 | 2996 | TIME | RFCXXXX, Section 4.3.2 | 2997 | DATE-TIME | RFCXXXX, Section 4.3.3 | 2998 | DATE-AND-OR-TIME | RFCXXXX, Section 4.3.4 | 2999 | TIMESTAMP | RFCXXXX, Section 4.3.5 | 3000 | FLOAT | RFCXXXX, Section 4.6 | 3001 | INTEGER | RFCXXXX, Section 4.5 | 3002 | TEXT | RFCXXXX, Section 4.1 | 3003 | URI | RFCXXXX, Section 4.2 | 3004 | LANGUAGE-TAG | RFCXXXX, Section 4.7 | 3005 +------------------+------------------------+ 3007 10.3.4. Values Registries 3009 Separate tables will be used for property and parameter values. 3011 The following table is to be used to initialize the property values 3012 registry. 3014 +----------+------------+------------------------+ 3015 | Property | Value | Reference | 3016 +----------+------------+------------------------+ 3017 | BEGIN | VCARD | RFCXXXX, Section 6.1.1 | 3018 | END | VCARD | RFCXXXX, Section 6.1.2 | 3019 | KIND | individual | RFCXXXX, Section 6.1.4 | 3020 | KIND | group | RFCXXXX, Section 6.1.4 | 3021 | KIND | org | RFCXXXX, Section 6.1.4 | 3022 | KIND | location | RFCXXXX, Section 6.1.4 | 3023 +----------+------------+------------------------+ 3025 The following table is to be used to initialize the parameter values 3026 registry. 3028 +------------------------+-----------+--------------+---------------+ 3029 | Property | Parameter | Value | Reference | 3030 +------------------------+-----------+--------------+---------------+ 3031 | FN, NICKNAME, PHOTO, | TYPE | work | RFCXXXX, | 3032 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | 3033 | LANG, TZ, GEO, TITLE, | | | | 3034 | ROLE, LOGO, ORG, | | | | 3035 | RELATED, CATEGORIES, | | | | 3036 | NOTE, SOUND, URL, KEY, | | | | 3037 | FBURL, CALADRURI, and | | | | 3038 | CALURI | | | | 3039 | FN, NICKNAME, PHOTO, | TYPE | home | RFCXXXX, | 3040 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | 3041 | LANG, TZ, GEO, TITLE, | | | | 3042 | ROLE, LOGO, ORG, | | | | 3043 | RELATED, CATEGORIES, | | | | 3044 | NOTE, SOUND, URL, KEY, | | | | 3045 | FBURL, CALADRURI, and | | | | 3046 | CALURI | | | | 3047 | TEL | TYPE | text | RFCXXXX, | 3048 | | | | Section 6.4.1 | 3049 | TEL | TYPE | voice | RFCXXXX, | 3050 | | | | Section 6.4.1 | 3051 | TEL | TYPE | fax | RFCXXXX, | 3052 | | | | Section 6.4.1 | 3053 | TEL | TYPE | cell | RFCXXXX, | 3054 | | | | Section 6.4.1 | 3055 | TEL | TYPE | video | RFCXXXX, | 3056 | | | | Section 6.4.1 | 3057 | TEL | TYPE | pager | RFCXXXX, | 3058 | | | | Section 6.4.1 | 3059 | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFCXXXX, | 3060 | | | | Section 6.2.5 | 3061 | RELATED | TYPE | contact | RFCXXXX, | 3062 | | | | Section 6.6.6 | 3063 | | | | and [xfn] | 3064 | RELATED | TYPE | acquaintance | RFCXXXX, | 3065 | | | | Section 6.6.6 | 3066 | | | | and [xfn] | 3067 | RELATED | TYPE | friend | RFCXXXX, | 3068 | | | | Section 6.6.6 | 3069 | | | | and [xfn] | 3070 | RELATED | TYPE | met | RFCXXXX, | 3071 | | | | Section 6.6.6 | 3072 | | | | and [xfn] | 3073 | RELATED | TYPE | co-worker | RFCXXXX, | 3074 | | | | Section 6.6.6 | 3075 | | | | and [xfn] | 3076 | RELATED | TYPE | colleague | RFCXXXX, | 3077 | | | | Section 6.6.6 | 3078 | | | | and [xfn] | 3079 | RELATED | TYPE | co-resident | RFCXXXX, | 3080 | | | | Section 6.6.6 | 3081 | | | | and [xfn] | 3082 | RELATED | TYPE | neighbor | RFCXXXX, | 3083 | | | | Section 6.6.6 | 3084 | | | | and [xfn] | 3085 | RELATED | TYPE | child | RFCXXXX, | 3086 | | | | Section 6.6.6 | 3087 | | | | and [xfn] | 3088 | RELATED | TYPE | parent | RFCXXXX, | 3089 | | | | Section 6.6.6 | 3090 | | | | and [xfn] | 3091 | RELATED | TYPE | sibling | RFCXXXX, | 3092 | | | | Section 6.6.6 | 3093 | | | | and [xfn] | 3094 | RELATED | TYPE | spouse | RFCXXXX, | 3095 | | | | Section 6.6.6 | 3096 | | | | and [xfn] | 3097 | RELATED | TYPE | kin | RFCXXXX, | 3098 | | | | Section 6.6.6 | 3099 | | | | and [xfn] | 3100 | RELATED | TYPE | muse | RFCXXXX, | 3101 | | | | Section 6.6.6 | 3102 | | | | and [xfn] | 3103 | RELATED | TYPE | crush | RFCXXXX, | 3104 | | | | Section 6.6.6 | 3105 | | | | and [xfn] | 3106 | RELATED | TYPE | date | RFCXXXX, | 3107 | | | | Section 6.6.6 | 3108 | | | | and [xfn] | 3109 | RELATED | TYPE | sweetheart | RFCXXXX, | 3110 | | | | Section 6.6.6 | 3111 | | | | and [xfn] | 3112 | RELATED | TYPE | me | RFCXXXX, | 3113 | | | | Section 6.6.6 | 3114 | | | | and [xfn] | 3115 | RELATED | TYPE | agent | RFCXXXX, | 3116 | | | | Section 6.6.6 | 3117 | RELATED | TYPE | emergency | RFCXXXX, | 3118 | | | | Section 6.6.6 | 3119 +------------------------+-----------+--------------+---------------+ 3121 11. Acknowledgements 3123 The authors would like to thank Tim Howes, Mark Smith, and Frank 3124 Dawson, the original authors of [RFC2425] and [RFC2426], Pete 3125 Resnick, who got this effort started and provided help along the way, 3126 as well as the following individuals who have participated in the 3127 drafting, review and discussion of this memo: 3129 Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil 3130 Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie 3131 Hoeneisen, Bjoern Hoehrmann, Caleb Richarson, Chris Bryant, Chris 3132 Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale, 3133 Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian 3134 Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens, 3135 Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke, 3136 Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga. Lisa Dusseault, 3137 Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike 3138 Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter 3139 Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane 3140 Bortzmeyer, Tantek Celik, and Zoltan Ordogh. 3142 12. References 3144 12.1. Normative References 3146 [CCITT.E163.1988] International Telephone and Telegraph 3147 Consultative Committee, "Numbering Plan 3148 for the International Telephone 3149 Service", CCITT Recommendation E.163, 3150 1988. 3152 [CCITT.X121.1988] International Telephone and Telegraph 3153 Consultative Committee, "International 3154 Numbering Plan for the Public Data 3155 Networks", CCITT Recommendation X.121, 3156 1988. 3158 [CCITT.X520.1988] International International Telephone 3159 and Telegraph Consultative Committee, 3160 "Information Technology - Open Systems 3161 Interconnection - The Directory: 3162 Selected Attribute Types", 3163 CCITT Recommendation X.520, 3164 November 1988. 3166 [CCITT.X521.1988] International International Telephone 3167 and Telegraph Consultative Committee, 3168 "Information Technology - Open Systems 3169 Interconnection - The Directory: 3170 Selected Object Classes", 3171 CCITT Recommendation X.521, 3172 November 1988. 3174 [I-D.ietf-vcarddav-vcardxml] Perreault, S., "vCard XML 3175 Representation", 3176 draft-ietf-vcarddav-vcardxml-08 (work 3177 in progress), April 2011. 3179 [ISO.8601.2000] International Organization for 3180 Standardization, "Data elements and 3181 interchange formats - Information 3182 interchange - Representation of dates 3183 and times", ISO Standard 8601, 3184 December 2000. 3186 [ISO.8601.2004] International Organization for 3187 Standardization, "Data elements and 3188 interchange formats - Information 3189 interchange - Representation of dates 3190 and times", ISO Standard 8601, 3191 December 2004. 3193 [RFC1738] Berners-Lee, T., Masinter, L., and M. 3194 McCahill, "Uniform Resource Locators 3195 (URL)", RFC 1738, December 1994. 3197 [RFC2045] Freed, N. and N. Borenstein, 3198 "Multipurpose Internet Mail Extensions 3199 (MIME) Part One: Format of Internet 3200 Message Bodies", RFC 2045, 3201 November 1996. 3203 [RFC2046] Freed, N. and N. Borenstein, 3204 "Multipurpose Internet Mail Extensions 3205 (MIME) Part Two: Media Types", 3206 RFC 2046, November 1996. 3208 [RFC2119] Bradner, S., "Key words for use in RFCs 3209 to Indicate Requirement Levels", 3210 BCP 14, RFC 2119, March 1997. 3212 [RFC2739] Small, T., Hennessy, D., and F. Dawson, 3213 "Calendar Attributes for vCard and 3214 LDAP", RFC 2739, January 2000. 3216 [RFC3629] Yergeau, F., "UTF-8, a transformation 3217 format of ISO 10646", STD 63, RFC 3629, 3218 November 2003. 3220 [RFC3966] Schulzrinne, H., "The tel URI for 3221 Telephone Numbers", RFC 3966, 3222 December 2004. 3224 [RFC3986] Berners-Lee, T., Fielding, R., and L. 3225 Masinter, "Uniform Resource Identifier 3226 (URI): Generic Syntax", STD 66, 3227 RFC 3986, January 2005. 3229 [RFC4122] Leach, P., Mealling, M., and R. Salz, 3230 "A Universally Unique IDentifier (UUID) 3231 URN Namespace", RFC 4122, July 2005. 3233 [RFC5234] Crocker, D. and P. Overell, "Augmented 3234 BNF for Syntax Specifications: ABNF", 3235 STD 68, RFC 5234, January 2008. 3237 [RFC5322] Resnick, P., Ed., "Internet Message 3238 Format", RFC 5322, October 2008. 3240 [RFC5545] Desruisseaux, B., "Internet Calendaring 3241 and Scheduling Core Object 3242 Specification (iCalendar)", RFC 5545, 3243 September 2009. 3245 [RFC5546] Daboo, C., "iCalendar Transport- 3246 Independent Interoperability Protocol 3247 (iTIP)", RFC 5546, December 2009. 3249 [RFC5646] Phillips, A. and M. Davis, "Tags for 3250 Identifying Languages", BCP 47, 3251 RFC 5646, September 2009. 3253 [RFC5870] Mayrhofer, A. and C. Spanring, "A 3254 Uniform Resource Identifier for 3255 Geographic Locations ('geo' URI)", 3256 RFC 5870, June 2010. 3258 [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., 3259 Sperberg-McQueen, C., and T. Bray, 3260 "Extensible Markup Language (XML) 1.0 3261 (Fifth Edition)", World Wide Web 3262 Consortium Recommendation REC-xml- 3263 20081126, November 2008, . 3266 [xfn] Celik, T., Mullenweg, M., and E. Meyer, 3267 "XHTML Friends Network 1.1", 3268 . 3270 12.2. Informative References 3272 [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, 3273 "Internationalized Email Headers", 3274 draft-ietf-eai-rfc5335bis-10 (work in 3275 progress), March 2011. 3277 [ISO9070] The International Organization for 3278 Standardization, "ISO 9070, Information 3279 Processing - SGML support facilities - 3280 Registration Procedures for Public Text 3281 Owner Identifiers", April 1991. 3283 [RFC2397] Masinter, L., "The "data" URL scheme", 3284 RFC 2397, August 1998. 3286 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A 3287 MIME Content-Type for Directory 3288 Information", RFC 2425, September 1998. 3290 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 3291 Directory Profile", RFC 2426, 3292 September 1998. 3294 [RFC2616] Fielding, R., Gettys, J., Mogul, J., 3295 Frystyk, H., Masinter, L., Leach, P., 3296 and T. Berners-Lee, "Hypertext Transfer 3297 Protocol -- HTTP/1.1", RFC 2616, 3298 June 1999. 3300 [RFC3282] Alvestrand, H., "Content Language 3301 Headers", RFC 3282, May 2002. 3303 [RFC3406] Daigle, L., van Gulik, D., Iannella, 3304 R., and P. Faltstrom, "Uniform Resource 3305 Names (URN) Namespace Definition 3306 Mechanisms", BCP 66, RFC 3406, 3307 October 2002. 3309 [RFC4770] Jennings, C. and J. Reschke, Ed., 3310 "vCard Extensions for Instant Messaging 3311 (IM)", RFC 4770, January 2007. 3313 [RFC4880] Callas, J., Donnerhacke, L., Finney, 3314 H., Shaw, D., and R. Thayer, "OpenPGP 3315 Message Format", RFC 4880, 3316 November 2007. 3318 [RFC5751] Ramsdell, B. and S. Turner, "Secure/ 3319 Multipurpose Internet Mail Extensions 3320 (S/MIME) Version 3.2 Message 3321 Specification", RFC 5751, January 2010. 3323 [RFC6068] Duerst, M., Masinter, L., and J. 3324 Zawinski, "The 'mailto' URI Scheme", 3325 RFC 6068, October 2010. 3327 [TZ-DB] Olson, A., "Time zone code and data", 3328 . 3330 [vCard21] Internet Mail Consortium, "vCard - The 3331 Electronic Business Card Version 2.1", 3332 September September. 3334 URIs 3336 [1] 3338 [2] 3340 Appendix A. Differences from RFCs 2425 and 2426 3342 This appendix contains a list of changes that have been made in the 3343 vCard specification from RFCs 2425 and 2426. 3345 A.1. New Structure 3347 o [RFC2425] and [RFC2426] have been merged. 3349 o vCard is now not only a MIME type but a stand-alone format. 3351 o A proper MIME type registration form has been included. 3353 o UTF-8 is now the default character set. 3355 o New vCard elements can be registered from IANA. 3357 o Expanded text on character set. 3359 A.2. Removed Features 3361 o The CONTEXT and CHARSET parameters are no more. 3363 o The NAME, MAILER, LABEL, and CLASS properties are no more. 3365 o The "intl", "dom", "postal", and "parcel" TYPE parameter values 3366 for the ADR property have been removed. 3368 o Inline vCards (such as the value of the AGENT property) are no 3369 longer supported. 3371 o In the N property, each component may now contain multiple comma- 3372 separated values. 3374 A.3. New Properties and Parameters 3376 o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP 3377 properties have been added. 3379 o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI 3380 properties, has been merged in. 3382 o [RFC4770], which defines the IMPP property, has been merged in. 3384 o The "work", "home", and "uri" TYPE parameter values for the EMAIL 3385 property have been added. 3387 o The "pref" value of the TYPE parameter is now a parameter of its 3388 own, with a positive integer value indicating the level of 3389 preference. 3391 o The ALTID and PID parameters have been added. 3393 A.4. Other Changes 3395 o Synchronization is addressed in Section 7. 3397 o The N property is no longer mandatory. 3399 o The value of TEL is now a URI. 3401 o The AGENT property was replaced with a type of RELATED. 3403 o Date and time values now only support the basic format. 3404 Truncation is now supported. 3406 Appendix B. Change Log (to be removed by RFC Editor prior to 3407 publication) 3409 B.1. Changes in -17 3411 o s/individual/entity/ 3413 o Moved section 3.4 for better flow. 3415 o Removed text overriding general MIME and HTTP rules. 3417 o Fixed redundant ABNF. 3419 o Fixed parameter value quoting in examples. 3421 o Added informative reference for Content-Language header. 3423 o Moved cardinality table earlier for better flow. 3425 o Added normative reference for XML 1.0. 3427 o Added informative reference for mailto: scheme. 3429 o Clarified where the VERSION property must go. 3431 o Created the MEDIATYPE parameter. 3433 o Fixed text/vcard encoding considerations. 3435 o Added .vcard file extension. 3437 o Removed need for extension documents to contain tables in their 3438 IANA Considerations section. 3440 o Removed underspecified "Status" column in IANA registry. 3442 o Moved obsoleted references to Informative section. 3444 o Moved iCalendar references to Normative section. 3446 o Expanded specification of KIND values. 3448 o Recommend defining an XML representation for new vCard objects. 3450 B.2. Changes in -16 3452 o RELATED: Added XFN values into IANA registry. 3454 o RELATED: Added values "agent" and "emergency". 3456 o EMAIL is now free-form text, with informative reference to EAI. 3458 o GENDER now has two components: one for biological sex, the other 3459 for gender identity. 3461 o Bugfixes to the core ABNF. 3463 o Clarified IANA considerations. 3465 o UID may be reset to free-form text. 3467 B.3. Changes in -15 3469 o Reverted N to the 5-component format of vCard 3. 3471 o Removed DDAY, BIRTH, and DEATH. 3473 o First two components in ADR SHOULD be empty. 3475 o Removed the LABEL property. 3477 o Removed the binary value type and the ENCODING and FMTTYPE 3478 parameters. 3480 o Renamed SEX to GENDER. Set predefined values to "male" and 3481 "female". 3483 o Reverted TEL to take a text value by default, but SHOULD be reset 3484 to a URI. 3486 o Refer to iCalendar for CALSCALE. 3488 o Removed the "thing" value for KIND. 3490 o RELATED now uses XFN 1.1 for its value. 3492 o Dropped the VERSION parameter. XML MUST be version 1.0. 3494 o Dropped the CLASS property. 3496 o Property and parameter names SHOULD be upper-case. 3498 o Use ABNF for cardinality notation. 3500 B.4. Changes in -14 3502 o DQUOTE is US-ASCII decimal 34, not 22. 3504 o Removed unused reference to RFC 2046. 3506 o Updated reference to draft-ietf-vcarddav-vcardxml. 3508 o Small fixes to the IANA registration text. 3510 o Added notes on the usage of TEL and IMPP properties. 3512 o Clarified "country name" component of ADR property. 3514 o Removed usage of undefined type value "msg" in TEL example. 3516 o Fixed parameter value quoting rules and ABNF. 3518 o Added example to LANGUAGE property. 3520 o Fixed synchronization example regarding the cardinality of FN. 3522 o Added implementation note for float value type. 3524 o Removed advice for always including VALUE parameter. 3526 o FMTTYPE MUST include the full MIME type. 3528 o Made ADR's ABNF more verbose. 3530 o Organized TEL TYPE values in a table. 3532 o Replaced TOP-SECRET example with NOINDEX. 3534 B.5. Changes in -13 3536 o Changed global ABNF to make explicit that VERSION comes first. 3538 o Reworked example for LANGUAGE property. 3540 o s/TYPE/FMTTYPE/ in two examples. 3542 o Allow LANGUAGE parameter for text-valued BDAY, DDAY, and RELATED. 3544 o Tightened language on LANGUAGE parameter regarding cardinality. 3546 o Removed the NAME property. 3548 o Adjusted semi-colon escaping rules. 3550 o Added the ALTID parameter. 3552 B.6. Changes in -12 3554 o Fixed example of LANGUAGE cardinality. 3556 o Added note about YYYY-MM date format. 3558 o Fixed appendix A. 3560 o VERSION property must come first. 3562 o Fixed mistake in PID example. 3564 o Removed two changes from Appendix A which were probably intended 3565 to go into this change log section. 3567 o Explicitly state that the value for the BEGIN and END properties 3568 is case-insensitive. 3570 o Removed the SORT-STRING property. Created the SORT-AS parameter. 3572 o "T" and "Z" in dates and times are now mandatory uppercase. 3574 o Added the "version" MIME parameter. 3576 o More consistent capitalization. 3578 o Added missing "ANNIVERSARY" in name production rule. 3580 o Added missing calscale-param in param production rule. 3582 o Moved definition of GEO and TZ parameters to section 5. 3584 o Simplified discussion of encoding. 3586 o Removed restriction for "work" and "home" values of TYPE parameter 3587 w.r.t. the KIND property. 3589 o XML value may now be binary. 3591 o Created VERSION parameter for XML. 3593 o BIRTH and DEATH can now have URI values. 3595 o Created the FMTTYPE parameter. 3597 o KEY can now take a text value. 3599 o Added references to RFC 5545 (iCalendar). 3601 o Added namespace column in parameters registry. 3603 B.7. Changes in -11 3605 o Change "XML chunk" to "XML fragment". 3607 o Cite W3C document containing definition of "fragment". 3609 o Added "XML" to property name ABNF. 3611 o Clarified newline escaping rule. 3613 o Replaced one remaining "type" with "property". 3615 o Removed case insensitivity of parameter values. 3617 o XML property can now only contain one element that is not in the 3618 vCard 4 namespace. 3620 o Clarified interrelationship between LANGUAGE, cardinality, and 3621 PID. 3623 o Added "textphone" TEL type. 3625 o Fixed quoting of comma in ORG examples. 3627 B.8. Changes in -10 3629 o Added component in SORT-STRING for sorting by given name. Fixed 3630 and expanded the examples. 3632 o Fixed KIND-value ABNF. 3634 o Fixed deprecated media type. 3636 o Created the CALSCALE parameter. 3638 o Strenghtened the stance on character set. 3640 o Defined the Language-Tag ABNF. 3642 o Made explicit the fact that IANA does not register templates. 3644 o Created the XML property. 3646 o Added social networking examples to URL property. 3648 B.9. Changes in -09 3650 o Removed special meaning for groups. Removed the "work" and "home" 3651 groups. Removed the group registry. Re-introduced the "work" and 3652 "home" TYPE parameter values. Applied the TYPE parameter to 3653 properties which supported the "work" and "home" groups. 3655 o Vendor namespace now uses private enterprise number in prefix. 3657 o Added "thing" value for KIND property. 3659 B.10. Changes in -08 3661 o Allow 1985 (year only) in date ABNF. 3663 o Fixed missing country in ADR example. 3665 o Added the DATE-AND-OR-TIME value. 3667 o Made BDAY and DDAY use DATE-AND-OR-TIME. 3669 o Prefixed "param" and "value" production rules specific to 3670 properties with the property name. 3672 o Replaced the GENDER property with the SEX property. 3674 o Added the ANNIVERSARY property. 3676 o Added the "friend" and "spouse" types of RELATED. 3678 o TZ property now has text / uri value. 3680 o Refined the definitions of TITLE and ROLE. 3682 B.11. Changes in -07 3684 o PREF is now bounded. 100 is the maximum value. 3686 o Added the "emergency" RELATED type. 3688 o Made GEO a URI. 3690 o Added GEO and TZ parameters to ADR. 3692 o Changed wording of "default" use of SOUND property. 3694 o Completely reworked the date, time, and date-time grammars. 3696 o Added the timestamp value type. 3698 o REV now has the timestamp value type. 3700 o Rewrote ABNF. 3702 o ORG can now have a single level. 3704 B.12. Changes in -06 3706 o Corrected omission of resetability to text value for RELATED. 3708 o Let KEY value type be reset to a URI value. 3710 o ABNF fixes. 3712 o Made gender values extensible. 3714 o Gave the PREF parameter a positive integer value. 3716 o Removed usage of the undefined "word" ABNF production rule. 3718 o Defined property cardinalities. 3720 o Defined properties allowable in WORK and HOME groups. 3722 o Simplified the LANG property to use the vCard preference 3723 mechanism. 3725 o Created the "language-tag" value type. 3727 o Added PID to ABNF of SOURCE allowed parameters. 3729 o Clarified escaping rules. 3731 o Changed ABNF definition of non-standard X- properties. 3733 o Removed TYPE parameter from EMAIL properties in examples. 3735 o Created the CLIENTPIDMAP property. 3737 o Changed PID value to a pair of small integers. 3739 o Completely reworked synchronization mechanisms. 3741 o Created brand new synchronization example. 3743 B.13. Changes in -05 3745 o Added multi PID value proposal. 3747 B.14. Changes in -04 3749 o Added "location" value for KIND property. 3751 o Some fixes to ABNF. 3753 o Moved "pref" from being a TYPE value to a parameter in its own 3754 right. 3756 o Removed the "work" and "home" TYPE values. 3758 o Reintroduced the group construct. 3760 o Assigned meaning to WORK and HOME groups. 3762 o Restricted the TEL TYPE parameter value set. 3764 o In N property, removed additional names, and replaced with 3765 multiple given names. 3767 o Removed TYPE parameter from EMAIL and IMPP properties. 3769 o Replaced AGENT with a type of RELATED. 3771 o Use example.org domain in URL example. 3773 o Created initial IANA table of values. 3775 o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL. 3777 B.15. Changes in -03 3779 o Various changes to the synchronization mechanisms. 3781 o Allowed truncated format for dated. See issue #236. 3783 B.16. Changes in -02 3785 o Removed useless text in IMPP description. 3787 o Added CalDAV-SCHED example to CALADRURI. 3789 o Removed CAPURI property. 3791 o Dashes in dates and colons in times are now mandatory. 3793 o Allow for dates such as 2008 and 2008-05 and times such as 07 and 3794 07:54. 3796 o Removed inline vCard value. 3798 o Made AGENT only accept URI references instead of inline vCards. 3800 o Added the MEMBER property. 3802 o Renamed the UID parameter to PID. 3804 o Changed the value type of the PID parameter to "a small integer." 3806 o Changed the presence of UID and PID when synchronization is to be 3807 used from MUST to SHOULD. 3809 o Added the RELATED (Section 6.6.6) property. 3811 o Fixed many ABNF typos (issue #252). 3813 o Changed formatting of ABNF comments to make them easier to read 3814 (issue #226). 3816 B.17. Changes in -01 3818 o Merged [RFC2739] in. 3820 o Converted all foobar.com, abc.com, etc. to example.com. 3822 o Fixed bugs in ABNF. 3824 o Made explicit that coordinates in the GEO property are expressed 3825 in the WGS 84 reference system. 3827 o Clarified folding issues with multi-byte characters. 3829 o Made the value of TEL a URI. 3831 o Added the UID parameter. 3833 o Made the UID property's value type a URI. 3835 o Added Section 7. 3837 o Created IANA process for registering new parameters, value types, 3838 and properties. 3840 o Created the initial IANA registries. 3842 o Created vendor namespace based on text from RFC 4288. 3844 B.18. Changes in -00 3846 o Name change because draft has been accepted as WG item. 3847 Otherwise, same as draft-resnick-vcarddav-vcardrev-01. 3849 o Removed reference to RFC 2234. 3851 o Fixed errata from 3852 http://www.rfc-editor.org/errata_search.php?rfc=2426. 3854 o Removed passage referring to RFC 2425 profiles. 3856 o Renamed Section 6.4 from "Telecommunications Adressing Properties" 3857 to "Communications Properties. 3859 o Added Appendix A and Appendix B. 3861 o Added reference to [RFC4770]. 3863 o Removed the group construct. 3865 o Made the N property no longer mandatory. 3867 o Added the KIND property. 3869 o Clarified meaning of TYPE parameter value for PHOTO, LOGO, KEY, 3870 and SOUND. 3872 o Removed the CONTEXT parameter. 3874 o Removed the MAILER property. 3876 o Made reference to [ISO9070] informative. 3878 o Removed "intl", "dom", "postal", and "parcel" TYPE parameter 3879 values for the ADR and LABEL properties. 3881 o Clarified meaning of "extended address" ADR field. 3883 o Mentioned [RFC3406] as another method of generating PRODID values. 3885 o Updated obsolete references. 3887 o Allowed BDAY and DDAY value types to be text values for fuzzy 3888 dates. 3890 o Removed the CHARSET property. Now the encoding is always UTF-8, 3891 except when overridden by the Content-Type (which is considered a 3892 compatibility feature). 3894 Author's Address 3896 Simon Perreault 3897 Viagenie 3898 2875 Laurier, suite D2-630 3899 Quebec, QC G1V 2M2 3900 Canada 3902 Phone: +1 418 656 9254 3903 EMail: simon.perreault@viagenie.ca 3904 URI: http://www.viagenie.ca