draft-ietf-vcarddav-vcardrev-04.txt   draft-ietf-vcarddav-vcardrev-05.txt 
Network Working Group S. Perreault Network Working Group S. Perreault
Internet-Draft Viagenie Internet-Draft Viagenie
Obsoletes: 2425, 2426, 4770 P. Resnick Obsoletes: 2425, 2426, 4770 P. Resnick
(if approved) QUALCOMM Incorporated (if approved) QUALCOMM Incorporated
Updates: 2739 (if approved) October 31, 2008 Updates: 2739 (if approved) November 3, 2008
Intended status: Standards Track Intended status: Standards Track
Expires: May 4, 2009 Expires: May 7, 2009
vCard Format Specification vCard Format Specification
draft-ietf-vcarddav-vcardrev-04 draft-ietf-vcarddav-vcardrev-05
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 May 4, 2009. This Internet-Draft will expire on May 7, 2009.
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 an individual (e.g., exchanging a variety of information about an individual (e.g.,
formatted and structured name and delivery addresses, email address, formatted and structured name and delivery addresses, email address,
multiple telephone numbers, photograph, logo, audio clips, etc.). multiple telephone numbers, photograph, logo, audio clips, etc.).
Table of Contents Table of Contents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
5.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. DATE, TIME, and DATE-TIME . . . . . . . . . . . . . . . . 13 5.3. DATE, TIME, and DATE-TIME . . . . . . . . . . . . . . . . 13
5.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.7. BINARY . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.7. BINARY . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.8. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 15 5.8. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 15 6. Property Parameters . . . . . . . . . . . . . . . . . . . . . 15
6.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. ENCODING . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. ENCODING . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.5. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.5. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 18 7. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. General Properties . . . . . . . . . . . . . . . . . . . . 18 7.1. General Properties . . . . . . . . . . . . . . . . . . . . 18
7.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.4. NAME . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1.4. NAME . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1.5. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1.5. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 31 skipping to change at page 3, line 31
7.8.1. CLASS . . . . . . . . . . . . . . . . . . . . . . . . 36 7.8.1. CLASS . . . . . . . . . . . . . . . . . . . . . . . . 36
7.8.2. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.8.2. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 37 7.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 37
7.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 37 7.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 37
7.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 38 7.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 38
7.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 38 7.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 38
7.10. Extended Properties and Parameters . . . . . . . . . . . . 38 7.10. Extended Properties and Parameters . . . . . . . . . . . . 38
8. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 38 8. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 39
9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 40 9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 41
10. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 49 10. Example: Authors' vCards . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
12.1. Registering New vCard Elements . . . . . . . . . . . . . . 50 12.1. Registering New vCard Elements . . . . . . . . . . . . . . 51
12.1.1. Registration Procedure . . . . . . . . . . . . . . . . 50 12.1.1. Registration Procedure . . . . . . . . . . . . . . . . 51
12.1.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 51 12.1.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 52
12.1.3. Registration Template for Groups . . . . . . . . . . . 51 12.1.3. Registration Template for Groups . . . . . . . . . . . 52
12.1.4. Registration Template for Properties . . . . . . . . . 51 12.1.4. Registration Template for Properties . . . . . . . . . 52
12.1.5. Registration Template for Parameters . . . . . . . . . 52 12.1.5. Registration Template for Parameters . . . . . . . . . 53
12.1.6. Registration Template for Value Data Types . . . . . . 52 12.1.6. Registration Template for Value Data Types . . . . . . 53
12.1.7. Registration Template for Values . . . . . . . . . . . 53 12.1.7. Registration Template for Values . . . . . . . . . . . 54
12.2. Initial vCard Elements Registries . . . . . . . . . . . . 53 12.2. Initial vCard Elements Registries . . . . . . . . . . . . 54
12.2.1. Groups Registry . . . . . . . . . . . . . . . . . . . 54 12.2.1. Groups Registry . . . . . . . . . . . . . . . . . . . 55
12.2.2. Properties Registry . . . . . . . . . . . . . . . . . 54 12.2.2. Properties Registry . . . . . . . . . . . . . . . . . 55
12.2.3. Parameters Registry . . . . . . . . . . . . . . . . . 56 12.2.3. Parameters Registry . . . . . . . . . . . . . . . . . 57
12.2.4. Value Data Types Registry . . . . . . . . . . . . . . 56 12.2.4. Value Data Types Registry . . . . . . . . . . . . . . 57
12.2.5. Values Registries . . . . . . . . . . . . . . . . . . 56 12.2.5. Values Registries . . . . . . . . . . . . . . . . . . 57
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 58 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
14.1. Normative References . . . . . . . . . . . . . . . . . . . 58 14.1. Normative References . . . . . . . . . . . . . . . . . . . 59
14.2. Informative References . . . . . . . . . . . . . . . . . . 60 14.2. Informative References . . . . . . . . . . . . . . . . . . 61
Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 61 Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 62
A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 61 A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 62
A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 61 A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 62
A.3. New Properties and Parameters . . . . . . . . . . . . . . 61 A.3. New Properties and Parameters . . . . . . . . . . . . . . 62
A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 62 A.4. Other Changes . . . . . . . . . . . . . . . . . . . . . . 63
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) . . . . . . . . . . . . . . . . . . . . 62 publication) . . . . . . . . . . . . . . . . . . . . 63
B.1. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 62 B.1. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 63
B.2. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 63 B.2. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 63
B.3. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 63 B.3. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 64
B.4. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 63 B.4. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 64
B.5. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 64 B.5. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 64
B.6. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction 1. Introduction
Note: This draft contains much of the same text as 2425 and 2426 Note: This draft contains much of the same text as 2425 and 2426
which may not be correct. Those two RFCs have been merged and the which may not be correct. Those two RFCs have been merged and the
structure of this draft is what's new. Some vCard-specific structure of this draft is what's new. Some vCard-specific
suggestions have been added, but for the most part this is still very suggestions have been added, but for the most part this is still very
open. But we'd like to get feedback on the structure mostly so that open. But we'd like to get feedback on the structure mostly so that
it may be fixed. it may be fixed.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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; type=vcard * text/directory; type=vcard
* text/x-vcard * text/x-vcard
Published specification: draft-ietf-vcarddav-vcardrev-04 Published specification: draft-ietf-vcarddav-vcardrev-05
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, etc. management software, etc.
Additional information: Additional information:
Magic number(s): Magic number(s):
skipping to change at page 16, line 36 skipping to change at page 16, line 36
/ "float" / "float"
/ x-name / x-name
/ iana-token ; registered as described in / iana-token ; registered as described in
; section 12 of this document ; section 12 of this document
languageparam = "language" "=" Language-Tag languageparam = "language" "=" Language-Tag
; Language-Tag is defined in section 2.1 of RFC 4646 ; Language-Tag is defined in section 2.1 of RFC 4646
pref-param = "pref" pref-param = "pref"
pid-param = ("pid" "=" 1*DIGIT) pid-param = ("pid" "=" pid-value *("," pid-value))
pid-value = 1*DIGIT
Applications MUST ignore x-param and iana-param value they don't Applications MUST ignore x-param and iana-param value they don't
recognize. recognize.
6.1. LANGUAGE 6.1. LANGUAGE
The "language" property parameter is used to identify data in The "language" property parameter is used to identify data in
multiple languages. There is no concept of "default" language, multiple languages. There is no concept of "default" language,
except as specified by any "Content-Language" MIME header parameter except as specified by any "Content-Language" MIME header parameter
that is present. The value of the "language" property parameter is a that is present. The value of the "language" property parameter is a
skipping to change at page 18, line 12 skipping to change at page 18, line 12
search engine could look for dates in any item type and provide search engine could look for dates in any item type and provide
results that can still be interpreted. results that can still be interpreted.
6.4. PID 6.4. PID
The "pid" parameter is used to identify a specific property among The "pid" parameter is used to identify a specific property among
multiple instances. It plays a role analogous to the UID property multiple instances. It plays a role analogous to the UID property
(Section 7.7.7) on a per-property instead of per-vCard basis. It (Section 7.7.7) on a per-property instead of per-vCard basis. It
MUST NOT appear more than once in a given property. It MUST NOT MUST NOT appear more than once in a given property. It MUST NOT
appear on properties that only may have one instance per vCard. Its appear on properties that only may have one instance per vCard. Its
value is a small integer. Note that the "pid" parameter's value is value is a small integer. For synchronization purposes, it MAY
not globally unique, so it is possible for duplicate values to be contain more than one value to resolve conflicts (see Section 8).
created. Note that the "pid" parameter's values are not globally unique, so it
is possible for duplicate values to be created.
6.5. TYPE 6.5. TYPE
The "type" parameter has multiple, different uses. In general, it is The "type" parameter has multiple, different uses. In general, it is
a way of specifying class characteristics of the associated property. a way of specifying class characteristics of the associated property.
Most of the time, its value is a comma-separated subset of a pre- Most of the time, its value is a comma-separated subset of a pre-
defined enumeration. In this document, the following properties make defined enumeration. In this document, the following properties make
use of this parameter: PHOTO, ADR, LABEL, TEL, EMAIL, IMPP, LOGO, use of this parameter: PHOTO, ADR, LABEL, TEL, EMAIL, IMPP, LOGO,
MEMBER, SOUND, and KEY. MEMBER, SOUND, and KEY.
skipping to change at page 39, line 22 skipping to change at page 39, line 22
property where a synchronization engine determines there is property where a synchronization engine determines there is
sufficient similarity to assume equivalence. The particular strategy sufficient similarity to assume equivalence. The particular strategy
and criteria used is out of scope for this document. and criteria used is out of scope for this document.
Updates to vCards with multiple instances of particular properties Updates to vCards with multiple instances of particular properties
MAY use the PID associated with each property to aid in determining MAY use the PID associated with each property to aid in determining
what values have changed. Since PIDs are not globally unique, they what values have changed. Since PIDs are not globally unique, they
can only be used as guidelines to synchronization engine logic. Such can only be used as guidelines to synchronization engine logic. Such
logic is out of scope for this document. logic is out of scope for this document.
Note that when a synchronization engine performs conflict resolution,
it is possible that new values, from multiple sources and with
different PIDs, are in fact the same value. In such a situation, a
synchronization engine MAY choose to represent this situation by
using multiple PID values - first the final desired PID value,
followed by a ",", followed by any prior PID values for that
particular property. The recipient of multiple PID values for a
single property should update to only use the desired new PID value
in future communications.
8.2. Example 8.2. Example
Two vCards are to be synchronized: Two vCards are to be synchronized:
BEGIN:VCARD BEGIN:VCARD
VERSION:4.0 VERSION:4.0
UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da
FN:Jane Doe FN:Jane Doe
HOME.TEL;PID=1:tel:+33-01-23-45-67 HOME.TEL;PID=1:tel:+33-01-23-45-67
HOME.TEL;PID=3:tel:+1-800-555-1234 HOME.TEL;PID=3:tel:+1-800-555-1234
skipping to change at page 40, line 26 skipping to change at page 40, line 40
If the synchronization engine then is presented with an updated vCard If the synchronization engine then is presented with an updated vCard
such as: such as:
BEGIN:VCARD BEGIN:VCARD
VERSION:4.0 VERSION:4.0
UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da
FN:Jane Doe FN:Jane Doe
HOME.TEL;PID=1:tel:+33-01-23-45-67 HOME.TEL;PID=1:tel:+33-01-23-45-67
HOME.TEL;PID=4:tel:+1-800-555-5678 HOME.TEL;PID=4:tel:+1-800-555-5678
EMAIL;PID=1:jdoe@example.com EMAIL;PID=1:jdoe@example.com
EMAIL;PID=2:fred.smithdoe@example.com
IMPP;PREF:xmpp:jdoe@example.com IMPP;PREF:xmpp:jdoe@example.com
END:VCARD END:VCARD
It may use the PIDs on each property to determine that the second It may use the PIDs on each property to determine that the second
phone number in the sequence has been deleted. Note that there may phone number in the sequence has been deleted, and a new email
be data beyond what is available within a vCard, such as a speed dial address has been added. Note that there may be data beyond what is
number, that is specific to each individual property instance, which available within a vCard, such as a speed dial number, that is
is why providing a correlation between versions is significant. specific to each individual property instance, which is why providing
a correlation between versions is significant.
If the synchronization engine next received the following vCard from
a different source:
BEGIN:VCARD
VERSION:4.0
UID:urn:uuid:77a01597-0603-40f3-8138-36deca8618da
FN:Jane Doe
TEL;PID=1;TYPE=home:tel:+33-01-23-45-67
TEL;PID=4;TYPE=home:tel:+1-800-555-5678
EMAIL;PID=1:jdoe@example.com
EMAIL;PID=5:fred.smithdoe@example.com
IMPP;TYPE=personal,pref:xmpp:jdoe@example.com
END:VCARD
It may determine that that the new email address with PID=5 is
equivalent to the existing email address with PID=2. It could inform
the new data source to use the PID value 2 by specifying the
following line in the vCard returned to that last source:
EMAIL;PID=2,5:fred.smithdoe@example.com
After receipt of the updated PID values, the new source should begin
to use PID=2 for that email address in future communications with
that synchronization engine.
9. Formal Grammar 9. Formal Grammar
The following formal grammar is provided to assist developers in The following formal grammar is provided to assist developers in
building parsers for the vCard. building parsers for the vCard.
This syntax is written according to the form described in [RFC5234], This syntax is written according to the form described in [RFC5234],
but it references just this small subset of [RFC5234] literals: but it references just this small subset of [RFC5234] literals:
;******************************************* ;*******************************************
skipping to change at page 47, line 37 skipping to change at page 48, line 32
;******************************************* ;*******************************************
text-param = ("VALUE" "=" "ptext") text-param = ("VALUE" "=" "ptext")
/ ("LANGUAGE" "=" langval) / ("LANGUAGE" "=" langval)
/ (x-name "=" param-value) / (x-name "=" param-value)
langval = <a language string as defined in [RFC4646]> langval = <a language string as defined in [RFC4646]>
pref-param = "PREF" pref-param = "PREF"
pid-param = ("PID" "=" 1*DIGIT) pid-param = ("PID" "=" pid-value *("," pid-value))
pid-value = 1*DIGIT
img-inline-value = binary-value img-inline-value = binary-value
;Value MUST be "b" encoded image content ;Value MUST be "b" encoded image content
img-inline-param img-inline-param
img-inline-param = ("VALUE" "=" "binary") img-inline-param = ("VALUE" "=" "binary")
/ ("ENCODING" "=" "b") / ("ENCODING" "=" "b")
/ ("TYPE" "=" param-value) / ("TYPE" "=" param-value)
;TYPE value MUST be an image media type as defined in RFC 4288 ;TYPE value MUST be an image media type as defined in RFC 4288
skipping to change at page 62, line 21 skipping to change at page 63, line 21
o The N property is no longer mandatory. o The N property is no longer mandatory.
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.
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 -04 B.1. Changes in -05
o Added multi PID value proposal.
B.2. 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 63, line 5 skipping to change at page 64, line 7
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.2. Changes in -03 B.3. 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.3. Changes in -02 B.4. 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 63, line 44 skipping to change at page 64, line 46
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 7.6.6) property. o Added the RELATED (Section 7.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.4. Changes in -01 B.5. 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 64, line 25 skipping to change at page 65, line 27
o Added Section 8. o Added Section 8.
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.5. Changes in -00 B.6. 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. 19 change blocks. 
53 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/