idnits 2.17.1 draft-ietf-vcarddav-vcardrev-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 RFC4770, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document obsoletes RFC2739, but the header doesn't have an 'Obsoletes:' line to match this. -- 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 483 has weird spacing: '... [month day]...' == Line 487 has weird spacing: '... month day...' == Line 488 has weird spacing: '... month day...' == Line 490 has weird spacing: '... month day...' == Line 496 has weird spacing: '... = hour minut...' == (1 more instance...) (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 (May 20, 2011) is 4697 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008' ** Obsolete normative reference: RFC 3536 (Obsoleted by RFC 6365) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-13) exists of draft-ietf-eai-rfc5335bis-10 -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- 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 (~~), 10 warnings (==), 13 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 May 20, 2011 5 (if approved) 6 Updates: 2739 (if approved) 7 Intended status: Standards Track 8 Expires: November 21, 2011 10 vCard Format Specification 11 draft-ietf-vcarddav-vcardrev-20 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.). This document obsoletes RFCs 2425, 2426, 2739, and 20 4770. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 21, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 6 71 3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 6 73 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 7 74 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9 75 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 10 76 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 13 79 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 14 82 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14 83 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 15 84 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16 89 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16 90 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 21 97 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 24 102 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 24 103 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 24 104 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 25 106 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 26 107 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 6.2. Identification Properties . . . . . . . . . . . . . . . . 29 109 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 31 112 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 31 113 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 32 115 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 33 116 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 34 117 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 34 118 6.4. Communications Properties . . . . . . . . . . . . . . . . 35 119 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 35 120 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 37 121 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 38 122 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 38 123 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 39 124 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 39 125 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 40 126 6.6. Organizational Properties . . . . . . . . . . . . . . . . 40 127 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 40 128 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 41 129 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 42 130 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 42 131 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 43 132 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 44 133 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 45 134 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 45 135 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 46 136 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 46 137 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 47 138 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 47 139 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 48 140 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 48 141 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 49 142 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 50 143 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 50 144 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 50 146 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 51 147 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 51 148 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 52 149 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 52 150 6.10. Extended Properties and Parameters . . . . . . . . . . . . 53 151 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 53 152 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 53 153 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 53 154 7.1.2. Matching Property Instances . . . . . . . . . . . . . 54 155 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 54 156 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 55 157 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 55 158 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 55 159 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 56 160 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 56 161 7.2.5. Global Context Simplification . . . . . . . . . . . . 58 162 8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 59 163 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 164 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 165 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 60 166 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 61 167 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 61 168 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 62 169 10.2.3. Registration Template for Properties . . . . . . . . . 63 170 10.2.4. Registration Template for Parameters . . . . . . . . . 63 171 10.2.5. Registration Template for Value Data Types . . . . . . 64 172 10.2.6. Registration Template for Values . . . . . . . . . . . 64 173 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 65 174 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 65 175 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 66 176 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 67 177 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 67 178 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70 179 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 180 12.1. Normative References . . . . . . . . . . . . . . . . . . . 70 181 12.2. Informative References . . . . . . . . . . . . . . . . . . 73 182 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 75 183 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 75 184 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 75 185 A.3. New Properties and Parameters . . . . . . . . . . . . . . 75 186 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 76 187 Appendix B. Change Log (to be removed by RFC Editor prior to 188 publication) . . . . . . . . . . . . . . . . . . . . 76 189 B.1. Changes in -20 . . . . . . . . . . . . . . . . . . . . . . 76 190 B.2. Changes in -19 . . . . . . . . . . . . . . . . . . . . . . 77 191 B.3. Changes in -18 . . . . . . . . . . . . . . . . . . . . . . 77 192 B.4. Changes in -17 . . . . . . . . . . . . . . . . . . . . . . 77 193 B.5. Changes in -16 . . . . . . . . . . . . . . . . . . . . . . 78 194 B.6. Changes in -15 . . . . . . . . . . . . . . . . . . . . . . 78 195 B.7. Changes in -14 . . . . . . . . . . . . . . . . . . . . . . 79 196 B.8. Changes in -13 . . . . . . . . . . . . . . . . . . . . . . 80 197 B.9. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 80 198 B.10. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 81 199 B.11. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 82 200 B.12. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 82 201 B.13. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 82 202 B.14. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 83 203 B.15. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 83 204 B.16. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 84 205 B.17. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 84 206 B.18. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 85 207 B.19. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 85 208 B.20. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 86 209 B.21. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 86 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", "NOT RECOMMENDED", "MAY", and 224 "OPTIONAL" in this document are to be interpreted as described in 225 [RFC2119]. 227 3. vCard Format Specification 229 The text/vcard MIME content type (hereafter known as "vCard", see 230 Section 10.1) contains contact information, typically pertaining to a 231 single contact or group of contacts. The content consists of one or 232 more lines in the format given below. 234 3.1. Charset 236 The charset (see [RFC3536] for internationalization terminology) for 237 vCard is UTF-8 as defined in [RFC3629]. There is no way to override 238 this. It is invalid to specify a value other than "UTF-8" in the 239 "charset" MIME parameter (see Section 10.1). 241 3.2. Line Delimiting and Folding 243 Individual lines within vCard are delimited by the [RFC5322] line 244 break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII 245 decimal 10). Long logical lines of text can be split into a 246 multiple-physical-line representation using the following folding 247 technique. Content lines SHOULD be folded to a maximum width of 75 248 octets, excluding the line break. Multi-octet characters MUST remain 249 contiguous. The rationale for this folding process can be found in 250 [RFC5322], Section 2.1.1. 252 A logical line MAY be continued on the next physical line anywhere 253 between two characters by inserting a CRLF immediately followed by a 254 single white space character (space (ASCII decimal 32) or horizontal 255 tab, (ASCII decimal 9)). The folded line MUST contain at least one 256 character. Any sequence of CRLF followed immediately by a single 257 white space character is ignored (removed) when processing the 258 content type. For example the line: 260 NOTE:This is a long description that exists on a long line. 262 can be represented as: 264 NOTE:This is a long description 265 that exists on a long line. 267 It could also be represented as: 269 NOTE:This is a long descrip 270 tion that exists o 271 n a long line. 273 The process of moving from this folded multiple-line representation 274 of a property definition to its single line representation is called 275 unfolding. Unfolding is accomplished by regarding CRLF immediately 276 followed by a white space character (namely HTAB ASCII decimal 9 or 277 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., 278 the CRLF and single white space character are removed). 280 Note: It is possible for very simple implementations to generate 281 improperly folded lines in the middle of a UTF-8 multi-octet 282 sequence. For this reason, implementations SHOULD unfold lines in 283 such a way as to properly restore the original sequence. 285 Note: Unfolding is done differently than in [RFC5322]. Unfolding 286 in [RFC5322] only removes the CRLF, not the space following it. 288 Folding is done after any content encoding of a type value. 289 Unfolding is done before any decoding of a type value in a content 290 line. 292 3.3. ABNF Format Definition 294 The following ABNF uses the notation of [RFC5234], which also defines 295 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. 297 vcard-entity = 1*vcard 299 vcard = "BEGIN:VCARD" CRLF 300 "VERSION:4.0" CRLF 301 1*contentline 302 "END:VCARD" CRLF 303 ; A vCard object MUST include the VERSION and FN properties. 304 ; VERSION MUST come immediately after BEGIN:VCARD. 306 contentline = [group "."] name *(";" param) ":" value CRLF 307 ; When parsing a content line, folded lines must first 308 ; be unfolded according to the unfolding procedure 309 ; described in section 3.2. 310 ; When generating a content line, lines longer than 75 311 ; characters SHOULD be folded according to the folding 312 ; procedure described in section 3.2. 314 group = 1*(ALPHA / DIGIT / "-") 315 name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME" 316 / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL" 317 / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE" 318 / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES" 319 / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP" 320 / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML" 321 / iana-token / x-name 322 ; Parsing of the param and value is based on the "name" as 323 ; defined in ABNF sections below. 324 ; Group and name are case-insensitive. 326 iana-token = 1*(ALPHA / DIGIT / "-") 327 ; identifier registered with IANA 329 x-name = "x-" 1*(ALPHA / DIGIT / "-") 330 ; Names that begin with "x-" or "X-" are 331 ; reserved for experimental use, not intended for released 332 ; products, or for use in bilateral agreements. 334 param = language-param / value-param / pref-param / pid-param 335 / type-param / geo-parameter / tz-parameter / sort-as-param 336 / calscale-param / any-param 337 ; Allowed parameters depend on property name. 339 param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE 341 any-param = (iana-token / x-name) "=" param-value *("," param-value) 343 NON-ASCII = %x80-FF 344 ; Use is restricted by UTF-8 346 QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII 347 ; Any character except CTLs, DQUOTE 349 SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII 350 ; Any character except CTLs, DQUOTE, ";", ":" 352 VALUE-CHAR = WSP / VCHAR / NON-ASCII 353 ; Any textual character 355 A line that begins with a white space character is a continuation of 356 the previous line, as described in Section 3.2. The white space 357 character and immediately preceeding CRLF should be discarded when 358 reconstructing the original line. Note that this line-folding 359 convention differs from that found in [RFC5322], in that the sequence 360 found anywhere in the content indicates a continued line 361 and should be removed. 363 Property names and parameter names are case insensitive (e.g., the 364 property name "fn" is the same as "FN" and "Fn"). Parameter values 365 MAY be case-sensitive or case-insensitive, depending on their 366 definition. Parameter values that are not explicitly defined as 367 being case-sensitive are case-insenstive. Based on experience with 368 vCard 3 interoperability, it is RECOMMENDED that property and 369 parameter names be upper-case on output. 371 The group construct is used to group related properties together. 372 The group name is a syntactic convention used to indicate that all 373 property names prefaced with the same group name SHOULD be grouped 374 together when displayed by an application. It has no other 375 significance. Implementations that do not understand or support 376 grouping MAY simply strip off any text before a "." to the left of 377 the type name and present the types and values as normal. 379 Property cardinalities are indicated using the following notation, 380 which is based on ABNF (see [RFC5234], section 3.6): 382 +-------------+--------------------------------------------------+ 383 | Cardinality | Meaning | 384 +-------------+--------------------------------------------------+ 385 | 1 | Exactly one instance per vCard MUST be present. | 386 | *1 | Exactly one instance per vCard MAY be present. | 387 | 1* | One or more instances per vCard MUST be present. | 388 | * | One or more instances per vCard MAY be present. | 389 +-------------+--------------------------------------------------+ 391 Properties defined in a vCard instance may have multiple values 392 depending on the property cardinality. The general rule for encoding 393 multi-valued properties is to simply create a new content line for 394 each value (including the property name). However, it should be 395 noted that some value types support encoding multiple values in a 396 single content line by separating the values with a comma ",". This 397 approach has been taken for several of the content types defined 398 below (date, time, integer, float). 400 3.4. Property Value Escaping 402 Some properties may contain one or more values delimited by a COMMA 403 character (ASCII decimal 44). Therefore, a COMMA character in a 404 value MUST be escaped with a BACKSLASH character (ASCII decimal 92), 405 even for properties that don't allow multiple instances (for 406 consistency). 408 Some properties (e.g. N and ADR) comprise multiple fields delimited 409 by a SEMI-COLON character (ASCII decimal 59). Therefore, a SEMI- 410 COLON in a field of such a "compound" property MUST be escaped with a 411 BACKSLASH character. SEMI-COLON characters in non-compound 412 properties MAY be escaped. On input, an escaped SEMI-COLON character 413 is never a field separator. An unescaped SEMI-COLON character may be 414 a field separator, depending on the property in which it appears. 416 Furthermore, some fields of compound properties may contain a list of 417 values delimited by a COMMA character. Therefore, a COMMA character 418 in one of a field's values MUST be escaped with a BACKSLASH 419 character, even for fields that don't allow multiple values (for 420 consistency). Compound properties allowing multiple instances MUST 421 NOT be encoded in a single content line. 423 Finally, BACKSLASH characters in values MUST be escaped with a 424 BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values 425 MUST be encoded by two characters: a BACKSLASH followed by either an 426 'n' (ASCII decimal 110) or an 'N' (ASCII decimal 78). 428 In all other cases, escaping MUST NOT be used. 430 4. Property Value Data Types 432 Standard value types are defined below. 434 value = text 435 / text-list 436 / date-list 437 / time-list 438 / date-time-list 439 / date-and-or-time-list 440 / timestamp-list 441 / boolean 442 / integer-list 443 / float-list 444 / URI ; from Section 3 of [RFC3986] 445 / utc-offset 446 / Language-Tag 447 / iana-valuespec 448 ; Actual value type depends on property name and VALUE parameter. 450 text = *TEXT-CHAR 451 TEXT-CHAR = "\\" / "\," / "\n" 452 / 453 ; Backslashes, commas, and newlines must be encoded. 455 component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII 456 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E 457 list-component = component *("," component) 459 text-list = text *("," text) 460 date-list = date *("," date) 461 time-list = time *("," time) 462 date-time-list = date-time *("," date-time) 463 date-and-or-time-list = date-and-or-time *("," date-and-or-time) 464 timestamp-list = timestamp *("," timestamp) 465 integer-list = integer *("," integer) 466 float-list = float *("," float) 468 boolean = "TRUE" / "FALSE" 469 integer = [sign] 1*DIGIT 470 float = [sign] 1*DIGIT ["." 1*DIGIT] 472 sign = "+" / "-" 474 year = 4DIGIT ; 0000-9999 475 month = 2DIGIT ; 01-12 476 day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year 477 hour = 2DIGIT ; 00-23 478 minute = 2DIGIT ; 00-59 479 second = 2DIGIT ; 00-58/59/60 depending on leap second 480 zone = utc-designator / utc-offset 481 utc-designator = %x5A ; uppercase "Z" 483 date = year [month day] 484 / year "-" month 485 / "--" month [day] 486 / "--" "-" day 487 date-noreduc = year month day 488 / "--" month day 489 / "--" "-" day 490 date-complete = year month day 492 time = hour [minute [second]] [zone] 493 / "-" minute [second] [zone] 494 / "-" "-" second [zone] 495 time-notrunc = hour [minute [second]] [zone] 496 time-complete = hour minute second [zone] 498 time-designator = %x54 ; uppercase "T" 499 date-time = date-noreduc time-designator time-notrunc 500 timestamp = date-complete time-designator time-complete 502 date-and-or-time = date-time / date / time-designator time 504 utc-offset = sign hour [minute] 506 Language-Tag = 508 iana-valuespec = 509 ; a publicly-defined valuetype format, registered 510 ; with IANA, as defined in section 12 of this 511 ; document 513 4.1. TEXT 515 "text": The "text" value type should be used to identify values that 516 contain human-readable text. As for the language, it is controlled 517 by the LANGUAGE property parameter defined in Section 5.1. 519 Examples for "text": 521 this is a text value 522 this is one value,this is another 523 this is a single value\, with a comma encoded 525 A formatted text line break in a text value type MUST be represented 526 as the character sequence backslash (ASCII decimal 92) followed by a 527 Latin small letter n (ASCII decimal 110) or a Latin capital letter N 528 (ASCII decimal 78), that is "\n" or "\N". 530 For example a multiple line NOTE value of: 532 Mythical Manager 533 Hyjinx Software Division 534 BabsCo, Inc. 536 could be represented as: 538 NOTE:Mythical Manager\nHyjinx Software Division\n 539 BabsCo\, Inc.\n 541 demonstrating the \n literal formatted line break technique, the 542 CRLF-followed-by-space line folding technique, and the backslash 543 escape technique. 545 4.2. URI 547 "uri": The "uri" value type should be used to identify values that 548 are referenced by a Uniform Resource Identifier (URI) instead of 549 encoded in-line. These value references might be used if the value 550 is too large, or otherwise undesirable to include directly. The 551 format for the URI is as defined in Section 3 of [RFC3986]. Note 552 that the value of a property of type "uri" is what the URI points to, 553 not the URI itself. 555 Examples for "uri": 557 http://www.example.com/my/picture.jpg 558 ldap://ldap.example.com/cn=babs%20jensen 560 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP 562 "date", "time", "date-time", and "timestamp": Each of these value 563 types is based on the definitions in [ISO.8601.2004] standard. 564 Multiple such values can be specified using the comma-separated 565 notation. 567 Only the basic format is supported. 569 4.3.1. DATE 571 A calendar date as specified in [ISO.8601.2004] section 4.1.2. 573 Reduced accuracy, as specified in [ISO.8601.2004] sections 4.1.2.3 a) 574 and b), but not c), is permitted. 576 Expanded representation, as specified in [ISO.8601.2004] section 577 4.1.4, is forbidden. 579 Truncated representation, as specified in [ISO.8601.2000] sections 580 5.2.1.3 d), e), and f), is permitted. 582 Examples for "date": 584 19850412 585 1985-04 586 1985 587 --0412 588 ---12 590 Note the use of YYYY-MM in the second example above. YYYYMM is 591 disallowed to prevent confusion with YYMMDD. Note also that 592 YYYY-MM-DD is disallowed since we are using the basic format instead 593 of the extended format. 595 4.3.2. TIME 597 A time of day as specified in [ISO.8601.2004] section 4.2. 599 Reduced accuracy, as specified in [ISO.8601.2004] section 4.2.2.3, is 600 permitted. 602 Representation with decimal fraction, as specified in [ISO.8601.2004] 603 section 4.2.2.4, is forbidden. 605 The midnight hour is always represented by 00, never 24 (see 606 [ISO.8601.2004] section 4.2.3). 608 Truncated representation, as specified in [ISO.8601.2000] sections 609 5.3.1.4 a), b), and c), is permitted. 611 Examples for "time": 613 102200 614 1022 615 10 616 -2200 617 --00 618 102200Z 619 102200-0800 621 4.3.3. DATE-TIME 623 A date and time of day combination as specified in [ISO.8601.2004] 624 section 4.3. 626 Truncation of the date part, as specified in [ISO.8601.2000] section 627 5.4.2 c), is permitted. 629 Examples for "date-time": 631 19961022T140000 632 --1022T1400 633 ---22T14 635 4.3.4. DATE-AND-OR-TIME 637 Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous 638 interpretation, a standalone TIME value is always preceded by a "T". 640 Examples for "date-and-or-time": 642 19961022T140000 643 --1022T1400 644 ---22T14 645 19850412 646 1985-04 647 1985 648 --0412 649 ---12 650 T102200 651 T1022 652 T10 653 T-2200 654 T--00 655 T102200Z 656 T102200-0800 658 4.3.5. TIMESTAMP 660 A complete date and time of day combination as specified in 661 [ISO.8601.2004] section 4.3.2. 663 Examples for "timestamp": 665 19961022T140000 666 19961022T140000Z 667 19961022T140000-05 668 19961022T140000-0500 670 4.4. BOOLEAN 672 "boolean": The "boolean" value type is used to express boolean 673 values. These values are case insensitive. 675 Examples: 677 TRUE 678 false 679 True 681 4.5. INTEGER 683 "integer": The "integer" value type is used to express signed 684 integers in decimal format. If sign is not specified, the value is 685 assumed positive "+". Multiple "integer" values can be specified 686 using the comma-separated notation. The maximum value is 687 9223372036854775807 and the minimum value is -9223372036854775808. 689 These limits correspond to a signed 64-bit integer using two's- 690 complement arithmetic. 692 Examples: 694 1234567890 695 -1234556790 696 +1234556790,432109876 698 4.6. FLOAT 700 "float": The "float" value type is used to express real numbers. If 701 sign is not specified, the value is assumed positive "+". Multiple 702 "float" values can be specified using the comma-separated notation. 703 Implementations MUST support a precision equal or better than that of 704 the IEEE "binary64" format [IEEE.754.2008]. 706 Note: Scientific notation is disallowed. Implementors wishing to 707 use their favorite language's %f formatting should be careful. 709 Examples: 711 20.30 712 1000000.0000001 713 1.333,3.14 715 4.7. UTC-OFFSET 717 "utc-offset": The "utc-offset" value type specifies that the property 718 value is a signed offset from UTC. This value type can be specified 719 in the TZ property. 721 The value type is an offset from Coordinated Universal Time (UTC). 722 It is specified as a positive or negative difference in units of 723 hours and minutes (e.g., +hhmm). The time is specified as a 24-hour 724 clock. Hour values are from 00 to 23, and minute values are from 00 725 to 59. Hour and minutes are 2-digits with high order zeroes required 726 to maintain digit count. The basic format for ISO 8601 UTC offsets 727 MUST be used. 729 4.8. LANGUAGE-TAG 731 "language-tag": A single language tag, as defined in [RFC5646]. 733 5. Property Parameters 735 A property can have attributes associated with it. These "property 736 parameters" contain meta-information about the property or the 737 property value. In some cases the property parameter can be multi- 738 valued in which case the property parameter value elements are 739 separated by a COMMA (US-ASCII decimal 44). 741 Property parameter value elements that contain the COLON (US-ASCII 742 decimal 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII 743 decimal 44) character separators MUST be specified as quoted-string 744 text values. Property parameter values MUST NOT contain the DQUOTE 745 (US-ASCII decimal 34) character. The DQUOTE character is used as a 746 delimiter for parameter values that contain restricted characters or 747 URI text. 749 Applications MUST ignore x-param and iana-param values they don't 750 recognize. 752 5.1. LANGUAGE 754 The LANGUAGE property parameter is used to identify data in multiple 755 languages. There is no concept of "default" language, except as 756 specified by any "Content-Language" MIME header parameter that is 757 present [RFC3282]. The value of the LANGUAGE property parameter is a 758 language tag as defined in Section 2 of [RFC5646]. 760 Examples: 762 ROLE;LANGUAGE=tr:hoca 764 ABNF: 766 language-param = "LANGUAGE=" Language-Tag 767 ; Language-Tag is defined in section 2.1 of RFC 5646 769 5.2. VALUE 771 The VALUE parameter is optional, used to identify the value type 772 (data type) and format of the value. The use of these predefined 773 formats is encouraged even if the value parameter is not explicitly 774 used. By defining a standard set of value types and their formats, 775 existing parsing and processing code can be leveraged. The 776 predefined data type values MUST NOT be repeated in COMMA separated 777 value lists except within the N, NICKNAME, ADR, and CATEGORIES 778 properties. 780 ABNF: 782 value-param = "VALUE=" value-type 784 value-type = "text" 785 / "uri" 786 / "date" 787 / "time" 788 / "date-time" 789 / "date-and-or-time" 790 / "timestamp" 791 / "boolean" 792 / "integer" 793 / "float" 794 / "utc-offset" 795 / "language-tag" 796 / iana-token ; registered as described in section 12 797 / x-name 799 5.3. PREF 801 The PREF parameter is optional and is used to indicate that the 802 corresponding instance of a property is preferred by the vCard 803 author. Its value MUST be an integer between 1 and 100 that 804 quantifies the level of preference. Lower values correspond to a 805 higher level of preference, 1 being most preferred. 807 When the parameter is absent, the default MUST be to interpret the 808 property instance as being least preferred. 810 Note that the value of this parameter is to be interpreted only in 811 relation to values assigned to other instances of the same property 812 in the same vCard. A given value, or the absence of a value, MUST 813 NOT be interpreted on its own. 815 This parameter MAY be applied to any property that allows multiple 816 instances. 818 ABNF: 820 pref-param = "PREF=" (1*2DIGIT / "100") 821 ; An integer between 1 and 100. 823 5.4. ALTID 825 The ALTID parameter is used to "tag" property instances as being 826 alternative representations of the same logical property. For 827 example, translations of a property in multiple languages generates 828 multiple property instances having different LANGUAGE (Section 5.1) 829 parameter which are tagged with the same ALTID value. 831 This parameter's value is treated as an opaque string. Its sole 832 purpose is to be compared for equality against other ALTID parameter 833 values. 835 Two property instances are considered alternative representations of 836 the same logical property if and only if their names as well as the 837 value of their ALTID parameters are identical. Property instances 838 without the ALTID parameter MUST NOT be considered an alternative 839 representation of any other property instance. Values for the ALTID 840 parameter are not globally unique: they MAY be reused for different 841 property names. 843 Property instances having the same ALTID parameter value count as 1 844 toward cardinality. Therefore, since N (Section 6.2.2) has 845 cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these 846 three examples would be legal: 848 N;ALTID=1;LANGUAGE=jp:;;;; 849 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 850 ( denotes a UTF8-encoded Unicode character.) 852 TITLE;ALTID=1;LANGUAGE=fr:Patron 853 TITLE;ALTID=1;LANGUAGE=en:Boss 855 TITLE;ALTID=1;LANGUAGE=fr:Patron 856 TITLE;ALTID=1;LANGUAGE=en:Boss 857 TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist 859 while this one would not: 861 N;ALTID=1;LANGUAGE=jp:;;;; 862 N:Yamada;Taro;;; 863 (Two instances of the N property.) 865 and these three would be legal but questionable: 867 TITLE;ALTID=1;LANGUAGE=fr:Patron 868 TITLE;ALTID=2;LANGUAGE=en:Boss 869 (Should probably have the same ALTID value.) 871 TITLE;ALTID=1;LANGUAGE=fr:Patron 872 TITLE:LANGUAGE=en:Boss 873 (Second line should probably have ALTID=1.) 875 N;ALTID=1;LANGUAGE=jp:;;;; 876 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 877 N;ALTID=1;LANGUAGE=en:Smith;John;;; 878 (The last line should probably have ALTID=2. But that would be 879 illegal because N has cardinality *1.) 881 The ALTID property MAY also be used in may contexts other than with 882 the LANGUAGE parameter. Here's an example with two representations 883 of the same photo in different file formats: 885 PHOTO;ALTID=1:data:image/jpeg;base64,... 886 PHOTO;ALTID=1;data:image/jp2;base64,... 888 ABNF: 890 altid-param = "ALTID=" param-value 892 5.5. PID 894 The PID parameter is used to identify a specific property among 895 multiple instances. It plays a role analogous to the UID property 896 (Section 6.7.6) on a per-property instead of per-vCard basis. It MAY 897 appear more than once in a given property. It MUST NOT appear on 898 properties that may have only one instance per vCard. Its value is 899 either a single small positive integer or a pair of small positive 900 integers separated by a dot. Multiple values may be encoded in a 901 single PID parameter by separating the values with a comma ",". See 902 Section 7 for more details on its usage. 904 ABNF: 906 pid-param = "PID=" pid-value *("," pid-value) 907 pid-value = 1*DIGIT ["." 1*DIGIT] 909 5.6. TYPE 911 The TYPE parameter has multiple, different uses. In general, it is a 912 way of specifying class characteristics of the associated property. 913 Most of the time, its value is a comma-separated subset of a pre- 914 defined enumeration. In this document, the following properties make 915 use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL, IMPP, 916 LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES, NOTE, 917 SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE parameter 918 MUST NOT be applied on other properties defined in this document. 920 The "work" and "home" values act like tags. The "work" value implies 921 that the property is related to an individual's work place, while the 922 "home" value implies that the property is related to an individual's 923 personal life. When neither "work" nor "home" is present, it is 924 implied that the property is related to both an individual's work 925 place and personal life in the case that the KIND property's value is 926 "individual", or to none in other cases. 928 ABNF: 930 type-param = "TYPE=" type-value *("," type-value) 932 type-value = "work" / "home" / type-param-tel 933 / type-param-related / iana-token / x-name 934 ; This is further defined in individual property sections. 936 5.7. MEDIATYPE 938 The MEDIATYPE parameter is used with properties whose value is a URI. 939 Its use is OPTIONAL. It provides a hint to the vCard consumer 940 application about the media type [RFC2046] of the resource identified 941 by the URI. Some URI schemes do not need this parameter. For 942 example, the "data" scheme allows the media type to be explicitly 943 indicated as part of the URI [RFC2397]. Another scheme, "http", 944 provides the media type as part of the URI resolution process, with 945 the Content-Type HTTP header [RFC2616]. The MEDIATYPE parameter is 946 intended to be used with URI schemes that do not provide such 947 functionality (e.g. "ftp" [RFC1738]). 949 ABNF: 951 mediatype-param = "MEDIATYPE=" mediatype 952 mediatype = type-name "/" subtype-name *( ";" attribute "=" value ) 953 ; "attribute" and "value" are from [RFC2045] 954 ; "type-name" and "subtype-name" are from [RFC4288] 956 5.8. CALSCALE 958 The CALSCALE parameter is identical to the CALSCALE property in 959 iCalendar (see [RFC5545], section 3.7.1). It is used to define the 960 calendar system in which a date or date-time value is expressed. The 961 only value specified by iCalendar is "gregorian", which stands for 962 the Gregorian system. It is the default when the parameter is 963 absent. Additional values may be defined in extension documents and 964 registered from IANA (see Section 10.3.4). A vCard implementation 965 MUST ignore properties with a CALSCALE parameter value that it does 966 not understand. 968 ABNF: 970 calscale-param = "CALSCALE=" calscale-value 972 calscale-value = "gregorian" / iana-token / x-name 974 5.9. SORT-AS 976 The "sort-as" parameter is used to specify the string to be used for 977 national-language-specific sorting. Without this information, 978 sorting algorithms could incorrectly sort this vCard within a 979 sequence of sorted vCards. When this property is present in a vCard, 980 then the given strings are used for sorting the vCard. 982 This parameter's value is a comma-separated list which MUST have as 983 many or fewer elements as the corresponding property value has 984 components. This parameter's value is case-sensitive. 986 ABNF: 988 sort-as-param = "SORT-AS=" sort-as-value 990 sort-as-value = param-value *("," param-value) 992 Examples: For the case of surname and given name sorting, the 993 following examples define common sort string usage with the N 994 property. 996 FN:Rene van der Harten 997 N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N. 999 FN:Robert Pau Shou Chang 1000 N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;; 1002 FN:Osamu Koura 1003 N;SORT-AS="Koura,Osamu":Koura;Osamu;; 1005 FN:Oscar del Pozo 1006 N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;; 1008 FN:Chistine d'Aboville 1009 N;SORT-AS="Aboville,Christine":d'Aboville;Christine;; 1011 FN:H. James de Mann 1012 N;SORT-AS="Mann,James":de Mann;Henry,James;; 1014 If sorted by surname the results would be: 1016 Christine d'Aboville 1017 Rene van der Harten 1018 Osamu Koura 1019 H. James de Mann 1020 Robert Pau Shou Chang 1021 Oscar del Pozo 1023 If sorted by given name the results would be: 1025 Christine d'Aboville 1026 H. James de Mann 1027 Osamu Koura 1028 Oscar del Pozo 1029 Rene van der Harten 1030 Robert Pau Shou Chang 1032 5.10. GEO 1034 The GEO parameter can be used to indicate global positioning 1035 information that is specific to an address. Its value is the same as 1036 that of the GEO property (see Section 6.5.2). 1038 ABNF: 1040 geo-parameter = "GEO=" DQUOTE URI DQUOTE 1042 5.11. TZ 1044 The TZ parameter can be used to indicate time zone information that 1045 is specific to an address. Its value is the same as that of the TZ 1046 property. 1048 ABNF: 1050 tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE) 1052 6. vCard Properties 1054 What follows is an enumeration of the standard vCard properties. 1056 6.1. General Properties 1058 6.1.1. BEGIN 1060 Purpose: To denote the beginning of a syntactic entity within a 1061 text/vcard content-type. 1063 Value type: text 1065 Cardinality: 1 1067 Special notes: The content entity MUST begin with the BEGIN property 1068 with a value of "VCARD". The value is case-insensitive. 1070 The BEGIN property is used in conjunction with the END property to 1071 delimit an entity containing a related set of properties within an 1072 text/vcard content-type. This construct can be used instead of 1073 including multiple vCards as body parts inside of a multipart/ 1074 alternative MIME message. It is provided for applications that 1075 wish to define content that can contain multiple entities within 1076 the same text/vcard content-type or to define content that can be 1077 identifiable outside of a MIME environment. 1079 ABNF: 1081 BEGIN-param = 0 ; no parameter allowed 1082 BEGIN-value = "VCARD" 1084 Example: 1086 BEGIN:VCARD 1088 6.1.2. END 1090 Purpose: To denote the end of a syntactic entity within a text/vcard 1091 content-type. 1093 Value type: text 1095 Cardinality: 1 1097 Special notes: The content entity MUST end with the END type with a 1098 value of "VCARD". The value is case-insensitive. 1100 The END property is used in conjunction with the BEGIN property to 1101 delimit an entity containing a related set of properties within an 1102 text/vcard content-type. This construct can be used instead of or 1103 in addition to wrapping separate sets of information inside 1104 additional MIME headers. It is provided for applications that 1105 wish to define content that can contain multiple entities within 1106 the same text/vcard content-type or to define content that can be 1107 identifiable outside of a MIME environment. 1109 ABNF: 1111 END-param = 0 ; no parameter allowed 1112 END-value = "VCARD" 1114 Example: 1116 END:VCARD 1118 6.1.3. SOURCE 1120 Purpose: To identify the source of directory information contained 1121 in the content type. 1123 Value type: uri 1125 Cardinality: * 1127 Special notes: The SOURCE property is used to provide the means by 1128 which applications knowledgable in the given directory service 1129 protocol can obtain additional or more up-to-date information from 1130 the directory service. It contains a URI as defined in [RFC3986] 1131 and/or other information referencing the vCard to which the 1132 information pertains. When directory information is available 1133 from more than one source, the sending entity can pick what it 1134 considers to be the best source, or multiple SOURCE properties can 1135 be included. 1137 ABNF: 1139 SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param 1140 / mediatype-param / any-param 1141 SOURCE-value = URI 1143 Examples: 1145 SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US 1147 SOURCE:http://directory.example.com/addressbooks/jdoe/ 1148 Jean%20Dupont.vcf 1150 6.1.4. KIND 1152 Purpose: To specify the kind of object the vCard represents. 1154 Value type: A single text value. 1156 Cardinality: *1 1158 Special notes: The value may be one of the following: 1160 "individual" for a vCard representing a single person or entity. 1161 This is the default kind of vCard. 1163 "group" for a vCard representing a group of persons or entities. 1164 The group's member entities can be other vCards or other types 1165 of entities, such as email addresses or web sites. A group 1166 vCard will usually contain MEMBER properties to specify the 1167 members of the group, but it is not required to. A group vCard 1168 without MEMBER properties can be considered an abstract 1169 grouping, or one whose members are known empirically (perhaps 1170 "IETF Participants" or "Republican U.S. Senators"). 1172 All properties in a group vCard apply to the group as a whole, 1173 and not to any particular MEMBER. For example, an EMAIL 1174 property might specify the address of a mailing list associated 1175 with the group, and an IMPP property might refer to a group 1176 chat room. 1178 "org" for a vCard representing an organization. An organization 1179 vCard will not (in fact, MUST NOT) contain MEMBER properties, 1180 and so these are something of a cross between "individual" and 1181 "group". An organization is a single entity, but not a person. 1182 It might represent a business or government, a department or 1183 division within a business or government, a club, an 1184 association, or the like. 1186 All properties in an organization vCard apply to the 1187 organization as a whole, as is the case with a group vCard. 1188 For example, an EMAIL property might specify the address of a 1189 contact point for the organization. 1191 "location" for a named geographical place. A location vCard will 1192 usually contain a GEO property, but it is not required to. A 1193 location vCard without a GEO property can be considered an 1194 abstract location, or one whose definition is known empirically 1195 (perhaps "New England" or "The Seashore"). 1197 All properties in a location vCard apply to the location 1198 itself, and not with any entity that might exist at that 1199 location. For example, in a vCard for an office building, an 1200 ADR property might give the mailing address for the building, 1201 and a TEL property might specify the telephone number of the 1202 receptionist. 1204 An x-name. vCards MAY include private or experimental values for 1205 KIND. Remember that x-name values are not intended for general 1206 use, and are unlikely to interoperate. 1208 An iana-token. Additional values may be registered with IANA (see 1209 Section 10.3.4). A new value's specification document MUST 1210 specify which properties make sense for that new kind of vCard 1211 and which do not. 1213 Implementations MUST support the specific string values defined 1214 above. If this property is absent, "individual" MUST be assumed 1215 as the default. If this property is present but the 1216 implementation does not understand its value (the value is an 1217 x-name or iana-token that the implementation does not support), 1218 the implementation SHOULD act in a neutral way, which usually 1219 means treating the vCard as though its kind were "individual". 1220 The presence of MEMBER properties MAY, however, be taken as an 1221 indication that the unknown kind is an extension of "group". 1223 Clients often need to visually distinguish contacts based on what 1224 they represent, and the KIND property provides a direct way for 1225 them to do so. For example, when displaying contacts in a list, 1226 an icon could be displayed next to each one, using distinctive 1227 icons for the different kinds; a client might use an outline of a 1228 single person to represent an "individual", an outline of multiple 1229 people to represent a "group", and so on. Alternatively, or in 1230 addition, a client might choose to segregate different kinds of 1231 vCards to different panes, tabs, or selections in the user 1232 interface. 1234 Some clients might also make functional distinctions among the 1235 kinds, ignoring "location" vCards for some purposes and 1236 considering only "location" vCards for others. 1238 When designing those sorts of visual and functional distinctions, 1239 client implementations have to decide how to fit unsupported kinds 1240 into the scheme. What icon is used for them? The one for 1241 "individual"? A unique one, such as an icon of a question-mark? 1242 Which tab do they go into? It is beyond the scope of this 1243 specification to answer these questions, but these are things 1244 implementors need to consider. 1246 ABNF: 1248 KIND-param = "VALUE=text" / any-param 1249 KIND-value = "individual" / "group" / "org" / "location" 1250 / iana-token / x-name 1252 Example: 1254 This represents someone named Jane Doe working in the marketing 1255 department of the North American division of ABC Inc. 1257 BEGIN:VCARD 1258 VERSION:4.0 1259 KIND:individual 1260 FN:Jane Doe 1261 ORG:ABC\, Inc.;North American Division;Marketing 1262 END:VCARD 1264 This represents the department itself, commonly known as ABC 1265 Marketing. 1267 BEGIN:VCARD 1268 VERSION:4.0 1269 KIND:org 1270 FN:ABC Marketing 1271 ORG:ABC\, Inc.;North American Division;Marketing 1272 END:VCARD 1274 6.1.5. XML 1276 Purpose: To include extended XML-encoded vCard data in a plain 1277 vCard. 1279 Value type: A single text value. 1281 Cardinality: * 1283 Special notes: The content of this property is a single XML 1.0 1284 [W3C.REC-xml-20081126] element whose namespace MUST be explicitly 1285 specified using the xmlns attribute and MUST NOT be the vCard 4 1286 namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies 1287 that it cannot duplicate a standard vCard property.) The element 1288 is to be interpreted as if it was contained in a element, 1289 as defined in [I-D.ietf-vcarddav-vcardxml]. 1291 The fragment is subject to normal line folding and escaping, i.e. 1292 replace all backslashes with "\\", then replace all newlines with 1293 "\n", then fold long lines. 1295 Support for this property is OPTIONAL, but implementations of this 1296 specification MUST preserve instances of this property when 1297 propagating vCards. 1299 See [I-D.ietf-vcarddav-vcardxml] for more information on the 1300 intended use of this property. 1302 ABNF: 1304 XML-param = "VALUE=text" / altid-param 1305 XML-value = text 1307 6.2. Identification Properties 1309 These types are used to capture information associated with the 1310 identification and naming of the entity associated with the vCard. 1312 6.2.1. FN 1314 Purpose: To specify the formatted text corresponding to the name of 1315 the object the vCard represents. 1317 Value type: A single text value. 1319 Cardinality: 1* 1321 Special notes: This property is based on the semantics of the X.520 1322 Common Name attribute. The property MUST be present in the vCard 1323 object. 1325 ABNF: 1327 FN-param = "VALUE=text" / type-param / language-param / altid-param 1328 / pid-param / pref-param / any-param 1329 FN-value = text 1331 Example: 1333 FN:Mr. John Q. Public\, Esq. 1335 6.2.2. N 1337 Purpose: To specify the components of the name of the object the 1338 vCard represents. 1340 Value type: A single structured text value. Each component can have 1341 multiple values. 1343 Cardinality: *1 1345 Special note: The structured property value corresponds, in 1346 sequence, to the Family Names (also known as surnames), Given 1347 Names, Additional Names, Honorific Prefixes, and Honorific 1348 Suffixes. The text components are separated by the SEMI-COLON 1349 character (ASCII decimal 59). Individual text components can 1350 include multiple text values separated by the COMMA character 1351 (ASCII decimal 44). This property is based on the semantics of 1352 the X.520 individual name attributes. The property SHOULD be 1353 present in the vCard object when the name of the object the vCard 1354 represents follows the X.520 model. 1356 The SORT-AS parameter MAY be applied to this property. 1358 ABNF: 1360 N-param = "VALUE=text" / sort-as-param / language-param 1361 / altid-param / any-param 1362 N-value = list-component 4(";" list-component) 1364 Examples: 1366 N:Public;John;Quinlan;Mr.;Esq. 1368 N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P. 1370 6.2.3. NICKNAME 1372 Purpose: To specify the text corresponding to the nickname of the 1373 object the vCard represents. 1375 Value type: One or more text values separated by a COMMA character 1376 (ASCII decimal 44). 1378 Cardinality: * 1380 Special note: The nickname is the descriptive name given instead of 1381 or in addition to the one belonging to a the object the vCard 1382 represents. It can also be used to specify a familiar form of a 1383 proper name specified by the FN or N properties. 1385 ABNF: 1387 NICKNAME-param = "VALUE=text" / type-param / language-param 1388 / altid-param / pid-param / pref-param / any-param 1389 NICKNAME-value = text-list 1391 Examples: 1393 NICKNAME:Robbie 1395 NICKNAME:Jim,Jimmie 1397 NICKNAME;TYPE=work:Boss 1399 6.2.4. PHOTO 1401 Purpose: To specify an image or photograph information that 1402 annotates some aspect of the object the vCard represents. 1404 Value type: A single URI. 1406 Cardinality: * 1408 ABNF: 1410 PHOTO-param = "VALUE=uri" / altid-param / type-param 1411 / mediatype-param / pref-param / pid-param / any-param 1412 PHOTO-value = URI 1414 Examples: 1416 PHOTO:http://www.example.com/pub/photos/jqpublic.gif 1418 PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv 1419 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1420 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1421 <...remainder of base64-encoded data...> 1423 6.2.5. BDAY 1425 Purpose: To specify the birth date of the object the vCard 1426 represents. 1428 Value type: The default is a single date-and-or-time value. It can 1429 also be reset to a single text value. 1431 Cardinality: *1 1433 ABNF: 1435 BDAY-param = BDAY-param-date / BDAY-param-text 1436 BDAY-value = date-and-or-time / text 1437 ; Value and parameter MUST match. 1439 BDAY-param-date = "VALUE=date-and-or-time" 1440 BDAY-param-text = "VALUE=text" / language-param 1442 BDAY-param =/ altid-param / calscale-param / any-param 1443 ; calscale-param can only be present when BDAY-value is 1444 ; date-and-or-time and actually contains a date or date-time. 1446 Examples: 1448 BDAY:19960415 1449 BDAY:--0415 1450 BDAY;19531015T231000Z 1451 BDAY;VALUE=text:circa 1800 1453 6.2.6. ANNIVERSARY 1455 Purpose: The date of marriage, or equivalent, of the object the 1456 vCard represents. 1458 Value type: The default is a single date-and-or-time value. It can 1459 also be reset to a single text value. 1461 Cardinality: *1 1463 ABNF: 1465 ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text") 1466 ANNIVERSARY-value = date-and-or-time / text 1467 ; Value and parameter MUST match. 1469 ANNIVERSARY-param =/ altid-param / calscale-param / any-param 1470 ; calscale-param can only be present when ANNIVERSARY-value is 1471 ; date-and-or-time and actually contains a date or date-time. 1473 Examples: 1475 ANNIVERSARY:19960415 1477 6.2.7. GENDER 1479 Purpose: To specify the components of the sex and gender identity of 1480 the object the vCard represents. 1482 Value type: A single structured value with two components. Each 1483 component has a single text value. 1485 Cardinality: *1 1487 Special notes: The components correspond, in sequence, to the sex 1488 (biological), and gender identity. Each component is optional. 1490 Sex component: A single letter. M stands for "male", F stands 1491 for "female", O stands for "other", N stands for "none or not 1492 applicable", U stands for "unknown". 1494 Gender identity component: Free-form text. 1496 ABNF: 1498 GENDER-param = "VALUE=text" / any-param 1499 GENDER-value = sex [";" text] 1501 sex = "" / "M" / "F" / "O" / "N" / "U" 1503 Examples: 1505 GENDER:M 1506 GENDER:F 1507 GENDER:M;Fellow 1508 GENDER:F;Bird 1509 GENDER:O;intersex 1510 GENDER:;queer 1512 6.3. Delivery Addressing Properties 1514 These types are concerned with information related to the delivery 1515 addressing or label for the vCard object. 1517 6.3.1. ADR 1519 Purpose: To specify the components of the delivery address for the 1520 vCard object. 1522 Value type: A single structured text value, separated by the SEMI- 1523 COLON character (ASCII decimal 59). 1525 Cardinality: * 1527 Special notes: The structured type value consists of a sequence of 1528 address components. The component values MUST be specified in 1529 their corresponding position. The structured type value 1530 corresponds, in sequence, to 1531 the post office box; 1532 the extended address (e.g. apartment or suite number); 1533 the street address; 1534 the locality (e.g., city); 1535 the region (e.g., state or province); 1536 the postal code; 1537 the country name (full name in the language specified in 1538 Section 5.1). 1539 When a component value is missing, the associated component 1540 separator MUST still be specified. 1542 Experience with vCard 3 has shown that the first two components 1543 (post office box and extended address) are plagued with many 1544 interoperability issues. To ensure maximal interoperability, 1545 their values SHOULD be empty. 1547 The text components are separated by the SEMI-COLON character 1548 (ASCII decimal 59). Where it makes semantic sense, individual 1549 text components can include multiple text values (e.g., a "street" 1550 component with multiple lines) separated by the COMMA character 1551 (ASCII decimal 44). 1553 The property can include the "PREF" parameter to indicate the 1554 preferred delivery address when more than one address is 1555 specified. 1557 The GEO and TZ parameters MAY be used with this property. 1559 The property can also include a "LABEL" parameter to present a 1560 delivery delivery address label for the address. Its value is a 1561 plain-text string representing the formatted address. Newlines 1562 are encoded as \n, as they are for property values. 1564 ABNF: 1566 label-param = "LABEL=" param-value 1568 ADR-param = "VALUE=text" / label-param / language-param 1569 / geo-parameter / tz-parameter / altid-param / pid-param 1570 / pref-param / type-param / any-param 1571 ADR-value = ADR-component-pobox ";" ADR-component-ext ";" 1572 ADR-component-street ";" ADR-component-locality ";" 1573 ADR-component-region ";" ADR-component-code ";" 1574 ADR-component-country 1575 ADR-component-pobox = list-component 1576 ADR-component-ext = list-component 1577 ADR-component-street = list-component 1578 ADR-component-locality = list-component 1579 ADR-component-region = list-component 1580 ADR-component-code = list-component 1581 ADR-component-country = list-component 1583 Example: In this example the post office box and the extended address 1584 are absent. 1586 ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n 1587 Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n 1588 U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A. 1590 6.4. Communications Properties 1592 These properties describe information about how to communicate with 1593 the object the vCard represents. 1595 6.4.1. TEL 1596 Purpose: To specify the telephone number for telephony communication 1597 with the object the vCard represents. 1599 Value type: By default it is a single free-form text value (for 1600 backward compatibility with vCard 3), but it SHOULD be reset to a 1601 URI value. It is expected that the URI scheme will be "tel", as 1602 specified in [RFC3966], but other schemes MAY be used. 1604 Cardinality: * 1606 Special notes: This property is based on the X.520 Telephone Number 1607 attribute. 1609 The property can include the "PREF" parameter to indicate a 1610 preferred-use telephone number. 1612 The property can include the parameter "TYPE" to specify intended 1613 use for the telephone number. The predefined values for the TYPE 1614 parameter are: 1616 +-----------+-------------------------------------------------------+ 1617 | Value | Description | 1618 +-----------+-------------------------------------------------------+ 1619 | text | Indicates that the telephone number supports text | 1620 | | messages (SMS). | 1621 | voice | Indicates a voice telephone number. | 1622 | fax | Indicates a facsimile telephone number. | 1623 | cell | Indicates a cellular or mobile telephone number. | 1624 | video | Indicates a video conferencing telephone number. | 1625 | pager | Indicates a paging device telephone number. | 1626 | textphone | Indicates a telecommunication device for people with | 1627 | | hearing or speech difficulties.. | 1628 +-----------+-------------------------------------------------------+ 1630 The default type is "voice". These type parameter values can be 1631 specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a 1632 value list (e.g., TYPE="text,voice"). The default can be 1633 overridden to another set of values by specifying one or more 1634 alternate values. For example, the default TYPE of "voice" can be 1635 reset to a VOICE and FAX telephone number by the value list 1636 TYPE="voice,fax". 1638 If this property's value is a URI that can also be used for 1639 instant messaging, the IMPP (Section 6.4.3) property SHOULD be 1640 used in addition to this property. 1642 ABNF: 1644 TEL-param = TEL-text-param / TEL-uri-param 1645 TEL-value = TEL-text-value / TEL-uri-value 1646 ; Value and parameter MUST match 1648 TEL-text-param = "VALUE=text" 1649 TEL-text-value = text 1651 TEL-uri-param = "VALUE=uri" / mediatype-param 1652 TEL-uri-value = URI 1654 TEL-param =/ type-param / pid-param / pref-param / altid-param 1655 / any-param 1657 type-param-tel = "text" / "voice" / "fax" / "cell" / "video" 1658 / "pager" / "textphone" / iana-token / x-name 1659 ; type-param-tel MUST NOT be used with a property other than TEL. 1661 Example: 1663 TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555 1664 TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67 1666 6.4.2. EMAIL 1668 Purpose: To specify the electronic mail address for communication 1669 with the object the vCard represents. 1671 Value type: A single text value. 1673 Cardinality: * 1675 Special notes: The property can include tye "PREF" parameter to 1676 indicate a preferred-use email address when more than one is 1677 specified. 1679 Even though the value is free-form UTF-8 text, it is likely to be 1680 interpreted by an MUA as an "addr-spec", as defined in [RFC5322], 1681 section 3.4.1. Readers should also be aware of the current work 1682 toward internationalized email addresses 1683 [I-D.ietf-eai-rfc5335bis]. 1685 ABNF: 1687 EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param 1688 / altid-param / any-param 1689 EMAIL-value = text 1691 Example: 1693 EMAIL;TYPE=work:jqpublic@xyz.example.com 1695 EMAIL;PREF=1:jane_doe@example.com 1697 6.4.3. IMPP 1699 Purpose: To specify the URI for instant messaging and presence 1700 protocol communications with the object the vCard represents. 1702 Value type: A single URI. 1704 Cardinality: * 1706 Special notes: The property may include the "PREF" parameter to 1707 indicate that this is a preferred address and has the same 1708 semantics as the "PREF" parameter in a TEL property. 1710 If this property's value is a URI that can be used for voice 1711 and/or video, the TEL property (Section 6.4.1) SHOULD be used in 1712 addition to this property. 1714 This property is adapted from [RFC4770], which is made obsolete by 1715 this document. 1717 ABNF: 1719 IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param 1720 / mediatype-param / altid-param / any-param 1721 IMPP-value = URI 1723 Example: 1725 IMPP;PREF=1:xmpp:alice@example.com 1727 6.4.4. LANG 1729 Purpose: To specify the language(s) that may be used for contacting 1730 the entity associated with the vCard. 1732 Value type: A single language-tag value. 1734 Cardinality: * 1735 ABNF: 1737 LANG-param = "VALUE=language-tag" / pid-param / pref-param 1738 / altid-param / type-param / any-param 1739 LANG-value = Language-Tag 1741 Example: 1743 LANG;TYPE=work;PREF=1:en 1744 LANG;TYPE=work;PREF=2:fr 1745 LANG;TYPE=home:fr 1747 6.5. Geographical Properties 1749 These properties are concerned with information associated with 1750 geographical positions or regions associated with the object the 1751 vCard represents. 1753 6.5.1. TZ 1755 Purpose: To specify information related to the time zone of the 1756 object the vCard represents. 1758 Value type: The default is a single text value. It can also be 1759 reset to a single URI or utc-offset value. 1761 Cardinality: * 1763 Special notes: It is expected that names from the public-domain 1764 Olson database [TZ-DB] will be used, but this is not a 1765 restriction. 1767 Efforts are currently being directed at creating a standard URI 1768 scheme for expressing time zone information. Usage of such a 1769 scheme would ensure a high level of interoperability between 1770 implementations that support it. 1772 Note that utc-offset values SHOULD NOT be used because the UTC 1773 offset varies with time - not just because of the usual daylight 1774 saving time shifts that occur in may regions, but often entire 1775 regions will "re-base" their overall offset. The actual offset 1776 may be +/- 1 hour (or perhaps a little more) than the one given. 1778 ABNF: 1780 TZ-param = "VALUE=" ("text" / "uri" / "utc-offset") 1781 TZ-value = text / URI / utc-offset 1782 ; Value and parameter MUST match 1784 TZ-param =/ altid-param / pid-param / pref-param / type-param 1785 / mediatype-param / any-param 1787 Examples: 1789 TZ:Raleigh/North America 1791 TZ;VALUE=utc-offset:-0500 1792 ; Note: utc-offset format is NOT RECOMMENDED. 1794 6.5.2. GEO 1796 Purpose: To specify information related to the global positioning of 1797 the object the vCard represents. 1799 Value type: A single URI. 1801 Cardinality: * 1803 Special notes: The "geo" URI scheme [RFC5870] is particularly well- 1804 suited for this property, but other schemes MAY be used. 1806 ABNF: 1808 GEO-param = "VALUE=uri" / pid-param / pref-param / type-param 1809 / mediatype-param / altid-param / any-param 1810 GEO-value = URI 1812 Example: 1814 GEO:geo:37.386013,-122.082932 1816 6.6. Organizational Properties 1818 These properties are concerned with information associated with 1819 characteristics of the organization or organizational units of the 1820 object that the vCard represents. 1822 6.6.1. TITLE 1823 Purpose: To specify the position or job of the object the vCard 1824 represents. 1826 Value type: A single text value. 1828 Cardinality: * 1830 Special notes: This property is based on the X.520 Title attribute. 1832 ABNF: 1834 TITLE-param = "VALUE=text" / language-param / pid-param 1835 / pref-param / altid-param / type-param / any-param 1836 TITLE-value = text 1838 Example: 1840 TITLE:Research Scientist 1842 6.6.2. ROLE 1844 Purpose: To specify the function or part played in a particular 1845 situation by the object the vCard represents. 1847 Value type: A single text value. 1849 Cardinality: * 1851 Special notes: This property is based on the X.520 Business Category 1852 explanatory attribute. This property is included as an 1853 organizational type to avoid confusion with the semantics of the 1854 TITLE property and incorrect usage of that property when the 1855 semantics of this property is intended. 1857 ABNF: 1859 ROLE-param = "VALUE=text" / language-param / pid-param / pref-param 1860 / type-param / altid-param / any-param 1861 ROLE-value = text 1863 Example: 1865 ROLE:Project Leader 1867 6.6.3. LOGO 1869 Purpose: To specify a graphic image of a logo associated with the 1870 object the vCard represents. 1872 Value type: A single URI. 1874 Cardinality: * 1876 ABNF: 1878 LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param 1879 / type-param / mediatype-param / altid-param / any-param 1880 LOGO-value = URI 1882 Examples: 1884 LOGO:http://www.example.com/pub/logos/abccorp.jpg 1886 LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc 1887 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1888 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1889 <...the remainder of base64-encoded data...> 1891 6.6.4. ORG 1893 Purpose: To specify the organizational name and units associated 1894 with the vCard. 1896 Value type: A single structured text value consisting of components 1897 separated by the SEMI-COLON character (ASCII decimal 59). 1899 Cardinality: * 1901 Special notes: The property is based on the X.520 Organization Name 1902 and Organization Unit attributes. The property value is a 1903 structured type consisting of the organization name, followed by 1904 zero or more levels of organizational unit names. 1906 The SORT-AS parameter MAY be applied to this property. 1908 ABNF: 1910 ORG-param = "VALUE=text" / sort-as-param / language-param 1911 / pid-param / pref-param / altid-param / type-param 1912 / any-param 1913 ORG-value = component *(";" component) 1915 Example: A property value consisting of an organizational name, 1916 organizational unit #1 name and organizational unit #2 name. 1918 ORG:ABC\, Inc.;North American Division;Marketing 1920 6.6.5. MEMBER 1922 Purpose: To include a member in the group this vCard represents. 1924 Value type: A single URI. It MAY refer to something other than a 1925 vCard object. For example, an e-mail distribution list could 1926 employ the "mailto" URI scheme [RFC6068] for efficiency. 1928 Cardinality: * 1930 Special notes: This property MUST NOT be present unless the value of 1931 the KIND property is "group". 1933 ABNF: 1935 MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param 1936 / mediatype-param / any-param 1937 MEMBER-value = URI 1939 Examples: 1941 BEGIN:VCARD 1942 VERSION:4.0 1943 KIND:group 1944 FN:The Doe family 1945 MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1946 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1947 END:VCARD 1948 BEGIN:VCARD 1949 VERSION:4.0 1950 FN:John Doe 1951 UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1952 END:VCARD 1953 BEGIN:VCARD 1954 VERSION:4.0 1955 FN:Jane Doe 1956 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1957 END:VCARD 1958 BEGIN:VCARD 1959 VERSION:4.0 1960 KIND:group 1961 FN:Funky distribution list 1962 MEMBER:mailto:subscriber1@example.com 1963 MEMBER:xmpp:subscriber2@example.com 1964 MEMBER:sip:subscriber3@example.com 1965 MEMBER:tel:+1-418-555-5555 1966 END:VCARD 1968 6.6.6. RELATED 1970 Purpose: To specify a relationship between another entity and the 1971 entity represented by this vCard. 1973 Value type: A single URI. It can also be reset to a single text 1974 value. The text value can be used to specify textual information. 1976 Cardinality: * 1978 Special notes: The TYPE parameter MAY be used to characterize the 1979 related entity. It contains a comma-separated list of values that 1980 are registered from IANA as described in Section 10.2. The 1981 registry is pre-populated with the values defined in [xfn]. This 1982 document also specifies two additional values: 1984 agent: an entity who may sometimes act on behalf of the entity 1985 associated with the vCard. 1987 emergency: indicates an emergency contact 1989 ABNF: 1991 RELATED-param = RELATED-param-uri / RELATED-param-text 1992 RELATED-value = URI / text 1993 ; Parameter and value MUST match. 1995 RELATED-param-uri = "VALUE=uri" / mediatype-param 1996 RELATED-param-text = "VALUE=text" / language-param 1998 RELATED-param =/ pid-param / pref-param / altid-param / type-param 1999 / any-param 2001 type-param-related = related-type-value *("," related-type-value) 2002 ; type-param-related MUST NOT be used with a property other than 2003 ; RELATED. 2005 related-type-value = "contact" / "acquaintance" / "friend" / "met" 2006 / "co-worker" / "colleague" / "co-resident" 2007 / "neighbor" / "child" / "parent" 2008 / "sibling" / "spouse" / "kin" / "muse" 2009 / "crush" / "date" / "sweetheart" / "me" 2010 / "agent" / "emergency" 2012 Examples: 2014 RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2015 RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf 2016 RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane 2017 Doe for any inquiries. 2019 6.7. Explanatory Properties 2021 These properties are concerned with additional explanations, such as 2022 that related to informational notes or revisions specific to the 2023 vCard. 2025 6.7.1. CATEGORIES 2027 Purpose: To specify application category information about the 2028 vCard. Also known as "tags". 2030 Value type: One or more text values separated by a COMMA character 2031 (ASCII decimal 44). 2033 Cardinality: * 2035 ABNF: 2037 CATEGORIES-param = "VALUE=text" / pid-param / pref-param 2038 / type-param / altid-param / any-param 2040 CATEGORIES-value = text-list 2042 Example: 2044 CATEGORIES:TRAVEL AGENT 2046 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY 2048 6.7.2. NOTE 2050 Purpose: To specify supplemental information or a comment that is 2051 associated with the vCard. 2053 Value type: A single text value. 2055 Cardinality: * 2057 Special notes: The property is based on the X.520 Description 2058 attribute. 2060 ABNF: 2062 NOTE-param = "VALUE=text" / language-param / pid-param / pref-param 2063 / type-param / altid-param / any-param 2064 NOTE-value = text 2066 Example: 2068 NOTE:This fax number is operational 0800 to 1715 2069 EST\, Mon-Fri. 2071 6.7.3. PRODID 2073 Purpose: To specify the identifier for the product that created the 2074 vCard object. 2076 Type value: A single text value. 2078 Cardinality: *1 2080 Special notes: Implementations SHOULD use a method such as that 2081 specified for Formal Public Identifiers in [ISO9070] or for 2082 Universal Resource Names in [RFC3406] to ensure that the text 2083 value is unique. 2085 ABNF: 2087 PRODID-param = "VALUE=text" / any-param 2088 PRODID-value = text 2090 Example: 2092 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN 2094 6.7.4. REV 2096 Purpose: To specify revision information about the current vCard. 2098 Value type: A single timestamp value. 2100 Cardinality: *1 2102 Special notes: The value distinguishes the current revision of the 2103 information in this vCard for other renditions of the information. 2105 ABNF: 2107 REV-param = "VALUE=timestamp" / any-param 2108 REV-value = timestamp 2110 Example: 2112 REV:19951031T222710Z 2114 6.7.5. SOUND 2116 Purpose: To specify a digital sound content information that 2117 annotates some aspect of the vCard. This property is often used 2118 to specify the proper pronunciation of the name property value of 2119 the vCard. 2121 Value type: A single URI. 2123 Cardinality: * 2125 ABNF: 2127 SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param 2128 / type-param / mediatype-param / altid-param 2129 / any-param 2130 SOUND-value = URI 2132 Example: 2134 SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com 2136 SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh 2137 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 2138 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 2139 <...the remainder of base64-encoded data...> 2141 6.7.6. UID 2143 Purpose: To specify a value that represents a globally unique 2144 identifier corresponding to the entity associated with the vCard. 2146 Value type: A single URI value. It MAY also be reset to free-form 2147 text. 2149 Cardinality: *1 2151 Special notes: This property is used to uniquely identify the object 2152 that the vCard represents. The "uuid" URN namespace defined in 2153 [RFC4122] is particularly well-suited to this task, but other URI 2154 schemes MAY be used. Free-form text MAY also be used. 2156 ABNF: 2158 UID-param = UID-uri-param / UID-text-param 2159 UID-value = UID-uri-value / UID-text-value 2160 ; Value and parameter MUST match. 2162 UID-uri-param = "VALUE=uri" 2163 UID-uri-value = URI 2165 UID-text-param = "VALUE=text" 2166 UID-text-value = text 2168 UID-param =/ any-param 2170 Example: 2172 UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2174 6.7.7. CLIENTPIDMAP 2176 Purpose: To give a global meaning to a local PID source identifier. 2178 Value type: A semicolon-separated pair of values. The first field 2179 is a small integer corresponding to the second field of a PID 2180 parameter instance. The second field is a URI. The "uuid" URN 2181 namespace defined in [RFC4122] is particularly well-suited to this 2182 task, but other URI schemes MAY be used. 2184 Cardinality: * 2186 Special notes: PID source identifiers (the source identifier is the 2187 second field in a PID parameter instance) are small integers that 2188 only have significance within the scope of a single vCard 2189 instance. Each distinct source identifier present in a vCard MUST 2190 have an associated CLIENTPIDMAP. See Section 7 for more details 2191 on the usage of CLIENTPIDMAP. 2193 PID source identifiers MUST be strictly positive. Zero is not 2194 allowed. 2196 As a special exception, the PID parameter MUST NOT be applied to 2197 this property. 2199 ABNF: 2201 CLIENTPIDMAP-param = any-param 2202 CLIENTPIDMAP-value = 1*DIGIT ";" URI 2204 Example: 2206 TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555 2207 EMAIL;PID=4.1,5.2:jdoe@example.com 2208 CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b 2209 CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5 2211 6.7.8. URL 2213 Purpose: To specify a uniform resource locator associated with the 2214 object that the vCard refers to. Examples for individuals include 2215 personal web sites, blogs, and social networking site identifiers. 2217 Cardinality: * 2219 Value type: A single uri value. 2221 ABNF: 2223 URL-param = "VALUE=uri" / pid-param / pref-param / type-param 2224 / mediatype-param / altid-param / any-param 2225 URL-value = URI 2227 Example: 2229 URL:http://example.org/restaurant.french/~chezchic.html 2231 6.7.9. VERSION 2233 Purpose: To specify the version of the vCard specification used to 2234 format this vCard. 2236 Value type: A single text value. 2238 Cardinality: 1 2240 Special notes: This property MUST be present in the vCard object, 2241 and it must appear immediately after BEGIN:VCARD. The value MUST 2242 be "4.0" if the vCard corresponds to this specification. Note 2243 that earlier versions of vCard allowed this property to be placed 2244 anywhere in the vCard object, or even to be absent. 2246 ABNF: 2248 VERSION-param = "VALUE=text" / any-param 2249 VERSION-value = "4.0" 2251 Example: 2253 VERSION:4.0 2255 6.8. Security Properties 2257 These properties are concerned with the security of communication 2258 pathways or access to the vCard. 2260 6.8.1. KEY 2262 Purpose: To specify a public key or authentication certificate 2263 associated with the object that the vCard represents. 2265 Value type: A single URI. It can also be reset to a text value. 2267 Cardinality: * 2269 ABNF: 2271 KEY-param = KEY-uri-param / KEY-text-param 2272 KEY-value = KEY-uri-value / KEY-text-value 2273 ; Value and parameter MUST match. 2275 KEY-uri-param = "VALUE=uri" / mediatype-param 2276 KEY-uri-value = URI 2278 KEY-text-param = "VALUE=text" 2279 KEY-text-value = text 2281 KEY-param =/ altid-param / pid-param / pref-param / type-param 2282 / any-param 2284 Examples: 2286 KEY:http://www.example.com/keys/jdoe 2288 KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe 2290 KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE 2291 UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l 2292 <... remainder of base64-encoded data ...> 2294 6.9. Calendar Properties 2296 These properties are further specified in [RFC2739]. 2298 6.9.1. FBURL 2300 Purpose: To specify the URI for the busy time associated with the 2301 object that the vCard represents. 2303 Value type: A single URI value. 2305 Cardinality: * 2307 Special notes: Where multiple FBURL properties are specified, the 2308 default FBURL property is indicated with the PREF parameter. The 2309 FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar 2310 [RFC5545] object associated with a snapshot of the next few weeks 2311 or months of busy time data. If the iCalendar object is 2312 represented as a file or document, its file extension should be 2313 ".ifb". 2315 ABNF: 2317 FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param 2318 / mediatype-param / altid-param / any-param 2320 FBURL-value = URI 2322 Examples: 2324 FBURL;PREF=1:http://www.example.com/busy/janedoe 2325 FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb 2327 6.9.2. CALADRURI 2329 Purpose: To specify the calendar user address [RFC5545] to which a 2330 scheduling request [RFC5546] should be sent for the object 2331 represented by the vCard. 2333 Value type: A single URI value. 2335 Cardinality: * 2337 Special notes: Where multiple CALADRURI properties are specified, 2338 the default CALADRURI property is indicated with the PREF 2339 parameter. 2341 ABNF: 2343 CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2344 / mediatype-param / altid-param / any-param 2345 CALADRURI-value = URI 2347 Example: 2349 CALADRURI;PREF=1:mailto:janedoe@example.com 2350 CALADRURI:http://example.com/calendar/jdoe 2352 6.9.3. CALURI 2354 Purpose: To specify the URI for a calendar associated with the 2355 object represented by the vCard. 2357 Value type: A single URI value. 2359 Cardinality: * 2361 Special notes: Where multiple CALURI properties are specified, the 2362 default CALURI property is indicated with the PREF parameter. The 2363 property should contain a URI pointing to an iCalendar [RFC5545] 2364 object associated with a snapshot of the user's calendar store. 2365 If the iCalendar object is represented as a file or document, its 2366 file extension should be ".ics". 2368 ABNF: 2370 CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2371 / mediatype-param / altid-param / any-param 2372 CALURI-value = URI 2374 Examples: 2376 CALURI;PREF=1:http://cal.example.com/calA 2377 CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics 2379 6.10. Extended Properties and Parameters 2381 The properties and parameters defined by this document can be 2382 extended. Non-standard, private properties and parameters with a 2383 name starting with "X-" may be defined bilaterally between two 2384 cooperating agents without outside registration or standardization. 2386 7. Synchronization 2388 vCard data often needs to be synchronized between devices. In this 2389 context, synchronization is defined as the intelligent merging of two 2390 representations of the same object. vCard 4.0 includes mechanisms to 2391 aid this process. 2393 7.1. Mechanisms 2395 Two mechanisms are available: the UID property is used to match 2396 multiple instances of the same vCard, while the PID parameter is used 2397 to match multiple instances of the same property. 2399 The term "matching" is used here to mean recognizing that two 2400 instances are in fact representations of the same object. For 2401 example, a single vCard that is shared with someone results in two 2402 vCard instances. After they have evolved separately, they still 2403 represent the same object, and therefore may be matched by a 2404 synchronization engine. 2406 7.1.1. Matching vCard Instances 2408 vCard instances for which the UID properties (Section 6.7.6) are 2409 equivalent MUST be matched. Equivalence is determined as specified 2410 in [RFC3986], Section 6. 2412 In all other cases, vCard instances MAY be matched at the discretion 2413 of the synchronization engine. 2415 7.1.2. Matching Property Instances 2417 Property instances belonging to unmatched vCards MUST NOT be matched. 2419 Property instances whose name (e.g. EMAIL, TEL, etc.) is not the 2420 same MUST NOT be matched. 2422 Property instances whose name is CLIENTPIDMAP are handled separately 2423 and MUST NOT be matched. The synchronization MUST ensure that there 2424 is consistency of CLIENTPIDMAPs among matched vCard instances. 2426 Property instances belonging to matched vCards, whose name is the 2427 same, and whose maximum cardinality is 1 MUST be matched. 2429 Property instances belonging to matched vCards, whose name is the 2430 same, and whose PID parameters match MUST be matched. See 2431 Section 7.1.3 for details on PID matching. 2433 In all other cases, property instances MAY be matched at the 2434 discretion of the synchronization engine. 2436 7.1.3. PID Matching 2438 Two PID values for which the first fields are equivalent represent 2439 the same local value. 2441 Two PID values representing the same local value and for which the 2442 second fields point to CLIENTPIDMAP properties whose second field 2443 URIs are equivalent (as specified in [RFC3986], Section 6) also 2444 represent the same global value. 2446 PID parameters for which at least one pair of their values represent 2447 the same global value MUST be matched. 2449 In all other cases, PID parameters MAY be matched at the discretion 2450 of the synchronization engine. 2452 For example, PID value "5.1", in the first vCard below, and PID value 2453 "5.2", in the second vCard below, represent the same global value. 2455 BEGIN:VCARD 2456 VERSION:4.0 2457 EMAIL;PID=4.2,5.1:jdoe@example.com 2458 CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2459 CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc 2460 END:VCARD 2462 BEGIN:VCARD 2463 VERSION:4.0 2464 EMAIL;PID=5.1,5.2:john@example.com 2465 CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d 2466 CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2467 END:VCARD 2469 7.2. Example 2471 7.2.1. Creation 2473 The following simple vCard is first created on a given device. 2475 BEGIN:VCARD 2476 VERSION:4.0 2477 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2478 FN;PID=1.1:J. Doe 2479 N:Doe;J.;;; 2480 EMAIL;PID=1.1:jdoe@example.com 2481 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2482 END:VCARD 2484 This new vCard is assigned the UID 2485 "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating 2486 device. The FN and EMAIL properties are assigned the same local 2487 value of 1, and this value is given global context by associating it 2488 with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which 2489 represents the creating device. We are at liberty to reuse the same 2490 local value since instances of different properties will never be 2491 matched. The N property has no PID because it is forbidden by its 2492 maximum cardinality of 1. 2494 7.2.2. Initial Sharing 2496 This vCard is shared with a second device. Upon inspecting the UID 2497 property, the second device understands that this is a new vCard 2498 (i.e. unmatched) and thus the synchronization results in a simple 2499 copy. 2501 7.2.3. Adding and Sharing a Property 2503 A new phone number is created on the first device, then the vCard is 2504 shared with the second device. This is what the second device 2505 receives: 2507 BEGIN:VCARD 2508 VERSION:4.0 2509 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2510 FN;PID=1.1:J. Doe 2511 N:Doe;J.;;; 2512 EMAIL;PID=1.1:jdoe@example.com 2513 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2514 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2515 END:VCARD 2517 Upon inspecting the UID property, the second device matches the vCard 2518 it received to the vCard that it already has stored. It then starts 2519 comparing the properties of the two vCards in same-named pairs. 2521 The FN properties are matched because the PID parameters have the 2522 same global value. Since the property value is the same, no update 2523 takes place. 2525 The N properties are matched automatically because their maximum 2526 cardinality is 1. Since the property value is the same, no update 2527 takes place. 2529 The EMAIL properties are matched because the PID parameters have the 2530 same global value. Since the property value is the same, no update 2531 takes place. 2533 The TEL property in the new vCard is not matched to any in the stored 2534 vCard because no property in the stored vCard has the same name. 2535 Therefore, this property is copied from the new vCard to the stored 2536 vCard. 2538 The CLIENTPIDMAP property is handled separately by the 2539 synchronization engine. It ensures that it is consistent with the 2540 stored one. If it was not, the results would be up to the 2541 synchronization engine, and thus undefined by this document. 2543 7.2.4. Simultaneous Editing 2545 A new email address and a new phone number are added to the vCard on 2546 each of the two devices, and then a new synchronization event 2547 happens. Here are the vCards that are communicated to each other: 2549 BEGIN:VCARD 2550 VERSION:4.0 2551 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2552 FN;PID=1.1:J. Doe 2553 N:Doe;J.;;; 2554 EMAIL;PID=1.1:jdoe@example.com 2555 EMAIL;PID=2.1:boss@example.com 2556 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2557 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2558 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2559 END:VCARD 2561 BEGIN:VCARD 2562 VERSION:4.0 2563 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2564 FN;PID=1.1:J. Doe 2565 N:Doe;J.;;; 2566 EMAIL;PID=1.1:jdoe@example.com 2567 EMAIL;PID=2.2:ceo@example.com 2568 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2569 TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666 2570 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2571 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2572 END:VCARD 2574 On the first device, the same PID source identifier (1) is reused for 2575 the new EMAIL and TEL properties. On the second device, a new source 2576 identifier (2) is generated, and a corresponding CLIENTPIDMAP 2577 property is created. It contains the second device's identifier, 2578 "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee". 2580 The new EMAIL properties are unmatched on both sides since the PID 2581 global value is new in both cases. The sync thus results in a copy 2582 on both sides. 2584 Although the situation appears to be the same for the TEL properties, 2585 in this case the synchronization engine is particularly smart and 2586 matches the two new TEL properties even though their PID global 2587 values are different. Note that in this case, the rules of section 2588 Section 7.1.2 state that two properties MAY be matched at the 2589 discretion of the synchronization engine. Therefore, the two 2590 properties are merged. 2592 All this results in the following vCard which is stored on both 2593 devices: 2595 BEGIN:VCARD 2596 VERSION:4.0 2597 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2598 FN:J. Doe 2599 N:Doe;J.;;; 2600 EMAIL;PID=1.1:jdoe@example.com 2601 EMAIL;PID=2.1:boss@example.com 2602 EMAIL;PID=2.2:ceo@example.com 2603 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2604 TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666 2605 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2606 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2607 END:VCARD 2609 7.2.5. Global Context Simplification 2611 The two devices finish their synchronization procedure by simplifying 2612 their global contexts. Since they haven't talked to any other 2613 device, the following vCard is for all purposes equivalent to the 2614 above. It is also shorter. 2616 BEGIN:VCARD 2617 VERSION:4.0 2618 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2619 FN:J. Doe 2620 N:Doe;J.;;; 2621 EMAIL;PID=1.1:jdoe@example.com 2622 EMAIL;PID=2.1:boss@example.com 2623 EMAIL;PID=3.1:ceo@example.com 2624 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2625 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2626 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2627 END:VCARD 2629 The details of global context simplification are unspecified by this 2630 document. They are left up to the synchronization engine. This 2631 example is merely intended to illustrate the possibility, which 2632 investigating would be, in the authors' opinion, worthwhile. 2634 8. Example: Author's vCard 2636 BEGIN:VCARD 2637 VERSION:4.0 2638 FN:Simon Perreault 2639 N:Perreault;Simon;;;ing. jr,M.Sc. 2640 BDAY:--0203 2641 ANNIVERSARY:20090808T1430-0500 2642 GENDER:M 2643 LANG;PREF=1:fr 2644 LANG;PREF=2:en 2645 ORG;TYPE=work:Viagenie 2646 ADR;TYPE=work:;Suite D2-630;2875 Laurier; 2647 Quebec;QC;G1V 2M2;Canada 2648 TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102 2649 TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501 2650 EMAIL;TYPE=work:simon.perreault@viagenie.ca 2651 GEO;TYPE=work:geo:46.772673,-71.282945 2652 KEY;TYPE=work;VALUE=uri: 2653 http://www.viagenie.ca/simon.perreault/simon.asc 2654 TZ:-0500 2655 URL;TYPE=home:http://nomis80.org 2656 END:VCARD 2658 9. Security Considerations 2660 o Internet mail is often used to transport vCards and is subject to 2661 many well known security attacks, including monitoring, replay, 2662 and forgery. Care should be taken by any directory service in 2663 allowing information to leave the scope of the service itself, 2664 where any access controls or confidentiality can no longer be 2665 guaranteed. Applications should also take care to display 2666 directory data in a "safe" environment 2668 o vCards can carry cryptographic keys or certificates, as described 2669 in Section 6.8.1. 2671 o vCards often carry information that can be sensitive (e.g. 2672 birthday, address, and phone information). Although vCards have 2673 no inherent authentication or privacy provisions, they can easily 2674 be carried by any security mechanism that transfers MIME objects 2675 to address authentication or privacy (e.g. S/MIME [RFC5751], 2676 OpenPGP [RFC4880]). In cases where the privacy or authenticity of 2677 information contained in vCard is a concern, the vCard SHOULD be 2678 transported using one of these secure mechanisms. The KEY 2679 property (Section 6.8.1) can be used to transport the public key 2680 used by these mechanisms. 2682 o The information in a vCard may become out of date. In cases where 2683 the vitality of data is important to an originator of a vCard, the 2684 SOURCE property (Section 6.1.3) SHOULD be specified. In addition, 2685 the "REV" type described in section Section 6.7.4 can be specified 2686 to indicate the last time that the vCard data was updated. 2688 10. IANA Considerations 2690 10.1. Media Type Registration 2692 IANA is asked to register the following Media Type (in 2693 ). 2695 To: ietf-types@iana.org 2697 Subject: Registration of media type text/vcard 2699 Type name: text 2701 Subtype name: vcard 2703 Required parameters: none 2705 Optional parameters: version 2707 The "version" parameter is to be interpreted identically as the 2708 VERSION vCard property. If this parameter is present, all vCards 2709 in a text/vcard body part MUST have a VERSION property with value 2710 identical to that of this MIME parameter. 2712 "charset": as defined for text/plain [RFC2046]; encodings other 2713 than UTF-8 [RFC3629] MUST NOT be used. 2715 Encoding considerations: 8bit 2717 Security considerations: See Section 9. 2719 Interoperability considerations: The text/vcard media type is 2720 intended to identify vCard data of any version. There are older 2721 specifications of vCard [RFC2426][vCard21] still in common use. 2722 While these formats are similar, they are not strictly compatible. 2723 In general, it is necessary to inspect the value of the VERSION 2724 property (see Section 6.7.9) for identifying the standard to which 2725 a given vCard object conforms. 2727 In addition, the following media types are known to have been used 2728 to refer to vCard data. They should be considered deprecated in 2729 favor of text/vcard. 2731 * text/directory 2733 * text/directory; profile=vcard 2735 * text/x-vcard 2737 Published specification: draft-ietf-vcarddav-vcardrev-20 2739 Applications that use this media type: They are numerous, diverse, 2740 and include mail user agents, instant messaging clients, address 2741 book applications, directory servers, customer relationship 2742 management software. 2744 Additional information: 2746 Magic number(s): 2748 File extension(s): .vcf .vcard 2750 Macintosh file type code(s): 2752 Person & email address to contact for further information: vCard 2753 discussion mailing list 2755 Intended usage: COMMON 2757 Restrictions on usage: none 2759 Author: Simon Perreault 2761 Change controller: IETF 2763 10.2. Registering New vCard Elements 2765 This section defines the process for registering new or modified 2766 vCard elements (i.e. properties, parameters, value data types, and 2767 values) with IANA. It does not contain any immediate IANA actions. 2769 10.2.1. Registration Procedure 2771 The IETF will create a mailing list, vcarddav@ietf.org [1], which can 2772 be used for public discussion of vCard element proposals prior to 2773 registration. Use of the mailing list is strongly encouraged. The 2774 IESG will appoint a designated expert who will monitor the 2775 vcarddav@ietf.org [1] mailing list and review registrations. 2777 Registration of new vCard elements MUST be reviewed by the designated 2778 expert and published in an RFC. A Standard Track RFC is REQUIRED for 2779 the registration of new value data types that modify existing 2780 properties. A Standard Track RFC is also REQUIRED for registration 2781 of vCard elements that modify vCard elements previously documented in 2782 a Standard Track RFC. 2784 The registration procedure begins when a completed registration 2785 template, defined in the sections below, is sent to 2786 vcarddav@ietf.org [1] and iana@iana.org [2]. The designated expert 2787 is expected to tell IANA and the submitter of the registration within 2788 two weeks whether the registration is approved, approved with minor 2789 changes, or rejected with cause. When a registration is rejected 2790 with cause, it can be re-submitted if the concerns listed in the 2791 cause are addressed. Decisions made by the designated expert can be 2792 appealed to the IESG Applications Area Director, then to the IESG. 2793 They follow the normal appeals procedure for IESG decisions. 2795 Once the registration procedure concludes successfully, IANA creates 2796 or modifies the corresponding record in the vCard registry. The 2797 completed registration template is discarded. 2799 An RFC specifying new vCard elements MUST include the completed 2800 registration templates, which MAY be expanded with additional 2801 information. These completed templates are intended to go in the 2802 body of the document, not in the IANA Considerations section. 2804 Finally, note that there is an XML representation for vCard defined 2805 in [I-D.ietf-vcarddav-vcardxml]. An XML representation SHOULD be 2806 defined for new vCard objects. 2808 10.2.2. Vendor Namespace 2810 The vendor namespace is used for vCard elements associated with 2811 commercially available products. "Vendor" or "producer" are 2812 construed as equivalent and very broadly in this context. 2814 A registration may be placed in the vendor namespace by anyone who 2815 needs to interchange files associated with the particular product. 2816 However, the registration formally belongs to the vendor or 2817 organization handling the vCard elements in the namespace being 2818 registered. Changes to the specification will be made at their 2819 request, as discussed in subsequent sections. 2821 vCard elements belonging to the vendor namespace will be 2822 distinguished by the "VND-" prefix. This is followed by an IANA- 2823 registered Private Enterprise Number (PEN), a dash, and a vCard 2824 element designation of the vendor's choosing (e.g., "VND-123456- 2825 MUDPIE"). 2827 While public exposure and review of vCard elements to be registered 2828 in the vendor namespace is not required, using the 2829 vcarddav@ietf.org [1] mailing list for review is strongly encouraged 2830 to improve the quality of those specifications. Registrations in the 2831 vendor namespace may be submitted directly to the IANA. 2833 10.2.3. Registration Template for Properties 2835 A property is defined by completing the following template. 2837 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2838 specific property (where NNNN is replaced by the vendor's PEN). 2840 Property name: The name of the property. 2842 Purpose: The purpose of the property. Give a short but clear 2843 description. 2845 Value type: Any of the valid value types for the property value 2846 needs to be specified. The default value type also needs to be 2847 specified. 2849 Cardinality: See Section 6. 2851 Property parameters: Any of the valid property parameters for the 2852 property MUST be specified. 2854 Description: Any special notes about the property, how it is to be 2855 used, etc. 2857 Format definition: The ABNF for the property definition needs to be 2858 specified. 2860 Example(s): One or more examples of instances of the property needs 2861 to be specified. 2863 10.2.4. Registration Template for Parameters 2865 A parameter is defined by completing the following template. 2867 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2868 specific property (where NNNN is replaced by the vendor's PEN). 2870 Parameter name: The name of the parameter. 2872 Purpose: The purpose of the parameter. Give a short but clear 2873 description. 2875 Description: Any special notes about the parameter, how it is to be 2876 used, etc. 2878 Format definition: The ABNF for the parameter definition needs to be 2879 specified. 2881 Example(s): One or more examples of instances of the parameter needs 2882 to be specified. 2884 10.2.5. Registration Template for Value Data Types 2886 A value data type is defined by completing the following template. 2888 Value name: The name of the value type. 2890 Purpose: The purpose of the value type. Give a short but clear 2891 description. 2893 Description: Any special notes about the value type, how it is to be 2894 used, etc. 2896 Format definition: The ABNF for the value type definition needs to 2897 be specified. 2899 Example(s): One or more examples of instances of the value type 2900 needs to be specified. 2902 10.2.6. Registration Template for Values 2904 A value is defined by completing the following template. 2906 Value: The value literal. 2908 Purpose: The purpose of the value. Give a short but clear 2909 description. 2911 Conformance: The vCard properties and/or parameters that can take 2912 this value needs to be specified. 2914 Example(s): One or more examples of instances of the value needs to 2915 be specified. 2917 The following is a fictitious example of a registration of a vCard 2918 value: 2920 Value: supervisor 2922 Purpose: It means that the related entity is the direct hierarchical 2923 superior (i.e. supervisor or manager) of the entity this vCard 2924 represents. 2926 Conformance: This value can be used with the "TYPE" parameter 2927 applied on the "RELATED" property. 2929 Example(s): 2931 RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2933 10.3. Initial vCard Elements Registries 2935 The IANA is requested to create and maintain the following registries 2936 for vCard elements with pointers to appropriate reference documents. 2937 The registries will be grouped together under the heading "vCard 2938 Elements". 2940 10.3.1. Properties Registry 2942 The following table is to be used to initialize the properties 2943 registry. 2945 +-----------+--------------+------------------------+ 2946 | Namespace | Property | Reference | 2947 +-----------+--------------+------------------------+ 2948 | | SOURCE | RFCXXXX, Section 6.1.3 | 2949 | | KIND | RFCXXXX, Section 6.1.4 | 2950 | | XML | RFCXXXX, Section 6.1.5 | 2951 | | FN | RFCXXXX, Section 6.2.1 | 2952 | | N | RFCXXXX, Section 6.2.2 | 2953 | | NICKNAME | RFCXXXX, Section 6.2.3 | 2954 | | PHOTO | RFCXXXX, Section 6.2.4 | 2955 | | BDAY | RFCXXXX, Section 6.2.5 | 2956 | | ANNIVERSARY | RFCXXXX, Section 6.2.6 | 2957 | | GENDER | RFCXXXX, Section 6.2.7 | 2958 | | ADR | RFCXXXX, Section 6.3.1 | 2959 | | TEL | RFCXXXX, Section 6.4.1 | 2960 | | EMAIL | RFCXXXX, Section 6.4.2 | 2961 | | IMPP | RFCXXXX, Section 6.4.3 | 2962 | | LANG | RFCXXXX, Section 6.4.4 | 2963 | | TZ | RFCXXXX, Section 6.5.1 | 2964 | | GEO | RFCXXXX, Section 6.5.2 | 2965 | | TITLE | RFCXXXX, Section 6.6.1 | 2966 | | ROLE | RFCXXXX, Section 6.6.2 | 2967 | | LOGO | RFCXXXX, Section 6.6.3 | 2968 | | ORG | RFCXXXX, Section 6.6.4 | 2969 | | MEMBER | RFCXXXX, Section 6.6.5 | 2970 | | RELATED | RFCXXXX, Section 6.6.6 | 2971 | | CATEGORIES | RFCXXXX, Section 6.7.1 | 2972 | | NOTE | RFCXXXX, Section 6.7.2 | 2973 | | PRODID | RFCXXXX, Section 6.7.3 | 2974 | | REV | RFCXXXX, Section 6.7.4 | 2975 | | SOUND | RFCXXXX, Section 6.7.5 | 2976 | | UID | RFCXXXX, Section 6.7.6 | 2977 | | CLIENTPIDMAP | RFCXXXX, Section 6.7.7 | 2978 | | URL | RFCXXXX, Section 6.7.8 | 2979 | | VERSION | RFCXXXX, Section 6.7.9 | 2980 | | KEY | RFCXXXX, Section 6.8.1 | 2981 | | FBURL | RFCXXXX, Section 6.9.1 | 2982 | | CALADRURI | RFCXXXX, Section 6.9.2 | 2983 | | CALURI | RFCXXXX, Section 6.9.3 | 2984 +-----------+--------------+------------------------+ 2986 10.3.2. Parameters Registry 2988 The following table is to be used to initialize the parameters 2989 registry. 2991 +-----------+-----------+-----------------------+ 2992 | Namespace | Parameter | Reference | 2993 +-----------+-----------+-----------------------+ 2994 | | LANGUAGE | RFCXXXX, Section 5.1 | 2995 | | VALUE | RFCXXXX, Section 5.2 | 2996 | | PREF | RFCXXXX, Section 5.3 | 2997 | | ALTID | RFCXXXX, Section 5.4 | 2998 | | PID | RFCXXXX, Section 5.5 | 2999 | | TYPE | RFCXXXX, Section 5.6 | 3000 | | MEDIATYPE | RFCXXXX, Section 5.7 | 3001 | | CALSCALE | RFCXXXX, Section 5.8 | 3002 | | SORT-AS | RFCXXXX, Section 5.9 | 3003 | | GEO | RFCXXXX, Section 5.10 | 3004 | | TZ | RFCXXXX, Section 5.11 | 3005 +-----------+-----------+-----------------------+ 3007 10.3.3. Value Data Types Registry 3009 The following table is to be used to initialize the parameters 3010 registry. 3012 +------------------+------------------------+ 3013 | Value Data Type | Reference | 3014 +------------------+------------------------+ 3015 | BOOLEAN | RFCXXXX, Section 4.4 | 3016 | DATE | RFCXXXX, Section 4.3.1 | 3017 | TIME | RFCXXXX, Section 4.3.2 | 3018 | DATE-TIME | RFCXXXX, Section 4.3.3 | 3019 | DATE-AND-OR-TIME | RFCXXXX, Section 4.3.4 | 3020 | TIMESTAMP | RFCXXXX, Section 4.3.5 | 3021 | FLOAT | RFCXXXX, Section 4.6 | 3022 | INTEGER | RFCXXXX, Section 4.5 | 3023 | TEXT | RFCXXXX, Section 4.1 | 3024 | URI | RFCXXXX, Section 4.2 | 3025 | UTC-OFFSET | RFCXXXX, Section 4.7 | 3026 | LANGUAGE-TAG | RFCXXXX, Section 4.8 | 3027 +------------------+------------------------+ 3029 10.3.4. Values Registries 3031 Separate tables will be used for property and parameter values. 3033 The following table is to be used to initialize the property values 3034 registry. 3036 +----------+------------+------------------------+ 3037 | Property | Value | Reference | 3038 +----------+------------+------------------------+ 3039 | BEGIN | VCARD | RFCXXXX, Section 6.1.1 | 3040 | END | VCARD | RFCXXXX, Section 6.1.2 | 3041 | KIND | individual | RFCXXXX, Section 6.1.4 | 3042 | KIND | group | RFCXXXX, Section 6.1.4 | 3043 | KIND | org | RFCXXXX, Section 6.1.4 | 3044 | KIND | location | RFCXXXX, Section 6.1.4 | 3045 +----------+------------+------------------------+ 3047 The following table is to be used to initialize the parameter values 3048 registry. 3050 +------------------------+-----------+--------------+---------------+ 3051 | Property | Parameter | Value | Reference | 3052 +------------------------+-----------+--------------+---------------+ 3053 | FN, NICKNAME, PHOTO, | TYPE | work | RFCXXXX, | 3054 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | 3055 | LANG, TZ, GEO, TITLE, | | | | 3056 | ROLE, LOGO, ORG, | | | | 3057 | RELATED, CATEGORIES, | | | | 3058 | NOTE, SOUND, URL, KEY, | | | | 3059 | FBURL, CALADRURI, and | | | | 3060 | CALURI | | | | 3061 | FN, NICKNAME, PHOTO, | TYPE | home | RFCXXXX, | 3062 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | 3063 | LANG, TZ, GEO, TITLE, | | | | 3064 | ROLE, LOGO, ORG, | | | | 3065 | RELATED, CATEGORIES, | | | | 3066 | NOTE, SOUND, URL, KEY, | | | | 3067 | FBURL, CALADRURI, and | | | | 3068 | CALURI | | | | 3069 | TEL | TYPE | text | RFCXXXX, | 3070 | | | | Section 6.4.1 | 3071 | TEL | TYPE | voice | RFCXXXX, | 3072 | | | | Section 6.4.1 | 3073 | TEL | TYPE | fax | RFCXXXX, | 3074 | | | | Section 6.4.1 | 3075 | TEL | TYPE | cell | RFCXXXX, | 3076 | | | | Section 6.4.1 | 3077 | TEL | TYPE | video | RFCXXXX, | 3078 | | | | Section 6.4.1 | 3079 | TEL | TYPE | pager | RFCXXXX, | 3080 | | | | Section 6.4.1 | 3081 | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFCXXXX, | 3082 | | | | Section 6.2.5 | 3083 | RELATED | TYPE | contact | RFCXXXX, | 3084 | | | | Section 6.6.6 | 3085 | | | | and [xfn] | 3086 | RELATED | TYPE | acquaintance | RFCXXXX, | 3087 | | | | Section 6.6.6 | 3088 | | | | and [xfn] | 3089 | RELATED | TYPE | friend | RFCXXXX, | 3090 | | | | Section 6.6.6 | 3091 | | | | and [xfn] | 3092 | RELATED | TYPE | met | RFCXXXX, | 3093 | | | | Section 6.6.6 | 3094 | | | | and [xfn] | 3095 | RELATED | TYPE | co-worker | RFCXXXX, | 3096 | | | | Section 6.6.6 | 3097 | | | | and [xfn] | 3098 | RELATED | TYPE | colleague | RFCXXXX, | 3099 | | | | Section 6.6.6 | 3100 | | | | and [xfn] | 3101 | RELATED | TYPE | co-resident | RFCXXXX, | 3102 | | | | Section 6.6.6 | 3103 | | | | and [xfn] | 3104 | RELATED | TYPE | neighbor | RFCXXXX, | 3105 | | | | Section 6.6.6 | 3106 | | | | and [xfn] | 3107 | RELATED | TYPE | child | RFCXXXX, | 3108 | | | | Section 6.6.6 | 3109 | | | | and [xfn] | 3110 | RELATED | TYPE | parent | RFCXXXX, | 3111 | | | | Section 6.6.6 | 3112 | | | | and [xfn] | 3113 | RELATED | TYPE | sibling | RFCXXXX, | 3114 | | | | Section 6.6.6 | 3115 | | | | and [xfn] | 3116 | RELATED | TYPE | spouse | RFCXXXX, | 3117 | | | | Section 6.6.6 | 3118 | | | | and [xfn] | 3119 | RELATED | TYPE | kin | RFCXXXX, | 3120 | | | | Section 6.6.6 | 3121 | | | | and [xfn] | 3122 | RELATED | TYPE | muse | RFCXXXX, | 3123 | | | | Section 6.6.6 | 3124 | | | | and [xfn] | 3125 | RELATED | TYPE | crush | RFCXXXX, | 3126 | | | | Section 6.6.6 | 3127 | | | | and [xfn] | 3128 | RELATED | TYPE | date | RFCXXXX, | 3129 | | | | Section 6.6.6 | 3130 | | | | and [xfn] | 3131 | RELATED | TYPE | sweetheart | RFCXXXX, | 3132 | | | | Section 6.6.6 | 3133 | | | | and [xfn] | 3134 | RELATED | TYPE | me | RFCXXXX, | 3135 | | | | Section 6.6.6 | 3136 | | | | and [xfn] | 3137 | RELATED | TYPE | agent | RFCXXXX, | 3138 | | | | Section 6.6.6 | 3139 | RELATED | TYPE | emergency | RFCXXXX, | 3140 | | | | Section 6.6.6 | 3141 +------------------------+-----------+--------------+---------------+ 3143 11. Acknowledgements 3145 The authors would like to thank Tim Howes, Mark Smith, and Frank 3146 Dawson, the original authors of [RFC2425] and [RFC2426], Pete 3147 Resnick, who got this effort started and provided help along the way, 3148 as well as the following individuals who have participated in the 3149 drafting, review and discussion of this memo: 3151 Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil 3152 Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie 3153 Hoeneisen, Bjoern Hoehrmann, Caleb Richarson, Chris Bryant, Chris 3154 Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale, 3155 Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian 3156 Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens, 3157 Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke, 3158 Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga. Lisa Dusseault, 3159 Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike 3160 Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter 3161 Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane 3162 Bortzmeyer, Tantek Celik, and Zoltan Ordogh. 3164 12. References 3166 12.1. Normative References 3168 [CCITT.E163.1988] International Telephone and Telegraph 3169 Consultative Committee, "Numbering Plan 3170 for the International Telephone 3171 Service", CCITT Recommendation E.163, 3172 1988. 3174 [CCITT.X121.1988] International Telephone and Telegraph 3175 Consultative Committee, "International 3176 Numbering Plan for the Public Data 3177 Networks", CCITT Recommendation X.121, 3178 1988. 3180 [CCITT.X520.1988] International International Telephone 3181 and Telegraph Consultative Committee, 3182 "Information Technology - Open Systems 3183 Interconnection - The Directory: 3184 Selected Attribute Types", 3185 CCITT Recommendation X.520, 3186 November 1988. 3188 [CCITT.X521.1988] International International Telephone 3189 and Telegraph Consultative Committee, 3190 "Information Technology - Open Systems 3191 Interconnection - The Directory: 3192 Selected Object Classes", 3193 CCITT Recommendation X.521, 3194 November 1988. 3196 [I-D.ietf-vcarddav-vcardxml] Perreault, S., "vCard XML 3197 Representation", 3198 draft-ietf-vcarddav-vcardxml-08 (work 3199 in progress), April 2011. 3201 [IEEE.754.2008] Institute of Electrical and Electronics 3202 Engineers, "IEEE Standard for Floating- 3203 Point Arithmetic", IEEE Standard 754, 3204 August 2008. 3206 [ISO.8601.2000] International Organization for 3207 Standardization, "Data elements and 3208 interchange formats - Information 3209 interchange - Representation of dates 3210 and times", ISO Standard 8601, 3211 December 2000. 3213 [ISO.8601.2004] International Organization for 3214 Standardization, "Data elements and 3215 interchange formats - Information 3216 interchange - Representation of dates 3217 and times", ISO Standard 8601, 3218 December 2004. 3220 [RFC2045] Freed, N. and N. Borenstein, 3221 "Multipurpose Internet Mail Extensions 3222 (MIME) Part One: Format of Internet 3223 Message Bodies", RFC 2045, 3224 November 1996. 3226 [RFC2046] Freed, N. and N. Borenstein, 3227 "Multipurpose Internet Mail Extensions 3228 (MIME) Part Two: Media Types", 3229 RFC 2046, November 1996. 3231 [RFC2119] Bradner, S., "Key words for use in RFCs 3232 to Indicate Requirement Levels", 3233 BCP 14, RFC 2119, March 1997. 3235 [RFC2739] Small, T., Hennessy, D., and F. Dawson, 3236 "Calendar Attributes for vCard and 3237 LDAP", RFC 2739, January 2000. 3239 [RFC3536] Hoffman, P., "Terminology Used in 3240 Internationalization in the IETF", 3241 RFC 3536, May 2003. 3243 [RFC3629] Yergeau, F., "UTF-8, a transformation 3244 format of ISO 10646", STD 63, RFC 3629, 3245 November 2003. 3247 [RFC3966] Schulzrinne, H., "The tel URI for 3248 Telephone Numbers", RFC 3966, 3249 December 2004. 3251 [RFC3986] Berners-Lee, T., Fielding, R., and L. 3252 Masinter, "Uniform Resource Identifier 3253 (URI): Generic Syntax", STD 66, 3254 RFC 3986, January 2005. 3256 [RFC4122] Leach, P., Mealling, M., and R. Salz, 3257 "A Universally Unique IDentifier (UUID) 3258 URN Namespace", RFC 4122, July 2005. 3260 [RFC4288] Freed, N. and J. Klensin, "Media Type 3261 Specifications and Registration 3262 Procedures", BCP 13, RFC 4288, 3263 December 2005. 3265 [RFC5234] Crocker, D. and P. Overell, "Augmented 3266 BNF for Syntax Specifications: ABNF", 3267 STD 68, RFC 5234, January 2008. 3269 [RFC5322] Resnick, P., Ed., "Internet Message 3270 Format", RFC 5322, October 2008. 3272 [RFC5545] Desruisseaux, B., "Internet Calendaring 3273 and Scheduling Core Object 3274 Specification (iCalendar)", RFC 5545, 3275 September 2009. 3277 [RFC5546] Daboo, C., "iCalendar Transport- 3278 Independent Interoperability Protocol 3279 (iTIP)", RFC 5546, December 2009. 3281 [RFC5646] Phillips, A. and M. Davis, "Tags for 3282 Identifying Languages", BCP 47, 3283 RFC 5646, September 2009. 3285 [RFC5870] Mayrhofer, A. and C. Spanring, "A 3286 Uniform Resource Identifier for 3287 Geographic Locations ('geo' URI)", 3288 RFC 5870, June 2010. 3290 [W3C.REC-xml-20081126] Sperberg-McQueen, C., Yergeau, F., 3291 Bray, T., Paoli, J., and E. Maler, 3292 "Extensible Markup Language (XML) 1.0 3293 (Fifth Edition)", World Wide Web 3294 Consortium Recommendation REC-xml- 3295 20081126, November 2008, . 3298 [xfn] Celik, T., Mullenweg, M., and E. Meyer, 3299 "XHTML Friends Network 1.1", 3300 . 3302 12.2. Informative References 3304 [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, 3305 "Internationalized Email Headers", 3306 draft-ietf-eai-rfc5335bis-10 (work in 3307 progress), March 2011. 3309 [ISO9070] The International Organization for 3310 Standardization, "ISO 9070, Information 3311 Processing - SGML support facilities - 3312 Registration Procedures for Public Text 3313 Owner Identifiers", April 1991. 3315 [RFC1738] Berners-Lee, T., Masinter, L., and M. 3316 McCahill, "Uniform Resource Locators 3317 (URL)", RFC 1738, December 1994. 3319 [RFC2397] Masinter, L., "The "data" URL scheme", 3320 RFC 2397, August 1998. 3322 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A 3323 MIME Content-Type for Directory 3324 Information", RFC 2425, September 1998. 3326 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 3327 Directory Profile", RFC 2426, 3328 September 1998. 3330 [RFC2616] Fielding, R., Gettys, J., Mogul, J., 3331 Frystyk, H., Masinter, L., Leach, P., 3332 and T. Berners-Lee, "Hypertext Transfer 3333 Protocol -- HTTP/1.1", RFC 2616, 3334 June 1999. 3336 [RFC3282] Alvestrand, H., "Content Language 3337 Headers", RFC 3282, May 2002. 3339 [RFC3406] Daigle, L., van Gulik, D., Iannella, 3340 R., and P. Faltstrom, "Uniform Resource 3341 Names (URN) Namespace Definition 3342 Mechanisms", BCP 66, RFC 3406, 3343 October 2002. 3345 [RFC4770] Jennings, C. and J. Reschke, Ed., 3346 "vCard Extensions for Instant Messaging 3347 (IM)", RFC 4770, January 2007. 3349 [RFC4880] Callas, J., Donnerhacke, L., Finney, 3350 H., Shaw, D., and R. Thayer, "OpenPGP 3351 Message Format", RFC 4880, 3352 November 2007. 3354 [RFC5751] Ramsdell, B. and S. Turner, "Secure/ 3355 Multipurpose Internet Mail Extensions 3356 (S/MIME) Version 3.2 Message 3357 Specification", RFC 5751, January 2010. 3359 [RFC6068] Duerst, M., Masinter, L., and J. 3360 Zawinski, "The 'mailto' URI Scheme", 3361 RFC 6068, October 2010. 3363 [TZ-DB] Olson, A., "Time zone code and data", 3364 . 3366 [vCard21] Internet Mail Consortium, "vCard - The 3367 Electronic Business Card Version 2.1", 3368 September September. 3370 URIs 3372 [1] 3374 [2] 3376 Appendix A. Differences from RFCs 2425 and 2426 3378 This appendix contains a list of changes that have been made in the 3379 vCard specification from RFCs 2425 and 2426. 3381 A.1. New Structure 3383 o [RFC2425] and [RFC2426] have been merged. 3385 o vCard is now not only a MIME type but a stand-alone format. 3387 o A proper MIME type registration form has been included. 3389 o UTF-8 is now the default character set. 3391 o New vCard elements can be registered from IANA. 3393 o Expanded text on character set. 3395 A.2. Removed Features 3397 o The CONTEXT and CHARSET parameters are no more. 3399 o The NAME, MAILER, LABEL, and CLASS properties are no more. 3401 o The "intl", "dom", "postal", and "parcel" TYPE parameter values 3402 for the ADR property have been removed. 3404 o Inline vCards (such as the value of the AGENT property) are no 3405 longer supported. 3407 o In the N property, each component may now contain multiple comma- 3408 separated values. 3410 A.3. New Properties and Parameters 3412 o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP 3413 properties have been added. 3415 o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI 3416 properties, has been merged in. 3418 o [RFC4770], which defines the IMPP property, has been merged in. 3420 o The "work", "home", and "uri" TYPE parameter values for the EMAIL 3421 property have been added. 3423 o The "pref" value of the TYPE parameter is now a parameter of its 3424 own, with a positive integer value indicating the level of 3425 preference. 3427 o The ALTID and PID parameters have been added. 3429 o The MEDIATYPE parameter has been added and replaces the TYPE 3430 parameter when it was used for indicating the media type of the 3431 property's content. 3433 A.4. Other Changes 3435 o Synchronization is addressed in Section 7. 3437 o The N property is no longer mandatory. 3439 o The value of TEL is now a URI. 3441 o The AGENT property was replaced with a type of RELATED. 3443 o Date and time values now only support the basic format. 3444 Truncation is now supported. 3446 Appendix B. Change Log (to be removed by RFC Editor prior to 3447 publication) 3449 B.1. Changes in -20 3451 o Reworded security considerations. 3453 o Specified range of integer and float value types. 3455 o Adjusted IANA considerations wording. 3457 o Added missing date-and-or-type to the VALUE ABNF. 3459 o s/vcard@ietf.org/vcarddav@ietf.org/ 3461 o More precise wording: charset instead of character set 3463 o Make parameter values case-insensitive by default. 3465 o Escaping newlines can be done with \n or \N. 3467 o Make SORT-AS value case-sensitive. 3469 o Better formatting for ADR special notes. 3471 o Removed Pete Resnick's example vCard. 3473 o vcarddav@ietf.org is the contact person for the media type. 3475 o Add missing pref-param, pid-param, and any-param to the PHOTO 3476 property. 3478 o Re-added missing section on UTC-OFFSET value type. 3480 B.2. Changes in -19 3482 o Fixed nits. 3484 o Fixed MEDIATYPE ABNF. 3486 B.3. Changes in -18 3488 o Fix missing text in KIND section. 3490 B.4. Changes in -17 3492 o s/individual/entity/ 3494 o Moved section 3.4 for better flow. 3496 o Removed text overriding general MIME and HTTP rules. 3498 o Fixed redundant ABNF. 3500 o Fixed parameter value quoting in examples. 3502 o Added informative reference for Content-Language header. 3504 o Moved cardinality table earlier for better flow. 3506 o Added normative reference for XML 1.0. 3508 o Added informative reference for mailto: scheme. 3510 o Clarified where the VERSION property must go. 3512 o Created the MEDIATYPE parameter. 3514 o Fixed text/vcard encoding considerations. 3516 o Added .vcard file extension. 3518 o Removed need for extension documents to contain tables in their 3519 IANA Considerations section. 3521 o Removed underspecified "Status" column in IANA registry. 3523 o Moved obsoleted references to Informative section. 3525 o Moved iCalendar references to Normative section. 3527 o Expanded specification of KIND values. 3529 o Recommend defining an XML representation for new vCard objects. 3531 B.5. Changes in -16 3533 o RELATED: Added XFN values into IANA registry. 3535 o RELATED: Added values "agent" and "emergency". 3537 o EMAIL is now free-form text, with informative reference to EAI. 3539 o GENDER now has two components: one for biological sex, the other 3540 for gender identity. 3542 o Bugfixes to the core ABNF. 3544 o Clarified IANA considerations. 3546 o UID may be reset to free-form text. 3548 B.6. Changes in -15 3550 o Reverted N to the 5-component format of vCard 3. 3552 o Removed DDAY, BIRTH, and DEATH. 3554 o First two components in ADR SHOULD be empty. 3556 o Removed the LABEL property. 3558 o Removed the binary value type and the ENCODING and FMTTYPE 3559 parameters. 3561 o Renamed SEX to GENDER. Set predefined values to "male" and 3562 "female". 3564 o Reverted TEL to take a text value by default, but SHOULD be reset 3565 to a URI. 3567 o Refer to iCalendar for CALSCALE. 3569 o Removed the "thing" value for KIND. 3571 o RELATED now uses XFN 1.1 for its value. 3573 o Dropped the VERSION parameter. XML MUST be version 1.0. 3575 o Dropped the CLASS property. 3577 o Property and parameter names SHOULD be upper-case. 3579 o Use ABNF for cardinality notation. 3581 B.7. Changes in -14 3583 o DQUOTE is US-ASCII decimal 34, not 22. 3585 o Removed unused reference to RFC 2046. 3587 o Updated reference to draft-ietf-vcarddav-vcardxml. 3589 o Small fixes to the IANA registration text. 3591 o Added notes on the usage of TEL and IMPP properties. 3593 o Clarified "country name" component of ADR property. 3595 o Removed usage of undefined type value "msg" in TEL example. 3597 o Fixed parameter value quoting rules and ABNF. 3599 o Added example to LANGUAGE property. 3601 o Fixed synchronization example regarding the cardinality of FN. 3603 o Added implementation note for float value type. 3605 o Removed advice for always including VALUE parameter. 3607 o FMTTYPE MUST include the full MIME type. 3609 o Made ADR's ABNF more verbose. 3611 o Organized TEL TYPE values in a table. 3613 o Replaced TOP-SECRET example with NOINDEX. 3615 B.8. Changes in -13 3617 o Changed global ABNF to make explicit that VERSION comes first. 3619 o Reworked example for LANGUAGE property. 3621 o s/TYPE/FMTTYPE/ in two examples. 3623 o Allow LANGUAGE parameter for text-valued BDAY, DDAY, and RELATED. 3625 o Tightened language on LANGUAGE parameter regarding cardinality. 3627 o Removed the NAME property. 3629 o Adjusted semi-colon escaping rules. 3631 o Added the ALTID parameter. 3633 B.9. Changes in -12 3635 o Fixed example of LANGUAGE cardinality. 3637 o Added note about YYYY-MM date format. 3639 o Fixed appendix A. 3641 o VERSION property must come first. 3643 o Fixed mistake in PID example. 3645 o Removed two changes from Appendix A which were probably intended 3646 to go into this change log section. 3648 o Explicitly state that the value for the BEGIN and END properties 3649 is case-insensitive. 3651 o Removed the SORT-STRING property. Created the SORT-AS parameter. 3653 o "T" and "Z" in dates and times are now mandatory uppercase. 3655 o Added the "version" MIME parameter. 3657 o More consistent capitalization. 3659 o Added missing "ANNIVERSARY" in name production rule. 3661 o Added missing calscale-param in param production rule. 3663 o Moved definition of GEO and TZ parameters to section 5. 3665 o Simplified discussion of encoding. 3667 o Removed restriction for "work" and "home" values of TYPE parameter 3668 w.r.t. the KIND property. 3670 o XML value may now be binary. 3672 o Created VERSION parameter for XML. 3674 o BIRTH and DEATH can now have URI values. 3676 o Created the FMTTYPE parameter. 3678 o KEY can now take a text value. 3680 o Added references to RFC 5545 (iCalendar). 3682 o Added namespace column in parameters registry. 3684 B.10. Changes in -11 3686 o Change "XML chunk" to "XML fragment". 3688 o Cite W3C document containing definition of "fragment". 3690 o Added "XML" to property name ABNF. 3692 o Clarified newline escaping rule. 3694 o Replaced one remaining "type" with "property". 3696 o Removed case insensitivity of parameter values. 3698 o XML property can now only contain one element that is not in the 3699 vCard 4 namespace. 3701 o Clarified interrelationship between LANGUAGE, cardinality, and 3702 PID. 3704 o Added "textphone" TEL type. 3706 o Fixed quoting of comma in ORG examples. 3708 B.11. Changes in -10 3710 o Added component in SORT-STRING for sorting by given name. Fixed 3711 and expanded the examples. 3713 o Fixed KIND-value ABNF. 3715 o Fixed deprecated media type. 3717 o Created the CALSCALE parameter. 3719 o Strenghtened the stance on character set. 3721 o Defined the Language-Tag ABNF. 3723 o Made explicit the fact that IANA does not register templates. 3725 o Created the XML property. 3727 o Added social networking examples to URL property. 3729 B.12. Changes in -09 3731 o Removed special meaning for groups. Removed the "work" and "home" 3732 groups. Removed the group registry. Re-introduced the "work" and 3733 "home" TYPE parameter values. Applied the TYPE parameter to 3734 properties which supported the "work" and "home" groups. 3736 o Vendor namespace now uses private enterprise number in prefix. 3738 o Added "thing" value for KIND property. 3740 B.13. Changes in -08 3742 o Allow 1985 (year only) in date ABNF. 3744 o Fixed missing country in ADR example. 3746 o Added the DATE-AND-OR-TIME value. 3748 o Made BDAY and DDAY use DATE-AND-OR-TIME. 3750 o Prefixed "param" and "value" production rules specific to 3751 properties with the property name. 3753 o Replaced the GENDER property with the SEX property. 3755 o Added the ANNIVERSARY property. 3757 o Added the "friend" and "spouse" types of RELATED. 3759 o TZ property now has text / uri value. 3761 o Refined the definitions of TITLE and ROLE. 3763 B.14. Changes in -07 3765 o PREF is now bounded. 100 is the maximum value. 3767 o Added the "emergency" RELATED type. 3769 o Made GEO a URI. 3771 o Added GEO and TZ parameters to ADR. 3773 o Changed wording of "default" use of SOUND property. 3775 o Completely reworked the date, time, and date-time grammars. 3777 o Added the timestamp value type. 3779 o REV now has the timestamp value type. 3781 o Rewrote ABNF. 3783 o ORG can now have a single level. 3785 B.15. Changes in -06 3787 o Corrected omission of resetability to text value for RELATED. 3789 o Let KEY value type be reset to a URI value. 3791 o ABNF fixes. 3793 o Made gender values extensible. 3795 o Gave the PREF parameter a positive integer value. 3797 o Removed usage of the undefined "word" ABNF production rule. 3799 o Defined property cardinalities. 3801 o Defined properties allowable in WORK and HOME groups. 3803 o Simplified the LANG property to use the vCard preference 3804 mechanism. 3806 o Created the "language-tag" value type. 3808 o Added PID to ABNF of SOURCE allowed parameters. 3810 o Clarified escaping rules. 3812 o Changed ABNF definition of non-standard X- properties. 3814 o Removed TYPE parameter from EMAIL properties in examples. 3816 o Created the CLIENTPIDMAP property. 3818 o Changed PID value to a pair of small integers. 3820 o Completely reworked synchronization mechanisms. 3822 o Created brand new synchronization example. 3824 B.16. Changes in -05 3826 o Added multi PID value proposal. 3828 B.17. Changes in -04 3830 o Added "location" value for KIND property. 3832 o Some fixes to ABNF. 3834 o Moved "pref" from being a TYPE value to a parameter in its own 3835 right. 3837 o Removed the "work" and "home" TYPE values. 3839 o Reintroduced the group construct. 3841 o Assigned meaning to WORK and HOME groups. 3843 o Restricted the TEL TYPE parameter value set. 3845 o In N property, removed additional names, and replaced with 3846 multiple given names. 3848 o Removed TYPE parameter from EMAIL and IMPP properties. 3850 o Replaced AGENT with a type of RELATED. 3852 o Use example.org domain in URL example. 3854 o Created initial IANA table of values. 3856 o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL. 3858 B.18. Changes in -03 3860 o Various changes to the synchronization mechanisms. 3862 o Allowed truncated format for dated. See issue #236. 3864 B.19. Changes in -02 3866 o Removed useless text in IMPP description. 3868 o Added CalDAV-SCHED example to CALADRURI. 3870 o Removed CAPURI property. 3872 o Dashes in dates and colons in times are now mandatory. 3874 o Allow for dates such as 2008 and 2008-05 and times such as 07 and 3875 07:54. 3877 o Removed inline vCard value. 3879 o Made AGENT only accept URI references instead of inline vCards. 3881 o Added the MEMBER property. 3883 o Renamed the UID parameter to PID. 3885 o Changed the value type of the PID parameter to "a small integer." 3887 o Changed the presence of UID and PID when synchronization is to be 3888 used from MUST to SHOULD. 3890 o Added the RELATED (Section 6.6.6) property. 3892 o Fixed many ABNF typos (issue #252). 3894 o Changed formatting of ABNF comments to make them easier to read 3895 (issue #226). 3897 B.20. Changes in -01 3899 o Merged [RFC2739] in. 3901 o Converted all foobar.com, abc.com, etc. to example.com. 3903 o Fixed bugs in ABNF. 3905 o Made explicit that coordinates in the GEO property are expressed 3906 in the WGS 84 reference system. 3908 o Clarified folding issues with multi-byte characters. 3910 o Made the value of TEL a URI. 3912 o Added the UID parameter. 3914 o Made the UID property's value type a URI. 3916 o Added Section 7. 3918 o Created IANA process for registering new parameters, value types, 3919 and properties. 3921 o Created the initial IANA registries. 3923 o Created vendor namespace based on text from RFC 4288. 3925 B.21. Changes in -00 3927 o Name change because draft has been accepted as WG item. 3928 Otherwise, same as draft-resnick-vcarddav-vcardrev-01. 3930 o Removed reference to RFC 2234. 3932 o Fixed errata from 3933 http://www.rfc-editor.org/errata_search.php?rfc=2426. 3935 o Removed passage referring to RFC 2425 profiles. 3937 o Renamed Section 6.4 from "Telecommunications Adressing Properties" 3938 to "Communications Properties. 3940 o Added Appendix A and Appendix B. 3942 o Added reference to [RFC4770]. 3944 o Removed the group construct. 3946 o Made the N property no longer mandatory. 3948 o Added the KIND property. 3950 o Clarified meaning of TYPE parameter value for PHOTO, LOGO, KEY, 3951 and SOUND. 3953 o Removed the CONTEXT parameter. 3955 o Removed the MAILER property. 3957 o Made reference to [ISO9070] informative. 3959 o Removed "intl", "dom", "postal", and "parcel" TYPE parameter 3960 values for the ADR and LABEL properties. 3962 o Clarified meaning of "extended address" ADR field. 3964 o Mentioned [RFC3406] as another method of generating PRODID values. 3966 o Updated obsolete references. 3968 o Allowed BDAY and DDAY value types to be text values for fuzzy 3969 dates. 3971 o Removed the CHARSET property. Now the encoding is always UTF-8, 3972 except when overridden by the Content-Type (which is considered a 3973 compatibility feature). 3975 Author's Address 3977 Simon Perreault 3978 Viagenie 3979 2875 Laurier, suite D2-630 3980 Quebec, QC G1V 2M2 3981 Canada 3983 Phone: +1 418 656 9254 3984 EMail: simon.perreault@viagenie.ca 3985 URI: http://www.viagenie.ca