idnits 2.17.1 draft-ietf-vcarddav-vcardrev-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2425, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2426, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4770, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2739, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 470 has weird spacing: '... [month day]...' == Line 474 has weird spacing: '... month day...' == Line 475 has weird spacing: '... month day...' == Line 477 has weird spacing: '... month day...' == Line 483 has weird spacing: '... = hour minut...' == (1 more instance...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2739, updated by this document, for RFC5378 checks: 1998-08-14) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2011) is 4796 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-06 ** Obsolete normative reference: RFC 2425 (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 4770 (Obsoleted by RFC 6350) == Outdated reference: A later version (-13) exists of draft-ietf-eai-rfc5335bis-09 -- 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) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 8 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 March 10, 2011 5 (if approved) 6 Updates: 2739 (if approved) 7 Intended status: Standards Track 8 Expires: September 11, 2011 10 vCard Format Specification 11 draft-ietf-vcarddav-vcardrev-16 13 Abstract 15 This document defines the vCard data format for representing and 16 exchanging a variety of information about individuals and other 17 entities (e.g., formatted and structured name and delivery addresses, 18 email address, multiple telephone numbers, photograph, logo, audio 19 clips, etc.). 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 11, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 6 76 3.1. Line Delimiting and Folding . . . . . . . . . . . . . . . 6 77 3.2. ABNF Format Definition . . . . . . . . . . . . . . . . . . 7 78 3.3. Property Value Escaping . . . . . . . . . . . . . . . . . 9 79 3.4. Character Set . . . . . . . . . . . . . . . . . . . . . . 10 80 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 10 81 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 13 84 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 14 87 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14 88 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 15 89 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 4.7. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16 93 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16 94 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 5.7. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 5.8. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 5.9. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 5.10. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23 105 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23 106 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23 107 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 24 108 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24 109 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25 110 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 6.2. Identification Properties . . . . . . . . . . . . . . . . 27 112 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 27 113 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 27 114 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 28 115 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 29 116 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 29 117 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 30 118 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 30 119 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 31 120 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 31 121 6.4. Communications Properties . . . . . . . . . . . . . . . . 33 122 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 33 123 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 35 124 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 35 125 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 36 126 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 36 127 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 37 128 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 37 129 6.6. Organizational Properties . . . . . . . . . . . . . . . . 38 130 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 38 131 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 39 132 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 39 133 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40 134 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 40 135 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 41 136 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 42 137 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 42 138 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 43 139 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 43 140 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 44 141 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 44 142 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 45 143 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 46 144 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 46 145 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 47 146 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 47 147 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 47 148 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 48 149 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 48 150 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 49 151 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 49 152 6.10. Extended Properties and Parameters . . . . . . . . . . . . 50 153 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 50 154 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 50 155 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 51 156 7.1.2. Matching Property Instances . . . . . . . . . . . . . 51 157 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 51 158 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 52 159 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 52 160 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 52 161 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 53 162 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 53 163 7.2.5. Global Context Simplification . . . . . . . . . . . . 55 164 8. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 56 165 9. Security Considerations . . . . . . . . . . . . . . . . . . . 56 166 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 167 10.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 57 168 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 58 169 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 59 170 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 59 171 10.2.3. Registration Template for Properties . . . . . . . . . 60 172 10.2.4. Registration Template for Parameters . . . . . . . . . 61 173 10.2.5. Registration Template for Value Data Types . . . . . . 61 174 10.2.6. Registration Template for Values . . . . . . . . . . . 61 175 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 62 176 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 62 177 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 63 178 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 64 179 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 64 180 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 181 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 182 12.1. Normative References . . . . . . . . . . . . . . . . . . . 68 183 12.2. Informative References . . . . . . . . . . . . . . . . . . 70 184 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 71 185 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 71 186 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 71 187 A.3. New Properties and Parameters . . . . . . . . . . . . . . 72 188 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 72 189 Appendix B. Change Log (to be removed by RFC Editor prior to 190 publication) . . . . . . . . . . . . . . . . . . . . 72 191 B.1. Changes in -16 . . . . . . . . . . . . . . . . . . . . . . 72 192 B.2. Changes in -15 . . . . . . . . . . . . . . . . . . . . . . 73 193 B.3. Changes in -14 . . . . . . . . . . . . . . . . . . . . . . 73 194 B.4. Changes in -13 . . . . . . . . . . . . . . . . . . . . . . 74 195 B.5. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 74 196 B.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 76 197 B.7. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 76 198 B.8. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 77 199 B.9. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 77 200 B.10. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 77 201 B.11. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 78 202 B.12. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 79 203 B.13. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 79 204 B.14. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 79 205 B.15. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 79 206 B.16. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 80 207 B.17. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 81 209 1. Introduction 211 Electronic address books have become ubiquitous. Their increased 212 presence on portable, connected devices as well as the diversity of 213 platforms exchanging contact data call for a standard. This memo 214 defines the vCard format, which allows the capture and exchange of 215 information normally stored within an address book or directory 216 application. 218 2. Conventions 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in [RFC2119]. 224 3. vCard Format Specification 226 The text/vcard MIME content type (hereafter known as "vCard", see 227 Section 10.1) contains contact information, typically pertaining to a 228 single contact or group of contacts. The content consists of one or 229 more lines in the format given below. 231 3.1. Line Delimiting and Folding 233 Individual lines within vCard are delimited by the [RFC5322] line 234 break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII 235 decimal 10). Long logical lines of text can be split into a 236 multiple-physical-line representation using the following folding 237 technique. Content lines SHOULD be folded to a maximum width of 75 238 octets, excluding the line break. Multi-octet characters MUST remain 239 contiguous. The rationale for this folding process can be found in 240 [RFC5322], Section 2.1.1. 242 A logical line MAY be continued on the next physical line anywhere 243 between two characters by inserting a CRLF immediately followed by a 244 single white space character (space, ASCII decimal 32, or horizontal 245 tab, ASCII decimal 9). The folded line MUST contain at least one 246 character. Any sequence of CRLF followed immediately by a single 247 white space character is ignored (removed) when processing the 248 content type. For example the line: 250 NOTE:This is a long description that exists on a long line. 252 can be represented as: 254 NOTE:This is a long description 255 that exists on a long line. 257 It could also be represented as: 259 NOTE:This is a long descrip 260 tion that exists o 261 n a long line. 263 The process of moving from this folded multiple-line representation 264 of a property definition to its single line representation is called 265 unfolding. Unfolding is accomplished by regarding CRLF immediately 266 followed by a white space character (namely HTAB ASCII decimal 9 or 267 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., 268 the CRLF and single white space character are removed). 270 Note: It is possible for very simple implementations to generate 271 improperly folded lines in the middle of a UTF-8 multi-octet 272 sequence. For this reason, implementations SHOULD unfold lines in 273 such a way as to properly restore the original sequence. 275 Note: Unfolding is done differently than in [RFC5322]. Unfolding 276 in [RFC5322] only removes the CRLF, not the space following it. 278 Folding is done after any content encoding of a type value. 279 Unfolding is done before any decoding of a type value in a content 280 line. 282 3.2. ABNF Format Definition 284 The following ABNF uses the notation of [RFC5234], which also defines 285 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. 287 vcard-entity = 1*(vcard) 289 vcard = "BEGIN" ":" "VCARD" CRLF 290 "VERSION" ":" "4.0" CRLF 291 1*contentline 292 "END" ":" "VCARD" CRLF 293 ; A vCard object MUST include the VERSION and FN properties. 294 ; VERSION MUST come first. 296 contentline = [group "."] name *(";" param) ":" value CRLF 297 ; When parsing a content line, folded lines must first 298 ; be unfolded according to the unfolding procedure 299 ; described above. 300 ; When generating a content line, lines longer than 75 301 ; characters SHOULD be folded according to the folding 302 ; procedure described above. 304 group = 1*(ALPHA / DIGIT / "-") 305 name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME" 306 / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / / "TEL" 307 / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE" 308 / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES" 309 / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP" 310 / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML" 311 / iana-token / x-name 312 ; Parsing of the param and value is based on the "name" as 313 ; defined in ABNF sections below. 314 ; Group and name are case-insensitive. 316 iana-token = 1*(ALPHA / DIGIT / "-") 317 ; identifier registered with IANA 319 x-name = "x-" 1*(ALPHA / DIGIT / "-") 320 ; Names that begin with "x-" or "X-" are 321 ; reserved for experimental use, not intended for released 322 ; products, or for use in bilateral agreements. 324 param = language-param / value-param / pref-param / pid-param 325 / type-param / geo-param / tz-param / sort-as-param 326 / calscale-param / version-param / any-param 327 ; Allowed parameters depend on property name. 329 param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE 331 any-param = (iana-token / x-name) "=" param-value *("," param-value) 333 NON-ASCII = %x80-FF 334 ; Use is restricted by UTF-8 336 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII 337 ; Any character except CTLs, DQUOTE 339 SAFE-CHAR = WSP / %x21 / %x23-39 / %x3C-7E / NON-ASCII 340 ; Any character except CTLs, DQUOTE, ";", ":" 342 VALUE-CHAR = WSP / VCHAR / NON-ASCII 343 ; Any textual character 345 A line that begins with a white space character is a continuation of 346 the previous line, as described above. The white space character and 347 immediately preceeding CRLF should be discarded when reconstructing 348 the original line. Note that this line-folding convention differs 349 from that found in [RFC5322], in that the sequence found 350 anywhere in the content indicates a continued line and should be 351 removed. 353 Property names and parameter names are case insensitive (e.g., the 354 property name "fn" is the same as "FN" and "Fn"). Parameter values 355 MAY be case sensitive or case insensitive, depending on their 356 definition. Based on experience with vCard 3 interoperability, it is 357 RECOMMENDED that property and parameter names be upper-case on 358 output. 360 The group construct is used to group related properties together. 361 The group name is a syntactic convention used to indicate that all 362 property names prefaced with the same group name SHOULD be grouped 363 together when displayed by an application. It has no other 364 significance. Implementations that do not understand or support 365 grouping MAY simply strip off any text before a "." to the left of 366 the type name and present the types and values as normal. 368 Properties defined in a vCard instance may have multiple values 369 depending on the property cardinality. The general rule for encoding 370 multi-valued properties is to simply create a new content line for 371 each value (including the property name). However, it should be 372 noted that some value types support encoding multiple values in a 373 single content line by separating the values with a comma ",". This 374 approach has been taken for several of the content types defined 375 below (date, time, integer, float). 377 3.3. Property Value Escaping 379 Some properties may contain one or more values delimited by a COMMA 380 character (ASCII decimal 44). Therefore, a COMMA character in a 381 value MUST be escaped with a BACKSLASH character (ASCII decimal 92), 382 even for properties that don't allow multiple instances (for 383 consistency). 385 Some properties (e.g. N and ADR) comprise multiple fields delimited 386 by a SEMI-COLON character (ASCII decimal 59). Therefore, a SEMI- 387 COLON in a field of such a "compound" property MUST be escaped with a 388 BACKSLASH character. SEMI-COLON characters in non-compound 389 properties MAY be escaped. On input, an escaped SEMI-COLON character 390 is never a field separator. An unescaped SEMI-COLON character may be 391 a field separator, depending on the property in which it appears. 393 Furthermore, some fields of compound properties may contain a list of 394 values delimited by a COMMA character. Therefore, a COMMA character 395 in one of a field's values MUST be escaped with a BACKSLASH 396 character, even for fields that don't allow multiple values (for 397 consistency). Compound properties allowing multiple instances MUST 398 NOT be encoded in a single content line. 400 Finally, BACKSLASH characters in values MUST be escaped with a 401 BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values 402 MUST be encoded by two characters: a BACKSLASH followed by an 'n' 403 (ASCII decimal 110). 405 In all other cases, escaping MUST NOT be used. 407 3.4. Character Set 409 The character set for vCard is UTF-8 as defined in [RFC3629]. There 410 is no way to override this. It is invalid to specify a different 411 character set in the "charset" MIME parameter (see Section 10.1). 412 This overrides both [RFC2046] section 4.1.2 and [RFC2616] section 413 3.7.1. 415 4. Property Value Data Types 417 Standard value types are defined below. 419 value = text 420 / text-list 421 / date-list 422 / time-list 423 / date-time-list 424 / date-and-or-time-list 425 / timestamp-list 426 / boolean 427 / integer-list 428 / float-list 429 / URI ; from Section 3 of [RFC3986] 430 / iana-valuespec 431 ; Actual value type depends on property name and VALUE parameter. 433 text = *TEXT-CHAR 435 TEXT-CHAR = "\\" / "\," / "\n" 436 / 437 ; Backslashes, commas, and newlines must be encoded. 439 component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII 440 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E 442 list-component = list-component-value *("," list-component-value) 443 list-component-value = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII 444 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E 446 text-list = text *("," text) 447 date-list = date *("," date) 448 time-list = time *("," time) 449 date-time-list = date-time *("," date-time) 450 date-and-or-time-list = date-and-or-time *("," date-and-or-time) 451 timestamp-list = timestamp *("," timestamp) 452 integer-list = integer *("," integer) 453 float-list = float *("," float) 455 boolean = "TRUE" / "FALSE" 456 integer = [sign] 1*DIGIT 457 float = [sign] 1*DIGIT ["." 1*DIGIT] 459 sign = "+" / "-" 461 year = 4DIGIT ; 0000-9999 462 month = 2DIGIT ; 01-12 463 day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year 464 hour = 2DIGIT ; 00-23 465 minute = 2DIGIT ; 00-59 466 second = 2DIGIT ; 00-58/59/60 depending on leap second 467 zone = utc-designator / utc-offset 468 utc-designator = %d90 ; uppercase "Z" 470 date = year [month day] 471 / year "-" month 472 / "--" month [day] 473 / "--" "-" day 474 date-noreduc = year month day 475 / "--" month day 476 / "--" "-" day 477 date-complete = year month day 479 time = hour [minute [second]] [zone] 480 / "-" minute [second] [zone] 481 / "-" "-" second [zone] 482 time-notrunc = hour [minute [second]] [zone] 483 time-complete = hour minute second [zone] 485 time-designator = %d84 ; uppercase "T" 486 date-time = date-noreduc time-designator time-notrunc 487 timestamp = date-complete time-designator time-complete 489 date-and-or-time = date-time / date / time-designator time 491 utc-offset = sign hour [minute] 493 Language-Tag = 495 iana-valuespec = 496 ; a publicly-defined valuetype format, registered 497 ; with IANA, as defined in section 12 of this 498 ; document 500 4.1. TEXT 502 "text": The "text" value type should be used to identify values that 503 contain human-readable text. As for the language, it is controlled 504 by the LANGUAGE property parameter defined in Section 5.1. 506 Examples for "text": 508 this is a text value 509 this is one value,this is another 510 this is a single value\, with a comma encoded 512 A formatted text line break in a text value type MUST be represented 513 as the character sequence backslash (ASCII decimal 92) followed by a 514 Latin small letter n (ASCII decimal 110) or a Latin capital letter N 515 (ASCII decimal 78), that is "\n" or "\N". 517 For example a multiple line NOTE value of: 519 Mythical Manager 520 Hyjinx Software Division 521 BabsCo, Inc. 523 could be represented as: 525 NOTE:Mythical Manager\nHyjinx Software Division\n 526 BabsCo\, Inc.\n 528 demonstrating the \n literal formatted line break technique, the 529 CRLF-followed-by-space line folding technique, and the backslash 530 escape technique. 532 4.2. URI 534 "uri": The "uri" value type should be used to identify values that 535 are referenced by a URI (including a Content-ID URI), instead of 536 encoded in-line. These value references might be used if the value 537 is too large, or otherwise undesirable to include directly. The 538 format for the URI is as defined in Section 3 of [RFC3986]. Note 539 that the value of a property of type "uri" is what the URI points to, 540 not the URI itself. 542 Examples for "uri": 544 http://www.example.com/my/picture.jpg 545 ldap://ldap.example.com/cn=babs%20jensen 547 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP 549 "date", "time", "date-time", and "timestamp": Each of these value 550 types is based on the definitions in [ISO.8601.2004] standard. 551 Multiple such values can be specified using the comma-separated 552 notation. 554 Only the basic format is supported. 556 4.3.1. DATE 558 A calendar date as specified in [ISO.8601.2004] section 4.1.2. 560 Reduced accuracy, as specified in [ISO.8601.2004] sections 4.1.2.3 a) 561 and b), but not c), is permitted. 563 Expanded representation, as specified in [ISO.8601.2004] section 564 4.1.4, is forbidden. 566 Truncated representation, as specified in [ISO.8601.2000] sections 567 5.2.1.3 d), e), and f), is permitted. 569 Examples for "date": 571 19850412 572 1985-04 573 1985 574 --0412 575 ---12 577 Note the use of YYYY-MM in the second example above. YYYYMM is 578 disallowed to prevent confusion with YYMMDD. Note also that 579 YYYY-MM-DD is disallowed since we are using the basic format instead 580 of the extended format. 582 4.3.2. TIME 584 A time of day as specified in [ISO.8601.2004] section 4.2. 586 Reduced accuracy, as specified in [ISO.8601.2004] section 4.2.2.3, is 587 permitted. 589 Representation with decimal fraction, as specified in [ISO.8601.2004] 590 section 4.2.2.4, is forbidden. 592 The midnight hour is always represented by 00, never 24 (see 593 [ISO.8601.2004] section 4.2.3). 595 Truncated representation, as specified in [ISO.8601.2000] sections 596 5.3.1.4 a), b), and c), is permitted. 598 Examples for "time": 600 102200 601 1022 602 10 603 -2200 604 --00 605 102200Z 606 102200-0800 608 4.3.3. DATE-TIME 610 A date and time of day combination as specified in [ISO.8601.2004] 611 section 4.3. 613 Truncation of the date part, as specified in [ISO.8601.2000] section 614 5.4.2 c), is permitted. 616 Examples for "date-time": 618 19961022T140000 619 --1022T1400 620 ---22T14 622 4.3.4. DATE-AND-OR-TIME 624 Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous 625 interpretation, a standalone TIME value is always preceded by a "T". 627 Examples for "date-and-or-time": 629 19961022T140000 630 --1022T1400 631 ---22T14 632 19850412 633 1985-04 634 1985 635 --0412 636 ---12 637 T102200 638 T1022 639 T10 640 T-2200 641 T--00 642 T102200Z 643 T102200-0800 645 4.3.5. TIMESTAMP 647 A complete date and time of day combination as specified in 648 [ISO.8601.2004] section 4.3.2. 650 Examples for "timestamp": 652 19961022T140000 653 19961022T140000Z 654 19961022T140000-05 655 19961022T140000-0500 657 4.4. BOOLEAN 659 "boolean": The "boolean" value type is used to express boolean 660 values. These values are case insensitive. 662 Examples: 664 TRUE 665 false 666 True 668 4.5. INTEGER 670 "integer": The "integer" value type is used to express signed 671 integers in decimal format. If sign is not specified, the value is 672 assumed positive "+". Multiple "integer" values can be specified 673 using the comma-separated notation. 675 Examples: 677 1234567890 678 -1234556790 679 +1234556790,432109876 681 4.6. FLOAT 683 "float": The "float" value type is used to express real numbers. If 684 sign is not specified, the value is assumed positive "+". Multiple 685 "float" values can be specified using the comma-separated notation. 687 Note: Scientific notation is disallowed. Implementors wishing to 688 use their favorite language's %f formatting should be careful. 690 Examples: 692 20.30 693 1000000.0000001 694 1.333,3.14 696 4.7. LANGUAGE-TAG 698 "language-tag": A single language tag, as defined in [RFC5646]. 700 5. Property Parameters 702 A property can have attributes associated with it. These "property 703 parameters" contain meta-information about the property or the 704 property value. In some cases the property parameter can be multi- 705 valued in which case the property parameter value elements are 706 separated by a COMMA (US-ASCII decimal 44). 708 Property parameter value elements that contain the COLON (US-ASCII 709 decimal 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII 710 decimal 44) character separators MUST be specified as quoted-string 711 text values. Property parameter values MUST NOT contain the DQUOTE 712 (US-ASCII decimal 34) character. The DQUOTE character is used as a 713 delimiter for parameter values that contain restricted characters or 714 URI text. 716 Applications MUST ignore x-param and iana-param values they don't 717 recognize. 719 5.1. LANGUAGE 721 The LANGUAGE property parameter is used to identify data in multiple 722 languages. There is no concept of "default" language, except as 723 specified by any "Content-Language" MIME header parameter that is 724 present. The value of the LANGUAGE property parameter is a language 725 tag as defined in Section 2 of [RFC5646]. 727 Examples: 729 ROLE;LANGUAGE=tr:hoca 731 ABNF: 733 language-param = "LANGUAGE=" Language-Tag 734 ; Language-Tag is defined in section 2.1 of RFC 5646 736 5.2. VALUE 738 The VALUE parameter is optional, and is used to identify the value 739 type (data type) and format of the value. The use of these 740 predefined formats is encouraged even if the value parameter is not 741 explicitly used. By defining a standard set of value types and their 742 formats, existing parsing and processing code can be leveraged. The 743 predefined data type values MUST NOT be repeated in COMMA separated 744 value lists except within the N, NICKNAME, ADR and CATEGORIES 745 properties. 747 ABNF: 749 value-param = "VALUE=" value-type 751 value-type = "text" 752 / "uri" 753 / "date" 754 / "time" 755 / "date-time" 756 / "timestamp" 757 / "boolean" 758 / "integer" 759 / "float" 760 / "language-tag" 761 / "utc-offset" 762 / iana-token ; registered as described in section 12 763 / x-name 765 5.3. PREF 767 The PREF parameter is optional, and is used to indicate that the 768 corresponding instance of a property is preferred by the vCard 769 author. Its value MUST be an integer between 1 and 100 that 770 quantifies the level of preference. Lower values correspond to a 771 higher level of preference, 1 being most preferred. 773 When the parameter is absent, the default MUST be to interpret the 774 property instance as being least preferred. 776 Note that the value of this parameter is to be interpreted only in 777 relation to values assigned to other instances of the same property 778 in the same vCard. A given value, or the absence of a value, MUST 779 NOT be interpreted on its own. 781 This parameter MAY be applied to any property that allows multiple 782 instances. 784 ABNF: 786 pref-param = "PREF=" (1*2DIGIT / "100") 787 ; An integer between 1 and 100. 789 5.4. ALTID 791 The ALTID parameter is used to "tag" property instances as being 792 alternative representations of the same logical property. For 793 example, translations of a property in multiple languages generates 794 multiple property instances having different LANGUAGE (Section 5.1) 795 parameter which are tagged with the same ALTID value. 797 This parameter's value is treated as an opaque string. Its sole 798 purpose is to be compared for equality against other ALTID parameter 799 values. 801 Two property instances are considered alternative representations of 802 the same logical property if and only if their names as well as the 803 value of their ALTID parameters are identical. Property instances 804 without the ALTID parameter MUST NOT be considered an alternative 805 representation of any other property instance. Values for the ALTID 806 parameter are not globally unique: they MAY be reused for different 807 property names. 809 Property instances having the same ALTID parameter value count as 1 810 toward cardinality. Therefore, since N (Section 6.2.2) has 811 cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these 812 three examples would be legal: 814 N;ALTID=1;LANGUAGE=jp:;;;; 815 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 816 ( denotes a UTF8-encoded Unicode character.) 818 TITLE;ALTID=1;LANGUAGE=fr:Patron 819 TITLE;ALTID=1;LANGUAGE=en:Boss 821 TITLE;ALTID=1;LANGUAGE=fr:Patron 822 TITLE;ALTID=1;LANGUAGE=en:Boss 823 TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist 825 while this one would not: 827 N;ALTID=1;LANGUAGE=jp:;;;; 828 N:Yamada;Taro;;; 829 (Two instances of the N property.) 831 and these three would be legal but questionable: 833 TITLE;ALTID=1;LANGUAGE=fr:Patron 834 TITLE;ALTID=2;LANGUAGE=en:Boss 835 (Should probably have the same ALTID value.) 837 TITLE;ALTID=1;LANGUAGE=fr:Patron 838 TITLE:LANGUAGE=en:Boss 839 (Second line should probably have ALTID=1.) 841 N;ALTID=1;LANGUAGE=jp:;;;; 842 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 843 N;ALTID=1;LANGUAGE=en:Smith;John;;; 844 (The last line should probably have ALTID=2. But that would be 845 illegal because N has cardinality *1.) 847 The ALTID property MAY also be used in may contexts other than with 848 the LANGUAGE parameter. Here's an example with two representations 849 of the same photo in different file formats: 851 PHOTO;ALTID=1:data:image/jpeg;base64,... 852 PHOTO;ALTID=1;data:image/jp2;base64,... 854 ABNF: 856 altid-param = "ALTID=" param-value 858 5.5. PID 860 The PID parameter is used to identify a specific property among 861 multiple instances. It plays a role analogous to the UID property 862 (Section 6.7.6) on a per-property instead of per-vCard basis. It MAY 863 appear more than once in a given property. It MUST NOT appear on 864 properties that may have only one instance per vCard. Its value is 865 either a single small positive integer, or a pair of small positive 866 integers separated by a dot. Multiple values may be encoded in a 867 single PID parameter by separating the values with a comma ",". See 868 Section 7 for more details on its usage. 870 ABNF: 872 pid-param = "PID=" pid-value *("," pid-value) 873 pid-value = 1*DIGIT ["." 1*DIGIT] 875 5.6. TYPE 877 The TYPE parameter has multiple, different uses. In general, it is a 878 way of specifying class characteristics of the associated property. 879 Most of the time, its value is a comma-separated subset of a pre- 880 defined enumeration. In this document, the following properties make 881 use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL, IMPP, 882 LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES, NOTE, 883 SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE parameter 884 MUST NOT be applied on other properties defined in this document. 886 The "work" and "home" values act like tags. The "work" value implies 887 that the property is related to an individual's work place, while the 888 "home" value implies that the property is related to an individual's 889 personal life. When neither "work" nor "home" is present, it is 890 implied that the property is related to both an individual's work 891 place and personal life in the case that the KIND property's value is 892 "individual", or to none in other cases. 894 ABNF: 896 type-param = "TYPE=" type-value *("," type-value) 898 type-value = "work" / "home" / type-param-tel 899 / type-param-related / iana-token / x-name 900 ; This is further defined in individual property sections. 902 5.7. CALSCALE 904 The CALSCALE parameter is identical to the CALSCALE property in 905 iCalendar (see [RFC5545], section 3.7.1). It is used to define the 906 calendar system in which a date or date-time value is expressed. The 907 only value specified by iCalendar is "gregorian", which stands for 908 the Gregorian system. It is the default when the parameter is 909 absent. Additional values may be defined in extension documents and 910 registered from IANA (see Section 10.3.4). A vCard implementation 911 MUST ignore properties with a CALSCALE parameter value that it does 912 not understand. 914 ABNF: 916 calscale-param = "CALSCALE=" calscale-value 918 calscale-value = "gregorian" / iana-token / x-name 920 5.8. SORT-AS 922 The "sort-as" parameter is used to specify the string to be used for 923 national-language-specific sorting. Without this information, 924 sorting algorithms could incorrectly sort this vCard within a 925 sequence of sorted vCards. When this property is present in a vCard, 926 then the given strings are used for sorting the vCard. 928 This parameter's value is a comma-separated list which MUST have as 929 many or less elements as the corresponding property value has 930 components. 932 ABNF: 934 sort-as-param = "SORT-AS=" sort-as-value 936 sort-as-value = param-value *("," param-value) 938 Examples: For the case of surname and given name sorting, the 939 following examples define common sort string usage with the N 940 property. 942 FN:Rene van der Harten 943 N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N. 945 FN:Robert Pau Shou Chang 946 N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;; 948 FN:Osamu Koura 949 N;SORT-AS="Koura,Osamu":Koura;Osamu;; 951 FN:Oscar del Pozo 952 N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;; 954 FN:Chistine d'Aboville 955 N;SORT-AS="Aboville,Christine":d'Aboville;Christine;; 957 FN:H. James de Mann 958 N;SORT-AS="Mann,James":de Mann;Henry,James;; 960 If sorted by surname the results would be: 962 Christine d'Aboville 963 Rene van der Harten 964 Osamu Koura 965 H. James de Mann 966 Robert Pau Shou Chang 967 Oscar del Pozo 969 If sorted by given name the results would be: 971 Christine d'Aboville 972 H. James de Mann 973 Osamu Koura 974 Oscar del Pozo 975 Rene van der Harten 976 Robert Pau Shou Chang 978 5.9. GEO 980 The GEO parameter can be used to indicate global positioning 981 information that is specific to an address. Its value is the same as 982 that of the GEO property (see Section 6.5.2). 984 ABNF: 986 geo-param = "GEO=" DQUOTE uri DQUOTE 988 5.10. TZ 990 The TZ parameter can be used to indicate time zone information that 991 is specific to an address. Its value is the same as that of the TZ 992 property. 994 ABNF: 996 tz-param = "TZ=" (param-value / DQUOTE uri DQUOTE) 998 6. vCard Properties 1000 What follows is an enumeration of the standard vCard properties. 1002 Property cardinalities are indicated using the following notation, 1003 which is based on ABNF (see [RFC5234], section 3.6): 1005 +-------------+--------------------------------------------------+ 1006 | Cardinality | Meaning | 1007 +-------------+--------------------------------------------------+ 1008 | 1 | Exactly one instance per vCard MUST be present. | 1009 | *1 | Exactly one instance per vCard MAY be present. | 1010 | 1* | One or more instances per vCard MUST be present. | 1011 | * | One or more instances per vCard MAY be present. | 1012 +-------------+--------------------------------------------------+ 1014 6.1. General Properties 1016 6.1.1. BEGIN 1018 Purpose: To denote the beginning of a syntactic entity within a 1019 text/vcard content-type. 1021 Value type: text 1023 Cardinality: 1 1025 Special notes: The content entity MUST begin with the BEGIN property 1026 with a value of "VCARD". The value is case-insensitive. 1028 The BEGIN property is used in conjunction with the END property to 1029 delimit an entity containing a related set of properties within an 1030 text/vcard content-type. This construct can be used instead of or 1031 in addition to wrapping separate sets of information inside 1032 additional MIME headers. It is provided for applications that 1033 wish to define content that can contain multiple entities within 1034 the same text/vcard content-type or to define content that can be 1035 identifiable outside of a MIME environment. 1037 ABNF: 1039 BEGIN-param = ; no parameter allowed 1040 BEGIN-value = "VCARD" 1042 Example: 1044 BEGIN:VCARD 1046 6.1.2. END 1048 Purpose: To denote the end of a syntactic entity within a text/vcard 1049 content-type. 1051 Value type: text 1053 Cardinality: 1 1055 Special notes: The content entity MUST end with the END type with a 1056 value of "VCARD". The value is case-insensitive. 1058 The END property is used in conjunction with the BEGIN property to 1059 delimit an entity containing a related set of properties within an 1060 text/vcard content-type. This construct can be used instead of or 1061 in addition to wrapping separate sets of information inside 1062 additional MIME headers. It is provided for applications that 1063 wish to define content that can contain multiple entities within 1064 the same text/vcard content-type or to define content that can be 1065 identifiable outside of a MIME environment. 1067 ABNF: 1069 END-param = ; no parameter allowed 1070 END-value = "VCARD" 1072 Example: 1074 END:VCARD 1076 6.1.3. SOURCE 1078 Purpose: To identify the source of directory information contained 1079 in the content type. 1081 Value type: uri 1082 Cardinality: * 1084 Special notes: The SOURCE property is used to provide the means by 1085 which applications knowledgable in the given directory service 1086 protocol can obtain additional or more up-to-date information from 1087 the directory service. It contains a URI as defined in [RFC3986] 1088 and/or other information referencing the vCard to which the 1089 information pertains. When directory information is available 1090 from more than one source, the sending entity can pick what it 1091 considers to be the best source, or multiple SOURCE properties can 1092 be included. 1094 ABNF: 1096 SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param 1097 / any-param 1098 SOURCE-value = uri 1100 Examples: 1102 SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US 1104 SOURCE:http://directory.example.com/addressbooks/jdoe/ 1105 Jean%20Dupont.vcf 1107 6.1.4. KIND 1109 Purpose: To specify the kind of object the vCard represents. 1111 Value type: A single text value. 1113 Cardinality: *1 1115 Special notes: The value may be one of: "individual" for a single 1116 person, "group" for a group, "org" for an organization, "location" 1117 for a named geographical place, an x-name or an iana-token. If 1118 this property is absent, "individual" MUST be assumed as default. 1120 Additional values may be registered from IANA (see 1121 Section 10.3.4). A new value's specification document MUST 1122 specify which properties make sense for that new kind of vCard, 1123 and which do not. 1125 ABNF: 1127 KIND-param = "VALUE=text" / any-param 1128 KIND-value = "individual" / "group" / "org" / "location" 1129 / iana-token / x-name 1131 Example: 1133 This represents someone named Jane Doe working in the marketing 1134 department of the North American division of ABC Inc. 1136 BEGIN:VCARD 1137 VERSION:4.0 1138 KIND:individual 1139 FN:Jane Doe 1140 ORG:ABC\, Inc.;North American Division;Marketing 1141 END:VCARD 1143 This represents the department itself, commonly known as ABC 1144 Marketing. 1146 BEGIN:VCARD 1147 VERSION:4.0 1148 KIND:org 1149 FN:ABC Marketing 1150 ORG:ABC\, Inc.;North American Division;Marketing 1151 END:VCARD 1153 6.1.5. XML 1155 Purpose: To include extended XML-encoded vCard data in a plain 1156 vCard. 1158 Value type: A single text value. 1160 Cardinality: * 1162 Special notes: The content of this property is a single XML 1.0 1163 element whose namespace MUST be explicitly specified using the 1164 xmlns attribute and MUST NOT be the vCard 4 namespace 1165 ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies that it 1166 cannot duplicate a standard vCard property.) The element is to be 1167 interpreted as if it was contained in a element, as 1168 defined in [I-D.ietf-vcarddav-vcardxml]. 1170 The fragment is subject to normal line folding and escaping, i.e. 1171 replace all backslashes with "\\", then replace all newlines with 1172 "\n", then fold long lines. 1174 Support for this property is OPTIONAL, but implementations of this 1175 specification MUST preserve instances of this property when 1176 propagating vCards. 1178 See [I-D.ietf-vcarddav-vcardxml] for more information on the 1179 intended use of this property. 1181 ABNF: 1183 XML-param = "VALUE=text" / altid-param 1184 XML-value = text 1186 6.2. Identification Properties 1188 These types are used to capture information associated with the 1189 identification and naming of the person or resource associated with 1190 the vCard. 1192 6.2.1. FN 1194 Purpose: To specify the formatted text corresponding to the name of 1195 the object the vCard represents. 1197 Value type: A single text value. 1199 Cardinality: 1* 1201 Special notes: This property is based on the semantics of the X.520 1202 Common Name attribute. The property MUST be present in the vCard 1203 object. 1205 ABNF: 1207 FN-param = "VALUE=text" / type-param / language-param / altid-param 1208 / pid-param / pref-param / any-param 1209 FN-value = text 1211 Example: 1213 FN:Mr. John Q. Public\, Esq. 1215 6.2.2. N 1217 Purpose: To specify the components of the name of the object the 1218 vCard represents. 1220 Value type: A single structured text value. Each component can have 1221 multiple values. 1223 Cardinality: *1 1225 Special note: The structured property value corresponds, in 1226 sequence, to the Family Names (also known as surnames), Given 1227 Names, Additional Names, Honorific Prefixes, and Honorific 1228 Suffixes. The text components are separated by the SEMI-COLON 1229 character (ASCII decimal 59). Individual text components can 1230 include multiple text values separated by the COMMA character 1231 (ASCII decimal 44). This property is based on the semantics of 1232 the X.520 individual name attributes. The property SHOULD be 1233 present in the vCard object when the name of the object the vCard 1234 represents follows the X.520 model. 1236 The SORT-AS parameter MAY be applied to this property. 1238 ABNF: 1240 N-param = "VALUE=text" / sort-as-param / language-param 1241 / altid-param / any-param 1242 N-value = list-component 4(";" list-component) 1244 Examples: 1246 N:Public;John;Quinlan;Mr.;Esq. 1248 N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P. 1250 6.2.3. NICKNAME 1252 Purpose: To specify the text corresponding to the nickname of the 1253 object the vCard represents. 1255 Value type: One or more text values separated by a COMMA character 1256 (ASCII decimal 44). 1258 Cardinality: * 1260 Special note: The nickname is the descriptive name given instead of 1261 or in addition to the one belonging to a the object the vCard 1262 represents. It can also be used to specify a familiar form of a 1263 proper name specified by the FN or N properties. 1265 ABNF: 1267 NICKNAME-param = "VALUE=text" / type-param / language-param 1268 / altid-param / pid-param / pref-param / any-param 1269 NICKNAME-value = text-list 1271 Examples: 1273 NICKNAME:Robbie 1275 NICKNAME:Jim,Jimmie 1277 NICKNAME;TYPE=work:Boss 1279 6.2.4. PHOTO 1281 Purpose: To specify an image or photograph information that 1282 annotates some aspect of the object the vCard represents. 1284 Value type: A single URI. 1286 Cardinality: * 1288 ABNF: 1290 PHOTO-param = "VALUE=uri" / altid-param / type-param 1291 PHOTO-value = uri 1293 Examples: 1295 PHOTO:http://www.example.com/pub/photos/jqpublic.gif 1297 PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv 1298 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1299 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1300 <...remainder of base64-encoded data...> 1302 6.2.5. BDAY 1304 Purpose: To specify the birth date of the object the vCard 1305 represents. 1307 Value type: The default is a single date-and-or-time value. It can 1308 also be reset to a single text value. 1310 Cardinality: *1 1312 ABNF: 1314 BDAY-param = BDAY-param-date / BDAY-param-text 1315 BDAY-value = date-and-or-time / text 1316 ; Value and parameter MUST match. 1318 BDAY-param-date = "VALUE=date-and-or-time" 1319 BDAY-param-text = "VALUE=text" / language-param 1321 BDAY-param =/ altid-param / calscale-param / any-param 1322 ; calscale-param can only be present when BDAY-value is 1323 ; date-and-or-time and actually contains a date or date-time. 1325 Examples: 1327 BDAY:19960415 1328 BDAY:--0415 1329 BDAY;19531015T231000Z 1330 BDAY;VALUE=text:circa 1800 1332 6.2.6. ANNIVERSARY 1334 Purpose: The date of marriage, or equivalent, of the object the 1335 vCard represents. 1337 Value type: The default is a single date-and-or-time value. It can 1338 also be reset to a single text value. 1340 Cardinality: *1 1342 ABNF: 1344 ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text") 1345 ANNIVERSARY-value = date-and-or-time / text 1346 ; Value and parameter MUST match. 1348 ANNIVERSARY-param =/ altid-param / calscale-param / any-param 1349 ; calscale-param can only be present when ANNIVERSARY-value is 1350 ; date-and-or-time and actually contains a date or date-time. 1352 Examples: 1354 ANNIVERSARY:19960415 1356 6.2.7. GENDER 1357 Purpose: To specify the components of the sex and gender identity of 1358 the object the vCard represents. 1360 Value type: A single structured value with two components. Each 1361 component has a single text value. 1363 Cardinality: *1 1365 Special notes: The components correspond, in sequence, to the sex 1366 (biological), and gender identity. Each component is optional. 1368 Sex component: A single letter. M stands for "male", F stands 1369 for "female", O stands for "other", N stands for "none or not 1370 applicable", U stands for "unknown". 1372 Gender identity component: Free-form text. 1374 ABNF: 1376 GENDER-param = "VALUE=text" / any-param 1377 GENDER-value = sex [";" text] 1379 sex = "" / "M" / "F" / "O" / "N" / "U" 1381 Examples: 1383 GENDER:M 1384 GENDER:F 1385 GENDER:M;Fellow 1386 GENDER:F;Bird 1387 GENDER:O;intersex 1388 GENDER:;queer 1390 6.3. Delivery Addressing Properties 1392 These types are concerned with information related to the delivery 1393 addressing or label for the vCard object. 1395 6.3.1. ADR 1397 Purpose: To specify the components of the delivery address for the 1398 vCard object. 1400 Value type: A single structured text value, separated by the SEMI- 1401 COLON character (ASCII decimal 59). 1403 Cardinality: * 1405 Special notes: The structured type value consists of a sequence of 1406 address components. The component values MUST be specified in 1407 their corresponding position. The structured type value 1408 corresponds, in sequence, to the post office box; the extended 1409 address (e.g. apartment or suite number); the street address; the 1410 locality (e.g., city); the region (e.g., state or province); the 1411 postal code; the country name (full name in the language specified 1412 in Section 5.1). When a component value is missing, the 1413 associated component separator MUST still be specified. 1415 Experience with vCard 3 has shown that the first two components 1416 (post office box and extended address) are plagued with many 1417 interoperability issues. To ensure maximal interoperability, 1418 their values SHOULD be empty. 1420 The text components are separated by the SEMI-COLON character 1421 (ASCII decimal 59). Where it makes semantic sense, individual 1422 text components can include multiple text values (e.g., a "street" 1423 component with multiple lines) separated by the COMMA character 1424 (ASCII decimal 44). 1426 The property can include the "PREF" parameter to indicate the 1427 preferred delivery address when more than one address is 1428 specified. 1430 The GEO and TZ parameters MAY be used with this property. 1432 The property can also include a "LABEL" parameter to present a 1433 delivery delivery address label for the address. Its value is a 1434 plain-text string representing the formatted address. Newlines 1435 are encoded as \n, as they are for property values. 1437 ABNF: 1439 label-param = "LABEL=" param-value 1441 ADR-param = "VALUE=text" / label-param / language-param / geo-param 1442 / tz-param / altid-param / pid-param / pref-param 1443 / type-param / any-param 1444 ADR-value = ADR-component-pobox ";" ADR-component-ext ";" 1445 ADR-component-street ";" ADR-component-locality ";" 1446 ADR-component-region ";" ADR-component-code ";" 1447 ADR-component-country 1448 ADR-component-pobox = list-component 1449 ADR-component-ext = list-component 1450 ADR-component-street = list-component 1451 ADR-component-locality = list-component 1452 ADR-component-region = list-component 1453 ADR-component-code = list-component 1454 ADR-component-country = list-component 1456 Example: In this example the post office box and the extended address 1457 are absent. 1459 ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n 1460 Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n 1461 U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A. 1463 6.4. Communications Properties 1465 These properties describe information about how to communicate with 1466 the object the vCard represents. 1468 6.4.1. TEL 1470 Purpose: To specify the telephone number for telephony communication 1471 with the object the vCard represents. 1473 Value type: By default it is a single free-form text value (for 1474 backward compatibility with vCard 3), but it SHOULD be reset to a 1475 URI value. It is expected that the URI scheme will be "tel", as 1476 specified in [RFC3966], but other schemes MAY be used. 1478 Cardinality: * 1480 Special notes: This property is based on the X.520 Telephone Number 1481 attribute. 1483 The property can include the "PREF" parameter to indicate a 1484 preferred-use telephone number. 1486 The property can include the parameter "TYPE" to specify intended 1487 use for the telephone number. The predefined values for the TYPE 1488 parameter are: 1490 +-----------+-------------------------------------------------------+ 1491 | Value | Description | 1492 +-----------+-------------------------------------------------------+ 1493 | text | Indicates that the telephone number supports text | 1494 | | messages (SMS). | 1495 | voice | Indicates a voice telephone number. | 1496 | fax | Indicates a facsimile telephone number. | 1497 | cell | Indicates a cellular or mobile telephone number. | 1498 | video | Indicates a video conferencing telephone number. | 1499 | pager | Indicates a paging device telephone number. | 1500 | textphone | Indicates a telecommunication device for people with | 1501 | | hearing or speech difficulties.. | 1502 +-----------+-------------------------------------------------------+ 1504 The default type is "voice". These type parameter values can be 1505 specified as a parameter list (e.g., "TYPE=text;TYPE=voice") or as 1506 a value list (e.g., "TYPE=text,voice"). The default can be 1507 overridden to another set of values by specifying one or more 1508 alternate values. For example, the default TYPE of "voice" can be 1509 reset to a VOICE and FAX telephone number by the value list 1510 "TYPE=voice,fax". 1512 If this property's value is a URI that can also be used for 1513 instant messaging, the IMPP (Section 6.4.3) property SHOULD be 1514 used in addition to this property. 1516 ABNF: 1518 TEL-param = TEL-text-param / TEL-uri-param 1519 TEL-value = TEL-text-value / TEL-uri-value 1520 ; Value and parameter MUST match 1522 TEL-text-param = "VALUE=text" 1523 TEL-text-value = text 1525 TEL-uri-param = "VALUE=uri" 1526 TEL-uri-value = uri 1528 TEL-param =/ type-param / pid-param / pref-param / altid-param 1529 / any-param 1531 type-param-tel = "text" / "voice" / "fax" / "cell" / "video" 1532 / "pager" / "textphone" / iana-token / x-name 1533 ; type-param-tel MUST NOT be used with a property other than TEL. 1535 Example: 1537 TEL;VALUE=uri;PREF=1;TYPE=voice,home:tel:+1-555-555-5555;ext=5555 1538 TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67 1540 6.4.2. EMAIL 1542 Purpose: To specify the electronic mail address for communication 1543 with the object the vCard represents. 1545 Value type: A single text value. 1547 Cardinality: * 1549 Special notes: The property can include tye "PREF" parameter to 1550 indicate a preferred-use email address when more than one is 1551 specified. 1553 Even though the value is free-form UTF-8 text, it is likely to be 1554 interpreted by an MUA as an "addr-spec", as defined in [RFC5322], 1555 section 3.4.1. Readers should also be aware of the current work 1556 toward internationalized email addresses 1557 [I-D.ietf-eai-rfc5335bis]. 1559 ABNF: 1561 EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param 1562 / altid-param / any-param 1563 EMAIL-value = text 1565 Example: 1567 EMAIL;TYPE=work:jqpublic@xyz.example.com 1569 EMAIL;PREF=1:jane_doe@example.com 1571 6.4.3. IMPP 1573 Purpose: To specify the URI for instant messaging and presence 1574 protocol communications with the object the vCard represents. 1576 Value type: A single URI. 1578 Cardinality: * 1579 Special notes: The property may include the "PREF" parameter to 1580 indicate that this is a preferred address and has the same 1581 semantics as the "PREF" parameter in a TEL property. 1583 If this property's value is a URI that can be used for voice 1584 and/or video, the TEL property (Section 6.4.1) SHOULD be used in 1585 addition to this property. 1587 This property is adapted from [RFC4770], which is made obsolete by 1588 this document. 1590 ABNF: 1592 IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param 1593 / altid-param / any-param 1594 IMPP-value = uri 1596 Example: 1598 IMPP;PREF=1:xmpp:alice@example.com 1600 6.4.4. LANG 1602 Purpose: To specify the language(s) that may be used for contacting 1603 the individual associated with the vCard. 1605 Value type: A single language-tag value. 1607 Cardinality: * 1609 ABNF: 1611 LANG-param = "VALUE=language-tag" / pid-param / pref-param 1612 / altid-param / type-param / any-param 1613 LANG-value = Language-Tag 1615 Example: 1617 LANG;TYPE=work;PREF=1:en 1618 LANG;TYPE=work;PREF=2:fr 1619 LANG;TYPE=home:fr 1621 6.5. Geographical Properties 1623 These properties are concerned with information associated with 1624 geographical positions or regions associated with the object the 1625 vCard represents. 1627 6.5.1. TZ 1629 Purpose: To specify information related to the time zone of the 1630 object the vCard represents. 1632 Value type: The default is a single text value. It can also be 1633 reset to a single URI or utc-offset value. 1635 Cardinality: * 1637 Special notes: It is expected that names from the public-domain 1638 Olson database [TZ-DB] will be used, but this is not a 1639 restriction. 1641 Efforts are currently being directed at creating a standard URI 1642 scheme for expressing time zone information. Usage of such a 1643 scheme would ensure a high level of interoperability between 1644 implementations that support it. 1646 Note that utc-offset values SHOULD NOT be used because the UTC 1647 offset varies with time - not just because of the usual daylight 1648 saving time shifts that occur in may regions, but often entire 1649 regions will "re-base" their overall offset. The actual offset 1650 may be +/- 1 hour (or perhaps a little more) than the one given. 1652 ABNF: 1654 TZ-param = "VALUE=" ("text" / "uri" / "utc-offset") 1655 TZ-value = text / uri / utc-offset 1656 ; Value and parameter MUST match 1658 TZ-param =/ altid-param / pid-param / pref-param / type-param 1659 / any-param 1661 Examples: 1663 TZ:Raleigh/North America 1665 TZ;VALUE=utc-offset:-0500 1666 ; Note: utc-offset format is NOT RECOMMENDED. 1668 6.5.2. GEO 1670 Purpose: To specify information related to the global positioning of 1671 the object the vCard represents. 1673 Value type: A single URI. 1675 Cardinality: * 1677 Special notes: The "geo" URI scheme [RFC5870] is particularly well- 1678 suited for this property, but other schemes MAY be used. 1680 ABNF: 1682 GEO-param = "VALUE=uri" / pid-param / pref-param / type-param 1683 / altid-param / any-param 1684 GEO-value = uri 1686 Example: 1688 GEO:geo:37.386013,-122.082932 1690 6.6. Organizational Properties 1692 These properties are concerned with information associated with 1693 characteristics of the organization or organizational units of the 1694 object that the vCard represents. 1696 6.6.1. TITLE 1698 Purpose: To specify the position or job of the object the vCard 1699 represents. 1701 Value type: A single text value. 1703 Cardinality: * 1705 Special notes: This property is based on the X.520 Title attribute. 1707 ABNF: 1709 TITLE-param = "VALUE=text" / language-param / pid-param 1710 / pref-param / altid-param / type-param / any-param 1711 TITLE-value = text 1713 Example: 1715 TITLE:Research Scientist 1717 6.6.2. ROLE 1719 Purpose: To specify the function or part played in a particular 1720 situation by the object the vCard represents. 1722 Value type: A single text value. 1724 Cardinality: * 1726 Special notes: This property is based on the X.520 Business Category 1727 explanatory attribute. This property is included as an 1728 organizational type to avoid confusion with the semantics of the 1729 TITLE property and incorrect usage of that property when the 1730 semantics of this property is intended. 1732 ABNF: 1734 ROLE-param = "VALUE=text" / language-param / pid-param / pref-param 1735 / type-param / altid-param / any-param 1736 ROLE-value = text 1738 Example: 1740 ROLE:Project Leader 1742 6.6.3. LOGO 1744 Purpose: To specify a graphic image of a logo associated with the 1745 object the vCard represents. 1747 Value type: A single URI. 1749 Cardinality: * 1751 ABNF: 1753 LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param 1754 / type-param / altid-param / any-param 1755 LOGO-value = uri 1757 Examples: 1759 LOGO:http://www.example.com/pub/logos/abccorp.jpg 1761 LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc 1762 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1763 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1764 <...the remainder of base64-encoded data...> 1766 6.6.4. ORG 1768 Purpose: To specify the organizational name and units associated 1769 with the vCard. 1771 Value type: A single structured text value consisting of components 1772 separated by the SEMI-COLON character (ASCII decimal 59). 1774 Cardinality: * 1776 Special notes: The property is based on the X.520 Organization Name 1777 and Organization Unit attributes. The property value is a 1778 structured type consisting of the organization name, followed by 1779 zero or more levels of organizational unit names. 1781 The SORT-AS parameter MAY be applied to this property. 1783 ABNF: 1785 ORG-param = "VALUE=text" / sort-as-param / language-param 1786 / pid-param / pref-param / altid-param / type-param 1787 / any-param 1788 ORG-value = component *(";" component) 1790 Example: A property value consisting of an organizational name, 1791 organizational unit #1 name and organizational unit #2 name. 1793 ORG:ABC\, Inc.;North American Division;Marketing 1795 6.6.5. MEMBER 1797 Purpose: To include a member in the group this vCard represents. 1799 Value type: A single URI. It MAY refer to something other than a 1800 vCard object. For example, an e-mail distribution list could 1801 employ the "mailto" URI scheme for efficiency. 1803 Cardinality: * 1805 Special notes: This property MUST NOT be present unless the value of 1806 the KIND property is "group". 1808 ABNF: 1810 MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param 1811 / any-param 1812 MEMBER-value = uri 1814 Examples: 1816 BEGIN:VCARD 1817 VERSION:4.0 1818 KIND:group 1819 FN:The Doe family 1820 MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1821 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1822 END:VCARD 1823 BEGIN:VCARD 1824 VERSION:4.0 1825 FN:John Doe 1826 UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1827 END:VCARD 1828 BEGIN:VCARD 1829 VERSION:4.0 1830 FN:Jane Doe 1831 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1832 END:VCARD 1834 BEGIN:VCARD 1835 VERSION:4.0 1836 KIND:group 1837 FN:Funky distribution list 1838 MEMBER:mailto:subscriber1@example.com 1839 MEMBER:xmpp:subscriber2@example.com 1840 MEMBER:sip:subscriber3@example.com 1841 MEMBER:tel:+1-418-555-5555 1842 END:VCARD 1844 6.6.6. RELATED 1846 Purpose: To specify a relationship between another person and the 1847 individual represented by this vCard. 1849 Value type: A single URI. It can also be reset to a single text 1850 value. The text value can be used to specify textual information. 1852 Cardinality: * 1854 Special notes: The TYPE parameter MAY be used to characterize the 1855 related individual. It contains a comma-separated list of values 1856 that are registered from IANA as described in Section 10.2. The 1857 registry is pre-populated with the values defined in [xfn]. This 1858 document also specifies two additional values: 1860 agent: a person who may sometimes act on behalf of the individual 1861 or resource associated with the vCard. 1863 emergency: indicates an emergency contact 1865 ABNF: 1867 RELATED-param = RELATED-param-uri / RELATED-param-text 1868 RELATED-value = uri / text 1869 ; Parameter and value MUST match. 1871 RELATED-param-uri = "VALUE=uri" 1872 RELATED-param-text = "VALUE=text" / language-param 1874 RELATED-param =/ pid-param / pref-param / altid-param / type-param 1875 / any-param 1877 type-param-related = related-type-value *("," related-type-value) 1878 ; type-param-related MUST NOT be used with a property other than 1879 ; RELATED. 1881 related-type-value = "contact" / "acquaintance" / "friend" / "met" 1882 / "co-worker" / "colleague" / "co-resident" 1883 / "neighbor" / "child" / "parent" 1884 / "sibling" / "spouse" / "kin" / "muse" 1885 / "crush" / "date" / "sweetheart" / "me" 1886 / "agent" / "emergency" 1888 Examples: 1890 RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1891 RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf 1892 RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane 1893 Doe for any inquiries. 1895 6.7. Explanatory Properties 1897 These properties are concerned with additional explanations, such as 1898 that related to informational notes or revisions specific to the 1899 vCard. 1901 6.7.1. CATEGORIES 1903 Purpose: To specify application category information about the 1904 vCard. Also known as "tags". 1906 Value type: One or more text values separated by a COMMA character 1907 (ASCII decimal 44). 1909 Cardinality: * 1911 ABNF: 1913 CATEGORIES-param = "VALUE=text" / pid-param / pref-param 1914 / type-param / altid-param / any-param 1915 CATEGORIES-value = text-list 1917 Example: 1919 CATEGORIES:TRAVEL AGENT 1921 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY 1923 6.7.2. NOTE 1925 Purpose: To specify supplemental information or a comment that is 1926 associated with the vCard. 1928 Value type: A single text value. 1930 Cardinality: * 1932 Special notes: The property is based on the X.520 Description 1933 attribute. 1935 ABNF: 1937 NOTE-param = "VALUE=text" / language-param / pid-param / pref-param 1938 / type-param / altid-param / any-param 1939 NOTE-value = text 1941 Example: 1943 NOTE:This fax number is operational 0800 to 1715 1944 EST\, Mon-Fri. 1946 6.7.3. PRODID 1948 Purpose: To specify the identifier for the product that created the 1949 vCard object. 1951 Type value: A single text value. 1953 Cardinality: *1 1955 Special notes: Implementations SHOULD use a method such as that 1956 specified for Formal Public Identifiers in [ISO9070] or for 1957 Universal Resource Names in [RFC3406] to ensure that the text 1958 value is unique. 1960 ABNF: 1962 PRODID-param = "VALUE=text" / any-param 1963 PRODID-value = text 1965 Example: 1967 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN 1969 6.7.4. REV 1971 Purpose: To specify revision information about the current vCard. 1973 Value type: A single timestamp value. 1975 Cardinality: *1 1977 Special notes: The value distinguishes the current revision of the 1978 information in this vCard for other renditions of the information. 1980 ABNF: 1982 REV-param = "VALUE=timestamp" / any-param 1983 REV-value = timestamp 1985 Example: 1987 REV:19951031T222710Z 1989 6.7.5. SOUND 1991 Purpose: To specify a digital sound content information that 1992 annotates some aspect of the vCard. This property is often used 1993 to specify the proper pronunciation of the name property value of 1994 the vCard. 1996 Value type: A single URI. 1998 Cardinality: * 2000 ABNF: 2002 SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param 2003 / type-param / altid-param / any-param 2004 SOUND-value = uri 2006 Example: 2008 SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com 2010 SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh 2011 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 2012 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 2013 <...the remainder of base64-encoded data...> 2015 6.7.6. UID 2017 Purpose: To specify a value that represents a globally unique 2018 identifier corresponding to the individual or resource associated 2019 with the vCard. 2021 Value type: A single URI value. It MAY also be reset to free-form 2022 text. 2024 Cardinality: *1 2026 Special notes: This property is used to uniquely identify the object 2027 that the vCard represents. The "uuid" URN namespace defined in 2028 [RFC4122] is particularly well-suited to this task, but other URI 2029 schemes MAY be used. Free-form text MAY also be used. 2031 ABNF: 2033 UID-param = UID-uri-param / UID-text-param 2034 UID-value = UID-uri-value / UID-text-value 2035 ; Value and parameter MUST match. 2037 UID-uri-param = "VALUE=uri" 2038 UID-uri-value = uri 2040 UID-text-param = "VALUE=text" 2041 UID-text-value = text 2043 UID-param =/ any-param 2045 Example: 2047 UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2049 6.7.7. CLIENTPIDMAP 2051 Purpose: To give a global meaning to a local PID source identifier. 2053 Value type: A semicolon-separated pair of values. The first field 2054 is a small integer corresponding to the second field of a PID 2055 parameter instance. The second field is a URI. The "uuid" URN 2056 namespace defined in [RFC4122] is particularly well-suited to this 2057 task, but other URI schemes MAY be used. 2059 Cardinality: * 2061 Special notes: PID source identifiers (the source identifier is the 2062 second field in a PID parameter instance) are small integers that 2063 only have significance within the scope of a single vCard 2064 instance. Each distinct source identifier present in a vCard MUST 2065 have an associated CLIENTPIDMAP. See Section 7 for more details 2066 on the usage of CLIENTPIDMAP. 2068 PID source identifiers MUST be strictly positive. Zero is not 2069 allowed. 2071 As a special exception, the PID parameter MUST NOT be applied to 2072 this property. 2074 ABNF: 2076 CLIENTPIDMAP-param = any-param 2077 CLIENTPIDMAP-value = 1*DIGIT ";" uri 2079 Example: 2081 TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555 2082 EMAIL;PID=4.1,5.2:jdoe@example.com 2083 CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b 2084 CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5 2086 6.7.8. URL 2088 Purpose: To specify a uniform resource locator associated with the 2089 object that the vCard refers to. Examples for individuals include 2090 personal web sites, blogs, and social networking site identifiers. 2092 Cardinality: * 2094 Value type: A single uri value. 2096 ABNF: 2098 URL-param = "VALUE=uri" / pid-param / pref-param / type-param 2099 / altid-param / any-param 2100 URL-value = uri 2102 Example: 2104 URL:http://example.org/restaurant.french/~chezchic.html 2106 6.7.9. VERSION 2108 Purpose: To specify the version of the vCard specification used to 2109 format this vCard. 2111 Value type: A single text value. 2113 Cardinality: 1 2115 Special notes: This property MUST be present in the vCard object, 2116 and it must come first. The value MUST be "4.0" if the vCard 2117 corresponds to this specification. Note that earlier versions of 2118 vCard allowed this property to be placed anywehre in the vCard 2119 object, or even to be absent. 2121 ABNF: 2123 VERSION-param = "VALUE=text" / any-param 2124 VERSION-value = "4.0" 2126 Example: 2128 VERSION:4.0 2130 6.8. Security Properties 2132 These properties are concerned with the security of communication 2133 pathways or access to the vCard. 2135 6.8.1. KEY 2136 Purpose: To specify a public key or authentication certificate 2137 associated with the object that the vCard represents. 2139 Value type: A single URI. It can also be reset to a text value. 2141 Cardinality: * 2143 ABNF: 2145 KEY-param = KEY-uri-param / KEY-text-param 2146 KEY-value = KEY-uri-value / KEY-text-value 2147 ; Value and parameter MUST match. 2149 KEY-uri-param = "VALUE=uri" 2150 KEY-uri-value = uri 2152 KEY-text-param = "VALUE=text" 2153 KEY-text-value = text 2155 KEY-param =/ altid-param / pid-param / pref-param / type-param 2156 / any-param 2158 Examples: 2160 KEY:http://www.example.com/keys/jdoe 2162 KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE 2163 UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l 2164 <... remainder of base64-encoded data ...> 2166 6.9. Calendar Properties 2168 These properties are further specified in [RFC2739]. 2170 6.9.1. FBURL 2172 Purpose: To specify the URI for the busy time associated with the 2173 object that the vCard represents. 2175 Value type: A single URI value. 2177 Cardinality: * 2179 Special notes: Where multiple FBURL properties are specified, the 2180 default FBURL property is indicated with the PREF parameter. The 2181 FTP or HTTP type of URI points to an iCalendar [RFC5545] object 2182 associated with a snapshot of the next few weeks or months of busy 2183 time data. If the iCalendar object is represented as a file or 2184 document, its file type should be "ifb". 2186 ABNF: 2188 FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param 2189 / altid-param / any-param 2190 FBURL-value = uri 2192 Examples: 2194 FBURL;PREF=1:http://www.example.com/busy/janedoe 2195 FBURL:FTP://ftp.example.com/busy/project-a.ifb 2197 6.9.2. CALADRURI 2199 Purpose: To specify the calendar user address [RFC5545] to which a 2200 scheduling request [RFC5546] should be sent for the object 2201 represented by the vCard. 2203 Value type: A single URI value. 2205 Cardinality: * 2207 Special notes: Where multiple CALADRURI properties are specified, 2208 the default CALADRURI property is indicated with the PREF 2209 parameter. 2211 ABNF: 2213 CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2214 / altid-param / any-param 2215 CALADRURI-value = uri 2217 Example: 2219 CALADRURI;PREF=1:mailto:janedoe@example.com 2220 CALADRURI:http://example.com/calendar/jdoe 2222 6.9.3. CALURI 2224 Purpose: To specify the URI for a calendar associated with the 2225 object represented by the vCard. 2227 Value type: A single URI value. 2229 Cardinality: * 2231 Special notes: Where multiple CALURI properties are specified, the 2232 default CALURI property is indicated with the PREF parameter. The 2233 property should contain a URI pointing to an iCalendar [RFC5545] 2234 object associated with a snapshot of the user's calendar store. 2235 If the iCalendar object is represented as a file or document, its 2236 file type should be "ics". 2238 ABNF: 2240 CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2241 / altid-param / any-param 2242 CALURI-value = uri 2244 Examples: 2246 CALURI;PREF=1:http://cal.example.com/calA 2247 CALURI:ftp://ftp.example.com/calA.ics 2249 6.10. Extended Properties and Parameters 2251 The properties and parameters defined by this document can be 2252 extended. Non-standard, private properties and parameters with a 2253 name starting with "X-" may be defined bilaterally between two 2254 cooperating agents without outside registration or standardization. 2256 7. Synchronization 2258 vCard data often needs to be synchronized between devices. In this 2259 context, synchronization is defined as the intelligent merging of two 2260 representations of the same object. vCard 4.0 includes mechanisms to 2261 aid this process. 2263 7.1. Mechanisms 2265 Two mechanisms are available: the UID property is used to match 2266 multiple instances of the same vCard, while the PID parameter is used 2267 to match multiple instances of the same property. 2269 The term "matching" is used here to mean recognizing that two 2270 instances are in fact representations of the same object. For 2271 example, a single vCard that is shared with someone results in two 2272 vCard instances. After they have evolved separately, they still 2273 represent the same object, and therefore may be matched by a 2274 synchronization engine. 2276 7.1.1. Matching vCard Instances 2278 vCard instances for which the UID properties (Section 6.7.6) are 2279 equivalent MUST be matched. Equivalence is determined as specified 2280 in [RFC3986], Section 6. 2282 In all other cases, vCard instances MAY be matched at the discretion 2283 of the synchronization engine. 2285 7.1.2. Matching Property Instances 2287 Property instances belonging to unmatched vCards MUST NOT be matched. 2289 Property instances whose name (e.g. EMAIL, TEL, etc.) is not the 2290 same MUST NOT be matched. 2292 Property instances whose name is CLIENTPIDMAP are handled separately 2293 and MUST NOT be matched. The synchronization MUST ensure that there 2294 is consistency of CLIENTPIDMAPs among matched vCard instances. 2296 Property instances belonging to matched vCards, whose name is the 2297 same, and whose maximum cardinality is 1 MUST be matched. 2299 Property instances belonging to matched vCards, whose name is the 2300 same, and whose PID parameters match MUST be matched. See 2301 Section 7.1.3 for details on PID matching. 2303 In all other cases, property instances MAY be matched at the 2304 discretion of the synchronization engine. 2306 7.1.3. PID Matching 2308 Two PID values for which the first fields are equivalent represent 2309 the same local value. 2311 Two PID values representing the same local value and for which the 2312 second fields point to CLIENTPIDMAP properties whose second field 2313 URIs are equivalent (as specified in [RFC3986], Section 6) also 2314 represent the same global value. 2316 PID parameters for which at least one pair of their values represent 2317 the same global value MUST be matched. 2319 In all other cases, PID parameters MAY be matched at the discretion 2320 of the synchronization engine. 2322 For example, PID value "5.1", in the first vCard below, and PID value 2323 "5.2", in the second vCard below, represent the same global value. 2325 BEGIN:VCARD 2326 VERSION:4.0 2327 EMAIL;PID=4.2,5.1:jdoe@example.com 2328 CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2329 CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc 2330 END:VCARD 2332 BEGIN:VCARD 2333 VERSION:4.0 2334 EMAIL;PID=5.1,5.2:john@example.com 2335 CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d 2336 CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2337 END:VCARD 2339 7.2. Example 2341 7.2.1. Creation 2343 The following simple vCard is first created on a given device. 2345 BEGIN:VCARD 2346 VERSION:4.0 2347 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2348 FN;PID=1.1:J. Doe 2349 N:Doe;J.;;; 2350 EMAIL;PID=1.1:jdoe@example.com 2351 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2352 END:VCARD 2354 This new vCard is assigned the UID 2355 "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating 2356 device. The FN and EMAIL properties are assigned the same local 2357 value of 1, and this value is given global context by associating it 2358 with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which 2359 represents the creating device. We are at liberty to reuse the same 2360 local value since instances of different properties will never be 2361 matched. The N property has no PID because it is forbidden by its 2362 maximum cardinality of 1. 2364 7.2.2. Initial Sharing 2366 This vCard is shared with a second device. Upon inspecting the UID 2367 property, the second device understands that this is a new vCard 2368 (i.e. unmatched) and thus the synchronization results in a simple 2369 copy. 2371 7.2.3. Adding and Sharing a Property 2373 A new phone number is created on the first device, then the vCard is 2374 shared with the second device. This is what the second device 2375 receives: 2377 BEGIN:VCARD 2378 VERSION:4.0 2379 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2380 FN;PID=1.1:J. Doe 2381 N:Doe;J.;;; 2382 EMAIL;PID=1.1:jdoe@example.com 2383 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2384 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2385 END:VCARD 2387 Upon inspecting the UID property, the second device matches the vCard 2388 it received to the vCard that it already has stored. It then starts 2389 comparing the properties of the two vCards in same-named pairs. 2391 The FN properties are matched because the PID parameters have the 2392 same global value. Since the property value is the same, no update 2393 takes place. 2395 The N properties are matched automatically because their maximum 2396 cardinality is 1. Since the property value is the same, no update 2397 takes place. 2399 The EMAIL properties are matched because the PID parameters have the 2400 same global value. Since the property value is the same, no update 2401 takes place. 2403 The TEL property in the new vCard is not matched to any in the stored 2404 vCard because no property in the stored vCard has the same name. 2405 Therefore, this property is copied from the new vCard to the stored 2406 vCard. 2408 The CLIENTPIDMAP property is handled separately by the 2409 synchronization engine. It ensures that it is consistent with the 2410 stored one. If it was not, the results would be up to the 2411 synchronization engine, and thus undefined by this document. 2413 7.2.4. Simultaneous Editing 2415 A new email address and a new phone number are added to the vCard on 2416 each of the two devices, and then a new synchronization event 2417 happens. Here are the vCards that are communicated to each other: 2419 BEGIN:VCARD 2420 VERSION:4.0 2421 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2422 FN;PID=1.1:J. Doe 2423 N:Doe;J.;;; 2424 EMAIL;PID=1.1:jdoe@example.com 2425 EMAIL;PID=2.1:boss@example.com 2426 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2427 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2428 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2429 END:VCARD 2431 BEGIN:VCARD 2432 VERSION:4.0 2433 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2434 FN;PID=1.1:J. Doe 2435 N:Doe;J.;;; 2436 EMAIL;PID=1.1:jdoe@example.com 2437 EMAIL;PID=2.2:ceo@example.com 2438 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2439 TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666 2440 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2441 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2442 END:VCARD 2444 On the first device, the same PID source identifier (1) is reused for 2445 the new EMAIL and TEL properties. On the second device, a new source 2446 identifier (2) is generated, and a corresponding CLIENTPIDMAP 2447 property is created. It contains the second device's identifier, 2448 "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee". 2450 The new EMAIL properties are unmatched on both sides since the PID 2451 global value is new in both cases. The sync thus results in a copy 2452 on both sides. 2454 Although the situation appears to be the same for the TEL properties, 2455 in this case the synchronization engine is particularly smart and 2456 matches the two new TEL properties even though their PID global 2457 values are different. Note that in this case, the rules of section 2458 Section 7.1.2 state that two properties MAY be matched at the 2459 discretion of the synchronization engine. Therefore, the two 2460 properties are merged. 2462 All this results in the following vCard which is stored on both 2463 devices: 2465 BEGIN:VCARD 2466 VERSION:4.0 2467 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2468 FN:J. Doe 2469 N:Doe;J.;;; 2470 EMAIL;PID=1.1:jdoe@example.com 2471 EMAIL;PID=2.1:boss@example.com 2472 EMAIL;PID=2.2:ceo@example.com 2473 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2474 TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666 2475 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2476 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2477 END:VCARD 2479 7.2.5. Global Context Simplification 2481 The two devices finish their synchronization procedure by simplifying 2482 their global contexts. Since they haven't talked to any other 2483 device, the following vCard is for all purposes equivalent to the 2484 above. It is also shorter. 2486 BEGIN:VCARD 2487 VERSION:4.0 2488 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2489 FN:J. Doe 2490 N:Doe;J.;;; 2491 EMAIL;PID=1.1:jdoe@example.com 2492 EMAIL;PID=2.1:boss@example.com 2493 EMAIL;PID=3.1:ceo@example.com 2494 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2495 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2496 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2497 END:VCARD 2499 The details of global context simplification are unspecified by this 2500 document. They are left up to the synchronization engine. This 2501 example is merely intended to illustrate the possibility, which 2502 investigating would be, in the authors' opinion, worthwhile. 2504 8. Example: Authors' vCards 2506 BEGIN:VCARD 2507 VERSION:4.0 2508 FN:Simon Perreault 2509 N:Perreault;Simon;;;ing. jr,M.Sc. 2510 BDAY:--0203 2511 ANNIVERSARY:20090808T1430-0500 2512 GENDER:M 2513 LANG;PREF=1:fr 2514 LANG;PREF=2:en 2515 ORG;TYPE=work:Viagenie 2516 ADR;TYPE=work:;Suite D2-630;2875 Laurier; 2517 Quebec;QC;G1V 2M2;Canada 2518 TEL;VALUE=uri;TYPE=work,voice;PREF=1:tel:+1-418-656-9254;ext=102 2519 TEL;VALUE=uri;TYPE=work,cell,voice,video,text:tel:+1-418-262-6501 2520 EMAIL;TYPE=work:simon.perreault@viagenie.ca 2521 GEO;TYPE=work:geo:46.772673,-71.282945 2522 KEY;TYPE=work;VALUE=uri: 2523 http://www.viagenie.ca/simon.perreault/simon.asc 2524 TZ:-0500 2525 END:VCARD 2527 BEGIN:VCARD 2528 VERSION:4.0 2529 FN:Pete Resnick 2530 N:Resnick;Pete;;; 2531 GENDER:M 2532 ORG;TYPE=work:QUALCOMM Incorporated 2533 ADR;TYPE=work:;;5775 Morehouse Drive;San Diego;CA;92121-1714;US 2534 TEL;VALUE=uri;TYPE=work,voice:tel:+1-858-651-4478 2535 EMAIL;TYPE=work:presnick@qualcomm.com 2536 URL;TYPE=work:http://www.qualcomm.com/~presnick/ 2537 END:VCARD 2539 9. Security Considerations 2541 o Internet mail is often used to transport vCards and is subject to 2542 many well known security attacks, including monitoring, replay, 2543 and forgery. Care should be taken by any directory service in 2544 allowing information to leave the scope of the service itself, 2545 where any access controls can no longer be guaranteed. 2546 Applications should also take care to display directory data in a 2547 "safe" environment (e.g., PostScript-valued types). 2549 o vCards can carry cryptographic keys or certificates, as described 2550 in Section 6.8.1. 2552 o The vCard objects have no inherent authentication or privacy, but 2553 can easily be carried by any security mechanism that transfers 2554 MIME objects with authentication or privacy. In cases where the 2555 threat of "spoofed" vCard information is a concern, the vCard 2556 SHOULD BE transported using one of these secure mechanisms. 2558 o The information in a vCard may become out of date. In cases where 2559 the vitality of data is important to an originator of a vCard, the 2560 SOURCE property (Section 6.1.3) SHOULD be specified. In addition, 2561 the "REV" type described in section Section 6.7.4 can be specified 2562 to indicate the last time that the vCard data was updated. 2564 10. IANA Considerations 2566 10.1. MIME Type Registration 2568 IANA is asked to register the following MIME Media Type (in 2569 ). 2571 To: ietf-types@iana.org 2573 Subject: Registration of media type text/vcard 2575 Type name: text 2577 Subtype name: vcard 2579 Required parameters: none 2581 Optional parameters: version 2583 The "version" parameter is to be interpreted identically as the 2584 VERSION vCard property. If this parameter is present, all vCards 2585 in a text/vcard body part MUST have a VERSION property with value 2586 identical to that of this MIME parameter. 2588 "charset": as defined for text/plain [RFC2046]; encodings other 2589 than UTF-8 [RFC3629] MUST NOT be used. 2591 Encoding considerations: None. 2593 Security considerations: See Section 9. 2595 Interoperability considerations: The text/vcard media type is 2596 intended to identify vCard data of any version. There are older 2597 specifications of vCard [RFC2426][oldreference_VCARD] still in 2598 common use. While these formats are similar, they are not 2599 strictly compatible. In general, it is necessary to inspect the 2600 value of the VERSION property (see Section 6.7.9) for identifying 2601 the standard to which a given vCard object conforms. 2603 In addition, the following media types are known to have been used 2604 to refer to vCard data. They should be considered deprecated in 2605 favor of text/vcard. 2607 * text/directory 2609 * text/directory; profile=vcard 2611 * text/x-vcard 2613 Published specification: draft-ietf-vcarddav-vcardrev-15 2615 Applications that use this media type: They are numerous, diverse, 2616 and include mail user agents, instant messaging clients, address 2617 book applications, directory servers, customer relationship 2618 management software. 2620 Additional information: 2622 Magic number(s): 2624 File extension(s): .vcf 2626 Macintosh file type code(s): 2628 Person & email address to contact for further information: Simon 2629 Perreault 2631 Intended usage: COMMON 2633 Restrictions on usage: none 2635 Author: Simon Perreault and Pete Resnick 2637 Change controller: IETF 2639 10.2. Registering New vCard Elements 2641 This section defines the process for registering new or modified 2642 vCard elements (i.e. properties, parameters, value data types, and 2643 values) with IANA. It does not contain any immediate IANA actions. 2645 10.2.1. Registration Procedure 2647 The IETF will create a mailing list, vcard@ietf.org [1], which can be 2648 used for public discussion of vCard element proposals prior to 2649 registration. Use of the mailing list is strongly encouraged. The 2650 IESG will appoint a designated expert who will monitor the 2651 vcard@ietf.org [1] mailing list and review registrations. 2653 Registration of new vCard elements MUST be reviewed by the designated 2654 expert and published in an RFC. A Standard Tracks RFC is REQUIRED 2655 for the registration of new value data types that modify existing 2656 properties. A Standard Tracks RFC is also REQUIRED for registration 2657 of vCard elements that modify vCard elements previously documented in 2658 a Standard Tracks RFC. 2660 The registration procedure begins when a completed registration 2661 template, defined in the sections below, is sent to 2662 vcard@ietf.org [1] and iana@iana.org [2]. The designated expert is 2663 expected to tell IANA and the submitter of the registration within 2664 two weeks whether the registration is approved, approved with minor 2665 changes, or rejected with cause. When a registration is rejected 2666 with cause, it can be re-submitted if the concerns listed in the 2667 cause are addressed. Decisions made by the designated expert can be 2668 appealed to the IESG Applications Area Director, then to the IESG. 2669 They follow the normal appeals procedure for IESG decisions. 2671 Once the registration procedure concludes successfully, IANA creates 2672 or modifies the corresponding record in the vCard registry. The 2673 completed registration template is discarded. 2675 An RFC specifying new vCard elements MUST include the completed 2676 registration templates, which MAY be expanded with additional 2677 information. These completed templates will go in the body of the 2678 document, and SHOULD NOT be included or repeated in the IANA 2679 Considerations section. The IANA Considerations section MUST contain 2680 tables (see the tables in section Section 10.3) that show exactly the 2681 changes that IANA is requested to make to the registries. The 2682 registry's reference column MUST point to the section in the RFC 2683 containing to the completed the registration template. 2685 10.2.2. Vendor Namespace 2687 The vendor namespace is used for vCard elements associated with 2688 commercially available products. "Vendor" or "producer" are 2689 construed as equivalent and very broadly in this context. 2691 A registration may be placed in the vendor namespace by anyone who 2692 needs to interchange files associated with the particular product. 2694 However, the registration formally belongs to the vendor or 2695 organization handling the vCard elements in the namespace being 2696 registered. Changes to the specification will be made at their 2697 request, as discussed in subsequent sections. 2699 vCard elements belonging to the vendor namespace will be 2700 distinguished by the "VND-" prefix. This is followed by an IANA- 2701 registered Private Enterprise Number (PEN), a dash, and a vCard 2702 element designation of the vendor's choosing (e.g., "VND-123456- 2703 MUDPIE"). 2705 While public exposure and review of vCard elements to be registered 2706 in the vendor namespace is not required, using the vcard@ietf.org [1] 2707 mailing list for review is strongly encouraged to improve the quality 2708 of those specifications. Registrations in the vendor namespace may 2709 be submitted directly to the IANA. 2711 10.2.3. Registration Template for Properties 2713 A property is defined by completing the following template. 2715 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2716 specific property (where NNNN is replaced by the vendor's PEN). 2718 Property name: The name of the property. 2720 Purpose: The purpose of the property. Give a short but clear 2721 description. 2723 Value type: Any of the valid value types for the property value 2724 needs to be specified. The default value type also needs to be 2725 specified. 2727 Cardinality: See Section 6. 2729 Property parameters: Any of the valid property parameters for the 2730 property MUST be specified. 2732 Description: Any special notes about the property, how it is to be 2733 used, etc. 2735 Format definition: The ABNF for the property definition needs to be 2736 specified. 2738 Example(s): One or more examples of instances of the property needs 2739 to be specified. 2741 10.2.4. Registration Template for Parameters 2743 A parameter is defined by completing the following template. 2745 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2746 specific property (where NNNN is replaced by the vendor's PEN). 2748 Parameter name: The name of the parameter. 2750 Purpose: The purpose of the parameter. Give a short but clear 2751 description. 2753 Description: Any special notes about the parameter, how it is to be 2754 used, etc. 2756 Format definition: The ABNF for the parameter definition needs to be 2757 specified. 2759 Example(s): One or more examples of instances of the parameter needs 2760 to be specified. 2762 10.2.5. Registration Template for Value Data Types 2764 A value data type is defined by completing the following template. 2766 Value name: The name of the value type. 2768 Purpose: The purpose of the value type. Give a short but clear 2769 description. 2771 Description: Any special notes about the value type, how it is to be 2772 used, etc. 2774 Format definition: The ABNF for the value type definition needs to 2775 be specified. 2777 Example(s): One or more examples of instances of the value type 2778 needs to be specified. 2780 10.2.6. Registration Template for Values 2782 A value is defined by completing the following template. 2784 Value: The value literal. 2786 Purpose: The purpose of the value. Give a short but clear 2787 description. 2789 Conformance: The vCard properties and/or parameters that can take 2790 this value needs to be specified. 2792 Example(s): One or more examples of instances of the value needs to 2793 be specified. 2795 The following is a fictitious example of a registration of a vCard 2796 value: 2798 Value: supervisor 2800 Purpose: It means that the related individual is the direct 2801 hierarchical superior (i.e. supervisor or manager) of the 2802 individual this vCard represents. 2804 Conformance: This value can be used with the "TYPE" parameter 2805 applied on the "RELATED" property. 2807 Example(s): 2809 RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2811 10.3. Initial vCard Elements Registries 2813 The IANA is requested to create and maintain the following registries 2814 for vCard elements with pointers to appropriate reference documents. 2815 The registries will be grouped together under the heading "vCard 2816 Elements". 2818 10.3.1. Properties Registry 2820 The following table is to be used to initialize the properties 2821 registry. 2823 +-----------+--------------+---------+------------------------+ 2824 | Namespace | Property | Status | Reference | 2825 +-----------+--------------+---------+------------------------+ 2826 | | SOURCE | Current | RFCXXXX, Section 6.1.3 | 2827 | | KIND | Current | RFCXXXX, Section 6.1.4 | 2828 | | XML | Current | RFCXXXX, Section 6.1.5 | 2829 | | FN | Current | RFCXXXX, Section 6.2.1 | 2830 | | N | Current | RFCXXXX, Section 6.2.2 | 2831 | | NICKNAME | Current | RFCXXXX, Section 6.2.3 | 2832 | | PHOTO | Current | RFCXXXX, Section 6.2.4 | 2833 | | BDAY | Current | RFCXXXX, Section 6.2.5 | 2834 | | ANNIVERSARY | Current | RFCXXXX, Section 6.2.6 | 2835 | | GENDER | Current | RFCXXXX, Section 6.2.7 | 2836 | | ADR | Current | RFCXXXX, Section 6.3.1 | 2837 | | TEL | Current | RFCXXXX, Section 6.4.1 | 2838 | | EMAIL | Current | RFCXXXX, Section 6.4.2 | 2839 | | IMPP | Current | RFCXXXX, Section 6.4.3 | 2840 | | LANG | Current | RFCXXXX, Section 6.4.4 | 2841 | | TZ | Current | RFCXXXX, Section 6.5.1 | 2842 | | GEO | Current | RFCXXXX, Section 6.5.2 | 2843 | | TITLE | Current | RFCXXXX, Section 6.6.1 | 2844 | | ROLE | Current | RFCXXXX, Section 6.6.2 | 2845 | | LOGO | Current | RFCXXXX, Section 6.6.3 | 2846 | | ORG | Current | RFCXXXX, Section 6.6.4 | 2847 | | MEMBER | Current | RFCXXXX, Section 6.6.5 | 2848 | | RELATED | Current | RFCXXXX, Section 6.6.6 | 2849 | | CATEGORIES | Current | RFCXXXX, Section 6.7.1 | 2850 | | NOTE | Current | RFCXXXX, Section 6.7.2 | 2851 | | PRODID | Current | RFCXXXX, Section 6.7.3 | 2852 | | REV | Current | RFCXXXX, Section 6.7.4 | 2853 | | SOUND | Current | RFCXXXX, Section 6.7.5 | 2854 | | UID | Current | RFCXXXX, Section 6.7.6 | 2855 | | CLIENTPIDMAP | Current | RFCXXXX, Section 6.7.7 | 2856 | | URL | Current | RFCXXXX, Section 6.7.8 | 2857 | | VERSION | Current | RFCXXXX, Section 6.7.9 | 2858 | | KEY | Current | RFCXXXX, Section 6.8.1 | 2859 | | FBURL | Current | RFCXXXX, Section 6.9.1 | 2860 | | CALADRURI | Current | RFCXXXX, Section 6.9.2 | 2861 | | CALURI | Current | RFCXXXX, Section 6.9.3 | 2862 +-----------+--------------+---------+------------------------+ 2864 10.3.2. Parameters Registry 2866 The following table is to be used to initialize the parameters 2867 registry. 2869 +-----------+-----------+---------+-----------------------+ 2870 | Namespace | Parameter | Status | Reference | 2871 +-----------+-----------+---------+-----------------------+ 2872 | | LANGUAGE | Current | RFCXXXX, Section 5.1 | 2873 | | VALUE | Current | RFCXXXX, Section 5.2 | 2874 | | PREF | Current | RFCXXXX, Section 5.3 | 2875 | | ALTID | Current | RFCXXXX, Section 5.4 | 2876 | | PID | Current | RFCXXXX, Section 5.5 | 2877 | | TYPE | Current | RFCXXXX, Section 5.6 | 2878 | | CALSCALE | Current | RFCXXXX, Section 5.7 | 2879 | | SORT-AS | Current | RFCXXXX, Section 5.8 | 2880 | | GEO | Current | RFCXXXX, Section 5.9 | 2881 | | TZ | Current | RFCXXXX, Section 5.10 | 2882 +-----------+-----------+---------+-----------------------+ 2884 10.3.3. Value Data Types Registry 2886 The following table is to be used to initialize the parameters 2887 registry. 2889 +------------------+---------+------------------------+ 2890 | Value Data Type | Status | Reference | 2891 +------------------+---------+------------------------+ 2892 | BOOLEAN | Current | RFCXXXX, Section 4.4 | 2893 | DATE | Current | RFCXXXX, Section 4.3.1 | 2894 | TIME | Current | RFCXXXX, Section 4.3.2 | 2895 | DATE-TIME | Current | RFCXXXX, Section 4.3.3 | 2896 | DATE-AND-OR-TIME | Current | RFCXXXX, Section 4.3.4 | 2897 | TIMESTAMP | Current | RFCXXXX, Section 4.3.5 | 2898 | FLOAT | Current | RFCXXXX, Section 4.6 | 2899 | INTEGER | Current | RFCXXXX, Section 4.5 | 2900 | TEXT | Current | RFCXXXX, Section 4.1 | 2901 | URI | Current | RFCXXXX, Section 4.2 | 2902 | LANGUAGE-TAG | Current | RFCXXXX, Section 4.7 | 2903 +------------------+---------+------------------------+ 2905 10.3.4. Values Registries 2907 Separate tables will be used for property and parameter values. 2909 The following table is to be used to initialize the property values 2910 registry. 2912 +----------+------------+---------+------------------------+ 2913 | Property | Value | Status | Reference | 2914 +----------+------------+---------+------------------------+ 2915 | BEGIN | VCARD | Current | RFCXXXX, Section 6.1.1 | 2916 | END | VCARD | Current | RFCXXXX, Section 6.1.2 | 2917 | KIND | individual | Current | RFCXXXX, Section 6.1.4 | 2918 | KIND | group | Current | RFCXXXX, Section 6.1.4 | 2919 | KIND | org | Current | RFCXXXX, Section 6.1.4 | 2920 | KIND | location | Current | RFCXXXX, Section 6.1.4 | 2921 +----------+------------+---------+------------------------+ 2923 The following table is to be used to initialize the parameter values 2924 registry. 2926 +--------------+-----------+--------------+---------+---------------+ 2927 | Property | Parameter | Value | Status | Reference | 2928 +--------------+-----------+--------------+---------+---------------+ 2929 | FN, | TYPE | work | Current | RFCXXXX, | 2930 | NICKNAME, | | | | Section 5.6 | 2931 | PHOTO, ADR, | | | | | 2932 | TEL, EMAIL, | | | | | 2933 | IMPP, LANG, | | | | | 2934 | TZ, GEO, | | | | | 2935 | TITLE, ROLE, | | | | | 2936 | LOGO, ORG, | | | | | 2937 | RELATED, | | | | | 2938 | CATEGORIES, | | | | | 2939 | NOTE, SOUND, | | | | | 2940 | URL, KEY, | | | | | 2941 | FBURL, | | | | | 2942 | CALADRURI, | | | | | 2943 | and CALURI | | | | | 2944 | FN, | TYPE | home | Current | RFCXXXX, | 2945 | NICKNAME, | | | | Section 5.6 | 2946 | PHOTO, ADR, | | | | | 2947 | TEL, EMAIL, | | | | | 2948 | IMPP, LANG, | | | | | 2949 | TZ, GEO, | | | | | 2950 | TITLE, ROLE, | | | | | 2951 | LOGO, ORG, | | | | | 2952 | RELATED, | | | | | 2953 | CATEGORIES, | | | | | 2954 | NOTE, SOUND, | | | | | 2955 | URL, KEY, | | | | | 2956 | FBURL, | | | | | 2957 | CALADRURI, | | | | | 2958 | and CALURI | | | | | 2959 | TEL | TYPE | text | Current | RFCXXXX, | 2960 | | | | | Section 6.4.1 | 2961 | TEL | TYPE | voice | Current | RFCXXXX, | 2962 | | | | | Section 6.4.1 | 2963 | TEL | TYPE | fax | Current | RFCXXXX, | 2964 | | | | | Section 6.4.1 | 2965 | TEL | TYPE | cell | Current | RFCXXXX, | 2966 | | | | | Section 6.4.1 | 2967 | TEL | TYPE | video | Current | RFCXXXX, | 2968 | | | | | Section 6.4.1 | 2969 | TEL | TYPE | pager | Current | RFCXXXX, | 2970 | | | | | Section 6.4.1 | 2971 | BDAY, | CALSCALE | gregorian | Current | RFCXXXX, | 2972 | ANNIVERSARY | | | | Section 6.2.5 | 2973 | RELATED | TYPE | contact | Current | RFCXXXX, | 2974 | | | | | Section 6.6.6 | 2975 | | | | | and [xfn] | 2976 | RELATED | TYPE | acquaintance | Current | RFCXXXX, | 2977 | | | | | Section 6.6.6 | 2978 | | | | | and [xfn] | 2979 | RELATED | TYPE | friend | Current | RFCXXXX, | 2980 | | | | | Section 6.6.6 | 2981 | | | | | and [xfn] | 2982 | RELATED | TYPE | met | Current | RFCXXXX, | 2983 | | | | | Section 6.6.6 | 2984 | | | | | and [xfn] | 2985 | RELATED | TYPE | co-worker | Current | RFCXXXX, | 2986 | | | | | Section 6.6.6 | 2987 | | | | | and [xfn] | 2988 | RELATED | TYPE | colleague | Current | RFCXXXX, | 2989 | | | | | Section 6.6.6 | 2990 | | | | | and [xfn] | 2991 | RELATED | TYPE | co-resident | Current | RFCXXXX, | 2992 | | | | | Section 6.6.6 | 2993 | | | | | and [xfn] | 2994 | RELATED | TYPE | neighbor | Current | RFCXXXX, | 2995 | | | | | Section 6.6.6 | 2996 | | | | | and [xfn] | 2997 | RELATED | TYPE | child | Current | RFCXXXX, | 2998 | | | | | Section 6.6.6 | 2999 | | | | | and [xfn] | 3000 | RELATED | TYPE | parent | Current | RFCXXXX, | 3001 | | | | | Section 6.6.6 | 3002 | | | | | and [xfn] | 3003 | RELATED | TYPE | sibling | Current | RFCXXXX, | 3004 | | | | | Section 6.6.6 | 3005 | | | | | and [xfn] | 3006 | RELATED | TYPE | spouse | Current | RFCXXXX, | 3007 | | | | | Section 6.6.6 | 3008 | | | | | and [xfn] | 3009 | RELATED | TYPE | kin | Current | RFCXXXX, | 3010 | | | | | Section 6.6.6 | 3011 | | | | | and [xfn] | 3012 | RELATED | TYPE | muse | Current | RFCXXXX, | 3013 | | | | | Section 6.6.6 | 3014 | | | | | and [xfn] | 3015 | RELATED | TYPE | crush | Current | RFCXXXX, | 3016 | | | | | Section 6.6.6 | 3017 | | | | | and [xfn] | 3018 | RELATED | TYPE | date | Current | RFCXXXX, | 3019 | | | | | Section 6.6.6 | 3020 | | | | | and [xfn] | 3021 | RELATED | TYPE | sweetheart | Current | RFCXXXX, | 3022 | | | | | Section 6.6.6 | 3023 | | | | | and [xfn] | 3024 | RELATED | TYPE | me | Current | RFCXXXX, | 3025 | | | | | Section 6.6.6 | 3026 | | | | | and [xfn] | 3027 | RELATED | TYPE | agent | Current | RFCXXXX, | 3028 | | | | | Section 6.6.6 | 3029 | RELATED | TYPE | emergency | Current | RFCXXXX, | 3030 | | | | | Section 6.6.6 | 3031 +--------------+-----------+--------------+---------+---------------+ 3033 11. Acknowledgements 3035 The authors would like to thank Tim Howes, Mark Smith, and Frank 3036 Dawson, the original authors of [RFC2425] and [RFC2426], Pete 3037 Resnick, who got this effort started and provided help along the way, 3038 as well as the following individuals who have participated in the 3039 drafting, review and discussion of this memo: 3041 Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil 3042 Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie 3043 Hoeneisen, Bjoern Hoehrmann, Caleb Richarson, Chris Bryant, Chris 3044 Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale, 3045 Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian 3046 Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens, 3047 Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke, 3048 Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga. Lisa Dusseault, 3049 Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike 3050 Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter 3051 Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane 3052 Bortzmeyer, Tantek Celik, and Zoltan Ordogh. 3054 12. References 3056 12.1. Normative References 3058 [CCITT.E163.1988] International Telephone and Telegraph 3059 Consultative Committee, "Numbering Plan 3060 for the International Telephone 3061 Service", CCITT Recommendation E.163, 3062 1988. 3064 [CCITT.X121.1988] International Telephone and Telegraph 3065 Consultative Committee, "International 3066 Numbering Plan for the Public Data 3067 Networks", CCITT Recommendation X.121, 3068 1988. 3070 [CCITT.X520.1988] International International Telephone 3071 and Telegraph Consultative Committee, 3072 "Information Technology - Open Systems 3073 Interconnection - The Directory: 3074 Selected Attribute Types", 3075 CCITT Recommendation X.520, 3076 November 1988. 3078 [CCITT.X521.1988] International International Telephone 3079 and Telegraph Consultative Committee, 3080 "Information Technology - Open Systems 3081 Interconnection - The Directory: 3082 Selected Object Classes", 3083 CCITT Recommendation X.521, 3084 November 1988. 3086 [I-D.ietf-vcarddav-vcardxml] Perreault, S., "vCard XML 3087 Representation", 3088 draft-ietf-vcarddav-vcardxml-06 (work 3089 in progress), December 2010. 3091 [ISO.8601.2000] International Organization for 3092 Standardization, "Data elements and 3093 interchange formats - Information 3094 interchange - Representation of dates 3095 and times", ISO Standard 8601, 3096 December 2000. 3098 [ISO.8601.2004] International Organization for 3099 Standardization, "Data elements and 3100 interchange formats - Information 3101 interchange - Representation of dates 3102 and times", ISO Standard 8601, 3103 December 2004. 3105 [RFC2046] Freed, N. and N. Borenstein, 3106 "Multipurpose Internet Mail Extensions 3107 (MIME) Part Two: Media Types", 3108 RFC 2046, November 1996. 3110 [RFC2119] Bradner, S., "Key words for use in RFCs 3111 to Indicate Requirement Levels", 3112 BCP 14, RFC 2119, March 1997. 3114 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A 3115 MIME Content-Type for Directory 3116 Information", RFC 2425, September 1998. 3118 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 3119 Directory Profile", RFC 2426, 3120 September 1998. 3122 [RFC2739] Small, T., Hennessy, D., and F. Dawson, 3123 "Calendar Attributes for vCard and 3124 LDAP", RFC 2739, January 2000. 3126 [RFC3629] Yergeau, F., "UTF-8, a transformation 3127 format of ISO 10646", STD 63, RFC 3629, 3128 November 2003. 3130 [RFC3966] Schulzrinne, H., "The tel URI for 3131 Telephone Numbers", RFC 3966, 3132 December 2004. 3134 [RFC3986] Berners-Lee, T., Fielding, R., and L. 3135 Masinter, "Uniform Resource Identifier 3136 (URI): Generic Syntax", STD 66, 3137 RFC 3986, January 2005. 3139 [RFC4122] Leach, P., Mealling, M., and R. Salz, 3140 "A Universally Unique IDentifier (UUID) 3141 URN Namespace", RFC 4122, July 2005. 3143 [RFC4770] Jennings, C. and J. Reschke, Ed., 3144 "vCard Extensions for Instant Messaging 3145 (IM)", RFC 4770, January 2007. 3147 [RFC5234] Crocker, D. and P. Overell, "Augmented 3148 BNF for Syntax Specifications: ABNF", 3149 STD 68, RFC 5234, January 2008. 3151 [RFC5322] Resnick, P., Ed., "Internet Message 3152 Format", RFC 5322, October 2008. 3154 [RFC5646] Phillips, A. and M. Davis, "Tags for 3155 Identifying Languages", BCP 47, 3156 RFC 5646, September 2009. 3158 [RFC5870] Mayrhofer, A. and C. Spanring, "A 3159 Uniform Resource Identifier for 3160 Geographic Locations ('geo' URI)", 3161 RFC 5870, June 2010. 3163 [oldreference_VCARD] Internet Mail Consortium, "vCard - The 3164 Electronic Business Card Version 2.1", 3165 September September. 3167 [xfn] Celik, T., Mullenweg, M., and E. Meyer, 3168 "XHTML Friends Network 1.1", 3169 . 3171 12.2. Informative References 3173 [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., Crocker, D., and 3174 N. Freed, "Internationalized Email 3175 Headers", draft-ietf-eai-rfc5335bis-09 3176 (work in progress), March 2011. 3178 [ISO9070] The International Organization for 3179 Standardization, "ISO 9070, Information 3180 Processing - SGML support facilities - 3181 Registration Procedures for Public Text 3182 Owner Identifiers", April 1991. 3184 [RFC2616] Fielding, R., Gettys, J., Mogul, J., 3185 Frystyk, H., Masinter, L., Leach, P., 3186 and T. Berners-Lee, "Hypertext Transfer 3187 Protocol -- HTTP/1.1", RFC 2616, 3188 June 1999. 3190 [RFC3406] Daigle, L., van Gulik, D., Iannella, 3191 R., and P. Faltstrom, "Uniform Resource 3192 Names (URN) Namespace Definition 3193 Mechanisms", BCP 66, RFC 3406, 3194 October 2002. 3196 [RFC5545] Desruisseaux, B., "Internet Calendaring 3197 and Scheduling Core Object 3198 Specification (iCalendar)", RFC 5545, 3199 September 2009. 3201 [RFC5546] Daboo, C., "iCalendar Transport- 3202 Independent Interoperability Protocol 3203 (iTIP)", RFC 5546, December 2009. 3205 [TZ-DB] Olson, A., "Time zone code and data", 3206 . 3208 URIs 3210 [1] 3212 [2] 3214 Appendix A. Differences from RFCs 2425 and 2426 3216 This appendix contains a list of changes that have been made in the 3217 vCard specification from RFCs 2425 and 2426. 3219 A.1. New Structure 3221 o [RFC2425] and [RFC2426] have been merged. 3223 o vCard is now not only a MIME type but a stand-alone format. 3225 o A proper MIME type registration form has been included. 3227 o UTF-8 is now the default character set. 3229 o New vCard elements can be registered from IANA. 3231 o Expanded text on character set. 3233 A.2. Removed Features 3235 o The CONTEXT and CHARSET parameters are no more. 3237 o The NAME, MAILER, LABEL, and CLASS properties are no more. 3239 o The "intl", "dom", "postal", and "parcel" TYPE parameter values 3240 for the ADR property have been removed. 3242 o Inline vCards (such as the value of the AGENT property) are no 3243 longer supported. 3245 o In the N property, each component may now contain multiple comma- 3246 separated values. 3248 A.3. New Properties and Parameters 3250 o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP 3251 properties have been added. 3253 o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI 3254 properties, has been merged in. 3256 o [RFC4770], which defines the IMPP property, has been merged in. 3258 o The "work", "home", and "uri" TYPE parameter values for the EMAIL 3259 property have been added. 3261 o The "pref" value of the TYPE parameter is now a parameter of its 3262 own, with a positive integer value indicating the level of 3263 preference. 3265 o The ALTID and PID parameters have been added. 3267 A.4. Other Changes 3269 o Synchronization is addressed in Section 7. 3271 o The N property is no longer mandatory. 3273 o The value of TEL is now a URI. 3275 o The AGENT property was replaced with a type of RELATED. 3277 o Date and time values now only support the basic format. 3278 Truncation is now supported. 3280 Appendix B. Change Log (to be removed by RFC Editor prior to 3281 publication) 3283 B.1. Changes in -16 3285 o RELATED: Added XFN values into IANA registry. 3287 o RELATED: Added values "agent" and "emergency". 3289 o EMAIL is now free-form text, with informative reference to EAI. 3291 o GENDER now has two components: one for biological sex, the other 3292 for gender identity. 3294 o Bugfixes to the core ABNF. 3296 o Clarified IANA considerations. 3298 o UID may be reset to free-form text. 3300 B.2. Changes in -15 3302 o Reverted N to the 5-component format of vCard 3. 3304 o Removed DDAY, BIRTH, and DEATH. 3306 o First two components in ADR SHOULD be empty. 3308 o Removed the LABEL property. 3310 o Removed the binary value type and the ENCODING and FMTTYPE 3311 parameters. 3313 o Renamed SEX to GENDER. Set predefined values to "male" and 3314 "female". 3316 o Reverted TEL to take a text value by default, but SHOULD be reset 3317 to a URI. 3319 o Refer to iCalendar for CALSCALE. 3321 o Removed the "thing" value for KIND. 3323 o RELATED now uses XFN 1.1 for its value. 3325 o Dropped the VERSION parameter. XML MUST be version 1.0. 3327 o Dropped the CLASS property. 3329 o Property and parameter names SHOULD be upper-case. 3331 o Use ABNF for cardinality notation. 3333 B.3. Changes in -14 3335 o DQUOTE is US-ASCII decimal 34, not 22. 3337 o Removed unused reference to RFC 2046. 3339 o Updated reference to draft-ietf-vcarddav-vcardxml. 3341 o Small fixes to the IANA registration text. 3343 o Added notes on the usage of TEL and IMPP properties. 3345 o Clarified "country name" component of ADR property. 3347 o Removed usage of undefined type value "msg" in TEL example. 3349 o Fixed parameter value quoting rules and ABNF. 3351 o Added example to LANGUAGE property. 3353 o Fixed synchronization example regarding the cardinality of FN. 3355 o Added implementation note for float value type. 3357 o Removed advice for always including VALUE parameter. 3359 o FMTTYPE MUST include the full MIME type. 3361 o Made ADR's ABNF more verbose. 3363 o Organized TEL TYPE values in a table. 3365 o Replaced TOP-SECRET example with NOINDEX. 3367 B.4. Changes in -13 3369 o Changed global ABNF to make explicit that VERSION comes first. 3371 o Reworked example for LANGUAGE property. 3373 o s/TYPE/FMTTYPE/ in two examples. 3375 o Allow LANGUAGE parameter for text-valued BDAY, DDAY, and RELATED. 3377 o Tightened language on LANGUAGE parameter regarding cardinality. 3379 o Removed the NAME property. 3381 o Adjusted semi-colon escaping rules. 3383 o Added the ALTID parameter. 3385 B.5. Changes in -12 3387 o Fixed example of LANGUAGE cardinality. 3389 o Added note about YYYY-MM date format. 3391 o Fixed appendix A. 3393 o VERSION property must come first. 3395 o Fixed mistake in PID example. 3397 o Removed two changes from Appendix A which were probably intended 3398 to go into this change log section. 3400 o Explicitly state that the value for the BEGIN and END properties 3401 is case-insensitive. 3403 o Removed the SORT-STRING property. Created the SORT-AS parameter. 3405 o "T" and "Z" in dates and times are now mandatory uppercase. 3407 o Added the "version" MIME parameter. 3409 o More consistent capitalization. 3411 o Added missing "ANNIVERSARY" in name production rule. 3413 o Added missing calscale-param in param production rule. 3415 o Moved definition of GEO and TZ parameters to section 5. 3417 o Simplified discussion of encoding. 3419 o Removed restriction for "work" and "home" values of TYPE parameter 3420 w.r.t. the KIND property. 3422 o XML value may now be binary. 3424 o Created VERSION parameter for XML. 3426 o BIRTH and DEATH can now have URI values. 3428 o Created the FMTTYPE parameter. 3430 o KEY can now take a text value. 3432 o Added references to RFC 5545 (iCalendar). 3434 o Added namespace column in parameters registry. 3436 B.6. Changes in -11 3438 o Change "XML chunk" to "XML fragment". 3440 o Cite W3C document containing definition of "fragment". 3442 o Added "XML" to property name ABNF. 3444 o Clarified newline escaping rule. 3446 o Replaced one remaining "type" with "property". 3448 o Removed case insensitivity of parameter values. 3450 o XML property can now only contain one element that is not in the 3451 vCard 4 namespace. 3453 o Clarified interrelationship between LANGUAGE, cardinality, and 3454 PID. 3456 o Added "textphone" TEL type. 3458 o Fixed quoting of comma in ORG examples. 3460 B.7. Changes in -10 3462 o Added component in SORT-STRING for sorting by given name. Fixed 3463 and expanded the examples. 3465 o Fixed KIND-value ABNF. 3467 o Fixed deprecated media type. 3469 o Created the CALSCALE parameter. 3471 o Strenghtened the stance on character set. 3473 o Defined the Language-Tag ABNF. 3475 o Made explicit the fact that IANA does not register templates. 3477 o Created the XML property. 3479 o Added social networking examples to URL property. 3481 B.8. Changes in -09 3483 o Removed special meaning for groups. Removed the "work" and "home" 3484 groups. Removed the group registry. Re-introduced the "work" and 3485 "home" TYPE parameter values. Applied the TYPE parameter to 3486 properties which supported the "work" and "home" groups. 3488 o Vendor namespace now uses private enterprise number in prefix. 3490 o Added "thing" value for KIND property. 3492 B.9. Changes in -08 3494 o Allow 1985 (year only) in date ABNF. 3496 o Fixed missing country in ADR example. 3498 o Added the DATE-AND-OR-TIME value. 3500 o Made BDAY and DDAY use DATE-AND-OR-TIME. 3502 o Prefixed "param" and "value" production rules specific to 3503 properties with the property name. 3505 o Replaced the GENDER property with the SEX property. 3507 o Added the ANNIVERSARY property. 3509 o Added the "friend" and "spouse" types of RELATED. 3511 o TZ property now has text / uri value. 3513 o Refined the definitions of TITLE and ROLE. 3515 B.10. Changes in -07 3517 o PREF is now bounded. 100 is the maximum value. 3519 o Added the "emergency" RELATED type. 3521 o Made GEO a URI. 3523 o Added GEO and TZ parameters to ADR. 3525 o Changed wording of "default" use of SOUND property. 3527 o Completely reworked the date, time, and date-time grammars. 3529 o Added the timestamp value type. 3531 o REV now has the timestamp value type. 3533 o Rewrote ABNF. 3535 o ORG can now have a single level. 3537 B.11. Changes in -06 3539 o Corrected omission of resetability to text value for RELATED. 3541 o Let KEY value type be reset to a URI value. 3543 o ABNF fixes. 3545 o Made gender values extensible. 3547 o Gave the PREF parameter a positive integer value. 3549 o Removed usage of the undefined "word" ABNF production rule. 3551 o Defined property cardinalities. 3553 o Defined properties allowable in WORK and HOME groups. 3555 o Simplified the LANG property to use the vCard preference 3556 mechanism. 3558 o Created the "language-tag" value type. 3560 o Added PID to ABNF of SOURCE allowed parameters. 3562 o Clarified escaping rules. 3564 o Changed ABNF definition of non-standard X- properties. 3566 o Removed TYPE parameter from EMAIL properties in examples. 3568 o Created the CLIENTPIDMAP property. 3570 o Changed PID value to a pair of small integers. 3572 o Completely reworked synchronization mechanisms. 3574 o Created brand new synchronization example. 3576 B.12. Changes in -05 3578 o Added multi PID value proposal. 3580 B.13. Changes in -04 3582 o Added "location" value for KIND property. 3584 o Some fixes to ABNF. 3586 o Moved "pref" from being a TYPE value to a parameter in its own 3587 right. 3589 o Removed the "work" and "home" TYPE values. 3591 o Reintroduced the group construct. 3593 o Assigned meaning to WORK and HOME groups. 3595 o Restricted the TEL TYPE parameter value set. 3597 o In N property, removed additional names, and replaced with 3598 multiple given names. 3600 o Removed TYPE parameter from EMAIL and IMPP properties. 3602 o Replaced AGENT with a type of RELATED. 3604 o Use example.org domain in URL example. 3606 o Created initial IANA table of values. 3608 o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL. 3610 B.14. Changes in -03 3612 o Various changes to the synchronization mechanisms. 3614 o Allowed truncated format for dated. See issue #236. 3616 B.15. Changes in -02 3618 o Removed useless text in IMPP description. 3620 o Added CalDAV-SCHED example to CALADRURI. 3622 o Removed CAPURI property. 3624 o Dashes in dates and colons in times are now mandatory. 3626 o Allow for dates such as 2008 and 2008-05 and times such as 07 and 3627 07:54. 3629 o Removed inline vCard value. 3631 o Made AGENT only accept URI references instead of inline vCards. 3633 o Added the MEMBER property. 3635 o Renamed the UID parameter to PID. 3637 o Changed the value type of the PID parameter to "a small integer." 3639 o Changed the presence of UID and PID when synchronization is to be 3640 used from MUST to SHOULD. 3642 o Added the RELATED (Section 6.6.6) property. 3644 o Fixed many ABNF typos (issue #252). 3646 o Changed formatting of ABNF comments to make them easier to read 3647 (issue #226). 3649 B.16. Changes in -01 3651 o Merged [RFC2739] in. 3653 o Converted all foobar.com, abc.com, etc. to example.com. 3655 o Fixed bugs in ABNF. 3657 o Made explicit that coordinates in the GEO property are expressed 3658 in the WGS 84 reference system. 3660 o Clarified folding issues with multi-byte characters. 3662 o Made the value of TEL a URI. 3664 o Added the UID parameter. 3666 o Made the UID property's value type a URI. 3668 o Added Section 7. 3670 o Created IANA process for registering new parameters, value types, 3671 and properties. 3673 o Created the initial IANA registries. 3675 o Created vendor namespace based on text from RFC 4288. 3677 B.17. Changes in -00 3679 o Name change because draft has been accepted as WG item. 3680 Otherwise, same as draft-resnick-vcarddav-vcardrev-01. 3682 o Removed reference to RFC 2234. 3684 o Fixed errata from 3685 http://www.rfc-editor.org/errata_search.php?rfc=2426. 3687 o Removed passage referring to RFC 2425 profiles. 3689 o Renamed Section 6.4 from "Telecommunications Adressing Properties" 3690 to "Communications Properties. 3692 o Added Appendix A and Appendix B. 3694 o Added reference to [RFC4770]. 3696 o Removed the group construct. 3698 o Made the N property no longer mandatory. 3700 o Added the KIND property. 3702 o Clarified meaning of TYPE parameter value for PHOTO, LOGO, KEY, 3703 and SOUND. 3705 o Removed the CONTEXT parameter. 3707 o Removed the MAILER property. 3709 o Made reference to [ISO9070] informative. 3711 o Removed "intl", "dom", "postal", and "parcel" TYPE parameter 3712 values for the ADR and LABEL properties. 3714 o Clarified meaning of "extended address" ADR field. 3716 o Mentioned [RFC3406] as another method of generating PRODID values. 3718 o Updated obsolete references. 3720 o Allowed BDAY and DDAY value types to be text values for fuzzy 3721 dates. 3723 o Removed the CHARSET property. Now the encoding is always UTF-8, 3724 except when overridden by the Content-Type (which is considered a 3725 compatibility feature). 3727 Author's Address 3729 Simon Perreault 3730 Viagenie 3731 2875 Laurier, suite D2-630 3732 Quebec, QC G1V 2M2 3733 Canada 3735 Phone: +1 418 656 9254 3736 EMail: simon.perreault@viagenie.ca 3737 URI: http://www.viagenie.ca