idnits 2.17.1 draft-ietf-vcarddav-vcardrev-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 511 has weird spacing: '... month day...' == Line 515 has weird spacing: '... month day...' == Line 516 has weird spacing: '... month day...' == Line 518 has weird spacing: '... month day...' == Line 524 has weird spacing: '... = hour minut...' (Using the creation date from RFC2739, updated by this document, for RFC5378 checks: 1998-08-14) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 2009) is 5462 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) == Unused Reference: 'RFC2978' is defined on line 2974, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2425 (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 4770 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 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 P. Resnick 5 (if approved) QUALCOMM Incorporated 6 Updates: 2739 (if approved) May 6, 2009 7 Intended status: Standards Track 8 Expires: November 7, 2009 10 vCard Format Specification 11 draft-ietf-vcarddav-vcardrev-07 13 Status of This Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on November 7, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document defines the vCard data format for representing and 60 exchanging a variety of information about an individual (e.g., 61 formatted and structured name and delivery addresses, email address, 62 multiple telephone numbers, photograph, logo, audio clips, etc.). 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. MIME Type Registration . . . . . . . . . . . . . . . . . . . . 6 69 4. vCard Format Specification . . . . . . . . . . . . . . . . . . 7 70 4.1. Line Delimiting and Folding . . . . . . . . . . . . . . . 8 71 4.2. ABNF Format Definition . . . . . . . . . . . . . . . . . . 9 72 4.3. Property Value Escaping . . . . . . . . . . . . . . . . . 11 73 5. Property Value Data Types . . . . . . . . . . . . . . . . . . 11 74 5.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.3. DATE, TIME, DATE-TIME, and TIMESTAMP . . . . . . . . . . . 14 77 5.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 15 80 5.3.4. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 15 81 5.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 5.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 5.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.7. BINARY . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5.8. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 16 86 5.9. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 17 87 6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 17 88 6.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.2. ENCODING . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.3. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 6.4. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 6.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 6.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 7. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 20 95 7.1. General Properties . . . . . . . . . . . . . . . . . . . . 21 96 7.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 21 97 7.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 7.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 22 99 7.1.4. NAME . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 7.1.5. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 7.2. Identification Properties . . . . . . . . . . . . . . . . 24 102 7.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 7.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 7.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 25 105 7.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 26 106 7.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 7.2.6. DDAY . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 7.2.7. BIRTH . . . . . . . . . . . . . . . . . . . . . . . . 28 109 7.2.8. DEATH . . . . . . . . . . . . . . . . . . . . . . . . 28 110 7.2.9. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 29 111 7.3. Delivery Addressing Properties . . . . . . . . . . . . . . 29 112 7.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 29 113 7.3.2. LABEL . . . . . . . . . . . . . . . . . . . . . . . . 31 114 7.4. Communications Properties . . . . . . . . . . . . . . . . 31 115 7.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 7.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 32 117 7.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 33 118 7.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 33 119 7.5. Geographical Properties . . . . . . . . . . . . . . . . . 34 120 7.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 34 121 7.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 34 122 7.6. Organizational Properties . . . . . . . . . . . . . . . . 35 123 7.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 35 124 7.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 35 125 7.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 36 126 7.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 37 127 7.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 38 128 7.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 39 129 7.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 40 130 7.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 40 131 7.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 40 132 7.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 41 133 7.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 41 134 7.7.5. SORT-STRING . . . . . . . . . . . . . . . . . . . . . 42 135 7.7.6. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 43 136 7.7.7. UID . . . . . . . . . . . . . . . . . . . . . . . . . 43 137 7.7.8. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 44 138 7.7.9. URL . . . . . . . . . . . . . . . . . . . . . . . . . 45 139 7.7.10. VERSION . . . . . . . . . . . . . . . . . . . . . . . 45 140 7.8. Security Properties . . . . . . . . . . . . . . . . . . . 46 141 7.8.1. CLASS . . . . . . . . . . . . . . . . . . . . . . . . 46 142 7.8.2. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 47 143 7.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 47 144 7.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 47 145 7.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 48 146 7.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 49 147 7.10. Extended Properties and Parameters . . . . . . . . . . . . 49 148 8. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 49 149 8.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 49 150 8.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 50 151 8.1.2. Matching Property Instances . . . . . . . . . . . . . 50 152 8.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 50 153 8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 51 154 8.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 51 155 8.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 51 156 8.2.3. Adding and Sharing a Property . . . . . . . . . . . . 52 157 8.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 52 158 8.2.5. Global Context Simplification . . . . . . . . . . . . 54 159 9. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 55 160 10. Security Considerations . . . . . . . . . . . . . . . . . . . 55 161 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 162 11.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 56 163 11.2. Registering New vCard Elements . . . . . . . . . . . . . . 56 164 11.2.1. Registration Procedure . . . . . . . . . . . . . . . . 56 165 11.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 57 166 11.2.3. Registration Template for Groups . . . . . . . . . . . 57 167 11.2.4. Registration Template for Properties . . . . . . . . . 58 168 11.2.5. Registration Template for Parameters . . . . . . . . . 58 169 11.2.6. Registration Template for Value Data Types . . . . . . 59 170 11.2.7. Registration Template for Values . . . . . . . . . . . 59 171 11.3. Initial vCard Elements Registries . . . . . . . . . . . . 60 172 11.3.1. Groups Registry . . . . . . . . . . . . . . . . . . . 60 173 11.3.2. Properties Registry . . . . . . . . . . . . . . . . . 60 174 11.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 62 175 11.3.4. Value Data Types Registry . . . . . . . . . . . . . . 62 176 11.3.5. Values Registries . . . . . . . . . . . . . . . . . . 62 177 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 178 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 179 13.1. Normative References . . . . . . . . . . . . . . . . . . . 64 180 13.2. Informative References . . . . . . . . . . . . . . . . . . 66 181 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 67 182 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 67 183 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 67 184 A.3. New Properties and Parameters . . . . . . . . . . . . . . 67 185 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 68 186 Appendix B. Change Log (to be removed by RFC Editor prior to 187 publication) . . . . . . . . . . . . . . . . . . . . 68 188 B.1. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 68 189 B.2. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 68 190 B.3. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 69 191 B.4. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 69 192 B.5. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 70 193 B.6. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 70 194 B.7. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 71 195 B.8. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 71 197 1. Introduction 199 Note: This draft contains much of the same text as 2425 and 2426 200 which may not be correct. Those two RFCs have been merged and the 201 structure of this draft is what's new. Some vCard-specific 202 suggestions have been added, but for the most part this is still very 203 open. But we'd like to get feedback on the structure mostly so that 204 it may be fixed. 206 Electronic address books have become ubiquitous. Their increased 207 presense on portable, connected devices as well as the diversity of 208 platforms exchanging contact data call for a standard. This memo 209 defines the vCard format, which allows the capture and exchange of 210 information normally stored within an address book or directory 211 application. 213 2. Conventions 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 3. MIME Type Registration 221 To: ietf-types@iana.org 223 Subject: Registration of media type text/vcard 225 Type name: text 227 Subtype name: vcard 229 Required parameters: none 231 Optional parameters: charset 233 Encoding considerations: The "charset" MIME parameter is interpreted 234 as defined in [RFC2046], section 4.1.2. If it is omitted, the 235 default encoding is UTF-8 as defined in [RFC3629]. 237 Security considerations: See Section 10. 239 Interoperability considerations: The text/vcard media type is 240 intended to identify vCard data of any version. There are older 241 specifications of vCard [RFC2426][oldreference_VCARD] still in 242 common use. While these formats are similar, they are not 243 strictly compatible. In general, it is necessary to inspect the 244 value of the VERSION property (see Section 7.7.10) for identifying 245 the standard to which a given vCard object conforms. 247 In addition, the following media types are known to have been used 248 to refer to vCard data. They should be considered deprecated in 249 favor of text/vcard. 251 * text/directory 253 * text/directory; type=vcard 255 * text/x-vcard 257 Published specification: draft-ietf-vcarddav-vcardrev-07 259 Applications that use this media type: They are numerous, diverse, 260 and include mail user agents, instant messaging clients, address 261 book applications, directory servers, customer relationship 262 management software, etc. 264 Additional information: 266 Magic number(s): 268 File extension(s): .vcf 270 Macintosh file type code(s): 272 Person & email address to contact for further information: Simon 273 Perreault 275 Intended usage: COMMON 277 Restrictions on usage: none 279 Author: Simon Perreault and Pete Resnick 281 Change controller: IETF 283 4. vCard Format Specification 285 The text/vcard MIME content type (hereafter known as "vCard") 286 contains contact information, typically pertaining to a single 287 contact or group of contacts. The content consists of one or more 288 lines in the format given below. 290 4.1. Line Delimiting and Folding 292 Individual lines within vCard are delimited by the [RFC5322] line 293 break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII 294 decimal 10). Long logical lines of text can be split into a 295 multiple-physical-line representation using the following folding 296 technique. Content lines SHOULD be folded to a maximum width of 75 297 octets. Multi-octet characters MUST remain contiguous. The 298 rationale for this folding process can be found in [RFC5322], Section 299 2.1.1. 301 A logical line MAY be continued on the next physical line anywhere 302 between two characters by inserting a CRLF immediately followed by a 303 single white space character (space, ASCII decimal 32, or horizontal 304 tab, ASCII decimal 9). At least one character must be present on the 305 folded line. Any sequence of CRLF followed immediately by a single 306 white space character is ignored (removed) when processing the 307 content type. For example the line: 309 DESCRIPTION:This is a long description that exists on a long line. 311 can be represented as: 313 DESCRIPTION:This is a long description 314 that exists on a long line. 316 It could also be represented as: 318 DESCRIPTION:This is a long descrip 319 tion that exists o 320 n a long line. 322 The process of moving from this folded multiple-line representation 323 of a property definition to its single line representation is called 324 unfolding. Unfolding is accomplished by regarding CRLF immediately 325 followed by a white space character (namely HTAB ASCII decimal 9 or 326 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., 327 the CRLF and single white space character are removed). 329 Note: It is possible for very simple implementations to generate 330 improperly folded lines in the middle of a UTF-8 multi-octet 331 sequence. For this reason, implementations SHOULD unfold lines in 332 such a way as to properly restore the original sequence. 334 Note: Unfolding is done differently than in [RFC5322]. Unfolding 335 in [RFC5322] only removes the CRLF, not the space following it. 337 Folding is done after any content encoding of a type value. 339 Unfolding is done before any decoding of a type value in a content 340 line. 342 4.2. ABNF Format Definition 344 The following ABNF uses the notation of [RFC5234], which also defines 345 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. 347 vcard-entity = 1*(vcard) 349 vcard = "BEGIN" ":" "VCARD" CRLF 350 1*contentline 351 "END" ":" "VCARD" CRLF 352 ;A vCard object MUST include the VERSION and FN properties. 354 contentline = [group "."] name *(";" param) ":" value CRLF 355 ; When parsing a content line, folded lines MUST first 356 ; be unfolded according to the unfolding procedure 357 ; described above. 358 ; When generating a content line, lines longer than 75 359 ; characters SHOULD be folded according to the folding 360 ; procedure described above. 362 group = "WORK" / "HOME" / iana-token / x-name 363 name = "SOURCE" / "NAME" / "KIND" / "FN" / "N" / "NICKNAME" 364 / "PHOTO" / "BDAY" / "DDAY" / "BIRTH" / "DEATH" / "GENDER" 365 / "ADR" / "LABEL" / "TEL" / "EMAIL" / "IMPP" / "LANG" 366 / "TZ" / "GEO" / "TITLE" / "ROLE" / "LOGO" / "ORG" / "MEMBER" 367 / "RELATED" / "CATEGORIES" / "NOTE" / "PRODID" / "REV" 368 / "SORT-STRING" / "SOUND" / "UID" / "CLIENTPIDMAP" / "URL" 369 / "VERSION" / "CLASS" / "KEY" / "FBURL" / "CALADRURI" 370 / "CALURI" / iana-token / x-name 371 ; Parsing of the param and value is based on the "name" as 372 ; defined in ABNF sections below. 373 ; Group and name are case-insensitive. 375 iana-token = 1*(ALPHA / DIGIT / "-") 376 ; identifier registered with IANA 378 x-name = "x-" 1*(ALPHA / DIGIT / "-") 379 ; Names that begin with "x-" or "X-" are 380 ; reserved for experimental use, not intended for released 381 ; products, or for use in bilateral agreements. 383 param = language-param / encoding-param / value-param / pref-param 384 / pid-param / type-param / geo-param / tz-param / any-param 385 ; Allowed parameters depend on property name. 387 param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE 389 any-param = (iana-token / x-name) "=" param-value 391 NON-ASCII = %x80-FF 392 ; Use is restricted by charset parameter 393 ; on outer MIME object (UTF-8 by default) 395 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII 396 ; Any character except CTLs, DQUOTE 398 SAFE-CHAR = WSP / %x21 / %x23-39 / %x3C-7E / NON-ASCII 399 ; Any character except CTLs, DQUOTE, ";", ":" 401 VALUE-CHAR = WSP / VCHAR / NON-ASCII 402 ; Any textual character 404 A line that begins with a white space character is a continuation of 405 the previous line, as described above. The white space character and 406 immediately preceeding CRLF should be discarded when reconstructing 407 the original line. Note that this line-folding convention differs 408 from that found in [RFC5322], in that the sequence found 409 anywhere in the content indicates a continued line and should be 410 removed. 412 Property names and parameter names are case insensitive (e.g., the 413 property name "fn" is the same as "FN" and "Fn"). Parameter values 414 MAY be case sensitive or case insensitive, depending on their 415 definition. 417 The group construct is used to group related properties together. 418 For example, groups named "WORK" and "HOME" could be used to 419 segregate properties such as telephone number, address, etc. 420 Displaying of groups is left entirely up to the application. 421 Predefined groups with assigned meaning are listed in Section 11.3.1. 422 It is possible to register new groups from IANA. Unregistered groups 423 MAY be used and MUST start with "X-". 425 Properties defined in a vCard instance may have multiple values 426 depending on the property cardinality. The general rule for encoding 427 multi-valued properties is to simply create a new content line for 428 each value (including the property name). However, it should be 429 noted that some value types support encoding multiple values in a 430 single content line by separating the values with a comma ",". This 431 approach has been taken for several of the content types defined 432 below (date, time, integer, float), for space-saving reasons. 434 4.3. Property Value Escaping 436 A property instance may contain one or more values delimited by a 437 COMMA character (ASCII decimal 44). Therefore, a COMMA character in 438 a value MUST be escaped with a BACKSLASH character (ASCII decimal 439 92), even for properties that don't allow multiple instances (for 440 consistency). 442 Some properties (e.g. N and ADR) comprise multiple fields delimited 443 by a SEMI-COLON character (ASCII decimal 59). Therefore, a SEMI- 444 COLON in a field of such a "compound" property MUST be escaped with a 445 BACKSLASH character. SEMI-COLON characters in non-compound 446 properties MUST NOT be escaped. 448 Furthermore, some fields of compound properties may contain a list of 449 values delimited by a COMMA character. Therefore, a COMMA character 450 in one of a field's values MUST be escaped with a BACKSLASH 451 character, even for fields that don't allow multiple values (for 452 consistency). Compound properties allowing multiple instances MUST 453 NOT be encoded in a single content line. 455 Finally, newline (ASCII decimal 10) and backslash (ASCII decimal 92) 456 characters in values MUST be escaped by prefixing them with a 457 backslash character. 459 In all other cases, escaping MUST NOT be used. 461 5. Property Value Data Types 463 Standard value types are defined below. 465 value = text 466 / text-list 467 / date-list 468 / time-list 469 / date-time-list 470 / timestamp-list 471 / boolean 472 / integer-list 473 / float-list 474 / binary 475 / utc-offset 476 / URI ; from Appendix A of [RFC3986] 477 / iana-valuespec 478 ; Actual value type depends on property name and VALUE parameter. 480 text = *VALUE-CHAR 481 text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR) 483 TEXT-LIST-CHAR = "\\" / "\," / "\n" 484 / 485 ; Backslashes, commas, and newlines must be encoded. 487 date-list = date *("," date) 488 time-list = time *("," time) 489 date-time-list = date-time *("," date-time) 490 timestamp-list = timestamp *("," timestamp) 491 integer-list = integer *("," integer) 492 float-list = float *("," float) 494 boolean = "TRUE" / "FALSE" 495 integer = [sign] 1*DIGIT 496 float = [sign] 1*DIGIT ["." 1*DIGIT] 498 sign = "+" / "-" 500 binary = 503 year = 4DIGIT ; 0000-9999 504 month = 2DIGIT ; 01-12 505 day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year 506 hour = 2DIGIT ; 00-23 507 minute = 2DIGIT ; 00-59 508 second = 2DIGIT ; 00-58/59/60 depending on leap second 509 zone = "Z" / utc-offset 511 date = year month day 512 / year "-" month 513 / "--" month [day] 514 / "--" "-" day 515 date-noreduc = year month day 516 / "--" month day 517 / "--" "-" day 518 date-complete = year month day 520 time = hour [minute [second]] [zone] 521 / "-" minute [second] [zone] 522 / "-" "-" second [zone] 523 time-notrunc = hour [minute [second]] [zone] 524 time-complete = hour minute second [zone] 526 date-time = date-noreduc "T" time-notrunc 527 timestamp = date-complete "T" time-complete 528 utc-offset = sign hour [minute] 530 iana-valuespec = 534 5.1. TEXT 536 "text": The "text" value type should be used to identify values that 537 contain human-readable text. The character set in which the text is 538 represented is controlled by the "charset" MIME type parameter. Note 539 that there is no way to override this parameter on a per-property 540 basis. As for the language, it is controlled by the "language" 541 property parameter defined in Section 6.1. 543 Examples for "text": 545 this is a text value 546 this is one value,this is another 547 this is a single value\, with a comma encoded 549 A formatted text line break in a text value type MUST be represented 550 as the character sequence backslash (ASCII decimal 92) followed by a 551 Latin small letter n (ASCII decimal 110) or a Latin capital letter N 552 (ASCII decimal 78), that is "\n" or "\N". 554 For example a multiple line DESCRIPTION value of: 556 Mythical Manager 557 Hyjinx Software Division 558 BabsCo, Inc. 560 could be represented as: 562 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n 563 BabsCo\, Inc.\n 565 demonstrating the \n literal formatted line break technique, the 566 CRLF-followed-by-space line folding technique, and the backslash 567 escape technique. 569 5.2. URI 571 "uri": The "uri" value type should be used to identify values that 572 are referenced by a URI (including a Content-ID URI), instead of 573 encoded in-line. These value references might be used if the value 574 is too large, or otherwise undesirable to include directly. The 575 format for the URI is as defined in [RFC3986]. Note that the value 576 of a property of type "uri" is what the URI points to, not the URI 577 itself. 579 Examples for "uri": 581 http://www.example.com/my/picture.jpg 582 ldap://ldap.example.com/cn=babs%20jensen 584 5.3. DATE, TIME, DATE-TIME, and TIMESTAMP 586 "date", "time", "date-time", and "timestamp": Each of these value 587 types is based on a the definitions in [ISO.8601.2004] standard. 588 Multiple such values can be specified using the comma-separated 589 notation. 591 Only the basic format is supported. 593 5.3.1. DATE 595 A calendar date as specified in [ISO.8601.2004] section 4.1.2. 597 Reduced accuracy, as specified in [ISO.8601.2004] sections 4.1.2.3 a) 598 and b), but not c), is permitted. 600 Expanded representation, as specified in [ISO.8601.2004] section 601 4.1.4, is forbidden. 603 Truncated representation, as specified in [ISO.8601.2000] sections 604 5.2.1.3 d), e), and f), is permitted. 606 Examples for "date": 608 19850412 609 1985-04 610 1985 611 --0412 612 ---12 614 5.3.2. TIME 616 A time of day as specified in [ISO.8601.2004] section 4.2. 618 Reduced accuracy, as specified in [ISO.8601.2004] section 4.2.2.3, is 619 permitted. 621 Representation with decimal fraction, as specified in [ISO.8601.2004] 622 section 4.2.2.4, is forbidden. 624 Midnight is always represented by 00, never 24 (see [ISO.8601.2004] 625 section 4.2.3). 627 Truncated representation, as specified in [ISO.8601.2000] sections 628 5.3.1.4 a), b), and c), is permitted. 630 Examples for "time": 632 102200 633 1022 634 10 635 -2200 636 --00 637 102200Z 638 102200-0800 640 5.3.3. DATE-TIME 642 A date and time of day combination as specified in [ISO.8601.2004] 643 section 4.3. 645 Truncation of the date part, as specified in [ISO.8601.2000] section 646 5.4.2 c), is permitted. 648 Examples for "date-time": 650 19961022T140000 651 --1022T1400 652 ---22T14 654 5.3.4. TIMESTAMP 656 A complete date and time of day combination as specified in 657 [ISO.8601.2004] section 4.3.2. 659 Examples for "timestamp": 661 19961022T140000 662 19961022T140000Z 663 19961022T140000-05 664 19961022T140000-0500 666 5.4. BOOLEAN 668 "boolean": The "boolean" value type is used to express boolen values. 669 These values are case insensitive. 671 Examples: 673 TRUE 674 false 675 True 677 5.5. INTEGER 679 "integer": The "integer" value type is used to express signed 680 integers in decimal format. If sign is not specified, the value is 681 assumed positive "+". Multiple "integer" values can be specified 682 using the comma-separated notation. 684 Examples: 686 1234567890 687 -1234556790 688 +1234556790,432109876 690 5.6. FLOAT 692 "float": The "float" value type is used to express real numbers. If 693 sign is not specified, the value is assumed positive "+". Multiple 694 "float" values can be specified using the comma-separated notation. 696 Examples: 698 20.30 699 1000000.0000001 700 1.333,3.14 702 5.7. BINARY 704 "binary": The "binary" value type specifies that the type value is 705 inline, encoded binary data. This value type can be specified in the 706 PHOTO, LOGO, SOUND, and KEY types. 708 If inline encoded binary data is specified, the ENCODING type 709 parameter MUST be used to specify the encoding format. The binary 710 data MUST be encoded using the "B" encoding format. Long lines of 711 encoded binary data SHOULD BE folded to 75 characters using the 712 folding method defined in Section 4.1. 714 5.8. UTC-OFFSET 716 "utc-offset": The "utc-offset" value type specifies that the type 717 value is a signed offset from UTC. This value type can be specified 718 in the TZ type. 720 The value type is an offset from Coordinated Universal Time (UTC). 721 It is specified as a positive or negative difference in units of 722 hours and minutes (e.g., +hhmm). The time is specified as a 24-hour 723 clock. Hour values are from 00 to 23, and minute values are from 00 724 to 59. Hour and minutes are 2-digits with high order zeroes required 725 to maintain digit count. The basic format for ISO 8601 UTC offsets 726 MUST be used. 728 5.9. LANGUAGE-TAG 730 "language-tag": A single language tag, as defined in [RFC4646]. 732 6. Property Parameters 734 A property can have attributes associated with it. These "property 735 parameters" contain meta-information about the property or the 736 property value. 738 Property parameter values that contain the COLON (US-ASCII decimal 739 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) 740 character separators MUST be specified as quoted-string text values. 741 Property parameter values MUST NOT contain the DQUOTE (US-ASCII 742 decimal 22) character. The DQUOTE (US-ASCII decimal 22) character is 743 used as a delimiter for parameter values that contain restricted 744 characters or URI text. For example: 746 EMAIL;PID=8:jdoe@example.com 748 Property parameter values that are not in quoted strings are case 749 insensitive. 751 Applications MUST ignore x-param and iana-param value they don't 752 recognize. 754 6.1. LANGUAGE 756 The "language" property parameter is used to identify data in 757 multiple languages. There is no concept of "default" language, 758 except as specified by any "Content-Language" MIME header parameter 759 that is present. The value of the "language" property parameter is a 760 language tag as defined in Section 2 of [RFC4646]. 762 ABNF: 764 language-param = "LANGUAGE=" Language-Tag 765 ; Language-Tag is defined in section 2.1 of RFC 4646 767 6.2. ENCODING 769 The "encoding" property parameter is used to specify an alternate 770 encoding for a value. If the value contains a CRLF, it must be 771 encoded, since CRLF is used to separate lines in the content-type 772 itself. Currently, only the "b" encoding is supported. 774 The "b" encoding can also be useful for binary values that are mixed 775 with other text information in the body part (e.g., a certificate). 776 Using a per-value "b" encoding in this case leaves the other 777 information in a more readable form. The encoded base 64 value can 778 be split across multiple physical lines by using the line folding 779 technique described above. 781 The Content-Transfer-Encoding header field is used to specify the 782 encoding used for the body part as a whole. The "encoding" property 783 parameter is used to specify an encoding for a particular value 784 (e.g., a certificate). In this case, the Content-Transfer-Encoding 785 header might specify "8bit", while the one certificate value might 786 specify an encoding of "b" via an "encoding=b" property parameter. 788 The Content-Transfer-Encoding and the encodings of individual 789 properties given by the "encoding" property parameter are independent 790 of one another. When encoding a text/vcard body part for 791 transmission, individual property encodings are performed first, then 792 the entire body part is encoded according to the Content-Transfer- 793 Encoding. When decoding a text/vcard body part, the Content- 794 Transfer-Encoding is decoded first, and then any individual 795 properties with an "encoding" property parameter are decoded. 797 ABNF: 799 encoding-param = "ENCODING=" encoding-type 801 encoding-type = "b" ; from [RFC2047] 802 / iana-token ; registered as in section 12 804 6.3. VALUE 806 The "value" parameter is optional, and is used to identify the value 807 type (data type) and format of the value. The use of these 808 predefined formats is encouraged even if the value parameter is not 809 explicity used. By defining a standard set of value types and their 810 formats, existing parsing and processing code can be leveraged. The 811 predefined data type values MUST NOT be repeated in COMMA separated 812 value lists except within the N, NICKNAME, ADR and CATEGORIES 813 properties. 815 Including the value type explicitly as part of each property provides 816 an extra hint to keep parsing simple and support more generalized 817 applications. For example a search engine would not have to know the 818 particular value types for all of the items for which it is 819 searching. Because the value type is explicit in the definition, the 820 search engine could look for dates in any item type and provide 821 results that can still be interpreted. 823 ABNF: 825 value-param = "VALUE=" value-type 827 value-type = "text" 828 / "uri" 829 / "date" 830 / "time" 831 / "date-time" 832 / "timestamp" 833 / "boolean" 834 / "integer" 835 / "float" 836 / "binary" 837 / "utc-offset" 838 / "language-tag" 839 / iana-token ; registered as described in section 12 840 / x-name 842 6.4. PREF 844 The "pref" parameter is optional, and is used to indicate that the 845 corresponding instance of a property is preferred by the vCard 846 author. Its value MUST be an integer between 1 and 100 that 847 quantifies the level of preferredness. Lower values correspond to a 848 higher level of preferrredness, 1 being most preferred. 850 When the parameter is absent, the default MUST be to interpret the 851 property instance as being least preferred. 853 Note that the value of this parameter is to be interpreted only in 854 relation to values assigned to other instances of the same property 855 in the same vCard. A given value, or the absence of a value, MUST 856 NOT be interpreted on its own. 858 This parameter MAY be applied to any property that allows multiple 859 instances. 861 ABNF: 863 pref-param = "PREF=" (1*2DIGIT / "100") 865 6.5. PID 867 The "pid" parameter is used to identify a specific property among 868 multiple instances. It plays a role analogous to the UID property 869 (Section 7.7.7) on a per-property instead of per-vCard basis. It MAY 870 appear more than once in a given property. It MUST NOT appear on 871 properties that only may have one instance per vCard. Its value is 872 either a single small integer, or a pair of small integers separated 873 by a dot. Multiple values may be encoded in a single PID parameter 874 by separating the values with a comma ",". See Section 8 for more 875 details on its usage. 877 ABNF: 879 pid-param = "PID=" pid-value *("," pid-value) 880 pid-value = 1*DIGIT ["." 1*DIGIT] 882 6.6. TYPE 884 The "type" parameter has multiple, different uses. In general, it is 885 a way of specifying class characteristics of the associated property. 886 Most of the time, its value is a comma-separated subset of a pre- 887 defined enumeration. In this document, the following properties make 888 use of this parameter: PHOTO, ADR, LABEL, TEL, EMAIL, IMPP, LOGO, 889 MEMBER, SOUND, and KEY. 891 ABNF: 893 type-param= = "TYPE=" type-value *("," type-value) 895 type-value = type-value-tel / type-value-related 896 / iana-token / x-name 897 ; This is further defined in individual property sections. 899 7. vCard Properties 901 What follows is an enumeration of the standard vCard properties. 903 Property cardinalities are indicated using the following notation: 905 +-------------+--------------------------------------------------+ 906 | Cardinality | Meaning | 907 +-------------+--------------------------------------------------+ 908 | (1,1) | Exactly one instance per vCard MUST be present. | 909 | (0,1) | Exactly one instance per vCard MAY be present. | 910 | (1,n) | One or more instances per vCard MUST be present. | 911 | (0,n) | One or more instances per vCard MAY be present. | 912 +-------------+--------------------------------------------------+ 914 7.1. General Properties 916 7.1.1. BEGIN 918 Purpose: To denote the beginning of a syntactic entity within a 919 text/vcard content-type. 921 Value type: text 923 Cardinality: (1,1) 925 Special notes: The content entity MUST begin with the BEGIN property 926 with a value of "VCARD". 928 The BEGIN property is used in conjunction with the END property to 929 delimit an entity containing a related set of properties within an 930 text/vcard content-type. This construct can be used instead of or 931 in addition to wrapping separate sets of information inside 932 additional MIME headers. It is provided for applications that 933 wish to define content that can contain multiple entities within 934 the same text/vcard content-type or to define content that can be 935 identifiable outside of a MIME environment. 937 ABNF: 939 param = ; no parameter allowed 940 value = "VCARD" 942 Example: 944 BEGIN:VCARD 946 7.1.2. END 948 Purpose: To denote the end of a syntactic entity within a text/vcard 949 content-type. 951 Value type: text 953 Cardinality: (1,1) 955 Special notes: The content entity MUST end with the END type with a 956 value of "VCARD". 958 The END property is used in conjunction with the BEGIN property to 959 delimit an entity containing a related set of properties within an 960 text/vcard content-type. This construct can be used instead of or 961 in addition to wrapping separate sets of information inside 962 additional MIME headers. It is provided for applications that 963 wish to define content that can contain multiple entities within 964 the same text/vcard content-type or to define content that can be 965 identifiable outside of a MIME environment. 967 ABNF: 969 param = ; no parameter allowed 970 value = "VCARD" 972 Example: 974 END:VCARD 976 7.1.3. SOURCE 978 Purpose: To identify the source of directory information contained 979 in the content type. 981 Value type: uri 983 Cardinality: (0,n) 985 Special notes: The SOURCE property is used to provide the means by 986 which applications knowledgable in the given directory service 987 protocol can obtain additional or more up-to-date information from 988 the directory service. It contains a URI as defined in [RFC3986] 989 and/or other information referencing the vCard to which the 990 information pertains. When directory information is available 991 from more than one source, the sending entity can pick what it 992 considers to be the best source, or multiple SOURCE properties can 993 be included. 995 ABNF: 997 param = "VALUE=uri" / pid-param / pref-param / any-param 998 value = uri 1000 Examples: 1002 SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US 1004 SOURCE:http://directory.example.com/addressbooks/jdoe/ 1005 Jean%20Dupont.vcf 1007 7.1.4. NAME 1009 Purpose: To identify the displayable name of the directory entity to 1010 which information in the vCard pertains. 1012 Value type: text 1014 Cardinality: (0,1) 1016 Special notes: The NAME property is used to convey the display name 1017 of the entity to which the directory information pertains. Its 1018 value is the displayable, presentation text associated with the 1019 source for the vCard, as specified in the SOURCE property. 1021 ABNF: 1023 param = "VALUE=text" / any-param 1024 value = text 1026 Example: 1028 NAME:Babs Jensen's Contact Information 1030 7.1.5. KIND 1032 Purpose: To specify the kind of object the vCard represents. 1034 Value type: A single text value. 1036 Cardinality: (0,1) 1038 Special notes: The value may be one of: "individual" for a single 1039 person, "group" for a group of people, "org" for an organization, 1040 "location" for a named geographical place, an x-name or an iana- 1041 token. If this property is absent, "individual" MUST be assumed 1042 as default. 1044 ABNF: 1046 param = "VALUE=text" / any-param 1047 value = "individual" / "group" / "org" / "location" 1048 / iana-token / x-name 1050 Example: 1052 This represents someone named Jane Doe working in the marketing 1053 department of the North American division of ABC Inc. 1055 BEGIN:VCARD 1056 VERSION:4.0 1057 KIND:individual 1058 FN:Jane Doe 1059 ORG:ABC\, Inc.;North American Division;Marketing 1060 END:VCARD 1062 This represents the department itself, commonly known as ABC 1063 Marketing. 1065 BEGIN:VCARD 1066 VERSION:4.0 1067 KIND:org 1068 FN:ABC Marketing 1069 ORG:ABC\, Inc.;North American Division;Marketing 1070 END:VCARD 1072 7.2. Identification Properties 1074 These types are used to capture information associated with the 1075 identification and naming of the person or resource associated with 1076 the vCard. 1078 7.2.1. FN 1080 Purpose: To specify the formatted text corresponding to the name of 1081 the object the vCard represents. 1083 Value type: A single text value. 1085 Cardinality: (1,n) 1087 Special notes: This property is based on the semantics of the X.520 1088 Common Name attribute. The property MUST be present in the vCard 1089 object. 1091 ABNF: 1093 param = "VALUE=text" / language-param / pid-param / pref-param 1094 / any-param 1095 value = text 1097 Example: 1099 FN:Mr. John Q. Public\, Esq. 1101 7.2.2. N 1103 Purpose: To specify the components of the name of the object the 1104 vCard represents. 1106 Value type: A single structured text value. Each component can have 1107 multiple values. 1109 Cardinality: (0,1) 1111 Special note: The structured property value corresponds, in 1112 sequence, to the Surname, Given Names, Honorific Prefixes, and 1113 Honorific Suffixes. The text components are separated by the 1114 SEMI-COLON character (ASCII decimal 59). Individual text 1115 components can include multiple text values (e.g., multiple 1116 Additional Names) separated by the COMMA character (ASCII decimal 1117 44). This property is based on the semantics of the X.520 1118 individual name attributes. The property SHOULD be present in the 1119 vCard object when the name of the object the vCard represents 1120 follows the X.520 model. 1122 ABNF: 1124 param = "VALUE=text" / language-param / any-param 1125 value = list-component 3(";" list-component) 1127 list-component = list-component-value *("," list-component-value) 1128 list-component-value = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII 1129 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E 1131 Examples: 1133 N:Public;John,Q.;Mr.;Esq. 1135 N:Stevenson;John,Philip,Paul;Dr.;Jr.,M.D.,A.C.P. 1137 7.2.3. NICKNAME 1139 Purpose: To specify the text corresponding to the nickname of the 1140 object the vCard represents. 1142 Value type: One or more text values separated by a COMMA character 1143 (ASCII decimal 44). 1145 Cardinality: (0,n) 1147 Special note: The nickname is the descriptive name given instead of 1148 or in addition to the one belonging to a person, place, or thing. 1149 It can also be used to specify a familiar form of a proper name 1150 specified by the FN or N properties. 1152 ABNF: 1154 param = "VALUE=text" / language-param / pid-param / pref-param 1155 / any-param 1156 value = text-list 1158 Examples: 1160 NICKNAME:Robbie 1162 NICKNAME:Jim,Jimmie 1164 WORK.NICKNAME:Boss 1166 7.2.4. PHOTO 1168 Purpose: To specify an image or photograph information that 1169 annotates some aspect of the object the vCard represents. 1171 Encoding: The encoding MUST be reset to "b" using the ENCODING 1172 parameter in order to specify inline, encoded binary data. If the 1173 value is referenced by a URI value, then the default encoding is 1174 used and no explicit ENCODING parameter is needed. 1176 Value type: A single value. The default is binary value. It can 1177 also be reset to uri value. The uri value can be used to specify 1178 a value outside of this MIME entity. 1180 Cardinality: (0,n) 1182 Special notes: This property SHOULD include the parameter "TYPE" to 1183 specify the graphic image format type. The TYPE parameter value 1184 MUST be an image media type as specified in [RFC4288]. The full 1185 media type name, including the "image/" prefix, should be used. 1186 However, implementations SHOULD be able to handle bare subtypes. 1188 ABNF: 1190 param = inline-param / refer-param 1191 value = inline-value / refer-value 1192 ; Value and parameter MUST match. 1194 param =/ pid-param / pref-param / any-param 1196 inline-param = "VALUE=binary" 1197 / encoding-param 1198 / "TYPE=" type-name "/" subtype-name 1199 ; from [RFC4288] section 4.2 1200 inline-value = binary 1202 refer-param = "VALUE=uri" 1203 refer-value = uri 1205 Example: 1207 PHOTO;VALUE=uri:http://www.example.com/pub/photos 1208 /jqpublic.gif 1210 PHOTO;ENCODING=b;TYPE=image/jpeg:MIICajCCAdOgAwIBAgICBEUwDQYJKo 1211 ZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENv 1212 bW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbi 1213 <...remainder of "B" encoded binary data...> 1215 7.2.5. BDAY 1217 Purpose: To specify the birth date of the object the vCard 1218 represents. 1220 Value type: The default is a single date value. It can also be 1221 reset to a single date-time or text value. 1223 Cardinality: (0,1) 1225 ABNF: 1227 param = "VALUE=" ("date" / "date-time" / "text") 1228 value = date / date-time / text 1229 ; Value and parameter MUST match. 1231 param =/ any-param 1233 Examples: 1235 BDAY:19960415 1236 BDAY:--0415 1237 BDAY;VALUE=date-time:19531015T231000Z 1238 BDAY;VALUE=text:circa 1800 1240 7.2.6. DDAY 1242 Purpose: To specify the date of death of the object the vCard 1243 represents. 1245 Value type: The default is a single date value. It can also be 1246 reset to a single date-time or text value. 1248 Cardinality: (0,1) 1250 ABNF: 1252 param = "VALUE=" ("date" / "date-time" / "text") 1253 value = date / date-time / text 1254 ; Value and parameter MUST match. 1256 param =/ any-param 1258 7.2.7. BIRTH 1260 Purpose: To specify the place of birth of the object the vCard 1261 represents. 1263 Value type: A single text value. 1265 Cardinality: (0,1) 1267 ABNF: 1269 param = "VALUE=text" / language-param / any-param 1270 value = text 1272 Example: 1274 BIRTH:Babies'R'Us Hospital 1276 7.2.8. DEATH 1277 Purpose: To specify the place of death of the object the vCard 1278 represents. 1280 Value type: A single text value. 1282 Cardinality: (0,1) 1284 ABNF: 1286 param = "VALUE=text" / language-param / any-param 1287 value = text 1289 Example: 1291 DEATH:Aboard the Titanic\, near Newfoundland 1293 7.2.9. GENDER 1295 Purpose: To specify the gender of the object the vCard represents. 1297 Value type: A single text value. 1299 Cardinality: (0,1) 1301 Special notes: The value "M" stands for male while "F" stands for 1302 female. IANA-registered values and x-names are also allowed. 1304 ABNF: 1306 param = "VALUE=text" / any-param 1307 value = "M" / "F" / iana-token / x-name 1309 Example: 1311 GENDER:F 1313 7.3. Delivery Addressing Properties 1315 These types are concerned with information related to the delivery 1316 addressing or label for the vCard object. 1318 7.3.1. ADR 1320 Purpose: To specify the components of the delivery address for the 1321 vCard object. 1323 Value type: A single structured text value, separated by the SEMI- 1324 COLON character (ASCII decimal 59). 1326 Cardinality: (0,n) 1328 Special notes: The structured type value consists of a sequence of 1329 address components. The component values MUST be specified in 1330 their corresponding position. The structured type value 1331 corresponds, in sequence, to the post office box; the extended 1332 address (e.g. apartment or suite number); the street address; the 1333 locality (e.g., city); the region (e.g., state or province); the 1334 postal code; the country name. When a component value is missing, 1335 the associated component separator MUST still be specified. 1337 The text components are separated by the SEMI-COLON character 1338 (ASCII decimal 59). Where it makes semantic sense, individual 1339 text components can include multiple text values (e.g., a "street" 1340 component with multiple lines) separated by the COMMA character 1341 (ASCII decimal 44). 1343 The property can include the "PREF" parameter to indicate the 1344 preferred delivery address when more than one address is 1345 specified. 1347 The GEO parameter can be used to indicate global positioning 1348 information that is specific to this address. Its value is the 1349 same as that of the GEO property. 1351 The TZ parameter can be used to indicate time zone information 1352 that is specific to this address. Its value is the same as that 1353 of the TZ property. 1355 ABNF: 1357 param = "VALUE=text" / language-param / geo-param / tz-param 1358 / pid-param / pref-param / any-param 1359 value = list-component 6(";" list-component) 1361 geo-param = "GEO=" DQUOTE uri DQUOTE 1362 tz-param = "TZ=" utc-offset 1364 Example: In this example the post office box and the extended address 1365 are absent. 1367 ADR;GEO="geo:12.3457,78.910":;;123 Main Street;Any Town;CA 1368 ;91921-1234 1370 7.3.2. LABEL 1372 Purpose: To specify the formatted text corresponding to delivery 1373 address of the object the vCard represents. 1375 Value type: A single text value. 1377 Cardinality: (0,n) 1379 Special notes: The property value is formatted text that can be used 1380 to present a delivery address label for the vCard object. The 1381 property can include the "PREF" parameter to indicate the 1382 preferred delivery address when more than one address is 1383 specified. 1385 ABNF: 1387 param = "VALUE=text" / language-param / pid-param / pref-param 1388 / any-param 1389 value = text 1391 Example: A multi-line address label. 1393 LABEL:Mr.John Q. Public\, Esq.\nMail Drop: TNE QB\n 1394 123 Main Street\nAny Town\, CA 91921-1234\nU.S.A. 1396 7.4. Communications Properties 1398 These properties are concerned with information associated with the 1399 way communications with the object the vCard represents are carried 1400 out. 1402 7.4.1. TEL 1404 Purpose: To specify the telephone number for telephony communication 1405 with the object the vCard represents. 1407 Value type: A single URI value. It is expected that the URI scheme 1408 will be "tel", as specified in [RFC3966], but other schemes MAY be 1409 used. 1411 Cardinality: (0,n) 1413 Special notes: This property is based on the X.520 Telephone Number 1414 attribute. 1416 The property can include the "PREF" parameter to indicate a 1417 prefered-use telephone number. 1419 The property can include the parameter "TYPE" to specify intended 1420 use for the telephone number. The TYPE parameter values can 1421 include: "text" to indicate the telephone number supports text 1422 messages, "voice" to indicate a voice telephone number, "fax" to 1423 indicate a facsimile telephone number, "cell" to indicate a 1424 cellular telephone number, "video" to indicate a video 1425 conferencing telephone number, "pager" to indicate a paging device 1426 telephone number. The default type is "voice". These type 1427 parameter values can be specified as a parameter list (i.e., 1428 "TYPE=text;TYPE=voice") or as a value list (i.e., 1429 "TYPE=text,voice"). The default can be overridden to another set 1430 of values by specifying one or more alternate values. For 1431 example, the default TYPE of "voice" can be reset to a VOICE and 1432 FAX telephone number by the value list "TYPE=voice,fax". 1434 ABNF: 1436 param = "VALUE=uri" / type-param / pid-param / pref-param 1437 / any-param 1438 value = uri 1440 type-value-tel = "text" / "voice" / "fax" / "cell" / "video" 1441 / "pager" / iana-token / x-name 1443 Example: 1445 WORK.TEL;PREF=1;TYPE=voice,msg:tel:+1-555-555-5555;ext=5555 1446 HOME.TEL:tel:+33-01-23-45-67 1448 7.4.2. EMAIL 1450 Purpose: To specify the electronic mail address for communication 1451 with the object the vCard represents. 1453 Value type: A single text value. 1455 Cardinality: (0,n) 1457 Special notes: The property can include tye "PREF" parameter to 1458 indicate a preferred-use email address when more than one is 1459 specified. 1461 ABNF: 1463 param = "VALUE=text" / pid-param / pref-param / any-param 1464 value = addr-spec ; from [RFC5322] section 3.4.1 1466 Type example: 1468 WORK.EMAIL:jqpublic@xyz.example.com 1470 EMAIL;PREF=1:jane_doe@example.com 1472 7.4.3. IMPP 1474 Purpose: To specify the URI for instant messaging and presence 1475 protocol communications with the object the vCard represents. 1477 Value type: A single URI. 1479 Cardinality: (0,n) 1481 Special notes: The property may include the "PREF" parameter to 1482 indicate that this is a preferred address and has the same 1483 semantics as the "PREF" parameter in a TEL property. 1485 ABNF: 1487 param = "VALUE=uri" / pid-param / pref-param / any-param 1488 value = uri 1490 Example: 1492 IMPP;PREF=1:xmpp:alice@example.com 1494 7.4.4. LANG 1496 Purpose: To specify the language(s) that may be used for contacting 1497 the individual associated with the vCard. 1499 Value type: A single language-tag value. 1501 Cardinality: (0,n) 1503 ABNF: 1505 param = "VALUE=language-tag" / pid-param / pref-param / any-param 1506 value = Language-Tag 1508 Example: 1510 WORK.LANG;PREF=1:en 1511 WORK.LANG;PREF=2:fr 1512 HOME.LANG=fr 1514 7.5. Geographical Properties 1516 These properties are concerned with information associated with 1517 geographical positions or regions associated with the object the 1518 vCard represents. 1520 7.5.1. TZ 1522 Purpose: To specify information related to the time zone of the 1523 object the vCard represents. 1525 Value type: The default is a single utc-offset value. It can also 1526 be reset to a single text value. 1528 Cardinality: (0,n) 1530 Special notes: The type value consists of a single value. 1532 ABNF: 1534 param = "VALUE=" ("utc-offset" / "text") 1535 value = utc-offset / text 1536 ; Value and parameter must match 1538 param =/ pid-param / pref-param / any-param 1540 Type examples: 1542 TZ:-0500 1544 TZ;VALUE=text:-0500; EST; Raleigh/North America 1545 ;This example has a single value, not a structure text value. 1547 7.5.2. GEO 1549 Purpose: To specify information related to the global positioning of 1550 the object the vCard represents. 1552 Value type: A single URI. 1554 Cardinality: (0,n) 1556 Special notes: The "geo" URI scheme [I-D.mayrhofer-geo-uri] is 1557 particularly well-suited for this property, but other schemes MAY 1558 be used. 1560 ABNF: 1562 param = "VALUE=uri" / pid-param / pref-param / any-param 1563 value = uri 1565 Example: 1567 GEO:geo:37.386013,-122.082932 1569 7.6. Organizational Properties 1571 These properties are concerned with information associated with 1572 characteristics of the organization or organizational units of the 1573 object the vCard represents. 1575 7.6.1. TITLE 1577 Purpose: To specify the job title, functional position or function 1578 of the object the vCard represents. 1580 Value type: A single text value. 1582 Cardinality: (0,n) 1584 Special notes: This property is based on the X.520 Title attribute. 1586 ABNF: 1588 param = "VALUE=text" / language-param / pid-param / pref-param 1589 / any-param 1590 value = text 1592 Example: 1594 TITLE:Director\, Research and Development 1596 7.6.2. ROLE 1597 Purpose: To specify information concerning the role, occupation, or 1598 business category of the object the vCard represents. 1600 Value type: A single text value. 1602 Cardinality: (0,n) 1604 Special notes: This property is based on the X.520 Business Category 1605 explanatory attribute. This property is included as an 1606 organizational type to avoid confusion with the semantics of the 1607 TITLE property and incorrect usage of that property when the 1608 semantics of this property is intended. 1610 ABNF: 1612 param = "VALUE=text" / language-param / pid-param / pref-param 1613 / any-param 1614 value = text 1616 Example: 1618 ROLE:Programmer 1620 7.6.3. LOGO 1622 Purpose: To specify a graphic image of a logo associated with the 1623 object the vCard represents. 1625 Encoding: The encoding MUST be reset to "b" using the ENCODING 1626 parameter in order to specify inline, encoded binary data. If the 1627 value is referenced by a URI value, then the default encoding of 1628 8bit is used and no explicit ENCODING parameter is needed. 1630 Value type: A single value. The default is binary value. It can 1631 also be reset to uri value. The uri value can be used to specify 1632 a value outside of this MIME entity. 1634 Cardinality: (0,n) 1636 Special notes: This property SHOULD include the parameter "TYPE" to 1637 specify the graphic image format type. The TYPE parameter value 1638 MUST be an image media type as specified in [RFC4288]. The full 1639 media type name, including the "image/" prefix, should be used. 1640 However, implementations SHOULD be able to handle bare subtypes. 1642 ABNF: 1644 param = inline-param / refer-param 1645 value = inline-value / refer-value 1646 ; Value and parameter MUST match. 1648 param =/ language-param / pid-param / pref-param / any-param 1650 Example: 1652 LOGO;VALUE=uri:http://www.example.com/pub/logos/abccorp.jpg 1654 LOGO;ENCODING=b;TYPE=image/jpeg:MIICajCCAdOgAwIBAgICBEUwDQYJKoZ 1655 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1656 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1657 <...the remainder of "B" encoded binary data...> 1659 7.6.4. ORG 1661 Purpose: To specify the organizational name and units associated 1662 with the vCard. 1664 Value type: A single structured text value consisting of components 1665 separated the SEMI-COLON character (ASCII decimal 59). 1667 Cardinality: (0,n) 1669 Special notes: The property is based on the X.520 Organization Name 1670 and Organization Unit attributes. The property value is a 1671 structured type consisting of the organization name, followed by 1672 zero or more levels of organizational unit names. 1674 ABNF: 1676 param = "VALUE=text" / language-param / pid-param / pref-param 1677 / any-param 1678 value = component *(";" component) 1680 component = "\\" / "\;" / "\n" / WSP / NON-ASCII 1681 / %x21-3A / %x3C-5B / %x5D-7E 1683 Example: A property value consisting of an organizational name, 1684 organizational unit #1 name and organizational unit #2 name. 1686 ORG:ABC\, Inc.;North American Division;Marketing 1688 7.6.5. MEMBER 1690 Purpose: To include a member in the group this vCard represents. 1692 Value tpe: A single URI. It MAY refer to something other than a 1693 vCard object. For example, an e-mail distribution list could 1694 employ the "mailto" URI scheme for efficiency. 1696 Cardinality: (0,n) 1698 Special notes: This property MUST NOT be present unless the value of 1699 the KIND property is "group". 1701 ABNF: 1703 param = "VALUE=uri" / pid-param / pref-param / any-param 1704 value = uri 1706 Examples: 1708 BEGIN:VCARD 1709 VERSION:4.0 1710 KIND:group 1711 FN:The Doe family 1712 MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1713 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1714 END:VCARD 1715 BEGIN:VCARD 1716 VERSION:4.0 1717 FN:John Doe 1718 UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1719 END:VCARD 1720 BEGIN:VCARD 1721 VERSION:4.0 1722 FN:Jane Doe 1723 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1724 END:VCARD 1726 BEGIN:VCARD 1727 VERSION:4.0 1728 KIND:group 1729 FN:Funky distribution list 1730 MEMBER:mailto:subscriber1@example.com 1731 MEMBER:xmpp:subscriber2@example.com 1732 MEMBER:sip:subscriber3@example.com 1733 MEMBER:tel:+1-418-555-5555 1734 END:VCARD 1736 7.6.6. RELATED 1738 Purpose: To specify a relationship the individual this vCard 1739 represents has with another. 1741 Value type: A single URI. It can also be reset to a single text 1742 value. The text value can be used to specify textual information. 1744 Cardinality: (0,n) 1746 Special notes: The TYPE parameter MAY be used to characterize the 1747 related individual. The understood types are: 1749 * "parent" means that the related individual is the parent of the 1750 individual this vCard represents. 1752 * "child" means the opposite of "parent". 1754 * "sibling" means that the two individuals are siblings. 1756 * "manager" means that the related individual is the direct 1757 hierarchical superior (i.e. supervisor or manager) of the 1758 individual this vCard represents. 1760 * "assistant" for an assistant or secretary. 1762 * "agent" for a person who will act on behalf of the individual 1763 or resource associated with the vCard. 1765 * "emergency" indicates an emergency contact. 1767 Other types may be registered to IANA as described in 1768 Section 11.2, and private extensions starting with "X-" may be 1769 used. 1771 ABNF: 1773 param = "VALUE=" ("uri" / "text") 1774 value = uri / text 1775 ; Parameter and value MUST match. 1777 param =/ type-param / pid-param / pref-param / any-param 1779 type-param-related = "parent" / "child" / "sibling" / "manager" 1780 / "assistant" / "agent" / "emergency" 1781 / iana-token / x-name 1783 Examples: 1785 RELATED;TYPE=manager:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1786 RELATED;TYPE=assistant:http://example.com/directory/jdoe.vcf 1787 RELATED;TYPE=agent;VALUE=text:Please contact my assistant Jane Doe 1788 for any inquiries. 1790 7.7. Explanatory Properties 1792 These properties are concerned with additional explanations, such as 1793 that related to informational notes or revisions specific to the 1794 vCard. 1796 7.7.1. CATEGORIES 1798 Purpose: To specify application category information about the 1799 vCard. 1801 Value type: One or more text values separated by a COMMA character 1802 (ASCII decimal 44). 1804 Cardinality: (0,n) 1806 ABNF: 1808 param = "VALUE=text" / pid-param / pref-param / any-param 1809 value = text-list 1811 Example: 1813 CATEGORIES:TRAVEL AGENT 1815 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY 1817 7.7.2. NOTE 1819 Purpose: To specify supplemental information or a comment that is 1820 associated with the vCard. 1822 Value type: A single text value. 1824 Cardinality: (0,n) 1826 Special notes: The property is based on the X.520 Description 1827 attribute. 1829 ABNF: 1831 param = "VALUE=text" / language-param / pid-param / pref-param 1832 / any-param 1834 value = text 1836 Example: 1838 NOTE:This fax number is operational 0800 to 1715 1839 EST\, Mon-Fri. 1841 7.7.3. PRODID 1843 Purpose: To specify the identifier for the product that created the 1844 vCard object. 1846 Type value: A single text value. 1848 Cardinality: (0,1) 1850 Special notes: Implementations SHOULD use a method such as that 1851 specified for Formal Public Identifiers in [ISO9070] or for 1852 Universal Resource Names in [RFC3406] to assure that the text 1853 value is unique. 1855 ABNF: 1857 param = "VALUE=text" / any-param 1858 value = text 1860 Example: 1862 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN 1864 7.7.4. REV 1866 Purpose: To specify revision information about the current vCard. 1868 Value type: A single timestamp value. 1870 Cardinality: (0,1) 1872 Special notes: The value distinguishes the current revision of the 1873 information in this vCard for other renditions of the information. 1875 ABNF: 1877 param = "VALUE=timestamp" / any-param 1878 value = timestamp 1880 Example: 1882 REV:19951031T222710Z 1884 7.7.5. SORT-STRING 1886 Purpose: To specify the family name or given name text to be used 1887 for national-language-specific sorting of the FN and N types. 1889 Value type: A single text value. 1891 Cardinality: (0,1) 1893 Special notes: The sort string is used to provide family name or 1894 given name text that is to be used in locale- or national- 1895 language- specific sorting of the formatted name and structured 1896 name types. Without this information, sorting algorithms could 1897 incorrectly sort this vCard within a sequence of sorted vCards. 1898 When this property is present in a vCard, then this family name or 1899 given name value is used for sorting the vCard. 1901 ABNF: 1903 param = "VALUE=text" / any-param 1904 value = text 1906 Examples: For the case of family name sorting, the following examples 1907 define common sort string usage with the FN and N properties. 1909 FN:Rene van der Harten 1910 N:van der Harten;Rene;J.;Sir;R.D.O.N. 1911 SORT-STRING:Harten 1913 FN:Robert Pau Shou Chang 1914 N:Pau;Shou Chang;Robert 1915 SORT-STRING:Pau 1917 FN:Osamu Koura 1918 N:Koura;Osamu 1919 SORT-STRING:Koura 1921 FN:Oscar del Pozo 1922 N:del Pozo Triscon;Oscar 1923 SORT-STRING:Pozo 1925 FN:Chistine d'Aboville 1926 N:d'Aboville;Christine 1927 SORT-STRING:Aboville 1929 7.7.6. SOUND 1931 Purpose: To specify a digital sound content information that 1932 annotates some aspect of the vCard. This property is often used 1933 to specify the proper pronunciation of the name property value of 1934 the vCard. 1936 Encoding: The encoding MUST be reset to "b" using the ENCODING 1937 parameter in order to specify inline, encoded binary data. If the 1938 value is referenced by a URI value, then the default encoding of 1939 8bit is used and no explicit ENCODING parameter is needed. 1941 Value type: A single value. The default is binary value. It can 1942 also be reset to uri value. The uri value can be used to specify 1943 a value outside of this MIME entity. 1945 Cardinality: (0,n) 1947 Special notes: This property SHOULD include the parameter "TYPE" to 1948 specify the audio format type. The TYPE parameter value MUST be 1949 an audio media type as specified in [RFC4288]. The full media 1950 type name, including the "audio/" prefix, should be used. 1951 However, implementations SHOULD be able to handle bare subtypes. 1953 ABNF: 1955 param = inline-param / refer-param 1956 value = inline-value / refer-value 1957 ; Value and parameter MUST match. 1959 param =/ language-param / pid-param / pref-param / any-param 1961 Example: 1963 SOUND;TYPE=audio/basic;VALUE=uri:CID:JOHNQPUBLIC.part8. 1964 19960229T080000.xyzMail@example.com 1966 SOUND;TYPE=audio/basic;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJK 1967 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1968 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1969 <...the remainder of "B" encoded binary data...> 1971 7.7.7. UID 1972 Purpose: To specify a value that represents a globally unique 1973 identifier corresponding to the individual or resource associated 1974 with the vCard. 1976 Value type: A single URI value. 1978 Cardinality: (0,1) 1980 Special notes: This property is used to uniquely identify the object 1981 that the vCard represents. The "uuid" URN namespace defined in 1982 [RFC4122] is particularly well-suited to this task, but other URI 1983 schemes MAY be used. 1985 ABNF: 1987 param = "VALUE=uri" / any-param 1988 value = uri 1990 Example: 1992 UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1994 7.7.8. CLIENTPIDMAP 1996 Purpose: To give a global meaning to a local PID source identifier. 1998 Value type: A semicolon-separated pair of values. The first field 1999 is a small integer corresponding to the second field of a PID 2000 parameter instance. The second field is a URI. The "uuid" URN 2001 namespace defined in [RFC4122] is particularly well-suited to this 2002 task, but other URI schemes MAY be used. 2004 Cardinality: (0,n) 2006 Special notes: PID source identifiers (the source identifier is the 2007 second field in a PID parameter instance) are small integers that 2008 only have significance within the scope of a single vCard 2009 instance. Each distinct source identifier present in a vCard MUST 2010 have an associated CLIENTPIDMAP. See Section 8 for more details 2011 on the usage of CLIENTPIDMAP. 2013 PID source identifiers MUST be strictly positive. Zero is not 2014 allowed. 2016 As a special exception, the PID parameter MUST NOT be applied to 2017 this property. 2019 ABNF: 2021 param = any-param 2022 value = 1*DIGIT ";" uri 2024 Example: 2026 TEL;PID=3.1,4.2:tel:+1-555-555-5555 2027 EMAIL;PID=4.1,5.2:jdoe@example.com 2028 CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b 2029 CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5 2031 7.7.9. URL 2033 Purpose: To specify a uniform resource locator associated with the 2034 object that the vCard refers to. 2036 Cardinality: (0,n) 2038 Value type: A single uri value. 2040 ABNF: 2042 param = "VALUE=uri" / pid-param / pref-param / any-param 2043 value = uri 2045 Example: 2047 URL:http://example.org/restaurant.french/~chezchic.html 2049 7.7.10. VERSION 2051 Purpose: To specify the version of the vCard specification used to 2052 format this vCard. 2054 Value type: A single text value. 2056 Cardinality: (1,1) 2058 Special notes: The property MUST be present in the vCard object. 2059 The value MUST be "4.0" if the vCard corresponds to this 2060 specification. 2062 ABNF: 2064 param = "VALUE=text" / any-param 2065 value = "4.0" 2067 Example: 2069 VERSION:4.0 2071 7.8. Security Properties 2073 These properties are concerned with the security of communication 2074 pathways or access to the vCard. 2076 7.8.1. CLASS 2078 Purpose: To specify the access classification for a vCard object. 2080 Value type: A single text value. 2082 Cardinality: (0,1) 2084 Special notes: An access classification is only one component of the 2085 general security model for a directory service. The 2086 classification attribute provides a method of capturing the intent 2087 of the owner for general access to information described by the 2088 vCard object. 2090 Predefined values are: 2092 PUBLIC: This vCard MAY be shared with anyone. 2094 PRIVATE: This vCard MUST NOT be shared. It MAY be exported if 2095 explictly authorized and requested by the creator. 2097 CONFIDENTIAL: This vCard MAY be shared with allowed users or 2098 systems. The exact confidentiality level is site-specific and 2099 out of scope for the vCard specification. 2101 ABNF: 2103 param = "VALUE=text" / any-param 2104 value = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token / x-name 2106 Examples: 2108 CLASS:PUBLIC 2110 CLASS:PRIVATE 2112 CLASS:CONFIDENTIAL 2114 7.8.2. KEY 2116 Purpose: To specify a public key or authentication certificate 2117 associated with the object that the vCard represents. 2119 Encoding: The encoding MUST be reset to "b" using the ENCODING 2120 parameter in order to specify inline, encoded binary data. If the 2121 value is a text value, then the default encoding of 8bit is used 2122 and no explicit ENCODING parameter is needed. 2124 Value type: A single value. The default is binary. It can also be 2125 reset to uri value. The uri value can be used to specify a value 2126 outside of this MIME entity. In this case, the key's media type 2127 is obtained externally (e.g. with the HTTP Content-Type header) 2128 instead of with the TYPE parameter. 2130 Cardinality: (0,n) 2132 Special notes: This property SHOULD include the parameter "TYPE" to 2133 specify the public key or authentication certificate format. The 2134 TYPE parameter value MUST be a media type as specified in 2135 [RFC4288]. 2137 ABNF: 2139 param = inline-param / refer-param 2140 value = inline-value / refer-value 2141 ; Value and parameter MUST match. 2143 param =/ pid-param / pref-param / any-param 2145 Examples: 2147 KEY;VALUE=uri:http://www.example.com/keys/jdoe 2149 KEY;TYPE=application/pgp-keys;ENCODING=b:mQGiBEbEPUsRBACBF0RSIN 2150 mGutdM+KSAl7HMzwXHaLbvEOyu8At80I8qGejhzWowKbfem3X0m68Y/vhb+J2g 2151 7q11KHpnEdNb67uZaj9nTQ09Q+UFtH25qD/Afn3+9bOJQaPjAUYzXu3vD/xmN8 2152 <...remainder of "B" encoded binary data...> 2154 7.9. Calendar Properties 2156 These properties are further specified in [RFC2739]. 2158 7.9.1. FBURL 2159 Purpose: To specify the URI for a user's busy time in a vCard 2160 object. 2162 Value type: A single URI value. 2164 Cardinality: (0,n) 2166 Special notes: Where multiple FBURL properties are specified, the 2167 default FBURL property is indicated with the PREF parameter. The 2168 FTP or HTTP type of URI points to an iCalendar object associated 2169 with a snapshot of the last six weeks of the user's busy time 2170 data. If the iCalendar object is represented as a file or 2171 document, it's file type should be "ifb". 2173 ABNF: 2175 param = "VALUE=uri" / pid-param / pref-param / any-param 2176 value = uri 2178 Examples: 2180 FBURL;PREF=1:http://www.example.com/busy/janedoe 2181 FBURL:FTP://ftp.example.com/busy/project-a.ifb 2183 7.9.2. CALADRURI 2185 Purpose: To specify the location to which an event request should be 2186 sent for the user. 2188 Value type: A single URI value. 2190 Cardinality: (0,n) 2192 Special notes: Where multiple CALADRURI properties are specified, 2193 the default CALADRURI property is indicated with the PREF 2194 parameter. 2196 ABNF: 2198 param = "VALUE=uri" / pid-param / pref-param / any-param 2199 value = uri 2201 Example: 2203 CALADRURI;PREF=1:mailto:janedoe@example.com 2204 CALADRURI:http://example.com/calendar/jdoe 2206 7.9.3. CALURI 2208 Purpose: To specify the URI for a user's calendar in a vCard object. 2210 Value type: A single URI value. 2212 Cardinality: (0,n) 2214 Special notes: Where multiple CALURI properties are specified, the 2215 default CALURI property is indicated with the PREF parameter. The 2216 property should contain a URI pointing to an iCalendar object 2217 associated with a snapshot of the user's calendar store. If the 2218 iCalendar object is represented as a file or document, it's file 2219 type should be "ics". 2221 ABNF: 2223 param = "VALUE=uri" / pid-param / pref-param / any-param 2224 value = uri 2226 Examples: 2228 CALURI;PREF=1:http://cal.example.com/calA 2229 CALURI:ftp://ftp.example.com/calA.ics 2231 7.10. Extended Properties and Parameters 2233 The properties and parameters defined by this document can be 2234 extended. Non-standard, private properties and parameters with a 2235 name starting with "X-" may be defined bilaterally between two 2236 cooperating agents without outside registration or standardization. 2238 8. Synchronization 2240 vCard data often needs to be synchronized between devices. In this 2241 context, synchronization is defined as the intelligent merging of two 2242 representations of the same object. vCard 4.0 includes mechanisms to 2243 aid this process. 2245 8.1. Mechanisms 2247 Two mechanisms are available: the UID property is used to match 2248 multiple instances of the same vCard, while the PID parameter is used 2249 to match multiple instances of the same property. 2251 The term "matching" is used here to mean recognizing that two 2252 instances are in fact representations of the same object. For 2253 example, a single vCard that is shared with someone results in two 2254 vCard instances. After they have evolved separately, they still 2255 represent the same object, and therefore may be matched by a 2256 synchronization engine. 2258 8.1.1. Matching vCard Instances 2260 vCard instances for which the UID properties (Section 7.7.7) are 2261 equivalent MUST be matched. Equivalence is determined as specified 2262 in [RFC3986], Section 6. 2264 In all other cases, vCard instances MAY be matched at the discretion 2265 of the synchronization engine. 2267 8.1.2. Matching Property Instances 2269 Property instances belonging to unmatched vCards MUST NOT be matched. 2271 Property instances whose name (e.g. EMAIL, TEL, etc.) is not the 2272 same MUST NOT be matched. 2274 Property instances whose name is CLIENTPIDMAP are handled separately 2275 and MUST NOT be matched. The synchronization MUST ensure that there 2276 is consistency of CLIENTPIDMAPs among matched vCard instances. 2278 Property instances belonging to matched vCards, whose name is the 2279 same, and whose maximum cardinality is 1 MUST be matched. 2281 Property instances belonging to matched vCards, whose name is the 2282 same, and whose PID parameters match MUST be matched. See 2283 Section 8.1.3 for details on PID matching. 2285 In all other cases, property instances MAY be matched at the 2286 discretion of the synchronization engine. 2288 8.1.3. PID Matching 2290 Two PID values for which the first fields are equivalent represent 2291 the same local value. 2293 Two PID values representing the same local value and for which the 2294 second fields point to CLIENTPIDMAP properties whose second field 2295 URIs are equivalent (as specified in [RFC3986], Section 6) also 2296 represent the same global value. 2298 PID parameters for which at least one pair of their values represent 2299 the same global value MUST be matched. 2301 In all other cases, PID parameters MAY be matched at the discretion 2302 of the synchronization engine. 2304 For example, PID value "5.1", in the first vCard below, and PID value 2305 "6.2", in the second vCard below, represent the same global value. 2307 BEGIN:VCARD 2308 VERSION:4.0 2309 EMAIL;PID=4.2,5.1:jdoe@example.com 2310 CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2311 CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc 2312 END:VCARD 2314 BEGIN:VCARD 2315 VERSION:4.0 2316 EMAIL;PID=5.1,6.2:john@example.com 2317 CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d 2318 CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2319 END:VCARD 2321 8.2. Example 2323 8.2.1. Creation 2325 The following simple vCard is first created on a given device. 2327 BEGIN:VCARD 2328 VERSION:4.0 2329 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2330 FN:J. Doe 2331 EMAIL;PID=1.1:jdoe@example.com 2332 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2333 END:VCARD 2335 This new vCard is assigned the UID 2336 "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating 2337 device. The EMAIL property is assigned PID 1, and this PID is given 2338 global context by associating it with 2339 "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which represents the 2340 creating device. The FN property has no PID because it is forbidden 2341 by its maximum cardinality of 1. 2343 8.2.2. Initial Sharing 2345 This vCard is shared with a second device. Upon inspecting the UID 2346 property, the second device understands that this is a new vCard 2347 (i.e. unmatched) and thus the synchronization results in a simple 2348 copy. 2350 8.2.3. Adding and Sharing a Property 2352 A new phone number is created on the first device, then the vCard is 2353 shared with the second device. This is what the second device 2354 receives: 2356 BEGIN:VCARD 2357 VERSION:4.0 2358 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2359 FN:J. Doe 2360 EMAIL;PID=1.1:jdoe@example.com 2361 TEL;PID=1.1:tel:+1-555-555-5555 2362 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2363 END:VCARD 2365 Upon inspecting the UID property, the second device matches the vCard 2366 it received to the vCard that it already has stored. It then starts 2367 comparing the properties of the two vCards in same-named pairs. 2369 The FN properties are matched automatically because their maximum 2370 cardinality is 1. Since the property value is the same, no update 2371 takes place. 2373 The EMAIL properties are matched because the PID parameters have the 2374 same global value. Since the property value is the same, no update 2375 takes place. 2377 The TEL property in the new vCard is not matched to any in the stored 2378 vCard because no property in the stored vCard has the same name. 2379 Therefore, this property is copied from the new vCard to the stored 2380 vCard. 2382 The CLIENTPIDMAP property is handled separately by the 2383 synchronization engine. It ensures that it is consistent with the 2384 stored one. If it was not, the results would be up to the 2385 synchronization engine, and thus undefined by this document. 2387 8.2.4. Simultaneous Editing 2389 A new email address and a new phone number are added to the vCard on 2390 each of the two devices, and then a new synchronization event 2391 happens. Here are the vCards that are communicated to each other: 2393 BEGIN:VCARD 2394 VERSION:4.0 2395 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2396 FN:J. Doe 2397 EMAIL;PID=1.1:jdoe@example.com 2398 EMAIL;PID=2.1:boss@example.com 2399 TEL;PID=1.1:tel:+1-555-555-5555 2400 TEL;PID=2.1:tel:+1-666-666-6666 2401 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2402 END:VCARD 2404 BEGIN:VCARD 2405 VERSION:4.0 2406 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2407 FN:J. Doe 2408 EMAIL;PID=1.1:jdoe@example.com 2409 EMAIL;PID=2.2:ceo@example.com 2410 TEL;PID=1.1:tel:+1-555-555-5555 2411 TEL;PID=2.2:tel:+1-666-666-6666 2412 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2413 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2414 END:VCARD 2416 On the first device, the same PID source identifier (1) is reused for 2417 the new EMAIL and TEL properties. On the second device, a new source 2418 identifier (2) is generated, and a corresponding CLIENTPIDMAP 2419 property is created. It contains the second device's identifier, 2420 "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee". 2422 The new EMAIL properties are unmatched on both sides since the PID 2423 global value is new in both cases. The sync thus results in a copy 2424 on both sides. 2426 Although the situation appears to be the same for the TEL properties, 2427 in this case the synchronization engine is particularly smart and 2428 matches the two new TEL properties even though their PID global 2429 values are different. Note that in this case, the rules of section 2430 Section 8.1.2 state that two properties may be matched at the 2431 discretion of the synchronization engine. Therefore, the two 2432 properties are merged. 2434 All this results in the following vCard which is stored on both 2435 devices: 2437 BEGIN:VCARD 2438 VERSION:4.0 2439 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2440 FN:J. Doe 2441 EMAIL;PID=1.1:jdoe@example.com 2442 EMAIL;PID=2.1:boss@example.com 2443 EMAIL;PID=2.2:ceo@example.com 2444 TEL;PID=1.1:tel:+1-555-555-5555 2445 TEL;PID=2.1,2.2:tel:+1-666-666-6666 2446 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2447 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2448 END:VCARD 2450 8.2.5. Global Context Simplification 2452 The two devices finish their synchronization procedure by simplifying 2453 their global contexts. Since they haven't talked to any other 2454 device, the following vCard is for all purposes equivalent to the 2455 above. It is also shorter. 2457 BEGIN:VCARD 2458 VERSION:4.0 2459 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2460 FN:J. Doe 2461 EMAIL;PID=1.1:jdoe@example.com 2462 EMAIL;PID=2.1:boss@example.com 2463 EMAIL;PID=3.1:ceo@example.com 2464 TEL;PID=1.1:tel:+1-555-555-5555 2465 TEL;PID=2.1:tel:+1-666-666-6666 2466 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2467 END:VCARD 2469 The details of global context simplification are unspecified by this 2470 document. They are left up to the synchronization engine. This 2471 example is merely intended to illustrate the possibility, which 2472 investigating would be, in the authors' opinion, worthwhile. 2474 9. Example: Authors' vCards 2476 BEGIN:VCARD 2477 VERSION:4.0 2478 FN:Simon Perreault 2479 N:Perreault;Simon;;ing. jr,M.Sc. 2480 BDAY:--0203 2481 GENDER:M 2482 LANG;PREF=1:fr 2483 LANG;PREF=2:en 2484 WORK.ORG:Viagenie 2485 WORK.ADR:;Suite 625;2600 boul. Laurier; 2486 Quebec;QC;G1V 4W1;Canada 2487 WORK.TEL;TYPE=voice;PREF=1:tel:+1-418-656-9254;ext=102 2488 WORK.TEL;TYPE=cell,voice,video,text:tel:+1-418-262-6501 2489 WORK.TEL;TYPE=fax:tel:+1-418-656-9257 2490 WORK.EMAIL:simon.perreault@viagenie.ca 2491 WORK.GEO:geo:46.772673,-71.282945 2492 WORK.KEY;VALUE=uri:http://www.viagenie.ca/simon.perreault/simon.asc 2493 TZ:-0500 2494 CLASS:PUBLIC 2495 END:VCARD 2497 BEGIN:VCARD 2498 VERSION:4.0 2499 FN:Pete Resnick 2500 N:Resnick;Pete;; 2501 GENDER:M 2502 WORK.ORG:QUALCOMM Incorporated 2503 WORK.ADR:;;5775 Morehouse Drive;San Diego;CA;92121-1714;US 2504 WORK.TEL;TYPE=voice:tel:+1-858-651-4478 2505 WORK.EMAIL:presnick@qualcomm.com 2506 WORK.URL:http://www.qualcomm.com/~presnick/ 2507 END:VCARD 2509 10. Security Considerations 2511 o Internet mail is subject to many well known security attacks, 2512 including monitoring, replay, and forgery. Care should be taken 2513 by any directory service in allowing information to leave the 2514 scope of the service itself, where any access controls can no 2515 longer be guaranteed. Applications should also take care to 2516 display directory data in a "safe" environment (e.g., PostScript- 2517 valued types). 2519 o vCards can carry cryptographic keys or certificates, as described 2520 in Section 7.8.2. 2522 o Section 7.8.1 specifies a desired security classification policy 2523 for a particular vCard. That policy is not enforced in any way. 2525 o The vCard objects have no inherent authentication or privacy, but 2526 can easily be carried by any security mechanism that transfers 2527 MIME objects with authentication or privacy. In cases where 2528 threats of "spoofed" vCard information is a concern, the vCard 2529 SHOULD BE transported using one of these secure mechanisms. 2531 o The information in a vCard may become out of date. In cases where 2532 the vitality of data is important to an originator of a vCard, the 2533 "URL" type described in Section 7.7.9 SHOULD BE specified. In 2534 addition, the "REV" type described in section Section 7.7.4 can be 2535 specified to indicate the last time that the vCard data was 2536 updated. 2538 11. IANA Considerations 2540 11.1. MIME Type Registration 2542 Please refer to Section 3. 2544 11.2. Registering New vCard Elements 2546 This section defines the process for registering new or modified 2547 vCard elements (i.e. properties, parameters, value data types, and 2548 values) with IANA. 2550 11.2.1. Registration Procedure 2552 The IETF will create a mailing list, vcard@ietf.org [1], which can be 2553 used for public discussion of vCard element proposals prior to 2554 registration. Use of the mailing list is strongly encouraged. The 2555 IESG will appoint a designated expert who will monitor the 2556 vcard@ietf.org [1] mailing list and review registrations. 2558 Registration of new vCard elements MUST be reviewed by the designated 2559 expert and published in an RFC. A Standard Tracks RFC is REQUIRED 2560 for the regisration of new value data types that modify existing 2561 properties. A Standard Tracks RFC is also REQUIRED for registration 2562 of vCard elements that modify vCard elements previously documented in 2563 a Standard Tracks RFC. 2565 The registration procedure begins when a completed registration 2566 template, defined in the sections below, is sent to 2567 vcard@ietf.org [1] and iana@iana.org [2]. The designated expert is 2568 expected to tell IANA and the submitter of the registration within 2569 two weeks whether the registration is approved, approved with minor 2570 changes, or rejected with cause. When a registration is rejected 2571 with cause, it can be re-submitted if the concerns listed in the 2572 cause are addressed. Decisions made by the designated expert can be 2573 appealed to the IESG Applications Area Director, then to the IESG. 2574 They follow the normal appeals procedure for IESG decisions. 2576 11.2.2. Vendor Namespace 2578 The vendor namespace is used for vCard elements associated with 2579 commercially available products. "Vendor" or "producer" are 2580 construed as equivalent and very broadly in this context. 2582 A registration may be placed in the vendor namespace by anyone who 2583 needs to interchange files associated with the particular product. 2584 However, the registration formally belongs to the vendor or 2585 organization handling the vCard elements in the namespace being 2586 registered. Changes to the specification will be made at their 2587 request, as discussed in subsequent sections. 2589 vCard elements belonging to the vendor namespace will be 2590 distinguished by the "VND-" prefix. That may be followed, at the 2591 discretion of the registrant, by either a vCard element name from a 2592 well-known producer (e.g., "VND-MUDPIE") or by an IANA-approved 2593 designation of the producer's name that is followed by a vCard 2594 element designation (e.g., "VND-BIGCOMPANY-MUDPIE"). 2596 While public exposure and review of vCard elements to be registered 2597 in the vendor namespace is not required, using the vcard@ietf.org [1] 2598 mailing list for review is strongly encouraged to improve the quality 2599 of those specifications. Registrations in the vendor namespace may 2600 be submitted directly to the IANA. 2602 11.2.3. Registration Template for Groups 2604 A group is defined by completing the following template. 2606 Group name: The name of the group. 2608 Purpose: The purpose of the group. Give a short but clear 2609 description. 2611 Description: Any special notes about the group, how it is to be 2612 used, etc. 2614 Allowed Properties: List of properties that may be placed inside the 2615 group. 2617 Example(s): One or more examples of instances of the value type 2618 needs to be specified. 2620 11.2.4. Registration Template for Properties 2622 A property is defined by completing the following template. 2624 Property name: The name of the property. 2626 Purpose: The purpose of the property. Give a short but clear 2627 description. 2629 Value type: Any of the valid value types for the property value 2630 needs to be specified. The default value type also needs to be 2631 specified. 2633 Property parameters: Any of the valid property parameters for the 2634 property MUST be specified. 2636 Groups: List of already-existing groups whose allowed properties 2637 list must be updated by adding this new property. 2639 Description: Any special notes about the property, how it is to be 2640 used, etc. 2642 Format definition: The ABNF for the property definition needs to be 2643 specified. 2645 Example(s): One or more examples of instances of the property needs 2646 to be specified. 2648 11.2.5. Registration Template for Parameters 2650 A parameter is defined by completing the following template. 2652 Parameter name: The name of the parameter. 2654 Purpose: The purpose of the parameter. Give a short but clear 2655 description. 2657 Description: Any special notes about the parameter, how it is to be 2658 used, etc. 2660 Format definition: The ABNF for the parameter definition needs to be 2661 specified. 2663 Example(s): One or more examples of instances of the parameter needs 2664 to be specified. 2666 11.2.6. Registration Template for Value Data Types 2668 A value data type is defined by completing the following template. 2670 Value name: The name of the value type. 2672 Purpose: The purpose of the value type. Give a short but clear 2673 description. 2675 Description: Any special notes about the value type, how it is to be 2676 used, etc. 2678 Format definition: The ABNF for the value type definition needs to 2679 be specified. 2681 Example(s): One or more examples of instances of the value type 2682 needs to be specified. 2684 11.2.7. Registration Template for Values 2686 A value is defined by completing the following template. 2688 Value: The value literal. 2690 Purpose: The purpose of the value. Give a short but clear 2691 description. 2693 Conformance: The vCard properties and/or parameters that can take 2694 this value needs to be specified. 2696 Example(s): One or more examples of instances of the value needs to 2697 be specified. 2699 The following is a fictitious example of a registration of a vCard 2700 value: 2702 Value: TOP-SECRET 2704 Purpose: This value is used to specify the access classification of 2705 top-secret vCards. 2707 Conformance: This value can be used with the "CLASS" property. 2709 Example(s): The following is an example of this value used with the 2710 "CLASS" property: 2712 CLASS:TOP-SECRET 2714 11.3. Initial vCard Elements Registries 2716 The IANA is requested to create and maintain the following registries 2717 for vCard elements with pointers to appropriate reference documents. 2719 11.3.1. Groups Registry 2721 The following table is to be used to initialize the groups registry. 2723 +------+--------------+---------+-----------------------+-----------+ 2724 | Goup | Description | Status | Allowed Properties | Reference | 2725 +------+--------------+---------+-----------------------+-----------+ 2726 | WORK | Properties | Current | FN, NICKNAME, PHOTO, | RFCXXXX | 2727 | | related to | | ADR, LABEL, TEL, | | 2728 | | an | | EMAIL, IMPP, LANG, | | 2729 | | individual's | | TZ, GEO, TITLE, ROLE, | | 2730 | | work place. | | LOGO, ORG, RELATED, | | 2731 | | | | CATEGORIES, NOTE, | | 2732 | | | | SOUND, URL, KEY, | | 2733 | | | | FBURL, CALADRURI, | | 2734 | | | | CALURI | | 2735 | HOME | Properties | Current | FN, NICKNAME, PHOTO, | RFCXXXX | 2736 | | related to | | ADR, LABEL, TEL, | | 2737 | | an | | EMAIL, IMPP, LANG, | | 2738 | | individual's | | TZ, GEO, TITLE, ROLE, | | 2739 | | personal | | LOGO, ORG, RELATED, | | 2740 | | life. | | CATEGORIES, NOTE, | | 2741 | | | | SOUND, URL, KEY, | | 2742 | | | | FBURL, CALADRURI, | | 2743 | | | | CALURI | | 2744 +------+--------------+---------+-----------------------+-----------+ 2746 11.3.2. Properties Registry 2748 The following table is to be used to initialize the properties 2749 registry. 2751 +--------------+---------+-------------------------+ 2752 | Property | Status | Reference | 2753 +--------------+---------+-------------------------+ 2754 | SOURCE | Current | RFCXXXX, Section 7.1.3 | 2755 | NAME | Current | RFCXXXX, Section 7.1.4 | 2756 | KIND | Current | RFCXXXX, Section 7.1.5 | 2757 | FN | Current | RFCXXXX, Section 7.2.1 | 2758 | N | Current | RFCXXXX, Section 7.2.2 | 2759 | NICKNAME | Current | RFCXXXX, Section 7.2.3 | 2760 | PHOTO | Current | RFCXXXX, Section 7.2.4 | 2761 | BDAY | Current | RFCXXXX, Section 7.2.5 | 2762 | DDAY | Current | RFCXXXX, Section 7.2.6 | 2763 | BIRTH | Current | RFCXXXX, Section 7.2.7 | 2764 | DEATH | Current | RFCXXXX, Section 7.2.8 | 2765 | GENDER | Current | RFCXXXX, Section 7.2.9 | 2766 | ADR | Current | RFCXXXX, Section 7.3.1 | 2767 | LABEL | Current | RFCXXXX, Section 7.3.2 | 2768 | TEL | Current | RFCXXXX, Section 7.4.1 | 2769 | EMAIL | Current | RFCXXXX, Section 7.4.2 | 2770 | IMPP | Current | RFCXXXX, Section 7.4.3 | 2771 | LANG | Current | RFCXXXX, Section 7.4.4 | 2772 | TZ | Current | RFCXXXX, Section 7.5.1 | 2773 | GEO | Current | RFCXXXX, Section 7.5.2 | 2774 | TITLE | Current | RFCXXXX, Section 7.6.1 | 2775 | ROLE | Current | RFCXXXX, Section 7.6.2 | 2776 | LOGO | Current | RFCXXXX, Section 7.6.3 | 2777 | ORG | Current | RFCXXXX, Section 7.6.4 | 2778 | MEMBER | Current | RFCXXXX, Section 7.6.5 | 2779 | RELATED | Current | RFCXXXX, Section 7.6.6 | 2780 | CATEGORIES | Current | RFCXXXX, Section 7.7.1 | 2781 | NOTE | Current | RFCXXXX, Section 7.7.2 | 2782 | PRODID | Current | RFCXXXX, Section 7.7.3 | 2783 | REV | Current | RFCXXXX, Section 7.7.4 | 2784 | SORT-STRING | Current | RFCXXXX, Section 7.7.5 | 2785 | SOUND | Current | RFCXXXX, Section 7.7.6 | 2786 | UID | Current | RFCXXXX, Section 7.7.7 | 2787 | CLIENTPIDMAP | Current | RFCXXXX, Section 7.7.8 | 2788 | URL | Current | RFCXXXX, Section 7.7.9 | 2789 | VERSION | Current | RFCXXXX, Section 7.7.10 | 2790 | CLASS | Current | RFCXXXX, Section 7.8.1 | 2791 | KEY | Current | RFCXXXX, Section 7.8.2 | 2792 | FBURL | Current | RFCXXXX, Section 7.9.1 | 2793 | CALADRURI | Current | RFCXXXX, Section 7.9.2 | 2794 | CALURI | Current | RFCXXXX, Section 7.9.3 | 2795 +--------------+---------+-------------------------+ 2797 11.3.3. Parameters Registry 2799 The following table is to be used to initialize the parameters 2800 registry. 2802 +-----------+---------+------------------------+ 2803 | Parameter | Status | Reference | 2804 +-----------+---------+------------------------+ 2805 | LANGUAGE | Current | RFCXXXX, Section 6.1 | 2806 | ENCODING | Current | RFCXXXX, Section 6.2 | 2807 | VALUE | Current | RFCXXXX, Section 6.3 | 2808 | PREF | Current | RFCXXXX, Section 6.4 | 2809 | PID | Current | RFCXXXX, Section 6.5 | 2810 | TYPE | Current | RFCXXXX, Section 6.6 | 2811 | GEO | Current | RFCXXXX, Section 7.3.1 | 2812 | TZ | Current | RFCXXXX, Section 7.3.1 | 2813 +-----------+---------+------------------------+ 2815 11.3.4. Value Data Types Registry 2817 The following table is to be used to initialize the parameters 2818 registry. 2820 +-----------------+---------+------------------------+ 2821 | Value Data Type | Status | Reference | 2822 +-----------------+---------+------------------------+ 2823 | BINARY | Current | RFCXXXX, Section 5.7 | 2824 | BOOLEAN | Current | RFCXXXX, Section 5.4 | 2825 | DATE | Current | RFCXXXX, Section 5.3.1 | 2826 | TIME | Current | RFCXXXX, Section 5.3.2 | 2827 | DATE-TIME | Current | RFCXXXX, Section 5.3.3 | 2828 | TIMESTAMP | Current | RFCXXXX, Section 5.3.4 | 2829 | FLOAT | Current | RFCXXXX, Section 5.6 | 2830 | INTEGER | Current | RFCXXXX, Section 5.5 | 2831 | TEXT | Current | RFCXXXX, Section 5.1 | 2832 | URI | Current | RFCXXXX, Section 5.2 | 2833 | LANGUAGE-TAG | Current | RFCXXXX, Section 5.9 | 2834 +-----------------+---------+------------------------+ 2836 11.3.5. Values Registries 2838 Separate tables will be used for property and parameter values. 2840 The following table is to be used to initialize the property values 2841 registry. 2843 +----------+--------------+---------+------------------------+ 2844 | Property | Value | Status | Reference | 2845 +----------+--------------+---------+------------------------+ 2846 | BEGIN | VCARD | Current | RFCXXXX, Section 7.1.1 | 2847 | END | VCARD | Current | RFCXXXX, Section 7.1.2 | 2848 | KIND | individual | Current | RFCXXXX, Section 7.1.5 | 2849 | KIND | group | Current | RFCXXXX, Section 7.1.5 | 2850 | KIND | org | Current | RFCXXXX, Section 7.1.5 | 2851 | KIND | location | Current | RFCXXXX, Section 7.1.5 | 2852 | GENDER | M | Current | RFCXXXX, Section 7.2.9 | 2853 | GENDER | F | Current | RFCXXXX, Section 7.2.9 | 2854 | CLASS | PUBLIC | Current | RFCXXXX, Section 7.8.1 | 2855 | CLASS | PRIVATE | Current | RFCXXXX, Section 7.8.1 | 2856 | CLASS | CONFIDENTIAL | Current | RFCXXXX, Section 7.8.1 | 2857 +----------+--------------+---------+------------------------+ 2859 The following table is to be used to initialize the parameter values 2860 registry. 2862 +----------+-----------+-----------+---------+----------------------+ 2863 | Property | Parameter | Value | Status | Reference | 2864 +----------+-----------+-----------+---------+----------------------+ 2865 | TEL | TYPE | text | Current | RFCXXXX, | 2866 | | | | | Section 7.4.1 | 2867 | TEL | TYPE | voice | Current | RFCXXXX, | 2868 | | | | | Section 7.4.1 | 2869 | TEL | TYPE | fax | Current | RFCXXXX, | 2870 | | | | | Section 7.4.1 | 2871 | TEL | TYPE | cell | Current | RFCXXXX, | 2872 | | | | | Section 7.4.1 | 2873 | TEL | TYPE | video | Current | RFCXXXX, | 2874 | | | | | Section 7.4.1 | 2875 | TEL | TYPE | pager | Current | RFCXXXX, | 2876 | | | | | Section 7.4.1 | 2877 | RELATED | TYPE | parent | Current | RFCXXXX, | 2878 | | | | | Section 7.6.6 | 2879 | RELATED | TYPE | child | Current | RFCXXXX, | 2880 | | | | | Section 7.6.6 | 2881 | RELATED | TYPE | sibling | Current | RFCXXXX, | 2882 | | | | | Section 7.6.6 | 2883 | RELATED | TYPE | manager | Current | RFCXXXX, | 2884 | | | | | Section 7.6.6 | 2885 | RELATED | TYPE | assistant | Current | RFCXXXX, | 2886 | | | | | Section 7.6.6 | 2887 | RELATED | TYPE | agent | Current | RFCXXXX, | 2888 | | | | | Section 7.6.6 | 2889 +----------+-----------+-----------+---------+----------------------+ 2891 12. Acknowledgements 2893 The authors would like to thank Tim Howes, Mark Smith, and Frank 2894 Dawson, the original authors of [RFC2425] and [RFC2426], as well as 2895 the following individuals who have participated in the drafting, 2896 review and discussion of this memo: 2898 Marc Blanchet, Stephane Bortzmeyer, Dan Brickley, Chris Bryant, Dany 2899 Cauchie, Darryl Champagne, Cyrus Daboo, Bernard Desruisseaux, Lisa 2900 Dusseault, Javier Godoy, Helge Hess, Alexander Mayrhofer, Chris 2901 Newman, Mark Paterson, Julian Reschke, Peter K. Sheerin, Anil 2902 Srivastava, and Kurt Zeilenga. 2904 13. References 2906 13.1. Normative References 2908 [CCITT.E163.1988] International Telephone and Telegraph 2909 Consultative Committee, "Numbering Plan for 2910 the International Telephone Service", 2911 CCITT Recommendation E.163, 1988. 2913 [CCITT.X121.1988] International Telephone and Telegraph 2914 Consultative Committee, "International 2915 Numbering Plan for the Public Data 2916 Networks", CCITT Recommendation X.121, 1988. 2918 [CCITT.X520.1988] International International Telephone and 2919 Telegraph Consultative Committee, 2920 "Information Technology - Open Systems 2921 Interconnection - The Directory: Selected 2922 Attribute Types", CCITT Recommendation 2923 X.520, November 1988. 2925 [CCITT.X521.1988] International International Telephone and 2926 Telegraph Consultative Committee, 2927 "Information Technology - Open Systems 2928 Interconnection - The Directory: Selected 2929 Object Classes", CCITT Recommendation X.521, 2930 November 1988. 2932 [I-D.mayrhofer-geo-uri] Mayrhofer, A. and C. Spanring, "A Uniform 2933 Resource Identifier for Geographic Areas 2934 ('geo' URI)", draft-mayrhofer-geo-uri-02 2935 (work in progress), February 2008. 2937 [ISO.8601.2000] International Organization for 2938 Standardization, "Data elements and 2939 interchange formats - Information 2940 interchange - Representation of dates and 2941 times", ISO Standard 8601, December 2000. 2943 [ISO.8601.2004] International Organization for 2944 Standardization, "Data elements and 2945 interchange formats - Information 2946 interchange - Representation of dates and 2947 times", ISO Standard 8601, December 2004. 2949 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose 2950 Internet Mail Extensions (MIME) Part Two: 2951 Media Types", RFC 2046, November 1996. 2953 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 2954 Extensions) Part Three: Message Header 2955 Extensions for Non-ASCII Text", RFC 2047, 2956 November 1996. 2958 [RFC2119] Bradner, S., "Key words for use in RFCs to 2959 Indicate Requirement Levels", BCP 14, 2960 RFC 2119, March 1997. 2962 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME 2963 Content-Type for Directory Information", 2964 RFC 2425, September 1998. 2966 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 2967 Directory Profile", RFC 2426, 2968 September 1998. 2970 [RFC2739] Small, T., Hennessy, D., and F. Dawson, 2971 "Calendar Attributes for vCard and LDAP", 2972 RFC 2739, January 2000. 2974 [RFC2978] Freed, N. and J. Postel, "IANA Charset 2975 Registration Procedures", BCP 19, RFC 2978, 2976 October 2000. 2978 [RFC3629] Yergeau, F., "UTF-8, a transformation format 2979 of ISO 10646", STD 63, RFC 3629, 2980 November 2003. 2982 [RFC3966] Schulzrinne, H., "The tel URI for Telephone 2983 Numbers", RFC 3966, December 2004. 2985 [RFC3986] Berners-Lee, T., Fielding, R., and L. 2986 Masinter, "Uniform Resource Identifier 2987 (URI): Generic Syntax", STD 66, RFC 3986, 2988 January 2005. 2990 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A 2991 Universally Unique IDentifier (UUID) URN 2992 Namespace", RFC 4122, July 2005. 2994 [RFC4288] Freed, N. and J. Klensin, "Media Type 2995 Specifications and Registration Procedures", 2996 BCP 13, RFC 4288, December 2005. 2998 [RFC4646] Phillips, A. and M. Davis, "Tags for 2999 Identifying Languages", BCP 47, RFC 4646, 3000 September 2006. 3002 [RFC4770] Jennings, C. and J. Reschke, Ed., "vCard 3003 Extensions for Instant Messaging (IM)", 3004 RFC 4770, January 2007. 3006 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF 3007 for Syntax Specifications: ABNF", STD 68, 3008 RFC 5234, January 2008. 3010 [RFC5322] Resnick, P., Ed., "Internet Message Format", 3011 RFC 5322, October 2008. 3013 [oldreference_VCARD] Internet Mail Consortium, "vCard - The 3014 Electronic Business Card Version 2.1", 3015 September September. 3017 13.2. Informative References 3019 [ISO9070] The International Organization for 3020 Standardization, "ISO 9070, Information 3021 Processing - SGML support facilities - 3022 Registration Procedures for Public Text 3023 Owner Identifiers", April 1991. 3025 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and 3026 P. Faltstrom, "Uniform Resource Names (URN) 3027 Namespace Definition Mechanisms", BCP 66, 3028 RFC 3406, October 2002. 3030 URIs 3032 [1] 3034 [2] 3036 Appendix A. Differences from RFCs 2425 and 2426 3038 This appendix contains a list of changes that have been made in the 3039 vCard specification from RFCs 2425 and 2426. 3041 A.1. New Structure 3043 o [RFC2425] and [RFC2426] have been merged. Initially [RFC2425] was 3044 intended to be extensible but only 2426 ever extended it. 3046 o vCard is now not only a MIME type but a stand-alone format. 3048 o A proper MIME type registration form has been included. 3050 o UTF-8 is now the default character set. 3052 o New vCard elements can be registered from IANA. 3054 A.2. Removed Features 3056 o The group construct (i.e. GROUP.PROPERTY:...) no longer exists. 3058 o The CONTEXT and CHARSET parameters are no more. 3060 o The MAILER property is no more. 3062 o The "intl", "dom", "postal", and "parcel" TYPE parameter values 3063 for the ADR and LABEL properties have been removed. 3065 o Inline vCards (such as the value of the AGENT property) are no 3066 longer supported. 3068 o In the N property, additional names are now subsumed into the 3069 given names list. 3071 A.3. New Properties and Parameters 3073 o The KIND, GENDER, LANG, DDAY, BIRTH, and DEATH properties have 3074 been added. 3076 o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI 3077 properties, has been merged in. 3079 o [RFC4770], which defines the IMPP property, has been merged in. 3081 o The "work", "home", and "uri" TYPE parameter values for the EMAIL 3082 property have been added. 3084 o The "pref" value of the TYPE parameter is now a parameter of its 3085 own, with a positive integer value indicating the level of 3086 preferredness. 3088 A.4. Other Changes 3090 o Synchronization is addressed in Section 8. 3092 o The N property is no longer mandatory. 3094 o The value of TEL is now a URI. 3096 o The AGENT property was replaced with a type of RELATED. 3098 o Date and time values now only support the basic format. 3099 Truncation is now supported. 3101 Appendix B. Change Log (to be removed by RFC Editor prior to 3102 publication) 3104 B.1. Changes in -07 3106 o PREF is now bounded. 100 is the maximum value. 3108 o Added the "emergency" RELATED type. 3110 o Made GEO a URI. 3112 o Added GEO and TZ parameters to ADR. 3114 o Changed wording of "default" use of SOUND property. 3116 o Completely reworked the date, time, and date-time grammars. 3118 o Added the timestamp value type. 3120 o REV now has the timestamp value type. 3122 o Rewrote ABNF. 3124 o ORG can now have a single level. 3126 B.2. Changes in -06 3128 o Corrected omission of resetability to text value for RELATED. 3130 o Let KEY value type be reset to a URI value. 3132 o ABNF fixes. 3134 o Made gender values extensible. 3136 o Gave the PREF parameter a positive integer value. 3138 o Removed usage of the undefined "word" ABNF production rule. 3140 o Defined property cardinalities. 3142 o Defined properties allowable in WORK and HOME groups. 3144 o Simplified the LANG property to use the vCard preference 3145 mechanism. 3147 o Created the "language-tag" value type. 3149 o Added PID to ABNF of SOURCE allowed parameters. 3151 o Clarified escaping rules. 3153 o Changed ABNF definition of non-standard X- properties. 3155 o Removed TYPE parameter from EMAIL properties in examples. 3157 o Created the CLIENTPIDMAP property. 3159 o Changed PID value to a pair of small integers. 3161 o Completely reworked synchronization mechanisms. 3163 o Created brand new synchronization example. 3165 B.3. Changes in -05 3167 o Added multi PID value proposal. 3169 B.4. Changes in -04 3171 o Added "location" value for KIND property. 3173 o Some fixes to ABNF. 3175 o Moved "pref" from being a TYPE value to a parameter in its own 3176 right. 3178 o Removed the "work" and "home" TYPE values. 3180 o Reintroduced the group construct. 3182 o Assigned meaning to WORK and HOME groups. 3184 o Restricted the TEL TYPE parameter value set. 3186 o In N property, removed additional names, and replaced with 3187 multiple given names. 3189 o Removed TYPE parameter from EMAIL and IMPP properties. 3191 o Replaced AGENT with a type of RELATED. 3193 o Use example.org domain in URL example. 3195 o Created initial IANA table of values. 3197 o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL. 3199 B.5. Changes in -03 3201 o Various changes to the synchronization mechanisms. 3203 o Allowed truncated format for dated. See issue #236. 3205 B.6. Changes in -02 3207 o Removed useless text in IMPP description. 3209 o Added CalDAV-SCHED example to CALADRURI. 3211 o Removed CAPURI property. 3213 o Dashes in dates and colons in times are now mandatory. 3215 o Allow for dates such as 2008 and 2008-05 and times such as 07 and 3216 07:54. 3218 o Removed inline vCard value. 3220 o Made AGENT only accept URI references instead of inline vCards. 3222 o Added the MEMBER property. 3224 o Renamed the UID parameter to PID. 3226 o Changed the value type of the PID parameter to "a small integer." 3227 o Changed the presence of UID and PID when synchronization is to be 3228 used from MUST to SHOULD. 3230 o Added the RELATED (Section 7.6.6) property. 3232 o Fixed many ABNF typos (issue #252). 3234 o Changed formatting of ABNF comments to make them easier to read 3235 (issue #226). 3237 B.7. Changes in -01 3239 o Merged [RFC2739] in. 3241 o Converted all foobar.com, abc.com, etc. to example.com. 3243 o Fixed bugs in ABNF. 3245 o Made explicit that coordinates in the GEO property are expressed 3246 in the WGS 84 reference system. 3248 o Clarified folding issues with multi-byte characters. 3250 o Made the value of TEL a URI. 3252 o Added the UID parameter. 3254 o Made the UID property's value type a URI. 3256 o Added Section 8. 3258 o Created IANA process for registering new parameters, value types, 3259 and properties. 3261 o Created the initial IANA registries. 3263 o Created vendor namespace based on text from RFC 4288. 3265 B.8. Changes in -00 3267 o Name change because draft has been accepted as WG item. 3268 Otherwise, same as draft-resnick-vcarddav-vcardrev-01. 3270 o Removed reference to RFC 2234. 3272 o Fixed errata from 3273 http://www.rfc-editor.org/errata_search.php?rfc=2426. 3275 o Removed passage referring to RFC 2425 profiles. 3277 o Renamed Section 7.4 from "Telecommunications Adressing Properties" 3278 to "Communications Properties. 3280 o Added Appendix A and Appendix B. 3282 o Added reference to [RFC4770]. 3284 o Removed the group construct. 3286 o Made the N property no longer mandatory. 3288 o Added the KIND property. 3290 o Clarified meaning of TYPE parameter value for PHOTO, LOGO, KEY, 3291 and SOUND. 3293 o Removed the CONTEXT parameter. 3295 o Removed the MAILER property. 3297 o Made reference to [ISO9070] informative. 3299 o Removed "intl", "dom", "postal", and "parcel" TYPE parameter 3300 values for the ADR and LABEL properties. 3302 o Clarified meaning of "extended address" ADR field. 3304 o Mentioned [RFC3406] as another method of generating PRODID values. 3306 o Updated obsolete references. 3308 o Allowed BDAY and DDAY value types to be text values for fuzzy 3309 dates. 3311 o Removed the CHARSET property. Now the encoding is always UTF-8, 3312 except when overridden by the Content-Type (which is considered a 3313 compatibility feature). 3315 Authors' Addresses 3317 Simon Perreault 3318 Viagenie 3319 2600 boul. Laurier, suite 625 3320 Quebec, QC G1V 4W1 3321 Canada 3323 Phone: +1 418 656 9254 3324 EMail: simon.perreault@viagenie.ca 3325 URI: http://www.viagenie.ca 3327 Peter W. Resnick 3328 QUALCOMM Incorporated 3329 5775 Morehouse Drive 3330 San Diego, CA 92121-1714 3331 US 3333 Phone: +1 858 651 4478 3334 EMail: presnick@qualcomm.com 3335 URI: http://www.qualcomm.com/~presnick/