draft-ietf-calsify-2446bis-09.txt   draft-ietf-calsify-2446bis-10.txt 
Network Working Group C. Daboo, Ed. Network Working Group C. Daboo, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Obsoletes: 2446 (if approved) April 19, 2009 Obsoletes: 2446 (if approved) October 4, 2009
Updates: 5545 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 21, 2009 Expires: April 7, 2010
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-09 draft-ietf-calsify-2446bis-10
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 44
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 October 21, 2009. This Internet-Draft will expire on April 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 51 skipping to change at page 3, line 51
3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 53 3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 55 3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 57 3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 58 3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 58
3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 60 3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 60
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 65 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 65
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 67 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 67
3.7. Implementation Considerations . . . . . . . . . . . . . . 70 3.7. Implementation Considerations . . . . . . . . . . . . . . 74
3.7.1. Working With Recurrence Instances . . . . . . . . . . 70 3.7.1. Working With Recurrence Instances . . . . . . . . . . 74
3.7.2. Attendee Property Considerations . . . . . . . . . . 71 3.7.2. Attendee Property Considerations . . . . . . . . . . 75
3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 72 3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 75
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.1. Published Event Examples . . . . . . . . . . . . . . . . 72 4.1. Published Event Examples . . . . . . . . . . . . . . . . 76
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 73 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 76
4.1.2. Changing A Published Event . . . . . . . . . . . . . 73 4.1.2. Changing A Published Event . . . . . . . . . . . . . 77
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 74 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 77
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 74 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 78
4.1.5. Anniversaries or Events attached to entire days . . . 76 4.1.5. Anniversaries or Events attached to entire days . . . 79
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 76 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 80
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 77 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 81
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 78 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 81
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 78 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 82
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 79 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 83
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 82 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 85
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 84 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 87
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 85 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 88
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 86 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 89
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 86 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 89
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 87 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 91
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 89 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 92
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 90 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 93
4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 90 4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 93
4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 91 4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 94
4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 92 4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 95
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 92 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 95
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 92 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 95
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 94 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 97
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 96 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 99
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 97 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 100
4.4.5. Change All Future Instances . . . . . . . . . . . . . 97 4.4.5. Change All Future Instances . . . . . . . . . . . . . 100
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 98 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 101
4.4.7. Add A New Series of Instances To A Recurring Event . 99 4.4.7. Add A New Series of Instances To A Recurring Event . 102
4.4.8. Refreshing A Recurring Event . . . . . . . . . . . . 101 4.4.8. Refreshing A Recurring Event . . . . . . . . . . . . 104
4.4.9. Counter An Instance Of A Recurring Event . . . . . . 103 4.4.9. Counter An Instance Of A Recurring Event . . . . . . 106
4.4.10. Error Reply To A Request . . . . . . . . . . . . . . 104 4.4.10. Error Reply To A Request . . . . . . . . . . . . . . 107
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 106 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 109
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 107 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 110
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 107 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 110
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 108 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 111
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 108 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 111
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 109 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 112
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 109 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 112
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 110 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 113
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 111 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 114
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 111 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 114
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 111 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 114
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 112 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 115
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 115 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 118
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 115 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 118
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 115 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 118
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 117 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 120
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 118 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 121
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 120 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 123
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 121 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 124
5.2.1. Cancellation of an Unknown Calendar Component. . . . 121 5.2.1. Cancellation of an Unknown Calendar Component. . . . 124
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 122 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 125
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 122 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 125
6. Security Considerations . . . . . . . . . . . . . . . . . . . 122 6. Security Considerations . . . . . . . . . . . . . . . . . . . 125
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 122 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 125
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 122 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 125
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 122 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 125
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 123 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 126
6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 123 6.1.4. Eavesdropping and Data Integrity . . . . . . . . . . 126
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 123 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 126
6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 123 6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 126
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 123 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 126
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 123 6.2.1. Securing iTIP transactions . . . . . . . . . . . . . 126
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 124 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 127
6.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 124 6.2.3. Access Controls and Filtering . . . . . . . . . . . . 127
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 124 6.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 127
7.1. METHOD:PUBLISH . . . . . . . . . . . . . . . . . . . . . 125 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 128
7.2. METHOD:REQUEST . . . . . . . . . . . . . . . . . . . . . 125 7.1. Registration Template for REQUEST-STATUS Values . . . . . 128
7.3. METHOD:REPLY . . . . . . . . . . . . . . . . . . . . . . 125 7.2. Additions to iCalendar METHOD Registry . . . . . . . . . 128
7.4. METHOD:ADD . . . . . . . . . . . . . . . . . . . . . . . 125 7.3. REQUEST-STATUS Value Registry . . . . . . . . . . . . . . 129
7.5. METHOD:CANCEL . . . . . . . . . . . . . . . . . . . . . . 126 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 130
7.6. METHOD:REFRESH . . . . . . . . . . . . . . . . . . . . . 126 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.7. METHOD:COUNTER . . . . . . . . . . . . . . . . . . . . . 126 9.1. Normative References . . . . . . . . . . . . . . . . . . 131
7.8. METHOD:DECLINECOUNTER . . . . . . . . . . . . . . . . . . 126 9.2. Informative References . . . . . . . . . . . . . . . . . 131
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 126 Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 131
9. Normative References . . . . . . . . . . . . . . . . . . . . 127 A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 131
Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 127 A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 132
A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 127
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 128
Appendix B. Change History (to be removed prior to Appendix B. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 128 publication as an RFC) . . . . . . . . . . . . . . . 132
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 131 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 135
1. Introduction and Overview 1. Introduction and Overview
This document specifies how calendaring systems use iCalendar This document specifies how calendaring systems use iCalendar
[I-D.ietf-calsify-rfc2445bis] objects to interoperate with other [RFC5545] objects to interoperate with other calendaring systems. In
calendaring systems. In particular, it specifies how to schedule particular, it specifies how to schedule events, to-dos, or daily
events, to-dos, or daily journal entries. It further specifies how journal entries. It further specifies how to search for available
to search for available busy time information. It does so in a busy time information. It does so in a general way without
general way without specifying how communication between different specifying how communication between different systems actually takes
systems actually takes place. Subsequent documents specify transport place. Subsequent documents specify transport bindings between
bindings between systems that use this protocol. systems that use this protocol.
This protocol is based on messages sent from an originator to one or This protocol is based on messages sent from an originator to one or
more recipients. For certain types of messages, a recipient may more recipients. For certain types of messages, a recipient may
reply, in order to update their status and may also return reply, in order to update their status and may also return
transaction/request status information. The protocol supports the transaction/request status information. The protocol supports the
ability for the message originator to modify or cancel the original ability for the message originator to modify or cancel the original
message. The protocol also supports the ability for recipients to message. The protocol also supports the ability for recipients to
suggest changes to the originator of a message. The elements of the suggest changes to the originator of a message. The elements of the
protocol also define the user roles for its transactions. protocol also define the user roles for its transactions.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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].
Calendaring and scheduling roles are referred to in quoted-strings of Calendaring and scheduling roles are referred to in quoted-strings of
text with the first character of each word in upper case. For text with the first character of each word in upper case. For
example, "Organizer" refers to a role of a "Calendar User" (CU) example, "Organizer" refers to a role of a "Calendar User" (CU)
within the scheduling protocol. within the scheduling protocol.
Calendar components defined by [I-D.ietf-calsify-rfc2445bis] are Calendar components defined by [RFC5545] are referred to with
referred to with capitalized, quoted-strings of text. All calendar capitalized, quoted-strings of text. All calendar components start
components start with the letter "V". For example, "VEVENT" refers with the letter "V". For example, "VEVENT" refers to the event
to the event calendar component, "VTODO" refers to the to-do calendar calendar component, "VTODO" refers to the to-do calendar component
component and "VJOURNAL" refers to the daily journal calendar and "VJOURNAL" refers to the daily journal calendar component.
component.
Scheduling methods are referred to with capitalized, quoted-strings Scheduling methods are referred to with capitalized, quoted-strings
of text. For example, "REQUEST" refers to the method for requesting of text. For example, "REQUEST" refers to the method for requesting
a scheduling calendar component be created or modified, "REPLY" a scheduling calendar component be created or modified, "REPLY"
refers to the method a recipient of a request uses to update their refers to the method a recipient of a request uses to update their
status with the "Organizer" of the calendar component. status with the "Organizer" of the calendar component.
Properties defined by [I-D.ietf-calsify-rfc2445bis] are referred to Properties defined by [RFC5545] are referred to with capitalized,
with capitalized, quoted-strings of text, followed by the word quoted-strings of text, followed by the word "property". For
"property". For example, "ATTENDEE" property refers to the iCalendar example, "ATTENDEE" property refers to the iCalendar property used to
property used to convey the calendar address of a "Calendar User". convey the calendar address of a "Calendar User".
Property parameters defined by this specification are referred to Property parameters defined by this specification are referred to
with capitalized, quoted-strings of text, followed by the word with capitalized, quoted-strings of text, followed by the word
"parameter". For example, "VALUE" parameter refers to the iCalendar "parameter". For example, "VALUE" parameter refers to the iCalendar
property parameter used to override the default data type for a property parameter used to override the default data type for a
property value. property value.
Enumerated values defined by this specification are referred to with Enumerated values defined by this specification are referred to with
capitalized text, either alone or followed by the word "value". capitalized text, either alone or followed by the word "value".
In tables, the quoted-string text is specified without quotes in In tables, the quoted-string text is specified without quotes in
order to minimize the table length. order to minimize the table length.
1.2. Related Documents 1.2. Related Documents
Implementers will need to be familiar with several other Implementers will need to be familiar with several other
specifications that, along with this one, describe the Internet specifications that, along with this one, describe the Internet
calendaring and scheduling standards. The related documents are: calendaring and scheduling standards. The related documents are:
[I-D.ietf-calsify-rfc2445bis] - specifies the objects, data types, [RFC5545] - specifies the objects, data types, properties and
properties and property parameters used in the protocols, along property parameters used in the protocols, along with the methods
with the methods for representing and encoding them. for representing and encoding them.
[I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding [I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding
for iTIP. for iTIP.
This specification does not attempt to repeat the concepts or This specification does not attempt to repeat the concepts or
definitions from these other specifications. Where possible, definitions from these other specifications. Where possible,
explicit references are made to the other specifications. explicit references are made to the other specifications.
1.3. Roles 1.3. Roles
skipping to change at page 9, line 12 skipping to change at page 9, line 12
| | recurring iCalendar object. | | | recurring iCalendar object. |
| | | | | |
| CANCEL | Cancel one or more instances of an existing | | CANCEL | Cancel one or more instances of an existing |
| | iCalendar object. | | | iCalendar object. |
| | | | | |
| REFRESH | The Refresh method is used by an "Attendee" to | | REFRESH | The Refresh method is used by an "Attendee" to |
| | request the latest version of an iCalendar | | | request the latest version of an iCalendar |
| | object. | | | object. |
| | | | | |
| COUNTER | The Counter method is used by an "Attendee" to | | COUNTER | The Counter method is used by an "Attendee" to |
| | negotiate a change in an iCalendar objecy. | | | negotiate a change in an iCalendar object. |
| | Examples include the request to change a | | | Examples include the request to change a |
| | proposed event time or change the due date for a | | | proposed event time or change the due date for a |
| | task. | | | task. |
| | | | | |
| DECLINECOUNTER | Used by the "Organizer" to decline the proposed | | DECLINECOUNTER | Used by the "Organizer" to decline the proposed |
| | counter-proposal. | | | counter-proposal. |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
Group scheduling in iTIP is accomplished using the set of "request" Group scheduling in iTIP is accomplished using the set of "request"
and "response" methods described above. The following table shows and "response" methods described above. The following table shows
skipping to change at page 15, line 19 skipping to change at page 15, line 19
| 1+ | At least one instance MUST be present | | 1+ | At least one instance MUST be present |
| 0 | Instances of this property MUST NOT be present | | 0 | Instances of this property MUST NOT be present |
| 0+ | Multiple instances MAY be present | | 0+ | Multiple instances MAY be present |
| 0 or 1 | Up to 1 instance of this property MAY be present | | 0 or 1 | Up to 1 instance of this property MAY be present |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA- The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA-
COMPONENT" and "X-COMPONENT" to show where registered and vendor- COMPONENT" and "X-COMPONENT" to show where registered and vendor-
specific property and component extensions can appear. The tables do specific property and component extensions can appear. The tables do
not lay out the restrictions of property parameters. Those not lay out the restrictions of property parameters. Those
restrictions are defined in [I-D.ietf-calsify-rfc2445bis]. restrictions are defined in [RFC5545].
3.1. Common Component Restriction Tables 3.1. Common Component Restriction Tables
3.1.1. VCALENDAR 3.1.1. VCALENDAR
The restriction table below applies to properties of the iCalendar The restriction table below applies to properties of the iCalendar
object. That is, the properties at the outermost scope. object. That is, the properties at the outermost scope.
+-----------------------------------------------------+ +-----------------------------------------------------+
| Constraints for properties in a VCALENDAR Component | | Constraints for properties in a VCALENDAR Component |
skipping to change at page 23, line 28 skipping to change at page 23, line 28
for the "Delegate" MUST be included and must specify the calendar for the "Delegate" MUST be included and must specify the calendar
user address set in the "DELEGATED-TO" parameter, as above. user address set in the "DELEGATED-TO" parameter, as above.
In response to the request, the "Delegate" MUST send a "REPLY" method In response to the request, the "Delegate" MUST send a "REPLY" method
to the "Organizer" and optionally, to the "Delegator". The "REPLY" to the "Organizer" and optionally, to the "Delegator". The "REPLY"
method SHOULD include the "ATTENDEE" property with the "DELEGATED- method SHOULD include the "ATTENDEE" property with the "DELEGATED-
FROM" parameter value of the "Delegator's" calendar address. FROM" parameter value of the "Delegator's" calendar address.
The "Delegator" may continue to receive updates to the event even The "Delegator" may continue to receive updates to the event even
though they will not be attending. This is accomplished by the though they will not be attending. This is accomplished by the
"Delegator" setting their "role" attribute to " NON-PARTICIPANT" in "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in
the "REPLY" to the "Organizer" the "REPLY" to the "Organizer"
3.2.2.4. Changing the Organizer 3.2.2.4. Changing the Organizer
The situation may arise where the "Organizer" of a VEVENT is no The situation may arise where the "Organizer" of a VEVENT is no
longer able to perform the "Organizer" role and abdicates without longer able to perform the "Organizer" role and abdicates without
passing on the "Organizer" role to someone else. When this occurs passing on the "Organizer" role to someone else. When this occurs
the "Attendees" of the VEVENT may use out-of-band mechanisms to the "Attendees" of the VEVENT may use out-of-band mechanisms to
communicate the situation and agree upon a new "Organizer". The new communicate the situation and agree upon a new "Organizer". The new
"Organizer" should then send out a new "REQUEST" with a modified "Organizer" should then send out a new "REQUEST" with a modified
skipping to change at page 29, line 20 skipping to change at page 29, line 20
recurring "VEVENT" calendar component: recurring "VEVENT" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
"THISANDFUTURE" to indicate cancellation of the specified "THISANDFUTURE" to indicate cancellation of the specified
"VEVENT" calendar component and all instances after; or "VEVENT" calendar component and all instances after; or
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "VEVENT" components each with a "RECURRENCE-ID" property multiple "VEVENT" components each with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled. corresponding to one of the instances to be cancelled.
The "Organizer" is MUST send a "CANCEL" message to each "Attendee" The "Organizer" MUST send a "CANCEL" message to each "Attendee"
affected by the cancellation. This can be done using a single affected by the cancellation. This can be done using a single
"CANCEL" message for all "Attendees", or multiple messages with "CANCEL" message for all "Attendees", or multiple messages with
different subsets of the affected "Attendees" in each. different subsets of the affected "Attendees" in each.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
incremented as described in Section 2.1.4. incremented as described in Section 2.1.4.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
skipping to change at page 53, line 34 skipping to change at page 53, line 34
recurring "VTODO" calendar component: recurring "VTODO" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of be specified with the "RANGE" property parameter value of
"THISANDFUTURE" to indicate cancellation of the specified "VTODO" "THISANDFUTURE" to indicate cancellation of the specified "VTODO"
calendar component and all instances after calendar component and all instances after
b. individual recurrence instances may be cancelled by specifying b. individual recurrence instances may be cancelled by specifying
multiple "VTODO" components with a "RECURRENCE-ID" property multiple "VTODO" components with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled corresponding to one of the instances to be cancelled
The "Organizer" is MUST send a "CANCEL" message to each "Attendee" The "Organizer" MUST send a "CANCEL" message to each "Attendee"
affected by the cancellation. This can be done using a single affected by the cancellation. This can be done using a single
"CANCEL" message for all "Attendees", or multiple messages with "CANCEL" message for all "Attendees", or multiple messages with
different subsets of the affected "Attendees" in each. different subsets of the affected "Attendees" in each.
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented as described in Section 2.1.4. incremented as described in Section 2.1.4.
This method type is an iCalendar object that conforms to the This method type is an iCalendar object that conforms to the
following property constraints: following property constraints:
skipping to change at page 67, line 12 skipping to change at page 67, line 12
| | | | | | | |
| VFREEBUSY | 0 | | | VFREEBUSY | 0 | |
| | | | | | | |
| VTODO | 0 | | | VTODO | 0 | |
+--------------------+----------+-----------------------------------+ +--------------------+----------+-----------------------------------+
3.6. Status Replies 3.6. Status Replies
The "REQUEST-STATUS" property is used to convey status information The "REQUEST-STATUS" property is used to convey status information
about a REPLY, COUNTER or DECLINECOUNTER iTIP message. The codes about a REPLY, COUNTER or DECLINECOUNTER iTIP message. The codes
listed in the table below SHOULD be used. Additional codes MAY be listed in the table below SHOULD be used. If the "REQUEST-STATUS"
used provided they are defined in a Standards Track or Experimental property is not present in one of these iTIP messages, then a status
RFC. code of "2.0" (success) MUST be assumed.
This specification adds a new IANA registry for REQUEST-STATUS
values, as defined in Section 7, which includes a new registration
template for defining the specific components of the REQUEST-STATUS
value. Additional codes MAY be used provided the process described
in Section 8.2.1 of [RFC5545] is used to register them.
This specification allows for multiple "REQUEST-STATUS" properties to This specification allows for multiple "REQUEST-STATUS" properties to
be returned in iCalendar components in the appropriate iTIP messages. be returned in iCalendar components in the appropriate iTIP messages.
When multiple "REQUEST-STATUS" properties are present, the following When multiple "REQUEST-STATUS" properties are present, the following
restrictions apply: restrictions apply:
1. Within any one component, the "top-level" numeric value of the 1. Within any one component, the "top-level" numeric value of the
"short return status code" MUST be the same for all REQUEST- "short return status code" MUST be the same for all REQUEST-
STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx
and 5.xx codes within a single component. and 5.xx codes within a single component.
skipping to change at page 67, line 42 skipping to change at page 67, line 48
STATUS" MUST NOT be present in the other components if a 3.xx STATUS" MUST NOT be present in the other components if a 3.xx
code is not appropriate for those components. code is not appropriate for those components.
C. 2.xx and 4.xx codes can be used in different components C. 2.xx and 4.xx codes can be used in different components
provided that each component follows the restriction in (1) provided that each component follows the restriction in (1)
above. above.
The following "REQUEST-STATUS" codes are defined (any "Offending The following "REQUEST-STATUS" codes are defined (any "Offending
Data" MAY be specified in the "REQUEST-STATUS" value as the extdata Data" MAY be specified in the "REQUEST-STATUS" value as the extdata
field): field):
+----------+------------------------+-------------------------------+ 3.6.1. Status Code 2.0
| Short | Longer Return Status | Offending Data | Status Code: 2.0
| Return | Description | | Status Description: Success.
| Status | | | Status Exception Data: None.
| Code | | | Description: iTIP operation succeeded.
+----------+------------------------+-------------------------------+
| 2.0 | Success. | None. | 3.6.2. Status Code 2.1
| | | |
| 2.1 | Success but fallback | Property name and value MAY | Status Code: 2.1
| | taken on one or more | be specified. | Status Description: Success but fallback taken on one or more
| | property values. | | property values.
| | | | Status Exception Data: Property name and value MAY be specified.
| 2.2 | Success, invalid | Property name MAY be | Description: iTIP operation succeeded with fallback on one or more
| | property ignored. | specified. | property values.
| | | |
| 2.3 | Success, invalid | Property parameter name and | 3.6.3. Status Code 2.2
| | property parameter | value MAY be specified. |
| | ignored. | | Status Code: 2.2
| | | | Status Description: Success, invalid property ignored.
| 2.4 | Success, unknown | Non-standard property name | Status Exception Data: Property name MAY be specified.
| | non-standard property | MAY be specified. | Description: iTIP operation succeeded but a property was ignored.
| | ignored. | |
| | | | 3.6.4. Status Code 2.3
| 2.5 | Success, unknown | Property and non-standard |
| | non-standard property | value MAY be specified. | Status Code: 2.3
| | value ignored. | | Status Description: Success, invalid property parameter ignored.
| | | | Status Exception Data: Property parameter name and value MAY be
| 2.6 | Success, invalid | Calendar component sentinel | specified.
| | calendar component | (e.g., BEGIN:ALARM) MAY be | Description: iTIP operation succeeded but a property parameter was
| | ignored. | specified. | ignored because it was invalid.
| | | |
| 2.7 | Success, request | Original and forwarded | 3.6.5. Status Code 2.4
| | forwarded to Calendar | caluser addresses MAY be |
| | User. | specified. | Status Code: 2.4
| | | | Status Description: Success, unknown non-standard property ignored.
| 2.8 | Success, repeating | RRULE or RDATE property name | Status Exception Data: Non-standard property name MAY be specified.
| | event ignored. | and value MAY be specified. | Description: iTIP operation succeeded but a property parameter was
| | Scheduled as a single | | ignored because it was unknown.
| | component. | |
| | | | 3.6.6. Status Code 2.5
| 2.9 | Success, truncated end | DTEND property value MAY be |
| | date time to date | specified. | Status Code: 2.5
| | boundary. | | Status Description: Success, unknown non-standard property value
| | | | ignored.
| 2.10 | Success, repeating | RRULE or RDATE property name | Status Exception Data: Property and non-standard value MAY be
| | VTODO ignored. | and value MAY be specified. | specified.
| | Scheduled as a single | |
| | VTODO. | | Description: iTIP operation succeeded but a property was ignored
| | | | because its value was unknown.
| 2.11 | Success, unbounded | RRULE property name and value |
| | RRULE clipped at some | MAY be specified. Number of | 3.6.7. Status Code 2.6
| | finite number of | instances MAY also be |
| | instances | specified. | Status Code: 2.6
| | | | Status Description: Success, invalid calendar component ignored.
| 3.0 | Invalid property name. | Property name MAY be | Status Exception Data: Calendar component sentinel (e.g., BEGIN:
| | | specified. | ALARM) MAY be specified.
| | | | Description: iTIP operation succeeded but a component was ignored
| 3.1 | Invalid property | Property name and value MAY | because it was invalid.
| | value. | be specified. |
| | | | 3.6.8. Status Code 2.7
| 3.2 | Invalid property | Property parameter name and |
| | parameter. | value MAY be specified. | Status Code: 2.7
| | | | Status Description: Success, request forwarded to Calendar User.
| 3.3 | Invalid property | Property parameter name and | Status Exception Data: Original and forwarded calendar user
| | parameter value. | value MAY be specified. | addresses MAY be specified.
| | | | Description: iTIP operation succeeded, and the request was forwarded
| 3.4 | Invalid calendar | Calendar component sentinel | to another calendar user.
| | component sequence. | MAY be specified (e.g., |
| | | BEGIN:VTIMEZONE). | 3.6.9. Status Code 2.8
| | | |
| 3.5 | Invalid date or time. | Date/time value(s) MAY be | Status Code: 2.8
| | | specified. | Status Description: Success, repeating event ignored. Scheduled as
| | | | a single component.
| 3.6 | Invalid rule. | Rule value MAY be specified. | Status Exception Data: RRULE or RDATE property name and value MAY be
| | | | specified.
| 3.7 | Invalid Calendar User. | Attendee property value MAY | Description: iTIP operation succeeded, but a repeating event was
| | | be specified. | truncated to a single instance.
| | | |
| 3.8 | No authority. | METHOD and Attendee property | 3.6.10. Status Code 2.9
| | | values MAY be specified. |
| | | | Status Code: 2.9
| 3.9 | Unsupported version. | VERSION property name and | Status Description: Success, truncated end date time to date
| | | value MAY be specified. | boundary.
| | | | Status Exception Data: DTEND property value MAY be specified.
| 3.10 | Request entity too | None. | Description: iTIP operation succeeded, but the end time was
| | large. | | truncated to a date boundary.
| | | |
| 3.11 | Required component or | Component or property name | 3.6.11. Status Code 2.10
| | property missing. | MAY be specified. |
| | | | Status Code: 2.10
| 3.12 | Unknown component or | Component or property name | Status Description: Success, repeating VTODO ignored. Scheduled as
| | property found | MAY be specified | a single VTODO.
| | | |
| 3.13 | Unsupported component | Component or property name | Status Exception Data: RRULE or RDATE property name and value MAY be
| | or property found | MAY be specified | specified.
| | | | Description: iTIP operation succeeded, but a repeating todo was
| 3.14 | Unsupported capability | METHOD or action MAY be | truncated to a single instance.
| | | specified |
| | | | 3.6.12. Status Code 2.11
| 4.0 | Event conflict. | DTSTART and DTEND property |
| | Date/time is busy. | name and values MAY be | Status Code: 2.11
| | | specified. | Status Description: Success, unbounded RRULE clipped at some finite
| | | | number of instances.
| 5.0 | Request not supported. | METHOD property value MAY be | Status Exception Data: RRULE property name and value MAY be
| | | specified. | specified. Number of instances MAY also be specified.
| | | | Description: iTIP operation succeeded, but an unbounded repeating
| 5.1 | Service unavailable. | ATTENDEE property value MAY | object was clipped to a finite number of instances.
| | | be specified. |
| | | | 3.6.13. Status Code 3.0
| 5.2 | Invalid calendar | ATTENDEE property value MAY |
| | service. | be specified. | Status Code: 3.0
| | | | Status Description: Invalid property name.
| 5.3 | No scheduling support | ATTENDEE property value MAY | Status Exception Data: Property name MAY be specified.
| | for user. | be specified. | Description: iTIP operation failed because of an invalid property
+----------+------------------------+-------------------------------+ name.
3.6.14. Status Code 3.1
Status Code: 3.1
Status Description: Invalid property value.
Status Exception Data: Property name and value MAY be specified.
Description: iTIP operation failed because of an invalid property
value.
3.6.15. Status Code 3.2
Status Code: 3.2
Status Description: Invalid property parameter.
Status Exception Data: Property parameter name and value MAY be
specified.
Description: iTIP operation failed because of an invalid property
parameter.
3.6.16. Status Code 3.3
Status Code: 3.3
Status Description: Invalid property parameter value.
Status Exception Data: Property parameter name and value MAY be
specified.
Description: iTIP operation failed because of an invalid property
parameter value.
3.6.17. Status Code 3.4
Status Code: 3.4
Status Description: Invalid calendar component sequence.
Status Exception Data: Calendar component sentinel MAY be specified
(e.g., BEGIN:VTIMEZONE).
Description: iTIP operation failed because of an invalid component.
3.6.18. Status Code 3.5
Status Code: 3.5
Status Description: Invalid date or time.
Status Exception Data: Date/time value(s) MAY be specified.
Description: iTIP operation failed because of an invalid date or
time property.
3.6.19. Status Code 3.6
Status Code: 3.6
Status Description: Invalid rule.
Status Exception Data: Rule value MAY be specified.
Description: iTIP operation failed because of an invalid rule
property.
3.6.20. Status Code 3.7
Status Code: 3.7
Status Description: Invalid Calendar User.
Status Exception Data: Attendee property value MAY be specified.
Description: iTIP operation failed because of an invalid Attendee
property.
3.6.21. Status Code 3.8
Status Code: 3.8
Status Description: No authority.
Status Exception Data: METHOD and Attendee property values MAY be
specified.
Description: iTIP operation failed because an Attendee does not have
suitable privileges for the operation.
3.6.22. Status Code 3.9
Status Code: 3.9
Status Description: Unsupported version.
Status Exception Data: VERSION property name and value MAY be
specified.
Description: iTIP operation failed because the calendar data version
is not supported.
3.6.23. Status Code 3.10
Status Code: 3.10
Status Description: Request entity too large.
Status Exception Data: Request entity too large.
Description: iTIP operation failed because the calendar data was too
large.
3.6.24. Status Code 3.11
Status Code: 3.11
Status Description: Required component or property missing.
Status Exception Data: Component or property name MAY be specified.
Description: iTIP operation failed because the calendar data did not
contain a required property or component.
3.6.25. Status Code 3.12
Status Code: 3.12
Status Description: Unknown component or property found.
Status Exception Data: Component or property name MAY be specified.
Description: iTIP operation failed because the calendar data
contained an unknown property or component.
3.6.26. Status Code 3.13
Status Code: 3.13
Status Description: Unsupported component or property found.
Status Exception Data: Component or property name MAY be specified.
Description: iTIP operation failed because the calendar data
contained an unsupported property or component.
3.6.27. Status Code 3.14
Status Code: 3.14
Status Description: Unsupported capability.
Status Exception Data: METHOD or action MAY be specified.
Description: iTIP operation failed because the operation is not
supported.
3.6.28. Status Code 4.0
Status Code: 4.0
Status Description: Event conflict. Date/time is busy.
Status Exception Data: DTSTART and DTEND property name and values
MAY be specified.
Description: iTIP operation failed because the event overlaps the
date and time of another event.
3.6.29. Status Code 5.0
Status Code: 5.0
Status Description: Request not supported.
Status Exception Data: METHOD property value MAY be specified.
Description: iTIP operation failed because the operation is not
supported.
3.6.30. Status Code 5.1
Status Code: 5.1
Status Description: Service unavailable.
Status Exception Data: ATTENDEE property value MAY be specified.
Description: iTIP operation failed because scheduling is not active.
3.6.31. Status Code 5.2
Status Code: 5.2
Status Description: Invalid calendar service.
Status Exception Data: ATTENDEE property value MAY be specified.
Description: iTIP operation failed because there is no scheduling
capability.
3.6.32. Status Code 5.3
Status Code: 5.3
Status Description: No scheduling support for user.
Status Exception Data: ATTENDEE property value MAY be specified.
Description: iTIP operation failed because scheduling is not enabled
for an Attendee.
3.7. Implementation Considerations 3.7. Implementation Considerations
3.7.1. Working With Recurrence Instances 3.7.1. Working With Recurrence Instances
iCalendar includes a recurrence grammar to represent recurring iCalendar includes a recurrence grammar to represent recurring
events. The benefit of such a grammar is the ability to represent a events. The benefit of such a grammar is the ability to represent a
number of events in a single object. However, while this simplifies number of events in a single object. However, while this simplifies
creation of a recurring event, meeting instances still need to be creation of a recurring event, meeting instances still need to be
referenced. For instance, an "Attendee" may decline the third referenced. For instance, an "Attendee" may decline the third
skipping to change at page 71, line 35 skipping to change at page 75, line 20
The "ORGANIZER" property is required on published events, to-dos, and The "ORGANIZER" property is required on published events, to-dos, and
journal entries for two reasons. First, only the "Organizer" is journal entries for two reasons. First, only the "Organizer" is
allowed to update and redistribute an event or to-do component. It allowed to update and redistribute an event or to-do component. It
follows that the "ORGANIZER" property MUST be present in the event, follows that the "ORGANIZER" property MUST be present in the event,
to-do, or journal entry component so that the CUA has a basis for to-do, or journal entry component so that the CUA has a basis for
authorizing an update. Second, it is prudent to provide a point of authorizing an update. Second, it is prudent to provide a point of
contact for anyone who receives a published component in case of contact for anyone who receives a published component in case of
problems. problems.
There are valid [RFC5322] addresses that represent groups. Sending Email addresses that correspond to groups of calendar users could be
email to such an address results in mail being sent to multiple specified as a mailto: URI [RFC2368] calendar user address. Sending
email to such an address results in email being sent to multiple
recipients. Such an address may be used as the value of an recipients. Such an address may be used as the value of an
"ATTENDEE" property. Thus, it is possible that the recipient of a "ATTENDEE" property. Thus, it is possible that the recipient of a
"REQUEST" does not appear explicitly in the list. "REQUEST" does not appear explicitly in the list.
It is recommended that the general approach to finding a "Calendar It is recommended that the general approach to finding a "Calendar
User" in an attendee list be as follows: User" in an attendee list be as follows:
1. Search for the "Calendar User" in the attendee list where 1. Search for the "Calendar User" in the attendee list where
"CUTYPE=INDIVIDUAL" "CUTYPE=INDIVIDUAL"
2. Failing (1) look for attendees where "CUTYPE=GROUP" or 2. Failing (1) look for attendees where "CUTYPE=GROUP" or
skipping to change at page 116, line 17 skipping to change at page 119, line 17
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| ATTACH | Ignore | | ATTACH | Ignore |
| ATTENDEE | Required if METHOD is REQUEST, otherwise ignore | | ATTENDEE | Required if METHOD is REQUEST, otherwise ignore |
| CATEGORIES | Ignore | | CATEGORIES | Ignore |
| CLASS | Ignore | | CLASS | Ignore |
| COMMENT | Ignore | | COMMENT | Ignore |
| COMPLETED | Ignore | | COMPLETED | Ignore |
| CONTACT | Ignore | | CONTACT | Ignore |
| CREATED | Ignore | | CREATED | Ignore |
| DESCRIPTION | Ignore | | DESCRIPTION | Ignore |
| DURATION | Reply with "Not Supported" | | DURATION | Required |
| DTSTAMP | Required | | DTSTAMP | Required |
| DTSTART | Required | | DTSTART | Required |
| DTEND | Required | | DTEND | Required |
| EXDATE | Ignore | | EXDATE | Ignore |
| GEO | Ignore | | GEO | Ignore |
| LAST-MODIFIED | Ignore | | LAST-MODIFIED | Ignore |
| LOCATION | Required | | LOCATION | Required |
| ORGANIZER | Required if METHOD is REQUEST, otherwise ignore | | ORGANIZER | Required if METHOD is REQUEST, otherwise ignore |
| PRIORITY | Ignore | | PRIORITY | Ignore |
| RELATED-TO | Ignore | | RELATED-TO | Ignore |
skipping to change at page 117, line 10 skipping to change at page 120, line 10
| URL | Ignore | | URL | Ignore |
| UID | Required | | UID | Required |
| X- | Ignore | | X- | Ignore |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
5.1.2. Free/Busy-Related Fallbacks 5.1.2. Free/Busy-Related Fallbacks
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| Method | Fallback | | Method | Fallback |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
| PUBLISH | Implementations MAY ignore the METHOD type. The | | PUBLISH | Required if freebusy lookups are supported, otherwise |
| | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | reply with a REQUEST-STATUS "3.14;Unsupported |
| | returned. | | | capability" |
| REQUEST | Implementations MAY ignore the METHOD type. The | | REQUEST | Required if freebusy lookups are supported, otherwise |
| | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | reply with a REQUEST-STATUS "3.14;Unsupported |
| | returned. | | | capability" |
| REPLY | Implementations MAY ignore the METHOD type. The | | REPLY | Required if freebusy lookups are supported, otherwise |
| | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | reply with a REQUEST-STATUS "3.14;Unsupported |
| | returned. | | | capability" |
+---------+---------------------------------------------------------+ +---------+---------------------------------------------------------+
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| iCalendar | Fallback | | iCalendar | Fallback |
| Property | | | Property | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| CALSCALE | Ignore - assume GREGORIAN. | | CALSCALE | Ignore - assume GREGORIAN. |
| PRODID | Ignore | | PRODID | Ignore |
| METHOD | Required as described in the Method list above. | | METHOD | Required as described in the Method list above. |
| VERSION | Ignore | | VERSION | Ignore |
skipping to change at page 119, line 20 skipping to change at page 122, line 20
| | ignore | | | ignore |
| CATEGORIES | Ignore | | CATEGORIES | Ignore |
| CLASS | Ignore | | CLASS | Ignore |
| COMMENT | Ignore | | COMMENT | Ignore |
| COMPLETED | Required | | COMPLETED | Required |
| CONTACT | Ignore | | CONTACT | Ignore |
| CREATED | Ignore | | CREATED | Ignore |
| DESCRIPTION | Required if METHOD is REQUEST, otherwise | | DESCRIPTION | Required if METHOD is REQUEST, otherwise |
| | ignore | | | ignore |
| DUE | Required | | DUE | Required |
| DURATION | Ignore - reply with "Not Supported" | | DURATION | Required |
| DTSTAMP | Required | | DTSTAMP | Required |
| DTSTART | Required | | DTSTART | Required |
| EXDATE | Ignore - reply with "Not Supported" | | EXDATE | Ignore - reply with "Not Supported" |
| LAST-MODIFIED | Ignore | | LAST-MODIFIED | Ignore |
| LOCATION | Ignore | | LOCATION | Ignore |
| ORGANIZER | Required if METHOD is REQUEST, otherwise | | ORGANIZER | Required if METHOD is REQUEST, otherwise |
| | ignore | | | ignore |
| PERCENT-COMPLETE | Ignore | | PERCENT-COMPLETE | Ignore |
| PRIORITY | Required | | PRIORITY | Required |
| RECURRENCE-ID | Required if RRULE is implemented, otherwise | | RECURRENCE-ID | Required if RRULE is implemented, otherwise |
skipping to change at page 123, line 18 skipping to change at page 126, line 18
6.1.3. Unauthorized Replacement of the Organizer 6.1.3. Unauthorized Replacement of the Organizer
There will be circumstances when "Attendees" of an event or to-do There will be circumstances when "Attendees" of an event or to-do
decide, using out-of-band mechanisms, that the "Organizer" must be decide, using out-of-band mechanisms, that the "Organizer" must be
replaced. When the new "Organizer" sends out the updated "VEVENT" or replaced. When the new "Organizer" sends out the updated "VEVENT" or
"VTODO" the "Attendee's" CUA will detect that the "Organizer" has "VTODO" the "Attendee's" CUA will detect that the "Organizer" has
been changed, but it has no way of knowing whether or not the change been changed, but it has no way of knowing whether or not the change
was mutually agreed upon. was mutually agreed upon.
6.1.4. Eavesdropping 6.1.4. Eavesdropping and Data Integrity
The iCalendar object is constructed with human-readable clear text. The iCalendar object is constructed with human-readable clear text.
Any information contained in an iCalendar object may be read and/or Any information contained in an iCalendar object may be read and/or
changed by unauthorized persons while the object is in transit. changed by unauthorized persons while the object is in transit.
6.1.5. Flooding a Calendar 6.1.5. Flooding a Calendar
Implementations could provide a means to automatically incorporate Implementations could provide a means to automatically incorporate
"REQUEST" methods into a calendar. This presents the opportunity for "REQUEST" methods into a calendar. This presents the opportunity for
a calendar to be flooded with requests, which effectively block all a calendar to be flooded with requests, which effectively block all
skipping to change at page 123, line 43 skipping to change at page 126, line 43
It is possible for an "Organizer" to receive a "REFRESH" request from It is possible for an "Organizer" to receive a "REFRESH" request from
someone who is not an "Attendee" of an event or to-do. Only someone who is not an "Attendee" of an event or to-do. Only
"Attendee's" of an event or to-do are authorized to receive replies "Attendee's" of an event or to-do are authorized to receive replies
to "REFRESH" requests. Replying to such requests to anyone who is to "REFRESH" requests. Replying to such requests to anyone who is
not an "Attendee" may be a security problem. not an "Attendee" may be a security problem.
6.2. Recommendations 6.2. Recommendations
For an application where the information is sensitive or critical and For an application where the information is sensitive or critical and
the network is subject to a high probability of attack, iTIP the network is subject to a high probability of attack, iTIP
transactions SHOULD be encrypted. This may be accomplished using transactions SHOULD be encrypted and authenticated. This helps
public key technology, specifically Security Multiparts for MIME mitigate the threats of spoofing, eavesdropping and malicious changes
[RFC1847] in the iTIP transport binding. This helps mitigate the in transit.
threats of spoofing, eavesdropping and malicious changes in transit.
6.2.1. Use of [RFC1847] to secure iTIP transactions
iTIP transport bindings MUST provide a mechanism based on Security 6.2.1. Securing iTIP transactions
Multiparts for MIME [RFC1847] to enable authentication of the
sender's identity, and privacy and integrity of the data being
transmitted. This allows the receiver of a signed iCalendar object
to verify the identity of the sender. This sender may then be
correlated to an "ATTENDEE" property in the iCalendar object. If the
correlation is made and the sender is authorized to make the
requested change or update then the operation may proceed. It also
allows the message to be encrypted to prevent unauthorized reading of
the message contents in transit. iTIP transport binding documents
describe this process in detail.
Implementations MAY provide controls for users to disable this iTIP transport bindings MUST provide a mechanism to enable
capability. authentication of the sender's identity, and privacy and integrity of
the data being transmitted. This allows the receiver of a signed
iCalendar object to verify the identity of the sender. This sender
may then be correlated to an "ATTENDEE" property in the iCalendar
object. If the correlation is made and the sender is authorized to
make the requested change or update then the operation may proceed.
It also allows the message to be encrypted to prevent unauthorized
reading of the message contents in transit. iTIP transport binding
documents describe this process in detail.
6.2.2. Implementation Controls 6.2.2. Implementation Controls
The threat of unauthorized replacement of the "Organizer" SHOULD be The threat of unauthorized replacement of the "Organizer" SHOULD be
mitigated by a calendar system that uses this protocol by providing mitigated by a calendar system that uses this protocol by providing
controls or alerts that make "Calendar Users" aware of such controls or alerts that make "Calendar Users" aware of such
"Organizer" changes and allowing them to decide whether or not the "Organizer" changes and allowing them to decide whether or not the
request should be honored. request should be honored.
The threat of flooding a calendar SHOULD be mitigated by a calendar The threat of flooding a calendar SHOULD be mitigated by a calendar
skipping to change at page 124, line 39 skipping to change at page 127, line 34
The threat of unauthorized "REFRESH" requests SHOULD be mitigated by The threat of unauthorized "REFRESH" requests SHOULD be mitigated by
a calendar system that uses this protocol by providing controls or a calendar system that uses this protocol by providing controls or
alerts that allow "Calendar User" to decide whether or not the alerts that allow "Calendar User" to decide whether or not the
request should be honored. An implementation MAY decide to maintain, request should be honored. An implementation MAY decide to maintain,
for audit or historical purposes, "Calendar Users" who were part of for audit or historical purposes, "Calendar Users" who were part of
an attendee list and who were subsequently uninvited. Similar an attendee list and who were subsequently uninvited. Similar
controls or alerts should be provided when a "REFRESH" request is controls or alerts should be provided when a "REFRESH" request is
received from these "Calendar Users" as well. received from these "Calendar Users" as well.
6.2.3. Access Controls and Filtering
In many environments there could be restrictions on who is allowed to
scheduled with whom, and who allowed delegates are for particular
calendar users.
iTIP transport bindings SHOULD provide mechanisms for implementing
access controls or filtering to ensure iTIP transactions only take
place between authorized calendar users. That would include
preventing one calendar user from scheduling with another, or a
calendar user delegating to another.
6.3. Privacy Issues 6.3. Privacy Issues
The "Organizer" might want to keep "Attendees" from knowing which The "Organizer" might want to keep "Attendees" from knowing which
other "Attendees" are participating in an event or to-do. The other "Attendees" are participating in an event or to-do. The
"Organizer" has the choice of sending single iTIP messages with a "Organizer" has the choice of sending single iTIP messages with a
full list of "Attendees" or sending iTIP messages to each "Attendee" full list of "Attendees" or sending iTIP messages to each "Attendee"
with only that "Attendee" listed. with only that "Attendee" listed.
7. IANA Consideration 7. IANA Consideration
This documents defines the following values for the iCalendar 7.1. Registration Template for REQUEST-STATUS Values
"METHOD" property and these should be added to the Methods Registry
defined in Section 8.3.12 of [I-D.ietf-calsify-rfc2445bis]:
7.1. METHOD:PUBLISH
Value: PUBLISH
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
7.2. METHOD:REQUEST
Value: REQUEST
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
7.3. METHOD:REPLY
Value: REPLY
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
7.4. METHOD:ADD
Value: ADD
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property. This specification updates [RFC5545] by adding a "REQUEST-STATUS"
value registry to the iCalendar Elements registry.
Examples: See this RFC. A "REQUEST-STATUS" value is defined by completing the following
template.
Status Code: Hierarchical, numeric return status code, following the
rules defined in Section 3.8.8.3 of [RFC5545].
Status Description: Textual status description. A short but clear
description of the error.
Status Exception Data: Textual exception data. A short but clear
description of what might appear in this field.
Description: Describe the underlying cause for this status code
value.
7.5. METHOD:CANCEL 7.2. Additions to iCalendar METHOD Registry
Value: CANCEL This documents defines the following values for the iCalendar
"METHOD" property using the values template from Section 8.2.6 of
[RFC5545]. These should be added to the Methods Registry defined in
Section 8.3.12 of [RFC5545]:
Purpose: Standard iTIP "METHOD" value. 7.2.1. METHOD:PUBLISH
Conformance: Only used with the "METHOD" property. Value: PUBLISH
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
Examples: See this RFC. 7.2.2. METHOD:REQUEST
7.6. METHOD:REFRESH Value: REQUEST
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
Value: REFRESH 7.2.3. METHOD:REPLY
Value: REPLY
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
Purpose: Standard iTIP "METHOD" value. 7.2.4. METHOD:ADD
Conformance: Only used with the "METHOD" property. Value: ADD
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
Examples: See this RFC. 7.2.5. METHOD:CANCEL
7.7. METHOD:COUNTER Value: CANCEL
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
Value: COUNTER 7.2.6. METHOD:REFRESH
Purpose: Standard iTIP "METHOD" value. Value: REFRESH
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
Conformance: Only used with the "METHOD" property. 7.2.7. METHOD:COUNTER
Examples: See this RFC. Value: COUNTER
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
7.8. METHOD:DECLINECOUNTER 7.2.8. METHOD:DECLINECOUNTER
Value: DECLINECOUNTER Value: DECLINECOUNTER
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
Purpose: Standard iTIP "METHOD" value. 7.3. REQUEST-STATUS Value Registry
Conformance: Only used with the "METHOD" property. The following table is to be used to initialize the "REQUEST-STATUS"
value registry.
Examples: See this RFC. +-------------+---------+-------------------------+
| Status Code | Status | Reference |
+-------------+---------+-------------------------+
| 2.0 | Current | RFCXXXX, Section 3.6.1 |
| 2.1 | Current | RFCXXXX, Section 3.6.2 |
| 2.2 | Current | RFCXXXX, Section 3.6.3 |
| 2.3 | Current | RFCXXXX, Section 3.6.4 |
| 2.4 | Current | RFCXXXX, Section 3.6.5 |
| 2.5 | Current | RFCXXXX, Section 3.6.6 |
| 2.6 | Current | RFCXXXX, Section 3.6.7 |
| 2.7 | Current | RFCXXXX, Section 3.6.8 |
| 2.8 | Current | RFCXXXX, Section 3.6.9 |
| 2.9 | Current | RFCXXXX, Section 3.6.10 |
| 2.10 | Current | RFCXXXX, Section 3.6.11 |
| 2.11 | Current | RFCXXXX, Section 3.6.12 |
| 3.0 | Current | RFCXXXX, Section 3.6.13 |
| 3.1 | Current | RFCXXXX, Section 3.6.14 |
| 3.2 | Current | RFCXXXX, Section 3.6.15 |
| 3.3 | Current | RFCXXXX, Section 3.6.16 |
| 3.4 | Current | RFCXXXX, Section 3.6.17 |
| 3.5 | Current | RFCXXXX, Section 3.6.18 |
| 3.6 | Current | RFCXXXX, Section 3.6.19 |
| 3.7 | Current | RFCXXXX, Section 3.6.20 |
| 3.8 | Current | RFCXXXX, Section 3.6.21 |
| 3.9 | Current | RFCXXXX, Section 3.6.22 |
| 3.10 | Current | RFCXXXX, Section 3.6.23 |
| 3.11 | Current | RFCXXXX, Section 3.6.24 |
| 3.12 | Current | RFCXXXX, Section 3.6.25 |
| 3.13 | Current | RFCXXXX, Section 3.6.26 |
| 3.14 | Current | RFCXXXX, Section 3.6.27 |
| 4.0 | Current | RFCXXXX, Section 3.6.28 |
| 5.0 | Current | RFCXXXX, Section 3.6.29 |
| 5.1 | Current | RFCXXXX, Section 3.6.30 |
| 5.2 | Current | RFCXXXX, Section 3.6.31 |
| 5.3 | Current | RFCXXXX, Section 3.6.32 |
+-------------+---------+-------------------------+
8. Acknowledgments 8. Acknowledgments
This is an update to the original iTIP document authored by This is an update to the original iTIP document authored by S.
S.Silverberg, S. Mansour, F. Dawson and R. Hopson. Silverberg, S. Mansour, F. Dawson and R. Hopson.
This revision is the product of the Calsify IETF Working Group, and This revision is the product of the Calsify IETF Working Group, and
several participants have made important contributions to this several participants have made important contributions to this
specification, including: Oliver Block, Bernard Desruisseaux, Mike specification, including: Oliver Block, Bernard Desruisseaux, Mike
Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot
Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg
II, Robert Ransdell, Caleb Richardson. II, Robert Ransdell, Caleb Richardson.
9. Normative References 9. References
[I-D.ietf-calsify-rfc2445bis]
Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)",
draft-ietf-calsify-rfc2445bis-09 (work in progress),
October 2008.
[I-D.ietf-calsify-rfc2447bis]
Melnikov, A., "iCalendar Message-Based Interoperability
Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-05 (work
in progress), June 2008.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 9.1. Normative References
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
October 2008. URL scheme", RFC 2368, July 1998.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 2009.
9.2. Informative References
[I-D.ietf-calsify-rfc2447bis]
Melnikov, A., "iCalendar Message-Based Interoperability
Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-06 (work
in progress), September 2009.
Appendix A. Differences from RFC 2446 Appendix A. Differences from RFC 2446
A.1. Changed Restrictions A.1. Changed Restrictions
This specification now defines an allowed combination of "REQUEST- This specification now defines an allowed combination of "REQUEST-
STATUS" codes when multiple iCalendar components are included in an STATUS" codes when multiple iCalendar components are included in an
iTIP message. iTIP message.
This specification now restricts "RECURRENCE-ID" to only a single This specification now restricts "RECURRENCE-ID" to only a single
occurrence in any one iCalendar component in an iTIP message as occurrence in any one iCalendar component in an iTIP message as
required by [I-D.ietf-calsify-rfc2445bis]. required by [RFC5545].
Changed "RECURRENCE-ID" entry in component restriction table to "0 or Changed "RECURRENCE-ID" entry in component restriction table to "0 or
1" from "0+" to fall in line with [I-D.ietf-calsify-rfc2445bis]. 1" from "0+" to fall in line with [RFC5545].
Changed "FREEBUSY" entry in "VFREEBUSY" "PUBLISH" and "REPLY" Changed "FREEBUSY" entry in "VFREEBUSY" "PUBLISH" and "REPLY"
restriction table to "0+" from "1+" to fall in line with restriction table to "0+" from "1+" to fall in line with [RFC5545].
[I-D.ietf-calsify-rfc2445bis].
Changed "FREEBUSY" description in "VFREEBUSY" "REPLY" restriction Changed "FREEBUSY" description in "VFREEBUSY" "REPLY" restriction
table to indicate that different "FBTYPE" ranges MUST NOT overlap. table to indicate that different "FBTYPE" ranges MUST NOT overlap.
Changed "TZNAME" entry in "VTIMEZONE" restriction table to "0+" from Changed "TZNAME" entry in "VTIMEZONE" restriction table to "0+" from
"0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis]. "0 or 1" to fall in line with [RFC5545].
Changed "COMMENT" entry in component restriction tables to "0+" from Changed "COMMENT" entry in component restriction tables to "0+" from
"0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis]. "0 or 1" to fall in line with [RFC5545].
Added "ATTENDEE" entry in "VALARM" restriction table to match email Added "ATTENDEE" entry in "VALARM" restriction table to match email
alarm type in [I-D.ietf-calsify-rfc2445bis]. alarm type in [RFC5545].
Changed "CATEGORIES" entry in component restriction tables to "0+" Changed "CATEGORIES" entry in component restriction tables to "0+"
from "0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis]. from "0 or 1" to fall in line with [RFC5545].
Changed "RESOURCES" entry in component restriction tables to "0+" Changed "RESOURCES" entry in component restriction tables to "0+"
from "0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis]. from "0 or 1" to fall in line with [RFC5545].
Changed "CONTACT" entry in "VFREEBUSY" restriction table to "0 or 1" Changed "CONTACT" entry in "VFREEBUSY" restriction table to "0 or 1"
from "0+" to fall in line with [I-D.ietf-calsify-rfc2445bis]. from "0+" to fall in line with [RFC5545].
Changed "UID" entry in "VFREEBUSY" "PUBLISH" restriction table to "1" Changed "UID" entry in "VFREEBUSY" "PUBLISH" restriction table to "1"
from "0" to fall in line with [I-D.ietf-calsify-rfc2445bis]. from "0" to fall in line with [RFC5545].
Added "COMPLETED" entry in "VTODO" restriction tables to fall in line Added "COMPLETED" entry in "VTODO" restriction tables to fall in line
with [I-D.ietf-calsify-rfc2445bis]. with [RFC5545].
Added "REQUEST-STATUS" entry in "VJOURNAL" restriction tables to fall Added "REQUEST-STATUS" entry in "VJOURNAL" restriction tables to fall
in line with [I-D.ietf-calsify-rfc2445bis]. in line with [RFC5545].
A.2. Deprecated features A.2. Deprecated features
The "EXRULE" property was removed in [I-D.ietf-calsify-rfc2445bis] The "EXRULE" property was removed in [RFC5545] and references to that
and references to that have been removed in this document too. have been removed in this document too.
The "PROCEDURE" value for the "ACTION" property was removed in The "PROCEDURE" value for the "ACTION" property was removed in
[I-D.ietf-calsify-rfc2445bis] and references to that have been [RFC5545] and references to that have been removed in this document
removed in this document too. too.
The "THISANDFUTURE" option for the "RANGE" parameter was removed in The "THISANDPRIOR" option for the "RANGE" parameter was removed in
[I-D.ietf-calsify-rfc2445bis] and references to that have been [RFC5545] and references to that have been removed in this document
removed in this document too. too.
Appendix B. Change History (to be removed prior to publication as an Appendix B. Change History (to be removed prior to publication as an
RFC) RFC)
Changes in -09: Changes in -10:
a. Gen-ART: changed section title "Eavesdropping" to "Eavesdropping
and Data Integrity".
b. SecDir: changed "encrypted" to "encrypted and authenticated" in
6.2.
c. SecDir: removed S/MIME reference and changed text to just talk
about "generic" authentication and encryption.
d. SecDir: added access controls and filtering section.
e. IESG: fixed "THISANDFUTURE" -> "THISANDPRIOR" in A.2.
f. IESG: 2447bis is now an informative reference.
g. IESG: Changed text about email groups to reference mailto URI.
h. IESG: tweaked fallback text for free/busy methods.
i. IESG: fallback for DURATION in events and to-dos now required.
j. IESG: removed last sentence in 6.2.1.
k. IESG: added reference to values template section in 2445bis in
IANA section.
l. IESG: clarified that 2.0 is the default REQUEST-STATUS if the
property is not present.
m. IANA: added registry for REQUEST-STATUS codes.
n. Updated to RFC 5545 reference!
o. Fixed minor typos.
Changes in -09:
a. Updated to RFC5322 reference. a. Updated to RFC5322 reference.
b. Fixed more issues from Reinhold Kainhofer review being tracked on b. Fixed more issues from Reinhold Kainhofer review being tracked on
the WG wiki. the WG wiki.
Changes in -08: Changes in -08:
a. AD review: Changed "calendar entry" to "iCalendar object". a. AD review: Changed "calendar entry" to "iCalendar object".
b. AD review: Added extra captions above restriction tables for more b. AD review: Added extra captions above restriction tables for more
clarity. clarity.
c. AD review: Added missing step of uninvited CU replying to c. AD review: Added missing step of uninvited CU replying to
Organizer in description of event forwarding. Organizer in description of event forwarding.
 End of changes. 71 change blocks. 
369 lines changed or deleted 593 lines changed or added

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