idnits 2.17.1 draft-ietf-vcarddav-vcardrev-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC4770, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC2426, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 487 has weird spacing: '... [month day]...' == Line 491 has weird spacing: '... month day...' == Line 492 has weird spacing: '... month day...' == Line 494 has weird spacing: '... month day...' == Line 500 has weird spacing: '... = hour minut...' == (1 more instance...) (Using the creation date from RFC2739, updated by this document, for RFC5378 checks: 1998-08-14) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 26, 2011) is 4713 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-vcarddav-vcardxml-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.2008' ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: A later version (-13) exists of draft-ietf-eai-rfc5335bis-10 == Outdated reference: A later version (-05) exists of draft-lear-iana-timezone-database-04 -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 2425 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3536 (Obsoleted by RFC 6365) -- Obsolete informational reference (is this intentional?): RFC 4770 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Perreault 3 Internet-Draft Viagenie 4 Obsoletes: 2425, 2426, 4770 May 26, 2011 5 (if approved) 6 Updates: 2739 (if approved) 7 Intended status: Standards Track 8 Expires: November 27, 2011 10 vCard Format Specification 11 draft-ietf-vcarddav-vcardrev-22 13 Abstract 15 This document defines the vCard data format for representing and 16 exchanging a variety of information about individuals and other 17 entities (e.g., formatted and structured name and delivery addresses, 18 email address, multiple telephone numbers, photograph, logo, audio 19 clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and 20 updates RFC 2739. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 27, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 6 71 3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 6 73 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 7 74 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 10 75 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 10 76 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 13 79 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 14 82 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14 83 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 15 84 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16 89 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16 90 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 21 97 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 24 102 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 24 103 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 24 104 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 25 106 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 26 107 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 6.2. Identification Properties . . . . . . . . . . . . . . . . 29 109 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 31 112 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 31 113 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 32 115 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 33 116 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 34 117 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 34 118 6.4. Communications Properties . . . . . . . . . . . . . . . . 35 119 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 35 120 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 37 121 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 38 122 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 38 123 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 39 124 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 39 125 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 40 126 6.6. Organizational Properties . . . . . . . . . . . . . . . . 40 127 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 40 128 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 41 129 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 42 130 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 42 131 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 43 132 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 44 133 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 45 134 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 45 135 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 46 136 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 46 137 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 47 138 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 47 139 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 48 140 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 48 141 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 49 142 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 50 143 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 50 144 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 50 146 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 51 147 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 51 148 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 52 149 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 52 150 6.10. Extended Properties and Parameters . . . . . . . . . . . . 53 151 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 53 152 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 53 153 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 53 154 7.1.2. Matching Property Instances . . . . . . . . . . . . . 54 155 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 54 156 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 55 157 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 55 158 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 55 159 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 56 160 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 56 161 7.2.5. Global Context Simplification . . . . . . . . . . . . 58 162 8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 59 163 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 164 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 165 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 60 166 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 61 167 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 61 168 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 62 169 10.2.3. Registration Template for Properties . . . . . . . . . 63 170 10.2.4. Registration Template for Parameters . . . . . . . . . 63 171 10.2.5. Registration Template for Value Data Types . . . . . . 64 172 10.2.6. Registration Template for Values . . . . . . . . . . . 64 173 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 65 174 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 65 175 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 66 176 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 67 177 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 67 178 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 70 179 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 180 12.1. Normative References . . . . . . . . . . . . . . . . . . . 70 181 12.2. Informative References . . . . . . . . . . . . . . . . . . 73 182 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 75 183 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 75 184 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 76 185 A.3. New Properties and Parameters . . . . . . . . . . . . . . 76 186 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 76 187 Appendix B. Change Log (to be removed by RFC Editor prior to 188 publication) . . . . . . . . . . . . . . . . . . . . 77 189 B.1. Changes in -22 . . . . . . . . . . . . . . . . . . . . . . 77 190 B.2. Changes in -21 . . . . . . . . . . . . . . . . . . . . . . 77 191 B.3. Changes in -20 . . . . . . . . . . . . . . . . . . . . . . 77 192 B.4. Changes in -19 . . . . . . . . . . . . . . . . . . . . . . 78 193 B.5. Changes in -18 . . . . . . . . . . . . . . . . . . . . . . 78 194 B.6. Changes in -17 . . . . . . . . . . . . . . . . . . . . . . 78 195 B.7. Changes in -16 . . . . . . . . . . . . . . . . . . . . . . 79 196 B.8. Changes in -15 . . . . . . . . . . . . . . . . . . . . . . 79 197 B.9. Changes in -14 . . . . . . . . . . . . . . . . . . . . . . 80 198 B.10. Changes in -13 . . . . . . . . . . . . . . . . . . . . . . 81 199 B.11. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 81 200 B.12. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 82 201 B.13. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 83 202 B.14. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 83 203 B.15. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 83 204 B.16. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 84 205 B.17. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 84 206 B.18. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 85 207 B.19. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 85 208 B.20. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 86 209 B.21. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 86 210 B.22. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 87 211 B.23. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 87 213 1. Introduction 215 Electronic address books have become ubiquitous. Their increased 216 presence on portable, connected devices as well as the diversity of 217 platforms exchanging contact data call for a standard. This memo 218 defines the vCard format, which allows the capture and exchange of 219 information normally stored within an address book or directory 220 application. 222 A high-level overview of the differences from RFCs 2425 and 2426 can 223 be found in Appendix A. 225 2. Conventions 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in 230 [RFC2119]. 232 3. vCard Format Specification 234 The text/vcard MIME content type (hereafter known as "vCard", see 235 Section 10.1) contains contact information, typically pertaining to a 236 single contact or group of contacts. The content consists of one or 237 more lines in the format given below. 239 3.1. Charset 241 The charset (see [RFC3536] for internationalization terminology) for 242 vCard is UTF-8 as defined in [RFC3629]. There is no way to override 243 this. It is invalid to specify a value other than "UTF-8" in the 244 "charset" MIME parameter (see Section 10.1). 246 3.2. Line Delimiting and Folding 248 Individual lines within vCard are delimited by the [RFC5322] line 249 break, which is a CRLF sequence (U+000D followed by U+000A). Long 250 logical lines of text can be split into a multiple-physical-line 251 representation using the following folding technique. Content lines 252 SHOULD be folded to a maximum width of 75 octets, excluding the line 253 break. Multi-octet characters MUST remain contiguous. The rationale 254 for this folding process can be found in [RFC5322], Section 2.1.1. 256 A logical line MAY be continued on the next physical line anywhere 257 between two characters by inserting a CRLF immediately followed by a 258 single white space character (space (U+0020) or horizontal tab 259 (U+0009)). The folded line MUST contain at least one character. Any 260 sequence of CRLF followed immediately by a single white space 261 character is ignored (removed) when processing the content type. For 262 example the line: 264 NOTE:This is a long description that exists on a long line. 266 can be represented as: 268 NOTE:This is a long description 269 that exists on a long line. 271 It could also be represented as: 273 NOTE:This is a long descrip 274 tion that exists o 275 n a long line. 277 The process of moving from this folded multiple-line representation 278 of a property definition to its single line representation is called 279 unfolding. Unfolding is accomplished by regarding CRLF immediately 280 followed by a white space character (namely HTAB (U+0009) or SPACE 281 (U+0020)) as equivalent to no characters at all (i.e., the CRLF and 282 single white space character are removed). 284 Note: It is possible for very simple implementations to generate 285 improperly folded lines in the middle of a UTF-8 multi-octet 286 sequence. For this reason, implementations SHOULD unfold lines in 287 such a way as to properly restore the original sequence. 289 Note: Unfolding is done differently than in [RFC5322]. Unfolding 290 in [RFC5322] only removes the CRLF, not the space following it. 292 Folding is done after any content encoding of a type value. 293 Unfolding is done before any decoding of a type value in a content 294 line. 296 3.3. ABNF Format Definition 298 The following ABNF uses the notation of [RFC5234], which also defines 299 CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. 301 vcard-entity = 1*vcard 303 vcard = "BEGIN:VCARD" CRLF 304 "VERSION:4.0" CRLF 305 1*contentline 306 "END:VCARD" CRLF 307 ; A vCard object MUST include the VERSION and FN properties. 308 ; VERSION MUST come immediately after BEGIN:VCARD. 310 contentline = [group "."] name *(";" param) ":" value CRLF 311 ; When parsing a content line, folded lines must first 312 ; be unfolded according to the unfolding procedure 313 ; described in section 3.2. 314 ; When generating a content line, lines longer than 75 315 ; characters SHOULD be folded according to the folding 316 ; procedure described in section 3.2. 318 group = 1*(ALPHA / DIGIT / "-") 319 name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME" 320 / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL" 321 / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE" 322 / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES" 323 / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP" 324 / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML" 325 / iana-token / x-name 326 ; Parsing of the param and value is based on the "name" as 327 ; defined in ABNF sections below. 328 ; Group and name are case-insensitive. 330 iana-token = 1*(ALPHA / DIGIT / "-") 331 ; identifier registered with IANA 333 x-name = "x-" 1*(ALPHA / DIGIT / "-") 334 ; Names that begin with "x-" or "X-" are 335 ; reserved for experimental use, not intended for released 336 ; products, or for use in bilateral agreements. 338 param = language-param / value-param / pref-param / pid-param 339 / type-param / geo-parameter / tz-parameter / sort-as-param 340 / calscale-param / any-param 341 ; Allowed parameters depend on property name. 343 param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE 345 any-param = (iana-token / x-name) "=" param-value *("," param-value) 347 NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4 348 ; UTF8-{2,3,4} are defined in [RFC3629] 350 QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII 351 ; Any character except CTLs, DQUOTE 353 SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII 354 ; Any character except CTLs, DQUOTE, ";", ":" 356 VALUE-CHAR = WSP / VCHAR / NON-ASCII 357 ; Any textual character 359 A line that begins with a white space character is a continuation of 360 the previous line, as described in Section 3.2. The white space 361 character and immediately preceeding CRLF should be discarded when 362 reconstructing the original line. Note that this line-folding 363 convention differs from that found in [RFC5322], in that the sequence 364 found anywhere in the content indicates a continued line 365 and should be removed. 367 Property names and parameter names are case insensitive (e.g., the 368 property name "fn" is the same as "FN" and "Fn"). Parameter values 369 MAY be case-sensitive or case-insensitive, depending on their 370 definition. Parameter values that are not explicitly defined as 371 being case-sensitive are case-insenstive. Based on experience with 372 vCard 3 interoperability, it is RECOMMENDED that property and 373 parameter names be upper-case on output. 375 The group construct is used to group related properties together. 376 The group name is a syntactic convention used to indicate that all 377 property names prefaced with the same group name SHOULD be grouped 378 together when displayed by an application. It has no other 379 significance. Implementations that do not understand or support 380 grouping MAY simply strip off any text before a "." to the left of 381 the type name and present the types and values as normal. 383 Property cardinalities are indicated using the following notation, 384 which is based on ABNF (see [RFC5234], section 3.6): 386 +-------------+--------------------------------------------------+ 387 | Cardinality | Meaning | 388 +-------------+--------------------------------------------------+ 389 | 1 | Exactly one instance per vCard MUST be present. | 390 | *1 | Exactly one instance per vCard MAY be present. | 391 | 1* | One or more instances per vCard MUST be present. | 392 | * | One or more instances per vCard MAY be present. | 393 +-------------+--------------------------------------------------+ 395 Properties defined in a vCard instance may have multiple values 396 depending on the property cardinality. The general rule for encoding 397 multi-valued properties is to simply create a new content line for 398 each value (including the property name). However, it should be 399 noted that some value types support encoding multiple values in a 400 single content line by separating the values with a comma ",". This 401 approach has been taken for several of the content types defined 402 below (date, time, integer, float). 404 3.4. Property Value Escaping 406 Some properties may contain one or more values delimited by a COMMA 407 character (U+002C). Therefore, a COMMA character in a value MUST be 408 escaped with a BACKSLASH character (U+005C), even for properties that 409 don't allow multiple instances (for consistency). 411 Some properties (e.g. N and ADR) comprise multiple fields delimited 412 by a SEMI-COLON character (U+003B). Therefore, a SEMI-COLON in a 413 field of such a "compound" property MUST be escaped with a BACKSLASH 414 character. SEMI-COLON characters in non-compound properties MAY be 415 escaped. On input, an escaped SEMI-COLON character is never a field 416 separator. An unescaped SEMI-COLON character may be a field 417 separator, depending on the property in which it appears. 419 Furthermore, some fields of compound properties may contain a list of 420 values delimited by a COMMA character. Therefore, a COMMA character 421 in one of a field's values MUST be escaped with a BACKSLASH 422 character, even for fields that don't allow multiple values (for 423 consistency). Compound properties allowing multiple instances MUST 424 NOT be encoded in a single content line. 426 Finally, BACKSLASH characters in values MUST be escaped with a 427 BACKSLASH character. NEWLINE (U+000A) characters in values MUST be 428 encoded by two characters: a BACKSLASH followed by either an 'n' 429 (U+006E) or an 'N' (U+004E). 431 In all other cases, escaping MUST NOT be used. 433 4. Property Value Data Types 435 Standard value types are defined below. 437 value = text 438 / text-list 439 / date-list 440 / time-list 441 / date-time-list 442 / date-and-or-time-list 443 / timestamp-list 444 / boolean 445 / integer-list 446 / float-list 447 / URI ; from Section 3 of [RFC3986] 448 / utc-offset 449 / Language-Tag 450 / iana-valuespec 451 ; Actual value type depends on property name and VALUE parameter. 453 text = *TEXT-CHAR 455 TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII 456 / %x21-2B / %x2D-5B / %x5D-7E 457 ; Backslashes, commas, and newlines must be encoded. 459 component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII 460 / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E 461 list-component = component *("," component) 463 text-list = text *("," text) 464 date-list = date *("," date) 465 time-list = time *("," time) 466 date-time-list = date-time *("," date-time) 467 date-and-or-time-list = date-and-or-time *("," date-and-or-time) 468 timestamp-list = timestamp *("," timestamp) 469 integer-list = integer *("," integer) 470 float-list = float *("," float) 472 boolean = "TRUE" / "FALSE" 473 integer = [sign] 1*DIGIT 474 float = [sign] 1*DIGIT ["." 1*DIGIT] 476 sign = "+" / "-" 478 year = 4DIGIT ; 0000-9999 479 month = 2DIGIT ; 01-12 480 day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year 481 hour = 2DIGIT ; 00-23 482 minute = 2DIGIT ; 00-59 483 second = 2DIGIT ; 00-58/59/60 depending on leap second 484 zone = utc-designator / utc-offset 485 utc-designator = %x5A ; uppercase "Z" 487 date = year [month day] 488 / year "-" month 489 / "--" month [day] 490 / "--" "-" day 491 date-noreduc = year month day 492 / "--" month day 493 / "--" "-" day 494 date-complete = year month day 496 time = hour [minute [second]] [zone] 497 / "-" minute [second] [zone] 498 / "-" "-" second [zone] 499 time-notrunc = hour [minute [second]] [zone] 500 time-complete = hour minute second [zone] 501 time-designator = %x54 ; uppercase "T" 502 date-time = date-noreduc time-designator time-notrunc 503 timestamp = date-complete time-designator time-complete 505 date-and-or-time = date-time / date / time-designator time 507 utc-offset = sign hour [minute] 509 Language-Tag = 511 iana-valuespec = 512 ; a publicly-defined valuetype format, registered 513 ; with IANA, as defined in section 12 of this 514 ; document 516 4.1. TEXT 518 "text": The "text" value type should be used to identify values that 519 contain human-readable text. As for the language, it is controlled 520 by the LANGUAGE property parameter defined in Section 5.1. 522 Examples for "text": 524 this is a text value 525 this is one value,this is another 526 this is a single value\, with a comma encoded 528 A formatted text line break in a text value type MUST be represented 529 as the character sequence backslash (U+005C) followed by a Latin 530 small letter n (U+006E) or a Latin capital letter N (U+004E), that is 531 "\n" or "\N". 533 For example a multiple line NOTE value of: 535 Mythical Manager 536 Hyjinx Software Division 537 BabsCo, Inc. 539 could be represented as: 541 NOTE:Mythical Manager\nHyjinx Software Division\n 542 BabsCo\, Inc.\n 544 demonstrating the \n literal formatted line break technique, the 545 CRLF-followed-by-space line folding technique, and the backslash 546 escape technique. 548 4.2. URI 550 "uri": The "uri" value type should be used to identify values that 551 are referenced by a Uniform Resource Identifier (URI) instead of 552 encoded in-line. These value references might be used if the value 553 is too large, or otherwise undesirable to include directly. The 554 format for the URI is as defined in Section 3 of [RFC3986]. Note 555 that the value of a property of type "uri" is what the URI points to, 556 not the URI itself. 558 Examples for "uri": 560 http://www.example.com/my/picture.jpg 561 ldap://ldap.example.com/cn=babs%20jensen 563 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP 565 "date", "time", "date-time", and "timestamp": Each of these value 566 types is based on the definitions in [ISO.8601.2004] standard. 567 Multiple such values can be specified using the comma-separated 568 notation. 570 Only the basic format is supported. 572 4.3.1. DATE 574 A calendar date as specified in [ISO.8601.2004] section 4.1.2. 576 Reduced accuracy, as specified in [ISO.8601.2004] sections 4.1.2.3 a) 577 and b), but not c), is permitted. 579 Expanded representation, as specified in [ISO.8601.2004] section 580 4.1.4, is forbidden. 582 Truncated representation, as specified in [ISO.8601.2000] sections 583 5.2.1.3 d), e), and f), is permitted. 585 Examples for "date": 587 19850412 588 1985-04 589 1985 590 --0412 591 ---12 593 Note the use of YYYY-MM in the second example above. YYYYMM is 594 disallowed to prevent confusion with YYMMDD. Note also that 595 YYYY-MM-DD is disallowed since we are using the basic format instead 596 of the extended format. 598 4.3.2. TIME 600 A time of day as specified in [ISO.8601.2004] section 4.2. 602 Reduced accuracy, as specified in [ISO.8601.2004] section 4.2.2.3, is 603 permitted. 605 Representation with decimal fraction, as specified in [ISO.8601.2004] 606 section 4.2.2.4, is forbidden. 608 The midnight hour is always represented by 00, never 24 (see 609 [ISO.8601.2004] section 4.2.3). 611 Truncated representation, as specified in [ISO.8601.2000] sections 612 5.3.1.4 a), b), and c), is permitted. 614 Examples for "time": 616 102200 617 1022 618 10 619 -2200 620 --00 621 102200Z 622 102200-0800 624 4.3.3. DATE-TIME 626 A date and time of day combination as specified in [ISO.8601.2004] 627 section 4.3. 629 Truncation of the date part, as specified in [ISO.8601.2000] section 630 5.4.2 c), is permitted. 632 Examples for "date-time": 634 19961022T140000 635 --1022T1400 636 ---22T14 638 4.3.4. DATE-AND-OR-TIME 640 Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous 641 interpretation, a standalone TIME value is always preceded by a "T". 643 Examples for "date-and-or-time": 645 19961022T140000 646 --1022T1400 647 ---22T14 648 19850412 649 1985-04 650 1985 651 --0412 652 ---12 653 T102200 654 T1022 655 T10 656 T-2200 657 T--00 658 T102200Z 659 T102200-0800 661 4.3.5. TIMESTAMP 663 A complete date and time of day combination as specified in 664 [ISO.8601.2004] section 4.3.2. 666 Examples for "timestamp": 668 19961022T140000 669 19961022T140000Z 670 19961022T140000-05 671 19961022T140000-0500 673 4.4. BOOLEAN 675 "boolean": The "boolean" value type is used to express boolean 676 values. These values are case insensitive. 678 Examples: 680 TRUE 681 false 682 True 684 4.5. INTEGER 686 "integer": The "integer" value type is used to express signed 687 integers in decimal format. If sign is not specified, the value is 688 assumed positive "+". Multiple "integer" values can be specified 689 using the comma-separated notation. The maximum value is 690 9223372036854775807 and the minimum value is -9223372036854775808. 692 These limits correspond to a signed 64-bit integer using two's- 693 complement arithmetic. 695 Examples: 697 1234567890 698 -1234556790 699 +1234556790,432109876 701 4.6. FLOAT 703 "float": The "float" value type is used to express real numbers. If 704 sign is not specified, the value is assumed positive "+". Multiple 705 "float" values can be specified using the comma-separated notation. 706 Implementations MUST support a precision equal or better than that of 707 the IEEE "binary64" format [IEEE.754.2008]. 709 Note: Scientific notation is disallowed. Implementors wishing to 710 use their favorite language's %f formatting should be careful. 712 Examples: 714 20.30 715 1000000.0000001 716 1.333,3.14 718 4.7. UTC-OFFSET 720 "utc-offset": The "utc-offset" value type specifies that the property 721 value is a signed offset from UTC. This value type can be specified 722 in the TZ property. 724 The value type is an offset from Coordinated Universal Time (UTC). 725 It is specified as a positive or negative difference in units of 726 hours and minutes (e.g., +hhmm). The time is specified as a 24-hour 727 clock. Hour values are from 00 to 23, and minute values are from 00 728 to 59. Hour and minutes are 2-digits with high order zeroes required 729 to maintain digit count. The basic format for ISO 8601 UTC offsets 730 MUST be used. 732 4.8. LANGUAGE-TAG 734 "language-tag": A single language tag, as defined in [RFC5646]. 736 5. Property Parameters 738 A property can have attributes associated with it. These "property 739 parameters" contain meta-information about the property or the 740 property value. In some cases the property parameter can be multi- 741 valued in which case the property parameter value elements are 742 separated by a COMMA (U+002C). 744 Property parameter value elements that contain the COLON (U+003A), 745 SEMICOLON (U+003B) or COMMA (U+002C) character separators MUST be 746 specified as quoted-string text values. Property parameter values 747 MUST NOT contain the DQUOTE (U+0022) character. The DQUOTE character 748 is used as a delimiter for parameter values that contain restricted 749 characters or URI text. 751 Applications MUST ignore x-param and iana-param values they don't 752 recognize. 754 5.1. LANGUAGE 756 The LANGUAGE property parameter is used to identify data in multiple 757 languages. There is no concept of "default" language, except as 758 specified by any "Content-Language" MIME header parameter that is 759 present [RFC3282]. The value of the LANGUAGE property parameter is a 760 language tag as defined in Section 2 of [RFC5646]. 762 Examples: 764 ROLE;LANGUAGE=tr:hoca 766 ABNF: 768 language-param = "LANGUAGE=" Language-Tag 769 ; Language-Tag is defined in section 2.1 of RFC 5646 771 5.2. VALUE 773 The VALUE parameter is OPTIONAL, used to identify the value type 774 (data type) and format of the value. The use of these predefined 775 formats is encouraged even if the value parameter is not explicitly 776 used. By defining a standard set of value types and their formats, 777 existing parsing and processing code can be leveraged. The 778 predefined data type values MUST NOT be repeated in COMMA separated 779 value lists except within the N, NICKNAME, ADR, and CATEGORIES 780 properties. 782 ABNF: 784 value-param = "VALUE=" value-type 786 value-type = "text" 787 / "uri" 788 / "date" 789 / "time" 790 / "date-time" 791 / "date-and-or-time" 792 / "timestamp" 793 / "boolean" 794 / "integer" 795 / "float" 796 / "utc-offset" 797 / "language-tag" 798 / iana-token ; registered as described in section 12 799 / x-name 801 5.3. PREF 803 The PREF parameter is OPTIONAL and is used to indicate that the 804 corresponding instance of a property is preferred by the vCard 805 author. Its value MUST be an integer between 1 and 100 that 806 quantifies the level of preference. Lower values correspond to a 807 higher level of preference, 1 being most preferred. 809 When the parameter is absent, the default MUST be to interpret the 810 property instance as being least preferred. 812 Note that the value of this parameter is to be interpreted only in 813 relation to values assigned to other instances of the same property 814 in the same vCard. A given value, or the absence of a value, MUST 815 NOT be interpreted on its own. 817 This parameter MAY be applied to any property that allows multiple 818 instances. 820 ABNF: 822 pref-param = "PREF=" (1*2DIGIT / "100") 823 ; An integer between 1 and 100. 825 5.4. ALTID 827 The ALTID parameter is used to "tag" property instances as being 828 alternative representations of the same logical property. For 829 example, translations of a property in multiple languages generates 830 multiple property instances having different LANGUAGE (Section 5.1) 831 parameter which are tagged with the same ALTID value. 833 This parameter's value is treated as an opaque string. Its sole 834 purpose is to be compared for equality against other ALTID parameter 835 values. 837 Two property instances are considered alternative representations of 838 the same logical property if and only if their names as well as the 839 value of their ALTID parameters are identical. Property instances 840 without the ALTID parameter MUST NOT be considered an alternative 841 representation of any other property instance. Values for the ALTID 842 parameter are not globally unique: they MAY be reused for different 843 property names. 845 Property instances having the same ALTID parameter value count as 1 846 toward cardinality. Therefore, since N (Section 6.2.2) has 847 cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these 848 three examples would be legal: 850 N;ALTID=1;LANGUAGE=jp:;;;; 851 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 852 ( denotes a UTF8-encoded Unicode character.) 854 TITLE;ALTID=1;LANGUAGE=fr:Patron 855 TITLE;ALTID=1;LANGUAGE=en:Boss 857 TITLE;ALTID=1;LANGUAGE=fr:Patron 858 TITLE;ALTID=1;LANGUAGE=en:Boss 859 TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist 861 while this one would not: 863 N;ALTID=1;LANGUAGE=jp:;;;; 864 N:Yamada;Taro;;; 865 (Two instances of the N property.) 867 and these three would be legal but questionable: 869 TITLE;ALTID=1;LANGUAGE=fr:Patron 870 TITLE;ALTID=2;LANGUAGE=en:Boss 871 (Should probably have the same ALTID value.) 873 TITLE;ALTID=1;LANGUAGE=fr:Patron 874 TITLE:LANGUAGE=en:Boss 875 (Second line should probably have ALTID=1.) 877 N;ALTID=1;LANGUAGE=jp:;;;; 878 N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; 879 N;ALTID=1;LANGUAGE=en:Smith;John;;; 880 (The last line should probably have ALTID=2. But that would be 881 illegal because N has cardinality *1.) 883 The ALTID property MAY also be used in may contexts other than with 884 the LANGUAGE parameter. Here's an example with two representations 885 of the same photo in different file formats: 887 PHOTO;ALTID=1:data:image/jpeg;base64,... 888 PHOTO;ALTID=1;data:image/jp2;base64,... 890 ABNF: 892 altid-param = "ALTID=" param-value 894 5.5. PID 896 The PID parameter is used to identify a specific property among 897 multiple instances. It plays a role analogous to the UID property 898 (Section 6.7.6) on a per-property instead of per-vCard basis. It MAY 899 appear more than once in a given property. It MUST NOT appear on 900 properties that may have only one instance per vCard. Its value is 901 either a single small positive integer or a pair of small positive 902 integers separated by a dot. Multiple values may be encoded in a 903 single PID parameter by separating the values with a comma ",". See 904 Section 7 for more details on its usage. 906 ABNF: 908 pid-param = "PID=" pid-value *("," pid-value) 909 pid-value = 1*DIGIT ["." 1*DIGIT] 911 5.6. TYPE 913 The TYPE parameter has multiple, different uses. In general, it is a 914 way of specifying class characteristics of the associated property. 915 Most of the time, its value is a comma-separated subset of a pre- 916 defined enumeration. In this document, the following properties make 917 use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL, IMPP, 918 LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES, NOTE, 919 SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE parameter 920 MUST NOT be applied on other properties defined in this document. 922 The "work" and "home" values act like tags. The "work" value implies 923 that the property is related to an individual's work place, while the 924 "home" value implies that the property is related to an individual's 925 personal life. When neither "work" nor "home" is present, it is 926 implied that the property is related to both an individual's work 927 place and personal life in the case that the KIND property's value is 928 "individual", or to none in other cases. 930 ABNF: 932 type-param = "TYPE=" type-value *("," type-value) 934 type-value = "work" / "home" / type-param-tel 935 / type-param-related / iana-token / x-name 936 ; This is further defined in individual property sections. 938 5.7. MEDIATYPE 940 The MEDIATYPE parameter is used with properties whose value is a URI. 941 Its use is OPTIONAL. It provides a hint to the vCard consumer 942 application about the media type [RFC2046] of the resource identified 943 by the URI. Some URI schemes do not need this parameter. For 944 example, the "data" scheme allows the media type to be explicitly 945 indicated as part of the URI [RFC2397]. Another scheme, "http", 946 provides the media type as part of the URI resolution process, with 947 the Content-Type HTTP header [RFC2616]. The MEDIATYPE parameter is 948 intended to be used with URI schemes that do not provide such 949 functionality (e.g. "ftp" [RFC1738]). 951 ABNF: 953 mediatype-param = "MEDIATYPE=" mediatype 954 mediatype = type-name "/" subtype-name *( ";" attribute "=" value ) 955 ; "attribute" and "value" are from [RFC2045] 956 ; "type-name" and "subtype-name" are from [RFC4288] 958 5.8. CALSCALE 960 The CALSCALE parameter is identical to the CALSCALE property in 961 iCalendar (see [RFC5545], section 3.7.1). It is used to define the 962 calendar system in which a date or date-time value is expressed. The 963 only value specified by iCalendar is "gregorian", which stands for 964 the Gregorian system. It is the default when the parameter is 965 absent. Additional values may be defined in extension documents and 966 registered from IANA (see Section 10.3.4). A vCard implementation 967 MUST ignore properties with a CALSCALE parameter value that it does 968 not understand. 970 ABNF: 972 calscale-param = "CALSCALE=" calscale-value 974 calscale-value = "gregorian" / iana-token / x-name 976 5.9. SORT-AS 978 The "sort-as" parameter is used to specify the string to be used for 979 national-language-specific sorting. Without this information, 980 sorting algorithms could incorrectly sort this vCard within a 981 sequence of sorted vCards. When this property is present in a vCard, 982 then the given strings are used for sorting the vCard. 984 This parameter's value is a comma-separated list which MUST have as 985 many or fewer elements as the corresponding property value has 986 components. This parameter's value is case-sensitive. 988 ABNF: 990 sort-as-param = "SORT-AS=" sort-as-value 992 sort-as-value = param-value *("," param-value) 994 Examples: For the case of surname and given name sorting, the 995 following examples define common sort string usage with the N 996 property. 998 FN:Rene van der Harten 999 N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N. 1001 FN:Robert Pau Shou Chang 1002 N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;; 1004 FN:Osamu Koura 1005 N;SORT-AS="Koura,Osamu":Koura;Osamu;; 1007 FN:Oscar del Pozo 1008 N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;; 1010 FN:Chistine d'Aboville 1011 N;SORT-AS="Aboville,Christine":d'Aboville;Christine;; 1013 FN:H. James de Mann 1014 N;SORT-AS="Mann,James":de Mann;Henry,James;; 1016 If sorted by surname the results would be: 1018 Christine d'Aboville 1019 Rene van der Harten 1020 Osamu Koura 1021 H. James de Mann 1022 Robert Pau Shou Chang 1023 Oscar del Pozo 1025 If sorted by given name the results would be: 1027 Christine d'Aboville 1028 H. James de Mann 1029 Osamu Koura 1030 Oscar del Pozo 1031 Rene van der Harten 1032 Robert Pau Shou Chang 1034 5.10. GEO 1036 The GEO parameter can be used to indicate global positioning 1037 information that is specific to an address. Its value is the same as 1038 that of the GEO property (see Section 6.5.2). 1040 ABNF: 1042 geo-parameter = "GEO=" DQUOTE URI DQUOTE 1044 5.11. TZ 1046 The TZ parameter can be used to indicate time zone information that 1047 is specific to an address. Its value is the same as that of the TZ 1048 property. 1050 ABNF: 1052 tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE) 1054 6. vCard Properties 1056 What follows is an enumeration of the standard vCard properties. 1058 6.1. General Properties 1060 6.1.1. BEGIN 1062 Purpose: To denote the beginning of a syntactic entity within a 1063 text/vcard content-type. 1065 Value type: text 1067 Cardinality: 1 1069 Special notes: The content entity MUST begin with the BEGIN property 1070 with a value of "VCARD". The value is case-insensitive. 1072 The BEGIN property is used in conjunction with the END property to 1073 delimit an entity containing a related set of properties within an 1074 text/vcard content-type. This construct can be used instead of 1075 including multiple vCards as body parts inside of a multipart/ 1076 alternative MIME message. It is provided for applications that 1077 wish to define content that can contain multiple entities within 1078 the same text/vcard content-type or to define content that can be 1079 identifiable outside of a MIME environment. 1081 ABNF: 1083 BEGIN-param = 0" " ; no parameter allowed 1084 BEGIN-value = "VCARD" 1086 Example: 1088 BEGIN:VCARD 1090 6.1.2. END 1092 Purpose: To denote the end of a syntactic entity within a text/vcard 1093 content-type. 1095 Value type: text 1097 Cardinality: 1 1099 Special notes: The content entity MUST end with the END type with a 1100 value of "VCARD". The value is case-insensitive. 1102 The END property is used in conjunction with the BEGIN property to 1103 delimit an entity containing a related set of properties within an 1104 text/vcard content-type. This construct can be used instead of or 1105 in addition to wrapping separate sets of information inside 1106 additional MIME headers. It is provided for applications that 1107 wish to define content that can contain multiple entities within 1108 the same text/vcard content-type or to define content that can be 1109 identifiable outside of a MIME environment. 1111 ABNF: 1113 END-param = 0" " ; no parameter allowed 1114 END-value = "VCARD" 1116 Example: 1118 END:VCARD 1120 6.1.3. SOURCE 1122 Purpose: To identify the source of directory information contained 1123 in the content type. 1125 Value type: uri 1127 Cardinality: * 1129 Special notes: The SOURCE property is used to provide the means by 1130 which applications knowledgable in the given directory service 1131 protocol can obtain additional or more up-to-date information from 1132 the directory service. It contains a URI as defined in [RFC3986] 1133 and/or other information referencing the vCard to which the 1134 information pertains. When directory information is available 1135 from more than one source, the sending entity can pick what it 1136 considers to be the best source, or multiple SOURCE properties can 1137 be included. 1139 ABNF: 1141 SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param 1142 / mediatype-param / any-param 1143 SOURCE-value = URI 1145 Examples: 1147 SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US 1149 SOURCE:http://directory.example.com/addressbooks/jdoe/ 1150 Jean%20Dupont.vcf 1152 6.1.4. KIND 1154 Purpose: To specify the kind of object the vCard represents. 1156 Value type: A single text value. 1158 Cardinality: *1 1160 Special notes: The value may be one of the following: 1162 "individual" for a vCard representing a single person or entity. 1163 This is the default kind of vCard. 1165 "group" for a vCard representing a group of persons or entities. 1166 The group's member entities can be other vCards or other types 1167 of entities, such as email addresses or web sites. A group 1168 vCard will usually contain MEMBER properties to specify the 1169 members of the group, but it is not required to. A group vCard 1170 without MEMBER properties can be considered an abstract 1171 grouping, or one whose members are known empirically (perhaps 1172 "IETF Participants" or "Republican U.S. Senators"). 1174 All properties in a group vCard apply to the group as a whole, 1175 and not to any particular MEMBER. For example, an EMAIL 1176 property might specify the address of a mailing list associated 1177 with the group, and an IMPP property might refer to a group 1178 chat room. 1180 "org" for a vCard representing an organization. An organization 1181 vCard will not (in fact, MUST NOT) contain MEMBER properties, 1182 and so these are something of a cross between "individual" and 1183 "group". An organization is a single entity, but not a person. 1184 It might represent a business or government, a department or 1185 division within a business or government, a club, an 1186 association, or the like. 1188 All properties in an organization vCard apply to the 1189 organization as a whole, as is the case with a group vCard. 1190 For example, an EMAIL property might specify the address of a 1191 contact point for the organization. 1193 "location" for a named geographical place. A location vCard will 1194 usually contain a GEO property, but it is not required to. A 1195 location vCard without a GEO property can be considered an 1196 abstract location, or one whose definition is known empirically 1197 (perhaps "New England" or "The Seashore"). 1199 All properties in a location vCard apply to the location 1200 itself, and not with any entity that might exist at that 1201 location. For example, in a vCard for an office building, an 1202 ADR property might give the mailing address for the building, 1203 and a TEL property might specify the telephone number of the 1204 receptionist. 1206 An x-name. vCards MAY include private or experimental values for 1207 KIND. Remember that x-name values are not intended for general 1208 use, and are unlikely to interoperate. 1210 An iana-token. Additional values may be registered with IANA (see 1211 Section 10.3.4). A new value's specification document MUST 1212 specify which properties make sense for that new kind of vCard 1213 and which do not. 1215 Implementations MUST support the specific string values defined 1216 above. If this property is absent, "individual" MUST be assumed 1217 as the default. If this property is present but the 1218 implementation does not understand its value (the value is an 1219 x-name or iana-token that the implementation does not support), 1220 the implementation SHOULD act in a neutral way, which usually 1221 means treating the vCard as though its kind were "individual". 1222 The presence of MEMBER properties MAY, however, be taken as an 1223 indication that the unknown kind is an extension of "group". 1225 Clients often need to visually distinguish contacts based on what 1226 they represent, and the KIND property provides a direct way for 1227 them to do so. For example, when displaying contacts in a list, 1228 an icon could be displayed next to each one, using distinctive 1229 icons for the different kinds; a client might use an outline of a 1230 single person to represent an "individual", an outline of multiple 1231 people to represent a "group", and so on. Alternatively, or in 1232 addition, a client might choose to segregate different kinds of 1233 vCards to different panes, tabs, or selections in the user 1234 interface. 1236 Some clients might also make functional distinctions among the 1237 kinds, ignoring "location" vCards for some purposes and 1238 considering only "location" vCards for others. 1240 When designing those sorts of visual and functional distinctions, 1241 client implementations have to decide how to fit unsupported kinds 1242 into the scheme. What icon is used for them? The one for 1243 "individual"? A unique one, such as an icon of a question-mark? 1244 Which tab do they go into? It is beyond the scope of this 1245 specification to answer these questions, but these are things 1246 implementors need to consider. 1248 ABNF: 1250 KIND-param = "VALUE=text" / any-param 1251 KIND-value = "individual" / "group" / "org" / "location" 1252 / iana-token / x-name 1254 Example: 1256 This represents someone named Jane Doe working in the marketing 1257 department of the North American division of ABC Inc. 1259 BEGIN:VCARD 1260 VERSION:4.0 1261 KIND:individual 1262 FN:Jane Doe 1263 ORG:ABC\, Inc.;North American Division;Marketing 1264 END:VCARD 1266 This represents the department itself, commonly known as ABC 1267 Marketing. 1269 BEGIN:VCARD 1270 VERSION:4.0 1271 KIND:org 1272 FN:ABC Marketing 1273 ORG:ABC\, Inc.;North American Division;Marketing 1274 END:VCARD 1276 6.1.5. XML 1278 Purpose: To include extended XML-encoded vCard data in a plain 1279 vCard. 1281 Value type: A single text value. 1283 Cardinality: * 1285 Special notes: The content of this property is a single XML 1.0 1286 [W3C.REC-xml-20081126] element whose namespace MUST be explicitly 1287 specified using the xmlns attribute and MUST NOT be the vCard 4 1288 namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies 1289 that it cannot duplicate a standard vCard property.) The element 1290 is to be interpreted as if it was contained in a element, 1291 as defined in [I-D.ietf-vcarddav-vcardxml]. 1293 The fragment is subject to normal line folding and escaping, i.e. 1294 replace all backslashes with "\\", then replace all newlines with 1295 "\n", then fold long lines. 1297 Support for this property is OPTIONAL, but implementations of this 1298 specification MUST preserve instances of this property when 1299 propagating vCards. 1301 See [I-D.ietf-vcarddav-vcardxml] for more information on the 1302 intended use of this property. 1304 ABNF: 1306 XML-param = "VALUE=text" / altid-param 1307 XML-value = text 1309 6.2. Identification Properties 1311 These types are used to capture information associated with the 1312 identification and naming of the entity associated with the vCard. 1314 6.2.1. FN 1316 Purpose: To specify the formatted text corresponding to the name of 1317 the object the vCard represents. 1319 Value type: A single text value. 1321 Cardinality: 1* 1323 Special notes: This property is based on the semantics of the X.520 1324 Common Name attribute. The property MUST be present in the vCard 1325 object. 1327 ABNF: 1329 FN-param = "VALUE=text" / type-param / language-param / altid-param 1330 / pid-param / pref-param / any-param 1331 FN-value = text 1333 Example: 1335 FN:Mr. John Q. Public\, Esq. 1337 6.2.2. N 1339 Purpose: To specify the components of the name of the object the 1340 vCard represents. 1342 Value type: A single structured text value. Each component can have 1343 multiple values. 1345 Cardinality: *1 1347 Special note: The structured property value corresponds, in 1348 sequence, to the Family Names (also known as surnames), Given 1349 Names, Additional Names, Honorific Prefixes, and Honorific 1350 Suffixes. The text components are separated by the SEMI-COLON 1351 character (U+003B). Individual text components can include 1352 multiple text values separated by the COMMA character (U+002C). 1353 This property is based on the semantics of the X.520 individual 1354 name attributes. The property SHOULD be present in the vCard 1355 object when the name of the object the vCard represents follows 1356 the X.520 model. 1358 The SORT-AS parameter MAY be applied to this property. 1360 ABNF: 1362 N-param = "VALUE=text" / sort-as-param / language-param 1363 / altid-param / any-param 1364 N-value = list-component 4(";" list-component) 1366 Examples: 1368 N:Public;John;Quinlan;Mr.;Esq. 1370 N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P. 1372 6.2.3. NICKNAME 1374 Purpose: To specify the text corresponding to the nickname of the 1375 object the vCard represents. 1377 Value type: One or more text values separated by a COMMA character 1378 (U+002C). 1380 Cardinality: * 1382 Special note: The nickname is the descriptive name given instead of 1383 or in addition to the one belonging to a the object the vCard 1384 represents. It can also be used to specify a familiar form of a 1385 proper name specified by the FN or N properties. 1387 ABNF: 1389 NICKNAME-param = "VALUE=text" / type-param / language-param 1390 / altid-param / pid-param / pref-param / any-param 1391 NICKNAME-value = text-list 1393 Examples: 1395 NICKNAME:Robbie 1397 NICKNAME:Jim,Jimmie 1399 NICKNAME;TYPE=work:Boss 1401 6.2.4. PHOTO 1403 Purpose: To specify an image or photograph information that 1404 annotates some aspect of the object the vCard represents. 1406 Value type: A single URI. 1408 Cardinality: * 1410 ABNF: 1412 PHOTO-param = "VALUE=uri" / altid-param / type-param 1413 / mediatype-param / pref-param / pid-param / any-param 1414 PHOTO-value = URI 1416 Examples: 1418 PHOTO:http://www.example.com/pub/photos/jqpublic.gif 1420 PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv 1421 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1422 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1423 <...remainder of base64-encoded data...> 1425 6.2.5. BDAY 1427 Purpose: To specify the birth date of the object the vCard 1428 represents. 1430 Value type: The default is a single date-and-or-time value. It can 1431 also be reset to a single text value. 1433 Cardinality: *1 1435 ABNF: 1437 BDAY-param = BDAY-param-date / BDAY-param-text 1438 BDAY-value = date-and-or-time / text 1439 ; Value and parameter MUST match. 1441 BDAY-param-date = "VALUE=date-and-or-time" 1442 BDAY-param-text = "VALUE=text" / language-param 1444 BDAY-param =/ altid-param / calscale-param / any-param 1445 ; calscale-param can only be present when BDAY-value is 1446 ; date-and-or-time and actually contains a date or date-time. 1448 Examples: 1450 BDAY:19960415 1451 BDAY:--0415 1452 BDAY;19531015T231000Z 1453 BDAY;VALUE=text:circa 1800 1455 6.2.6. ANNIVERSARY 1457 Purpose: The date of marriage, or equivalent, of the object the 1458 vCard represents. 1460 Value type: The default is a single date-and-or-time value. It can 1461 also be reset to a single text value. 1463 Cardinality: *1 1465 ABNF: 1467 ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text") 1468 ANNIVERSARY-value = date-and-or-time / text 1469 ; Value and parameter MUST match. 1471 ANNIVERSARY-param =/ altid-param / calscale-param / any-param 1472 ; calscale-param can only be present when ANNIVERSARY-value is 1473 ; date-and-or-time and actually contains a date or date-time. 1475 Examples: 1477 ANNIVERSARY:19960415 1479 6.2.7. GENDER 1481 Purpose: To specify the components of the sex and gender identity of 1482 the object the vCard represents. 1484 Value type: A single structured value with two components. Each 1485 component has a single text value. 1487 Cardinality: *1 1489 Special notes: The components correspond, in sequence, to the sex 1490 (biological), and gender identity. Each component is optional. 1492 Sex component: A single letter. M stands for "male", F stands 1493 for "female", O stands for "other", N stands for "none or not 1494 applicable", U stands for "unknown". 1496 Gender identity component: Free-form text. 1498 ABNF: 1500 GENDER-param = "VALUE=text" / any-param 1501 GENDER-value = sex [";" text] 1503 sex = "" / "M" / "F" / "O" / "N" / "U" 1505 Examples: 1507 GENDER:M 1508 GENDER:F 1509 GENDER:M;Fellow 1510 GENDER:F;grrrl 1511 GENDER:O;intersex 1512 GENDER:;it's complicated 1514 6.3. Delivery Addressing Properties 1516 These types are concerned with information related to the delivery 1517 addressing or label for the vCard object. 1519 6.3.1. ADR 1521 Purpose: To specify the components of the delivery address for the 1522 vCard object. 1524 Value type: A single structured text value, separated by the SEMI- 1525 COLON character (U+003B). 1527 Cardinality: * 1529 Special notes: The structured type value consists of a sequence of 1530 address components. The component values MUST be specified in 1531 their corresponding position. The structured type value 1532 corresponds, in sequence, to 1533 the post office box; 1534 the extended address (e.g. apartment or suite number); 1535 the street address; 1536 the locality (e.g., city); 1537 the region (e.g., state or province); 1538 the postal code; 1539 the country name (full name in the language specified in 1540 Section 5.1). 1541 When a component value is missing, the associated component 1542 separator MUST still be specified. 1544 Experience with vCard 3 has shown that the first two components 1545 (post office box and extended address) are plagued with many 1546 interoperability issues. To ensure maximal interoperability, 1547 their values SHOULD be empty. 1549 The text components are separated by the SEMI-COLON character 1550 (U+003B). Where it makes semantic sense, individual text 1551 components can include multiple text values (e.g., a "street" 1552 component with multiple lines) separated by the COMMA character 1553 (U+002C). 1555 The property can include the "PREF" parameter to indicate the 1556 preferred delivery address when more than one address is 1557 specified. 1559 The GEO and TZ parameters MAY be used with this property. 1561 The property can also include a "LABEL" parameter to present a 1562 delivery delivery address label for the address. Its value is a 1563 plain-text string representing the formatted address. Newlines 1564 are encoded as \n, as they are for property values. 1566 ABNF: 1568 label-param = "LABEL=" param-value 1570 ADR-param = "VALUE=text" / label-param / language-param 1571 / geo-parameter / tz-parameter / altid-param / pid-param 1572 / pref-param / type-param / any-param 1573 ADR-value = ADR-component-pobox ";" ADR-component-ext ";" 1574 ADR-component-street ";" ADR-component-locality ";" 1575 ADR-component-region ";" ADR-component-code ";" 1576 ADR-component-country 1577 ADR-component-pobox = list-component 1578 ADR-component-ext = list-component 1579 ADR-component-street = list-component 1580 ADR-component-locality = list-component 1581 ADR-component-region = list-component 1582 ADR-component-code = list-component 1583 ADR-component-country = list-component 1585 Example: In this example the post office box and the extended address 1586 are absent. 1588 ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n 1589 Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n 1590 U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A. 1592 6.4. Communications Properties 1594 These properties describe information about how to communicate with 1595 the object the vCard represents. 1597 6.4.1. TEL 1598 Purpose: To specify the telephone number for telephony communication 1599 with the object the vCard represents. 1601 Value type: By default it is a single free-form text value (for 1602 backward compatibility with vCard 3), but it SHOULD be reset to a 1603 URI value. It is expected that the URI scheme will be "tel", as 1604 specified in [RFC3966], but other schemes MAY be used. 1606 Cardinality: * 1608 Special notes: This property is based on the X.520 Telephone Number 1609 attribute. 1611 The property can include the "PREF" parameter to indicate a 1612 preferred-use telephone number. 1614 The property can include the parameter "TYPE" to specify intended 1615 use for the telephone number. The predefined values for the TYPE 1616 parameter are: 1618 +-----------+-------------------------------------------------------+ 1619 | Value | Description | 1620 +-----------+-------------------------------------------------------+ 1621 | text | Indicates that the telephone number supports text | 1622 | | messages (SMS). | 1623 | voice | Indicates a voice telephone number. | 1624 | fax | Indicates a facsimile telephone number. | 1625 | cell | Indicates a cellular or mobile telephone number. | 1626 | video | Indicates a video conferencing telephone number. | 1627 | pager | Indicates a paging device telephone number. | 1628 | textphone | Indicates a telecommunication device for people with | 1629 | | hearing or speech difficulties.. | 1630 +-----------+-------------------------------------------------------+ 1632 The default type is "voice". These type parameter values can be 1633 specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a 1634 value list (e.g., TYPE="text,voice"). The default can be 1635 overridden to another set of values by specifying one or more 1636 alternate values. For example, the default TYPE of "voice" can be 1637 reset to a VOICE and FAX telephone number by the value list 1638 TYPE="voice,fax". 1640 If this property's value is a URI that can also be used for 1641 instant messaging, the IMPP (Section 6.4.3) property SHOULD be 1642 used in addition to this property. 1644 ABNF: 1646 TEL-param = TEL-text-param / TEL-uri-param 1647 TEL-value = TEL-text-value / TEL-uri-value 1648 ; Value and parameter MUST match 1650 TEL-text-param = "VALUE=text" 1651 TEL-text-value = text 1653 TEL-uri-param = "VALUE=uri" / mediatype-param 1654 TEL-uri-value = URI 1656 TEL-param =/ type-param / pid-param / pref-param / altid-param 1657 / any-param 1659 type-param-tel = "text" / "voice" / "fax" / "cell" / "video" 1660 / "pager" / "textphone" / iana-token / x-name 1661 ; type-param-tel MUST NOT be used with a property other than TEL. 1663 Example: 1665 TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555 1666 TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67 1668 6.4.2. EMAIL 1670 Purpose: To specify the electronic mail address for communication 1671 with the object the vCard represents. 1673 Value type: A single text value. 1675 Cardinality: * 1677 Special notes: The property can include tye "PREF" parameter to 1678 indicate a preferred-use email address when more than one is 1679 specified. 1681 Even though the value is free-form UTF-8 text, it is likely to be 1682 interpreted by an MUA as an "addr-spec", as defined in [RFC5322], 1683 section 3.4.1. Readers should also be aware of the current work 1684 toward internationalized email addresses 1685 [I-D.ietf-eai-rfc5335bis]. 1687 ABNF: 1689 EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param 1690 / altid-param / any-param 1691 EMAIL-value = text 1693 Example: 1695 EMAIL;TYPE=work:jqpublic@xyz.example.com 1697 EMAIL;PREF=1:jane_doe@example.com 1699 6.4.3. IMPP 1701 Purpose: To specify the URI for instant messaging and presence 1702 protocol communications with the object the vCard represents. 1704 Value type: A single URI. 1706 Cardinality: * 1708 Special notes: The property may include the "PREF" parameter to 1709 indicate that this is a preferred address and has the same 1710 semantics as the "PREF" parameter in a TEL property. 1712 If this property's value is a URI that can be used for voice 1713 and/or video, the TEL property (Section 6.4.1) SHOULD be used in 1714 addition to this property. 1716 This property is adapted from [RFC4770], which is made obsolete by 1717 this document. 1719 ABNF: 1721 IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param 1722 / mediatype-param / altid-param / any-param 1723 IMPP-value = URI 1725 Example: 1727 IMPP;PREF=1:xmpp:alice@example.com 1729 6.4.4. LANG 1731 Purpose: To specify the language(s) that may be used for contacting 1732 the entity associated with the vCard. 1734 Value type: A single language-tag value. 1736 Cardinality: * 1737 ABNF: 1739 LANG-param = "VALUE=language-tag" / pid-param / pref-param 1740 / altid-param / type-param / any-param 1741 LANG-value = Language-Tag 1743 Example: 1745 LANG;TYPE=work;PREF=1:en 1746 LANG;TYPE=work;PREF=2:fr 1747 LANG;TYPE=home:fr 1749 6.5. Geographical Properties 1751 These properties are concerned with information associated with 1752 geographical positions or regions associated with the object the 1753 vCard represents. 1755 6.5.1. TZ 1757 Purpose: To specify information related to the time zone of the 1758 object the vCard represents. 1760 Value type: The default is a single text value. It can also be 1761 reset to a single URI or utc-offset value. 1763 Cardinality: * 1765 Special notes: It is expected that names from the public-domain 1766 Olson database [TZ-DB] will be used, but this is not a 1767 restriction. See also [I-D.lear-iana-timezone-database]. 1769 Efforts are currently being directed at creating a standard URI 1770 scheme for expressing time zone information. Usage of such a 1771 scheme would ensure a high level of interoperability between 1772 implementations that support it. 1774 Note that utc-offset values SHOULD NOT be used because the UTC 1775 offset varies with time - not just because of the usual daylight 1776 saving time shifts that occur in may regions, but often entire 1777 regions will "re-base" their overall offset. The actual offset 1778 may be +/- 1 hour (or perhaps a little more) than the one given. 1780 ABNF: 1782 TZ-param = "VALUE=" ("text" / "uri" / "utc-offset") 1783 TZ-value = text / URI / utc-offset 1784 ; Value and parameter MUST match 1786 TZ-param =/ altid-param / pid-param / pref-param / type-param 1787 / mediatype-param / any-param 1789 Examples: 1791 TZ:Raleigh/North America 1793 TZ;VALUE=utc-offset:-0500 1794 ; Note: utc-offset format is NOT RECOMMENDED. 1796 6.5.2. GEO 1798 Purpose: To specify information related to the global positioning of 1799 the object the vCard represents. 1801 Value type: A single URI. 1803 Cardinality: * 1805 Special notes: The "geo" URI scheme [RFC5870] is particularly well- 1806 suited for this property, but other schemes MAY be used. 1808 ABNF: 1810 GEO-param = "VALUE=uri" / pid-param / pref-param / type-param 1811 / mediatype-param / altid-param / any-param 1812 GEO-value = URI 1814 Example: 1816 GEO:geo:37.386013,-122.082932 1818 6.6. Organizational Properties 1820 These properties are concerned with information associated with 1821 characteristics of the organization or organizational units of the 1822 object that the vCard represents. 1824 6.6.1. TITLE 1825 Purpose: To specify the position or job of the object the vCard 1826 represents. 1828 Value type: A single text value. 1830 Cardinality: * 1832 Special notes: This property is based on the X.520 Title attribute. 1834 ABNF: 1836 TITLE-param = "VALUE=text" / language-param / pid-param 1837 / pref-param / altid-param / type-param / any-param 1838 TITLE-value = text 1840 Example: 1842 TITLE:Research Scientist 1844 6.6.2. ROLE 1846 Purpose: To specify the function or part played in a particular 1847 situation by the object the vCard represents. 1849 Value type: A single text value. 1851 Cardinality: * 1853 Special notes: This property is based on the X.520 Business Category 1854 explanatory attribute. This property is included as an 1855 organizational type to avoid confusion with the semantics of the 1856 TITLE property and incorrect usage of that property when the 1857 semantics of this property is intended. 1859 ABNF: 1861 ROLE-param = "VALUE=text" / language-param / pid-param / pref-param 1862 / type-param / altid-param / any-param 1863 ROLE-value = text 1865 Example: 1867 ROLE:Project Leader 1869 6.6.3. LOGO 1871 Purpose: To specify a graphic image of a logo associated with the 1872 object the vCard represents. 1874 Value type: A single URI. 1876 Cardinality: * 1878 ABNF: 1880 LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param 1881 / type-param / mediatype-param / altid-param / any-param 1882 LOGO-value = URI 1884 Examples: 1886 LOGO:http://www.example.com/pub/logos/abccorp.jpg 1888 LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc 1889 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 1890 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 1891 <...the remainder of base64-encoded data...> 1893 6.6.4. ORG 1895 Purpose: To specify the organizational name and units associated 1896 with the vCard. 1898 Value type: A single structured text value consisting of components 1899 separated by the SEMI-COLON character (U+003B). 1901 Cardinality: * 1903 Special notes: The property is based on the X.520 Organization Name 1904 and Organization Unit attributes. The property value is a 1905 structured type consisting of the organization name, followed by 1906 zero or more levels of organizational unit names. 1908 The SORT-AS parameter MAY be applied to this property. 1910 ABNF: 1912 ORG-param = "VALUE=text" / sort-as-param / language-param 1913 / pid-param / pref-param / altid-param / type-param 1914 / any-param 1915 ORG-value = component *(";" component) 1917 Example: A property value consisting of an organizational name, 1918 organizational unit #1 name and organizational unit #2 name. 1920 ORG:ABC\, Inc.;North American Division;Marketing 1922 6.6.5. MEMBER 1924 Purpose: To include a member in the group this vCard represents. 1926 Value type: A single URI. It MAY refer to something other than a 1927 vCard object. For example, an e-mail distribution list could 1928 employ the "mailto" URI scheme [RFC6068] for efficiency. 1930 Cardinality: * 1932 Special notes: This property MUST NOT be present unless the value of 1933 the KIND property is "group". 1935 ABNF: 1937 MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param 1938 / mediatype-param / any-param 1939 MEMBER-value = URI 1941 Examples: 1943 BEGIN:VCARD 1944 VERSION:4.0 1945 KIND:group 1946 FN:The Doe family 1947 MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1948 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1949 END:VCARD 1950 BEGIN:VCARD 1951 VERSION:4.0 1952 FN:John Doe 1953 UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af 1954 END:VCARD 1955 BEGIN:VCARD 1956 VERSION:4.0 1957 FN:Jane Doe 1958 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 1959 END:VCARD 1960 BEGIN:VCARD 1961 VERSION:4.0 1962 KIND:group 1963 FN:Funky distribution list 1964 MEMBER:mailto:subscriber1@example.com 1965 MEMBER:xmpp:subscriber2@example.com 1966 MEMBER:sip:subscriber3@example.com 1967 MEMBER:tel:+1-418-555-5555 1968 END:VCARD 1970 6.6.6. RELATED 1972 Purpose: To specify a relationship between another entity and the 1973 entity represented by this vCard. 1975 Value type: A single URI. It can also be reset to a single text 1976 value. The text value can be used to specify textual information. 1978 Cardinality: * 1980 Special notes: The TYPE parameter MAY be used to characterize the 1981 related entity. It contains a comma-separated list of values that 1982 are registered from IANA as described in Section 10.2. The 1983 registry is pre-populated with the values defined in [xfn]. This 1984 document also specifies two additional values: 1986 agent: an entity who may sometimes act on behalf of the entity 1987 associated with the vCard. 1989 emergency: indicates an emergency contact 1991 ABNF: 1993 RELATED-param = RELATED-param-uri / RELATED-param-text 1994 RELATED-value = URI / text 1995 ; Parameter and value MUST match. 1997 RELATED-param-uri = "VALUE=uri" / mediatype-param 1998 RELATED-param-text = "VALUE=text" / language-param 2000 RELATED-param =/ pid-param / pref-param / altid-param / type-param 2001 / any-param 2003 type-param-related = related-type-value *("," related-type-value) 2004 ; type-param-related MUST NOT be used with a property other than 2005 ; RELATED. 2007 related-type-value = "contact" / "acquaintance" / "friend" / "met" 2008 / "co-worker" / "colleague" / "co-resident" 2009 / "neighbor" / "child" / "parent" 2010 / "sibling" / "spouse" / "kin" / "muse" 2011 / "crush" / "date" / "sweetheart" / "me" 2012 / "agent" / "emergency" 2014 Examples: 2016 RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2017 RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf 2018 RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane 2019 Doe for any inquiries. 2021 6.7. Explanatory Properties 2023 These properties are concerned with additional explanations, such as 2024 that related to informational notes or revisions specific to the 2025 vCard. 2027 6.7.1. CATEGORIES 2029 Purpose: To specify application category information about the 2030 vCard. Also known as "tags". 2032 Value type: One or more text values separated by a COMMA character 2033 (U+002C). 2035 Cardinality: * 2037 ABNF: 2039 CATEGORIES-param = "VALUE=text" / pid-param / pref-param 2040 / type-param / altid-param / any-param 2042 CATEGORIES-value = text-list 2044 Example: 2046 CATEGORIES:TRAVEL AGENT 2048 CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY 2050 6.7.2. NOTE 2052 Purpose: To specify supplemental information or a comment that is 2053 associated with the vCard. 2055 Value type: A single text value. 2057 Cardinality: * 2059 Special notes: The property is based on the X.520 Description 2060 attribute. 2062 ABNF: 2064 NOTE-param = "VALUE=text" / language-param / pid-param / pref-param 2065 / type-param / altid-param / any-param 2066 NOTE-value = text 2068 Example: 2070 NOTE:This fax number is operational 0800 to 1715 2071 EST\, Mon-Fri. 2073 6.7.3. PRODID 2075 Purpose: To specify the identifier for the product that created the 2076 vCard object. 2078 Type value: A single text value. 2080 Cardinality: *1 2082 Special notes: Implementations SHOULD use a method such as that 2083 specified for Formal Public Identifiers in [ISO9070] or for 2084 Universal Resource Names in [RFC3406] to ensure that the text 2085 value is unique. 2087 ABNF: 2089 PRODID-param = "VALUE=text" / any-param 2090 PRODID-value = text 2092 Example: 2094 PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN 2096 6.7.4. REV 2098 Purpose: To specify revision information about the current vCard. 2100 Value type: A single timestamp value. 2102 Cardinality: *1 2104 Special notes: The value distinguishes the current revision of the 2105 information in this vCard for other renditions of the information. 2107 ABNF: 2109 REV-param = "VALUE=timestamp" / any-param 2110 REV-value = timestamp 2112 Example: 2114 REV:19951031T222710Z 2116 6.7.5. SOUND 2118 Purpose: To specify a digital sound content information that 2119 annotates some aspect of the vCard. This property is often used 2120 to specify the proper pronunciation of the name property value of 2121 the vCard. 2123 Value type: A single URI. 2125 Cardinality: * 2127 ABNF: 2129 SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param 2130 / type-param / mediatype-param / altid-param 2131 / any-param 2132 SOUND-value = URI 2134 Example: 2136 SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com 2138 SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh 2139 AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm 2140 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 2141 <...the remainder of base64-encoded data...> 2143 6.7.6. UID 2145 Purpose: To specify a value that represents a globally unique 2146 identifier corresponding to the entity associated with the vCard. 2148 Value type: A single URI value. It MAY also be reset to free-form 2149 text. 2151 Cardinality: *1 2153 Special notes: This property is used to uniquely identify the object 2154 that the vCard represents. The "uuid" URN namespace defined in 2155 [RFC4122] is particularly well-suited to this task, but other URI 2156 schemes MAY be used. Free-form text MAY also be used. 2158 ABNF: 2160 UID-param = UID-uri-param / UID-text-param 2161 UID-value = UID-uri-value / UID-text-value 2162 ; Value and parameter MUST match. 2164 UID-uri-param = "VALUE=uri" 2165 UID-uri-value = URI 2167 UID-text-param = "VALUE=text" 2168 UID-text-value = text 2170 UID-param =/ any-param 2172 Example: 2174 UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2176 6.7.7. CLIENTPIDMAP 2178 Purpose: To give a global meaning to a local PID source identifier. 2180 Value type: A semicolon-separated pair of values. The first field 2181 is a small integer corresponding to the second field of a PID 2182 parameter instance. The second field is a URI. The "uuid" URN 2183 namespace defined in [RFC4122] is particularly well-suited to this 2184 task, but other URI schemes MAY be used. 2186 Cardinality: * 2188 Special notes: PID source identifiers (the source identifier is the 2189 second field in a PID parameter instance) are small integers that 2190 only have significance within the scope of a single vCard 2191 instance. Each distinct source identifier present in a vCard MUST 2192 have an associated CLIENTPIDMAP. See Section 7 for more details 2193 on the usage of CLIENTPIDMAP. 2195 PID source identifiers MUST be strictly positive. Zero is not 2196 allowed. 2198 As a special exception, the PID parameter MUST NOT be applied to 2199 this property. 2201 ABNF: 2203 CLIENTPIDMAP-param = any-param 2204 CLIENTPIDMAP-value = 1*DIGIT ";" URI 2206 Example: 2208 TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555 2209 EMAIL;PID=4.1,5.2:jdoe@example.com 2210 CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b 2211 CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5 2213 6.7.8. URL 2215 Purpose: To specify a uniform resource locator associated with the 2216 object that the vCard refers to. Examples for individuals include 2217 personal web sites, blogs, and social networking site identifiers. 2219 Cardinality: * 2221 Value type: A single uri value. 2223 ABNF: 2225 URL-param = "VALUE=uri" / pid-param / pref-param / type-param 2226 / mediatype-param / altid-param / any-param 2227 URL-value = URI 2229 Example: 2231 URL:http://example.org/restaurant.french/~chezchic.html 2233 6.7.9. VERSION 2235 Purpose: To specify the version of the vCard specification used to 2236 format this vCard. 2238 Value type: A single text value. 2240 Cardinality: 1 2242 Special notes: This property MUST be present in the vCard object, 2243 and it must appear immediately after BEGIN:VCARD. The value MUST 2244 be "4.0" if the vCard corresponds to this specification. Note 2245 that earlier versions of vCard allowed this property to be placed 2246 anywhere in the vCard object, or even to be absent. 2248 ABNF: 2250 VERSION-param = "VALUE=text" / any-param 2251 VERSION-value = "4.0" 2253 Example: 2255 VERSION:4.0 2257 6.8. Security Properties 2259 These properties are concerned with the security of communication 2260 pathways or access to the vCard. 2262 6.8.1. KEY 2264 Purpose: To specify a public key or authentication certificate 2265 associated with the object that the vCard represents. 2267 Value type: A single URI. It can also be reset to a text value. 2269 Cardinality: * 2271 ABNF: 2273 KEY-param = KEY-uri-param / KEY-text-param 2274 KEY-value = KEY-uri-value / KEY-text-value 2275 ; Value and parameter MUST match. 2277 KEY-uri-param = "VALUE=uri" / mediatype-param 2278 KEY-uri-value = URI 2280 KEY-text-param = "VALUE=text" 2281 KEY-text-value = text 2283 KEY-param =/ altid-param / pid-param / pref-param / type-param 2284 / any-param 2286 Examples: 2288 KEY:http://www.example.com/keys/jdoe.cer 2290 KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe 2292 KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE 2293 UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l 2294 <... remainder of base64-encoded data ...> 2296 6.9. Calendar Properties 2298 These properties are further specified in [RFC2739]. 2300 6.9.1. FBURL 2302 Purpose: To specify the URI for the busy time associated with the 2303 object that the vCard represents. 2305 Value type: A single URI value. 2307 Cardinality: * 2309 Special notes: Where multiple FBURL properties are specified, the 2310 default FBURL property is indicated with the PREF parameter. The 2311 FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar 2312 [RFC5545] object associated with a snapshot of the next few weeks 2313 or months of busy time data. If the iCalendar object is 2314 represented as a file or document, its file extension should be 2315 ".ifb". 2317 ABNF: 2319 FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param 2320 / mediatype-param / altid-param / any-param 2322 FBURL-value = URI 2324 Examples: 2326 FBURL;PREF=1:http://www.example.com/busy/janedoe 2327 FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb 2329 6.9.2. CALADRURI 2331 Purpose: To specify the calendar user address [RFC5545] to which a 2332 scheduling request [RFC5546] should be sent for the object 2333 represented by the vCard. 2335 Value type: A single URI value. 2337 Cardinality: * 2339 Special notes: Where multiple CALADRURI properties are specified, 2340 the default CALADRURI property is indicated with the PREF 2341 parameter. 2343 ABNF: 2345 CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2346 / mediatype-param / altid-param / any-param 2347 CALADRURI-value = URI 2349 Example: 2351 CALADRURI;PREF=1:mailto:janedoe@example.com 2352 CALADRURI:http://example.com/calendar/jdoe 2354 6.9.3. CALURI 2356 Purpose: To specify the URI for a calendar associated with the 2357 object represented by the vCard. 2359 Value type: A single URI value. 2361 Cardinality: * 2363 Special notes: Where multiple CALURI properties are specified, the 2364 default CALURI property is indicated with the PREF parameter. The 2365 property should contain a URI pointing to an iCalendar [RFC5545] 2366 object associated with a snapshot of the user's calendar store. 2367 If the iCalendar object is represented as a file or document, its 2368 file extension should be ".ics". 2370 ABNF: 2372 CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param 2373 / mediatype-param / altid-param / any-param 2374 CALURI-value = URI 2376 Examples: 2378 CALURI;PREF=1:http://cal.example.com/calA 2379 CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics 2381 6.10. Extended Properties and Parameters 2383 The properties and parameters defined by this document can be 2384 extended. Non-standard, private properties and parameters with a 2385 name starting with "X-" may be defined bilaterally between two 2386 cooperating agents without outside registration or standardization. 2388 7. Synchronization 2390 vCard data often needs to be synchronized between devices. In this 2391 context, synchronization is defined as the intelligent merging of two 2392 representations of the same object. vCard 4.0 includes mechanisms to 2393 aid this process. 2395 7.1. Mechanisms 2397 Two mechanisms are available: the UID property is used to match 2398 multiple instances of the same vCard, while the PID parameter is used 2399 to match multiple instances of the same property. 2401 The term "matching" is used here to mean recognizing that two 2402 instances are in fact representations of the same object. For 2403 example, a single vCard that is shared with someone results in two 2404 vCard instances. After they have evolved separately, they still 2405 represent the same object, and therefore may be matched by a 2406 synchronization engine. 2408 7.1.1. Matching vCard Instances 2410 vCard instances for which the UID properties (Section 6.7.6) are 2411 equivalent MUST be matched. Equivalence is determined as specified 2412 in [RFC3986], Section 6. 2414 In all other cases, vCard instances MAY be matched at the discretion 2415 of the synchronization engine. 2417 7.1.2. Matching Property Instances 2419 Property instances belonging to unmatched vCards MUST NOT be matched. 2421 Property instances whose name (e.g. EMAIL, TEL, etc.) is not the 2422 same MUST NOT be matched. 2424 Property instances whose name is CLIENTPIDMAP are handled separately 2425 and MUST NOT be matched. The synchronization MUST ensure that there 2426 is consistency of CLIENTPIDMAPs among matched vCard instances. 2428 Property instances belonging to matched vCards, whose name is the 2429 same, and whose maximum cardinality is 1 MUST be matched. 2431 Property instances belonging to matched vCards, whose name is the 2432 same, and whose PID parameters match MUST be matched. See 2433 Section 7.1.3 for details on PID matching. 2435 In all other cases, property instances MAY be matched at the 2436 discretion of the synchronization engine. 2438 7.1.3. PID Matching 2440 Two PID values for which the first fields are equivalent represent 2441 the same local value. 2443 Two PID values representing the same local value and for which the 2444 second fields point to CLIENTPIDMAP properties whose second field 2445 URIs are equivalent (as specified in [RFC3986], Section 6) also 2446 represent the same global value. 2448 PID parameters for which at least one pair of their values represent 2449 the same global value MUST be matched. 2451 In all other cases, PID parameters MAY be matched at the discretion 2452 of the synchronization engine. 2454 For example, PID value "5.1", in the first vCard below, and PID value 2455 "5.2", in the second vCard below, represent the same global value. 2457 BEGIN:VCARD 2458 VERSION:4.0 2459 EMAIL;PID=4.2,5.1:jdoe@example.com 2460 CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2461 CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc 2462 END:VCARD 2464 BEGIN:VCARD 2465 VERSION:4.0 2466 EMAIL;PID=5.1,5.2:john@example.com 2467 CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d 2468 CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 2469 END:VCARD 2471 7.2. Example 2473 7.2.1. Creation 2475 The following simple vCard is first created on a given device. 2477 BEGIN:VCARD 2478 VERSION:4.0 2479 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2480 FN;PID=1.1:J. Doe 2481 N:Doe;J.;;; 2482 EMAIL;PID=1.1:jdoe@example.com 2483 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2484 END:VCARD 2486 This new vCard is assigned the UID 2487 "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating 2488 device. The FN and EMAIL properties are assigned the same local 2489 value of 1, and this value is given global context by associating it 2490 with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which 2491 represents the creating device. We are at liberty to reuse the same 2492 local value since instances of different properties will never be 2493 matched. The N property has no PID because it is forbidden by its 2494 maximum cardinality of 1. 2496 7.2.2. Initial Sharing 2498 This vCard is shared with a second device. Upon inspecting the UID 2499 property, the second device understands that this is a new vCard 2500 (i.e. unmatched) and thus the synchronization results in a simple 2501 copy. 2503 7.2.3. Adding and Sharing a Property 2505 A new phone number is created on the first device, then the vCard is 2506 shared with the second device. This is what the second device 2507 receives: 2509 BEGIN:VCARD 2510 VERSION:4.0 2511 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2512 FN;PID=1.1:J. Doe 2513 N:Doe;J.;;; 2514 EMAIL;PID=1.1:jdoe@example.com 2515 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2516 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2517 END:VCARD 2519 Upon inspecting the UID property, the second device matches the vCard 2520 it received to the vCard that it already has stored. It then starts 2521 comparing the properties of the two vCards in same-named pairs. 2523 The FN properties are matched because the PID parameters have the 2524 same global value. Since the property value is the same, no update 2525 takes place. 2527 The N properties are matched automatically because their maximum 2528 cardinality is 1. Since the property value is the same, no update 2529 takes place. 2531 The EMAIL properties are matched because the PID parameters have the 2532 same global value. Since the property value is the same, no update 2533 takes place. 2535 The TEL property in the new vCard is not matched to any in the stored 2536 vCard because no property in the stored vCard has the same name. 2537 Therefore, this property is copied from the new vCard to the stored 2538 vCard. 2540 The CLIENTPIDMAP property is handled separately by the 2541 synchronization engine. It ensures that it is consistent with the 2542 stored one. If it was not, the results would be up to the 2543 synchronization engine, and thus undefined by this document. 2545 7.2.4. Simultaneous Editing 2547 A new email address and a new phone number are added to the vCard on 2548 each of the two devices, and then a new synchronization event 2549 happens. Here are the vCards that are communicated to each other: 2551 BEGIN:VCARD 2552 VERSION:4.0 2553 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2554 FN;PID=1.1:J. Doe 2555 N:Doe;J.;;; 2556 EMAIL;PID=1.1:jdoe@example.com 2557 EMAIL;PID=2.1:boss@example.com 2558 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2559 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2560 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2561 END:VCARD 2563 BEGIN:VCARD 2564 VERSION:4.0 2565 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2566 FN;PID=1.1:J. Doe 2567 N:Doe;J.;;; 2568 EMAIL;PID=1.1:jdoe@example.com 2569 EMAIL;PID=2.2:ceo@example.com 2570 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2571 TEL;PID=2.2;VALUE=uri: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 On the first device, the same PID source identifier (1) is reused for 2577 the new EMAIL and TEL properties. On the second device, a new source 2578 identifier (2) is generated, and a corresponding CLIENTPIDMAP 2579 property is created. It contains the second device's identifier, 2580 "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee". 2582 The new EMAIL properties are unmatched on both sides since the PID 2583 global value is new in both cases. The sync thus results in a copy 2584 on both sides. 2586 Although the situation appears to be the same for the TEL properties, 2587 in this case the synchronization engine is particularly smart and 2588 matches the two new TEL properties even though their PID global 2589 values are different. Note that in this case, the rules of section 2590 Section 7.1.2 state that two properties MAY be matched at the 2591 discretion of the synchronization engine. Therefore, the two 2592 properties are merged. 2594 All this results in the following vCard which is stored on both 2595 devices: 2597 BEGIN:VCARD 2598 VERSION:4.0 2599 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2600 FN:J. Doe 2601 N:Doe;J.;;; 2602 EMAIL;PID=1.1:jdoe@example.com 2603 EMAIL;PID=2.1:boss@example.com 2604 EMAIL;PID=2.2:ceo@example.com 2605 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2606 TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666 2607 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2608 CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee 2609 END:VCARD 2611 7.2.5. Global Context Simplification 2613 The two devices finish their synchronization procedure by simplifying 2614 their global contexts. Since they haven't talked to any other 2615 device, the following vCard is for all purposes equivalent to the 2616 above. It is also shorter. 2618 BEGIN:VCARD 2619 VERSION:4.0 2620 UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 2621 FN:J. Doe 2622 N:Doe;J.;;; 2623 EMAIL;PID=1.1:jdoe@example.com 2624 EMAIL;PID=2.1:boss@example.com 2625 EMAIL;PID=3.1:ceo@example.com 2626 TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 2627 TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 2628 CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 2629 END:VCARD 2631 The details of global context simplification are unspecified by this 2632 document. They are left up to the synchronization engine. This 2633 example is merely intended to illustrate the possibility, which 2634 investigating would be, in the authors' opinion, worthwhile. 2636 8. Example: Author's vCard 2638 BEGIN:VCARD 2639 VERSION:4.0 2640 FN:Simon Perreault 2641 N:Perreault;Simon;;;ing. jr,M.Sc. 2642 BDAY:--0203 2643 ANNIVERSARY:20090808T1430-0500 2644 GENDER:M 2645 LANG;PREF=1:fr 2646 LANG;PREF=2:en 2647 ORG;TYPE=work:Viagenie 2648 ADR;TYPE=work:;Suite D2-630;2875 Laurier; 2649 Quebec;QC;G1V 2M2;Canada 2650 TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102 2651 TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501 2652 EMAIL;TYPE=work:simon.perreault@viagenie.ca 2653 GEO;TYPE=work:geo:46.772673,-71.282945 2654 KEY;TYPE=work;VALUE=uri: 2655 http://www.viagenie.ca/simon.perreault/simon.asc 2656 TZ:-0500 2657 URL;TYPE=home:http://nomis80.org 2658 END:VCARD 2660 9. Security Considerations 2662 o Internet mail is often used to transport vCards and is subject to 2663 many well known security attacks, including monitoring, replay, 2664 and forgery. Care should be taken by any directory service in 2665 allowing information to leave the scope of the service itself, 2666 where any access controls or confidentiality can no longer be 2667 guaranteed. Applications should also take care to display 2668 directory data in a "safe" environment 2670 o vCards can carry cryptographic keys or certificates, as described 2671 in Section 6.8.1. 2673 o vCards often carry information that can be sensitive (e.g. 2674 birthday, address, and phone information). Although vCards have 2675 no inherent authentication or confidentiality provisions, they can 2676 easily be carried by any security mechanism that transfers MIME 2677 objects to address authentication or confidentiality (e.g. S/MIME 2678 [RFC5751], OpenPGP [RFC4880]). In cases where the confidentiality 2679 or authenticity of information contained in vCard is a concern, 2680 the vCard SHOULD be transported using one of these secure 2681 mechanisms. The KEY property (Section 6.8.1) can be used to 2682 transport the public key used by these mechanisms. 2684 o The information in a vCard may become out of date. In cases where 2685 the vitality of data is important to an originator of a vCard, the 2686 SOURCE property (Section 6.1.3) SHOULD be specified. In addition, 2687 the "REV" type described in section Section 6.7.4 can be specified 2688 to indicate the last time that the vCard data was updated. 2690 o Many vCard properties may be used to transport URIs. Please refer 2691 to [RFC3986] section 7 for considerations related to URIs. 2693 10. IANA Considerations 2695 10.1. Media Type Registration 2697 IANA is asked to register the following Media Type (in 2698 ), and to mark the 2699 text/directory Media Type as DEPRECATED. 2701 To: ietf-types@iana.org 2703 Subject: Registration of media type text/vcard 2705 Type name: text 2707 Subtype name: vcard 2709 Required parameters: none 2711 Optional parameters: version 2713 The "version" parameter is to be interpreted identically as the 2714 VERSION vCard property. If this parameter is present, all vCards 2715 in a text/vcard body part MUST have a VERSION property with value 2716 identical to that of this MIME parameter. 2718 "charset": as defined for text/plain [RFC2046]; encodings other 2719 than UTF-8 [RFC3629] MUST NOT be used. 2721 Encoding considerations: 8bit 2723 Security considerations: See Section 9. 2725 Interoperability considerations: The text/vcard media type is 2726 intended to identify vCard data of any version. There are older 2727 specifications of vCard [RFC2426][vCard21] still in common use. 2728 While these formats are similar, they are not strictly compatible. 2729 In general, it is necessary to inspect the value of the VERSION 2730 property (see Section 6.7.9) for identifying the standard to which 2731 a given vCard object conforms. 2733 In addition, the following media types are known to have been used 2734 to refer to vCard data. They should be considered deprecated in 2735 favor of text/vcard. 2737 * text/directory 2739 * text/directory; profile=vcard 2741 * text/x-vcard 2743 Published specification: draft-ietf-vcarddav-vcardrev-22 2745 Applications that use this media type: They are numerous, diverse, 2746 and include mail user agents, instant messaging clients, address 2747 book applications, directory servers, customer relationship 2748 management software. 2750 Additional information: 2752 Magic number(s): 2754 File extension(s): .vcf .vcard 2756 Macintosh file type code(s): 2758 Person & email address to contact for further information: vCard 2759 discussion mailing list 2761 Intended usage: COMMON 2763 Restrictions on usage: none 2765 Author: Simon Perreault 2767 Change controller: IETF 2769 10.2. Registering New vCard Elements 2771 This section defines the process for registering new or modified 2772 vCard elements (i.e. properties, parameters, value data types, and 2773 values) with IANA. It does not contain any immediate IANA actions. 2775 10.2.1. Registration Procedure 2777 The IETF will create a mailing list, vcarddav@ietf.org [1], which can 2778 be used for public discussion of vCard element proposals prior to 2779 registration. Use of the mailing list is strongly encouraged. The 2780 IESG will appoint a designated expert who will monitor the 2781 vcarddav@ietf.org [1] mailing list and review registrations. 2783 Registration of new vCard elements MUST be reviewed by the designated 2784 expert and published in an RFC. A Standard Track RFC is REQUIRED for 2785 the registration of new value data types that modify existing 2786 properties. A Standard Track RFC is also REQUIRED for registration 2787 of vCard elements that modify vCard elements previously documented in 2788 a Standard Track RFC. 2790 The registration procedure begins when a completed registration 2791 template, defined in the sections below, is sent to 2792 vcarddav@ietf.org [1] and iana@iana.org [2]. The designated expert 2793 is expected to tell IANA and the submitter of the registration within 2794 two weeks whether the registration is approved, approved with minor 2795 changes, or rejected with cause. When a registration is rejected 2796 with cause, it can be re-submitted if the concerns listed in the 2797 cause are addressed. Decisions made by the designated expert can be 2798 appealed to the IESG Applications Area Director, then to the IESG. 2799 They follow the normal appeals procedure for IESG decisions. 2801 Once the registration procedure concludes successfully, IANA creates 2802 or modifies the corresponding record in the vCard registry. The 2803 completed registration template is discarded. 2805 An RFC specifying new vCard elements MUST include the completed 2806 registration templates, which MAY be expanded with additional 2807 information. These completed templates are intended to go in the 2808 body of the document, not in the IANA Considerations section. 2810 Finally, note that there is an XML representation for vCard defined 2811 in [I-D.ietf-vcarddav-vcardxml]. An XML representation SHOULD be 2812 defined for new vCard elements. 2814 10.2.2. Vendor Namespace 2816 The vendor namespace is used for vCard elements associated with 2817 commercially available products. "Vendor" or "producer" are 2818 construed as equivalent and very broadly in this context. 2820 A registration may be placed in the vendor namespace by anyone who 2821 needs to interchange files associated with the particular product. 2822 However, the registration formally belongs to the vendor or 2823 organization handling the vCard elements in the namespace being 2824 registered. Changes to the specification will be made at their 2825 request, as discussed in subsequent sections. 2827 vCard elements belonging to the vendor namespace will be 2828 distinguished by the "VND-" prefix. This is followed by an IANA- 2829 registered Private Enterprise Number (PEN), a dash, and a vCard 2830 element designation of the vendor's choosing (e.g., "VND-123456- 2831 MUDPIE"). 2833 While public exposure and review of vCard elements to be registered 2834 in the vendor namespace is not required, using the 2835 vcarddav@ietf.org [1] mailing list for review is strongly encouraged 2836 to improve the quality of those specifications. Registrations in the 2837 vendor namespace may be submitted directly to the IANA. 2839 10.2.3. Registration Template for Properties 2841 A property is defined by completing the following template. 2843 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2844 specific property (where NNNN is replaced by the vendor's PEN). 2846 Property name: The name of the property. 2848 Purpose: The purpose of the property. Give a short but clear 2849 description. 2851 Value type: Any of the valid value types for the property value 2852 needs to be specified. The default value type also needs to be 2853 specified. 2855 Cardinality: See Section 6. 2857 Property parameters: Any of the valid property parameters for the 2858 property MUST be specified. 2860 Description: Any special notes about the property, how it is to be 2861 used, etc. 2863 Format definition: The ABNF for the property definition needs to be 2864 specified. 2866 Example(s): One or more examples of instances of the property needs 2867 to be specified. 2869 10.2.4. Registration Template for Parameters 2871 A parameter is defined by completing the following template. 2873 Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- 2874 specific property (where NNNN is replaced by the vendor's PEN). 2876 Parameter name: The name of the parameter. 2878 Purpose: The purpose of the parameter. Give a short but clear 2879 description. 2881 Description: Any special notes about the parameter, how it is to be 2882 used, etc. 2884 Format definition: The ABNF for the parameter definition needs to be 2885 specified. 2887 Example(s): One or more examples of instances of the parameter needs 2888 to be specified. 2890 10.2.5. Registration Template for Value Data Types 2892 A value data type is defined by completing the following template. 2894 Value name: The name of the value type. 2896 Purpose: The purpose of the value type. Give a short but clear 2897 description. 2899 Description: Any special notes about the value type, how it is to be 2900 used, etc. 2902 Format definition: The ABNF for the value type definition needs to 2903 be specified. 2905 Example(s): One or more examples of instances of the value type 2906 needs to be specified. 2908 10.2.6. Registration Template for Values 2910 A value is defined by completing the following template. 2912 Value: The value literal. 2914 Purpose: The purpose of the value. Give a short but clear 2915 description. 2917 Conformance: The vCard properties and/or parameters that can take 2918 this value needs to be specified. 2920 Example(s): One or more examples of instances of the value needs to 2921 be specified. 2923 The following is a fictitious example of a registration of a vCard 2924 value: 2926 Value: supervisor 2928 Purpose: It means that the related entity is the direct hierarchical 2929 superior (i.e. supervisor or manager) of the entity this vCard 2930 represents. 2932 Conformance: This value can be used with the "TYPE" parameter 2933 applied on the "RELATED" property. 2935 Example(s): 2937 RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 2939 10.3. Initial vCard Elements Registries 2941 The IANA is requested to create and maintain the following registries 2942 for vCard elements with pointers to appropriate reference documents. 2943 The registries will be grouped together under the heading "vCard 2944 Elements". 2946 10.3.1. Properties Registry 2948 The following table is to be used to initialize the properties 2949 registry. 2951 +-----------+--------------+------------------------+ 2952 | Namespace | Property | Reference | 2953 +-----------+--------------+------------------------+ 2954 | | SOURCE | RFCXXXX, Section 6.1.3 | 2955 | | KIND | RFCXXXX, Section 6.1.4 | 2956 | | XML | RFCXXXX, Section 6.1.5 | 2957 | | FN | RFCXXXX, Section 6.2.1 | 2958 | | N | RFCXXXX, Section 6.2.2 | 2959 | | NICKNAME | RFCXXXX, Section 6.2.3 | 2960 | | PHOTO | RFCXXXX, Section 6.2.4 | 2961 | | BDAY | RFCXXXX, Section 6.2.5 | 2962 | | ANNIVERSARY | RFCXXXX, Section 6.2.6 | 2963 | | GENDER | RFCXXXX, Section 6.2.7 | 2964 | | ADR | RFCXXXX, Section 6.3.1 | 2965 | | TEL | RFCXXXX, Section 6.4.1 | 2966 | | EMAIL | RFCXXXX, Section 6.4.2 | 2967 | | IMPP | RFCXXXX, Section 6.4.3 | 2968 | | LANG | RFCXXXX, Section 6.4.4 | 2969 | | TZ | RFCXXXX, Section 6.5.1 | 2970 | | GEO | RFCXXXX, Section 6.5.2 | 2971 | | TITLE | RFCXXXX, Section 6.6.1 | 2972 | | ROLE | RFCXXXX, Section 6.6.2 | 2973 | | LOGO | RFCXXXX, Section 6.6.3 | 2974 | | ORG | RFCXXXX, Section 6.6.4 | 2975 | | MEMBER | RFCXXXX, Section 6.6.5 | 2976 | | RELATED | RFCXXXX, Section 6.6.6 | 2977 | | CATEGORIES | RFCXXXX, Section 6.7.1 | 2978 | | NOTE | RFCXXXX, Section 6.7.2 | 2979 | | PRODID | RFCXXXX, Section 6.7.3 | 2980 | | REV | RFCXXXX, Section 6.7.4 | 2981 | | SOUND | RFCXXXX, Section 6.7.5 | 2982 | | UID | RFCXXXX, Section 6.7.6 | 2983 | | CLIENTPIDMAP | RFCXXXX, Section 6.7.7 | 2984 | | URL | RFCXXXX, Section 6.7.8 | 2985 | | VERSION | RFCXXXX, Section 6.7.9 | 2986 | | KEY | RFCXXXX, Section 6.8.1 | 2987 | | FBURL | RFCXXXX, Section 6.9.1 | 2988 | | CALADRURI | RFCXXXX, Section 6.9.2 | 2989 | | CALURI | RFCXXXX, Section 6.9.3 | 2990 +-----------+--------------+------------------------+ 2992 10.3.2. Parameters Registry 2994 The following table is to be used to initialize the parameters 2995 registry. 2997 +-----------+-----------+-----------------------+ 2998 | Namespace | Parameter | Reference | 2999 +-----------+-----------+-----------------------+ 3000 | | LANGUAGE | RFCXXXX, Section 5.1 | 3001 | | VALUE | RFCXXXX, Section 5.2 | 3002 | | PREF | RFCXXXX, Section 5.3 | 3003 | | ALTID | RFCXXXX, Section 5.4 | 3004 | | PID | RFCXXXX, Section 5.5 | 3005 | | TYPE | RFCXXXX, Section 5.6 | 3006 | | MEDIATYPE | RFCXXXX, Section 5.7 | 3007 | | CALSCALE | RFCXXXX, Section 5.8 | 3008 | | SORT-AS | RFCXXXX, Section 5.9 | 3009 | | GEO | RFCXXXX, Section 5.10 | 3010 | | TZ | RFCXXXX, Section 5.11 | 3011 +-----------+-----------+-----------------------+ 3013 10.3.3. Value Data Types Registry 3015 The following table is to be used to initialize the parameters 3016 registry. 3018 +------------------+------------------------+ 3019 | Value Data Type | Reference | 3020 +------------------+------------------------+ 3021 | BOOLEAN | RFCXXXX, Section 4.4 | 3022 | DATE | RFCXXXX, Section 4.3.1 | 3023 | TIME | RFCXXXX, Section 4.3.2 | 3024 | DATE-TIME | RFCXXXX, Section 4.3.3 | 3025 | DATE-AND-OR-TIME | RFCXXXX, Section 4.3.4 | 3026 | TIMESTAMP | RFCXXXX, Section 4.3.5 | 3027 | FLOAT | RFCXXXX, Section 4.6 | 3028 | INTEGER | RFCXXXX, Section 4.5 | 3029 | TEXT | RFCXXXX, Section 4.1 | 3030 | URI | RFCXXXX, Section 4.2 | 3031 | UTC-OFFSET | RFCXXXX, Section 4.7 | 3032 | LANGUAGE-TAG | RFCXXXX, Section 4.8 | 3033 +------------------+------------------------+ 3035 10.3.4. Values Registries 3037 Separate tables will be used for property and parameter values. 3039 The following table is to be used to initialize the property values 3040 registry. 3042 +----------+------------+------------------------+ 3043 | Property | Value | Reference | 3044 +----------+------------+------------------------+ 3045 | BEGIN | VCARD | RFCXXXX, Section 6.1.1 | 3046 | END | VCARD | RFCXXXX, Section 6.1.2 | 3047 | KIND | individual | RFCXXXX, Section 6.1.4 | 3048 | KIND | group | RFCXXXX, Section 6.1.4 | 3049 | KIND | org | RFCXXXX, Section 6.1.4 | 3050 | KIND | location | RFCXXXX, Section 6.1.4 | 3051 +----------+------------+------------------------+ 3053 The following table is to be used to initialize the parameter values 3054 registry. 3056 +------------------------+-----------+--------------+---------------+ 3057 | Property | Parameter | Value | Reference | 3058 +------------------------+-----------+--------------+---------------+ 3059 | FN, NICKNAME, PHOTO, | TYPE | work | RFCXXXX, | 3060 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | 3061 | LANG, TZ, GEO, TITLE, | | | | 3062 | ROLE, LOGO, ORG, | | | | 3063 | RELATED, CATEGORIES, | | | | 3064 | NOTE, SOUND, URL, KEY, | | | | 3065 | FBURL, CALADRURI, and | | | | 3066 | CALURI | | | | 3067 | FN, NICKNAME, PHOTO, | TYPE | home | RFCXXXX, | 3068 | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | 3069 | LANG, TZ, GEO, TITLE, | | | | 3070 | ROLE, LOGO, ORG, | | | | 3071 | RELATED, CATEGORIES, | | | | 3072 | NOTE, SOUND, URL, KEY, | | | | 3073 | FBURL, CALADRURI, and | | | | 3074 | CALURI | | | | 3075 | TEL | TYPE | text | RFCXXXX, | 3076 | | | | Section 6.4.1 | 3077 | TEL | TYPE | voice | RFCXXXX, | 3078 | | | | Section 6.4.1 | 3079 | TEL | TYPE | fax | RFCXXXX, | 3080 | | | | Section 6.4.1 | 3081 | TEL | TYPE | cell | RFCXXXX, | 3082 | | | | Section 6.4.1 | 3083 | TEL | TYPE | video | RFCXXXX, | 3084 | | | | Section 6.4.1 | 3085 | TEL | TYPE | pager | RFCXXXX, | 3086 | | | | Section 6.4.1 | 3087 | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFCXXXX, | 3088 | | | | Section 6.2.5 | 3089 | RELATED | TYPE | contact | RFCXXXX, | 3090 | | | | Section 6.6.6 | 3091 | | | | and [xfn] | 3092 | RELATED | TYPE | acquaintance | RFCXXXX, | 3093 | | | | Section 6.6.6 | 3094 | | | | and [xfn] | 3095 | RELATED | TYPE | friend | RFCXXXX, | 3096 | | | | Section 6.6.6 | 3097 | | | | and [xfn] | 3098 | RELATED | TYPE | met | RFCXXXX, | 3099 | | | | Section 6.6.6 | 3100 | | | | and [xfn] | 3101 | RELATED | TYPE | co-worker | RFCXXXX, | 3102 | | | | Section 6.6.6 | 3103 | | | | and [xfn] | 3104 | RELATED | TYPE | colleague | RFCXXXX, | 3105 | | | | Section 6.6.6 | 3106 | | | | and [xfn] | 3107 | RELATED | TYPE | co-resident | RFCXXXX, | 3108 | | | | Section 6.6.6 | 3109 | | | | and [xfn] | 3110 | RELATED | TYPE | neighbor | RFCXXXX, | 3111 | | | | Section 6.6.6 | 3112 | | | | and [xfn] | 3113 | RELATED | TYPE | child | RFCXXXX, | 3114 | | | | Section 6.6.6 | 3115 | | | | and [xfn] | 3116 | RELATED | TYPE | parent | RFCXXXX, | 3117 | | | | Section 6.6.6 | 3118 | | | | and [xfn] | 3119 | RELATED | TYPE | sibling | RFCXXXX, | 3120 | | | | Section 6.6.6 | 3121 | | | | and [xfn] | 3122 | RELATED | TYPE | spouse | RFCXXXX, | 3123 | | | | Section 6.6.6 | 3124 | | | | and [xfn] | 3125 | RELATED | TYPE | kin | RFCXXXX, | 3126 | | | | Section 6.6.6 | 3127 | | | | and [xfn] | 3128 | RELATED | TYPE | muse | RFCXXXX, | 3129 | | | | Section 6.6.6 | 3130 | | | | and [xfn] | 3131 | RELATED | TYPE | crush | RFCXXXX, | 3132 | | | | Section 6.6.6 | 3133 | | | | and [xfn] | 3134 | RELATED | TYPE | date | RFCXXXX, | 3135 | | | | Section 6.6.6 | 3136 | | | | and [xfn] | 3137 | RELATED | TYPE | sweetheart | RFCXXXX, | 3138 | | | | Section 6.6.6 | 3139 | | | | and [xfn] | 3140 | RELATED | TYPE | me | RFCXXXX, | 3141 | | | | Section 6.6.6 | 3142 | | | | and [xfn] | 3143 | RELATED | TYPE | agent | RFCXXXX, | 3144 | | | | Section 6.6.6 | 3145 | RELATED | TYPE | emergency | RFCXXXX, | 3146 | | | | Section 6.6.6 | 3147 +------------------------+-----------+--------------+---------------+ 3149 11. Acknowledgements 3151 The authors would like to thank Tim Howes, Mark Smith, and Frank 3152 Dawson, the original authors of [RFC2425] and [RFC2426], Pete 3153 Resnick, who got this effort started and provided help along the way, 3154 as well as the following individuals who have participated in the 3155 drafting, review and discussion of this memo: 3157 Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil 3158 Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie 3159 Hoeneisen, Bjoern Hoehrmann, Caleb Richarson, Chris Bryant, Chris 3160 Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale, 3161 Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian 3162 Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens, 3163 Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke, 3164 Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga. Lisa Dusseault, 3165 Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike 3166 Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter 3167 Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane 3168 Bortzmeyer, Tantek Celik, and Zoltan Ordogh. 3170 12. References 3172 12.1. Normative References 3174 [CCITT.E163.1988] International Telephone and 3175 Telegraph Consultative Committee, 3176 "Numbering Plan for the 3177 International Telephone Service", 3178 CCITT Recommendation E.163, 1988. 3180 [CCITT.X121.1988] International Telephone and 3181 Telegraph Consultative Committee, 3182 "International Numbering Plan for 3183 the Public Data Networks", 3184 CCITT Recommendation X.121, 1988. 3186 [CCITT.X520.1988] International International 3187 Telephone and Telegraph 3188 Consultative Committee, 3189 "Information Technology - Open 3190 Systems Interconnection - The 3191 Directory: Selected Attribute 3192 Types", CCITT Recommendation 3193 X.520, November 1988. 3195 [CCITT.X521.1988] International International 3196 Telephone and Telegraph 3197 Consultative Committee, 3198 "Information Technology - Open 3199 Systems Interconnection - The 3200 Directory: Selected Object 3201 Classes", CCITT Recommendation 3202 X.521, November 1988. 3204 [I-D.ietf-vcarddav-vcardxml] Perreault, S., "vCard XML 3205 Representation", 3206 draft-ietf-vcarddav-vcardxml-08 3207 (work in progress), April 2011. 3209 [IEEE.754.2008] Institute of Electrical and 3210 Electronics Engineers, "IEEE 3211 Standard for Floating-Point 3212 Arithmetic", IEEE Standard 754, 3213 August 2008. 3215 [ISO.8601.2000] International Organization for 3216 Standardization, "Data elements 3217 and interchange formats - 3218 Information interchange - 3219 Representation of dates and 3220 times", ISO Standard 8601, 3221 December 2000. 3223 [ISO.8601.2004] International Organization for 3224 Standardization, "Data elements 3225 and interchange formats - 3226 Information interchange - 3227 Representation of dates and 3228 times", ISO Standard 8601, 3229 December 2004. 3231 [RFC2045] Freed, N. and N. Borenstein, 3232 "Multipurpose Internet Mail 3233 Extensions (MIME) Part One: Format 3234 of Internet Message Bodies", 3235 RFC 2045, November 1996. 3237 [RFC2046] Freed, N. and N. Borenstein, 3238 "Multipurpose Internet Mail 3239 Extensions (MIME) Part Two: Media 3240 Types", RFC 2046, November 1996. 3242 [RFC2119] Bradner, S., "Key words for use in 3243 RFCs to Indicate Requirement 3244 Levels", BCP 14, RFC 2119, 3245 March 1997. 3247 [RFC2739] Small, T., Hennessy, D., and F. 3248 Dawson, "Calendar Attributes for 3249 vCard and LDAP", RFC 2739, 3250 January 2000. 3252 [RFC3629] Yergeau, F., "UTF-8, a 3253 transformation format of ISO 3254 10646", STD 63, RFC 3629, 3255 November 2003. 3257 [RFC3966] Schulzrinne, H., "The tel URI for 3258 Telephone Numbers", RFC 3966, 3259 December 2004. 3261 [RFC3986] Berners-Lee, T., Fielding, R., and 3262 L. Masinter, "Uniform Resource 3263 Identifier (URI): Generic Syntax", 3264 STD 66, RFC 3986, January 2005. 3266 [RFC4122] Leach, P., Mealling, M., and R. 3267 Salz, "A Universally Unique 3268 IDentifier (UUID) URN Namespace", 3269 RFC 4122, July 2005. 3271 [RFC4288] Freed, N. and J. Klensin, "Media 3272 Type Specifications and 3273 Registration Procedures", BCP 13, 3274 RFC 4288, December 2005. 3276 [RFC5234] Crocker, D. and P. Overell, 3277 "Augmented BNF for Syntax 3278 Specifications: ABNF", STD 68, 3279 RFC 5234, January 2008. 3281 [RFC5322] Resnick, P., Ed., "Internet 3282 Message Format", RFC 5322, 3283 October 2008. 3285 [RFC5545] Desruisseaux, B., "Internet 3286 Calendaring and Scheduling Core 3287 Object Specification (iCalendar)", 3288 RFC 5545, September 2009. 3290 [RFC5546] Daboo, C., "iCalendar Transport- 3291 Independent Interoperability 3292 Protocol (iTIP)", RFC 5546, 3293 December 2009. 3295 [RFC5646] Phillips, A. and M. Davis, "Tags 3296 for Identifying Languages", 3297 BCP 47, RFC 5646, September 2009. 3299 [RFC5870] Mayrhofer, A. and C. Spanring, "A 3300 Uniform Resource Identifier for 3301 Geographic Locations ('geo' URI)", 3302 RFC 5870, June 2010. 3304 [W3C.REC-xml-20081126] Paoli, J., Yergeau, F., Bray, T., 3305 Maler, E., and C. Sperberg- 3306 McQueen, "Extensible Markup 3307 Language (XML) 1.0 (Fifth 3308 Edition)", World Wide Web 3309 Consortium Recommendation REC-xml- 3310 20081126, November 2008, . 3314 [xfn] Celik, T., Mullenweg, M., and E. 3315 Meyer, "XHTML Friends Network 3316 1.1", . 3318 12.2. Informative References 3320 [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, 3321 "Internationalized Email Headers", 3322 draft-ietf-eai-rfc5335bis-10 (work 3323 in progress), March 2011. 3325 [I-D.lear-iana-timezone-database] Lear, E. and P. Eggert, "IANA 3326 Procedures for Maintaining the 3327 Timezone Database", draft-lear- 3328 iana-timezone-database-04 (work in 3329 progress), May 2011. 3331 [ISO9070] The International Organization for 3332 Standardization, "ISO 9070, 3333 Information Processing - SGML 3334 support facilities - Registration 3335 Procedures for Public Text Owner 3336 Identifiers", April 1991. 3338 [RFC1738] Berners-Lee, T., Masinter, L., and 3339 M. McCahill, "Uniform Resource 3340 Locators (URL)", RFC 1738, 3341 December 1994. 3343 [RFC2397] Masinter, L., "The "data" URL 3344 scheme", RFC 2397, August 1998. 3346 [RFC2425] Howes, T., Smith, M., and F. 3347 Dawson, "A MIME Content-Type for 3348 Directory Information", RFC 2425, 3349 September 1998. 3351 [RFC2426] Dawson, F. and T. Howes, "vCard 3352 MIME Directory Profile", RFC 2426, 3353 September 1998. 3355 [RFC2616] Fielding, R., Gettys, J., Mogul, 3356 J., Frystyk, H., Masinter, L., 3357 Leach, P., and T. Berners-Lee, 3358 "Hypertext Transfer Protocol -- 3359 HTTP/1.1", RFC 2616, June 1999. 3361 [RFC3282] Alvestrand, H., "Content Language 3362 Headers", RFC 3282, May 2002. 3364 [RFC3406] Daigle, L., van Gulik, D., 3365 Iannella, R., and P. Faltstrom, 3366 "Uniform Resource Names (URN) 3367 Namespace Definition Mechanisms", 3368 BCP 66, RFC 3406, October 2002. 3370 [RFC3536] Hoffman, P., "Terminology Used in 3371 Internationalization in the IETF", 3372 RFC 3536, May 2003. 3374 [RFC4770] Jennings, C. and J. Reschke, Ed., 3375 "vCard Extensions for Instant 3376 Messaging (IM)", RFC 4770, 3377 January 2007. 3379 [RFC4880] Callas, J., Donnerhacke, L., 3380 Finney, H., Shaw, D., and R. 3381 Thayer, "OpenPGP Message Format", 3382 RFC 4880, November 2007. 3384 [RFC5751] Ramsdell, B. and S. Turner, 3385 "Secure/Multipurpose Internet Mail 3386 Extensions (S/MIME) Version 3.2 3387 Message Specification", RFC 5751, 3388 January 2010. 3390 [RFC6068] Duerst, M., Masinter, L., and J. 3391 Zawinski, "The 'mailto' URI 3392 Scheme", RFC 6068, October 2010. 3394 [TZ-DB] Olson, A., "Time zone code and 3395 data", 3396 . 3398 [vCard21] Internet Mail Consortium, "vCard - 3399 The Electronic Business Card 3400 Version 2.1", September September. 3402 URIs 3404 [1] 3406 [2] 3408 Appendix A. Differences from RFCs 2425 and 2426 3410 This appendix contains a high-level overview of the major changes 3411 that have been made in the vCard specification from RFCs 2425 and 3412 2426. It is incomplete as it only lists the most important changes. 3414 A.1. New Structure 3416 o [RFC2425] and [RFC2426] have been merged. 3418 o vCard is now not only a MIME type but a stand-alone format. 3420 o A proper MIME type registration form has been included. 3422 o UTF-8 is now the only possible character set. 3424 o New vCard elements can be registered from IANA. 3426 A.2. Removed Features 3428 o The CONTEXT and CHARSET parameters are no more. 3430 o The NAME, MAILER, LABEL, and CLASS properties are no more. 3432 o The "intl", "dom", "postal", and "parcel" TYPE parameter values 3433 for the ADR property have been removed. 3435 o Inline vCards (such as the value of the AGENT property) are no 3436 longer supported. 3438 A.3. New Properties and Parameters 3440 o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP 3441 properties have been added. 3443 o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI 3444 properties, has been merged in. 3446 o [RFC4770], which defines the IMPP property, has been merged in. 3448 o The "work" and "home" TYPE parameter values are now applicable to 3449 many more properties. 3451 o The "pref" value of the TYPE parameter is now a parameter of its 3452 own, with a positive integer value indicating the level of 3453 preference. 3455 o The ALTID and PID parameters have been added. 3457 o The MEDIATYPE parameter has been added and replaces the TYPE 3458 parameter when it was used for indicating the media type of the 3459 property's content. 3461 A.4. Other Changes 3463 o Synchronization is addressed in Section 7. 3465 o The N property is no longer mandatory. 3467 o In the N property, each component may now contain multiple comma- 3468 separated values. 3470 o The value of TEL is now a URI. 3472 o The AGENT property was replaced with a type of RELATED. 3474 o Date and time values now only support the basic format. 3475 Truncation is now supported. 3477 Appendix B. Change Log (to be removed by RFC Editor prior to 3478 publication) 3480 B.1. Changes in -22 3482 o Made reference to RFC3536 informative instead of normative. 3484 o Adjusted ABNF for readability (no normative changes). 3486 o Added informative reference to draft-lear-iana-timezone-database. 3488 o Tweaked Appendix A a little bit. 3490 o s/privacy/confidentiality/ 3492 o Changed all references to ASCII characters into Unicode code 3493 points. 3495 o Added pointer to URI security considerations. 3497 o Adjusted GENDER examples. 3499 o Clearly ask IANA to mark text/directory as DEPRECATED. 3501 o Adjusted updating/obsoleting text in abstract. 3503 B.2. Changes in -21 3505 o Minor ABNF clarification. 3507 B.3. Changes in -20 3509 o Reworded security considerations. 3511 o Specified range of integer and float value types. 3513 o Adjusted IANA considerations wording. 3515 o Added missing date-and-or-type to the VALUE ABNF. 3517 o s/vcard@ietf.org/vcarddav@ietf.org/ 3519 o More precise wording: charset instead of character set 3520 o Make parameter values case-insensitive by default. 3522 o Escaping newlines can be done with \n or \N. 3524 o Make SORT-AS value case-sensitive. 3526 o Better formatting for ADR special notes. 3528 o Removed Pete Resnick's example vCard. 3530 o vcarddav@ietf.org is the contact person for the media type. 3532 o Add missing pref-param, pid-param, and any-param to the PHOTO 3533 property. 3535 o Re-added missing section on UTC-OFFSET value type. 3537 B.4. Changes in -19 3539 o Fixed nits. 3541 o Fixed MEDIATYPE ABNF. 3543 B.5. Changes in -18 3545 o Fix missing text in KIND section. 3547 B.6. Changes in -17 3549 o s/individual/entity/ 3551 o Moved section 3.4 for better flow. 3553 o Removed text overriding general MIME and HTTP rules. 3555 o Fixed redundant ABNF. 3557 o Fixed parameter value quoting in examples. 3559 o Added informative reference for Content-Language header. 3561 o Moved cardinality table earlier for better flow. 3563 o Added normative reference for XML 1.0. 3565 o Added informative reference for mailto: scheme. 3567 o Clarified where the VERSION property must go. 3569 o Created the MEDIATYPE parameter. 3571 o Fixed text/vcard encoding considerations. 3573 o Added .vcard file extension. 3575 o Removed need for extension documents to contain tables in their 3576 IANA Considerations section. 3578 o Removed underspecified "Status" column in IANA registry. 3580 o Moved obsoleted references to Informative section. 3582 o Moved iCalendar references to Normative section. 3584 o Expanded specification of KIND values. 3586 o Recommend defining an XML representation for new vCard elements. 3588 B.7. Changes in -16 3590 o RELATED: Added XFN values into IANA registry. 3592 o RELATED: Added values "agent" and "emergency". 3594 o EMAIL is now free-form text, with informative reference to EAI. 3596 o GENDER now has two components: one for biological sex, the other 3597 for gender identity. 3599 o Bugfixes to the core ABNF. 3601 o Clarified IANA considerations. 3603 o UID may be reset to free-form text. 3605 B.8. Changes in -15 3607 o Reverted N to the 5-component format of vCard 3. 3609 o Removed DDAY, BIRTH, and DEATH. 3611 o First two components in ADR SHOULD be empty. 3613 o Removed the LABEL property. 3615 o Removed the binary value type and the ENCODING and FMTTYPE 3616 parameters. 3618 o Renamed SEX to GENDER. Set predefined values to "male" and 3619 "female". 3621 o Reverted TEL to take a text value by default, but SHOULD be reset 3622 to a URI. 3624 o Refer to iCalendar for CALSCALE. 3626 o Removed the "thing" value for KIND. 3628 o RELATED now uses XFN 1.1 for its value. 3630 o Dropped the VERSION parameter. XML MUST be version 1.0. 3632 o Dropped the CLASS property. 3634 o Property and parameter names SHOULD be upper-case. 3636 o Use ABNF for cardinality notation. 3638 B.9. Changes in -14 3640 o DQUOTE is US-ASCII decimal 34, not 22. 3642 o Removed unused reference to RFC 2046. 3644 o Updated reference to draft-ietf-vcarddav-vcardxml. 3646 o Small fixes to the IANA registration text. 3648 o Added notes on the usage of TEL and IMPP properties. 3650 o Clarified "country name" component of ADR property. 3652 o Removed usage of undefined type value "msg" in TEL example. 3654 o Fixed parameter value quoting rules and ABNF. 3656 o Added example to LANGUAGE property. 3658 o Fixed synchronization example regarding the cardinality of FN. 3660 o Added implementation note for float value type. 3662 o Removed advice for always including VALUE parameter. 3664 o FMTTYPE MUST include the full MIME type. 3666 o Made ADR's ABNF more verbose. 3668 o Organized TEL TYPE values in a table. 3670 o Replaced TOP-SECRET example with NOINDEX. 3672 B.10. Changes in -13 3674 o Changed global ABNF to make explicit that VERSION comes first. 3676 o Reworked example for LANGUAGE property. 3678 o s/TYPE/FMTTYPE/ in two examples. 3680 o Allow LANGUAGE parameter for text-valued BDAY, DDAY, and RELATED. 3682 o Tightened language on LANGUAGE parameter regarding cardinality. 3684 o Removed the NAME property. 3686 o Adjusted semi-colon escaping rules. 3688 o Added the ALTID parameter. 3690 B.11. Changes in -12 3692 o Fixed example of LANGUAGE cardinality. 3694 o Added note about YYYY-MM date format. 3696 o Fixed appendix A. 3698 o VERSION property must come first. 3700 o Fixed mistake in PID example. 3702 o Removed two changes from Appendix A which were probably intended 3703 to go into this change log section. 3705 o Explicitly state that the value for the BEGIN and END properties 3706 is case-insensitive. 3708 o Removed the SORT-STRING property. Created the SORT-AS parameter. 3710 o "T" and "Z" in dates and times are now mandatory uppercase. 3712 o Added the "version" MIME parameter. 3714 o More consistent capitalization. 3716 o Added missing "ANNIVERSARY" in name production rule. 3718 o Added missing calscale-param in param production rule. 3720 o Moved definition of GEO and TZ parameters to section 5. 3722 o Simplified discussion of encoding. 3724 o Removed restriction for "work" and "home" values of TYPE parameter 3725 w.r.t. the KIND property. 3727 o XML value may now be binary. 3729 o Created VERSION parameter for XML. 3731 o BIRTH and DEATH can now have URI values. 3733 o Created the FMTTYPE parameter. 3735 o KEY can now take a text value. 3737 o Added references to RFC 5545 (iCalendar). 3739 o Added namespace column in parameters registry. 3741 B.12. Changes in -11 3743 o Change "XML chunk" to "XML fragment". 3745 o Cite W3C document containing definition of "fragment". 3747 o Added "XML" to property name ABNF. 3749 o Clarified newline escaping rule. 3751 o Replaced one remaining "type" with "property". 3753 o Removed case insensitivity of parameter values. 3755 o XML property can now only contain one element that is not in the 3756 vCard 4 namespace. 3758 o Clarified interrelationship between LANGUAGE, cardinality, and 3759 PID. 3761 o Added "textphone" TEL type. 3763 o Fixed quoting of comma in ORG examples. 3765 B.13. Changes in -10 3767 o Added component in SORT-STRING for sorting by given name. Fixed 3768 and expanded the examples. 3770 o Fixed KIND-value ABNF. 3772 o Fixed deprecated media type. 3774 o Created the CALSCALE parameter. 3776 o Strenghtened the stance on character set. 3778 o Defined the Language-Tag ABNF. 3780 o Made explicit the fact that IANA does not register templates. 3782 o Created the XML property. 3784 o Added social networking examples to URL property. 3786 B.14. Changes in -09 3788 o Removed special meaning for groups. Removed the "work" and "home" 3789 groups. Removed the group registry. Re-introduced the "work" and 3790 "home" TYPE parameter values. Applied the TYPE parameter to 3791 properties which supported the "work" and "home" groups. 3793 o Vendor namespace now uses private enterprise number in prefix. 3795 o Added "thing" value for KIND property. 3797 B.15. Changes in -08 3799 o Allow 1985 (year only) in date ABNF. 3801 o Fixed missing country in ADR example. 3803 o Added the DATE-AND-OR-TIME value. 3805 o Made BDAY and DDAY use DATE-AND-OR-TIME. 3807 o Prefixed "param" and "value" production rules specific to 3808 properties with the property name. 3810 o Replaced the GENDER property with the SEX property. 3812 o Added the ANNIVERSARY property. 3814 o Added the "friend" and "spouse" types of RELATED. 3816 o TZ property now has text / uri value. 3818 o Refined the definitions of TITLE and ROLE. 3820 B.16. Changes in -07 3822 o PREF is now bounded. 100 is the maximum value. 3824 o Added the "emergency" RELATED type. 3826 o Made GEO a URI. 3828 o Added GEO and TZ parameters to ADR. 3830 o Changed wording of "default" use of SOUND property. 3832 o Completely reworked the date, time, and date-time grammars. 3834 o Added the timestamp value type. 3836 o REV now has the timestamp value type. 3838 o Rewrote ABNF. 3840 o ORG can now have a single level. 3842 B.17. Changes in -06 3844 o Corrected omission of resetability to text value for RELATED. 3846 o Let KEY value type be reset to a URI value. 3848 o ABNF fixes. 3850 o Made gender values extensible. 3852 o Gave the PREF parameter a positive integer value. 3854 o Removed usage of the undefined "word" ABNF production rule. 3856 o Defined property cardinalities. 3858 o Defined properties allowable in WORK and HOME groups. 3860 o Simplified the LANG property to use the vCard preference 3861 mechanism. 3863 o Created the "language-tag" value type. 3865 o Added PID to ABNF of SOURCE allowed parameters. 3867 o Clarified escaping rules. 3869 o Changed ABNF definition of non-standard X- properties. 3871 o Removed TYPE parameter from EMAIL properties in examples. 3873 o Created the CLIENTPIDMAP property. 3875 o Changed PID value to a pair of small integers. 3877 o Completely reworked synchronization mechanisms. 3879 o Created brand new synchronization example. 3881 B.18. Changes in -05 3883 o Added multi PID value proposal. 3885 B.19. Changes in -04 3887 o Added "location" value for KIND property. 3889 o Some fixes to ABNF. 3891 o Moved "pref" from being a TYPE value to a parameter in its own 3892 right. 3894 o Removed the "work" and "home" TYPE values. 3896 o Reintroduced the group construct. 3898 o Assigned meaning to WORK and HOME groups. 3900 o Restricted the TEL TYPE parameter value set. 3902 o In N property, removed additional names, and replaced with 3903 multiple given names. 3905 o Removed TYPE parameter from EMAIL and IMPP properties. 3907 o Replaced AGENT with a type of RELATED. 3909 o Use example.org domain in URL example. 3911 o Created initial IANA table of values. 3913 o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL. 3915 B.20. Changes in -03 3917 o Various changes to the synchronization mechanisms. 3919 o Allowed truncated format for dated. See issue #236. 3921 B.21. Changes in -02 3923 o Removed useless text in IMPP description. 3925 o Added CalDAV-SCHED example to CALADRURI. 3927 o Removed CAPURI property. 3929 o Dashes in dates and colons in times are now mandatory. 3931 o Allow for dates such as 2008 and 2008-05 and times such as 07 and 3932 07:54. 3934 o Removed inline vCard value. 3936 o Made AGENT only accept URI references instead of inline vCards. 3938 o Added the MEMBER property. 3940 o Renamed the UID parameter to PID. 3942 o Changed the value type of the PID parameter to "a small integer." 3944 o Changed the presence of UID and PID when synchronization is to be 3945 used from MUST to SHOULD. 3947 o Added the RELATED (Section 6.6.6) property. 3949 o Fixed many ABNF typos (issue #252). 3951 o Changed formatting of ABNF comments to make them easier to read 3952 (issue #226). 3954 B.22. Changes in -01 3956 o Merged [RFC2739] in. 3958 o Converted all foobar.com, abc.com, etc. to example.com. 3960 o Fixed bugs in ABNF. 3962 o Made explicit that coordinates in the GEO property are expressed 3963 in the WGS 84 reference system. 3965 o Clarified folding issues with multi-byte characters. 3967 o Made the value of TEL a URI. 3969 o Added the UID parameter. 3971 o Made the UID property's value type a URI. 3973 o Added Section 7. 3975 o Created IANA process for registering new parameters, value types, 3976 and properties. 3978 o Created the initial IANA registries. 3980 o Created vendor namespace based on text from RFC 4288. 3982 B.23. Changes in -00 3984 o Name change because draft has been accepted as WG item. 3985 Otherwise, same as draft-resnick-vcarddav-vcardrev-01. 3987 o Removed reference to RFC 2234. 3989 o Fixed errata from 3990 http://www.rfc-editor.org/errata_search.php?rfc=2426. 3992 o Removed passage referring to RFC 2425 profiles. 3994 o Renamed Section 6.4 from "Telecommunications Adressing Properties" 3995 to "Communications Properties. 3997 o Added Appendix A and Appendix B. 3999 o Added reference to [RFC4770]. 4001 o Removed the group construct. 4003 o Made the N property no longer mandatory. 4005 o Added the KIND property. 4007 o Clarified meaning of TYPE parameter value for PHOTO, LOGO, KEY, 4008 and SOUND. 4010 o Removed the CONTEXT parameter. 4012 o Removed the MAILER property. 4014 o Made reference to [ISO9070] informative. 4016 o Removed "intl", "dom", "postal", and "parcel" TYPE parameter 4017 values for the ADR and LABEL properties. 4019 o Clarified meaning of "extended address" ADR field. 4021 o Mentioned [RFC3406] as another method of generating PRODID values. 4023 o Updated obsolete references. 4025 o Allowed BDAY and DDAY value types to be text values for fuzzy 4026 dates. 4028 o Removed the CHARSET property. Now the encoding is always UTF-8, 4029 except when overridden by the Content-Type (which is considered a 4030 compatibility feature). 4032 Author's Address 4034 Simon Perreault 4035 Viagenie 4036 2875 Laurier, suite D2-630 4037 Quebec, QC G1V 2M2 4038 Canada 4040 Phone: +1 418 656 9254 4041 EMail: simon.perreault@viagenie.ca 4042 URI: http://www.viagenie.ca