idnits 2.17.1 draft-resnick-vcarddav-vcardrev-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2335. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2008) is 5926 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) == Missing Reference: 'UNICODE' is mentioned on line 1547, but not defined == Missing Reference: 'MIME DIR' is mentioned on line 1595, but not defined == Unused Reference: 'RFC2978' is defined on line 2133, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2425 (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 4770 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Resnick 3 Internet-Draft QUALCOMM Incorporated 4 Obsoletes: 2425, 2426, 4770 S. Perreault 5 (if approved) Viagenie 6 Intended status: Standards Track February 4, 2008 7 Expires: August 7, 2008 9 vCard Format Specification 10 draft-resnick-vcarddav-vcardrev-01 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 7, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document defines the vCard data format for representing and 44 exchanging a variety of information about an individual (e.g., 45 formatted and structured name and delivery addresses, email address, 46 multiple telephone numbers, photograph, logo, audio clips, etc.). 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. MIME Type Registration . . . . . . . . . . . . . . . . . . . . 4 53 4. vCard Format Specification . . . . . . . . . . . . . . . . . . 5 54 4.1. Line Delimiting and Folding . . . . . . . . . . . . . . . 6 55 4.2. ABNF Format Definition . . . . . . . . . . . . . . . . . . 6 56 4.3. Value Types . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.4. Pre-defined Parameters . . . . . . . . . . . . . . . . . . 13 58 5. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 15 59 5.1. General Properties . . . . . . . . . . . . . . . . . . . . 15 60 5.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 15 61 5.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 16 62 5.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 16 63 5.1.4. NAME . . . . . . . . . . . . . . . . . . . . . . . . . 17 64 5.1.5. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 5.2. Identification Properties . . . . . . . . . . . . . . . . 18 66 5.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 18 67 5.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 5.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 19 69 5.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 19 70 5.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 5.2.6. DDAY . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 5.2.7. BIRTH . . . . . . . . . . . . . . . . . . . . . . . . 21 73 5.2.8. DEATH . . . . . . . . . . . . . . . . . . . . . . . . 21 74 5.2.9. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 21 75 5.3. Delivery Addressing Properties . . . . . . . . . . . . . . 21 76 5.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 5.3.2. LABEL . . . . . . . . . . . . . . . . . . . . . . . . 22 78 5.4. Communications Properties . . . . . . . . . . . . . . . . 23 79 5.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 5.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 24 81 5.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 5.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 5.5. Geographical Properties . . . . . . . . . . . . . . . . . 25 84 5.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 5.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 5.6. Organizational Properties . . . . . . . . . . . . . . . . 26 87 5.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 26 88 5.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 5.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 27 90 5.6.4. AGENT . . . . . . . . . . . . . . . . . . . . . . . . 28 91 5.6.5. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 5.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 28 93 5.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 29 94 5.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 5.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 29 96 5.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 5.7.5. SORT-STRING . . . . . . . . . . . . . . . . . . . . . 30 98 5.7.6. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 31 99 5.7.7. UID . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 5.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 5.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 32 102 5.8. Security Properties . . . . . . . . . . . . . . . . . . . 33 103 5.8.1. CLASS . . . . . . . . . . . . . . . . . . . . . . . . 33 104 5.8.2. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 33 105 5.9. Extended Properties and Parameters . . . . . . . . . . . . 34 106 6. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 34 107 7. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 44 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 111 10.1. Normative References . . . . . . . . . . . . . . . . . . . 45 112 10.2. Informative References . . . . . . . . . . . . . . . . . . 47 113 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 48 114 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 48 115 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 48 116 A.3. New Properties and Parameters . . . . . . . . . . . . . . 48 117 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 49 118 Appendix B. Change Log (to be removed by RFC Editor prior to 119 publication) . . . . . . . . . . . . . . . . . . . . 49 120 B.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 49 122 1. Introduction 124 Note: This draft contains much of the same text as 2425 and 2426 125 which may not be correct. Those two RFCs have been merged and the 126 structure of this draft is what's new. Some vCard-specific 127 suggestions have been added, but for the most part this is still very 128 open. But we'd like to get feedback on the structure mostly so that 129 it may be fixed. 131 Electronic address books have become ubiquitous. Their increased 132 presense on portable, connected devices as well as the diversity of 133 platforms exchanging contact data call for a standard. This memo 134 defines the vCard format, which allows the capture and exchange of 135 information normally stored within an address book or directory 136 application. 138 2. Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. MIME Type Registration 146 To: ietf-types@iana.org 148 Subject: Registration of media type text/vcard 150 Type name: text 152 Subtype name: vcard 154 Required parameters: none 156 Optional parameters: charset 158 Encoding considerations: The "charset" MIME parameter is interpreted 159 as defined in [RFC2046], section 4.1.2. If it is omitted, the 160 default encoding is UTF-8 as defined in [RFC3629]. 162 Security considerations: See Section 8. 164 Interoperability considerations: The text/vcard media type is 165 intended to identify vCard data of any version. There are older 166 specifications of vCard [RFC2426][oldreference_VCARD] still in 167 common use. While these formats are similar, they are not 168 strictly compatible. In general, it is necessary to inspect the 169 value of the VERSION property (see Section 5.7.9) for identifying 170 the standard to which a given vCard object conforms. 172 In addition, the following media types are known to have been used 173 to refer to vCard data. They should be considered deprecated in 174 favor of text/vcard. 176 * text/directory 178 * text/directory; type=vcard 180 * text/x-vcard 182 Published specification: draft-resnick-vcarddav-vcardrev-01 184 Applications that use this media type: They are numerous, diverse, 185 and include mail user agents, instant messaging clients, address 186 book applications, directory servers, customer relationship 187 management software, etc. 189 Additional information: 191 Magic number(s): 193 File extension(s): .vcf 195 Macintosh file type code(s): 197 Person & email address to contact for further information: Simon 198 Perreault 200 Intended usage: COMMON 202 Restrictions on usage: none 204 Author: Pete Resnick and Simon Perreault 206 Change controller: IETF 208 4. vCard Format Specification 210 The text/vcard MIME content type (hereafter known as "vCard") 211 contains contact information, typically pertaining to a single 212 contact or group of contacts. The content consists of one or more 213 lines in the format given below. 215 4.1. Line Delimiting and Folding 217 Individual lines within vCard are delimited by the [RFC2822] line 218 break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII 219 decimal 10). Long logical lines of text can be split into a 220 multiple-physical-line representation using the following folding 221 technique. After generating a content line, lines longer than 75 222 characters SHOULD be folded. 224 A logical line MAY be continued on the next physical line anywhere 225 between two characters by inserting a CRLF immediately followed by a 226 single white space character (space, ASCII decimal 32, or horizontal 227 tab, ASCII decimal 9). At least one character must be present on the 228 folded line. Any sequence of CRLF followed immediately by a single 229 white space character is ignored (removed) when processing the 230 content type. For example the line: 232 DESCRIPTION:This is a long description that exists on a long line. 234 can be represented as: 236 DESCRIPTION:This is a long description 237 that exists on a long line. 239 It could also be represented as: 241 DESCRIPTION:This is a long descrip 242 tion that exists o 243 n a long line. 245 The process of moving from this folded multiple-line representation 246 of a property definition to its single line representation is called 247 unfolding. Unfolding is accomplished by regarding CRLF immediately 248 followed by a white space character (namely HTAB ASCII decimal 9 or 249 SPACE ASCII decimal 32) as equivalent to no characters at all (i.e., 250 the CRLF and single white space character are removed). 252 Folding is done after any content encoding of a type value. 253 Unfolding is done before any decoding of a type value in a content 254 line. 256 4.2. ABNF Format Definition 258 The following ABNF uses the notation of [RFC5234], which also defines 259 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. After the unfolding of 260 any folded lines as described above, the syntax for a line of this 261 content type is as follows: 263 contentline = name *(";" param) ":" value CRLF 264 ; When parsing a content line, folded lines MUST first 265 ; be unfolded according to the unfolding procedure 266 ; described above. 267 ; When generating a content line, lines longer than 75 268 ; characters SHOULD be folded according to the folding 269 ; procedure described above. 271 name = x-name / iana-token 273 iana-token = 1*(ALPHA / DIGIT / "-") 274 ; identifier registered with IANA 276 x-name = "x-" 1*(ALPHA / DIGIT / "-") 277 ; Names that begin with "x-" or "X-" are 278 ; reserved for experimental use, not intended for released 279 ; products, or for use in bilateral agreements. 281 param = param-name "=" param-value *("," param-value) 283 param-name = x-name / iana-token 285 param-value = ptext / quoted-string 287 ptext = *SAFE-CHAR 289 value = *VALUE-CHAR 290 / valuespec ; valuespec defined in section 5.8.4 292 contentline = name *(";" param) ":" value CRLF 293 ; When parsing a content line, folded lines MUST first 294 ; be unfolded according to the unfolding procedure 295 ; described above. 296 ; When generating a content line, lines longer than 75 297 ; characters SHOULD be folded according to the folding 298 ; procedure described above. 300 name = x-name / iana-token 302 iana-token = 1*(ALPHA / DIGIT / "-") 303 ; identifier registered with IANA 305 x-name = "x-" 1*(ALPHA / DIGIT / "-") 306 ; Names that begin with "x-" or "X-" are 307 ; reserved for experimental use, not intended for released 308 ; products, or for use in bilateral agreements. 310 param = param-name "=" param-value *("," param-value) 311 param-name = x-name / iana-token 313 param-value = ptext / quoted-string 315 ptext = *SAFE-CHAR 317 value = *VALUE-CHAR 318 / valuespec ; valuespec defined in section 5.8.4 320 A line that begins with a white space character is a continuation of 321 the previous line, as described above. The white space character and 322 immediately preceeding CRLF should be discarded when reconstructing 323 the original line. Note that this line-folding convention differs 324 from that found in [RFC2822], in that the sequence found 325 anywhere in the content indicates a continued line and should be 326 removed. 328 Property names and parameter names are case insensitive (e.g., the 329 property name "fn" is the same as "FN" and "Fn"). Parameter values 330 MAY be case sensitive or case insensitive, depending on their 331 definition. 333 Each property defined in a vCard instance MAY have multiple values. 334 The general rule for encoding multi-valued properties is to simply 335 create a new content line for each value (including the property 336 name). However, it should be noted that some value types support 337 encoding multiple values in a single content line by separating the 338 values with a comma ",". This approach has been taken for several of 339 the content types defined below (date, time, integer, float), for 340 space-saving reasons. 342 4.3. Value Types 344 Lists of values are delimited by a list delimiter, specified by the 345 COMMA character (ASCII decimal 44). A COMMA character in a value 346 MUST be escaped with a BACKSLASH character (ASCII decimal 92). 348 Compound type values are delimited by a field delimiter, specified by 349 the SEMI-COLON character (ASCII decimal 59). A SEMI-COLON in a 350 component of a compound property value MUST be escaped with a 351 BACKSLASH character (ASCII decimal 92). 353 Standard value types are defined below. 355 valuespec = text-list 356 / URI ; from Appendix A of [RFC3986] 357 / date-list 358 / time-list 359 / date-time-list 360 / boolean 361 / integer-list 362 / float-list 363 / binary 364 / vcard 365 / phone-number 366 / utc-offset 367 / iana-valuespec 369 text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR) 371 TEXT-LIST-CHAR = "\\" / "\," / "\n" 372 / 373 ; Backslashes, newlines, and commas must be encoded. 374 ; \n or \N can be used to encode a newline. 376 date-list = date *("," date) 378 time-list = time *("," time) 380 date-time-list = date "T" time *("," date "T" time) 382 boolean = "TRUE" / "FALSE" 384 integer-list = integer *("," integer) 386 integer = [sign] 1*DIGIT 388 float-list = float *("," float) 390 float = [sign] 1*DIGIT ["." 1*DIGIT] 392 sign = "+" / "-" 394 binary = 396 vcard = 398 phone-number = 401 date = date-fullyear ["-"] date-month ["-"] date-mday 403 date-fullyear = 4 DIGIT 405 date-month = 2 DIGIT ;01-12 406 date-mday = 2 DIGIT ;01-28, 01-29, 01-30, 01-31 407 ;based on month/year 409 time = time-hour [":"] time-minute [":"] time-second [time-secfrac] 410 [time-zone] 412 time-hour = 2 DIGIT ;00-23 414 time-minute = 2 DIGIT ;00-59 416 time-second = 2 DIGIT ;00-60 (leap second) 418 time-secfrac = "," 1*DIGIT 420 time-zone = "Z" / time-numzone 422 time-numzome = sign time-hour [":"] time-minute 424 utc-offset = ("+" / "-") time-hour ":" time-minute 426 iana-valuespec = 430 Some specific notes on the value types and formats: 432 "text": The "text" value type should be used to identify values that 433 contain human-readable text. The character set in which the text is 434 represented is controlled by the "charset" MIME type parameter. Note 435 that there is no way to override this parameter on a per-property 436 basis. As for the language, it is controlled by the "language" 437 property parameter defined in Section 4.4. 439 Examples for "text": 441 this is a text value 442 this is one value,this is another 443 this is a single value\, with a comma encoded 445 A formatted text line break in a text value type MUST be represented 446 as the character sequence backslash (ASCII decimal 92) followed by a 447 Latin small letter n (ASCII decimal 110) or a Latin capital letter N 448 (ASCII decimal 78), that is "\n" or "\N". 450 For example a multiple line DESCRIPTION value of: 452 Mythical Manager 453 Hyjinx Software Division 454 BabsCo, Inc. 456 could be represented as: 458 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n 459 BabsCo\, Inc.\n 461 demonstrating the \n literal formatted line break technique, the 462 CRLF-followed-by-space line folding technique, and the backslash 463 escape technique. 465 "uri": The "uri" value type should be used to identify values that 466 are referenced by a URI (including a Content-ID URI), instead of 467 encoded in-line. These value references might be used if the value 468 is too large, or otherwise undesirable to include directly. The 469 format for the URI is as defined in [RFC3986]. Note that the value 470 of a property of type "uri" is what the URI points to, not the URI 471 itself. 473 Examples for "uri": 475 http://www.foobar.com/my/picture.jpg 476 ldap://ldap.foobar.com/cn=babs%20jensen 478 "date", "time", and "date-time": Each of these value types is based 479 on a subset of the definitions in [ISO.8601.1988] standard. Multiple 480 "date" and "time" values can be specified using the comma-separated 481 notation. 483 Examples for "date": 485 1985-04-12 486 1996-08-05,1996-11-11 487 19850412 489 Examples for "time": 491 10:22:00 492 102200 493 10:22:00.33 494 10:22:00.33Z 495 10:22:33,11:22:00 496 10:22:00-08:00 498 Examples for "date-time": 500 1996-10-22T14:00:00Z 501 1996-08-11T12:34:56Z 502 19960811T123456Z 503 1996-10-22T14:00:00Z,1996-08-11T12:34:56Z 505 "boolean": The "boolean" value type is used to express boolen values. 506 These values are case insensitive. 508 Examples: 510 TRUE 511 false 512 True 514 "integer": The "integer" value type is used to express signed 515 integers in decimal format. If sign is not specified, the value is 516 assumed positive "+". Multiple "integer" values can be specified 517 using the comma-separated notation. 519 Examples: 521 1234567890 522 -1234556790 523 +1234556790,432109876 525 "float": The "float" value type is used to express real numbers. If 526 sign is not specified, the value is assumed positive "+". Multiple 527 "float" values can be specified using the comma-separated notation. 529 Examples: 531 20.30 532 1000000.0000001 533 1.333,3.14 535 "binary": The "binary" value type specifies that the type value is 536 inline, encoded binary data. This value type can be specified in the 537 PHOTO, LOGO, SOUND, and KEY types. 539 If inline encoded binary data is specified, the ENCODING type 540 parameter MUST be used to specify the encoding format. The binary 541 data MUST be encoded using the "B" encoding format. Long lines of 542 encoded binary data SHOULD BE folded to 75 characters using the 543 folding method defined in Section 4.1. 545 "vcard": The "vcard" value type specifies that the type value is 546 another vCard. This value type can be specified in the AGENT 547 property. The value type is defined by this specification. Since 548 each of the type declarations within the vcard value type are being 549 specified within a text value themselves, they MUST be terminated 550 with the backslash escape sequence "\n" or "\N", instead of the 551 normal newline character sequence CRLF. In addition, any COMMA 552 character (ASCII decimal 44), SEMI-COLON character (ASCII decimal 59) 553 and COLON character (ASCII decimal 58) MUST be escaped with the 554 BACKSLASH character (ASCII decimal 92). For example, with the AGENT 555 property a value would be specified as: 557 AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n 558 TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERN\n 559 ET:jfriday@host.com\nEND:VCARD\n 561 "phone-number": The "phone-number" value type specifies that the type 562 value is a telephone number. This value type can be specified in the 563 TEL type. The value type is a text value that has the special 564 semantics of a telephone number as defined in [CCITT.E163.1988] and 565 [CCITT.X121.1988]. 567 "utc-offset": The "utc-offset" value type specifies that the type 568 value is a signed offset from UTC. This value type can be specified 569 in the TZ type. 571 The value type is an offset from Coordinated Universal Time (UTC). 572 It is specified as a positive or negative difference in units of 573 hours and minutes (e.g., +hh:mm). The time is specified as a 24-hour 574 clock. Hour values are from 00 to 23, and minute values are from 00 575 to 59. Hour and minutes are 2-digits with high order zeroes required 576 to maintain digit count. The extended format for ISO 8601 UTC 577 offsets MUST be used. The extended format makes use of a colon 578 character as a separator of the hour and minute text fields. 580 4.4. Pre-defined Parameters 582 The following parameters are defined for general use. 584 predefined-param = encodingparm 585 / valuetypeparm 586 / languageparm 588 encodingparm = "encoding" "=" encodingtype 590 encodingtype = "b" ; from [RFC2047] 591 / iana-token ; registered as described in 592 ; section 15 of this document 594 predefined-param = encodingparm 595 / valuetypeparm 596 / languageparm 598 encodingparm = "encoding" "=" encodingtype 600 encodingtype = "b" ; from [RFC2047] 601 / iana-token ; registered as described in 602 ; section 15 of this document 604 predefined-param = encodingparm 605 / valuetypeparm 606 / languageparm 608 encodingparm = "encoding" "=" encodingtype 610 encodingtype = "b" ; from [RFC2047] 611 / iana-token ; registered as described in 612 ; section 15 of this document 614 The "language" property parameter is used to identify data in 615 multiple languages. There is no concept of "default" language, 616 except as specified by any "Content-Language" MIME header parameter 617 that is present. The value of the "language" property parameter is a 618 language tag as defined in Section 2 of [RFC4646]. 620 The "encoding" property parameter is used to specify an alternate 621 encoding for a value. If the value contains a CRLF, it must be 622 encoded, since CRLF is used to separate lines in the content-type 623 itself. Currently, only the "b" encoding is supported. 625 The "b" encoding can also be useful for binary values that are mixed 626 with other text information in the body part (e.g., a certificate). 627 Using a per-value "b" encoding in this case leaves the other 628 information in a more readable form. The encoded base 64 value can 629 be split across multiple physical lines by using the line folding 630 technique described above. 632 The Content-Transfer-Encoding header field is used to specify the 633 encoding used for the body part as a whole. The "encoding" property 634 parameter is used to specify an encoding for a particular value 635 (e.g., a certificate). In this case, the Content-Transfer-Encoding 636 header might specify "8bit", while the one certificate value might 637 specify an encoding of "b" via an "encoding=b" property parameter. 639 The Content-Transfer-Encoding and the encodings of individual 640 properties given by the "encoding" property parameter are independent 641 of one another. When encoding a text/vcard body part for 642 transmission, individual property encodings are performed first, then 643 the entire body part is encoded according to the Content-Transfer- 644 Encoding. When decoding a text/vcard body part, the Content- 645 Transfer-Encoding is decoded first, and then any individual 646 properties with an "encoding" property parameter are decoded. 648 The "value" parameter is optional, and is used to identify the value 649 type (data type) and format of the value. The use of these 650 predefined formats is encouraged even if the value parameter is not 651 explicity used. By defining a standard set of value types and their 652 formats, existing parsing and processing code can be leveraged. The 653 predefined data type values MUST NOT be repeated in COMMA separated 654 value lists except within the N, NICKNAME, ADR and CATEGORIES 655 properties. 657 Including the value type explicitly as part of each property provides 658 an extra hint to keep parsing simple and support more generalized 659 applications. For example a search engine would not have to know the 660 particular value types for all of the items for which it is 661 searching. Because the value type is explicit in the definition, the 662 search engine could look for dates in any item type and provide 663 results that can still be interpreted. 665 5. vCard Properties 667 What follows is an enumeration of the standard vCard properties. 669 5.1. General Properties 671 5.1.1. BEGIN 673 Purpose: To denote the beginning of a syntactic entity within a 674 text/vcard content-type. 676 Value type: text 677 Special notes: The content entity MUST begin with the BEGIN property 678 with a value of "VCARD". 680 The BEGIN type is used in conjunction with the END type to delimit 681 an entity containing a related set of properties within an text/ 682 vcard content-type. This construct can be used instead of or in 683 addition to wrapping separate sets of information inside 684 additional MIME headers. It is provided for applications that 685 wish to define content that can contain multiple entities within 686 the same text/vcard content-type or to define content that can be 687 identifiable outside of a MIME environment. 689 Example: 691 BEGIN:VCARD 693 5.1.2. END 695 Purpose: To denote the end of a syntactic entity within a text/vcard 696 content-type. 698 Value type: text 700 Special notes: The content entity MUST end with the END type with a 701 value of "VCARD". 703 The END type is used in conjunction with the BEGIN type to delimit 704 an entity containing a related set of properties within an text/ 705 vcard content-type. This construct can be used instead of or in 706 addition to wrapping separate sets of information inside 707 additional MIME headers. It is provided for applications that 708 wish to define content that can contain multiple entities within 709 the same text/vcard content-type or to define content that can be 710 identifiable outside of a MIME environment. 712 Example: 714 END:VCARD 716 5.1.3. SOURCE 718 Purpose: To identify the source of directory information contained 719 in the content type. 721 Value type: uri 722 Special notes: The SOURCE property is used to provide the means by 723 which applications knowledgable in the given directory service 724 protocol can obtain additional or more up-to-date information from 725 the directory service. It contains a URI as defined in [RFC3986] 726 and/or other information referencing the vCard to which the 727 information pertains. When directory information is available 728 from more than one source, the sending entity can pick what it 729 considers to be the best source, or multiple SOURCE properties can 730 be included. 732 Examples: 734 SOURCE:ldap://ldap.host/cn=Babs%20Jensen,%20o=Babsco,%20c=US 736 SOURCE:http://directory.example.com/addressbooks/jdoe/ 737 Jean%20Dupont.vcf 739 5.1.4. NAME 741 Purpose: To identify the displayable name of the directory entity to 742 which information in the vCard pertains. 744 Value type: text 746 Special notes: The NAME property is used to convey the display name 747 of the entity to which the directory information pertains. Its 748 value is the displayable, presentation text associated with the 749 source for the vCard, as specified in the SOURCE property. 751 Example: 753 NAME:Babs Jensen's Contact Information 755 5.1.5. KIND 757 Purpose: To specify the kind of object the vCard represents. 759 Value type: A single text value. 761 Special notes: The value may be one of: "individual" for a single 762 person, "group" for a group of people, "org" for an organization, 763 an x-name or an iana-token. If this property is absent, 764 "individual" MUST be assumed as default. 766 Example: 768 This represents someone named Jane Doe working in the marketing 769 department of the North American division of ABC Inc. 771 BEGIN:VCARD 772 VERSION:4.0 773 KIND:individual 774 FN:Jane Doe 775 ORG:ABC\, Inc.;North American Division;Marketing 776 END:VCARD 778 This represents the department itself, commonly known as ABC 779 Marketing. 781 BEGIN:VCARD 782 VERSION:4.0 783 KIND:org 784 FN:ABC Marketing 785 ORG:ABC\, Inc.;North American Division;Marketing 786 END:VCARD 788 5.2. Identification Properties 790 These types are used to capture information associated with the 791 identification and naming of the person or resource associated with 792 the vCard. 794 5.2.1. FN 796 Purpose: To specify the formatted text corresponding to the name of 797 the object the vCard represents. 799 Value type: A single text value. 801 Special notes: This property is based on the semantics of the X.520 802 Common Name attribute. The property MUST be present in the vCard 803 object. 805 Example: 807 FN:Mr. John Q. Public\, Esq. 809 5.2.2. N 811 Purpose: To specify the components of the name of the object the 812 vCard represents. 814 Value type: A single structured text value. Each component can have 815 multiple values. 817 Special note: The structured type value corresponds, in sequence, to 818 the Family Name, Given Name, Additional Names, Honorific Prefixes, 819 and Honorific Suffixes. The text components are separated by the 820 SEMI-COLON character (ASCII decimal 59). Individual text 821 components can include multiple text values (e.g., multiple 822 Additional Names) separated by the COMMA character (ASCII decimal 823 44). This type is based on the semantics of the X.520 individual 824 name attributes. The property SHOULD be present in the vCard 825 object when the name of the object the vCard represents follows 826 the X.520 model. 828 Examples: 830 N:Public;John;Quinlan;Mr.;Esq. 832 N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P. 834 5.2.3. NICKNAME 836 Purpose: To specify the text corresponding to the nickname of the 837 object the vCard represents. 839 Value type: One or more text values separated by a COMMA character 840 (ASCII decimal 44). 842 Special note: The nickname is the descriptive name given instead of 843 or in addition to the one belonging to a person, place, or thing. 844 It can also be used to specify a familiar form of a proper name 845 specified by the FN or N types. 847 Examples: 849 NICKNAME:Robbie 851 NICKNAME:Jim,Jimmie 853 5.2.4. PHOTO 855 Purpose: To specify an image or photograph information that 856 annotates some aspect of the object the vCard represents. 858 Encoding: The encoding MUST be reset to "b" using the ENCODING 859 parameter in order to specify inline, encoded binary data. If the 860 value is referenced by a URI value, then the default encoding is 861 used and no explicit ENCODING parameter is needed. 863 Value type: A single value. The default is binary value. It can 864 also be reset to uri value. The uri value can be used to specify 865 a value outside of this MIME entity. 867 Special notes: This property SHOULD include the parameter "TYPE" to 868 specify the graphic image format type. The TYPE parameter value 869 MUST be an image media type as specified in [RFC4288]. The full 870 media type name, including the "image/" prefix, should be used. 871 However, implementations SHOULD be able to handle bare subtypes. 873 Example: 875 PHOTO;VALUE=uri:http://www.abc.com/pub/photos 876 /jqpublic.gif 878 PHOTO;ENCODING=b;TYPE=image/jpeg:MIICajCCAdOgAwIBAgICBEUwDQYJKo 879 ZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENv 880 bW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbi 881 <...remainder of "B" encoded binary data...> 883 5.2.5. BDAY 885 Purpose: To specify the birth date of the object the vCard 886 represents. 888 Value type: The default is a single date value. It can also be 889 reset to a single date-time or text value. 891 Examples: 893 BDAY:1996-04-15 895 BDAY:1953-10-15T23:10:00Z 897 BDAY;VALUE=text:circa 1800 899 5.2.6. DDAY 901 Purpose: To specify the date of death of the object the vCard 902 represents. 904 Value type: The default is a single date value. It can also be 905 reset to a single date-time or text value. 907 5.2.7. BIRTH 909 Purpose: To specify the place of birth of the object the vCard 910 represents. 912 Value type: A single text value. 914 Example: 916 BIRTH:Babies'R'Us Hospital 918 5.2.8. DEATH 920 Purpose: To specify the place of death of the object the vCard 921 represents. 923 Value type: A single text value. 925 Example: 927 DEATH:Aboard the Titanic\, near Newfoundland 929 5.2.9. GENDER 931 Purpose: To specify the gender of the object the vCard represents. 933 Value type: A single text value. 935 Special notes: The value "M" stands for male while "F" stands for 936 female. 938 Example: 940 GENDER:F 942 5.3. Delivery Addressing Properties 944 These types are concerned with information related to the delivery 945 addressing or label for the vCard object. 947 5.3.1. ADR 949 Purpose: To specify the components of the delivery address for the 950 vCard object. 952 Value type: A single structured text value, separated by the SEMI- 953 COLON character (ASCII decimal 59). 955 Special notes: The structured type value consists of a sequence of 956 address components. The component values MUST be specified in 957 their corresponding position. The structured type value 958 corresponds, in sequence, to the post office box; the extended 959 address (e.g. apartment or suite number); the street address; the 960 locality (e.g., city); the region (e.g., state or province); the 961 postal code; the country name. When a component value is missing, 962 the associated component separator MUST still be specified. 964 The text components are separated by the SEMI-COLON character 965 (ASCII decimal 59). Where it makes semantic sense, individual 966 text components can include multiple text values (e.g., a "street" 967 component with multiple lines) separated by the COMMA character 968 (ASCII decimal 44). 970 The type can include the type parameter "TYPE" to specify the 971 delivery address type. The TYPE parameter values can include 972 "home" to indicate a delivery address for a residence; "work" to 973 indicate delivery address for a place of work; and "pref" to 974 indicate the preferred delivery address when more than one address 975 is specified. These type parameter values can be specified as a 976 parameter list (i.e., "TYPE=home;TYPE=pref") or as a value list 977 (i.e., "TYPE=home,pref"). This type is based on semantics of the 978 X.520 geographical and postal addressing attributes. The default 979 is "TYPE=work". 981 Example: In this example the post office box and the extended address 982 are absent. 984 ADR;TYPE=home:;;123 Main Street;Any Town;CA;91921-1234 986 5.3.2. LABEL 988 Purpose: To specify the formatted text corresponding to delivery 989 address of the object the vCard represents. 991 Value type: A single text value. 993 Special notes: The property value is formatted text that can be used 994 to present a delivery address label for the vCard object. The 995 type can include the type parameter "TYPE" to specify delivery 996 label type. The TYPE parameter values can include "home" to 997 indicate a delivery label for a residence; "work" to indicate 998 delivery label for a place of work; and "pref" to indicate the 999 preferred delivery label when more than one label is specified. 1001 These type parameter values can be specified as a parameter list 1002 (i.e., "TYPE=home;TYPE=pref") or as a value list (i.e., 1003 "TYPE=home,pref"). The default is "TYPE=work". 1005 Example: A multi-line address label. 1007 LABEL;TYPE=home:Mr.John Q. Public\, Esq.\nMail Drop: TNE QB\n 1008 123 Main Street\nAny Town\, CA 91921-1234\nU.S.A. 1010 5.4. Communications Properties 1012 These properties are concerned with information associated with the 1013 way communications with the object the vCard represents are carried 1014 out. 1016 5.4.1. TEL 1018 Purpose: To specify the telephone number for telephony communication 1019 with the object the vCard represents. 1021 Value type: A single phone-number value. 1023 Special notes: The value of this property is specified in a 1024 canonical form in order to specify an unambiguous representation 1025 of the globally unique telephone endpoint. This property is based 1026 on the X.500 Telephone Number attribute. 1028 The property can include the parameter "TYPE" to specify intended 1029 use for the telephone number. The TYPE parameter values can 1030 include: "home" to indicate a telephone number associated with a 1031 residence, "msg" to indicate the telephone number has voice 1032 messaging support, "work" to indicate a telephone number 1033 associated with a place of work, "pref" to indicate a preferred- 1034 use telephone number, "voice" to indicate a voice telephone 1035 number, "fax" to indicate a facsimile telephone number, "cell" to 1036 indicate a cellular telephone number, "video" to indicate a video 1037 conferencing telephone number, "pager" to indicate a paging device 1038 telephone number, "bbs" to indicate a bulletin board system 1039 telephone number, "modem" to indicate a MODEM connected telephone 1040 number, "car" to indicate a car-phone telephone number, "isdn" to 1041 indicate an ISDN service telephone number, "pcs" to indicate a 1042 personal communication services telephone number. The default 1043 type is "voice". These type parameter values can be specified as 1044 a parameter list (i.e., "TYPE=work;TYPE=voice") or as a value list 1045 (i.e., "TYPE=work,voice"). The default can be overridden to 1046 another set of values by specifying one or more alternate values. 1047 For example, the default TYPE of "voice" can be reset to a WORK 1048 and HOME, VOICE and FAX telephone number by the value list 1049 "TYPE=work,home,voice,fax". 1051 Example: 1053 TEL;TYPE=work,voice,pref,msg:+1-213-555-1234 1055 5.4.2. EMAIL 1057 Purpose: To specify the electronic mail address for communication 1058 with the object the vCard represents. 1060 Value type: A single text value. 1062 Special notes: The type can include the type parameter "TYPE" to 1063 specify the format or preference of the electronic mail address. 1064 The TYPE parameter values can include: "internet" to indicate an 1065 Internet addressing type, "x400" to indicate a X.400 addressing 1066 type, "uri" to indicate a URI useable for electronic 1067 communication, "home" to indicate an address associated with a 1068 residence, "work" to indicate an address associated with a place 1069 of work, or "pref" to indicate a preferred-use email address when 1070 more than one is specified. Another IANA registered address type 1071 can also be specified. The default email type is "internet". A 1072 non-standard value can also be specified. 1074 Type example: 1076 EMAIL;TYPE=internet:jqpublic@xyz.dom1.com 1078 EMAIL;TYPE=internet,pref:jane_doe@abc.com 1080 EMAIL;TYPE=uri,work:http://example.com/contact.php 1082 5.4.3. IMPP 1084 Purpose: To specify the URI for instant messaging and presence 1085 protocol communications with the object the vCard represents. 1087 Value type: A single URI. The type of the URI indicates the 1088 protocol that can be used for this contact. 1090 Special notes: The property may include the type parameter "TYPE" to 1091 specify an intended use for the URI. The TYPE parameter values 1092 include one or more of the following: 1094 * An indication of the type of communication for which this URI 1095 is appropriate. This can be a value of "personal" or 1096 "business". 1098 * An indication of the location of a device associated with this 1099 URI. Values can be "home", "work", or "mobile". 1101 * The value "pref" indicates this is a preferred address and has 1102 the same semantics as the "pref" value in a TEL property. 1104 Example: 1106 IMPP;TYPE=personal,pref:xmpp:alice@example.com 1108 5.4.4. LANG 1110 Purpose: To specify the language(s) that may be used for contacting 1111 the individual associated with the vCard. 1113 Value type: A list of text values. 1115 Special notes: The list is to be interpreted as defined in 1116 [RFC2616], Section 14.4, i.e. as the value of an Accept-Language 1117 HTTP header. This lets one specify preference among languages. 1118 Note that any SEMI-COLON character (ASCII decimal 59) must be 1119 escaped. 1121 Example: 1123 LANG:fr,en\;q=0.9 1125 5.5. Geographical Properties 1127 These properties are concerned with information associated with 1128 geographical positions or regions associated with the object the 1129 vCard represents. 1131 5.5.1. TZ 1133 Purpose: To specify information related to the time zone of the 1134 object the vCard represents. 1136 Value type: The default is a single utc-offset value. It can also 1137 be reset to a single text value. 1139 Special notes: The type value consists of a single value. 1141 Type examples: 1143 TZ:-05:00 1145 TZ;VALUE=text:-05:00; EST; Raleigh/North America 1146 ;This example has a single value, not a structure text value. 1148 5.5.2. GEO 1150 Purpose: To specify information related to the global positioning of 1151 the object the vCard represents. 1153 Value type: A single structured value consisting of two float values 1154 separated by the SEMI-COLON character (ASCII decimal 59). 1156 Special notes: This property specifies information related to the 1157 global position of the object associated with the vCard. The 1158 value specifies latitude and longitude, in that order (i.e., "LAT 1159 LON" ordering). The longitude represents the location east and 1160 west of the prime meridian as a positive or negative real number, 1161 respectively. The latitude represents the location north and 1162 south of the equator as a positive or negative real number, 1163 respectively. The longitude and latitude values MUST be specified 1164 as decimal degrees and should be specified to six decimal places. 1165 This will allow for granularity within a meter of the geographical 1166 position. The text components are separated by the SEMI-COLON 1167 character (ASCII decimal 59). The simple formula for converting 1168 degrees-minutes-seconds into decimal degrees is: 1170 decimal = degrees + minutes/60 + seconds/3600. 1172 Example: 1174 GEO:37.386013;-122.082932 1176 5.6. Organizational Properties 1178 These properties are concerned with information associated with 1179 characteristics of the organization or organizational units of the 1180 object the vCard represents. 1182 5.6.1. TITLE 1184 Purpose: To specify the job title, functional position or function 1185 of the object the vCard represents. 1187 Value type: A single text value. 1189 Special notes: This property is based on the X.520 Title attribute. 1191 Example: 1193 TITLE:Director\, Research and Development 1195 5.6.2. ROLE 1197 Purpose: To specify information concerning the role, occupation, or 1198 business category of the object the vCard represents. 1200 Value type: A single text value. 1202 Special notes: This property is based on the X.520 Business Category 1203 explanatory attribute. This property is included as an 1204 organizational type to avoid confusion with the semantics of the 1205 TITLE property and incorrect usage of that property when the 1206 semantics of this property is intended. 1208 Example: 1210 ROLE:Programmer 1212 5.6.3. LOGO 1214 Purpose: To specify a graphic image of a logo associated with the 1215 object the vCard represents. 1217 Encoding: The encoding MUST be reset to "b" using the ENCODING 1218 parameter in order to specify inline, encoded binary data. If the 1219 value is referenced by a URI value, then the default encoding of 1220 8bit is used and no explicit ENCODING parameter is needed. 1222 Value type: A single value. The default is binary value. It can 1223 also be reset to uri value. The uri value can be used to specify 1224 a value outside of this MIME entity. 1226 Special notes: This property SHOULD include the parameter "TYPE" to 1227 specify the graphic image format type. The TYPE parameter value 1228 MUST be an image media type as specified in [RFC4288]. The full 1229 media type name, including the "image/" prefix, should be used. 1230 However, implementations SHOULD be able to handle bare subtypes. 1232 Example: 1234 LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg 1236 LOGO;ENCODING=b;TYPE=image/jpeg:MIICajCCAdOgAwIBAgICBEUwDQYJKoZ 1237 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1238 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1239 <...the remainder of "B" encoded binary data...> 1241 5.6.4. AGENT 1243 Purpose: To specify information about another person who will act on 1244 behalf of the individual or resource associated with the vCard. 1246 Value type: The default is a single vcard value. It can also be 1247 reset to either a single text or uri value. The text value can be 1248 used to specify textual information. The uri value can be used to 1249 specify information outside of this MIME entity. 1251 Special notes: This property typically is used to specify an area 1252 administrator, assistant, or secretary for the individual 1253 associated with the vCard. A key characteristic of the AGENT 1254 property is that it represents somebody or something that is 1255 separately addressable. 1257 Example: 1259 AGENT;VALUE=uri: 1260 CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com 1262 AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555- 1263 1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n 1265 5.6.5. ORG 1267 Purpose: To specify the organizational name and units associated 1268 with the vCard. 1270 Value type: A single structured text value consisting of components 1271 separated the SEMI-COLON character (ASCII decimal 59). 1273 Special notes: The property is based on the X.520 Organization Name 1274 and Organization Unit attributes. The property value is a 1275 structured type consisting of the organization name, followed by 1276 one or more levels of organizational unit names. 1278 Example: A property value consisting of an organizational name, 1279 organizational unit #1 name and organizational unit #2 name. 1281 ORG:ABC\, Inc.;North American Division;Marketing 1283 5.7. Explanatory Properties 1285 These properties are concerned with additional explanations, such as 1286 that related to informational notes or revisions specific to the 1287 vCard. 1289 5.7.1. CATEGORIES 1291 Purpose: To specify application category information about the 1292 vCard. 1294 Value type: One or more text values separated by a COMMA character 1295 (ASCII decimal 44). 1297 Example: 1299 CATEGORIES:TRAVEL AGENT 1301 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY 1303 5.7.2. NOTE 1305 Purpose: To specify supplemental information or a comment that is 1306 associated with the vCard. 1308 Value type: A single text value. 1310 Special notes: The property is based on the X.520 Description 1311 attribute. 1313 Example: 1315 NOTE:This fax number is operational 0800 to 1715 1316 EST\, Mon-Fri. 1318 5.7.3. PRODID 1320 Purpose: To specify the identifier for the product that created the 1321 vCard object. 1323 Type value: A single text value. 1325 Special notes: Implementations SHOULD use a method such as that 1326 specified for Formal Public Identifiers in [ISO9070] or for 1327 Universal Resource Names in [RFC3406] to assure that the text 1328 value is unique. 1330 Example: 1332 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN 1334 5.7.4. REV 1336 Purpose: To specify revision information about the current vCard. 1338 Value type: The default is a single date-time value. Can also be 1339 reset to a single date value. 1341 Special notes: The value distinguishes the current revision of the 1342 information in this vCard for other renditions of the information. 1344 Example: 1346 REV:1995-10-31T22:27:10Z 1348 REV:1997-11-15 1350 5.7.5. SORT-STRING 1352 Purpose: To specify the family name or given name text to be used 1353 for national-language-specific sorting of the FN and N types. 1355 Value type: A single text value. 1357 Special notes: The sort string is used to provide family name or 1358 given name text that is to be used in locale- or national- 1359 language- specific sorting of the formatted name and structured 1360 name types. Without this information, sorting algorithms could 1361 incorrectly sort this vCard within a sequence of sorted vCards. 1362 When this property is present in a vCard, then this family name or 1363 given name value is used for sorting the vCard. 1365 Examples: For the case of family name sorting, the following examples 1366 define common sort string usage with the FN and N properties. 1368 FN:Rene van der Harten 1369 N:van der Harten;Rene;J.;Sir;R.D.O.N. 1370 SORT-STRING:Harten 1372 FN:Robert Pau Shou Chang 1373 N:Pau;Shou Chang;Robert 1374 SORT-STRING:Pau 1376 FN:Osamu Koura 1377 N:Koura;Osamu 1378 SORT-STRING:Koura 1380 FN:Oscar del Pozo 1381 N:del Pozo Triscon;Oscar 1382 SORT-STRING:Pozo 1384 FN:Chistine d'Aboville 1385 N:d'Aboville;Christine 1386 SORT-STRING:Aboville 1388 5.7.6. SOUND 1390 Purpose: To specify a digital sound content information that 1391 annotates some aspect of the vCard. By default this property is 1392 used to specify the proper pronunciation of the name property 1393 value of the vCard. 1395 Encoding: The encoding MUST be reset to "b" using the ENCODING 1396 parameter in order to specify inline, encoded binary data. If the 1397 value is referenced by a URI value, then the default encoding of 1398 8bit is used and no explicit ENCODING parameter is needed. 1400 Value type: A single value. The default is binary value. It can 1401 also be reset to uri value. The uri value can be used to specify 1402 a value outside of this MIME entity. 1404 Special notes: This property SHOULD include the parameter "TYPE" to 1405 specify the audio format type. The TYPE parameter value MUST be 1406 an audio media type as specified in [RFC4288]. The full media 1407 type name, including the "audio/" prefix, should be used. 1408 However, implementations SHOULD be able to handle bare subtypes. 1410 Example: 1412 SOUND;TYPE=audio/basic;VALUE=uri:CID:JOHNQPUBLIC.part8. 1413 19960229T080000.xyzMail@host1.com 1415 SOUND;TYPE=audio/basic;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJK 1416 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1417 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1418 <...the remainder of "B" encoded binary data...> 1420 5.7.7. UID 1422 Purpose: To specify a value that represents a globally unique 1423 identifier corresponding to the individual or resource associated 1424 with the vCard. 1426 Value type: A single text value. 1428 Special notes: The type is used to uniquely identify the object that 1429 the vCard represents. 1431 The type can include the type parameter "TYPE" to specify the format 1432 of the identifier. The TYPE parameter value should be an IANA 1433 registered identifier format. The value can also be a non-standard 1434 format. 1436 Example: 1438 UID:19950401-080045-40000F192713-0052 1440 5.7.8. URL 1442 Purpose: To specify a uniform resource locator associated with the 1443 object that the vCard refers to. 1445 Value type: A single uri value. 1447 Example: 1449 URL:http://www.swbyps.restaurant.french/~chezchic.html 1451 5.7.9. VERSION 1453 Purpose: To specify the version of the vCard specification used to 1454 format this vCard. 1456 Value type: A single text value. 1458 Special notes: The property MUST be present in the vCard object. 1459 The value MUST be "4.0" if the vCard corresponds to this 1460 specification. 1462 Example: 1464 VERSION:4.0 1466 5.8. Security Properties 1468 These properties are concerned with the security of communication 1469 pathways or access to the vCard. 1471 5.8.1. CLASS 1473 Purpose: To specify the access classification for a vCard object. 1475 Value type: A single text value. 1477 Special notes: An access classification is only one component of the 1478 general security model for a directory service. The 1479 classification attribute provides a method of capturing the intent 1480 of the owner for general access to information described by the 1481 vCard object. 1483 Examples: 1485 CLASS:PUBLIC 1487 CLASS:PRIVATE 1489 CLASS:CONFIDENTIAL 1491 5.8.2. KEY 1493 Purpose: To specify a public key or authentication certificate 1494 associated with the object that the vCard represents. 1496 Encoding: The encoding MUST be reset to "b" using the ENCODING 1497 parameter in order to specify inline, encoded binary data. If the 1498 value is a text value, then the default encoding of 8bit is used 1499 and no explicit ENCODING parameter is needed. 1501 Value type: A single value. The default is binary. It can also be 1502 reset to text value. The text value can be used to specify a text 1503 key. 1505 Special notes: The property can also include the parameter TYPE to 1506 specify the public key or authentication certificate format. This 1507 parameter should specify an IANA registered public key or 1508 authentication certificate format. It can also specify a non- 1509 standard format. 1511 Special notes: This property SHOULD include the parameter "TYPE" to 1512 specify the public key or authentication certificate format. The 1513 TYPE parameter value MUST be a media type as specified in 1514 [RFC4288]. 1516 Example: 1518 KEY;TYPE=application/pgp-keys;ENCODING=b:mQGiBEbEPUsRBACBF0RSIN 1519 mGutdM+KSAl7HMzwXHaLbvEOyu8At80I8qGejhzWowKbfem3X0m68Y/vhb+J2g 1520 7q11KHpnEdNb67uZaj9nTQ09Q+UFtH25qD/Afn3+9bOJQaPjAUYzXu3vD/xmN8 1521 <...remainder of "B" encoded binary data...> 1523 5.9. Extended Properties and Parameters 1525 The properties and parameters defined by this document can be 1526 extended. Non-standard, private properties and parameters with a 1527 name starting with "X-" may be defined bilaterally between two 1528 cooperating agents without outside registration or standardization. 1530 6. Formal Grammar 1532 The following formal grammar is provided to assist developers in 1533 building parsers for the vCard. 1535 This syntax is written according to the form described in [RFC5234], 1536 but it references just this small subset of [RFC5234] literals: 1538 ;******************************************* 1539 ; Commonly Used Literal Definition 1540 ;******************************************* 1542 ALPHA = %x41-5A / %x61-7A 1543 ; Latin Capital Letter A-Latin Capital Letter Z / 1544 ; Latin Small Letter a-Latin Small Letter z 1545 CHAR = %x01-7F 1546 ; Any C0 Controls and Basic Latin, excluding NULL from 1547 ; Code Charts, pages 7-6 through 7-9 in [UNICODE] 1549 CR = %x0D 1550 ; Carriage Return 1552 LF = %0A 1553 ; Line Feed 1555 CRLF = CR LF 1556 ; Internet standard newline 1558 ;CTL = %x00-1F / %x7F 1559 ; Controls. Not used, but referenced in comments. 1561 DIGIT = %x30-39 1562 ; Digit Zero-Digit Nine 1564 DQUOTE = %x22 1565 ; Quotation Mark 1567 HTAB = %x09 1568 ; Horizontal Tabulation 1570 SP = %x20 1571 ; space 1573 VCHAR = %x21-7E 1574 ; Visible (printing) characters 1576 WSP = SP / HTAB 1577 ; White Space 1579 ;******************************************* 1580 ; Basic vCard Definition 1581 ;******************************************* 1583 vcard_entity = 1*(vcard) 1585 vcard = "BEGIN" ":" "VCARD" 1*CRLF 1586 1*(contentline) 1587 ;A vCard object MUST include the VERSION, FN and N types. 1588 "END" ":" "VCARD" 1*CRLF 1590 contentline = name *(";" param ) ":" value CRLF 1591 ; When parsing a content line, folded lines must first 1592 ; be unfolded according to the unfolding procedure 1593 ; described above. When generating a content line, lines 1594 ; longer than 75 characters SHOULD be folded according to 1595 ; the folding procedure described in [MIME DIR]. 1597 name = iana-token / x-name 1598 ; Parsing of the param and value is 1599 ; based on the "name" or type identifier 1600 ; as defined in ABNF sections below 1602 iana-token = 1*(ALPHA / DIGIT / "-") 1603 ; vCard type or parameter identifier registered with IANA 1605 x-name = "X-" 1*(ALPHA / DIGIT / "-") 1606 ; Reserved for non-standard use 1608 param = param-name "=" param-value *("," param-value) 1610 param-name = iana-token / x-name 1612 param-value = ptext / quoted-string 1614 ptext = *SAFE-CHAR 1616 value = *VALUE-CHAR 1618 quoted-string = DQUOTE QSAFE-CHAR DQUOTE 1620 NON-ASCII = %x80-FF 1621 ; Use is restricted by outer MIME object (UTF-8 preferred) 1623 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII 1624 ; Any character except CTLs, DQUOTE 1626 SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII 1627 ; Any character except CTLs, DQUOTE, ";", ":", "," 1629 VALUE-CHAR = WSP / VCHAR / NON-ASCII 1630 ; Any textual character 1632 ;******************************************* 1633 ; vCard Type Definition 1634 ; 1635 ; Provides type-specific definitions for how the 1636 ; "value" and "param" are defined. 1637 ;******************************************* 1638 ;For name="NAME" 1639 param = "" 1640 ; No parameters allowed 1642 value = text-value 1644 ;For name="KIND" 1645 param = "" 1646 ; No parameters allowed 1648 value = kind-value 1649 kind-value = "individual" / "group" / "org" / x-name / iana-token 1651 ;For name="PROFILE" 1652 param = "" 1653 ; No parameters allowed 1655 value = text-value 1656 ; Value MUST be the case insensitive value "VCARD 1658 ;For name="SOURCE" 1659 param = source-param 1660 ; Only source parameters allowed 1662 value = uri 1664 source-param = ("VALUE" "=" "uri") 1665 / (x-name "=" *SAFE-CHAR) 1667 ;For name="FN" 1668 ;This type MUST be included in a vCard object. 1669 param = text-param 1670 ; Text parameters allowed 1672 value = text-value 1674 ;For name="N" 1675 ;This type MUST be included in a vCard object. 1677 param = text-param 1678 ; Text parameters allowed 1680 value = n-value 1682 n-value = 0*4(text-value *("," text-value) ";") 1683 text-value *("," text-value) 1684 ; Family; Given; Middle; Prefix; Suffix. 1685 ; Example: Public;John;Quincy,Adams;Reverend Dr. III 1687 ;For name="NICKNAME" 1688 param = text-param 1689 ; Text parameters allowed 1690 value = text-value-list 1692 ;For name="PHOTO" 1693 param = img-inline-param 1694 ; Only image parameters allowed 1696 param =/ img-refer-param 1697 ; Only image parameters allowed 1699 value = img-inline-value 1700 ; Value and parameter MUST match 1702 value =/ img-refer-value 1703 ; Value and parameter MUST match 1705 ;For name="BDAY" 1706 param = ("VALUE" "=" "date") 1707 ; Only value parameter allowed 1709 param =/ ("VALUE" "=" "date-time") 1710 ; Only value parameter allowed 1712 value = date-value 1713 ; Value MUST match value type 1715 value =/ date-time-value 1716 ; Value MUST match value type 1718 ;For name="ADR" 1719 param = adr-param / text-param 1720 ; Only adr and text parameters allowed 1722 value = adr-value 1724 ;For name="LABEL" 1725 param = adr-param / text-param 1726 ; Only adr and text parameters allowed 1728 value = text-value 1730 ;For name="TEL" 1731 param = tel-param 1732 ; Only tel parameters allowed 1734 value = phone-number-value 1736 tel-param = "TYPE" "=" tel-type *("," tel-type) 1737 tel-type = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG" 1738 / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN" 1739 / "VIDEO" / "PCS" / iana-token / x-name 1740 ; Values are case insensitive 1742 ;For name="EMAIL" 1743 param = email-param 1744 ; Only email parameters allowed 1746 value = text-value 1748 email-param = "TYPE" "=" email-type ["," "PREF"] 1749 ; Value is case insensitive 1751 email-type = "INTERNET" / "X400" / iana-token / "X-" word 1752 ; Values are case insensitive 1754 ;For name="TZ" 1755 param = "" 1756 ; No parameters allowed 1758 value = utc-offset-value 1760 ;For name="GEO" 1761 param = "" 1762 ; No parameters allowed 1764 value = float-value ";" float-value 1766 ;For name="TITLE" 1767 param = text-param 1768 ; Only text parameters allowed 1770 value = text-value 1772 ;For name="ROLE" 1773 param = text-param 1774 ; Only text parameters allowed 1776 value = text-value 1778 ;For name="LOGO" 1779 param = img-inline-param / img-refer-param 1780 ; Only image parameters allowed 1782 value = img-inline-value / img-refer-value 1783 ; Value and parameter MUST match 1785 ;For name="AGENT" 1786 param = agent-inline-param 1788 param =/ agent-refer-param 1790 param =/ text-param 1792 value = agent-inline-value 1793 ; Value and parameter MUST match 1795 value =/ agent-refer-value 1796 ; Value and parameter MUST match 1798 value =/ text-value 1799 ; Value and parameter MUST match 1801 agent-inline-param = "" 1802 ; No parameters allowed 1804 agent-refer-param = "VALUE" "=" "uri" 1805 ; Only value parameter allowed 1807 agent-inline-value = text-value 1808 ; Value MUST be a valid vCard object 1810 agent-refer-value = uri 1811 ; URI MUST refer to valid vCard object 1813 ;For name="ORG" 1815 param = text-param 1816 ; Only text parameters allowed 1818 value = org-value 1820 org-value = *(text-value ";") text-value 1821 ; First is Organization Name, remainder are Organization Units. 1823 ;For name="CATEGORIES" 1824 param = text-param 1825 ; Only text parameters allowed 1827 value = text-value-list 1829 ;For name="NOTE" 1830 param = text-param 1831 ; Only text parameters allowed 1832 value = text-value 1834 ;For name="PRODID" 1835 param = "" 1836 ; No parameters allowed 1838 value = text-value 1840 ;For name="REV" 1841 param = ["VALUE" =" "date-time"] 1842 ; Only value parameters allowed. Values are case insensitive. 1844 param =/ "VALUE" =" "date" 1845 ; Only value parameters allowed. Values are case insensitive. 1847 value = date-time-value 1849 value =/ date-value 1851 ;For name="SORT-STRING" 1852 param = text-param 1853 ; Only text parameters allowed 1855 value = text-value 1857 ;For name="SOUND" 1858 param = snd-inline-param 1859 ; Only sound parameters allowed 1861 param =/ snd-refer-param 1862 ; Only sound parameters allowed 1864 value = snd-line-value 1865 ; Value MUST match value type 1867 value =/ snd-refer-value 1868 ; Value MUST match value type 1870 snd-inline-value = binary-value CRLF 1871 ; Value MUST be "b" encoded audio content 1873 snd-inline-param = ("VALUE" "=" "binary"]) 1874 / ("ENCODING" "=" "b") 1875 / ("TYPE" "=" *SAFE-CHAR) 1876 ; Value MUST be an IANA registered audio type 1878 snd-refer-value = uri 1879 ; URI MUST refer to audio content of given type 1880 snd-refer-param = ("VALUE" "=" "uri") 1881 / ("TYPE" "=" word) 1882 ; Value MUST be an IANA registered audio type 1884 ;For name="UID" 1885 param = "TYPE" "=" (iana-token / x-name) 1886 ;TYPE value should be an IANA registered identifier format 1888 value = text-value 1890 ;For name="URL" 1891 param = "" 1892 ; No parameters allowed 1894 value = uri 1896 ;For name="VERSION" 1897 ;This type MUST be included in a vCard object. 1898 param = "" 1899 ; No parameters allowed 1901 value = text-value 1902 ; Value MUST be "3.0" 1904 ;For name="CLASS" 1905 param = "" 1906 ; No parameters allowed 1908 value = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" 1909 / iana-token / x-name 1910 ; Value are case insensitive 1912 ;For name="KEY" 1913 param = key-txt-param 1914 ; Only value and type parameters allowed 1916 param =/ key-bin-param 1917 ; Only value and type parameters allowed 1919 value = text-value 1921 value =/ binary-value 1923 key-txt-param = "TYPE" "=" keytype 1925 key-bin-param = ("TYPE" "=" keytype) 1926 / ("ENCODING" "=" "b") 1927 ; Value MUST be a "b" encoded key or certificate 1928 keytype = param-value 1929 ; Type MUST be a media type as defined in RFC 4288 1931 ;For name="X-" non-standard type 1932 param = text-param / (x-name "=" param-value) 1933 ; Only text or non-standard parameters allowed 1935 value = text-value 1937 ;******************************************* 1938 ; vCard Commonly Used Parameter Definition 1939 ;******************************************* 1940 text-param = ("VALUE" "=" "ptext") 1941 / ("LANGUAGE" "=" langval) 1942 / (x-name "=" param-value) 1944 langval = 1946 img-inline-value = binary-value 1947 ;Value MUST be "b" encoded image content 1949 img-inline-param 1951 img-inline-param = ("VALUE" "=" "binary") 1952 / ("ENCODING" "=" "b") 1953 / ("TYPE" "=" param-value 1954 ;TYPE value MUST be an image media type as defined in RFC 4288 1956 img-refer-value = uri 1957 ;URI MUST refer to image content of given type 1959 img-refer-param = ("VALUE" "=" "uri") 1960 / ("TYPE" "=" param-value) 1961 ;TYPE value MUST be an image media type as defined in RFC 4288 1963 adr-param = ("TYPE" "=" adr-type *("," adr-type)) 1964 / (text-param) 1966 adr-type = "home" / "work" / "pref" / iana-token / x-name 1968 adr-value = 0*6(text-value ";") text-value 1969 ; PO Box, Extended Address, Street, Locality, Region, Postal 1970 ; Code, Country Name 1971 ;******************************************* 1972 ; vCard Type Value Definition 1973 ;******************************************* 1975 text-value-list = 1*text-value *("," 1*text-value) 1977 text-value = *(SAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) 1979 ESCAPED-CHAR = "\\" / "\;" / "\," / "\n" / "\N") 1980 ; \\ encodes \, \n or \N encodes newline 1981 ; \; encodes ;, \, encodes , 1983 binary-value = 1985 date-value = 1987 time-value = 1988 date-time-value = 1990 float-value = 1992 phone-number-value = 1995 uri-value = 1997 utc-offset-value = ("+" / "-") time-hour ":" time-minute 1998 time-hour = 2DIGIT ;00-23 1999 time-minute = 2DIGIT ;00-59 2001 7. Example: Authors' vCards 2003 BEGIN:VCARD 2004 VERSION:4.0 2005 FN:Pete Resnick 2006 N:Resnick;Pete;;; 2007 GENDER:M 2008 ORG:QUALCOMM Incorporated 2009 ADR;TYPE=work:;;5775 Morehouse Drive;San Diego;CA;92121-1714;US 2010 TEL;TYPE=voice:+1-858-651-4478 2011 EMAIL;TYPE=internet:presnick@qualcomm.com 2012 URL:http://www.qualcomm.com/~presnick/ 2013 END:VCARD 2015 BEGIN:VCARD 2016 VERSION:4.0 2017 FN:Simon Perreault 2018 N:Perreault;Simon;;;ing. jr.,M.Sc. 2019 BDAY:1983-02-03 2020 GENDER:M 2021 ORG:Viagenie 2022 ADR;TYPE=work:;;2600 boul. Laurier\, suite 625; 2023 Quebec;QC;G1V 4W1;Canada 2024 TEL;TYPE=voice,work:+1-418-656-9254 2025 TEL;TYPE=fax,work:+1-418-656-9257 2026 EMAIL;TYPE=internet,work:simon.perreault@viagenie.ca 2027 GEO:46.772673,-71.282945 2028 CLASS:PUBLIC 2029 KEY;VALUE=uri:http://www.viagenie.ca/simon.perreault/simon.asc 2030 END:VCARD 2032 8. Security Considerations 2034 o Internet mail is subject to many well known security attacks, 2035 including monitoring, replay, and forgery. Care should be taken 2036 by any directory service in allowing information to leave the 2037 scope of the service itself, where any access controls can no 2038 longer be guaranteed. Applications should also take care to 2039 display directory data in a "safe" environment (e.g., PostScript- 2040 valued types). 2042 o vCards can carry cryptographic keys or certificates, as described 2043 in Section 5.8.2. 2045 o Section 5.8.1 specifies a desired security classification policy 2046 for a particular vCard. That policy is not enforced in any way. 2048 o The vCard objects have no inherent authentication or privacy, but 2049 can easily be carried by any security mechanism that transfers 2050 MIME objects with authentication or privacy. In cases where 2051 threats of "spoofed" vCard information is a concern, the vCard 2052 SHOULD BE transported using one of these secure mechanisms. 2054 o The information in a vCard may become out of date. In cases where 2055 the vitality of data is important to an originator of a vCard, the 2056 "URL" type described in Section 5.7.8 SHOULD BE specified. In 2057 addition, the "REV" type described in section Section 5.7.4 can be 2058 specified to indicate the last time that the vCard data was 2059 updated. 2061 9. Acknowledgements 2063 The authors would like to thank Frank Dawson and Tim Howes, the 2064 original authors of [RFC2425] and [RFC2426], as well as the following 2065 individuals who have participated in the drafting, review and 2066 discussion of this memo: 2068 Marc Blanchet, Darryl Champagne, Cyrus Daboo, Javier Godoy, Mark 2069 Paterson, and Julien Reschke. 2071 10. References 2073 10.1. Normative References 2075 [CCITT.E163.1988] International Telephone and Telegraph 2076 Consultative Committee, "Numbering Plan for 2077 the International Telephone Service", 2078 CCITT Recommendation E.163, 1988. 2080 [CCITT.X121.1988] International Telephone and Telegraph 2081 Consultative Committee, "International 2082 Numbering Plan for the Public Data Networks", 2083 CCITT Recommendation X.121, 1988. 2085 [CCITT.X520.1988] International International Telephone and 2086 Telegraph Consultative Committee, 2087 "Information Technology - Open Systems 2088 Interconnection - The Directory: Selected 2089 Attribute Types", CCITT Recommendation X.520, 2090 November 1988. 2092 [CCITT.X521.1988] International International Telephone and 2093 Telegraph Consultative Committee, 2094 "Information Technology - Open Systems 2095 Interconnection - The Directory: Selected 2096 Object Classes", CCITT Recommendation X.521, 2097 November 1988. 2099 [ISO.8601.1988] International Organization for 2100 Standardization, "Data elements and 2101 interchange formats - Information interchange 2102 - Representation of dates and times", 2103 ISO Standard 8601, June 1988. 2105 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose 2106 Internet Mail Extensions (MIME) Part Two: 2107 Media Types", RFC 2046, November 1996. 2109 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 2110 Extensions) Part Three: Message Header 2111 Extensions for Non-ASCII Text", RFC 2047, 2112 November 1996. 2114 [RFC2119] Bradner, S., "Key words for use in RFCs to 2115 Indicate Requirement Levels", BCP 14, 2116 RFC 2119, March 1997. 2118 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME 2119 Content-Type for Directory Information", 2120 RFC 2425, September 1998. 2122 [RFC2426] Dawson, F. and T. Howes, "vCard MIME 2123 Directory Profile", RFC 2426, September 1998. 2125 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, 2126 H., Masinter, L., Leach, P., and T. Berners- 2127 Lee, "Hypertext Transfer Protocol -- 2128 HTTP/1.1", RFC 2616, June 1999. 2130 [RFC2822] Resnick, P., "Internet Message Format", 2131 RFC 2822, April 2001. 2133 [RFC2978] Freed, N. and J. Postel, "IANA Charset 2134 Registration Procedures", BCP 19, RFC 2978, 2135 October 2000. 2137 [RFC3629] Yergeau, F., "UTF-8, a transformation format 2138 of ISO 10646", STD 63, RFC 3629, 2139 November 2003. 2141 [RFC3986] Berners-Lee, T., Fielding, R., and L. 2142 Masinter, "Uniform Resource Identifier (URI): 2143 Generic Syntax", STD 66, RFC 3986, 2144 January 2005. 2146 [RFC4288] Freed, N. and J. Klensin, "Media Type 2147 Specifications and Registration Procedures", 2148 BCP 13, RFC 4288, December 2005. 2150 [RFC4646] Phillips, A. and M. Davis, "Tags for 2151 Identifying Languages", BCP 47, RFC 4646, 2152 September 2006. 2154 [RFC4770] Jennings, C. and J. Reschke, Ed., "vCard 2155 Extensions for Instant Messaging (IM)", 2156 RFC 4770, January 2007. 2158 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF 2159 for Syntax Specifications: ABNF", STD 68, 2160 RFC 5234, January 2008. 2162 [oldreference_UNICODE] The International Organization for 2163 Standardization, "The Unicode Standard - 2164 Version 2.0", The Unicode Consortium", 2165 July 1996. 2167 [oldreference_VCARD] Internet Mail Consortium, "vCard - The 2168 Electronic Business Card Version 2.1", 2169 September September. 2171 10.2. Informative References 2173 [ISO9070] The International Organization for 2174 Standardization, "ISO 9070, Information 2175 Processing - SGML support facilities - 2176 Registration Procedures for Public Text Owner 2177 Identifiers", April 1991. 2179 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and 2180 P. Faltstrom, "Uniform Resource Names (URN) 2181 Namespace Definition Mechanisms", BCP 66, 2182 RFC 3406, October 2002. 2184 Appendix A. Differences from RFCs 2425 and 2426 2186 This appendix contains a list of changes that have been made in the 2187 vCard specification from RFCs 2425 and 2426. 2189 A.1. New Structure 2191 o [RFC2425] and [RFC2426] have been merged. Initially [RFC2425] was 2192 intended to be extensible but only 2426 ever extended it. 2194 o vCard is now not only a MIME type but a stand-alone format. 2196 o A proper MIME type registration form has been included. 2198 o UTF-8 is now the default character set. 2200 A.2. Removed Features 2202 o The group construct (i.e. GROUP.PROPERTY:...) no longer exists. 2204 o The CONTEXT and CHARSET parameters are no more. 2206 o The MAILER property is no more. 2208 o The "intl", "dom", "postal", and "parcel" TYPE parameter values 2209 for the ADR and LABEL properties have been removed. 2211 A.3. New Properties and Parameters 2213 o The KIND, GENDER, LANG, DDAY, BIRTH, and DEATH properties have 2214 been added. 2216 o [RFC4770], which defines the IMPP property, has been merged in. 2218 o The "work", "home", and "uri" TYPE parameter values for the EMAIL 2219 property have been added. 2221 A.4. Other Changes 2223 o The N property is no longer mandatory. 2225 Appendix B. Change Log (to be removed by RFC Editor prior to 2226 publication) 2228 B.1. Changes in -01 2230 o Removed reference to RFC 2234. 2232 o Fixed errata from 2233 http://www.rfc-editor.org/errata_search.php?rfc=2426. 2235 o Removed passage referring to RFC 2425 profiles. 2237 o Renamed Section 5.4 from "Telecommunications Adressing Properties" 2238 to "Communications Properties. 2240 o Added Appendix A and Appendix B. 2242 o Added reference to [RFC4770]. 2244 o Removed the group construct. 2246 o Made the N property no longer mandatory. 2248 o Added the KIND property. 2250 o Clarified meaning of TYPE parameter value for PHOTO, LOGO, KEY, 2251 and SOUND. 2253 o Removed the CONTEXT parameter. 2255 o Removed the MAILER property. 2257 o Made reference to [ISO9070] informative. 2259 o Removed "intl", "dom", "postal", and "parcel" TYPE parameter 2260 values for the ADR and LABEL properties. 2262 o Clarified meaning of "extended address" ADR field. 2264 o Mentioned [RFC3406] as another method of generating PRODID values. 2266 o Updated obsolete references. 2268 o Allowed BDAY and DDAY value types to be text values for fuzzy 2269 dates. 2271 o Removed the CHARSET property. Now the encoding is always UTF-8, 2272 except when overridden by the Content-Type (which is considered a 2273 compatibility feature). 2275 Authors' Addresses 2277 Peter W. Resnick 2278 QUALCOMM Incorporated 2279 5775 Morehouse Drive 2280 San Diego, CA 92121-1714 2281 US 2283 Phone: +1 858 651 4478 2284 EMail: presnick@qualcomm.com 2285 URI: http://www.qualcomm.com/~presnick/ 2287 Simon Perreault 2288 Viagenie 2289 2600 boul. Laurier, suite 625 2290 Quebec, QC G1V 4W1 2291 Canada 2293 Phone: +1 418 656 9254 2294 EMail: simon.perreault@viagenie.ca 2295 URI: http://www.viagenie.ca 2297 Full Copyright Statement 2299 Copyright (C) The IETF Trust (2008). 2301 This document is subject to the rights, licenses and restrictions 2302 contained in BCP 78, and except as set forth therein, the authors 2303 retain all their rights. 2305 This document and the information contained herein are provided on an 2306 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2307 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2308 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2309 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2310 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2311 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2313 Intellectual Property 2315 The IETF takes no position regarding the validity or scope of any 2316 Intellectual Property Rights or other rights that might be claimed to 2317 pertain to the implementation or use of the technology described in 2318 this document or the extent to which any license under such rights 2319 might or might not be available; nor does it represent that it has 2320 made any independent effort to identify any such rights. Information 2321 on the procedures with respect to rights in RFC documents can be 2322 found in BCP 78 and BCP 79. 2324 Copies of IPR disclosures made to the IETF Secretariat and any 2325 assurances of licenses to be made available, or the result of an 2326 attempt made to obtain a general license or permission for the use of 2327 such proprietary rights by implementers or users of this 2328 specification can be obtained from the IETF on-line IPR repository at 2329 http://www.ietf.org/ipr. 2331 The IETF invites any interested party to bring to its attention any 2332 copyrights, patents or patent applications, or other proprietary 2333 rights that may cover technology that may be required to implement 2334 this standard. Please address the information to the IETF at 2335 ietf-ipr@ietf.org. 2337 Acknowledgements 2339 Funding for the RFC Editor function is provided by the IETF 2340 Administrative Support Activity (IASA). This document was produced 2341 using xml2rfc v1.32 (of http://xml.resource.org/) from a source in 2342 RFC-2629 XML format.