draft-ietf-vcarddav-vcardrev-16.txt   draft-ietf-vcarddav-vcardrev-17.txt 
Network Working Group S. Perreault Network Working Group S. Perreault
Internet-Draft Viagenie Internet-Draft Viagenie
Obsoletes: 2425, 2426, 4770 March 10, 2011 Obsoletes: 2425, 2426, 4770 April 6, 2011
(if approved) (if approved)
Updates: 2739 (if approved) Updates: 2739 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 11, 2011 Expires: October 8, 2011
vCard Format Specification vCard Format Specification
draft-ietf-vcarddav-vcardrev-16 draft-ietf-vcarddav-vcardrev-17
Abstract Abstract
This document defines the vCard data format for representing and This document defines the vCard data format for representing and
exchanging a variety of information about individuals and other exchanging a variety of information about individuals and other
entities (e.g., formatted and structured name and delivery addresses, entities (e.g., formatted and structured name and delivery addresses,
email address, multiple telephone numbers, photograph, logo, audio email address, multiple telephone numbers, photograph, logo, audio
clips, etc.). clips, etc.).
Status of This Memo Status of This Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 11, 2011. This Internet-Draft will expire on October 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. vCard Format Specification . . . . . . . . . . . . . . . . . . 6 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 6
3.1. Line Delimiting and Folding . . . . . . . . . . . . . . . 6 3.1. Character Set . . . . . . . . . . . . . . . . . . . . . . 6
3.2. ABNF Format Definition . . . . . . . . . . . . . . . . . . 7 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 6
3.3. Property Value Escaping . . . . . . . . . . . . . . . . . 9 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 7
3.4. Character Set . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9
4. Property Value Data Types . . . . . . . . . . . . . . . . . . 10 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 10
4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 13 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 13
4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 14
4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14
4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 15 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 15
4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16 4.7. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16
5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16
5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.7. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.9. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.10. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23
6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Identification Properties . . . . . . . . . . . . . . . . 27 6.2. Identification Properties . . . . . . . . . . . . . . . . 28
6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 28 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 30
6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 30 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 32
6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 30 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 31 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 33
6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4. Communications Properties . . . . . . . . . . . . . . . . 33 6.4. Communications Properties . . . . . . . . . . . . . . . . 34
6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.5. Geographical Properties . . . . . . . . . . . . . . . . . 36 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 38
6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.6. Organizational Properties . . . . . . . . . . . . . . . . 38 6.6. Organizational Properties . . . . . . . . . . . . . . . . 39
6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 38 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 39
6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 40 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 42
6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 41 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 43
6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 42 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 44
6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 42 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 44
6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 43 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 45
6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 44 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 46
6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 46 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47
6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 47 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 49
6.8. Security Properties . . . . . . . . . . . . . . . . . . . 47 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 49
6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 48 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 50
6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 48 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 50
6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 49 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 51
6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 49 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 51
6.10. Extended Properties and Parameters . . . . . . . . . . . . 50 6.10. Extended Properties and Parameters . . . . . . . . . . . . 52
7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 50 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 50 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 51 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 52
7.1.2. Matching Property Instances . . . . . . . . . . . . . 51 7.1.2. Matching Property Instances . . . . . . . . . . . . . 53
7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 51 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 53
7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 52 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 52 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 54
7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 52 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 54
7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 53 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 55
7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 53 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 55
7.2.5. Global Context Simplification . . . . . . . . . . . . 55 7.2.5. Global Context Simplification . . . . . . . . . . . . 57
8. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 56 8. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 58
9. Security Considerations . . . . . . . . . . . . . . . . . . . 56 9. Security Considerations . . . . . . . . . . . . . . . . . . . 58
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
10.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 57 10.1. MIME Type Registration . . . . . . . . . . . . . . . . . . 59
10.2. Registering New vCard Elements . . . . . . . . . . . . . . 58 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 60
10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 59 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 61
10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 59 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 61
10.2.3. Registration Template for Properties . . . . . . . . . 60 10.2.3. Registration Template for Properties . . . . . . . . . 62
10.2.4. Registration Template for Parameters . . . . . . . . . 61 10.2.4. Registration Template for Parameters . . . . . . . . . 63
10.2.5. Registration Template for Value Data Types . . . . . . 61 10.2.5. Registration Template for Value Data Types . . . . . . 63
10.2.6. Registration Template for Values . . . . . . . . . . . 61 10.2.6. Registration Template for Values . . . . . . . . . . . 63
10.3. Initial vCard Elements Registries . . . . . . . . . . . . 62 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 64
10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 62 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64
10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 63 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 65
10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 64 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 66
10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 64 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
12.1. Normative References . . . . . . . . . . . . . . . . . . . 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
12.2. Informative References . . . . . . . . . . . . . . . . . . 70 12.2. Informative References . . . . . . . . . . . . . . . . . . 72
Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 71 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 73
A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 71 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73
A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 71 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 74
A.3. New Properties and Parameters . . . . . . . . . . . . . . 72 A.3. New Properties and Parameters . . . . . . . . . . . . . . 74
A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 72 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 74
Appendix B. Change Log (to be removed by RFC Editor prior to Appendix B. Change Log (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 72 publication) . . . . . . . . . . . . . . . . . . . . 75
B.1. Changes in -16 . . . . . . . . . . . . . . . . . . . . . . 72 B.1. Changes in -17 . . . . . . . . . . . . . . . . . . . . . . 75
B.2. Changes in -15 . . . . . . . . . . . . . . . . . . . . . . 73 B.2. Changes in -16 . . . . . . . . . . . . . . . . . . . . . . 76
B.3. Changes in -14 . . . . . . . . . . . . . . . . . . . . . . 73 B.3. Changes in -15 . . . . . . . . . . . . . . . . . . . . . . 76
B.4. Changes in -13 . . . . . . . . . . . . . . . . . . . . . . 74 B.4. Changes in -14 . . . . . . . . . . . . . . . . . . . . . . 77
B.5. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 74 B.5. Changes in -13 . . . . . . . . . . . . . . . . . . . . . . 77
B.6. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 76 B.6. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 78
B.7. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 76 B.7. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 79
B.8. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 77 B.8. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 79
B.9. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 77 B.9. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 80
B.10. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 77 B.10. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 80
B.11. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 78 B.11. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 81
B.12. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 79 B.12. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 81
B.13. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 79 B.13. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 82
B.14. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 79 B.14. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 82
B.15. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 79 B.15. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 83
B.16. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 80 B.16. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 83
B.17. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 81 B.17. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 83
B.18. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
Electronic address books have become ubiquitous. Their increased Electronic address books have become ubiquitous. Their increased
presence on portable, connected devices as well as the diversity of presence on portable, connected devices as well as the diversity of
platforms exchanging contact data call for a standard. This memo platforms exchanging contact data call for a standard. This memo
defines the vCard format, which allows the capture and exchange of defines the vCard format, which allows the capture and exchange of
information normally stored within an address book or directory information normally stored within an address book or directory
application. application.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. vCard Format Specification 3. vCard Format Specification
The text/vcard MIME content type (hereafter known as "vCard", see The text/vcard MIME content type (hereafter known as "vCard", see
Section 10.1) contains contact information, typically pertaining to a Section 10.1) contains contact information, typically pertaining to a
single contact or group of contacts. The content consists of one or single contact or group of contacts. The content consists of one or
more lines in the format given below. more lines in the format given below.
3.1. Line Delimiting and Folding 3.1. Character Set
The character set for vCard is UTF-8 as defined in [RFC3629]. There
is no way to override this. It is invalid to specify a different
character set in the "charset" MIME parameter (see Section 10.1).
3.2. Line Delimiting and Folding
Individual lines within vCard are delimited by the [RFC5322] line Individual lines within vCard are delimited by the [RFC5322] line
break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII break, which is a CRLF sequence (ASCII decimal 13, followed by ASCII
decimal 10). Long logical lines of text can be split into a decimal 10). Long logical lines of text can be split into a
multiple-physical-line representation using the following folding multiple-physical-line representation using the following folding
technique. Content lines SHOULD be folded to a maximum width of 75 technique. Content lines SHOULD be folded to a maximum width of 75
octets, excluding the line break. Multi-octet characters MUST remain octets, excluding the line break. Multi-octet characters MUST remain
contiguous. The rationale for this folding process can be found in contiguous. The rationale for this folding process can be found in
[RFC5322], Section 2.1.1. [RFC5322], Section 2.1.1.
skipping to change at page 7, line 30 skipping to change at page 7, line 35
sequence. For this reason, implementations SHOULD unfold lines in sequence. For this reason, implementations SHOULD unfold lines in
such a way as to properly restore the original sequence. such a way as to properly restore the original sequence.
Note: Unfolding is done differently than in [RFC5322]. Unfolding Note: Unfolding is done differently than in [RFC5322]. Unfolding
in [RFC5322] only removes the CRLF, not the space following it. in [RFC5322] only removes the CRLF, not the space following it.
Folding is done after any content encoding of a type value. Folding is done after any content encoding of a type value.
Unfolding is done before any decoding of a type value in a content Unfolding is done before any decoding of a type value in a content
line. line.
3.2. ABNF Format Definition 3.3. ABNF Format Definition
The following ABNF uses the notation of [RFC5234], which also defines The following ABNF uses the notation of [RFC5234], which also defines
CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.
vcard-entity = 1*(vcard) vcard-entity = 1*(vcard)
vcard = "BEGIN" ":" "VCARD" CRLF vcard = "BEGIN" ":" "VCARD" CRLF
"VERSION" ":" "4.0" CRLF "VERSION" ":" "4.0" CRLF
1*contentline 1*contentline
"END" ":" "VCARD" CRLF "END" ":" "VCARD" CRLF
; A vCard object MUST include the VERSION and FN properties. ; A vCard object MUST include the VERSION and FN properties.
; VERSION MUST come first. ; VERSION MUST come immediately after BEGIN:VCARD.
contentline = [group "."] name *(";" param) ":" value CRLF contentline = [group "."] name *(";" param) ":" value CRLF
; When parsing a content line, folded lines must first ; When parsing a content line, folded lines must first
; be unfolded according to the unfolding procedure ; be unfolded according to the unfolding procedure
; described above. ; described above.
; When generating a content line, lines longer than 75 ; When generating a content line, lines longer than 75
; characters SHOULD be folded according to the folding ; characters SHOULD be folded according to the folding
; procedure described above. ; procedure described above.
group = 1*(ALPHA / DIGIT / "-") group = 1*(ALPHA / DIGIT / "-")
name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME" name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME"
/ "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / / "TEL" / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / / "TEL"
/ "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE" / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE"
/ "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES" / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES"
/ "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP" / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP"
skipping to change at page 9, line 20 skipping to change at page 9, line 24
output. output.
The group construct is used to group related properties together. The group construct is used to group related properties together.
The group name is a syntactic convention used to indicate that all The group name is a syntactic convention used to indicate that all
property names prefaced with the same group name SHOULD be grouped property names prefaced with the same group name SHOULD be grouped
together when displayed by an application. It has no other together when displayed by an application. It has no other
significance. Implementations that do not understand or support significance. Implementations that do not understand or support
grouping MAY simply strip off any text before a "." to the left of grouping MAY simply strip off any text before a "." to the left of
the type name and present the types and values as normal. the type name and present the types and values as normal.
Property cardinalities are indicated using the following notation,
which is based on ABNF (see [RFC5234], section 3.6):
+-------------+--------------------------------------------------+
| Cardinality | Meaning |
+-------------+--------------------------------------------------+
| 1 | Exactly one instance per vCard MUST be present. |
| *1 | Exactly one instance per vCard MAY be present. |
| 1* | One or more instances per vCard MUST be present. |
| * | One or more instances per vCard MAY be present. |
+-------------+--------------------------------------------------+
Properties defined in a vCard instance may have multiple values Properties defined in a vCard instance may have multiple values
depending on the property cardinality. The general rule for encoding depending on the property cardinality. The general rule for encoding
multi-valued properties is to simply create a new content line for multi-valued properties is to simply create a new content line for
each value (including the property name). However, it should be each value (including the property name). However, it should be
noted that some value types support encoding multiple values in a noted that some value types support encoding multiple values in a
single content line by separating the values with a comma ",". This single content line by separating the values with a comma ",". This
approach has been taken for several of the content types defined approach has been taken for several of the content types defined
below (date, time, integer, float). below (date, time, integer, float).
3.3. Property Value Escaping 3.4. Property Value Escaping
Some properties may contain one or more values delimited by a COMMA Some properties may contain one or more values delimited by a COMMA
character (ASCII decimal 44). Therefore, a COMMA character in a character (ASCII decimal 44). Therefore, a COMMA character in a
value MUST be escaped with a BACKSLASH character (ASCII decimal 92), value MUST be escaped with a BACKSLASH character (ASCII decimal 92),
even for properties that don't allow multiple instances (for even for properties that don't allow multiple instances (for
consistency). consistency).
Some properties (e.g. N and ADR) comprise multiple fields delimited Some properties (e.g. N and ADR) comprise multiple fields delimited
by a SEMI-COLON character (ASCII decimal 59). Therefore, a SEMI- by a SEMI-COLON character (ASCII decimal 59). Therefore, a SEMI-
COLON in a field of such a "compound" property MUST be escaped with a COLON in a field of such a "compound" property MUST be escaped with a
skipping to change at page 10, line 10 skipping to change at page 10, line 27
consistency). Compound properties allowing multiple instances MUST consistency). Compound properties allowing multiple instances MUST
NOT be encoded in a single content line. NOT be encoded in a single content line.
Finally, BACKSLASH characters in values MUST be escaped with a Finally, BACKSLASH characters in values MUST be escaped with a
BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values
MUST be encoded by two characters: a BACKSLASH followed by an 'n' MUST be encoded by two characters: a BACKSLASH followed by an 'n'
(ASCII decimal 110). (ASCII decimal 110).
In all other cases, escaping MUST NOT be used. In all other cases, escaping MUST NOT be used.
3.4. Character Set
The character set for vCard is UTF-8 as defined in [RFC3629]. There
is no way to override this. It is invalid to specify a different
character set in the "charset" MIME parameter (see Section 10.1).
This overrides both [RFC2046] section 4.1.2 and [RFC2616] section
3.7.1.
4. Property Value Data Types 4. Property Value Data Types
Standard value types are defined below. Standard value types are defined below.
value = text value = text
/ text-list / text-list
/ date-list / date-list
/ time-list / time-list
/ date-time-list / date-time-list
/ date-and-or-time-list / date-and-or-time-list
skipping to change at page 10, line 45 skipping to change at page 11, line 5
text = *TEXT-CHAR text = *TEXT-CHAR
TEXT-CHAR = "\\" / "\," / "\n" TEXT-CHAR = "\\" / "\," / "\n"
/ <any VALUE-CHAR except , or \> / <any VALUE-CHAR except , or \>
; Backslashes, commas, and newlines must be encoded. ; Backslashes, commas, and newlines must be encoded.
component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
/ %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
list-component = list-component-value *("," list-component-value) list-component = component *("," component)
list-component-value = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
/ %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
text-list = text *("," text) text-list = text *("," text)
date-list = date *("," date) date-list = date *("," date)
time-list = time *("," time) time-list = time *("," time)
date-time-list = date-time *("," date-time) date-time-list = date-time *("," date-time)
date-and-or-time-list = date-and-or-time *("," date-and-or-time) date-and-or-time-list = date-and-or-time *("," date-and-or-time)
timestamp-list = timestamp *("," timestamp) timestamp-list = timestamp *("," timestamp)
integer-list = integer *("," integer) integer-list = integer *("," integer)
float-list = float *("," float) float-list = float *("," float)
skipping to change at page 17, line 5 skipping to change at page 17, line 5
URI text. URI text.
Applications MUST ignore x-param and iana-param values they don't Applications MUST ignore x-param and iana-param values they don't
recognize. recognize.
5.1. LANGUAGE 5.1. LANGUAGE
The LANGUAGE property parameter is used to identify data in multiple The LANGUAGE property parameter is used to identify data in multiple
languages. There is no concept of "default" language, except as languages. There is no concept of "default" language, except as
specified by any "Content-Language" MIME header parameter that is specified by any "Content-Language" MIME header parameter that is
present. The value of the LANGUAGE property parameter is a language present [RFC3282]. The value of the LANGUAGE property parameter is a
tag as defined in Section 2 of [RFC5646]. language tag as defined in Section 2 of [RFC5646].
Examples: Examples:
ROLE;LANGUAGE=tr:hoca ROLE;LANGUAGE=tr:hoca
ABNF: ABNF:
language-param = "LANGUAGE=" Language-Tag language-param = "LANGUAGE=" Language-Tag
; Language-Tag is defined in section 2.1 of RFC 5646 ; Language-Tag is defined in section 2.1 of RFC 5646
skipping to change at page 21, line 5 skipping to change at page 21, line 5
"individual", or to none in other cases. "individual", or to none in other cases.
ABNF: ABNF:
type-param = "TYPE=" type-value *("," type-value) type-param = "TYPE=" type-value *("," type-value)
type-value = "work" / "home" / type-param-tel type-value = "work" / "home" / type-param-tel
/ type-param-related / iana-token / x-name / type-param-related / iana-token / x-name
; This is further defined in individual property sections. ; This is further defined in individual property sections.
5.7. CALSCALE 5.7. MEDIATYPE
The MEDIATYPE parameter is used with properties whose value is a URI.
Its use is OPTIONAL. It provides a hint to the vCard consumer
application about the media type of the resource identified by the
URI. Some URI schemes do not need this parameter. For example, the
"data" scheme allows the media type to be explicitly indicated as
part of the URI [RFC2397]. Another scheme, "http", provides the
media type as part of the URI resolution process, with the Content-
Type HTTP header [RFC2616]. The MEDIATYPE parameter is intended to
be used with URI schemes that do not provide such functionality (e.g.
"ftp" [RFC1738]).
ABNF:
mediatype-param = "MEDIATYPE=" mediatype
mediatype = type "/" subtype *( ";" attribute "=" value )
; "type", "subtype", "attribute", and "value" are from [RFC2045].
5.8. CALSCALE
The CALSCALE parameter is identical to the CALSCALE property in The CALSCALE parameter is identical to the CALSCALE property in
iCalendar (see [RFC5545], section 3.7.1). It is used to define the iCalendar (see [RFC5545], section 3.7.1). It is used to define the
calendar system in which a date or date-time value is expressed. The calendar system in which a date or date-time value is expressed. The
only value specified by iCalendar is "gregorian", which stands for only value specified by iCalendar is "gregorian", which stands for
the Gregorian system. It is the default when the parameter is the Gregorian system. It is the default when the parameter is
absent. Additional values may be defined in extension documents and absent. Additional values may be defined in extension documents and
registered from IANA (see Section 10.3.4). A vCard implementation registered from IANA (see Section 10.3.4). A vCard implementation
MUST ignore properties with a CALSCALE parameter value that it does MUST ignore properties with a CALSCALE parameter value that it does
not understand. not understand.
ABNF: ABNF:
calscale-param = "CALSCALE=" calscale-value calscale-param = "CALSCALE=" calscale-value
calscale-value = "gregorian" / iana-token / x-name calscale-value = "gregorian" / iana-token / x-name
5.8. SORT-AS 5.9. SORT-AS
The "sort-as" parameter is used to specify the string to be used for The "sort-as" parameter is used to specify the string to be used for
national-language-specific sorting. Without this information, national-language-specific sorting. Without this information,
sorting algorithms could incorrectly sort this vCard within a sorting algorithms could incorrectly sort this vCard within a
sequence of sorted vCards. When this property is present in a vCard, sequence of sorted vCards. When this property is present in a vCard,
then the given strings are used for sorting the vCard. then the given strings are used for sorting the vCard.
This parameter's value is a comma-separated list which MUST have as This parameter's value is a comma-separated list which MUST have as
many or less elements as the corresponding property value has many or less elements as the corresponding property value has
components. components.
skipping to change at page 22, line 41 skipping to change at page 23, line 5
If sorted by given name the results would be: If sorted by given name the results would be:
Christine d'Aboville Christine d'Aboville
H. James de Mann H. James de Mann
Osamu Koura Osamu Koura
Oscar del Pozo Oscar del Pozo
Rene van der Harten Rene van der Harten
Robert Pau Shou Chang Robert Pau Shou Chang
5.9. GEO 5.10. GEO
The GEO parameter can be used to indicate global positioning The GEO parameter can be used to indicate global positioning
information that is specific to an address. Its value is the same as information that is specific to an address. Its value is the same as
that of the GEO property (see Section 6.5.2). that of the GEO property (see Section 6.5.2).
ABNF: ABNF:
geo-param = "GEO=" DQUOTE uri DQUOTE geo-param = "GEO=" DQUOTE uri DQUOTE
5.10. TZ 5.11. TZ
The TZ parameter can be used to indicate time zone information that The TZ parameter can be used to indicate time zone information that
is specific to an address. Its value is the same as that of the TZ is specific to an address. Its value is the same as that of the TZ
property. property.
ABNF: ABNF:
tz-param = "TZ=" (param-value / DQUOTE uri DQUOTE) tz-param = "TZ=" (param-value / DQUOTE uri DQUOTE)
6. vCard Properties 6. vCard Properties
What follows is an enumeration of the standard vCard properties. What follows is an enumeration of the standard vCard properties.
Property cardinalities are indicated using the following notation,
which is based on ABNF (see [RFC5234], section 3.6):
+-------------+--------------------------------------------------+
| Cardinality | Meaning |
+-------------+--------------------------------------------------+
| 1 | Exactly one instance per vCard MUST be present. |
| *1 | Exactly one instance per vCard MAY be present. |
| 1* | One or more instances per vCard MUST be present. |
| * | One or more instances per vCard MAY be present. |
+-------------+--------------------------------------------------+
6.1. General Properties 6.1. General Properties
6.1.1. BEGIN 6.1.1. BEGIN
Purpose: To denote the beginning of a syntactic entity within a Purpose: To denote the beginning of a syntactic entity within a
text/vcard content-type. text/vcard content-type.
Value type: text Value type: text
Cardinality: 1 Cardinality: 1
skipping to change at page 25, line 19 skipping to change at page 25, line 19
the directory service. It contains a URI as defined in [RFC3986] the directory service. It contains a URI as defined in [RFC3986]
and/or other information referencing the vCard to which the and/or other information referencing the vCard to which the
information pertains. When directory information is available information pertains. When directory information is available
from more than one source, the sending entity can pick what it from more than one source, the sending entity can pick what it
considers to be the best source, or multiple SOURCE properties can considers to be the best source, or multiple SOURCE properties can
be included. be included.
ABNF: ABNF:
SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param
/ any-param / mediatype-param / any-param
SOURCE-value = uri SOURCE-value = uri
Examples: Examples:
SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US
SOURCE:http://directory.example.com/addressbooks/jdoe/ SOURCE:http://directory.example.com/addressbooks/jdoe/
Jean%20Dupont.vcf Jean%20Dupont.vcf
6.1.4. KIND 6.1.4. KIND
Purpose: To specify the kind of object the vCard represents. Purpose: To specify the kind of object the vCard represents.
Value type: A single text value. Value type: A single text value.
Cardinality: *1 Cardinality: *1
Special notes: The value may be one of: "individual" for a single Special notes: The value may be one of the following:
person, "group" for a group, "org" for an organization, "location"
for a named geographical place, an x-name or an iana-token. If
this property is absent, "individual" MUST be assumed as default.
Additional values may be registered from IANA (see * for a vCard representing a single person or entity. This is
Section 10.3.4). A new value's specification document MUST the default kind of vCard.
specify which properties make sense for that new kind of vCard,
and which do not. * for a vCard representing a group of persons or entities. The
group's member entities can be other vCards or other types of
entities, such as email addresses or web sites. A group vCard
will usually contain MEMBER properties to specify the members
of the group, but it is not required to. A group vCard without
MEMBER properties can be considered an abstract grouping, or
one whose members are known empirically (perhaps "IETF
Participants" or "Republican U.S. Senators").
* All properties in a group vCard apply to the group as a whole,
and not to any particular MEMBER. For example, an EMAIL
property might specify the address of a mailing list associated
with the group, and an IMPP property might refer to a group
chat room.
* for a vCard representing an organization. An organization
vCard will not (in fact, MUST NOT) contain MEMBER properties,
and so these are something of a cross between "individual" and
"group". An organization is a single entity, but not a person.
It might represent a business or government, a department or
division within a business or government, a club, an
association, or the like.
* All properties in an organization vCard apply to the
organization as a whole, as is the case with a group vCard.
For example, an EMAIL property might specify the address of a
contact point for the organization.
* for a named geographical place. A location vCard will usually
contain a GEO property, but it is not required to. A location
vCard without a GEO property can be considered an abstract
location, or one whose definition is known empirically (perhaps
"New England" or "The Seashore").
* All properties in an location vCard apply to the location
itself, and not with any entity that might exist at that
location. For example, in a vCard for an office building, an
ADR property might give the mailing address for the building,
and a TEL property might specify the telephone number of the
receptionist.
* vCards MAY include private or experimental values for KIND.
Remember that x-name values are not intended for general use,
and are unlikely to interoperate.
* Additional values may be registered with IANA (see
Section 10.3.4). A new value's specification document MUST
specify which properties make sense for that new kind of vCard,
and which do not.
Implementations MUST support the specific string values defined
above. If this property is absent, "individual" MUST be assumed
as the default. If this property is present but the
implementation does not understand its value (the value is an
x-name or iana-token that the implementation does not support),
the implementation SHOULD act in a neutral way, which usually
means treating the vCard as though its kind were "individual".
The presence of MEMBER properties MAY, however, be taken as an
indication that the unknown kind is an extension of "group".
Clients often need to visually distinguish contacts based on what
they represent, and the KIND property provides a direct way for
them to do so. For example, when displaying contacts in a list,
an icon could be displayed next to each one, using distinctive
icons for the different kinds; a client might use an outline of a
single person to represent an "individual", an outline of multiple
people to represent a "group", and so on. Alternatively, or in
addition, a client might choose to segregate different kinds of
vCards to different panes, tabs, or selections in the user
interface.
Some clients might also make functional distinctions among the
kinds, ignoring "location" vCards for some purposes and
considering only "location" vCards for others.
When designing those sorts of visual and functional distinctions,
client implementations have to decide how to fit unsupported kinds
into the scheme. What icon is used for them? The one for
"individual"? A unique one, such as an icon of a question-mark?
Which tab do they go into? It is beyond the scope of this
specification to answer these questions, but these are things
implementors need to consider.
ABNF: ABNF:
KIND-param = "VALUE=text" / any-param KIND-param = "VALUE=text" / any-param
KIND-value = "individual" / "group" / "org" / "location" KIND-value = "individual" / "group" / "org" / "location"
/ iana-token / x-name / iana-token / x-name
Example: Example:
This represents someone named Jane Doe working in the marketing This represents someone named Jane Doe working in the marketing
skipping to change at page 26, line 37 skipping to change at page 28, line 25
6.1.5. XML 6.1.5. XML
Purpose: To include extended XML-encoded vCard data in a plain Purpose: To include extended XML-encoded vCard data in a plain
vCard. vCard.
Value type: A single text value. Value type: A single text value.
Cardinality: * Cardinality: *
Special notes: The content of this property is a single XML 1.0 Special notes: The content of this property is a single XML 1.0
element whose namespace MUST be explicitly specified using the [W3C.REC-xml-20081126] element whose namespace MUST be explicitly
xmlns attribute and MUST NOT be the vCard 4 namespace specified using the xmlns attribute and MUST NOT be the vCard 4
("urn:ietf:params:xml:ns:vcard-4.0"). (This implies that it namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies
cannot duplicate a standard vCard property.) The element is to be that it cannot duplicate a standard vCard property.) The element
interpreted as if it was contained in a <vcard> element, as is to be interpreted as if it was contained in a <vcard> element,
defined in [I-D.ietf-vcarddav-vcardxml]. as defined in [I-D.ietf-vcarddav-vcardxml].
The fragment is subject to normal line folding and escaping, i.e. The fragment is subject to normal line folding and escaping, i.e.
replace all backslashes with "\\", then replace all newlines with replace all backslashes with "\\", then replace all newlines with
"\n", then fold long lines. "\n", then fold long lines.
Support for this property is OPTIONAL, but implementations of this Support for this property is OPTIONAL, but implementations of this
specification MUST preserve instances of this property when specification MUST preserve instances of this property when
propagating vCards. propagating vCards.
See [I-D.ietf-vcarddav-vcardxml] for more information on the See [I-D.ietf-vcarddav-vcardxml] for more information on the
intended use of this property. intended use of this property.
ABNF: ABNF:
XML-param = "VALUE=text" / altid-param XML-param = "VALUE=text" / altid-param
XML-value = text XML-value = text
6.2. Identification Properties 6.2. Identification Properties
These types are used to capture information associated with the These types are used to capture information associated with the
identification and naming of the person or resource associated with identification and naming of the entity associated with the vCard.
the vCard.
6.2.1. FN 6.2.1. FN
Purpose: To specify the formatted text corresponding to the name of Purpose: To specify the formatted text corresponding to the name of
the object the vCard represents. the object the vCard represents.
Value type: A single text value. Value type: A single text value.
Cardinality: 1* Cardinality: 1*
skipping to change at page 29, line 25 skipping to change at page 31, line 12
Purpose: To specify an image or photograph information that Purpose: To specify an image or photograph information that
annotates some aspect of the object the vCard represents. annotates some aspect of the object the vCard represents.
Value type: A single URI. Value type: A single URI.
Cardinality: * Cardinality: *
ABNF: ABNF:
PHOTO-param = "VALUE=uri" / altid-param / type-param PHOTO-param = "VALUE=uri" / altid-param / type-param
/ mediatype-param
PHOTO-value = uri PHOTO-value = uri
Examples: Examples:
PHOTO:http://www.example.com/pub/photos/jqpublic.gif PHOTO:http://www.example.com/pub/photos/jqpublic.gif
PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...remainder of base64-encoded data...> <...remainder of base64-encoded data...>
skipping to change at page 34, line 24 skipping to change at page 35, line 39
| voice | Indicates a voice telephone number. | | voice | Indicates a voice telephone number. |
| fax | Indicates a facsimile telephone number. | | fax | Indicates a facsimile telephone number. |
| cell | Indicates a cellular or mobile telephone number. | | cell | Indicates a cellular or mobile telephone number. |
| video | Indicates a video conferencing telephone number. | | video | Indicates a video conferencing telephone number. |
| pager | Indicates a paging device telephone number. | | pager | Indicates a paging device telephone number. |
| textphone | Indicates a telecommunication device for people with | | textphone | Indicates a telecommunication device for people with |
| | hearing or speech difficulties.. | | | hearing or speech difficulties.. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
The default type is "voice". These type parameter values can be The default type is "voice". These type parameter values can be
specified as a parameter list (e.g., "TYPE=text;TYPE=voice") or as specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
a value list (e.g., "TYPE=text,voice"). The default can be value list (e.g., TYPE="text,voice"). The default can be
overridden to another set of values by specifying one or more overridden to another set of values by specifying one or more
alternate values. For example, the default TYPE of "voice" can be alternate values. For example, the default TYPE of "voice" can be
reset to a VOICE and FAX telephone number by the value list reset to a VOICE and FAX telephone number by the value list
"TYPE=voice,fax". TYPE="voice,fax".
If this property's value is a URI that can also be used for If this property's value is a URI that can also be used for
instant messaging, the IMPP (Section 6.4.3) property SHOULD be instant messaging, the IMPP (Section 6.4.3) property SHOULD be
used in addition to this property. used in addition to this property.
ABNF: ABNF:
TEL-param = TEL-text-param / TEL-uri-param TEL-param = TEL-text-param / TEL-uri-param
TEL-value = TEL-text-value / TEL-uri-value TEL-value = TEL-text-value / TEL-uri-value
; Value and parameter MUST match ; Value and parameter MUST match
TEL-text-param = "VALUE=text" TEL-text-param = "VALUE=text"
TEL-text-value = text TEL-text-value = text
TEL-uri-param = "VALUE=uri" TEL-uri-param = "VALUE=uri" / mediatype-param
TEL-uri-value = uri TEL-uri-value = uri
TEL-param =/ type-param / pid-param / pref-param / altid-param TEL-param =/ type-param / pid-param / pref-param / altid-param
/ any-param / any-param
type-param-tel = "text" / "voice" / "fax" / "cell" / "video" type-param-tel = "text" / "voice" / "fax" / "cell" / "video"
/ "pager" / "textphone" / iana-token / x-name / "pager" / "textphone" / iana-token / x-name
; type-param-tel MUST NOT be used with a property other than TEL. ; type-param-tel MUST NOT be used with a property other than TEL.
Example: Example:
TEL;VALUE=uri;PREF=1;TYPE=voice,home:tel:+1-555-555-5555;ext=5555 TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67 TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67
6.4.2. EMAIL 6.4.2. EMAIL
Purpose: To specify the electronic mail address for communication Purpose: To specify the electronic mail address for communication
with the object the vCard represents. with the object the vCard represents.
Value type: A single text value. Value type: A single text value.
Cardinality: * Cardinality: *
skipping to change at page 36, line 4 skipping to change at page 37, line 19
EMAIL;PREF=1:jane_doe@example.com EMAIL;PREF=1:jane_doe@example.com
6.4.3. IMPP 6.4.3. IMPP
Purpose: To specify the URI for instant messaging and presence Purpose: To specify the URI for instant messaging and presence
protocol communications with the object the vCard represents. protocol communications with the object the vCard represents.
Value type: A single URI. Value type: A single URI.
Cardinality: * Cardinality: *
Special notes: The property may include the "PREF" parameter to Special notes: The property may include the "PREF" parameter to
indicate that this is a preferred address and has the same indicate that this is a preferred address and has the same
semantics as the "PREF" parameter in a TEL property. semantics as the "PREF" parameter in a TEL property.
If this property's value is a URI that can be used for voice If this property's value is a URI that can be used for voice
and/or video, the TEL property (Section 6.4.1) SHOULD be used in and/or video, the TEL property (Section 6.4.1) SHOULD be used in
addition to this property. addition to this property.
This property is adapted from [RFC4770], which is made obsolete by This property is adapted from [RFC4770], which is made obsolete by
this document. this document.
ABNF: ABNF:
IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param
/ altid-param / any-param / mediatype-param / altid-param / any-param
IMPP-value = uri IMPP-value = uri
Example: Example:
IMPP;PREF=1:xmpp:alice@example.com IMPP;PREF=1:xmpp:alice@example.com
6.4.4. LANG 6.4.4. LANG
Purpose: To specify the language(s) that may be used for contacting Purpose: To specify the language(s) that may be used for contacting
the individual associated with the vCard. the entity associated with the vCard.
Value type: A single language-tag value. Value type: A single language-tag value.
Cardinality: * Cardinality: *
ABNF: ABNF:
LANG-param = "VALUE=language-tag" / pid-param / pref-param LANG-param = "VALUE=language-tag" / pid-param / pref-param
/ altid-param / type-param / any-param / altid-param / type-param / any-param
LANG-value = Language-Tag LANG-value = Language-Tag
Example: Example:
LANG;TYPE=work;PREF=1:en LANG;TYPE=work;PREF=1:en
LANG;TYPE=work;PREF=2:fr LANG;TYPE=work;PREF=2:fr
skipping to change at page 37, line 37 skipping to change at page 39, line 10
regions will "re-base" their overall offset. The actual offset regions will "re-base" their overall offset. The actual offset
may be +/- 1 hour (or perhaps a little more) than the one given. may be +/- 1 hour (or perhaps a little more) than the one given.
ABNF: ABNF:
TZ-param = "VALUE=" ("text" / "uri" / "utc-offset") TZ-param = "VALUE=" ("text" / "uri" / "utc-offset")
TZ-value = text / uri / utc-offset TZ-value = text / uri / utc-offset
; Value and parameter MUST match ; Value and parameter MUST match
TZ-param =/ altid-param / pid-param / pref-param / type-param TZ-param =/ altid-param / pid-param / pref-param / type-param
/ any-param / mediatype-param / any-param
Examples: Examples:
TZ:Raleigh/North America TZ:Raleigh/North America
TZ;VALUE=utc-offset:-0500 TZ;VALUE=utc-offset:-0500
; Note: utc-offset format is NOT RECOMMENDED. ; Note: utc-offset format is NOT RECOMMENDED.
6.5.2. GEO 6.5.2. GEO
skipping to change at page 38, line 15 skipping to change at page 39, line 34
Value type: A single URI. Value type: A single URI.
Cardinality: * Cardinality: *
Special notes: The "geo" URI scheme [RFC5870] is particularly well- Special notes: The "geo" URI scheme [RFC5870] is particularly well-
suited for this property, but other schemes MAY be used. suited for this property, but other schemes MAY be used.
ABNF: ABNF:
GEO-param = "VALUE=uri" / pid-param / pref-param / type-param GEO-param = "VALUE=uri" / pid-param / pref-param / type-param
/ altid-param / any-param / mediatype-param / altid-param / any-param
GEO-value = uri GEO-value = uri
Example: Example:
GEO:geo:37.386013,-122.082932 GEO:geo:37.386013,-122.082932
6.6. Organizational Properties 6.6. Organizational Properties
These properties are concerned with information associated with These properties are concerned with information associated with
characteristics of the organization or organizational units of the characteristics of the organization or organizational units of the
skipping to change at page 39, line 42 skipping to change at page 41, line 17
Purpose: To specify a graphic image of a logo associated with the Purpose: To specify a graphic image of a logo associated with the
object the vCard represents. object the vCard represents.
Value type: A single URI. Value type: A single URI.
Cardinality: * Cardinality: *
ABNF: ABNF:
LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param
/ type-param / altid-param / any-param / type-param / mediatype-param / altid-param / any-param
LOGO-value = uri LOGO-value = uri
Examples: Examples:
LOGO:http://www.example.com/pub/logos/abccorp.jpg LOGO:http://www.example.com/pub/logos/abccorp.jpg
LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of base64-encoded data...> <...the remainder of base64-encoded data...>
skipping to change at page 40, line 40 skipping to change at page 42, line 16
organizational unit #1 name and organizational unit #2 name. organizational unit #1 name and organizational unit #2 name.
ORG:ABC\, Inc.;North American Division;Marketing ORG:ABC\, Inc.;North American Division;Marketing
6.6.5. MEMBER 6.6.5. MEMBER
Purpose: To include a member in the group this vCard represents. Purpose: To include a member in the group this vCard represents.
Value type: A single URI. It MAY refer to something other than a Value type: A single URI. It MAY refer to something other than a
vCard object. For example, an e-mail distribution list could vCard object. For example, an e-mail distribution list could
employ the "mailto" URI scheme for efficiency. employ the "mailto" URI scheme [RFC6068] for efficiency.
Cardinality: * Cardinality: *
Special notes: This property MUST NOT be present unless the value of Special notes: This property MUST NOT be present unless the value of
the KIND property is "group". the KIND property is "group".
ABNF: ABNF:
MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param
/ any-param / mediatype-param / any-param
MEMBER-value = uri MEMBER-value = uri
Examples: Examples:
BEGIN:VCARD BEGIN:VCARD
VERSION:4.0 VERSION:4.0
KIND:group KIND:group
FN:The Doe family FN:The Doe family
MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
skipping to change at page 41, line 24 skipping to change at page 43, line 4
BEGIN:VCARD BEGIN:VCARD
VERSION:4.0 VERSION:4.0
FN:John Doe FN:John Doe
UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:4.0 VERSION:4.0
FN:Jane Doe FN:Jane Doe
UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:4.0 VERSION:4.0
KIND:group KIND:group
FN:Funky distribution list FN:Funky distribution list
MEMBER:mailto:subscriber1@example.com MEMBER:mailto:subscriber1@example.com
MEMBER:xmpp:subscriber2@example.com MEMBER:xmpp:subscriber2@example.com
MEMBER:sip:subscriber3@example.com MEMBER:sip:subscriber3@example.com
MEMBER:tel:+1-418-555-5555 MEMBER:tel:+1-418-555-5555
END:VCARD END:VCARD
6.6.6. RELATED 6.6.6. RELATED
Purpose: To specify a relationship between another person and the Purpose: To specify a relationship between another entity and the
individual represented by this vCard. entity represented by this vCard.
Value type: A single URI. It can also be reset to a single text Value type: A single URI. It can also be reset to a single text
value. The text value can be used to specify textual information. value. The text value can be used to specify textual information.
Cardinality: * Cardinality: *
Special notes: The TYPE parameter MAY be used to characterize the Special notes: The TYPE parameter MAY be used to characterize the
related individual. It contains a comma-separated list of values related entity. It contains a comma-separated list of values that
that are registered from IANA as described in Section 10.2. The are registered from IANA as described in Section 10.2. The
registry is pre-populated with the values defined in [xfn]. This registry is pre-populated with the values defined in [xfn]. This
document also specifies two additional values: document also specifies two additional values:
agent: a person who may sometimes act on behalf of the individual agent: an entity who may sometimes act on behalf of the entity
or resource associated with the vCard. associated with the vCard.
emergency: indicates an emergency contact emergency: indicates an emergency contact
ABNF: ABNF:
RELATED-param = RELATED-param-uri / RELATED-param-text RELATED-param = RELATED-param-uri / RELATED-param-text
RELATED-value = uri / text RELATED-value = uri / text
; Parameter and value MUST match. ; Parameter and value MUST match.
RELATED-param-uri = "VALUE=uri" RELATED-param-uri = "VALUE=uri" / mediatype-param
RELATED-param-text = "VALUE=text" / language-param RELATED-param-text = "VALUE=text" / language-param
RELATED-param =/ pid-param / pref-param / altid-param / type-param RELATED-param =/ pid-param / pref-param / altid-param / type-param
/ any-param / any-param
type-param-related = related-type-value *("," related-type-value) type-param-related = related-type-value *("," related-type-value)
; type-param-related MUST NOT be used with a property other than ; type-param-related MUST NOT be used with a property other than
; RELATED. ; RELATED.
related-type-value = "contact" / "acquaintance" / "friend" / "met" related-type-value = "contact" / "acquaintance" / "friend" / "met"
skipping to change at page 45, line 12 skipping to change at page 46, line 48
to specify the proper pronunciation of the name property value of to specify the proper pronunciation of the name property value of
the vCard. the vCard.
Value type: A single URI. Value type: A single URI.
Cardinality: * Cardinality: *
ABNF: ABNF:
SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param
/ type-param / altid-param / any-param / type-param / mediatype-param / altid-param
/ any-param
SOUND-value = uri SOUND-value = uri
Example: Example:
SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com
SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of base64-encoded data...> <...the remainder of base64-encoded data...>
6.7.6. UID 6.7.6. UID
Purpose: To specify a value that represents a globally unique Purpose: To specify a value that represents a globally unique
identifier corresponding to the individual or resource associated identifier corresponding to the entity associated with the vCard.
with the vCard.
Value type: A single URI value. It MAY also be reset to free-form Value type: A single URI value. It MAY also be reset to free-form
text. text.
Cardinality: *1 Cardinality: *1
Special notes: This property is used to uniquely identify the object Special notes: This property is used to uniquely identify the object
that the vCard represents. The "uuid" URN namespace defined in that the vCard represents. The "uuid" URN namespace defined in
[RFC4122] is particularly well-suited to this task, but other URI [RFC4122] is particularly well-suited to this task, but other URI
schemes MAY be used. Free-form text MAY also be used. schemes MAY be used. Free-form text MAY also be used.
skipping to change at page 47, line 12 skipping to change at page 48, line 46
object that the vCard refers to. Examples for individuals include object that the vCard refers to. Examples for individuals include
personal web sites, blogs, and social networking site identifiers. personal web sites, blogs, and social networking site identifiers.
Cardinality: * Cardinality: *
Value type: A single uri value. Value type: A single uri value.
ABNF: ABNF:
URL-param = "VALUE=uri" / pid-param / pref-param / type-param URL-param = "VALUE=uri" / pid-param / pref-param / type-param
/ altid-param / any-param / mediatype-param / altid-param / any-param
URL-value = uri URL-value = uri
Example: Example:
URL:http://example.org/restaurant.french/~chezchic.html URL:http://example.org/restaurant.french/~chezchic.html
6.7.9. VERSION 6.7.9. VERSION
Purpose: To specify the version of the vCard specification used to Purpose: To specify the version of the vCard specification used to
format this vCard. format this vCard.
Value type: A single text value. Value type: A single text value.
Cardinality: 1 Cardinality: 1
Special notes: This property MUST be present in the vCard object, Special notes: This property MUST be present in the vCard object,
and it must come first. The value MUST be "4.0" if the vCard and it must appear immediately after BEGIN:VCARD. The value MUST
corresponds to this specification. Note that earlier versions of be "4.0" if the vCard corresponds to this specification. Note
vCard allowed this property to be placed anywehre in the vCard that earlier versions of vCard allowed this property to be placed
object, or even to be absent. anywhere in the vCard object, or even to be absent.
ABNF: ABNF:
VERSION-param = "VALUE=text" / any-param VERSION-param = "VALUE=text" / any-param
VERSION-value = "4.0" VERSION-value = "4.0"
Example: Example:
VERSION:4.0 VERSION:4.0
skipping to change at page 48, line 4 skipping to change at page 49, line 35
Example: Example:
VERSION:4.0 VERSION:4.0
6.8. Security Properties 6.8. Security Properties
These properties are concerned with the security of communication These properties are concerned with the security of communication
pathways or access to the vCard. pathways or access to the vCard.
6.8.1. KEY 6.8.1. KEY
Purpose: To specify a public key or authentication certificate Purpose: To specify a public key or authentication certificate
associated with the object that the vCard represents. associated with the object that the vCard represents.
Value type: A single URI. It can also be reset to a text value. Value type: A single URI. It can also be reset to a text value.
Cardinality: * Cardinality: *
ABNF: ABNF:
KEY-param = KEY-uri-param / KEY-text-param KEY-param = KEY-uri-param / KEY-text-param
KEY-value = KEY-uri-value / KEY-text-value KEY-value = KEY-uri-value / KEY-text-value
; Value and parameter MUST match. ; Value and parameter MUST match.
KEY-uri-param = "VALUE=uri" KEY-uri-param = "VALUE=uri" / mediatype-param
KEY-uri-value = uri KEY-uri-value = uri
KEY-text-param = "VALUE=text" KEY-text-param = "VALUE=text"
KEY-text-value = text KEY-text-value = text
KEY-param =/ altid-param / pid-param / pref-param / type-param KEY-param =/ altid-param / pid-param / pref-param / type-param
/ any-param / any-param
Examples: Examples:
KEY:http://www.example.com/keys/jdoe KEY:http://www.example.com/keys/jdoe
KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe
KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE
UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
<... remainder of base64-encoded data ...> <... remainder of base64-encoded data ...>
6.9. Calendar Properties 6.9. Calendar Properties
These properties are further specified in [RFC2739]. These properties are further specified in [RFC2739].
6.9.1. FBURL 6.9.1. FBURL
Purpose: To specify the URI for the busy time associated with the Purpose: To specify the URI for the busy time associated with the
object that the vCard represents. object that the vCard represents.
Value type: A single URI value. Value type: A single URI value.
Cardinality: * Cardinality: *
Special notes: Where multiple FBURL properties are specified, the Special notes: Where multiple FBURL properties are specified, the
default FBURL property is indicated with the PREF parameter. The default FBURL property is indicated with the PREF parameter. The
FTP or HTTP type of URI points to an iCalendar [RFC5545] object FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar
associated with a snapshot of the next few weeks or months of busy [RFC5545] object associated with a snapshot of the next few weeks
time data. If the iCalendar object is represented as a file or or months of busy time data. If the iCalendar object is
document, its file type should be "ifb". represented as a file or document, its file extension should be
".ifb".
ABNF: ABNF:
FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param
/ altid-param / any-param / mediatype-param / altid-param / any-param
FBURL-value = uri FBURL-value = uri
Examples: Examples:
FBURL;PREF=1:http://www.example.com/busy/janedoe FBURL;PREF=1:http://www.example.com/busy/janedoe
FBURL:FTP://ftp.example.com/busy/project-a.ifb FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb
6.9.2. CALADRURI 6.9.2. CALADRURI
Purpose: To specify the calendar user address [RFC5545] to which a Purpose: To specify the calendar user address [RFC5545] to which a
scheduling request [RFC5546] should be sent for the object scheduling request [RFC5546] should be sent for the object
represented by the vCard. represented by the vCard.
Value type: A single URI value. Value type: A single URI value.
Cardinality: * Cardinality: *
Special notes: Where multiple CALADRURI properties are specified, Special notes: Where multiple CALADRURI properties are specified,
the default CALADRURI property is indicated with the PREF the default CALADRURI property is indicated with the PREF
parameter. parameter.
ABNF: ABNF:
CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param
/ altid-param / any-param / mediatype-param / altid-param / any-param
CALADRURI-value = uri CALADRURI-value = uri
Example: Example:
CALADRURI;PREF=1:mailto:janedoe@example.com CALADRURI;PREF=1:mailto:janedoe@example.com
CALADRURI:http://example.com/calendar/jdoe CALADRURI:http://example.com/calendar/jdoe
6.9.3. CALURI 6.9.3. CALURI
Purpose: To specify the URI for a calendar associated with the Purpose: To specify the URI for a calendar associated with the
skipping to change at page 50, line 12 skipping to change at page 51, line 51
Value type: A single URI value. Value type: A single URI value.
Cardinality: * Cardinality: *
Special notes: Where multiple CALURI properties are specified, the Special notes: Where multiple CALURI properties are specified, the
default CALURI property is indicated with the PREF parameter. The default CALURI property is indicated with the PREF parameter. The
property should contain a URI pointing to an iCalendar [RFC5545] property should contain a URI pointing to an iCalendar [RFC5545]
object associated with a snapshot of the user's calendar store. object associated with a snapshot of the user's calendar store.
If the iCalendar object is represented as a file or document, its If the iCalendar object is represented as a file or document, its
file type should be "ics". file extension should be ".ics".
ABNF: ABNF:
CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param
/ altid-param / any-param / mediatype-param / altid-param / any-param
CALURI-value = uri CALURI-value = uri
Examples: Examples:
CALURI;PREF=1:http://cal.example.com/calA CALURI;PREF=1:http://cal.example.com/calA
CALURI:ftp://ftp.example.com/calA.ics CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics
6.10. Extended Properties and Parameters 6.10. Extended Properties and Parameters
The properties and parameters defined by this document can be The properties and parameters defined by this document can be
extended. Non-standard, private properties and parameters with a extended. Non-standard, private properties and parameters with a
name starting with "X-" may be defined bilaterally between two name starting with "X-" may be defined bilaterally between two
cooperating agents without outside registration or standardization. cooperating agents without outside registration or standardization.
7. Synchronization 7. Synchronization
skipping to change at page 56, line 19 skipping to change at page 58, line 19
FN:Simon Perreault FN:Simon Perreault
N:Perreault;Simon;;;ing. jr,M.Sc. N:Perreault;Simon;;;ing. jr,M.Sc.
BDAY:--0203 BDAY:--0203
ANNIVERSARY:20090808T1430-0500 ANNIVERSARY:20090808T1430-0500
GENDER:M GENDER:M
LANG;PREF=1:fr LANG;PREF=1:fr
LANG;PREF=2:en LANG;PREF=2:en
ORG;TYPE=work:Viagenie ORG;TYPE=work:Viagenie
ADR;TYPE=work:;Suite D2-630;2875 Laurier; ADR;TYPE=work:;Suite D2-630;2875 Laurier;
Quebec;QC;G1V 2M2;Canada Quebec;QC;G1V 2M2;Canada
TEL;VALUE=uri;TYPE=work,voice;PREF=1:tel:+1-418-656-9254;ext=102 TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
TEL;VALUE=uri;TYPE=work,cell,voice,video,text:tel:+1-418-262-6501 TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501
EMAIL;TYPE=work:simon.perreault@viagenie.ca EMAIL;TYPE=work:simon.perreault@viagenie.ca
GEO;TYPE=work:geo:46.772673,-71.282945 GEO;TYPE=work:geo:46.772673,-71.282945
KEY;TYPE=work;VALUE=uri: KEY;TYPE=work;VALUE=uri:
http://www.viagenie.ca/simon.perreault/simon.asc http://www.viagenie.ca/simon.perreault/simon.asc
TZ:-0500 TZ:-0500
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:4.0 VERSION:4.0
FN:Pete Resnick FN:Pete Resnick
N:Resnick;Pete;;; N:Resnick;Pete;;;
GENDER:M GENDER:M
ORG;TYPE=work:QUALCOMM Incorporated ORG;TYPE=work:QUALCOMM Incorporated
ADR;TYPE=work:;;5775 Morehouse Drive;San Diego;CA;92121-1714;US ADR;TYPE=work:;;5775 Morehouse Drive;San Diego;CA;92121-1714;US
TEL;VALUE=uri;TYPE=work,voice:tel:+1-858-651-4478 TEL;VALUE=uri;TYPE="work,voice":tel:+1-858-651-4478
EMAIL;TYPE=work:presnick@qualcomm.com EMAIL;TYPE=work:presnick@qualcomm.com
URL;TYPE=work:http://www.qualcomm.com/~presnick/ URL;TYPE=work:http://www.qualcomm.com/~presnick/
END:VCARD END:VCARD
9. Security Considerations 9. Security Considerations
o Internet mail is often used to transport vCards and is subject to o Internet mail is often used to transport vCards and is subject to
many well known security attacks, including monitoring, replay, many well known security attacks, including monitoring, replay,
and forgery. Care should be taken by any directory service in and forgery. Care should be taken by any directory service in
allowing information to leave the scope of the service itself, allowing information to leave the scope of the service itself,
where any access controls can no longer be guaranteed. where any access controls or confidentiality can no longer be
Applications should also take care to display directory data in a guaranteed. Applications should also take care to display
"safe" environment (e.g., PostScript-valued types). directory data in a "safe" environment
o vCards can carry cryptographic keys or certificates, as described o vCards can carry cryptographic keys or certificates, as described
in Section 6.8.1. in Section 6.8.1.
o The vCard objects have no inherent authentication or privacy, but o The vCard objects have no inherent authentication or privacy, but
can easily be carried by any security mechanism that transfers can easily be carried by any security mechanism that transfers
MIME objects with authentication or privacy. In cases where the MIME objects with authentication or privacy (e.g. S/MIME
threat of "spoofed" vCard information is a concern, the vCard [RFC5751], OpenPGP [RFC4880]). In cases where the threat of
SHOULD BE transported using one of these secure mechanisms. "spoofed" vCard information is a concern, the vCard SHOULD BE
transported using one of these secure mechanisms.
o The information in a vCard may become out of date. In cases where o The information in a vCard may become out of date. In cases where
the vitality of data is important to an originator of a vCard, the the vitality of data is important to an originator of a vCard, the
SOURCE property (Section 6.1.3) SHOULD be specified. In addition, SOURCE property (Section 6.1.3) SHOULD be specified. In addition,
the "REV" type described in section Section 6.7.4 can be specified the "REV" type described in section Section 6.7.4 can be specified
to indicate the last time that the vCard data was updated. to indicate the last time that the vCard data was updated.
10. IANA Considerations 10. IANA Considerations
10.1. MIME Type Registration 10.1. MIME Type Registration
skipping to change at page 57, line 44 skipping to change at page 59, line 45
Optional parameters: version Optional parameters: version
The "version" parameter is to be interpreted identically as the The "version" parameter is to be interpreted identically as the
VERSION vCard property. If this parameter is present, all vCards VERSION vCard property. If this parameter is present, all vCards
in a text/vcard body part MUST have a VERSION property with value in a text/vcard body part MUST have a VERSION property with value
identical to that of this MIME parameter. identical to that of this MIME parameter.
"charset": as defined for text/plain [RFC2046]; encodings other "charset": as defined for text/plain [RFC2046]; encodings other
than UTF-8 [RFC3629] MUST NOT be used. than UTF-8 [RFC3629] MUST NOT be used.
Encoding considerations: None. Encoding considerations: 8bit
Security considerations: See Section 9. Security considerations: See Section 9.
Interoperability considerations: The text/vcard media type is Interoperability considerations: The text/vcard media type is
intended to identify vCard data of any version. There are older intended to identify vCard data of any version. There are older
specifications of vCard [RFC2426][oldreference_VCARD] still in specifications of vCard [RFC2426][vCard21] still in common use.
common use. While these formats are similar, they are not While these formats are similar, they are not strictly compatible.
strictly compatible. In general, it is necessary to inspect the
value of the VERSION property (see Section 6.7.9) for identifying In general, it is necessary to inspect the value of the VERSION
the standard to which a given vCard object conforms. property (see Section 6.7.9) for identifying the standard to which
a given vCard object conforms.
In addition, the following media types are known to have been used In addition, the following media types are known to have been used
to refer to vCard data. They should be considered deprecated in to refer to vCard data. They should be considered deprecated in
favor of text/vcard. favor of text/vcard.
* text/directory * text/directory
* text/directory; profile=vcard * text/directory; profile=vcard
* text/x-vcard * text/x-vcard
Published specification: draft-ietf-vcarddav-vcardrev-15 Published specification: draft-ietf-vcarddav-vcardrev-17
Applications that use this media type: They are numerous, diverse, Applications that use this media type: They are numerous, diverse,
and include mail user agents, instant messaging clients, address and include mail user agents, instant messaging clients, address
book applications, directory servers, customer relationship book applications, directory servers, customer relationship
management software. management software.
Additional information: Additional information:
Magic number(s): Magic number(s):
File extension(s): .vcf File extension(s): .vcf .vcard
Macintosh file type code(s): Macintosh file type code(s):
Person & email address to contact for further information: Simon Person & email address to contact for further information: Simon
Perreault <simon.perreault@viagenie.ca> Perreault <simon.perreault@viagenie.ca>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
skipping to change at page 59, line 39 skipping to change at page 61, line 39
They follow the normal appeals procedure for IESG decisions. They follow the normal appeals procedure for IESG decisions.
Once the registration procedure concludes successfully, IANA creates Once the registration procedure concludes successfully, IANA creates
or modifies the corresponding record in the vCard registry. The or modifies the corresponding record in the vCard registry. The
completed registration template is discarded. completed registration template is discarded.
An RFC specifying new vCard elements MUST include the completed An RFC specifying new vCard elements MUST include the completed
registration templates, which MAY be expanded with additional registration templates, which MAY be expanded with additional
information. These completed templates will go in the body of the information. These completed templates will go in the body of the
document, and SHOULD NOT be included or repeated in the IANA document, and SHOULD NOT be included or repeated in the IANA
Considerations section. The IANA Considerations section MUST contain Considerations section.
tables (see the tables in section Section 10.3) that show exactly the
changes that IANA is requested to make to the registries. The Finally, note that there is an XML representation for vCard defined
registry's reference column MUST point to the section in the RFC in [I-D.ietf-vcarddav-vcardxml]. An XML representation SHOULD be
containing to the completed the registration template. defined for new vCard objects.
10.2.2. Vendor Namespace 10.2.2. Vendor Namespace
The vendor namespace is used for vCard elements associated with The vendor namespace is used for vCard elements associated with
commercially available products. "Vendor" or "producer" are commercially available products. "Vendor" or "producer" are
construed as equivalent and very broadly in this context. construed as equivalent and very broadly in this context.
A registration may be placed in the vendor namespace by anyone who A registration may be placed in the vendor namespace by anyone who
needs to interchange files associated with the particular product. needs to interchange files associated with the particular product.
skipping to change at page 62, line 19 skipping to change at page 64, line 19
this value needs to be specified. this value needs to be specified.
Example(s): One or more examples of instances of the value needs to Example(s): One or more examples of instances of the value needs to
be specified. be specified.
The following is a fictitious example of a registration of a vCard The following is a fictitious example of a registration of a vCard
value: value:
Value: supervisor Value: supervisor
Purpose: It means that the related individual is the direct Purpose: It means that the related entity is the direct hierarchical
hierarchical superior (i.e. supervisor or manager) of the superior (i.e. supervisor or manager) of the entity this vCard
individual this vCard represents. represents.
Conformance: This value can be used with the "TYPE" parameter Conformance: This value can be used with the "TYPE" parameter
applied on the "RELATED" property. applied on the "RELATED" property.
Example(s): Example(s):
RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
10.3. Initial vCard Elements Registries 10.3. Initial vCard Elements Registries
The IANA is requested to create and maintain the following registries The IANA is requested to create and maintain the following registries
for vCard elements with pointers to appropriate reference documents. for vCard elements with pointers to appropriate reference documents.
The registries will be grouped together under the heading "vCard The registries will be grouped together under the heading "vCard
Elements". Elements".
10.3.1. Properties Registry 10.3.1. Properties Registry
The following table is to be used to initialize the properties The following table is to be used to initialize the properties
registry. registry.
+-----------+--------------+---------+------------------------+ +-----------+--------------+------------------------+
| Namespace | Property | Status | Reference | | Namespace | Property | Reference |
+-----------+--------------+---------+------------------------+ +-----------+--------------+------------------------+
| | SOURCE | Current | RFCXXXX, Section 6.1.3 | | | SOURCE | RFCXXXX, Section 6.1.3 |
| | KIND | Current | RFCXXXX, Section 6.1.4 | | | KIND | RFCXXXX, Section 6.1.4 |
| | XML | Current | RFCXXXX, Section 6.1.5 | | | XML | RFCXXXX, Section 6.1.5 |
| | FN | Current | RFCXXXX, Section 6.2.1 | | | FN | RFCXXXX, Section 6.2.1 |
| | N | Current | RFCXXXX, Section 6.2.2 | | | N | RFCXXXX, Section 6.2.2 |
| | NICKNAME | Current | RFCXXXX, Section 6.2.3 | | | NICKNAME | RFCXXXX, Section 6.2.3 |
| | PHOTO | Current | RFCXXXX, Section 6.2.4 | | | PHOTO | RFCXXXX, Section 6.2.4 |
| | BDAY | Current | RFCXXXX, Section 6.2.5 | | | BDAY | RFCXXXX, Section 6.2.5 |
| | ANNIVERSARY | Current | RFCXXXX, Section 6.2.6 | | | ANNIVERSARY | RFCXXXX, Section 6.2.6 |
| | GENDER | Current | RFCXXXX, Section 6.2.7 | | | GENDER | RFCXXXX, Section 6.2.7 |
| | ADR | Current | RFCXXXX, Section 6.3.1 | | | ADR | RFCXXXX, Section 6.3.1 |
| | TEL | Current | RFCXXXX, Section 6.4.1 | | | TEL | RFCXXXX, Section 6.4.1 |
| | EMAIL | Current | RFCXXXX, Section 6.4.2 | | | EMAIL | RFCXXXX, Section 6.4.2 |
| | IMPP | Current | RFCXXXX, Section 6.4.3 | | | IMPP | RFCXXXX, Section 6.4.3 |
| | LANG | Current | RFCXXXX, Section 6.4.4 | | | LANG | RFCXXXX, Section 6.4.4 |
| | TZ | Current | RFCXXXX, Section 6.5.1 | | | TZ | RFCXXXX, Section 6.5.1 |
| | GEO | Current | RFCXXXX, Section 6.5.2 | | | GEO | RFCXXXX, Section 6.5.2 |
| | TITLE | Current | RFCXXXX, Section 6.6.1 | | | TITLE | RFCXXXX, Section 6.6.1 |
| | ROLE | Current | RFCXXXX, Section 6.6.2 | | | ROLE | RFCXXXX, Section 6.6.2 |
| | LOGO | Current | RFCXXXX, Section 6.6.3 | | | LOGO | RFCXXXX, Section 6.6.3 |
| | ORG | Current | RFCXXXX, Section 6.6.4 | | | ORG | RFCXXXX, Section 6.6.4 |
| | MEMBER | Current | RFCXXXX, Section 6.6.5 | | | MEMBER | RFCXXXX, Section 6.6.5 |
| | RELATED | Current | RFCXXXX, Section 6.6.6 | | | RELATED | RFCXXXX, Section 6.6.6 |
| | CATEGORIES | Current | RFCXXXX, Section 6.7.1 | | | CATEGORIES | RFCXXXX, Section 6.7.1 |
| | NOTE | Current | RFCXXXX, Section 6.7.2 | | | NOTE | RFCXXXX, Section 6.7.2 |
| | PRODID | Current | RFCXXXX, Section 6.7.3 | | | PRODID | RFCXXXX, Section 6.7.3 |
| | REV | Current | RFCXXXX, Section 6.7.4 | | | REV | RFCXXXX, Section 6.7.4 |
| | SOUND | Current | RFCXXXX, Section 6.7.5 | | | SOUND | RFCXXXX, Section 6.7.5 |
| | UID | Current | RFCXXXX, Section 6.7.6 | | | UID | RFCXXXX, Section 6.7.6 |
| | CLIENTPIDMAP | Current | RFCXXXX, Section 6.7.7 | | | CLIENTPIDMAP | RFCXXXX, Section 6.7.7 |
| | URL | Current | RFCXXXX, Section 6.7.8 | | | URL | RFCXXXX, Section 6.7.8 |
| | VERSION | Current | RFCXXXX, Section 6.7.9 | | | VERSION | RFCXXXX, Section 6.7.9 |
| | KEY | Current | RFCXXXX, Section 6.8.1 | | | KEY | RFCXXXX, Section 6.8.1 |
| | FBURL | Current | RFCXXXX, Section 6.9.1 | | | FBURL | RFCXXXX, Section 6.9.1 |
| | CALADRURI | Current | RFCXXXX, Section 6.9.2 | | | CALADRURI | RFCXXXX, Section 6.9.2 |
| | CALURI | Current | RFCXXXX, Section 6.9.3 | | | CALURI | RFCXXXX, Section 6.9.3 |
+-----------+--------------+---------+------------------------+ +-----------+--------------+------------------------+
10.3.2. Parameters Registry 10.3.2. Parameters Registry
The following table is to be used to initialize the parameters The following table is to be used to initialize the parameters
registry. registry.
+-----------+-----------+---------+-----------------------+ +-----------+-----------+-----------------------+
| Namespace | Parameter | Status | Reference | | Namespace | Parameter | Reference |
+-----------+-----------+---------+-----------------------+ +-----------+-----------+-----------------------+
| | LANGUAGE | Current | RFCXXXX, Section 5.1 | | | LANGUAGE | RFCXXXX, Section 5.1 |
| | VALUE | Current | RFCXXXX, Section 5.2 | | | VALUE | RFCXXXX, Section 5.2 |
| | PREF | Current | RFCXXXX, Section 5.3 | | | PREF | RFCXXXX, Section 5.3 |
| | ALTID | Current | RFCXXXX, Section 5.4 | | | ALTID | RFCXXXX, Section 5.4 |
| | PID | Current | RFCXXXX, Section 5.5 | | | PID | RFCXXXX, Section 5.5 |
| | TYPE | Current | RFCXXXX, Section 5.6 | | | TYPE | RFCXXXX, Section 5.6 |
| | CALSCALE | Current | RFCXXXX, Section 5.7 | | | MEDIATYPE | RFCXXXX, Section 5.7 |
| | SORT-AS | Current | RFCXXXX, Section 5.8 | | | CALSCALE | RFCXXXX, Section 5.8 |
| | GEO | Current | RFCXXXX, Section 5.9 | | | SORT-AS | RFCXXXX, Section 5.9 |
| | TZ | Current | RFCXXXX, Section 5.10 | | | GEO | RFCXXXX, Section 5.10 |
+-----------+-----------+---------+-----------------------+ | | TZ | RFCXXXX, Section 5.11 |
+-----------+-----------+-----------------------+
10.3.3. Value Data Types Registry 10.3.3. Value Data Types Registry
The following table is to be used to initialize the parameters The following table is to be used to initialize the parameters
registry. registry.
+------------------+---------+------------------------+ +------------------+------------------------+
| Value Data Type | Status | Reference | | Value Data Type | Reference |
+------------------+---------+------------------------+ +------------------+------------------------+
| BOOLEAN | Current | RFCXXXX, Section 4.4 | | BOOLEAN | RFCXXXX, Section 4.4 |
| DATE | Current | RFCXXXX, Section 4.3.1 | | DATE | RFCXXXX, Section 4.3.1 |
| TIME | Current | RFCXXXX, Section 4.3.2 | | TIME | RFCXXXX, Section 4.3.2 |
| DATE-TIME | Current | RFCXXXX, Section 4.3.3 | | DATE-TIME | RFCXXXX, Section 4.3.3 |
| DATE-AND-OR-TIME | Current | RFCXXXX, Section 4.3.4 | | DATE-AND-OR-TIME | RFCXXXX, Section 4.3.4 |
| TIMESTAMP | Current | RFCXXXX, Section 4.3.5 | | TIMESTAMP | RFCXXXX, Section 4.3.5 |
| FLOAT | Current | RFCXXXX, Section 4.6 | | FLOAT | RFCXXXX, Section 4.6 |
| INTEGER | Current | RFCXXXX, Section 4.5 | | INTEGER | RFCXXXX, Section 4.5 |
| TEXT | Current | RFCXXXX, Section 4.1 | | TEXT | RFCXXXX, Section 4.1 |
| URI | Current | RFCXXXX, Section 4.2 | | URI | RFCXXXX, Section 4.2 |
| LANGUAGE-TAG | Current | RFCXXXX, Section 4.7 | | LANGUAGE-TAG | RFCXXXX, Section 4.7 |
+------------------+---------+------------------------+ +------------------+------------------------+
10.3.4. Values Registries 10.3.4. Values Registries
Separate tables will be used for property and parameter values. Separate tables will be used for property and parameter values.
The following table is to be used to initialize the property values The following table is to be used to initialize the property values
registry. registry.
+----------+------------+---------+------------------------+ +----------+------------+------------------------+
| Property | Value | Status | Reference | | Property | Value | Reference |
+----------+------------+---------+------------------------+ +----------+------------+------------------------+
| BEGIN | VCARD | Current | RFCXXXX, Section 6.1.1 | | BEGIN | VCARD | RFCXXXX, Section 6.1.1 |
| END | VCARD | Current | RFCXXXX, Section 6.1.2 | | END | VCARD | RFCXXXX, Section 6.1.2 |
| KIND | individual | Current | RFCXXXX, Section 6.1.4 | | KIND | individual | RFCXXXX, Section 6.1.4 |
| KIND | group | Current | RFCXXXX, Section 6.1.4 | | KIND | group | RFCXXXX, Section 6.1.4 |
| KIND | org | Current | RFCXXXX, Section 6.1.4 | | KIND | org | RFCXXXX, Section 6.1.4 |
| KIND | location | Current | RFCXXXX, Section 6.1.4 | | KIND | location | RFCXXXX, Section 6.1.4 |
+----------+------------+---------+------------------------+ +----------+------------+------------------------+
The following table is to be used to initialize the parameter values The following table is to be used to initialize the parameter values
registry. registry.
+--------------+-----------+--------------+---------+---------------+ +------------------------+-----------+--------------+---------------+
| Property | Parameter | Value | Status | Reference | | Property | Parameter | Value | Reference |
+--------------+-----------+--------------+---------+---------------+ +------------------------+-----------+--------------+---------------+
| FN, | TYPE | work | Current | RFCXXXX, | | FN, NICKNAME, PHOTO, | TYPE | work | RFCXXXX, |
| NICKNAME, | | | | Section 5.6 | | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
| PHOTO, ADR, | | | | | | LANG, TZ, GEO, TITLE, | | | |
| TEL, EMAIL, | | | | | | ROLE, LOGO, ORG, | | | |
| IMPP, LANG, | | | | | | RELATED, CATEGORIES, | | | |
| TZ, GEO, | | | | | | NOTE, SOUND, URL, KEY, | | | |
| TITLE, ROLE, | | | | | | FBURL, CALADRURI, and | | | |
| LOGO, ORG, | | | | | | CALURI | | | |
| RELATED, | | | | | | FN, NICKNAME, PHOTO, | TYPE | home | RFCXXXX, |
| CATEGORIES, | | | | | | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
| NOTE, SOUND, | | | | | | LANG, TZ, GEO, TITLE, | | | |
| URL, KEY, | | | | | | ROLE, LOGO, ORG, | | | |
| FBURL, | | | | | | RELATED, CATEGORIES, | | | |
| CALADRURI, | | | | | | NOTE, SOUND, URL, KEY, | | | |
| and CALURI | | | | | | FBURL, CALADRURI, and | | | |
| FN, | TYPE | home | Current | RFCXXXX, | | CALURI | | | |
| NICKNAME, | | | | Section 5.6 | | TEL | TYPE | text | RFCXXXX, |
| PHOTO, ADR, | | | | | | | | | Section 6.4.1 |
| TEL, EMAIL, | | | | | | TEL | TYPE | voice | RFCXXXX, |
| IMPP, LANG, | | | | | | | | | Section 6.4.1 |
| TZ, GEO, | | | | | | TEL | TYPE | fax | RFCXXXX, |
| TITLE, ROLE, | | | | | | | | | Section 6.4.1 |
| LOGO, ORG, | | | | | | TEL | TYPE | cell | RFCXXXX, |
| RELATED, | | | | | | | | | Section 6.4.1 |
| CATEGORIES, | | | | | | TEL | TYPE | video | RFCXXXX, |
| NOTE, SOUND, | | | | | | | | | Section 6.4.1 |
| URL, KEY, | | | | | | TEL | TYPE | pager | RFCXXXX, |
| FBURL, | | | | | | | | | Section 6.4.1 |
| CALADRURI, | | | | | | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFCXXXX, |
| and CALURI | | | | | | | | | Section 6.2.5 |
| TEL | TYPE | text | Current | RFCXXXX, | | RELATED | TYPE | contact | RFCXXXX, |
| | | | | Section 6.4.1 | | | | | Section 6.6.6 |
| TEL | TYPE | voice | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.4.1 | | RELATED | TYPE | acquaintance | RFCXXXX, |
| TEL | TYPE | fax | Current | RFCXXXX, | | | | | Section 6.6.6 |
| | | | | Section 6.4.1 | | | | | and [xfn] |
| TEL | TYPE | cell | Current | RFCXXXX, | | RELATED | TYPE | friend | RFCXXXX, |
| | | | | Section 6.4.1 | | | | | Section 6.6.6 |
| TEL | TYPE | video | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.4.1 | | RELATED | TYPE | met | RFCXXXX, |
| TEL | TYPE | pager | Current | RFCXXXX, | | | | | Section 6.6.6 |
| | | | | Section 6.4.1 | | | | | and [xfn] |
| BDAY, | CALSCALE | gregorian | Current | RFCXXXX, | | RELATED | TYPE | co-worker | RFCXXXX, |
| ANNIVERSARY | | | | Section 6.2.5 | | | | | Section 6.6.6 |
| RELATED | TYPE | contact | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | colleague | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | acquaintance | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | co-resident | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | friend | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | neighbor | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | met | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | child | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | co-worker | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | parent | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | colleague | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | sibling | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | co-resident | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | spouse | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | neighbor | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | kin | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | child | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | muse | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | parent | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | crush | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | sibling | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | date | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | spouse | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | sweetheart | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | kin | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | me | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | muse | Current | RFCXXXX, | | | | | and [xfn] |
| | | | | Section 6.6.6 | | RELATED | TYPE | agent | RFCXXXX, |
| | | | | and [xfn] | | | | | Section 6.6.6 |
| RELATED | TYPE | crush | Current | RFCXXXX, | | RELATED | TYPE | emergency | RFCXXXX, |
| | | | | Section 6.6.6 | | | | | Section 6.6.6 |
| | | | | and [xfn] | +------------------------+-----------+--------------+---------------+
| RELATED | TYPE | date | Current | RFCXXXX, |
| | | | | Section 6.6.6 |
| | | | | and [xfn] |
| RELATED | TYPE | sweetheart | Current | RFCXXXX, |
| | | | | Section 6.6.6 |
| | | | | and [xfn] |
| RELATED | TYPE | me | Current | RFCXXXX, |
| | | | | Section 6.6.6 |
| | | | | and [xfn] |
| RELATED | TYPE | agent | Current | RFCXXXX, |
| | | | | Section 6.6.6 |
| RELATED | TYPE | emergency | Current | RFCXXXX, |
| | | | | Section 6.6.6 |
+--------------+-----------+--------------+---------+---------------+
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Tim Howes, Mark Smith, and Frank The authors would like to thank Tim Howes, Mark Smith, and Frank
Dawson, the original authors of [RFC2425] and [RFC2426], Pete Dawson, the original authors of [RFC2425] and [RFC2426], Pete
Resnick, who got this effort started and provided help along the way, Resnick, who got this effort started and provided help along the way,
as well as the following individuals who have participated in the as well as the following individuals who have participated in the
drafting, review and discussion of this memo: drafting, review and discussion of this memo:
Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil
skipping to change at page 68, line 39 skipping to change at page 70, line 23
[CCITT.X521.1988] International International Telephone [CCITT.X521.1988] International International Telephone
and Telegraph Consultative Committee, and Telegraph Consultative Committee,
"Information Technology - Open Systems "Information Technology - Open Systems
Interconnection - The Directory: Interconnection - The Directory:
Selected Object Classes", Selected Object Classes",
CCITT Recommendation X.521, CCITT Recommendation X.521,
November 1988. November 1988.
[I-D.ietf-vcarddav-vcardxml] Perreault, S., "vCard XML [I-D.ietf-vcarddav-vcardxml] Perreault, S., "vCard XML
Representation", Representation",
draft-ietf-vcarddav-vcardxml-06 (work draft-ietf-vcarddav-vcardxml-08 (work
in progress), December 2010. in progress), April 2011.
[ISO.8601.2000] International Organization for [ISO.8601.2000] International Organization for
Standardization, "Data elements and Standardization, "Data elements and
interchange formats - Information interchange formats - Information
interchange - Representation of dates interchange - Representation of dates
and times", ISO Standard 8601, and times", ISO Standard 8601,
December 2000. December 2000.
[ISO.8601.2004] International Organization for [ISO.8601.2004] International Organization for
Standardization, "Data elements and Standardization, "Data elements and
interchange formats - Information interchange formats - Information
interchange - Representation of dates interchange - Representation of dates
and times", ISO Standard 8601, and times", ISO Standard 8601,
December 2004. December 2004.
[RFC1738] Berners-Lee, T., Masinter, L., and M.
McCahill, "Uniform Resource Locators
(URL)", RFC 1738, December 1994.
[RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet
Message Bodies", RFC 2045,
November 1996.
[RFC2046] Freed, N. and N. Borenstein, [RFC2046] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", (MIME) Part Two: Media Types",
RFC 2046, November 1996. RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997. BCP 14, RFC 2119, March 1997.
[RFC2425] Howes, T., Smith, M., and F. Dawson, "A
MIME Content-Type for Directory
Information", RFC 2425, September 1998.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME
Directory Profile", RFC 2426,
September 1998.
[RFC2739] Small, T., Hennessy, D., and F. Dawson, [RFC2739] Small, T., Hennessy, D., and F. Dawson,
"Calendar Attributes for vCard and "Calendar Attributes for vCard and
LDAP", RFC 2739, January 2000. LDAP", RFC 2739, January 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC3629] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63, RFC 3629, format of ISO 10646", STD 63, RFC 3629,
November 2003. November 2003.
[RFC3966] Schulzrinne, H., "The tel URI for [RFC3966] Schulzrinne, H., "The tel URI for
Telephone Numbers", RFC 3966, Telephone Numbers", RFC 3966,
skipping to change at page 69, line 45 skipping to change at page 71, line 31
[RFC3986] Berners-Lee, T., Fielding, R., and L. [RFC3986] Berners-Lee, T., Fielding, R., and L.
Masinter, "Uniform Resource Identifier Masinter, "Uniform Resource Identifier
(URI): Generic Syntax", STD 66, (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, [RFC4122] Leach, P., Mealling, M., and R. Salz,
"A Universally Unique IDentifier (UUID) "A Universally Unique IDentifier (UUID)
URN Namespace", RFC 4122, July 2005. URN Namespace", RFC 4122, July 2005.
[RFC4770] Jennings, C. and J. Reschke, Ed.,
"vCard Extensions for Instant Messaging
(IM)", RFC 4770, January 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented [RFC5234] Crocker, D. and P. Overell, "Augmented
BNF for Syntax Specifications: ABNF", BNF for Syntax Specifications: ABNF",
STD 68, RFC 5234, January 2008. STD 68, RFC 5234, January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message [RFC5322] Resnick, P., Ed., "Internet Message
Format", RFC 5322, October 2008. Format", RFC 5322, October 2008.
[RFC5545] Desruisseaux, B., "Internet Calendaring
and Scheduling Core Object
Specification (iCalendar)", RFC 5545,
September 2009.
[RFC5546] Daboo, C., "iCalendar Transport-
Independent Interoperability Protocol
(iTIP)", RFC 5546, December 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for [RFC5646] Phillips, A. and M. Davis, "Tags for
Identifying Languages", BCP 47, Identifying Languages", BCP 47,
RFC 5646, September 2009. RFC 5646, September 2009.
[RFC5870] Mayrhofer, A. and C. Spanring, "A [RFC5870] Mayrhofer, A. and C. Spanring, "A
Uniform Resource Identifier for Uniform Resource Identifier for
Geographic Locations ('geo' URI)", Geographic Locations ('geo' URI)",
RFC 5870, June 2010. RFC 5870, June 2010.
[oldreference_VCARD] Internet Mail Consortium, "vCard - The [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J.,
Electronic Business Card Version 2.1", Sperberg-McQueen, C., and T. Bray,
September September. "Extensible Markup Language (XML) 1.0
(Fifth Edition)", World Wide Web
Consortium Recommendation REC-xml-
20081126, November 2008, <http://
www.w3.org/TR/2008/REC-xml-20081126>.
[xfn] Celik, T., Mullenweg, M., and E. Meyer, [xfn] Celik, T., Mullenweg, M., and E. Meyer,
"XHTML Friends Network 1.1", "XHTML Friends Network 1.1",
<http://gmpg.org/xfn/11>. <http://gmpg.org/xfn/11>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., Crocker, D., and [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele,
N. Freed, "Internationalized Email "Internationalized Email Headers",
Headers", draft-ietf-eai-rfc5335bis-09 draft-ietf-eai-rfc5335bis-10 (work in
(work in progress), March 2011. progress), March 2011.
[ISO9070] The International Organization for [ISO9070] The International Organization for
Standardization, "ISO 9070, Information Standardization, "ISO 9070, Information
Processing - SGML support facilities - Processing - SGML support facilities -
Registration Procedures for Public Text Registration Procedures for Public Text
Owner Identifiers", April 1991. Owner Identifiers", April 1991.
[RFC2397] Masinter, L., "The "data" URL scheme",
RFC 2397, August 1998.
[RFC2425] Howes, T., Smith, M., and F. Dawson, "A
MIME Content-Type for Directory
Information", RFC 2425, September 1998.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME
Directory Profile", RFC 2426,
September 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., [RFC2616] Fielding, R., Gettys, J., Mogul, J.,
Frystyk, H., Masinter, L., Leach, P., Frystyk, H., Masinter, L., Leach, P.,
and T. Berners-Lee, "Hypertext Transfer and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, Protocol -- HTTP/1.1", RFC 2616,
June 1999. June 1999.
[RFC3282] Alvestrand, H., "Content Language
Headers", RFC 3282, May 2002.
[RFC3406] Daigle, L., van Gulik, D., Iannella, [RFC3406] Daigle, L., van Gulik, D., Iannella,
R., and P. Faltstrom, "Uniform Resource R., and P. Faltstrom, "Uniform Resource
Names (URN) Namespace Definition Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, Mechanisms", BCP 66, RFC 3406,
October 2002. October 2002.
[RFC5545] Desruisseaux, B., "Internet Calendaring [RFC4770] Jennings, C. and J. Reschke, Ed.,
and Scheduling Core Object "vCard Extensions for Instant Messaging
Specification (iCalendar)", RFC 5545, (IM)", RFC 4770, January 2007.
September 2009.
[RFC5546] Daboo, C., "iCalendar Transport- [RFC4880] Callas, J., Donnerhacke, L., Finney,
Independent Interoperability Protocol H., Shaw, D., and R. Thayer, "OpenPGP
(iTIP)", RFC 5546, December 2009. Message Format", RFC 4880,
November 2007.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/
Multipurpose Internet Mail Extensions
(S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC6068] Duerst, M., Masinter, L., and J.
Zawinski, "The 'mailto' URI Scheme",
RFC 6068, October 2010.
[TZ-DB] Olson, A., "Time zone code and data", [TZ-DB] Olson, A., "Time zone code and data",
<ftp://elsie.nci.nih.gov/pub/>. <ftp://elsie.nci.nih.gov/pub/>.
[vCard21] Internet Mail Consortium, "vCard - The
Electronic Business Card Version 2.1",
September September.
URIs URIs
[1] <mailto:vcard@ietf.org> [1] <mailto:vcard@ietf.org>
[2] <mailto:iana@iana.org> [2] <mailto:iana@iana.org>
Appendix A. Differences from RFCs 2425 and 2426 Appendix A. Differences from RFCs 2425 and 2426
This appendix contains a list of changes that have been made in the This appendix contains a list of changes that have been made in the
vCard specification from RFCs 2425 and 2426. vCard specification from RFCs 2425 and 2426.
skipping to change at page 72, line 40 skipping to change at page 75, line 15
o The value of TEL is now a URI. o The value of TEL is now a URI.
o The AGENT property was replaced with a type of RELATED. o The AGENT property was replaced with a type of RELATED.
o Date and time values now only support the basic format. o Date and time values now only support the basic format.
Truncation is now supported. Truncation is now supported.
Appendix B. Change Log (to be removed by RFC Editor prior to Appendix B. Change Log (to be removed by RFC Editor prior to
publication) publication)
B.1. Changes in -16 B.1. Changes in -17
o s/individual/entity/
o Moved section 3.4 for better flow.
o Removed text overriding general MIME and HTTP rules.
o Fixed redundant ABNF.
o Fixed parameter value quoting in examples.
o Added informative reference for Content-Language header.
o Moved cardinality table earlier for better flow.
o Added normative reference for XML 1.0.
o Added informative reference for mailto: scheme.
o Clarified where the VERSION property must go.
o Created the MEDIATYPE parameter.
o Fixed text/vcard encoding considerations.
o Added .vcard file extension.
o Removed need for extension documents to contain tables in their
IANA Considerations section.
o Removed underspecified "Status" column in IANA registry.
o Moved obsoleted references to Informative section.
o Moved iCalendar references to Normative section.
o Expanded specification of KIND values.
o Recommend defining an XML representation for new vCard objects.
B.2. Changes in -16
o RELATED: Added XFN values into IANA registry. o RELATED: Added XFN values into IANA registry.
o RELATED: Added values "agent" and "emergency". o RELATED: Added values "agent" and "emergency".
o EMAIL is now free-form text, with informative reference to EAI. o EMAIL is now free-form text, with informative reference to EAI.
o GENDER now has two components: one for biological sex, the other o GENDER now has two components: one for biological sex, the other
for gender identity. for gender identity.
o Bugfixes to the core ABNF. o Bugfixes to the core ABNF.
o Clarified IANA considerations. o Clarified IANA considerations.
o UID may be reset to free-form text. o UID may be reset to free-form text.
B.2. Changes in -15 B.3. Changes in -15
o Reverted N to the 5-component format of vCard 3. o Reverted N to the 5-component format of vCard 3.
o Removed DDAY, BIRTH, and DEATH. o Removed DDAY, BIRTH, and DEATH.
o First two components in ADR SHOULD be empty. o First two components in ADR SHOULD be empty.
o Removed the LABEL property. o Removed the LABEL property.
o Removed the binary value type and the ENCODING and FMTTYPE o Removed the binary value type and the ENCODING and FMTTYPE
skipping to change at page 73, line 42 skipping to change at page 77, line 11
o RELATED now uses XFN 1.1 for its value. o RELATED now uses XFN 1.1 for its value.
o Dropped the VERSION parameter. XML MUST be version 1.0. o Dropped the VERSION parameter. XML MUST be version 1.0.
o Dropped the CLASS property. o Dropped the CLASS property.
o Property and parameter names SHOULD be upper-case. o Property and parameter names SHOULD be upper-case.
o Use ABNF for cardinality notation. o Use ABNF for cardinality notation.
B.3. Changes in -14 B.4. Changes in -14
o DQUOTE is US-ASCII decimal 34, not 22. o DQUOTE is US-ASCII decimal 34, not 22.
o Removed unused reference to RFC 2046. o Removed unused reference to RFC 2046.
o Updated reference to draft-ietf-vcarddav-vcardxml. o Updated reference to draft-ietf-vcarddav-vcardxml.
o Small fixes to the IANA registration text. o Small fixes to the IANA registration text.
o Added notes on the usage of TEL and IMPP properties. o Added notes on the usage of TEL and IMPP properties.
skipping to change at page 74, line 29 skipping to change at page 77, line 45
o Removed advice for always including VALUE parameter. o Removed advice for always including VALUE parameter.
o FMTTYPE MUST include the full MIME type. o FMTTYPE MUST include the full MIME type.
o Made ADR's ABNF more verbose. o Made ADR's ABNF more verbose.
o Organized TEL TYPE values in a table. o Organized TEL TYPE values in a table.
o Replaced TOP-SECRET example with NOINDEX. o Replaced TOP-SECRET example with NOINDEX.
B.4. Changes in -13 B.5. Changes in -13
o Changed global ABNF to make explicit that VERSION comes first. o Changed global ABNF to make explicit that VERSION comes first.
o Reworked example for LANGUAGE property. o Reworked example for LANGUAGE property.
o s/TYPE/FMTTYPE/ in two examples. o s/TYPE/FMTTYPE/ in two examples.
o Allow LANGUAGE parameter for text-valued BDAY, DDAY, and RELATED. o Allow LANGUAGE parameter for text-valued BDAY, DDAY, and RELATED.
o Tightened language on LANGUAGE parameter regarding cardinality. o Tightened language on LANGUAGE parameter regarding cardinality.
o Removed the NAME property. o Removed the NAME property.
o Adjusted semi-colon escaping rules. o Adjusted semi-colon escaping rules.
o Added the ALTID parameter. o Added the ALTID parameter.
B.5. Changes in -12 B.6. Changes in -12
o Fixed example of LANGUAGE cardinality. o Fixed example of LANGUAGE cardinality.
o Added note about YYYY-MM date format. o Added note about YYYY-MM date format.
o Fixed appendix A. o Fixed appendix A.
o VERSION property must come first. o VERSION property must come first.
o Fixed mistake in PID example. o Fixed mistake in PID example.
skipping to change at page 76, line 5 skipping to change at page 79, line 19
o BIRTH and DEATH can now have URI values. o BIRTH and DEATH can now have URI values.
o Created the FMTTYPE parameter. o Created the FMTTYPE parameter.
o KEY can now take a text value. o KEY can now take a text value.
o Added references to RFC 5545 (iCalendar). o Added references to RFC 5545 (iCalendar).
o Added namespace column in parameters registry. o Added namespace column in parameters registry.
B.6. Changes in -11 B.7. Changes in -11
o Change "XML chunk" to "XML fragment". o Change "XML chunk" to "XML fragment".
o Cite W3C document containing definition of "fragment". o Cite W3C document containing definition of "fragment".
o Added "XML" to property name ABNF. o Added "XML" to property name ABNF.
o Clarified newline escaping rule. o Clarified newline escaping rule.
o Replaced one remaining "type" with "property". o Replaced one remaining "type" with "property".
skipping to change at page 76, line 29 skipping to change at page 79, line 43
o XML property can now only contain one element that is not in the o XML property can now only contain one element that is not in the
vCard 4 namespace. vCard 4 namespace.
o Clarified interrelationship between LANGUAGE, cardinality, and o Clarified interrelationship between LANGUAGE, cardinality, and
PID. PID.
o Added "textphone" TEL type. o Added "textphone" TEL type.
o Fixed quoting of comma in ORG examples. o Fixed quoting of comma in ORG examples.
B.7. Changes in -10 B.8. Changes in -10
o Added component in SORT-STRING for sorting by given name. Fixed o Added component in SORT-STRING for sorting by given name. Fixed
and expanded the examples. and expanded the examples.
o Fixed KIND-value ABNF. o Fixed KIND-value ABNF.
o Fixed deprecated media type. o Fixed deprecated media type.
o Created the CALSCALE parameter. o Created the CALSCALE parameter.
o Strenghtened the stance on character set. o Strenghtened the stance on character set.
o Defined the Language-Tag ABNF. o Defined the Language-Tag ABNF.
o Made explicit the fact that IANA does not register templates. o Made explicit the fact that IANA does not register templates.
o Created the XML property. o Created the XML property.
o Added social networking examples to URL property. o Added social networking examples to URL property.
B.8. Changes in -09 B.9. Changes in -09
o Removed special meaning for groups. Removed the "work" and "home" o Removed special meaning for groups. Removed the "work" and "home"
groups. Removed the group registry. Re-introduced the "work" and groups. Removed the group registry. Re-introduced the "work" and
"home" TYPE parameter values. Applied the TYPE parameter to "home" TYPE parameter values. Applied the TYPE parameter to
properties which supported the "work" and "home" groups. properties which supported the "work" and "home" groups.
o Vendor namespace now uses private enterprise number in prefix. o Vendor namespace now uses private enterprise number in prefix.
o Added "thing" value for KIND property. o Added "thing" value for KIND property.
B.9. Changes in -08 B.10. Changes in -08
o Allow 1985 (year only) in date ABNF. o Allow 1985 (year only) in date ABNF.
o Fixed missing country in ADR example. o Fixed missing country in ADR example.
o Added the DATE-AND-OR-TIME value. o Added the DATE-AND-OR-TIME value.
o Made BDAY and DDAY use DATE-AND-OR-TIME. o Made BDAY and DDAY use DATE-AND-OR-TIME.
o Prefixed "param" and "value" production rules specific to o Prefixed "param" and "value" production rules specific to
skipping to change at page 77, line 39 skipping to change at page 81, line 5
o Replaced the GENDER property with the SEX property. o Replaced the GENDER property with the SEX property.
o Added the ANNIVERSARY property. o Added the ANNIVERSARY property.
o Added the "friend" and "spouse" types of RELATED. o Added the "friend" and "spouse" types of RELATED.
o TZ property now has text / uri value. o TZ property now has text / uri value.
o Refined the definitions of TITLE and ROLE. o Refined the definitions of TITLE and ROLE.
B.10. Changes in -07 B.11. Changes in -07
o PREF is now bounded. 100 is the maximum value. o PREF is now bounded. 100 is the maximum value.
o Added the "emergency" RELATED type. o Added the "emergency" RELATED type.
o Made GEO a URI. o Made GEO a URI.
o Added GEO and TZ parameters to ADR. o Added GEO and TZ parameters to ADR.
o Changed wording of "default" use of SOUND property. o Changed wording of "default" use of SOUND property.
skipping to change at page 78, line 13 skipping to change at page 81, line 27
o Completely reworked the date, time, and date-time grammars. o Completely reworked the date, time, and date-time grammars.
o Added the timestamp value type. o Added the timestamp value type.
o REV now has the timestamp value type. o REV now has the timestamp value type.
o Rewrote ABNF. o Rewrote ABNF.
o ORG can now have a single level. o ORG can now have a single level.
B.11. Changes in -06 B.12. Changes in -06
o Corrected omission of resetability to text value for RELATED. o Corrected omission of resetability to text value for RELATED.
o Let KEY value type be reset to a URI value. o Let KEY value type be reset to a URI value.
o ABNF fixes. o ABNF fixes.
o Made gender values extensible. o Made gender values extensible.
o Gave the PREF parameter a positive integer value. o Gave the PREF parameter a positive integer value.
skipping to change at page 79, line 5 skipping to change at page 82, line 19
o Removed TYPE parameter from EMAIL properties in examples. o Removed TYPE parameter from EMAIL properties in examples.
o Created the CLIENTPIDMAP property. o Created the CLIENTPIDMAP property.
o Changed PID value to a pair of small integers. o Changed PID value to a pair of small integers.
o Completely reworked synchronization mechanisms. o Completely reworked synchronization mechanisms.
o Created brand new synchronization example. o Created brand new synchronization example.
B.12. Changes in -05 B.13. Changes in -05
o Added multi PID value proposal. o Added multi PID value proposal.
B.13. Changes in -04 B.14. Changes in -04
o Added "location" value for KIND property. o Added "location" value for KIND property.
o Some fixes to ABNF. o Some fixes to ABNF.
o Moved "pref" from being a TYPE value to a parameter in its own o Moved "pref" from being a TYPE value to a parameter in its own
right. right.
o Removed the "work" and "home" TYPE values. o Removed the "work" and "home" TYPE values.
skipping to change at page 79, line 39 skipping to change at page 83, line 5
o Removed TYPE parameter from EMAIL and IMPP properties. o Removed TYPE parameter from EMAIL and IMPP properties.
o Replaced AGENT with a type of RELATED. o Replaced AGENT with a type of RELATED.
o Use example.org domain in URL example. o Use example.org domain in URL example.
o Created initial IANA table of values. o Created initial IANA table of values.
o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL. o Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL.
B.14. Changes in -03 B.15. Changes in -03
o Various changes to the synchronization mechanisms. o Various changes to the synchronization mechanisms.
o Allowed truncated format for dated. See issue #236. o Allowed truncated format for dated. See issue #236.
B.15. Changes in -02 B.16. Changes in -02
o Removed useless text in IMPP description. o Removed useless text in IMPP description.
o Added CalDAV-SCHED example to CALADRURI. o Added CalDAV-SCHED example to CALADRURI.
o Removed CAPURI property. o Removed CAPURI property.
o Dashes in dates and colons in times are now mandatory. o Dashes in dates and colons in times are now mandatory.
o Allow for dates such as 2008 and 2008-05 and times such as 07 and o Allow for dates such as 2008 and 2008-05 and times such as 07 and
skipping to change at page 80, line 30 skipping to change at page 83, line 44
o Changed the presence of UID and PID when synchronization is to be o Changed the presence of UID and PID when synchronization is to be
used from MUST to SHOULD. used from MUST to SHOULD.
o Added the RELATED (Section 6.6.6) property. o Added the RELATED (Section 6.6.6) property.
o Fixed many ABNF typos (issue #252). o Fixed many ABNF typos (issue #252).
o Changed formatting of ABNF comments to make them easier to read o Changed formatting of ABNF comments to make them easier to read
(issue #226). (issue #226).
B.16. Changes in -01 B.17. Changes in -01
o Merged [RFC2739] in. o Merged [RFC2739] in.
o Converted all foobar.com, abc.com, etc. to example.com. o Converted all foobar.com, abc.com, etc. to example.com.
o Fixed bugs in ABNF. o Fixed bugs in ABNF.
o Made explicit that coordinates in the GEO property are expressed o Made explicit that coordinates in the GEO property are expressed
in the WGS 84 reference system. in the WGS 84 reference system.
skipping to change at page 81, line 9 skipping to change at page 84, line 25
o Added Section 7. o Added Section 7.
o Created IANA process for registering new parameters, value types, o Created IANA process for registering new parameters, value types,
and properties. and properties.
o Created the initial IANA registries. o Created the initial IANA registries.
o Created vendor namespace based on text from RFC 4288. o Created vendor namespace based on text from RFC 4288.
B.17. Changes in -00 B.18. Changes in -00
o Name change because draft has been accepted as WG item. o Name change because draft has been accepted as WG item.
Otherwise, same as draft-resnick-vcarddav-vcardrev-01. Otherwise, same as draft-resnick-vcarddav-vcardrev-01.
o Removed reference to RFC 2234. o Removed reference to RFC 2234.
o Fixed errata from o Fixed errata from
http://www.rfc-editor.org/errata_search.php?rfc=2426. http://www.rfc-editor.org/errata_search.php?rfc=2426.
o Removed passage referring to RFC 2425 profiles. o Removed passage referring to RFC 2425 profiles.
 End of changes. 104 change blocks. 
454 lines changed or deleted 623 lines changed or added

This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff