draft-ietf-calsify-2446bis-06.txt   draft-ietf-calsify-2446bis-07.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) May 11, 2008 Obsoletes: 2446 (if approved) July 14, 2008
Intended status: Standards Track Intended status: Standards Track
Expires: November 12, 2008 Expires: January 15, 2009
iCalendar Transport-Independent Interoperability Protocol (iTIP) iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-06 draft-ietf-calsify-2446bis-07
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 35 skipping to change at page 1, line 35
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 November 12, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies a protocol using the iCalendar object This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between specification to provide scheduling interoperability between
different calendar systems. This is done without reference to a different calendar systems. This is done without reference to a
specific transport protocol so as to allow multiple methods of specific transport protocol so as to allow multiple methods of
communication between systems. Subsequent documents will define communication between systems. Subsequent documents will define
profiles of this protocol using specific interoperable methods of profiles of this protocol using specific interoperable methods of
communications between systems. communications between systems.
skipping to change at page 3, line 16 skipping to change at page 3, line 13
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 56 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 60
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 62 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 62
3.7. Implementation Considerations . . . . . . . . . . . . . . 65 3.7. Implementation Considerations . . . . . . . . . . . . . . 65
3.7.1. Working With Recurrence Instances . . . . . . . . . . 65 3.7.1. Working With Recurrence Instances . . . . . . . . . . 65
3.7.2. Attendee Property Considerations . . . . . . . . . . 66 3.7.2. Attendee Property Considerations . . . . . . . . . . 66
3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 67 3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 67
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1. Published Event Examples . . . . . . . . . . . . . . . . 67 4.1. Published Event Examples . . . . . . . . . . . . . . . . 67
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 68 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 67
4.1.2. Changing A Published Event . . . . . . . . . . . . . 68 4.1.2. Changing A Published Event . . . . . . . . . . . . . 68
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 69 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 69
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 69 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 69
4.1.5. Anniversaries or Events attached to entire days . . . 71 4.1.5. Anniversaries or Events attached to entire days . . . 70
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 71 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 71
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 72 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 72
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 73 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 72
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 73 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 73
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 74 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 74
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 77 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 76
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 79 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 78
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 80 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 79
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 81 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 80
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 81 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 80
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 82 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 82
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 84 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 83
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 85 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 84
4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 86 4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 85
4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 87 4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 86
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 87 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 86
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 87 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 86
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 89 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 88
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 91 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 90
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 92 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 91
4.4.5. Change All Future Instances . . . . . . . . . . . . . 92 4.4.5. Change All Future Instances . . . . . . . . . . . . . 91
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 93 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 92
4.4.7. Add A New Series of Instances To A Recurring Event . 94 4.4.7. Add A New Series of Instances To A Recurring Event . 93
4.4.8. Counter An Instance Of A Recurring Event . . . . . . 99 4.4.8. Counter An Instance Of A Recurring Event . . . . . . 98
4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 100 4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 99
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 102 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 101
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 103 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 102
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 103 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 102
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 104 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 103
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 104 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 103
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 105 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 104
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 105 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 104
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 106 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 105
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 107 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 106
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 108 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 107
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 108 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 107
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 108 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 107
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 111 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 110
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 111 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 110
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 111 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 110
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 113 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 112
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 114 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 113
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 116 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 115
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 117 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 116
5.2.1. Cancellation of an Unknown Calendar Component. . . . 117 5.2.1. Cancellation of an Unknown Calendar Component. . . . 116
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 118 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 117
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 118 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 117
6. Security Considerations . . . . . . . . . . . . . . . . . . . 118 6. Security Considerations . . . . . . . . . . . . . . . . . . . 117
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 118 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 117
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 118 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 117
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 118 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 117
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 119 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 118
6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 119 6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 118
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 119 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 118
6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 119 6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 118
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 119 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 118
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 119 6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 118
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 120 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 119
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 120 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 119
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.1. METHOD:PUBLISH . . . . . . . . . . . . . . . . . . . . . 120
8.1. Normative References . . . . . . . . . . . . . . . . . . 121 7.2. METHOD:REQUEST . . . . . . . . . . . . . . . . . . . . . 120
8.2. Informative References . . . . . . . . . . . . . . . . . 121 7.3. METHOD:REPLY . . . . . . . . . . . . . . . . . . . . . . 120
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 121 7.4. METHOD:ADD . . . . . . . . . . . . . . . . . . . . . . . 120
7.5. METHOD:CANCEL . . . . . . . . . . . . . . . . . . . . . . 121
7.6. METHOD:REFRESH . . . . . . . . . . . . . . . . . . . . . 121
7.7. METHOD:COUNTER . . . . . . . . . . . . . . . . . . . . . 121
7.8. METHOD:DECLINE-COUNTER . . . . . . . . . . . . . . . . . 121
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 121
9. Normative References . . . . . . . . . . . . . . . . . . . . 122
Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 122
A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 122
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 123
Appendix B. Change History (to be removed prior to Appendix B. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 121 publication as an RFC) . . . . . . . . . . . . . . . 123
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 123 Appendix C. Change History (to be removed prior to
Intellectual Property and Copyright Statements . . . . . . . . . 124 publication as an RFC) . . . . . . . . . . . . . . . 124
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 125
Intellectual Property and Copyright Statements . . . . . . . . . 126
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 [I-D.ietf-calsify-rfc2445bis] objects to interoperate with other
calendar systems. In particular, it specifies how to schedule calendar systems. In particular, it specifies how to schedule
events, to-dos, or daily journal entries. It further specifies how events, to-dos, or daily journal entries. It further specifies how
to search for available busy time information. It does so in a to search for available busy time information. It does so in a
general way without specifying how communication between different general way without specifying how communication between different
systems actually takes place. Subsequent documents specify transport systems actually takes place. Subsequent documents specify transport
skipping to change at page 5, line 25 skipping to change at page 5, line 25
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.
This specification obsoletes RFC 2446 - a list of important changes
is provided in Appendix A.
1.1. Formatting Conventions 1.1. Formatting Conventions
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.
skipping to change at page 26, line 23 skipping to change at page 26, line 23
"RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
order to cancel an individual instance of the event, the order to cancel an individual instance of the event, the
"RECURRENCE-ID" property value for the event MUST be specified in the "RECURRENCE-ID" property value for the event MUST be specified in the
"CANCEL" method. "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
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 "VEVENT" "THISANDFUTURE" to indicate cancellation of the specified
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.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
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 48, line 7 skipping to change at page 48, line 7
ID" MUST NOT be specified in the "CANCEL" method. In order to cancel ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
an individual instance of a recurring "VTODO" calendar component, the an individual instance of a recurring "VTODO" calendar component, the
"RECURRENCE-ID" property value for the "VTODO" calendar component "RECURRENCE-ID" property value for the "VTODO" calendar component
MUST be specified in the "CANCEL" method. MUST be specified in the "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
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
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
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 60, line 23 skipping to change at page 60, line 23
entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be
specified in the "CANCEL" method. In order to cancel an individual specified in the "CANCEL" method. In order to cancel an individual
instance of the journal entry, the "RECURRENCE-ID" property value for instance of the journal entry, the "RECURRENCE-ID" property value for
the journal entry MUST be specified in the "CANCEL" method. the journal entry MUST be specified in the "CANCEL" method.
There are two options for canceling a sequence of instances of a There are two options for canceling a sequence of instances of a
recurring "VJOURNAL" calendar component: recurring "VJOURNAL" 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 "VJOURNAL" components with a "RECURRENCE-ID" property multiple "VJOURNAL" components with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled corresponding to one of the instances to be cancelled
When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
incremented. incremented.
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 66, line 47 skipping to change at page 66, line 43
email to such an address results in mail being sent to multiple email to such an address results in mail 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
'CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User" 'CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User"
is a member of one of these groups. If so, the "REPLY" method is a member of one of these groups. If so, the "REPLY" method
sent to the "Organizer" MUST contain a new "ATTENDEE" property in sent to the "Organizer" MUST contain a new "ATTENDEE" property in
which: which:
3.
* the "TYPE" property parameter is set to INDIVIDUAL * the "TYPE" property parameter is set to INDIVIDUAL
* the "MEMBER" property parameter is set to the name of the * the "MEMBER" property parameter is set to the name of the
group group
4. Failing (2) the CUA MAY ignore or accept the request as the
3. Failing (2) the CUA MAY ignore or accept the request as the
"Calendar User" wishes. "Calendar User" wishes.
3.7.3. X-Tokens 3.7.3. X-Tokens
To make iCalendar objects extensible, new property types MAY be To make iCalendar objects extensible, new property types MAY be
inserted into components. These properties are called X-Tokens as inserted into components. These properties are called X-Tokens as
they are prefixed with "X-". A client is not required to make sense they are prefixed with "X-". A client is not required to make sense
of X-Tokens. Clients are not required to save X-Tokens or use them of X-Tokens. Clients are not required to save X-Tokens or use them
in replies. in replies.
skipping to change at page 120, line 46 skipping to change at page 119, line 46
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.
7. IANA Consideration 7. IANA Consideration
TBD. Will be based on 2445bis changes. This documents defines the following values for the iCalendar
"METHOD" property:
8. References 7.1. METHOD:PUBLISH
8.1. Normative References 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.
Examples: See this RFC.
7.5. METHOD:CANCEL
Value: CANCEL
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
7.6. METHOD:REFRESH
Value: REFRESH
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
7.7. METHOD:COUNTER
Value: COUNTER
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
7.8. METHOD:DECLINE-COUNTER
Value: DECLINE-COUNTER
Purpose: Standard iTIP "METHOD" value.
Conformance: Only used with the "METHOD" property.
Examples: See this RFC.
8. Acknowledgments
This is an update to the original iTIP document authored by
S.Silverberg, S. Mansour, F. Dawson and R. Hopson.
This revision is the product of the Calsify IETF Working Group, and
several participants have made important contributions to this
specification, including: Oliver Block, Bernard Desruisseaux, Mike
Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot
Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg
II, Robert Ransdell, Caleb Richardson.
9. Normative References
[I-D.ietf-calsify-rfc2445bis] [I-D.ietf-calsify-rfc2445bis]
Desruisseaux, B., "Internet Calendaring and Scheduling Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", Core Object Specification (iCalendar)",
draft-ietf-calsify-rfc2445bis-07 (work in progress), draft-ietf-calsify-rfc2445bis-08 (work in progress),
July 2007. February 2008.
[I-D.ietf-calsify-rfc2447bis] [I-D.ietf-calsify-rfc2447bis]
Melnikov, A., "iCalendar Message-Based Interoperability Melnikov, A., "iCalendar Message-Based Interoperability
Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-03 (work Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-04 (work
in progress), February 2007. in progress), May 2008.
[RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. 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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
8.2. Informative References Appendix A. Differences from RFC 2446
Appendix A. Acknowledgments A.1. Changed Restrictions
This is an update to the original iTIP document authored by This specification now defines an allowed combination of "REQUEST-
S.Silverberg, S. Mansour, F. Dawson and R. Hopson. STATUS" codes when multiple iCalendar components are included in an
iTIP message.
This revision is the product of the Calsify IETF Working Group, and This specification now restricts "RECURRENCE-ID" to only a single
several participants have made important contributions to this occurrence in any one iCalendar component in an iTIP message as
specification, including: Oliver Block, Bernard Desruisseaux, Mike required by [I-D.ietf-calsify-rfc2445bis].
Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot
Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg Changed "RECURRENCE-ID" entry in component restriction table to "0 or
II, Robert Ransdell, Caleb Richardson. 1" from "0+" to fall in line with [I-D.ietf-calsify-rfc2445bis].
Changed "FREEBUSY" entry in "VFREEBUSY" "PUBLISH" and "REPLY"
restriction table to "0+" from "1+" to fall in line with
[I-D.ietf-calsify-rfc2445bis].
Changed "FREEBUSY" description in "VFREEBUSY" "REPLY" restriction
table to indicate that different "FBTYPE" ranges MUST NOT overlap.
Changed "TZNAME" entry in "VTIMEZONE" restriction table to "0+" from
"0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis].
Changed "COMMENT" entry in component restriction tables to "0+" from
"0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis].
Added "ATTENDEE" entry in "VALARM" restriction table to match email
alarm type in [I-D.ietf-calsify-rfc2445bis].
Changed "CATEGORIES" entry in component restriction tables to "0+"
from "0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis].
Changed "RESOURCES" entry in component restriction tables to "0+"
from "0 or 1" to fall in line with [I-D.ietf-calsify-rfc2445bis].
Changed "CONTACT" entry in "VFREEBUSY" restriction table to "0 or 1"
from "0+" to fall in line with [I-D.ietf-calsify-rfc2445bis].
Changed "UID" entry in "VFREEBUSY" "PUBLISH" restriction table to "1"
from "0" to fall in line with [I-D.ietf-calsify-rfc2445bis].
Added "COMPLETED" entry in "VTODO" restriction tables to fall in line
with [I-D.ietf-calsify-rfc2445bis].
Added "REQUEST-STATUS" entry in "VJOURNAL" restriction tables to fall
in line with [I-D.ietf-calsify-rfc2445bis].
A.2. Deprecated features
The "EXRULE" property was removed in [I-D.ietf-calsify-rfc2445bis]
and references to that have been removed in this document too.
The "PROCEDURE" value for the "ACTION" property was removed in
[I-D.ietf-calsify-rfc2445bis] and references to that have been
removed in this document too.
The "THISANDFUTURE" option for the "RANGE" parameter was removed in
[I-D.ietf-calsify-rfc2445bis] and references to that have been
removed in this document 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 -07:
a. IANA considerations now registers METHOD values.
b. Added Appendix with key 2446 changes and text to the introduction
pointing to that.
Appendix C. Change History (to be removed prior to publication as an
RFC)
Changes in -06: Changes in -06:
a. Added text to SEQUENCE number description about detecting a a. Added text to SEQUENCE number description about detecting a
significant change. significant change.
b. Added text to REQUEST-STATUS section describing the allowed b. Added text to REQUEST-STATUS section describing the allowed
combinations of codes. combinations of codes.
c. Added text to REQUEST-STATUS section to require new codes to be c. Added text to REQUEST-STATUS section to require new codes to be
defined in a standard or experimental RFC. defined in a standard or experimental RFC.
d. Removed THISANDFUTURE. d. Removed THISANDFUTURE.
e. Cleaned up some examples. e. Cleaned up some examples.
Changes in -05: Changes in -05:
a. Changed "memo" to "specification". a. Changed "memo" to "specification".
b. Removed EXRULE as it is no longer in 2445bis. b. Removed EXRULE as it is no longer in 2445bis.
c. Removed section on PROCEDURE alarms since those are no longer in c. Removed section on PROCEDURE alarms since those are no longer in
2445bis. 2445bis.
skipping to change at page 124, line 44 skipping to change at line 5472
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 31 change blocks. 
100 lines changed or deleted 252 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/