idnits 2.17.1 draft-ietf-vcarddav-vcardrev-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2425, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2426, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC4770, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2739, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 454 has weird spacing: '... [month day]...' == Line 458 has weird spacing: '... month day...' == Line 459 has weird spacing: '... month day...' == Line 461 has weird spacing: '... month day...' == Line 467 has weird spacing: '... = hour minut...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2739, updated by this document, for RFC5378 checks: 1998-08-14) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5157 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: 'RFC2046' is defined on line 3167, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-geo-uri-04 == Outdated reference: A later version (-11) exists of draft-ietf-vcarddav-vcardxml-02 ** 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 4770 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 5 errors (**), 0 flaws (~~), 11 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) March 8, 2010 7 Intended status: Standards Track 8 Expires: September 9, 2010 10 vCard Format Specification 11 draft-ietf-vcarddav-vcardrev-10 13 Abstract 15 This document defines the vCard data format for representing and 16 exchanging a variety of information about individuals and other 17 entities (e.g., formatted and structured name and delivery addresses, 18 email address, multiple telephone numbers, photograph, logo, audio 19 clips, etc.). 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 6 76 3.1. Line Delimiting and Folding . . . . . . . . . . . . . . . 6 77 3.2. ABNF Format Definition . . . . . . . . . . . . . . . . . . 7 78 3.3. Property Value Escaping . . . . . . . . . . . . . . . . . 9 79 3.4. Character Set . . . . . . . . . . . . . . . . . . . . . . 10 80 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 10 81 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 12 84 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 13 87 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14 88 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 14 89 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 4.7. BINARY . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16 94 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16 95 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 5.2. ENCODING . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 5.3. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 5.4. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 5.7. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 20 103 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 20 104 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 20 105 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 21 106 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 21 107 6.1.4. NAME . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 6.1.5. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 22 109 6.1.6. XML . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 6.2. Identification Properties . . . . . . . . . . . . . . . . 24 111 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 25 113 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 26 114 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 26 115 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 28 116 6.2.6. DDAY . . . . . . . . . . . . . . . . . . . . . . . . . 28 117 6.2.7. BIRTH . . . . . . . . . . . . . . . . . . . . . . . . 29 118 6.2.8. DEATH . . . . . . . . . . . . . . . . . . . . . . . . 29 119 6.2.9. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 29 120 6.2.10. SEX . . . . . . . . . . . . . . . . . . . . . . . . . 30 121 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 30 122 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 30 123 6.3.2. LABEL . . . . . . . . . . . . . . . . . . . . . . . . 32 124 6.4. Communications Properties . . . . . . . . . . . . . . . . 32 125 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 32 126 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 33 127 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 34 128 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 34 129 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 35 130 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 35 131 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 36 132 6.6. Organizational Properties . . . . . . . . . . . . . . . . 36 133 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 36 134 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 37 135 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 38 136 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 38 137 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 39 138 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 40 139 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 42 140 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 42 141 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 42 142 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 43 143 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 43 144 6.7.5. SORT-STRING . . . . . . . . . . . . . . . . . . . . . 44 145 6.7.6. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 45 146 6.7.7. UID . . . . . . . . . . . . . . . . . . . . . . . . . 46 147 6.7.8. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47 148 6.7.9. URL . . . . . . . . . . . . . . . . . . . . . . . . . 48 149 6.7.10. VERSION . . . . . . . . . . . . . . . . . . . . . . . 48 150 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 49 151 6.8.1. CLASS . . . . . . . . . . . . . . . . . . . . . . . . 49 152 6.8.2. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 50 153 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 50 154 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 50 155 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 51 156 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 52 157 6.10. Extended Properties and Parameters . . . . . . . . . . . . 52 158 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 52 159 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 53 160 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 53 161 7.1.2. Matching Property Instances . . . . . . . . . . . . . 53 162 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 53 163 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 54 164 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 54 165 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 55 166 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 55 167 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 56 168 7.2.5. Global Context Simplification . . . . . . . . . . . . 57 169 8. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 58 170 9. Security Considerations . . . . . . . . . . . . . . . . . . . 58 171 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 172 10.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 59 173 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 60 174 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 60 175 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 61 176 10.2.3. Registration Template for Properties . . . . . . . . . 62 177 10.2.4. Registration Template for Parameters . . . . . . . . . 62 178 10.2.5. Registration Template for Value Data Types . . . . . . 63 179 10.2.6. Registration Template for Values . . . . . . . . . . . 63 180 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 64 181 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64 182 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 66 183 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 66 184 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66 185 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69 186 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 187 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69 188 12.2. Informative References . . . . . . . . . . . . . . . . . . 72 189 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 72 190 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 72 191 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 73 192 A.3. New Properties and Parameters . . . . . . . . . . . . . . 73 193 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 74 194 Appendix B. Change Log (to be removed by RFC Editor prior to 195 publication) . . . . . . . . . . . . . . . . . . . . 74 196 B.1. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 74 197 B.2. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 74 198 B.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 75 199 B.4. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 75 200 B.5. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 76 201 B.6. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 76 202 B.7. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 76 203 B.8. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 77 204 B.9. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 77 205 B.10. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 78 206 B.11. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 79 208 1. Introduction 210 Electronic address books have become ubiquitous. Their increased 211 presence on portable, connected devices as well as the diversity of 212 platforms exchanging contact data call for a standard. This memo 213 defines the vCard format, which allows the capture and exchange of 214 information normally stored within an address book or directory 215 application. 217 2. Conventions 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [RFC2119]. 223 3. vCard Format Specification 225 The text/vcard MIME content type (hereafter known as "vCard", see 226 Section 10.1) contains contact information, typically pertaining to a 227 single contact or group of contacts. The content consists of one or 228 more lines in the format given below. 230 3.1. Line Delimiting and Folding 232 Individual lines within vCard are delimited by the [RFC5322] line 233 break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII 234 decimal 10). Long logical lines of text can be split into a 235 multiple-physical-line representation using the following folding 236 technique. Content lines SHOULD be folded to a maximum width of 75 237 octets. Multi-octet characters MUST remain contiguous. The 238 rationale for this folding process can be found in [RFC5322], Section 239 2.1.1. 241 A logical line MAY be continued on the next physical line anywhere 242 between two characters by inserting a CRLF immediately followed by a 243 single white space character (space, ASCII decimal 32, or horizontal 244 tab, ASCII decimal 9). The folded line MUST contain at least one 245 character. Any sequence of CRLF followed immediately by a single 246 white space character is ignored (removed) when processing the 247 content type. For example the line: 249 DESCRIPTION:This is a long description that exists on a long line. 251 can be represented as: 253 DESCRIPTION:This is a long description 254 that exists on a long line. 256 It could also be represented as: 258 DESCRIPTION:This is a long descrip 259 tion that exists o 260 n a long line. 262 The process of moving from this folded multiple-line representation 263 of a property definition to its single line representation is called 264 unfolding. Unfolding is accomplished by regarding CRLF immediately 265 followed by a white space character (namely HTAB ASCII decimal 9 or 266 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., 267 the CRLF and single white space character are removed). 269 Note: It is possible for very simple implementations to generate 270 improperly folded lines in the middle of a UTF-8 multi-octet 271 sequence. For this reason, implementations SHOULD unfold lines in 272 such a way as to properly restore the original sequence. 274 Note: Unfolding is done differently than in [RFC5322]. Unfolding 275 in [RFC5322] only removes the CRLF, not the space following it. 277 Folding is done after any content encoding of a type value. 278 Unfolding is done before any decoding of a type value in a content 279 line. 281 3.2. ABNF Format Definition 283 The following ABNF uses the notation of [RFC5234], which also defines 284 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. 286 vcard-entity = 1*(vcard) 288 vcard = "BEGIN" ":" "VCARD" CRLF 289 1*contentline 290 "END" ":" "VCARD" CRLF 291 ;A vCard object MUST include the VERSION and FN properties. 293 contentline = [group "."] name *(";" param) ":" value CRLF 294 ; When parsing a content line, folded lines must first 295 ; be unfolded according to the unfolding procedure 296 ; described above. 297 ; When generating a content line, lines longer than 75 298 ; characters SHOULD be folded according to the folding 299 ; procedure described above. 301 group = 1*(ALPHA / DIGIT / "-") 302 name = "SOURCE" / "NAME" / "KIND" / "FN" / "N" / "NICKNAME" 303 / "PHOTO" / "BDAY" / "DDAY" / "BIRTH" / "DEATH" / "SEX" 304 / "ADR" / "LABEL" / "TEL" / "EMAIL" / "IMPP" / "LANG" 305 / "TZ" / "GEO" / "TITLE" / "ROLE" / "LOGO" / "ORG" / "MEMBER" 306 / "RELATED" / "CATEGORIES" / "NOTE" / "PRODID" / "REV" 307 / "SORT-STRING" / "SOUND" / "UID" / "CLIENTPIDMAP" / "URL" 308 / "VERSION" / "CLASS" / "KEY" / "FBURL" / "CALADRURI" 309 / "CALURI" / iana-token / x-name 310 ; Parsing of the param and value is based on the "name" as 311 ; defined in ABNF sections below. 312 ; Group and name are case-insensitive. 314 iana-token = 1*(ALPHA / DIGIT / "-") 315 ; identifier registered with IANA 317 x-name = "x-" 1*(ALPHA / DIGIT / "-") 318 ; Names that begin with "x-" or "X-" are 319 ; reserved for experimental use, not intended for released 320 ; products, or for use in bilateral agreements. 322 param = language-param / encoding-param / value-param / pref-param 323 / pid-param / type-param / geo-param / tz-param / any-param 324 ; Allowed parameters depend on property name. 326 param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE 328 any-param = (iana-token / x-name) "=" param-value 330 NON-ASCII = %x80-FF 331 ; Use is restricted by UTF-8 333 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII 334 ; Any character except CTLs, DQUOTE 336 SAFE-CHAR = WSP / %x21 / %x23-39 / %x3C-7E / NON-ASCII 337 ; Any character except CTLs, DQUOTE, ";", ":" 339 VALUE-CHAR = WSP / VCHAR / NON-ASCII 340 ; Any textual character 342 A line that begins with a white space character is a continuation of 343 the previous line, as described above. The white space character and 344 immediately preceeding CRLF should be discarded when reconstructing 345 the original line. Note that this line-folding convention differs 346 from that found in [RFC5322], in that the sequence found 347 anywhere in the content indicates a continued line and should be 348 removed. 350 Property names and parameter names are case insensitive (e.g., the 351 property name "fn" is the same as "FN" and "Fn"). Parameter values 352 MAY be case sensitive or case insensitive, depending on their 353 definition. 355 The group construct is used to group related properties together. 356 The group name is a syntactic convention used to indicate that all 357 property names prefaced with the same group name SHOULD be grouped 358 together when displayed by an application. It has no other 359 significance. Implementations that do not understand or support 360 grouping MAY simply strip off any text before a "." to the left of 361 the type name and present the types and values as normal. 363 Properties defined in a vCard instance may have multiple values 364 depending on the property cardinality. The general rule for encoding 365 multi-valued properties is to simply create a new content line for 366 each value (including the property name). However, it should be 367 noted that some value types support encoding multiple values in a 368 single content line by separating the values with a comma ",". This 369 approach has been taken for several of the content types defined 370 below (date, time, integer, float), for space-saving reasons. 372 3.3. Property Value Escaping 374 A property instance may contain one or more values delimited by a 375 COMMA character (ASCII decimal 44). Therefore, a COMMA character in 376 a value MUST be escaped with a BACKSLASH character (ASCII decimal 377 92), even for properties that don't allow multiple instances (for 378 consistency). 380 Some properties (e.g. N and ADR) comprise multiple fields delimited 381 by a SEMI-COLON character (ASCII decimal 59). Therefore, a SEMI- 382 COLON in a field of such a "compound" property MUST be escaped with a 383 BACKSLASH character. SEMI-COLON characters in non-compound 384 properties MUST NOT be escaped. 386 Furthermore, some fields of compound properties may contain a list of 387 values delimited by a COMMA character. Therefore, a COMMA character 388 in one of a field's values MUST be escaped with a BACKSLASH 389 character, even for fields that don't allow multiple values (for 390 consistency). Compound properties allowing multiple instances MUST 391 NOT be encoded in a single content line. 393 Finally, newline (ASCII decimal 10) and backslash (ASCII decimal 92) 394 characters in values MUST be escaped by prefixing them with a 395 backslash character. 397 In all other cases, escaping MUST NOT be used. 399 3.4. Character Set 401 The character set for vCard is UTF-8 as defined in [RFC3629]. There 402 is no way to override this. 404 4. Property Value Data Types 406 Standard value types are defined below. 408 value = text 409 / text-list 410 / date-list 411 / time-list 412 / date-time-list 413 / date-and-or-time-list 414 / timestamp-list 415 / boolean 416 / integer-list 417 / float-list 418 / binary 419 / URI ; from Section 3 of [RFC3986] 420 / iana-valuespec 421 ; Actual value type depends on property name and VALUE parameter. 423 text = *VALUE-CHAR 425 text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR) 427 TEXT-LIST-CHAR = "\\" / "\," / "\n" 428 / 429 ; Backslashes, commas, and newlines must be encoded. 431 date-list = date *("," date) 432 time-list = time *("," time) 433 date-time-list = date-time *("," date-time) 434 date-and-or-time-list = date-and-or-time *("," date-and-or-time) 435 timestamp-list = timestamp *("," timestamp) 436 integer-list = integer *("," integer) 437 float-list = float *("," float) 439 boolean = "TRUE" / "FALSE" 440 integer = [sign] 1*DIGIT 441 float = [sign] 1*DIGIT ["." 1*DIGIT] 443 sign = "+" / "-" 445 binary = 446 year = 4DIGIT ; 0000-9999 447 month = 2DIGIT ; 01-12 448 day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year 449 hour = 2DIGIT ; 00-23 450 minute = 2DIGIT ; 00-59 451 second = 2DIGIT ; 00-58/59/60 depending on leap second 452 zone = "Z" / utc-offset 454 date = year [month day] 455 / year "-" month 456 / "--" month [day] 457 / "--" "-" day 458 date-noreduc = year month day 459 / "--" month day 460 / "--" "-" day 461 date-complete = year month day 463 time = hour [minute [second]] [zone] 464 / "-" minute [second] [zone] 465 / "-" "-" second [zone] 466 time-notrunc = hour [minute [second]] [zone] 467 time-complete = hour minute second [zone] 469 date-time = date-noreduc "T" time-notrunc 470 timestamp = date-complete "T" time-complete 472 date-and-or-time = date-time / date / "T" time 474 utc-offset = sign hour [minute] 476 Language-Tag = 478 iana-valuespec = 479 ; a publicly-defined valuetype format, registered 480 ; with IANA, as defined in section 12 of this 481 ; document 483 4.1. TEXT 485 "text": The "text" value type should be used to identify values that 486 contain human-readable text. As for the language, it is controlled 487 by the "language" property parameter defined in Section 5.1. 489 Examples for "text": 491 this is a text value 492 this is one value,this is another 493 this is a single value\, with a comma encoded 495 A formatted text line break in a text value type MUST be represented 496 as the character sequence backslash (ASCII decimal 92) followed by a 497 Latin small letter n (ASCII decimal 110) or a Latin capital letter N 498 (ASCII decimal 78), that is "\n" or "\N". 500 For example a multiple line DESCRIPTION value of: 502 Mythical Manager 503 Hyjinx Software Division 504 BabsCo, Inc. 506 could be represented as: 508 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n 509 BabsCo\, Inc.\n 511 demonstrating the \n literal formatted line break technique, the 512 CRLF-followed-by-space line folding technique, and the backslash 513 escape technique. 515 4.2. URI 517 "uri": The "uri" value type should be used to identify values that 518 are referenced by a URI (including a Content-ID URI), instead of 519 encoded in-line. These value references might be used if the value 520 is too large, or otherwise undesirable to include directly. The 521 format for the URI is as defined in [RFC3986]. Note that the value 522 of a property of type "uri" is what the URI points to, not the URI 523 itself. 525 Examples for "uri": 527 http://www.example.com/my/picture.jpg 528 ldap://ldap.example.com/cn=babs%20jensen 530 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP 532 "date", "time", "date-time", and "timestamp": Each of these value 533 types is based on the definitions in [ISO.8601.2004] standard. 534 Multiple such values can be specified using the comma-separated 535 notation. 537 Only the basic format is supported. 539 4.3.1. DATE 541 A calendar date as specified in [ISO.8601.2004] section 4.1.2. 543 Reduced accuracy, as specified in [ISO.8601.2004] sections 4.1.2.3 a) 544 and b), but not c), is permitted. 546 Expanded representation, as specified in [ISO.8601.2004] section 547 4.1.4, is forbidden. 549 Truncated representation, as specified in [ISO.8601.2000] sections 550 5.2.1.3 d), e), and f), is permitted. 552 Examples for "date": 554 19850412 555 1985-04 556 1985 557 --0412 558 ---12 560 4.3.2. TIME 562 A time of day as specified in [ISO.8601.2004] section 4.2. 564 Reduced accuracy, as specified in [ISO.8601.2004] section 4.2.2.3, is 565 permitted. 567 Representation with decimal fraction, as specified in [ISO.8601.2004] 568 section 4.2.2.4, is forbidden. 570 Midnight is always represented by 00, never 24 (see [ISO.8601.2004] 571 section 4.2.3). 573 Truncated representation, as specified in [ISO.8601.2000] sections 574 5.3.1.4 a), b), and c), is permitted. 576 Examples for "time": 578 102200 579 1022 580 10 581 -2200 582 --00 583 102200Z 584 102200-0800 586 4.3.3. DATE-TIME 588 A date and time of day combination as specified in [ISO.8601.2004] 589 section 4.3. 591 Truncation of the date part, as specified in [ISO.8601.2000] section 592 5.4.2 c), is permitted. 594 Examples for "date-time": 596 19961022T140000 597 --1022T1400 598 ---22T14 600 4.3.4. DATE-AND-OR-TIME 602 Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous 603 interpretation, a standalone TIME value is always preceded by a "T". 605 Examples for "date-and-or-time": 607 19961022T140000 608 --1022T1400 609 ---22T14 610 19850412 611 1985-04 612 1985 613 --0412 614 ---12 615 T102200 616 T1022 617 T10 618 T-2200 619 T--00 620 T102200Z 621 T102200-0800 623 4.3.5. TIMESTAMP 625 A complete date and time of day combination as specified in 626 [ISO.8601.2004] section 4.3.2. 628 Examples for "timestamp": 630 19961022T140000 631 19961022T140000Z 632 19961022T140000-05 633 19961022T140000-0500 635 4.4. BOOLEAN 637 "boolean": The "boolean" value type is used to express boolen values. 638 These values are case insensitive. 640 Examples: 642 TRUE 643 false 644 True 646 4.5. INTEGER 648 "integer": The "integer" value type is used to express signed 649 integers in decimal format. If sign is not specified, the value is 650 assumed positive "+". Multiple "integer" values can be specified 651 using the comma-separated notation. 653 Examples: 655 1234567890 656 -1234556790 657 +1234556790,432109876 659 4.6. FLOAT 661 "float": The "float" value type is used to express real numbers. If 662 sign is not specified, the value is assumed positive "+". Multiple 663 "float" values can be specified using the comma-separated notation. 665 Examples: 667 20.30 668 1000000.0000001 669 1.333,3.14 671 4.7. BINARY 673 "binary": The "binary" value type specifies that the type value is 674 inline, encoded binary data. This value type can be specified in the 675 PHOTO, LOGO, SOUND, and KEY types. 677 If inline encoded binary data is specified, the ENCODING type 678 parameter MUST be used to specify the encoding format. The binary 679 data MUST be encoded using the "B" encoding format. Long lines of 680 encoded binary data SHOULD BE folded to 75 characters using the 681 folding method defined in Section 3.1. 683 4.8. LANGUAGE-TAG 685 "language-tag": A single language tag, as defined in [RFC5646]. 687 5. Property Parameters 689 A property can have attributes associated with it. These "property 690 parameters" contain meta-information about the property or the 691 property value. 693 Property parameter values that contain the COLON (US-ASCII decimal 694 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) 695 character separators MUST be specified as quoted-string text values. 696 Property parameter values MUST NOT contain the DQUOTE (US-ASCII 697 decimal 22) character. The DQUOTE (US-ASCII decimal 22) character is 698 used as a delimiter for parameter values that contain restricted 699 characters or URI text. 701 Property parameter values that are not in quoted strings are case 702 insensitive. 704 Applications MUST ignore x-param and iana-param values they don't 705 recognize. 707 5.1. LANGUAGE 709 The "language" property parameter is used to identify data in 710 multiple languages. There is no concept of "default" language, 711 except as specified by any "Content-Language" MIME header parameter 712 that is present. The value of the "language" property parameter is a 713 language tag as defined in Section 2 of [RFC5646]. 715 ABNF: 717 language-param = "LANGUAGE=" Language-Tag 718 ; Language-Tag is defined in section 2.1 of RFC 5646 720 5.2. ENCODING 722 The "encoding" property parameter is used to specify an alternate 723 encoding for a value. If the value contains a CRLF, it must be 724 encoded, since CRLF is used to separate lines in the content-type 725 itself. Currently, only the "b" encoding is supported. 727 The "b" encoding can also be useful for binary values that are mixed 728 with other text information in the body part (e.g., a certificate). 729 Using a per-value "b" encoding in this case leaves the other 730 information in a more readable form. The encoded base 64 value can 731 be split across multiple physical lines by using the line folding 732 technique described above. 734 The Content-Transfer-Encoding header field is used to specify the 735 encoding used for the body part as a whole. The "encoding" property 736 parameter is used to specify an encoding for a particular value 737 (e.g., a certificate). In this case, the Content-Transfer-Encoding 738 header might specify "8bit", while the one certificate value might 739 specify an encoding of "b" via an "encoding=b" property parameter. 741 The Content-Transfer-Encoding and the encodings of individual 742 properties given by the "encoding" property parameter are independent 743 of one another. When encoding a text/vcard body part for 744 transmission, individual property encodings are performed first, then 745 the entire body part is encoded according to the Content-Transfer- 746 Encoding. When decoding a text/vcard body part, the Content- 747 Transfer-Encoding is decoded first, and then any individual 748 properties with an "encoding" property parameter are decoded. 750 ABNF: 752 encoding-param = "ENCODING=" encoding-type 754 encoding-type = "b" ; from [RFC2047] 755 / iana-token ; registered as in section 12 757 5.3. VALUE 759 The "value" parameter is optional, and is used to identify the value 760 type (data type) and format of the value. The use of these 761 predefined formats is encouraged even if the value parameter is not 762 explicitly used. By defining a standard set of value types and their 763 formats, existing parsing and processing code can be leveraged. The 764 predefined data type values MUST NOT be repeated in COMMA separated 765 value lists except within the N, NICKNAME, ADR and CATEGORIES 766 properties. 768 Including the value type explicitly as part of each property provides 769 an extra hint to keep parsing simple and support more generalized 770 applications. For example a search engine would not have to know the 771 particular value types for all of the items for which it is 772 searching. Because the value type is explicit in the definition, the 773 search engine could look for dates in any item type and provide 774 results that can still be interpreted. 776 ABNF: 778 value-param = "VALUE=" value-type 780 value-type = "text" 781 / "uri" 782 / "date" 783 / "time" 784 / "date-time" 785 / "timestamp" 786 / "boolean" 787 / "integer" 788 / "float" 789 / "binary" 790 / "language-tag" 791 / iana-token ; registered as described in section 12 792 / x-name 794 5.4. PREF 796 The "pref" parameter is optional, and is used to indicate that the 797 corresponding instance of a property is preferred by the vCard 798 author. Its value MUST be an integer between 1 and 100 that 799 quantifies the level of preference. Lower values correspond to a 800 higher level of preference, 1 being most preferred. 802 When the parameter is absent, the default MUST be to interpret the 803 property instance as being least preferred. 805 Note that the value of this parameter is to be interpreted only in 806 relation to values assigned to other instances of the same property 807 in the same vCard. A given value, or the absence of a value, MUST 808 NOT be interpreted on its own. 810 This parameter MAY be applied to any property that allows multiple 811 instances. 813 ABNF: 815 pref-param = "PREF=" (1*2DIGIT / "100") 817 5.5. PID 819 The "pid" parameter is used to identify a specific property among 820 multiple instances. It plays a role analogous to the UID property 821 (Section 6.7.7) on a per-property instead of per-vCard basis. It MAY 822 appear more than once in a given property. It MUST NOT appear on 823 properties that only may have one instance per vCard. Its value is 824 either a single small integer, or a pair of small integers separated 825 by a dot. Multiple values may be encoded in a single PID parameter 826 by separating the values with a comma ",". See Section 7 for more 827 details on its usage. 829 ABNF: 831 pid-param = "PID=" pid-value *("," pid-value) 832 pid-value = 1*DIGIT ["." 1*DIGIT] 834 5.6. TYPE 836 The "type" parameter has multiple, different uses. In general, it is 837 a way of specifying class characteristics of the associated property. 838 Most of the time, its value is a comma-separated subset of a pre- 839 defined enumeration. In this document, the following properties make 840 use of this parameter: FN, NICKNAME, PHOTO, ADR, LABEL, TEL, EMAIL, 841 IMPP, LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES, 842 NOTE, SOUND, URL, KEY, FIBURL, CALADRURI, and CALURI. The TYPE 843 parameter MUST NOT be applied on other properties defined in this 844 document. 846 The "work" and "home" values can be used wherever the TYPE parameter 847 is allowed, but only when the KIND property is absent or its value is 848 "individual". They act like tags. The "work" value implies that the 849 property is related to an individual's work place, while the "home" 850 value implies that the property is related to an individual's 851 personal life. When neither "work" nor "home" is present, it is 852 implied that the property is related to both an individual's work 853 place and personal life in case the KIND property's value is 854 "individual", or to none in other cases. 856 ABNF: 858 type-param = "TYPE=" type-value *("," type-value) 860 type-value = "work" / "home" / type-param-tel 861 / type-param-related / iana-token / x-name 862 ; This is further defined in individual property sections. 864 5.7. CALSCALE 866 The "calscale" parameter is used to define the calendar system in 867 which a date or date-time value is expressed. The only value 868 specified in this document is "gregorian", which stands for the 869 Gregorian system. It is the default when the parameter is absent. 871 ABNF: 873 calscale-param = "CALSCALE=" calscale-value 875 calscale-value = "gregorian" / iana-token / x-name 877 6. vCard Properties 879 What follows is an enumeration of the standard vCard properties. 881 Property cardinalities are indicated using the following notation: 883 +-------------+--------------------------------------------------+ 884 | Cardinality | Meaning | 885 +-------------+--------------------------------------------------+ 886 | (1,1) | Exactly one instance per vCard MUST be present. | 887 | (0,1) | Exactly one instance per vCard MAY be present. | 888 | (1,n) | One or more instances per vCard MUST be present. | 889 | (0,n) | One or more instances per vCard MAY be present. | 890 +-------------+--------------------------------------------------+ 892 6.1. General Properties 894 6.1.1. BEGIN 896 Purpose: To denote the beginning of a syntactic entity within a 897 text/vcard content-type. 899 Value type: text 901 Cardinality: (1,1) 903 Special notes: The content entity MUST begin with the BEGIN property 904 with a value of "VCARD". 906 The BEGIN property is used in conjunction with the END property to 907 delimit an entity containing a related set of properties within an 908 text/vcard content-type. This construct can be used instead of or 909 in addition to wrapping separate sets of information inside 910 additional MIME headers. It is provided for applications that 911 wish to define content that can contain multiple entities within 912 the same text/vcard content-type or to define content that can be 913 identifiable outside of a MIME environment. 915 ABNF: 917 BEGIN-param = ; no parameter allowed 918 BEGIN-value = "VCARD" 920 Example: 922 BEGIN:VCARD 924 6.1.2. END 926 Purpose: To denote the end of a syntactic entity within a text/vcard 927 content-type. 929 Value type: text 931 Cardinality: (1,1) 933 Special notes: The content entity MUST end with the END type with a 934 value of "VCARD". 936 The END property is used in conjunction with the BEGIN property to 937 delimit an entity containing a related set of properties within an 938 text/vcard content-type. This construct can be used instead of or 939 in addition to wrapping separate sets of information inside 940 additional MIME headers. It is provided for applications that 941 wish to define content that can contain multiple entities within 942 the same text/vcard content-type or to define content that can be 943 identifiable outside of a MIME environment. 945 ABNF: 947 END-param = ; no parameter allowed 948 END-value = "VCARD" 950 Example: 952 END:VCARD 954 6.1.3. SOURCE 956 Purpose: To identify the source of directory information contained 957 in the content type. 959 Value type: uri 961 Cardinality: (0,n) 963 Special notes: The SOURCE property is used to provide the means by 964 which applications knowledgable in the given directory service 965 protocol can obtain additional or more up-to-date information from 966 the directory service. It contains a URI as defined in [RFC3986] 967 and/or other information referencing the vCard to which the 968 information pertains. When directory information is available 969 from more than one source, the sending entity can pick what it 970 considers to be the best source, or multiple SOURCE properties can 971 be included. 973 ABNF: 975 SOURCE-param = "VALUE=uri" / pid-param / pref-param / any-param 976 SOURCE-value = uri 978 Examples: 980 SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US 982 SOURCE:http://directory.example.com/addressbooks/jdoe/ 983 Jean%20Dupont.vcf 985 6.1.4. NAME 987 Purpose: To identify the displayable name of the directory entity to 988 which information in the vCard pertains. 990 Value type: text 992 Cardinality: (0,1) 994 Special notes: The NAME property is used to convey the display name 995 of the entity to which the directory information pertains. Its 996 value is the displayable, presentation text associated with the 997 source for the vCard, as specified in the SOURCE property. 999 ABNF: 1001 NAME-param = "VALUE=text" / any-param 1002 NAME-value = text 1004 Example: 1006 NAME:Babs Jensen's Contact Information 1008 6.1.5. KIND 1010 Purpose: To specify the kind of object the vCard represents. 1012 Value type: A single text value. 1014 Cardinality: (0,1) 1016 Special notes: The value may be one of: "individual" for a single 1017 person, "group" for a group of people, "org" for an organization, 1018 "location" for a named geographical place, "thing" for an 1019 inanimate object (e.g. a device, a server, etc.), an x-name or an 1020 iana-token. If this property is absent, "individual" MUST be 1021 assumed as default. 1023 ABNF: 1025 KIND-param = "VALUE=text" / any-param 1026 KIND-value = "individual" / "group" / "org" / "location" / "thing" 1027 / iana-token / x-name 1029 Example: 1031 This represents someone named Jane Doe working in the marketing 1032 department of the North American division of ABC Inc. 1034 BEGIN:VCARD 1035 VERSION:4.0 1036 KIND:individual 1037 FN:Jane Doe 1038 ORG:ABC\, Inc.;North American Division;Marketing 1039 END:VCARD 1041 This represents the department itself, commonly known as ABC 1042 Marketing. 1044 BEGIN:VCARD 1045 VERSION:4.0 1046 KIND:org 1047 FN:ABC Marketing 1048 ORG:ABC\, Inc.;North American Division;Marketing 1049 END:VCARD 1051 6.1.6. XML 1053 Purpose: To include XML-encoded vCard data in a plain vCard. 1055 Value type: A single text value. 1057 Cardinality: (0,n) 1058 Special notes: The content of this property is an XML chunk. Its 1059 default XML namespace is "urn:ietf:params:xml:ns:vcard-4.0". The 1060 elements allowed at the root level of this chunk are those that 1061 are allowed to be immediate children of the element 1062 defined in this document. The normal rules for extensibility 1063 apply (i.e. things in unknown namespaces are ignored). The chunk 1064 is subject to normal line folding and escaping, i.e. replace all 1065 backslashes with "\\", then replace all newlines with "\n", then 1066 fold long lines. 1068 Support for this property is OPTIONAL. The XML syntax is 1069 described in [I-D.ietf-vcarddav-vcardxml]. 1071 ABNF: 1073 XML-param = "" 1074 XML-value = text 1076 Example: The three following vCards are equivalent. 1078 1079 1080 1081 John Doe 1082 jdoe@example.com 1083 1084 1086 BEGIN:VCARD 1087 VERSION:4.0 1088 XML:John Doe>/text>\n 1089 jdoe@example.com 1090 END:VCARD 1092 BEGIN:VCARD 1093 VERSION:4.0 1094 FN:John Doe 1095 EMAIL:jdoe@example.com 1096 END:VCARD 1098 6.2. Identification Properties 1100 These types are used to capture information associated with the 1101 identification and naming of the person or resource associated with 1102 the vCard. 1104 6.2.1. FN 1106 Purpose: To specify the formatted text corresponding to the name of 1107 the object the vCard represents. 1109 Value type: A single text value. 1111 Cardinality: (1,n) 1113 Special notes: This property is based on the semantics of the X.520 1114 Common Name attribute. The property MUST be present in the vCard 1115 object. 1117 ABNF: 1119 FN-param = "VALUE=text" / type-param / language-param / pid-param 1120 / pref-param / any-param 1121 FN-value = text 1123 Example: 1125 FN:Mr. John Q. Public\, Esq. 1127 6.2.2. N 1129 Purpose: To specify the components of the name of the object the 1130 vCard represents. 1132 Value type: A single structured text value. Each component can have 1133 multiple values. 1135 Cardinality: (0,1) 1137 Special note: The structured property value corresponds, in 1138 sequence, to the Surname (also known as family name), Given Names, 1139 Honorific Prefixes, and Honorific Suffixes. The text components 1140 are separated by the SEMI-COLON character (ASCII decimal 59). 1141 Individual text components can include multiple text values 1142 separated by the COMMA character (ASCII decimal 44). This 1143 property is based on the semantics of the X.520 individual name 1144 attributes. The property SHOULD be present in the vCard object 1145 when the name of the object the vCard represents follows the X.520 1146 model. 1148 ABNF: 1150 N-param = "VALUE=text" / language-param / any-param 1151 N-value = list-component 3(";" list-component) 1153 list-component = list-component-value *("," list-component-value) 1154 list-component-value = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII 1155 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E 1157 Examples: 1159 N:Public;John,Q.;Mr.;Esq. 1161 N:Stevenson;John,Philip,Paul;Dr.;Jr.,M.D.,A.C.P. 1163 6.2.3. NICKNAME 1165 Purpose: To specify the text corresponding to the nickname of the 1166 object the vCard represents. 1168 Value type: One or more text values separated by a COMMA character 1169 (ASCII decimal 44). 1171 Cardinality: (0,n) 1173 Special note: The nickname is the descriptive name given instead of 1174 or in addition to the one belonging to a person, place, or thing. 1175 It can also be used to specify a familiar form of a proper name 1176 specified by the FN or N properties. 1178 ABNF: 1180 NICKNAME-param = "VALUE=text" / type-param / language-param 1181 / pid-param / pref-param / any-param 1182 NICKNAME-value = text-list 1184 Examples: 1186 NICKNAME:Robbie 1188 NICKNAME:Jim,Jimmie 1190 NICKNAME;TYPE=work:Boss 1192 6.2.4. PHOTO 1193 Purpose: To specify an image or photograph information that 1194 annotates some aspect of the object the vCard represents. 1196 Encoding: The encoding MUST be reset to "b" using the ENCODING 1197 parameter in order to specify inline, encoded binary data. If the 1198 value is referenced by a URI value, then the default encoding is 1199 used and no explicit ENCODING parameter is needed. 1201 Value type: A single value. The default is binary value. It can 1202 also be reset to uri value. The uri value can be used to specify 1203 a value outside of this MIME entity. 1205 Cardinality: (0,n) 1207 Special notes: This property SHOULD include the parameter "TYPE" to 1208 specify the graphic image format type. The TYPE parameter value 1209 MUST be an image media type as specified in [RFC4288]. The full 1210 media type name, including the "image/" prefix, SHOULD be used. 1211 However, implementations SHOULD be able to handle bare subtypes. 1213 ABNF: 1215 PHOTO-param = inline-param / refer-param / type-param 1216 PHOTO-value = inline-value / refer-value 1217 ; Value and parameter MUST match. 1219 PHOTO-param =/ pid-param / pref-param / any-param 1221 inline-param = "VALUE=binary" 1222 / encoding-param 1223 / "TYPE=" type-name "/" subtype-name 1224 ; from [RFC4288] section 4.2 1225 inline-value = binary 1227 refer-param = "VALUE=uri" 1228 refer-value = uri 1230 Example: 1232 PHOTO;VALUE=uri:http://www.example.com/pub/photos 1233 /jqpublic.gif 1235 PHOTO;ENCODING=b;TYPE=image/jpeg:MIICajCCAdOgAwIBAgICBEUwDQYJKo 1236 ZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENv 1237 bW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbi 1238 <...remainder of "B" encoded binary data...> 1240 6.2.5. BDAY 1242 Purpose: To specify the birth date of the object the vCard 1243 represents. 1245 Value type: The default is a single date-and-or-time value. It can 1246 also be reset to a single text value. 1248 Cardinality: (0,1) 1250 ABNF: 1252 BDAY-param = "VALUE=" ("date-and-or-time" / "text") 1253 BDAY-value = date-and-or-time / text 1254 ; Value and parameter MUST match. 1256 BDAY-param =/ calscale-param / any-param 1257 ; calscale-param can only be present when BDAY-value is 1258 ; date-and-or-time and actually contains a date or date-time. 1260 Examples: 1262 BDAY:19960415 1263 BDAY:--0415 1264 BDAY;19531015T231000Z 1265 BDAY;VALUE=text:circa 1800 1267 6.2.6. DDAY 1269 Purpose: To specify the date of death of the object the vCard 1270 represents. 1272 Value type: The default is a single date-and-or-time value. It can 1273 also be reset to a single text value. 1275 Cardinality: (0,1) 1277 ABNF: 1279 DDAY-param = "VALUE=" ("date-and-or-time" / "text") 1280 DDAY-value = date-and-or-time / text 1281 ; Value and parameter MUST match. 1283 DDAY-param =/ calscale-param / any-param 1284 ; calscale-param can only be present when DDAY-value is 1285 ; date-and-or-time and actually contains a date or date-time. 1287 6.2.7. BIRTH 1289 Purpose: To specify the place of birth of the object the vCard 1290 represents. 1292 Value type: A single text value. 1294 Cardinality: (0,1) 1296 ABNF: 1298 BIRTH-param = "VALUE=text" / language-param / any-param 1299 BIRTH-value = text 1301 Example: 1303 BIRTH:Babies'R'Us Hospital 1305 6.2.8. DEATH 1307 Purpose: To specify the place of death of the object the vCard 1308 represents. 1310 Value type: A single text value. 1312 Cardinality: (0,1) 1314 ABNF: 1316 DEATH-param = "VALUE=text" / language-param / any-param 1317 DEATH-value = text 1319 Example: 1321 DEATH:Aboard the Titanic\, near Newfoundland 1323 6.2.9. ANNIVERSARY 1325 Purpose: The date of marriage, or equivalent, of the object the 1326 vCard represents. 1328 Value type: The default is a single date-and-or-time value. It can 1329 also be reset to a single text value. 1331 Cardinality: (0,1) 1332 ABNF: 1334 ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text") 1335 ANNIVERSARY-value = date-and-or-time / text 1336 ; Value and parameter MUST match. 1338 ANNIVERSARY-param =/ calscale-param / any-param 1339 ; calscale-param can only be present when ANNIVERSARY-value is 1340 ; date-and-or-time and actually contains a date or date-time. 1342 Examples: 1344 ANNIVERSARY:19960415 1346 6.2.10. SEX 1348 Purpose: To specify the sex of the object the vCard represents, as 1349 defined in [ISO.5218.2004]. 1351 Value type: A single integer value. 1353 Cardinality: (0,1) 1355 Special notes: The value 0 stands for "not known", 1 stands for 1356 "male", 2 stands for "female", and 9 stands for "not applicable". 1358 ABNF: 1360 SEX-param = "VALUE=integer" / any-param 1361 SEX-value = "0" / "1" / "2" / "9" 1363 Example: 1365 SEX:2 1367 6.3. Delivery Addressing Properties 1369 These types are concerned with information related to the delivery 1370 addressing or label for the vCard object. 1372 6.3.1. ADR 1374 Purpose: To specify the components of the delivery address for the 1375 vCard object. 1377 Value type: A single structured text value, separated by the SEMI- 1378 COLON character (ASCII decimal 59). 1380 Cardinality: (0,n) 1382 Special notes: The structured type value consists of a sequence of 1383 address components. The component values MUST be specified in 1384 their corresponding position. The structured type value 1385 corresponds, in sequence, to the post office box; the extended 1386 address (e.g. apartment or suite number); the street address; the 1387 locality (e.g., city); the region (e.g., state or province); the 1388 postal code; the country name. When a component value is missing, 1389 the associated component separator MUST still be specified. 1391 The text components are separated by the SEMI-COLON character 1392 (ASCII decimal 59). Where it makes semantic sense, individual 1393 text components can include multiple text values (e.g., a "street" 1394 component with multiple lines) separated by the COMMA character 1395 (ASCII decimal 44). 1397 The property can include the "PREF" parameter to indicate the 1398 preferred delivery address when more than one address is 1399 specified. 1401 The GEO parameter can be used to indicate global positioning 1402 information that is specific to this address. Its value is the 1403 same as that of the GEO property. 1405 The TZ parameter can be used to indicate time zone information 1406 that is specific to this address. Its value is the same as that 1407 of the TZ property. 1409 ABNF: 1411 ADR-param = "VALUE=text" / language-param / geo-param / tz-param 1412 / pid-param / pref-param / type-param / any-param 1413 ADR-value = list-component 6(";" list-component) 1415 geo-param = "GEO=" DQUOTE uri DQUOTE 1416 tz-param = "TZ=" DQUOTE (text / uri) DQUOTE 1418 Example: In this example the post office box and the extended address 1419 are absent. 1421 ADR;GEO="geo:12.3457,78.910":;;123 Main Street;Any Town;CA 1422 ;91921-1234;USA 1424 6.3.2. LABEL 1426 Purpose: To specify the formatted text corresponding to a delivery 1427 address of the object the vCard represents. 1429 Value type: A single text value. 1431 Cardinality: (0,n) 1433 Special notes: The property value is formatted text that can be used 1434 to present a delivery address label for the vCard object. The 1435 property can include the "PREF" parameter to indicate the 1436 preferred delivery address when more than one address is 1437 specified. 1439 ABNF: 1441 LABEL-param = "VALUE=text" / language-param / pid-param 1442 / pref-param / type-param / any-param 1443 LABEL-value = text 1445 Example: A multi-line address label. 1447 LABEL:Mr.John Q. Public\, Esq.\nMail Drop: TNE QB\n 1448 123 Main Street\nAny Town\, CA 91921-1234\nU.S.A. 1450 6.4. Communications Properties 1452 These properties are concerned with information associated with the 1453 way communications with the object the vCard represents are carried 1454 out. 1456 6.4.1. TEL 1458 Purpose: To specify the telephone number for telephony communication 1459 with the object the vCard represents. 1461 Value type: A single URI value. It is expected that the URI scheme 1462 will be "tel", as specified in [RFC3966], but other schemes MAY be 1463 used. 1465 Cardinality: (0,n) 1467 Special notes: This property is based on the X.520 Telephone Number 1468 attribute. 1470 The property can include the "PREF" parameter to indicate a 1471 preferred-use telephone number. 1473 The property can include the parameter "TYPE" to specify intended 1474 use for the telephone number. The TYPE parameter values can 1475 include: "text" to indicate the telephone number supports text 1476 messages, "voice" to indicate a voice telephone number, "fax" to 1477 indicate a facsimile telephone number, "cell" to indicate a 1478 cellular or mobile telephone number, "video" to indicate a video 1479 conferencing telephone number, "pager" to indicate a paging device 1480 telephone number. The default type is "voice". These type 1481 parameter values can be specified as a parameter list (e.g., 1482 "TYPE=text;TYPE=voice") or as a value list (e.g., 1483 "TYPE=text,voice"). The default can be overridden to another set 1484 of values by specifying one or more alternate values. For 1485 example, the default TYPE of "voice" can be reset to a VOICE and 1486 FAX telephone number by the value list "TYPE=voice,fax". 1488 ABNF: 1490 TEL-param = "VALUE=uri" / type-param / pid-param / pref-param 1491 / any-param 1492 TEL-value = uri 1494 type-param-tel = "text" / "voice" / "fax" / "cell" / "video" 1495 / "pager" / iana-token / x-name 1496 ; type-param-tel MUST NOT be used with a property other than TEL. 1498 Example: 1500 TEL;PREF=1;TYPE=voice,msg,home:tel:+1-555-555-5555;ext=5555 1501 TEL;TYPE=home:tel:+33-01-23-45-67 1503 6.4.2. EMAIL 1505 Purpose: To specify the electronic mail address for communication 1506 with the object the vCard represents. 1508 Value type: A single text value. 1510 Cardinality: (0,n) 1512 Special notes: The property can include tye "PREF" parameter to 1513 indicate a preferred-use email address when more than one is 1514 specified. 1516 ABNF: 1518 EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param 1519 / any-param 1520 EMAIL-value = addr-spec ; from [RFC5322] section 3.4.1 1522 Type example: 1524 EMAIL;TYPE=work:jqpublic@xyz.example.com 1526 EMAIL;PREF=1:jane_doe@example.com 1528 6.4.3. IMPP 1530 Purpose: To specify the URI for instant messaging and presence 1531 protocol communications with the object the vCard represents. 1533 Value type: A single URI. 1535 Cardinality: (0,n) 1537 Special notes: The property may include the "PREF" parameter to 1538 indicate that this is a preferred address and has the same 1539 semantics as the "PREF" parameter in a TEL property. 1541 This property is adapted from [RFC4770], which is made obsolete by 1542 this document. 1544 ABNF: 1546 IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param 1547 / any-param 1548 IMPP-value = uri 1550 Example: 1552 IMPP;PREF=1:xmpp:alice@example.com 1554 6.4.4. LANG 1556 Purpose: To specify the language(s) that may be used for contacting 1557 the individual associated with the vCard. 1559 Value type: A single language-tag value. 1561 Cardinality: (0,n) 1563 ABNF: 1565 LANG-param = "VALUE=language-tag" / pid-param / pref-param 1566 / type-param / any-param 1567 LANG-value = Language-Tag 1569 Example: 1571 LANG;TYPE=work;PREF=1:en 1572 LANG;TYPE=work;PREF=2:fr 1573 LANG;TYPE=home:fr 1575 6.5. Geographical Properties 1577 These properties are concerned with information associated with 1578 geographical positions or regions associated with the object the 1579 vCard represents. 1581 6.5.1. TZ 1583 Purpose: To specify information related to the time zone of the 1584 object the vCard represents. 1586 Value type: The default is a single text value. It can also be 1587 reset to a single URI or utc-offset value. 1589 Cardinality: (0,n) 1591 Special notes: It is expected that names from the public-domain 1592 Olson database [TZ-DB] will be used, but this is not a 1593 restriction. 1595 Efforts are currently being directed at creating a standard URI 1596 scheme for expressing time zone information. Usage of such a 1597 scheme would ensure a high level of interoperability between 1598 implementations that support it. 1600 Note that utc-offset values SHOULD NOT be used because the UTC 1601 offset varies with time - not just because of the usual DST shifts 1602 that occur in may regions, but often entire regions will "re-base" 1603 their offset entirely. The actual offset may be +/- 1 hour (or 1604 perhaps a little more) than the one given. 1606 ABNF: 1608 TZ-param = "VALUE=" ("text" / "uri" / "utc-offset") 1609 TZ-value = text / uri / utc-offset 1610 ; Value and parameter must match 1612 TZ-param =/ pid-param / pref-param / type-param / any-param 1614 Examples: 1616 TZ:Raleigh/North America 1618 TZ;VALUE=utc-offset:-0500 1619 ; Note: utc-offset format is NOT RECOMMENDED. 1621 6.5.2. GEO 1623 Purpose: To specify information related to the global positioning of 1624 the object the vCard represents. 1626 Value type: A single URI. 1628 Cardinality: (0,n) 1630 Special notes: The "geo" URI scheme [I-D.ietf-geopriv-geo-uri] is 1631 particularly well-suited for this property, but other schemes MAY 1632 be used. 1634 ABNF: 1636 GEO-param = "VALUE=uri" / pid-param / pref-param / type-param 1637 / any-param 1638 GEO-value = uri 1640 Example: 1642 GEO:geo:37.386013,-122.082932 1644 6.6. Organizational Properties 1646 These properties are concerned with information associated with 1647 characteristics of the organization or organizational units of the 1648 object the vCard represents. 1650 6.6.1. TITLE 1651 Purpose: To specify the position or job of the object the vCard 1652 represents. 1654 Value type: A single text value. 1656 Cardinality: (0,n) 1658 Special notes: This property is based on the X.520 Title attribute. 1660 ABNF: 1662 TITLE-param = "VALUE=text" / language-param / pid-param 1663 / pref-param / type-param / any-param 1664 TITLE-value = text 1666 Example: 1668 TITLE:Research Scientist 1670 6.6.2. ROLE 1672 Purpose: To specify the function or part played in a particular 1673 situation by the object the vCard represents. 1675 Value type: A single text value. 1677 Cardinality: (0,n) 1679 Special notes: This property is based on the X.520 Business Category 1680 explanatory attribute. This property is included as an 1681 organizational type to avoid confusion with the semantics of the 1682 TITLE property and incorrect usage of that property when the 1683 semantics of this property is intended. 1685 ABNF: 1687 ROLE-param = "VALUE=text" / language-param / pid-param / pref-param 1688 / type-param / any-param 1689 ROLE-value = text 1691 Example: 1693 ROLE:Project Leader 1695 6.6.3. LOGO 1697 Purpose: To specify a graphic image of a logo associated with the 1698 object the vCard represents. 1700 Encoding: The encoding MUST be reset to "b" using the ENCODING 1701 parameter in order to specify inline, encoded binary data. If the 1702 value is referenced by a URI value, then the default encoding of 1703 8bit is used and no explicit ENCODING parameter is needed. 1705 Value type: A single value. The default is binary value. It can 1706 also be reset to uri value. The uri value can be used to specify 1707 a value outside of this MIME entity. 1709 Cardinality: (0,n) 1711 Special notes: This property SHOULD include the parameter "TYPE" to 1712 specify the graphic image format type. The TYPE parameter value 1713 MUST be an image media type as specified in [RFC4288]. The full 1714 media type name, including the "image/" prefix, SHOULD be used. 1715 However, implementations SHOULD be able to handle bare subtypes. 1717 ABNF: 1719 LOGO-param = inline-param / refer-param 1720 LOGO-value = inline-value / refer-value 1721 ; Value and parameter MUST match. 1723 LOGO-param =/ language-param / pid-param / pref-param / type-param 1724 / any-param 1726 Example: 1728 LOGO;VALUE=uri:http://www.example.com/pub/logos/abccorp.jpg 1730 LOGO;ENCODING=b;TYPE=image/jpeg:MIICajCCAdOgAwIBAgICBEUwDQYJKoZ 1731 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1732 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1733 <...the remainder of "B" encoded binary data...> 1735 6.6.4. ORG 1737 Purpose: To specify the organizational name and units associated 1738 with the vCard. 1740 Value type: A single structured text value consisting of components 1741 separated the SEMI-COLON character (ASCII decimal 59). 1743 Cardinality: (0,n) 1745 Special notes: The property is based on the X.520 Organization Name 1746 and Organization Unit attributes. The property value is a 1747 structured type consisting of the organization name, followed by 1748 zero or more levels of organizational unit names. 1750 ABNF: 1752 ORG-param = "VALUE=text" / language-param / pid-param / pref-param 1753 / type-param / any-param 1754 ORG-value = component *(";" component) 1756 component = "\\" / "\;" / "\n" / WSP / NON-ASCII 1757 / %x21-3A / %x3C-5B / %x5D-7E 1759 Example: A property value consisting of an organizational name, 1760 organizational unit #1 name and organizational unit #2 name. 1762 ORG:ABC\, Inc.;North American Division;Marketing 1764 6.6.5. MEMBER 1766 Purpose: To include a member in the group this vCard represents. 1768 Value type: A single URI. It MAY refer to something other than a 1769 vCard object. For example, an e-mail distribution list could 1770 employ the "mailto" URI scheme for efficiency. 1772 Cardinality: (0,n) 1774 Special notes: This property MUST NOT be present unless the value of 1775 the KIND property is "group". 1777 ABNF: 1779 MEMBER-param = "VALUE=uri" / pid-param / pref-param / any-param 1780 MEMBER-value = uri 1782 Examples: 1784 BEGIN:VCARD 1785 VERSION:4.0 1786 KIND:group 1787 FN:The Doe family 1788 MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1789 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1790 END:VCARD 1791 BEGIN:VCARD 1792 VERSION:4.0 1793 FN:John Doe 1794 UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1795 END:VCARD 1796 BEGIN:VCARD 1797 VERSION:4.0 1798 FN:Jane Doe 1799 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1800 END:VCARD 1802 BEGIN:VCARD 1803 VERSION:4.0 1804 KIND:group 1805 FN:Funky distribution list 1806 MEMBER:mailto:subscriber1@example.com 1807 MEMBER:xmpp:subscriber2@example.com 1808 MEMBER:sip:subscriber3@example.com 1809 MEMBER:tel:+1-418-555-5555 1810 END:VCARD 1812 6.6.6. RELATED 1814 Purpose: To specify a relationship between another person and the 1815 individual represented by this vCard. 1817 Value type: A single URI. It can also be reset to a single text 1818 value. The text value can be used to specify textual information. 1820 Cardinality: (0,n) 1822 Special notes: The TYPE parameter MAY be used to characterize the 1823 related individual. The understood types are: 1825 * "parent" means that the related individual is the parent of the 1826 individual this vCard represents. 1828 * "child" means that the related individual is the child of the 1829 individual this vCard represents. Note that the parent/child 1830 relationship does not need to be biological. 1832 * "sibling" means that the two individuals are siblings. 1834 * "spouse" for a spouse, domestic partner, or similar relation. 1836 * "family" for any other family relationship. 1838 * "friend" for a friend. 1840 * "supervisor" means that the related individual is the direct 1841 hierarchical superior (i.e. supervisor or manager) of the 1842 individual this vCard represents. 1844 * "supervisee" means the opposite of "supervisor". 1846 * "assistant" for an assistant or secretary. 1848 * "colleague" for any other workplace relationship. 1850 * "agent" for a person who may sometimes on behalf of the 1851 individual or resource associated with the vCard. 1853 * "emergency" indicates an emergency contact. 1855 Other types may be registered to IANA as described in 1856 Section 10.2, and private extensions starting with "X-" may be 1857 used. 1859 ABNF: 1861 RELATED-param = "VALUE=" ("uri" / "text") 1862 RELATED-value = uri / text 1863 ; Parameter and value MUST match. 1865 RELATED-param =/ type-param / pid-param / pref-param / type-param 1866 / any-param 1868 type-param-related = "parent" / "child" / "sibling" / "spouse" 1869 / "family" / "friend" / "supervisor" 1870 / "supervisee" / "assistant" / "colleague" 1871 / "agent" / "emergency" / iana-token / x-name 1872 ; type-param-related MUST NOT be used with a property other than 1873 ; RELATED. 1875 Examples: 1877 RELATED;TYPE=manager:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 1878 RELATED;TYPE=assistant:http://example.com/directory/jdoe.vcf 1879 RELATED;TYPE=agent;VALUE=text:Please contact my assistant Jane Doe 1880 for any inquiries. 1882 6.7. Explanatory Properties 1884 These properties are concerned with additional explanations, such as 1885 that related to informational notes or revisions specific to the 1886 vCard. 1888 6.7.1. CATEGORIES 1890 Purpose: To specify application category information about the 1891 vCard. Also known as "tags". 1893 Value type: One or more text values separated by a COMMA character 1894 (ASCII decimal 44). 1896 Cardinality: (0,n) 1898 ABNF: 1900 CATEGORIES-param = "VALUE=text" / pid-param / pref-param 1901 / type-param / any-param 1902 CATEGORIES-value = text-list 1904 Example: 1906 CATEGORIES:TRAVEL AGENT 1908 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY 1910 6.7.2. NOTE 1912 Purpose: To specify supplemental information or a comment that is 1913 associated with the vCard. 1915 Value type: A single text value. 1917 Cardinality: (0,n) 1919 Special notes: The property is based on the X.520 Description 1920 attribute. 1922 ABNF: 1924 NOTE-param = "VALUE=text" / language-param / pid-param / pref-param 1925 / type-param / any-param 1926 NOTE-value = text 1928 Example: 1930 NOTE:This fax number is operational 0800 to 1715 1931 EST\, Mon-Fri. 1933 6.7.3. PRODID 1935 Purpose: To specify the identifier for the product that created the 1936 vCard object. 1938 Type value: A single text value. 1940 Cardinality: (0,1) 1942 Special notes: Implementations SHOULD use a method such as that 1943 specified for Formal Public Identifiers in [ISO9070] or for 1944 Universal Resource Names in [RFC3406] to ensure that the text 1945 value is unique. 1947 ABNF: 1949 PRODID-param = "VALUE=text" / any-param 1950 PRODID-value = text 1952 Example: 1954 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN 1956 6.7.4. REV 1958 Purpose: To specify revision information about the current vCard. 1960 Value type: A single timestamp value. 1962 Cardinality: (0,1) 1964 Special notes: The value distinguishes the current revision of the 1965 information in this vCard for other renditions of the information. 1967 ABNF: 1969 REV-param = "VALUE=timestamp" / any-param 1970 REV-value = timestamp 1972 Example: 1974 REV:19951031T222710Z 1976 6.7.5. SORT-STRING 1978 Purpose: To specify the surname and given name text to be used for 1979 national-language-specific sorting of the FN and N types. 1981 Value type: A single structured text value with two components. The 1982 first component is associated with the surname while the second 1983 component is associated with the given name. 1985 Cardinality: (0,1) 1987 Special notes: The sort strings are used to provide surname and 1988 given name text that is to be used in sorting of the formatted 1989 name and structured name types in the context of a particular 1990 locale or national language. Without this information, sorting 1991 algorithms could incorrectly sort this vCard within a sequence of 1992 sorted vCards. When this property is present in a vCard, then the 1993 given strings are used for sorting the vCard. 1995 ABNF: 1997 SORT-STRING-param = "VALUE=text" / any-param 1998 SORT-STRING-value = list-component ";" list-component 2000 Examples: For the case of family name sorting, the following examples 2001 define common sort string usage with the FN and N properties. 2003 FN:Rene van der Harten 2004 N:van der Harten;Rene,J.;Sir;R.D.O.N. 2005 SORT-STRING:Harten;Rene 2007 FN:Robert Pau Shou Chang 2008 N:Shou Chang;Robert,Pau;; 2009 SORT-STRING:Pau Shou Chang;Robert 2011 FN:Osamu Koura 2012 N:Koura;Osamu;; 2013 SORT-STRING:Koura;Osamu 2015 FN:Oscar del Pozo 2016 N:del Pozo Triscon;Oscar;; 2017 SORT-STRING:Pozo;Oscar 2019 FN:Chistine d'Aboville 2020 N:d'Aboville;Christine;; 2021 SORT-STRING:Aboville;Christine 2023 FN:H. James de Mann 2024 N:de Mann;Henry,James;; 2025 SORT-STRING:Mann;James 2027 If sorted by surname the results would be: 2029 Christine d'Aboville 2030 Rene van der Harten 2031 Osamu Koura 2032 H. James de Mann 2033 Robert Pau Shou Chang 2034 Oscar del Pozo 2036 If sorted by given name the results would be: 2038 Christine d'Aboville 2039 H. James de Mann 2040 Osamu Koura 2041 Oscar del Pozo 2042 Rene van der Harten 2043 Robert Pau Shou Chang 2045 6.7.6. SOUND 2046 Purpose: To specify a digital sound content information that 2047 annotates some aspect of the vCard. This property is often used 2048 to specify the proper pronunciation of the name property value of 2049 the vCard. 2051 Encoding: The encoding MUST be reset to "b" using the ENCODING 2052 parameter in order to specify inline, encoded binary data. If the 2053 value is referenced by a URI value, then the default encoding of 2054 8bit is used and no explicit ENCODING parameter is needed. 2056 Value type: A single value. The default is binary value. It can 2057 also be reset to uri value. The uri value can be used to specify 2058 a value outside of this MIME entity. 2060 Cardinality: (0,n) 2062 Special notes: This property SHOULD include the parameter "TYPE" to 2063 specify the audio format type. The TYPE parameter value MUST be 2064 an audio media type as specified in [RFC4288]. The full media 2065 type name, including the "audio/" prefix, SHOULD be used. 2066 However, implementations SHOULD be able to handle bare subtypes. 2068 ABNF: 2070 SOUND-param = inline-param / refer-param 2071 SOUND-value = inline-value / refer-value 2072 ; Value and parameter MUST match. 2074 SOUND-param =/ language-param / pid-param / pref-param / type-param 2075 / any-param 2077 Example: 2079 SOUND;TYPE=audio/basic;VALUE=uri:CID:JOHNQPUBLIC.part8. 2080 19960229T080000.xyzMail@example.com 2082 SOUND;TYPE=audio/basic;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJK 2083 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 2084 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 2085 <...the remainder of "B" encoded binary data...> 2087 6.7.7. UID 2089 Purpose: To specify a value that represents a globally unique 2090 identifier corresponding to the individual or resource associated 2091 with the vCard. 2093 Value type: A single URI value. 2095 Cardinality: (0,1) 2097 Special notes: This property is used to uniquely identify the object 2098 that the vCard represents. The "uuid" URN namespace defined in 2099 [RFC4122] is particularly well-suited to this task, but other URI 2100 schemes MAY be used. 2102 ABNF: 2104 UID-param = "VALUE=uri" / any-param 2105 UID-value = uri 2107 Example: 2109 UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2111 6.7.8. CLIENTPIDMAP 2113 Purpose: To give a global meaning to a local PID source identifier. 2115 Value type: A semicolon-separated pair of values. The first field 2116 is a small integer corresponding to the second field of a PID 2117 parameter instance. The second field is a URI. The "uuid" URN 2118 namespace defined in [RFC4122] is particularly well-suited to this 2119 task, but other URI schemes MAY be used. 2121 Cardinality: (0,n) 2123 Special notes: PID source identifiers (the source identifier is the 2124 second field in a PID parameter instance) are small integers that 2125 only have significance within the scope of a single vCard 2126 instance. Each distinct source identifier present in a vCard MUST 2127 have an associated CLIENTPIDMAP. See Section 7 for more details 2128 on the usage of CLIENTPIDMAP. 2130 PID source identifiers MUST be strictly positive. Zero is not 2131 allowed. 2133 As a special exception, the PID parameter MUST NOT be applied to 2134 this property. 2136 ABNF: 2138 CLIENTPIDMAP-param = any-param 2139 CLIENTPIDMAP-value = 1*DIGIT ";" uri 2141 Example: 2143 TEL;PID=3.1,4.2:tel:+1-555-555-5555 2144 EMAIL;PID=4.1,5.2:jdoe@example.com 2145 CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b 2146 CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5 2148 6.7.9. URL 2150 Purpose: To specify a uniform resource locator associated with the 2151 object that the vCard refers to. Examples for individuals include 2152 personal web sites, blogs, and social networking site identifiers. 2154 Cardinality: (0,n) 2156 Value type: A single uri value. 2158 ABNF: 2160 URL-param = "VALUE=uri" / pid-param / pref-param / type-param 2161 / any-param 2162 URL-value = uri 2164 Example: 2166 URL:http://example.org/restaurant.french/~chezchic.html 2167 URL:http://twitters.org/myid 2168 URL:http://facebooks.org/myname 2169 URL:http://linkedins.org/myname 2171 6.7.10. VERSION 2173 Purpose: To specify the version of the vCard specification used to 2174 format this vCard. 2176 Value type: A single text value. 2178 Cardinality: (1,1) 2180 Special notes: The property MUST be present in the vCard object. 2181 The value MUST be "4.0" if the vCard corresponds to this 2182 specification. 2184 ABNF: 2186 VERSION-param = "VALUE=text" / any-param 2187 VERSION-value = "4.0" 2189 Example: 2191 VERSION:4.0 2193 6.8. Security Properties 2195 These properties are concerned with the security of communication 2196 pathways or access to the vCard. 2198 6.8.1. CLASS 2200 Purpose: To specify the access classification for a vCard object. 2202 Value type: A single text value. 2204 Cardinality: (0,1) 2206 Special notes: An access classification is only one component of the 2207 general security model for a directory service. The 2208 classification attribute provides a method of capturing the intent 2209 of the owner for general access to information described by the 2210 vCard object. 2212 Predefined values are: 2214 PUBLIC: This vCard MAY be shared with anyone. 2216 PRIVATE: This vCard MUST NOT be shared. It MAY be exported if 2217 explictly authorized and requested by the creator. 2219 CONFIDENTIAL: This vCard MAY be shared with allowed users or 2220 systems. The exact confidentiality level is site-specific and 2221 out of scope for the vCard specification. 2223 ABNF: 2225 CLASS-param = "VALUE=text" / any-param 2226 CLASS-value = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token 2227 / x-name 2229 Examples: 2231 CLASS:PUBLIC 2233 CLASS:PRIVATE 2235 CLASS:CONFIDENTIAL 2237 6.8.2. KEY 2239 Purpose: To specify a public key or authentication certificate 2240 associated with the object that the vCard represents. 2242 Encoding: The encoding MUST be reset to "b" using the ENCODING 2243 parameter in order to specify inline, encoded binary data. If the 2244 value is a text value, then the default encoding of 8bit is used 2245 and no explicit ENCODING parameter is needed. 2247 Value type: A single value. The default is binary. It can also be 2248 reset to uri value. The uri value can be used to specify a value 2249 outside of this MIME entity. In this case, the key's media type 2250 is obtained externally (e.g. with the HTTP Content-Type header) 2251 instead of with the TYPE parameter. 2253 Cardinality: (0,n) 2255 Special notes: This property SHOULD include the parameter "TYPE" to 2256 specify the public key or authentication certificate format. The 2257 TYPE parameter value MUST be a media type as specified in 2258 [RFC4288]. 2260 ABNF: 2262 KEY-param = inline-param / refer-param 2263 KEY-value = inline-value / refer-value 2264 ; Value and parameter MUST match. 2266 KEY-param =/ pid-param / pref-param / type-param / any-param 2268 Examples: 2270 KEY;VALUE=uri:http://www.example.com/keys/jdoe 2272 KEY;TYPE=application/pgp-keys;ENCODING=b:mQGiBEbEPUsRBACBF0RSIN 2273 mGutdM+KSAl7HMzwXHaLbvEOyu8At80I8qGejhzWowKbfem3X0m68Y/vhb+J2g 2274 7q11KHpnEdNb67uZaj9nTQ09Q+UFtH25qD/Afn3+9bOJQaPjAUYzXu3vD/xmN8 2275 <...remainder of "B" encoded binary data...> 2277 6.9. Calendar Properties 2279 These properties are further specified in [RFC2739]. 2281 6.9.1. FBURL 2282 Purpose: To specify the URI for a user's busy time in a vCard 2283 object. 2285 Value type: A single URI value. 2287 Cardinality: (0,n) 2289 Special notes: Where multiple FBURL properties are specified, the 2290 default FBURL property is indicated with the PREF parameter. The 2291 FTP or HTTP type of URI points to an iCalendar object associated 2292 with a snapshot of the last six weeks of the user's busy time 2293 data. If the iCalendar object is represented as a file or 2294 document, its file type should be "ifb". 2296 ABNF: 2298 FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param 2299 / any-param 2300 FBURL-value = uri 2302 Examples: 2304 FBURL;PREF=1:http://www.example.com/busy/janedoe 2305 FBURL:FTP://ftp.example.com/busy/project-a.ifb 2307 6.9.2. CALADRURI 2309 Purpose: To specify the location to which an event request should be 2310 sent for the user. 2312 Value type: A single URI value. 2314 Cardinality: (0,n) 2316 Special notes: Where multiple CALADRURI properties are specified, 2317 the default CALADRURI property is indicated with the PREF 2318 parameter. 2320 ABNF: 2322 CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2323 / any-param 2324 CALADRURI-value = uri 2326 Example: 2328 CALADRURI;PREF=1:mailto:janedoe@example.com 2329 CALADRURI:http://example.com/calendar/jdoe 2331 6.9.3. CALURI 2333 Purpose: To specify the URI for a user's calendar in a vCard object. 2335 Value type: A single URI value. 2337 Cardinality: (0,n) 2339 Special notes: Where multiple CALURI properties are specified, the 2340 default CALURI property is indicated with the PREF parameter. The 2341 property should contain a URI pointing to an iCalendar object 2342 associated with a snapshot of the user's calendar store. If the 2343 iCalendar object is represented as a file or document, its file 2344 type should be "ics". 2346 ABNF: 2348 CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2349 / any-param 2350 CALURI-value = uri 2352 Examples: 2354 CALURI;PREF=1:http://cal.example.com/calA 2355 CALURI:ftp://ftp.example.com/calA.ics 2357 6.10. Extended Properties and Parameters 2359 The properties and parameters defined by this document can be 2360 extended. Non-standard, private properties and parameters with a 2361 name starting with "X-" may be defined bilaterally between two 2362 cooperating agents without outside registration or standardization. 2364 7. Synchronization 2366 vCard data often needs to be synchronized between devices. In this 2367 context, synchronization is defined as the intelligent merging of two 2368 representations of the same object. vCard 4.0 includes mechanisms to 2369 aid this process. 2371 7.1. Mechanisms 2373 Two mechanisms are available: the UID property is used to match 2374 multiple instances of the same vCard, while the PID parameter is used 2375 to match multiple instances of the same property. 2377 The term "matching" is used here to mean recognizing that two 2378 instances are in fact representations of the same object. For 2379 example, a single vCard that is shared with someone results in two 2380 vCard instances. After they have evolved separately, they still 2381 represent the same object, and therefore may be matched by a 2382 synchronization engine. 2384 7.1.1. Matching vCard Instances 2386 vCard instances for which the UID properties (Section 6.7.7) are 2387 equivalent MUST be matched. Equivalence is determined as specified 2388 in [RFC3986], Section 6. 2390 In all other cases, vCard instances MAY be matched at the discretion 2391 of the synchronization engine. 2393 7.1.2. Matching Property Instances 2395 Property instances belonging to unmatched vCards MUST NOT be matched. 2397 Property instances whose name (e.g. EMAIL, TEL, etc.) is not the 2398 same MUST NOT be matched. 2400 Property instances whose name is CLIENTPIDMAP are handled separately 2401 and MUST NOT be matched. The synchronization MUST ensure that there 2402 is consistency of CLIENTPIDMAPs among matched vCard instances. 2404 Property instances belonging to matched vCards, whose name is the 2405 same, and whose maximum cardinality is 1 MUST be matched. 2407 Property instances belonging to matched vCards, whose name is the 2408 same, and whose PID parameters match MUST be matched. See 2409 Section 7.1.3 for details on PID matching. 2411 In all other cases, property instances MAY be matched at the 2412 discretion of the synchronization engine. 2414 7.1.3. PID Matching 2416 Two PID values for which the first fields are equivalent represent 2417 the same local value. 2419 Two PID values representing the same local value and for which the 2420 second fields point to CLIENTPIDMAP properties whose second field 2421 URIs are equivalent (as specified in [RFC3986], Section 6) also 2422 represent the same global value. 2424 PID parameters for which at least one pair of their values represent 2425 the same global value MUST be matched. 2427 In all other cases, PID parameters MAY be matched at the discretion 2428 of the synchronization engine. 2430 For example, PID value "5.1", in the first vCard below, and PID value 2431 "6.2", in the second vCard below, represent the same global value. 2433 BEGIN:VCARD 2434 VERSION:4.0 2435 EMAIL;PID=4.2,5.1:jdoe@example.com 2436 CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2437 CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc 2438 END:VCARD 2440 BEGIN:VCARD 2441 VERSION:4.0 2442 EMAIL;PID=5.1,6.2:john@example.com 2443 CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d 2444 CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2445 END:VCARD 2447 7.2. Example 2449 7.2.1. Creation 2451 The following simple vCard is first created on a given device. 2453 BEGIN:VCARD 2454 VERSION:4.0 2455 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2456 FN:J. Doe 2457 EMAIL;PID=1.1:jdoe@example.com 2458 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2459 END:VCARD 2461 This new vCard is assigned the UID 2462 "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating 2463 device. The EMAIL property is assigned PID 1, and this PID is given 2464 global context by associating it with 2465 "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which represents the 2466 creating device. The FN property has no PID because it is forbidden 2467 by its maximum cardinality of 1. 2469 7.2.2. Initial Sharing 2471 This vCard is shared with a second device. Upon inspecting the UID 2472 property, the second device understands that this is a new vCard 2473 (i.e. unmatched) and thus the synchronization results in a simple 2474 copy. 2476 7.2.3. Adding and Sharing a Property 2478 A new phone number is created on the first device, then the vCard is 2479 shared with the second device. This is what the second device 2480 receives: 2482 BEGIN:VCARD 2483 VERSION:4.0 2484 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2485 FN:J. Doe 2486 EMAIL;PID=1.1:jdoe@example.com 2487 TEL;PID=1.1:tel:+1-555-555-5555 2488 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2489 END:VCARD 2491 Upon inspecting the UID property, the second device matches the vCard 2492 it received to the vCard that it already has stored. It then starts 2493 comparing the properties of the two vCards in same-named pairs. 2495 The FN properties are matched automatically because their maximum 2496 cardinality is 1. Since the property value is the same, no update 2497 takes place. 2499 The EMAIL properties are matched because the PID parameters have the 2500 same global value. Since the property value is the same, no update 2501 takes place. 2503 The TEL property in the new vCard is not matched to any in the stored 2504 vCard because no property in the stored vCard has the same name. 2505 Therefore, this property is copied from the new vCard to the stored 2506 vCard. 2508 The CLIENTPIDMAP property is handled separately by the 2509 synchronization engine. It ensures that it is consistent with the 2510 stored one. If it was not, the results would be up to the 2511 synchronization engine, and thus undefined by this document. 2513 7.2.4. Simultaneous Editing 2515 A new email address and a new phone number are added to the vCard on 2516 each of the two devices, and then a new synchronization event 2517 happens. Here are the vCards that are communicated to each other: 2519 BEGIN:VCARD 2520 VERSION:4.0 2521 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2522 FN:J. Doe 2523 EMAIL;PID=1.1:jdoe@example.com 2524 EMAIL;PID=2.1:boss@example.com 2525 TEL;PID=1.1:tel:+1-555-555-5555 2526 TEL;PID=2.1:tel:+1-666-666-6666 2527 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2528 END:VCARD 2530 BEGIN:VCARD 2531 VERSION:4.0 2532 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2533 FN:J. Doe 2534 EMAIL;PID=1.1:jdoe@example.com 2535 EMAIL;PID=2.2:ceo@example.com 2536 TEL;PID=1.1:tel:+1-555-555-5555 2537 TEL;PID=2.2:tel:+1-666-666-6666 2538 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2539 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2540 END:VCARD 2542 On the first device, the same PID source identifier (1) is reused for 2543 the new EMAIL and TEL properties. On the second device, a new source 2544 identifier (2) is generated, and a corresponding CLIENTPIDMAP 2545 property is created. It contains the second device's identifier, 2546 "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee". 2548 The new EMAIL properties are unmatched on both sides since the PID 2549 global value is new in both cases. The sync thus results in a copy 2550 on both sides. 2552 Although the situation appears to be the same for the TEL properties, 2553 in this case the synchronization engine is particularly smart and 2554 matches the two new TEL properties even though their PID global 2555 values are different. Note that in this case, the rules of section 2556 Section 7.1.2 state that two properties may be matched at the 2557 discretion of the synchronization engine. Therefore, the two 2558 properties are merged. 2560 All this results in the following vCard which is stored on both 2561 devices: 2563 BEGIN:VCARD 2564 VERSION:4.0 2565 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2566 FN:J. Doe 2567 EMAIL;PID=1.1:jdoe@example.com 2568 EMAIL;PID=2.1:boss@example.com 2569 EMAIL;PID=2.2:ceo@example.com 2570 TEL;PID=1.1:tel:+1-555-555-5555 2571 TEL;PID=2.1,2.2:tel:+1-666-666-6666 2572 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2573 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2574 END:VCARD 2576 7.2.5. Global Context Simplification 2578 The two devices finish their synchronization procedure by simplifying 2579 their global contexts. Since they haven't talked to any other 2580 device, the following vCard is for all purposes equivalent to the 2581 above. It is also shorter. 2583 BEGIN:VCARD 2584 VERSION:4.0 2585 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2586 FN:J. Doe 2587 EMAIL;PID=1.1:jdoe@example.com 2588 EMAIL;PID=2.1:boss@example.com 2589 EMAIL;PID=3.1:ceo@example.com 2590 TEL;PID=1.1:tel:+1-555-555-5555 2591 TEL;PID=2.1:tel:+1-666-666-6666 2592 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2593 END:VCARD 2595 The details of global context simplification are unspecified by this 2596 document. They are left up to the synchronization engine. This 2597 example is merely intended to illustrate the possibility, which 2598 investigating would be, in the authors' opinion, worthwhile. 2600 8. Example: Authors' vCards 2602 BEGIN:VCARD 2603 VERSION:4.0 2604 FN:Simon Perreault 2605 N:Perreault;Simon;;ing. jr,M.Sc. 2606 BDAY:--0203 2607 ANNIVERSARY:20090808T1430-0500 2608 SEX:1 2609 LANG;PREF=1:fr 2610 LANG;PREF=2:en 2611 ORG;TYPE=work:Viagenie 2612 ADR;TYPE=work:;Suite 625;2600 boul. Laurier; 2613 Quebec;QC;G1V 4W1;Canada 2614 TEL;TYPE=work,voice;PREF=1:tel:+1-418-656-9254;ext=102 2615 TEL;TYPE=work,cell,voice,video,text:tel:+1-418-262-6501 2616 TEL;TYPE=work,fax:tel:+1-418-656-9257 2617 EMAIL;TYPE=work:simon.perreault@viagenie.ca 2618 GEO;TYPE=work:geo:46.772673,-71.282945 2619 KEY;TYPE=work;VALUE=uri: 2620 http://www.viagenie.ca/simon.perreault/simon.asc 2621 TZ:-0500 2622 CLASS:PUBLIC 2623 END:VCARD 2625 BEGIN:VCARD 2626 VERSION:4.0 2627 FN:Pete Resnick 2628 N:Resnick;Pete;; 2629 SEX:1 2630 ORG;TYPE=work:QUALCOMM Incorporated 2631 ADR;TYPE=work:;;5775 Morehouse Drive;San Diego;CA;92121-1714;US 2632 TEL;TYPE=work,voice:tel:+1-858-651-4478 2633 EMAIL;TYPE=work:presnick@qualcomm.com 2634 URL;TYPE=work:http://www.qualcomm.com/~presnick/ 2635 END:VCARD 2637 9. Security Considerations 2639 o Internet mail is often used to transport vCards and is subject to 2640 many well known security attacks, including monitoring, replay, 2641 and forgery. Care should be taken by any directory service in 2642 allowing information to leave the scope of the service itself, 2643 where any access controls can no longer be guaranteed. 2644 Applications should also take care to display directory data in a 2645 "safe" environment (e.g., PostScript-valued types). 2647 o vCards can carry cryptographic keys or certificates, as described 2648 in Section 6.8.2. 2650 o Section 6.8.1 specifies a desired security classification policy 2651 for a particular vCard. That policy is not enforced in any way. 2653 o The vCard objects have no inherent authentication or privacy, but 2654 can easily be carried by any security mechanism that transfers 2655 MIME objects with authentication or privacy. In cases where the 2656 threat of "spoofed" vCard information is a concern, the vCard 2657 SHOULD BE transported using one of these secure mechanisms. 2659 o The information in a vCard may become out of date. In cases where 2660 the vitality of data is important to an originator of a vCard, the 2661 "URL" type described in Section 6.7.9 SHOULD BE specified. In 2662 addition, the "REV" type described in section Section 6.7.4 can be 2663 specified to indicate the last time that the vCard data was 2664 updated. 2666 10. IANA Considerations 2668 10.1. MIME Type Registration 2670 To: ietf-types@iana.org 2672 Subject: Registration of media type text/vcard 2674 Type name: text 2676 Subtype name: vcard 2678 Required parameters: none 2680 Optional parameters: none 2682 Encoding considerations: The "charset" MIME parameter, if present, 2683 MUST be set to "UTF-8", as defined in [RFC3629]. 2685 Security considerations: See Section 9. 2687 Interoperability considerations: The text/vcard media type is 2688 intended to identify vCard data of any version. There are older 2689 specifications of vCard [RFC2426][oldreference_VCARD] still in 2690 common use. While these formats are similar, they are not 2691 strictly compatible. In general, it is necessary to inspect the 2692 value of the VERSION property (see Section 6.7.10) for identifying 2693 the standard to which a given vCard object conforms. 2695 In addition, the following media types are known to have been used 2696 to refer to vCard data. They should be considered deprecated in 2697 favor of text/vcard. 2699 * text/directory 2701 * text/directory; profile=vcard 2703 * text/x-vcard 2705 Published specification: draft-ietf-vcarddav-vcardrev-10 2707 Applications that use this media type: They are numerous, diverse, 2708 and include mail user agents, instant messaging clients, address 2709 book applications, directory servers, customer relationship 2710 management software, etc. 2712 Additional information: 2714 Magic number(s): 2716 File extension(s): .vcf 2718 Macintosh file type code(s): 2720 Person & email address to contact for further information: Simon 2721 Perreault 2723 Intended usage: COMMON 2725 Restrictions on usage: none 2727 Author: Simon Perreault and Pete Resnick 2729 Change controller: IETF 2731 10.2. Registering New vCard Elements 2733 This section defines the process for registering new or modified 2734 vCard elements (i.e. properties, parameters, value data types, and 2735 values) with IANA. 2737 10.2.1. Registration Procedure 2739 The IETF will create a mailing list, vcard@ietf.org [1], which can be 2740 used for public discussion of vCard element proposals prior to 2741 registration. Use of the mailing list is strongly encouraged. The 2742 IESG will appoint a designated expert who will monitor the 2743 vcard@ietf.org [1] mailing list and review registrations. 2745 Registration of new vCard elements MUST be reviewed by the designated 2746 expert and published in an RFC. A Standard Tracks RFC is REQUIRED 2747 for the registration of new value data types that modify existing 2748 properties. A Standard Tracks RFC is also REQUIRED for registration 2749 of vCard elements that modify vCard elements previously documented in 2750 a Standard Tracks RFC. 2752 The registration procedure begins when a completed registration 2753 template, defined in the sections below, is sent to 2754 vcard@ietf.org [1] and iana@iana.org [2]. The designated expert is 2755 expected to tell IANA and the submitter of the registration within 2756 two weeks whether the registration is approved, approved with minor 2757 changes, or rejected with cause. When a registration is rejected 2758 with cause, it can be re-submitted if the concerns listed in the 2759 cause are addressed. Decisions made by the designated expert can be 2760 appealed to the IESG Applications Area Director, then to the IESG. 2761 They follow the normal appeals procedure for IESG decisions. 2763 Once the registration procedure concludes successfully, IANA creates 2764 or modifies the corresponding record in the vCard registry. The 2765 completed registration template is discarded. 2767 10.2.2. Vendor Namespace 2769 The vendor namespace is used for vCard elements associated with 2770 commercially available products. "Vendor" or "producer" are 2771 construed as equivalent and very broadly in this context. 2773 A registration may be placed in the vendor namespace by anyone who 2774 needs to interchange files associated with the particular product. 2775 However, the registration formally belongs to the vendor or 2776 organization handling the vCard elements in the namespace being 2777 registered. Changes to the specification will be made at their 2778 request, as discussed in subsequent sections. 2780 vCard elements belonging to the vendor namespace will be 2781 distinguished by the "VND-" prefix. This is followed by an IANA- 2782 registered Private Enterprise Number (PEN), a dash, and a vCard 2783 element designation of the vendor's choosing (e.g., "VND-123456- 2784 MUDPIE"). 2786 While public exposure and review of vCard elements to be registered 2787 in the vendor namespace is not required, using the vcard@ietf.org [1] 2788 mailing list for review is strongly encouraged to improve the quality 2789 of those specifications. Registrations in the vendor namespace may 2790 be submitted directly to the IANA. 2792 10.2.3. Registration Template for Properties 2794 A property is defined by completing the following template. 2796 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2797 specific property (where NNNN is replaced by the vendor's PEN). 2799 Property name: The name of the property. 2801 Purpose: The purpose of the property. Give a short but clear 2802 description. 2804 Value type: Any of the valid value types for the property value 2805 needs to be specified. The default value type also needs to be 2806 specified. 2808 Cardinality: See Section 6. 2810 Property parameters: Any of the valid property parameters for the 2811 property MUST be specified. 2813 Description: Any special notes about the property, how it is to be 2814 used, etc. 2816 Format definition: The ABNF for the property definition needs to be 2817 specified. 2819 Example(s): One or more examples of instances of the property needs 2820 to be specified. 2822 10.2.4. Registration Template for Parameters 2824 A parameter is defined by completing the following template. 2826 Parameter name: The name of the parameter. 2828 Purpose: The purpose of the parameter. Give a short but clear 2829 description. 2831 Description: Any special notes about the parameter, how it is to be 2832 used, etc. 2834 Format definition: The ABNF for the parameter definition needs to be 2835 specified. 2837 Example(s): One or more examples of instances of the parameter needs 2838 to be specified. 2840 10.2.5. Registration Template for Value Data Types 2842 A value data type is defined by completing the following template. 2844 Value name: The name of the value type. 2846 Purpose: The purpose of the value type. Give a short but clear 2847 description. 2849 Description: Any special notes about the value type, how it is to be 2850 used, etc. 2852 Format definition: The ABNF for the value type definition needs to 2853 be specified. 2855 Example(s): One or more examples of instances of the value type 2856 needs to be specified. 2858 10.2.6. Registration Template for Values 2860 A value is defined by completing the following template. 2862 Value: The value literal. 2864 Purpose: The purpose of the value. Give a short but clear 2865 description. 2867 Conformance: The vCard properties and/or parameters that can take 2868 this value needs to be specified. 2870 Example(s): One or more examples of instances of the value needs to 2871 be specified. 2873 The following is a fictitious example of a registration of a vCard 2874 value: 2876 Value: TOP-SECRET 2878 Purpose: This value is used to specify the access classification of 2879 top-secret vCards. 2881 Conformance: This value can be used with the "CLASS" property. 2883 Example(s): The following is an example of this value used with the 2884 "CLASS" property: 2886 CLASS:TOP-SECRET 2888 10.3. Initial vCard Elements Registries 2890 The IANA is requested to create and maintain the following registries 2891 for vCard elements with pointers to appropriate reference documents. 2893 10.3.1. Properties Registry 2895 The following table is to be used to initialize the properties 2896 registry. 2898 +-----------+--------------+---------+-------------------------+ 2899 | Namespace | Property | Status | Reference | 2900 +-----------+--------------+---------+-------------------------+ 2901 | | SOURCE | Current | RFCXXXX, Section 6.1.3 | 2902 | | NAME | Current | RFCXXXX, Section 6.1.4 | 2903 | | KIND | Current | RFCXXXX, Section 6.1.5 | 2904 | | XML | Current | RFCXXXX, Section 6.1.6 | 2905 | | FN | Current | RFCXXXX, Section 6.2.1 | 2906 | | N | Current | RFCXXXX, Section 6.2.2 | 2907 | | NICKNAME | Current | RFCXXXX, Section 6.2.3 | 2908 | | PHOTO | Current | RFCXXXX, Section 6.2.4 | 2909 | | BDAY | Current | RFCXXXX, Section 6.2.5 | 2910 | | DDAY | Current | RFCXXXX, Section 6.2.6 | 2911 | | BIRTH | Current | RFCXXXX, Section 6.2.7 | 2912 | | DEATH | Current | RFCXXXX, Section 6.2.8 | 2913 | | ANNIVERSARY | Current | RFCXXXX, Section 6.2.9 | 2914 | | SEX | Current | RFCXXXX, Section 6.2.10 | 2915 | | ADR | Current | RFCXXXX, Section 6.3.1 | 2916 | | LABEL | Current | RFCXXXX, Section 6.3.2 | 2917 | | TEL | Current | RFCXXXX, Section 6.4.1 | 2918 | | EMAIL | Current | RFCXXXX, Section 6.4.2 | 2919 | | IMPP | Current | RFCXXXX, Section 6.4.3 | 2920 | | LANG | Current | RFCXXXX, Section 6.4.4 | 2921 | | TZ | Current | RFCXXXX, Section 6.5.1 | 2922 | | GEO | Current | RFCXXXX, Section 6.5.2 | 2923 | | TITLE | Current | RFCXXXX, Section 6.6.1 | 2924 | | ROLE | Current | RFCXXXX, Section 6.6.2 | 2925 | | LOGO | Current | RFCXXXX, Section 6.6.3 | 2926 | | ORG | Current | RFCXXXX, Section 6.6.4 | 2927 | | MEMBER | Current | RFCXXXX, Section 6.6.5 | 2928 | | RELATED | Current | RFCXXXX, Section 6.6.6 | 2929 | | CATEGORIES | Current | RFCXXXX, Section 6.7.1 | 2930 | | NOTE | Current | RFCXXXX, Section 6.7.2 | 2931 | | PRODID | Current | RFCXXXX, Section 6.7.3 | 2932 | | REV | Current | RFCXXXX, Section 6.7.4 | 2933 | | SORT-STRING | Current | RFCXXXX, Section 6.7.5 | 2934 | | SOUND | Current | RFCXXXX, Section 6.7.6 | 2935 | | UID | Current | RFCXXXX, Section 6.7.7 | 2936 | | CLIENTPIDMAP | Current | RFCXXXX, Section 6.7.8 | 2937 | | URL | Current | RFCXXXX, Section 6.7.9 | 2938 | | VERSION | Current | RFCXXXX, Section 6.7.10 | 2939 | | CLASS | Current | RFCXXXX, Section 6.8.1 | 2940 | | KEY | Current | RFCXXXX, Section 6.8.2 | 2941 | | FBURL | Current | RFCXXXX, Section 6.9.1 | 2942 | | CALADRURI | Current | RFCXXXX, Section 6.9.2 | 2943 | | CALURI | Current | RFCXXXX, Section 6.9.3 | 2944 +-----------+--------------+---------+-------------------------+ 2946 10.3.2. Parameters Registry 2948 The following table is to be used to initialize the parameters 2949 registry. 2951 +-----------+---------+------------------------+ 2952 | Parameter | Status | Reference | 2953 +-----------+---------+------------------------+ 2954 | LANGUAGE | Current | RFCXXXX, Section 5.1 | 2955 | ENCODING | Current | RFCXXXX, Section 5.2 | 2956 | VALUE | Current | RFCXXXX, Section 5.3 | 2957 | PREF | Current | RFCXXXX, Section 5.4 | 2958 | PID | Current | RFCXXXX, Section 5.5 | 2959 | TYPE | Current | RFCXXXX, Section 5.6 | 2960 | GEO | Current | RFCXXXX, Section 6.3.1 | 2961 | TZ | Current | RFCXXXX, Section 6.3.1 | 2962 +-----------+---------+------------------------+ 2964 10.3.3. Value Data Types Registry 2966 The following table is to be used to initialize the parameters 2967 registry. 2969 +------------------+---------+------------------------+ 2970 | Value Data Type | Status | Reference | 2971 +------------------+---------+------------------------+ 2972 | BINARY | Current | RFCXXXX, Section 4.7 | 2973 | BOOLEAN | Current | RFCXXXX, Section 4.4 | 2974 | DATE | Current | RFCXXXX, Section 4.3.1 | 2975 | TIME | Current | RFCXXXX, Section 4.3.2 | 2976 | DATE-TIME | Current | RFCXXXX, Section 4.3.3 | 2977 | DATE-AND-OR-TIME | Current | RFCXXXX, Section 4.3.4 | 2978 | TIMESTAMP | Current | RFCXXXX, Section 4.3.5 | 2979 | FLOAT | Current | RFCXXXX, Section 4.6 | 2980 | INTEGER | Current | RFCXXXX, Section 4.5 | 2981 | TEXT | Current | RFCXXXX, Section 4.1 | 2982 | URI | Current | RFCXXXX, Section 4.2 | 2983 | LANGUAGE-TAG | Current | RFCXXXX, Section 4.8 | 2984 +------------------+---------+------------------------+ 2986 10.3.4. Values Registries 2988 Separate tables will be used for property and parameter values. 2990 The following table is to be used to initialize the property values 2991 registry. 2993 +----------+--------------+---------+------------------------+ 2994 | Property | Value | Status | Reference | 2995 +----------+--------------+---------+------------------------+ 2996 | BEGIN | VCARD | Current | RFCXXXX, Section 6.1.1 | 2997 | END | VCARD | Current | RFCXXXX, Section 6.1.2 | 2998 | KIND | individual | Current | RFCXXXX, Section 6.1.5 | 2999 | KIND | group | Current | RFCXXXX, Section 6.1.5 | 3000 | KIND | org | Current | RFCXXXX, Section 6.1.5 | 3001 | KIND | location | Current | RFCXXXX, Section 6.1.5 | 3002 | KIND | thing | Current | RFCXXXX, Section 6.1.5 | 3003 | CLASS | PUBLIC | Current | RFCXXXX, Section 6.8.1 | 3004 | CLASS | PRIVATE | Current | RFCXXXX, Section 6.8.1 | 3005 | CLASS | CONFIDENTIAL | Current | RFCXXXX, Section 6.8.1 | 3006 +----------+--------------+---------+------------------------+ 3008 The following table is to be used to initialize the parameter values 3009 registry. 3011 +----------------+-----------+------------+---------+---------------+ 3012 | Property | Parameter | Value | Status | Reference | 3013 +----------------+-----------+------------+---------+---------------+ 3014 | FN, NICKNAME, | TYPE | work | Current | RFCXXXX, | 3015 | PHOTO, ADR, | | | | Section 5.6 | 3016 | LABEL, TEL, | | | | | 3017 | EMAIL, IMPP, | | | | | 3018 | LANG, TZ, GEO, | | | | | 3019 | TITLE, ROLE, | | | | | 3020 | LOGO, ORG, | | | | | 3021 | RELATED, | | | | | 3022 | CATEGORIES, | | | | | 3023 | NOTE, SOUND, | | | | | 3024 | URL, KEY, | | | | | 3025 | FIBURL, | | | | | 3026 | CALADRURI, and | | | | | 3027 | CALURI | | | | | 3028 | FN, NICKNAME, | TYPE | home | Current | RFCXXXX, | 3029 | PHOTO, ADR, | | | | Section 5.6 | 3030 | LABEL, TEL, | | | | | 3031 | EMAIL, IMPP, | | | | | 3032 | LANG, TZ, GEO, | | | | | 3033 | TITLE, ROLE, | | | | | 3034 | LOGO, ORG, | | | | | 3035 | RELATED, | | | | | 3036 | CATEGORIES, | | | | | 3037 | NOTE, SOUND, | | | | | 3038 | URL, KEY, | | | | | 3039 | FIBURL, | | | | | 3040 | CALADRURI, and | | | | | 3041 | CALURI | | | | | 3042 | TEL | TYPE | text | Current | RFCXXXX, | 3043 | | | | | Section 6.4.1 | 3044 | TEL | TYPE | voice | Current | RFCXXXX, | 3045 | | | | | Section 6.4.1 | 3046 | TEL | TYPE | fax | Current | RFCXXXX, | 3047 | | | | | Section 6.4.1 | 3048 | TEL | TYPE | cell | Current | RFCXXXX, | 3049 | | | | | Section 6.4.1 | 3050 | TEL | TYPE | video | Current | RFCXXXX, | 3051 | | | | | Section 6.4.1 | 3052 | TEL | TYPE | pager | Current | RFCXXXX, | 3053 | | | | | Section 6.4.1 | 3054 | RELATED | TYPE | parent | Current | RFCXXXX, | 3055 | | | | | Section 6.6.6 | 3056 | RELATED | TYPE | child | Current | RFCXXXX, | 3057 | | | | | Section 6.6.6 | 3058 | RELATED | TYPE | sibling | Current | RFCXXXX, | 3059 | | | | | Section 6.6.6 | 3060 | RELATED | TYPE | spouse | Current | RFCXXXX, | 3061 | | | | | Section 6.6.6 | 3062 | RELATED | TYPE | family | Current | RFCXXXX, | 3063 | | | | | Section 6.6.6 | 3064 | RELATED | TYPE | friend | Current | RFCXXXX, | 3065 | | | | | Section 6.6.6 | 3066 | RELATED | TYPE | supervisor | Current | RFCXXXX, | 3067 | | | | | Section 6.6.6 | 3068 | RELATED | TYPE | supervisee | Current | RFCXXXX, | 3069 | | | | | Section 6.6.6 | 3070 | RELATED | TYPE | assistant | Current | RFCXXXX, | 3071 | | | | | Section 6.6.6 | 3072 | RELATED | TYPE | colleague | Current | RFCXXXX, | 3073 | | | | | Section 6.6.6 | 3074 | RELATED | TYPE | agent | Current | RFCXXXX, | 3075 | | | | | Section 6.6.6 | 3076 | RELATED | TYPE | emergency | Current | RFCXXXX, | 3077 | | | | | Section 6.6.6 | 3078 | BDAY | CALSCALE | gregorian | Current | RFCXXXX, | 3079 | | | | | Section 6.2.5 | 3080 | DDAY | CALSCALE | gregorian | Current | RFCXXXX, | 3081 | | | | | Section 6.2.6 | 3082 | ANNIVERSARY | CALSCALE | gregorian | Current | RFCXXXX, | 3083 | | | | | Section 6.2.9 | 3084 +----------------+-----------+------------+---------+---------------+ 3086 11. Acknowledgements 3088 The authors would like to thank Tim Howes, Mark Smith, and Frank 3089 Dawson, the original authors of [RFC2425] and [RFC2426], as well as 3090 the following individuals who have participated in the drafting, 3091 review and discussion of this memo: 3093 Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil 3094 Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie 3095 Hoeneisen, Caleb Richarson, Chris Bryant, Chris Newman, Cyrus Daboo, 3096 Dan Brickley, Dan Mosedale, Dany Cauchie, Darryl Champagne, Dave 3097 Thewlis, Filip Navara, Helge Hess, Jari Urpalainen, Javier Godoy, 3098 Jean-Luc Schellens, Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, 3099 Julian Reschke, Kepeng Li, Kurt Zeilenga. Lisa Dusseault, Marc 3100 Blanchet, Mark Paterson, Markus Lorenz, Mike Douglass, Nick Levinson, 3101 Peter K. Sheerin, Peter Mogensen, Peter Saint-Andre, Renato Iannella, 3102 Sly Gryphon, Stephane Bortzmeyer, Tantek Celik, and Zoltan Ordogh. 3104 12. References 3106 12.1. Normative References 3108 [CCITT.E163.1988] International Telephone and Telegraph 3109 Consultative Committee, "Numbering Plan 3110 for the International Telephone 3111 Service", CCITT Recommendation E.163, 3112 1988. 3114 [CCITT.X121.1988] International Telephone and Telegraph 3115 Consultative Committee, "International 3116 Numbering Plan for the Public Data 3117 Networks", CCITT Recommendation X.121, 3118 1988. 3120 [CCITT.X520.1988] International International Telephone 3121 and Telegraph Consultative Committee, 3122 "Information Technology - Open Systems 3123 Interconnection - The Directory: 3125 Selected Attribute Types", 3126 CCITT Recommendation X.520, 3127 November 1988. 3129 [CCITT.X521.1988] International International Telephone 3130 and Telegraph Consultative Committee, 3131 "Information Technology - Open Systems 3132 Interconnection - The Directory: 3133 Selected Object Classes", 3134 CCITT Recommendation X.521, 3135 November 1988. 3137 [I-D.ietf-geopriv-geo-uri] Mayrhofer, A. and C. Spanring, "A 3138 Uniform Resource Identifier for 3139 Geographic Locations ('geo' URI)", 3140 draft-ietf-geopriv-geo-uri-04 (work in 3141 progress), November 2009. 3143 [I-D.ietf-vcarddav-vcardxml] Perreault, S., "vCard XML Schema", 3144 draft-ietf-vcarddav-vcardxml-02 (work 3145 in progress), March 2010. 3147 [ISO.5218.2004] International Organization for 3148 Standardization, "Information 3149 Technology - Codes for the 3150 representation of human sexes", 3151 ISO Standard 5218, December 2004. 3153 [ISO.8601.2000] International Organization for 3154 Standardization, "Data elements and 3155 interchange formats - Information 3156 interchange - Representation of dates 3157 and times", ISO Standard 8601, 3158 December 2000. 3160 [ISO.8601.2004] International Organization for 3161 Standardization, "Data elements and 3162 interchange formats - Information 3163 interchange - Representation of dates 3164 and times", ISO Standard 8601, 3165 December 2004. 3167 [RFC2046] Freed, N. and N. Borenstein, 3168 "Multipurpose Internet Mail Extensions 3169 (MIME) Part Two: Media Types", 3170 RFC 2046, November 1996. 3172 [RFC2047] Moore, K., "MIME (Multipurpose Internet 3173 Mail Extensions) Part Three: Message 3174 Header Extensions for Non-ASCII Text", 3175 RFC 2047, November 1996. 3177 [RFC2119] Bradner, S., "Key words for use in RFCs 3178 to Indicate Requirement Levels", 3179 BCP 14, RFC 2119, March 1997. 3181 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A 3182 MIME Content-Type for Directory 3183 Information", RFC 2425, September 1998. 3185 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 3186 Directory Profile", RFC 2426, 3187 September 1998. 3189 [RFC2739] Small, T., Hennessy, D., and F. Dawson, 3190 "Calendar Attributes for vCard and 3191 LDAP", RFC 2739, January 2000. 3193 [RFC3629] Yergeau, F., "UTF-8, a transformation 3194 format of ISO 10646", STD 63, RFC 3629, 3195 November 2003. 3197 [RFC3966] Schulzrinne, H., "The tel URI for 3198 Telephone Numbers", RFC 3966, 3199 December 2004. 3201 [RFC3986] Berners-Lee, T., Fielding, R., and L. 3202 Masinter, "Uniform Resource Identifier 3203 (URI): Generic Syntax", STD 66, 3204 RFC 3986, January 2005. 3206 [RFC4122] Leach, P., Mealling, M., and R. Salz, 3207 "A Universally Unique IDentifier (UUID) 3208 URN Namespace", RFC 4122, July 2005. 3210 [RFC4288] Freed, N. and J. Klensin, "Media Type 3211 Specifications and Registration 3212 Procedures", BCP 13, RFC 4288, 3213 December 2005. 3215 [RFC4770] Jennings, C. and J. Reschke, Ed., 3216 "vCard Extensions for Instant Messaging 3217 (IM)", RFC 4770, January 2007. 3219 [RFC5234] Crocker, D. and P. Overell, "Augmented 3220 BNF for Syntax Specifications: ABNF", 3221 STD 68, RFC 5234, January 2008. 3223 [RFC5322] Resnick, P., Ed., "Internet Message 3224 Format", RFC 5322, October 2008. 3226 [RFC5646] Phillips, A. and M. Davis, "Tags for 3227 Identifying Languages", BCP 47, 3228 RFC 5646, September 2009. 3230 [oldreference_VCARD] Internet Mail Consortium, "vCard - The 3231 Electronic Business Card Version 2.1", 3232 September September. 3234 12.2. Informative References 3236 [ISO9070] The International Organization for 3237 Standardization, "ISO 9070, Information 3238 Processing - SGML support facilities - 3239 Registration Procedures for Public Text 3240 Owner Identifiers", April 1991. 3242 [RFC3406] Daigle, L., van Gulik, D., Iannella, 3243 R., and P. Faltstrom, "Uniform Resource 3244 Names (URN) Namespace Definition 3245 Mechanisms", BCP 66, RFC 3406, 3246 October 2002. 3248 [TZ-DB] Olson, A., "Time zone code and data", 3249 . 3251 URIs 3253 [1] 3255 [2] 3257 Appendix A. Differences from RFCs 2425 and 2426 3259 This appendix contains a list of changes that have been made in the 3260 vCard specification from RFCs 2425 and 2426. 3262 A.1. New Structure 3264 o [RFC2425] and [RFC2426] have been merged. Initially [RFC2425] was 3265 intended to be extensible but only 2426 ever extended it. 3267 o vCard is now not only a MIME type but a stand-alone format. 3269 o A proper MIME type registration form has been included. 3271 o UTF-8 is now the default character set. 3273 o New vCard elements can be registered from IANA. 3275 o Changed "manager" to "supervisor". 3277 o Added "family", "supervisee", and "colleague" RELATED types. 3279 A.2. Removed Features 3281 o The group construct (i.e. GROUP.PROPERTY:...) no longer exists. 3283 o The CONTEXT and CHARSET parameters are no more. 3285 o The MAILER property is no more. 3287 o The "intl", "dom", "postal", and "parcel" TYPE parameter values 3288 for the ADR and LABEL properties have been removed. 3290 o Inline vCards (such as the value of the AGENT property) are no 3291 longer supported. 3293 o In the N property, additional names are now subsumed into the 3294 given names list. 3296 A.3. New Properties and Parameters 3298 o The KIND, SEX, LANG, DDAY, BIRTH, and DEATH properties have been 3299 added. 3301 o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI 3302 properties, has been merged in. 3304 o [RFC4770], which defines the IMPP property, has been merged in. 3306 o The "work", "home", and "uri" TYPE parameter values for the EMAIL 3307 property have been added. 3309 o The "pref" value of the TYPE parameter is now a parameter of its 3310 own, with a positive integer value indicating the level of 3311 preference. 3313 A.4. Other Changes 3315 o Synchronization is addressed in Section 7. 3317 o The N property is no longer mandatory. 3319 o The value of TEL is now a URI. 3321 o The AGENT property was replaced with a type of RELATED. 3323 o Date and time values now only support the basic format. 3324 Truncation is now supported. 3326 Appendix B. Change Log (to be removed by RFC Editor prior to 3327 publication) 3329 B.1. Changes in -10 3331 o Added component in SORT-STRING for sorting by given name. Fixed 3332 and expanded the examples. 3334 o Fixed KIND-value ABNF. 3336 o Fixed deprecated media type. 3338 o Created the CALSCALE parameter. 3340 o Strenghtened the stance on character set. 3342 o Defined the Language-Tag ABNF. 3344 o Made explicit the fact that IANA does not register templates. 3346 o Created the XML property. 3348 o Added social networking examples to URL property. 3350 B.2. Changes in -09 3352 o Removed special meaning for groups. Removed the "work" and "home" 3353 groups. Removed the group registry. Re-introduced the "work" and 3354 "home" TYPE parameter values. Applied the TYPE parameter to 3355 properties which supported the "work" and "home" groups. 3357 o Vendor namespace now uses private enterprise number in prefix. 3359 o Added "thing" value for KIND property. 3361 B.3. Changes in -08 3363 o Allow 1985 (year only) in date ABNF. 3365 o Fixed missing country in ADR example. 3367 o Added the DATE-AND-OR-TIME value. 3369 o Made BDAY and DDAY use DATE-AND-OR-TIME. 3371 o Prefixed "param" and "value" production rules specific to 3372 properties with the property name. 3374 o Replaced the GENDER property with the SEX property. 3376 o Added the ANNIVERSARY property. 3378 o Added the "friend" and "spouse" types of RELATED. 3380 o TZ property now has text / uri value. 3382 o Refined the definitions of TITLE and ROLE. 3384 B.4. Changes in -07 3386 o PREF is now bounded. 100 is the maximum value. 3388 o Added the "emergency" RELATED type. 3390 o Made GEO a URI. 3392 o Added GEO and TZ parameters to ADR. 3394 o Changed wording of "default" use of SOUND property. 3396 o Completely reworked the date, time, and date-time grammars. 3398 o Added the timestamp value type. 3400 o REV now has the timestamp value type. 3402 o Rewrote ABNF. 3404 o ORG can now have a single level. 3406 B.5. Changes in -06 3408 o Corrected omission of resetability to text value for RELATED. 3410 o Let KEY value type be reset to a URI value. 3412 o ABNF fixes. 3414 o Made gender values extensible. 3416 o Gave the PREF parameter a positive integer value. 3418 o Removed usage of the undefined "word" ABNF production rule. 3420 o Defined property cardinalities. 3422 o Defined properties allowable in WORK and HOME groups. 3424 o Simplified the LANG property to use the vCard preference 3425 mechanism. 3427 o Created the "language-tag" value type. 3429 o Added PID to ABNF of SOURCE allowed parameters. 3431 o Clarified escaping rules. 3433 o Changed ABNF definition of non-standard X- properties. 3435 o Removed TYPE parameter from EMAIL properties in examples. 3437 o Created the CLIENTPIDMAP property. 3439 o Changed PID value to a pair of small integers. 3441 o Completely reworked synchronization mechanisms. 3443 o Created brand new synchronization example. 3445 B.6. Changes in -05 3447 o Added multi PID value proposal. 3449 B.7. Changes in -04 3451 o Added "location" value for KIND property. 3453 o Some fixes to ABNF. 3455 o Moved "pref" from being a TYPE value to a parameter in its own 3456 right. 3458 o Removed the "work" and "home" TYPE values. 3460 o Reintroduced the group construct. 3462 o Assigned meaning to WORK and HOME groups. 3464 o Restricted the TEL TYPE parameter value set. 3466 o In N property, removed additional names, and replaced with 3467 multiple given names. 3469 o Removed TYPE parameter from EMAIL and IMPP properties. 3471 o Replaced AGENT with a type of RELATED. 3473 o Use example.org domain in URL example. 3475 o Created initial IANA table of values. 3477 o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL. 3479 B.8. Changes in -03 3481 o Various changes to the synchronization mechanisms. 3483 o Allowed truncated format for dated. See issue #236. 3485 B.9. Changes in -02 3487 o Removed useless text in IMPP description. 3489 o Added CalDAV-SCHED example to CALADRURI. 3491 o Removed CAPURI property. 3493 o Dashes in dates and colons in times are now mandatory. 3495 o Allow for dates such as 2008 and 2008-05 and times such as 07 and 3496 07:54. 3498 o Removed inline vCard value. 3500 o Made AGENT only accept URI references instead of inline vCards. 3502 o Added the MEMBER property. 3504 o Renamed the UID parameter to PID. 3506 o Changed the value type of the PID parameter to "a small integer." 3508 o Changed the presence of UID and PID when synchronization is to be 3509 used from MUST to SHOULD. 3511 o Added the RELATED (Section 6.6.6) property. 3513 o Fixed many ABNF typos (issue #252). 3515 o Changed formatting of ABNF comments to make them easier to read 3516 (issue #226). 3518 B.10. Changes in -01 3520 o Merged [RFC2739] in. 3522 o Converted all foobar.com, abc.com, etc. to example.com. 3524 o Fixed bugs in ABNF. 3526 o Made explicit that coordinates in the GEO property are expressed 3527 in the WGS 84 reference system. 3529 o Clarified folding issues with multi-byte characters. 3531 o Made the value of TEL a URI. 3533 o Added the UID parameter. 3535 o Made the UID property's value type a URI. 3537 o Added Section 7. 3539 o Created IANA process for registering new parameters, value types, 3540 and properties. 3542 o Created the initial IANA registries. 3544 o Created vendor namespace based on text from RFC 4288. 3546 B.11. Changes in -00 3548 o Name change because draft has been accepted as WG item. 3549 Otherwise, same as draft-resnick-vcarddav-vcardrev-01. 3551 o Removed reference to RFC 2234. 3553 o Fixed errata from 3554 http://www.rfc-editor.org/errata_search.php?rfc=2426. 3556 o Removed passage referring to RFC 2425 profiles. 3558 o Renamed Section 6.4 from "Telecommunications Adressing Properties" 3559 to "Communications Properties. 3561 o Added Appendix A and Appendix B. 3563 o Added reference to [RFC4770]. 3565 o Removed the group construct. 3567 o Made the N property no longer mandatory. 3569 o Added the KIND property. 3571 o Clarified meaning of TYPE parameter value for PHOTO, LOGO, KEY, 3572 and SOUND. 3574 o Removed the CONTEXT parameter. 3576 o Removed the MAILER property. 3578 o Made reference to [ISO9070] informative. 3580 o Removed "intl", "dom", "postal", and "parcel" TYPE parameter 3581 values for the ADR and LABEL properties. 3583 o Clarified meaning of "extended address" ADR field. 3585 o Mentioned [RFC3406] as another method of generating PRODID values. 3587 o Updated obsolete references. 3589 o Allowed BDAY and DDAY value types to be text values for fuzzy 3590 dates. 3592 o Removed the CHARSET property. Now the encoding is always UTF-8, 3593 except when overridden by the Content-Type (which is considered a 3594 compatibility feature). 3596 Authors' Addresses 3598 Simon Perreault 3599 Viagenie 3600 2600 boul. Laurier, suite 625 3601 Quebec, QC G1V 4W1 3602 Canada 3604 Phone: +1 418 656 9254 3605 EMail: simon.perreault@viagenie.ca 3606 URI: http://www.viagenie.ca 3608 Peter W. Resnick 3609 QUALCOMM Incorporated 3610 5775 Morehouse Drive 3611 San Diego, CA 92121-1714 3612 US 3614 Phone: +1 858 651 4478 3615 EMail: presnick@qualcomm.com 3616 URI: http://www.qualcomm.com/~presnick/