tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5546

 Errata 
Proposed STD
Pages: 133
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: CALSIFY

iCalendar Transport-Independent Interoperability Protocol (iTIP)

Part 1 of 5, p. 1 to 13
None       Next RFC Part

Obsoletes:    2446
Updates:    5545
Updated by:    6638


Top       ToC       Page 1 
Network Working Group                                      C. Daboo, Ed.
Request for Comments: 5546                                    Apple Inc.
Obsoletes: 2446                                            December 2009
Updates: 5545
Category: Standards Track


    iCalendar Transport-Independent Interoperability Protocol (iTIP)

Abstract

   This document specifies a protocol that uses the iCalendar object
   specification to provide scheduling interoperability between
   different calendaring systems.  This is done without reference to a
   specific transport protocol so as to allow multiple methods of
   communication between systems.  Subsequent documents will define
   profiles of this protocol that use specific, interoperable methods of
   communication between systems.

   The iCalendar Transport-Independent Interoperability Protocol (iTIP)
   complements the iCalendar object specification by adding semantics
   for group scheduling methods commonly available in current
   calendaring systems.  These scheduling methods permit two or more
   calendaring systems to perform transactions such as publishing,
   scheduling, rescheduling, responding to scheduling requests,
   negotiating changes, or canceling.

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Page 2 
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction and Overview .......................................5
      1.1. Formatting Conventions .....................................5
      1.2. Related Documents ..........................................6
      1.3. Roles ......................................................6
      1.4. Methods ....................................................7
   2. Interoperability Models .........................................9
      2.1. Application Protocol ......................................10
           2.1.1. Scheduling State ...................................10
           2.1.2. Delegation .........................................10
           2.1.3. Acting on Behalf of Other Calendar Users ...........11
           2.1.4. Component Revisions ................................11
           2.1.5. Message Sequencing .................................12
   3. Application Protocol Elements ..................................13
      3.1. Common Component Restriction Tables .......................15
           3.1.1. VCALENDAR ..........................................15
           3.1.2. VTIMEZONE ..........................................15
           3.1.3. VALARM .............................................17
      3.2. Methods for VEVENT Calendar Components ....................17
           3.2.1. PUBLISH ............................................18
           3.2.2. REQUEST ............................................20
           3.2.3. REPLY ..............................................25
           3.2.4. ADD ................................................27
           3.2.5. CANCEL .............................................29
           3.2.6. REFRESH ............................................31
           3.2.7. COUNTER ............................................33
           3.2.8. DECLINECOUNTER .....................................35
      3.3. Methods for VFREEBUSY Components ..........................37
           3.3.1. PUBLISH ............................................37
           3.3.2. REQUEST ............................................40
           3.3.3. REPLY ..............................................42

Top      ToC       Page 3 
      3.4. Methods for VTODO Components ..............................44
           3.4.1. PUBLISH ............................................44
           3.4.2. REQUEST ............................................46
           3.4.3. REPLY ..............................................51
           3.4.4. ADD ................................................53
           3.4.5. CANCEL .............................................55
           3.4.6. REFRESH ............................................57
           3.4.7. COUNTER ............................................59
           3.4.8. DECLINECOUNTER .....................................61
      3.5. Methods for VJOURNAL Components ...........................62
           3.5.1. PUBLISH ............................................63
           3.5.2. ADD ................................................64
           3.5.3. CANCEL .............................................66
      3.6. Status Replies ............................................68
      3.7. Implementation Considerations .............................77
           3.7.1. Working With Recurrence Instances ..................77
           3.7.2. Attendee Property Considerations ...................78
           3.7.3. Extension Tokens ...................................79
   4. Examples .......................................................79
      4.1. Published Event Examples ..................................79
           4.1.1. A Minimal Published Event ..........................80
           4.1.2. Changing a Published Event .........................80
           4.1.3. Canceling a Published Event ........................81
           4.1.4. A Rich Published Event .............................81
           4.1.5. Anniversaries or Events Attached to Entire Days ....83
      4.2. Group Event Examples ......................................83
           4.2.1. A Group Event Request ..............................84
           4.2.2. Reply to a Group Event Request .....................85
           4.2.3. Update an Event ....................................85
           4.2.4. Countering an Event Proposal .......................86
           4.2.5. Delegating an Event ................................88
           4.2.6. Delegate Accepts the Meeting .......................90
           4.2.7. Delegate Declines the Meeting ......................91
           4.2.8. Forwarding an Event Request ........................92
           4.2.9. Cancel a Group Event ...............................92
           4.2.10. Removing Attendees ................................93
           4.2.11. Replacing the Organizer ...........................95
      4.3. Busy Time Examples ........................................96
           4.3.1. Publish Busy Time ..................................96
           4.3.2. Request Busy Time ..................................96
           4.3.3. Reply to a Busy Time Request .......................97
      4.4. Recurring Event and Time Zone Examples ....................98
           4.4.1. A Recurring Event Spanning Time Zones ..............98
           4.4.2. Modify a Recurring Instance ........................99
           4.4.3. Cancel an Instance ................................101
           4.4.4. Cancel a Recurring Event ..........................101
           4.4.5. Change All Future Instances .......................102
           4.4.6. Add a New Instance to a Recurring Event ...........102

Top      ToC       Page 4 
           4.4.7. Add a New Series of Instances to a
                  Recurring Event ...................................103
           4.4.8. Refreshing a Recurring Event ......................104
           4.4.9. Counter an Instance of a Recurring Event ..........106
           4.4.10. Error Reply to a Request .........................107
      4.5. Group To-Do Examples .....................................108
           4.5.1. A VTODO Request ...................................109
           4.5.2. A VTODO Reply .....................................110
           4.5.3. A VTODO Request for Updated Status ................110
           4.5.4. A Reply: Percent-Complete .........................111
           4.5.5. A Reply: Completed ................................111
           4.5.6. An Updated VTODO Request ..........................112
           4.5.7. Recurring VTODOs ..................................112
      4.6. Journal Examples .........................................113
      4.7. Other Examples ...........................................114
           4.7.1. Event Refresh .....................................114
           4.7.2. Bad RECURRENCE-ID .................................114
   5. Application Protocol Fallbacks ................................116
      5.1. Partial Implementation ...................................116
           5.1.1. Event-Related Fallbacks ...........................117
           5.1.2. Free/Busy-Related Fallbacks .......................119
           5.1.3. To-Do-Related Fallbacks ...........................120
           5.1.4. Journal-Related Fallbacks .........................122
      5.2. Latency Issues ...........................................123
           5.2.1. Cancellation of an Unknown Calendar Component .....123
           5.2.2. Unexpected Reply from an Unknown Delegate .........124
      5.3. Sequence Number ..........................................124
   6. Security Considerations .......................................124
      6.1. Security Threats .........................................124
           6.1.1. Spoofing the Organizer ............................124
           6.1.2. Spoofing the Attendee .............................124
           6.1.3. Unauthorized Replacement of the Organizer .........125
           6.1.4. Eavesdropping and Data Integrity ..................125
           6.1.5. Flooding a Calendar ...............................125
           6.1.6. Unauthorized REFRESH Requests .....................125
      6.2. Recommendations ..........................................125
           6.2.1. Securing iTIP transactions ........................125
           6.2.2. Implementation Controls ...........................126
           6.2.3. Access Controls and Filtering .....................126
      6.3. Privacy Issues ...........................................126
   7. IANA Considerations ...........................................127
      7.1. Registration Template for REQUEST-STATUS Values ..........127
      7.2. Additions to iCalendar METHOD Registry ...................127
      7.3. REQUEST-STATUS Value Registry ............................129
   8. Acknowledgments ...............................................130
   9. References ....................................................131
      9.1. Normative References .....................................131
      9.2. Informative References ...................................131

Top      ToC       Page 5 
   Appendix A.  Differences from RFC 2446 ...........................132
     A.1.  Changed Restrictions .....................................132
     A.2.  Deprecated Features ......................................133

1.  Introduction and Overview

   This document specifies how calendaring systems use iCalendar
   [RFC5545] objects to interoperate with other calendaring systems.  In
   particular, it specifies how to schedule events, to-dos, or daily
   journal entries.  It further specifies how to search for available
   busy time information.  It does so in a general way, without
   specifying how communication between different systems actually takes
   place.  Subsequent documents will specify transport bindings between
   systems that use this protocol.

   This protocol is based on messages sent from an originator to one or
   more recipients.  For certain types of messages, a recipient may
   reply in order to update their status and may also return
   transaction/request status information.  The protocol supports the
   ability for the message originator to modify or cancel the original
   message.  The protocol also supports the ability for recipients to
   suggest changes to the originator of a message.  The elements of the
   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Calendaring and scheduling roles are referred to in quoted-strings of
   text with the first character of each word in upper case.  For
   example, "Organizer" refers to a role of a "Calendar User" (CU)
   within the scheduling protocol.

   Calendar components defined by [RFC5545] are referred to with
   capitalized, quoted-strings of text.  All calendar components start
   with the letter "V".  For example, "VEVENT" refers to the event
   calendar component, "VTODO" refers to the to-do calendar component,
   and "VJOURNAL" refers to the daily journal calendar component.

Top      ToC       Page 6 
   Scheduling methods are referred to with capitalized, quoted-strings
   of text.  For example, "REQUEST" refers to the method for requesting
   a scheduling calendar component be created or modified; "REPLY"
   refers to the method a recipient of a request uses to update their
   status with the "Organizer" of the calendar component.

   Properties defined by [RFC5545] are referred to with capitalized,
   quoted-strings of text, followed by the word "property".  For
   example, "ATTENDEE" property refers to the iCalendar property used to
   convey the calendar address of a "Calendar User".

   Property parameters defined by this specification are referred to
   with capitalized, quoted-strings of text, followed by the word
   "parameter".  For example, "VALUE" parameter refers to the iCalendar
   property parameter used to override the default data type for a
   property value.

   Enumerated values defined by this specification are referred to with
   capitalized text, either alone or followed by the word "value".

   In tables, the quoted-string text is specified without quotes in
   order to minimize the table length.

1.2.  Related Documents

   Implementers will need to be familiar with several other
   specifications that, along with this one, describe the Internet
   calendaring and scheduling standards.  The related documents are:

      [RFC5545] - specifies the objects, data types, properties, and
      property parameters used in the protocols, along with the methods
      for representing and encoding them.

      [iMIP] - specifies an Internet email binding for iTIP.

   This specification does not attempt to repeat the concepts or
   definitions from these other specifications.  Where possible,
   explicit references are made to the other specifications.

1.3.  Roles

   Exchanges of iCalendar objects for the purposes of group calendaring
   and scheduling occur between "Calendar Users" (CUs).  CUs take on
   several roles in iTIP:

Top      ToC       Page 7 
   +-----------+-------------------------------------------------------+
   | Role      | Description                                           |
   +-----------+-------------------------------------------------------+
   | Organizer | The CU who initiates an exchange takes on the role of |
   |           | Organizer.  For example, the CU who proposes a group  |
   |           | meeting is the Organizer.                             |
   |           |                                                       |
   | Attendee  | CUs who are included in the scheduling message as     |
   |           | possible recipients of that scheduling message.  For  |
   |           | example, the CUs asked to participate in a group      |
   |           | meeting by the Organizer take on the role of          |
   |           | Attendee.                                             |
   |           |                                                       |
   | Other CU  | A CU that is not explicitly included in a scheduling  |
   |           | message, i.e., not the Organizer or an Attendee.      |
   +-----------+-------------------------------------------------------+

   Note that "ROLE" is also a descriptive parameter to the iCalendar
   "ATTENDEE" property.  Its use is to convey descriptive context about
   an "Attendee" -- such as "chair", "required participant", or "non-
   required participant" -- and has nothing to do with the calendaring
   workflow.

1.4.  Methods

   The iTIP methods are listed below and their usage and semantics are
   defined in Section 3 of this document.

Top      ToC       Page 8 
   +----------------+--------------------------------------------------+
   | Method         | Description                                      |
   +----------------+--------------------------------------------------+
   | PUBLISH        | Used to publish an iCalendar object to one or    |
   |                | more "Calendar Users".  There is no              |
   |                | interactivity between the publisher and any      |
   |                | other "Calendar User".  An example might include |
   |                | a baseball team publishing its schedule to the   |
   |                | public.                                          |
   |                |                                                  |
   | REQUEST        | Used to schedule an iCalendar object with other  |
   |                | "Calendar Users".  Requests are interactive in   |
   |                | that they require the receiver to respond using  |
   |                | the reply methods.  Meeting requests, busy-time  |
   |                | requests, and the assignment of tasks to other   |
   |                | "Calendar Users" are all examples.  Requests are |
   |                | also used by the Organizer to update the status  |
   |                | of an iCalendar object.                          |
   |                |                                                  |
   | REPLY          | A reply is used in response to a request to      |
   |                | convey Attendee status to the Organizer.         |
   |                | Replies are commonly used to respond to meeting  |
   |                | and task requests.                               |
   |                |                                                  |
   | ADD            | Add one or more new instances to an existing     |
   |                | recurring iCalendar object.                      |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | iCalendar object.                                |
   |                |                                                  |
   | REFRESH        | Used by an Attendee to request the latest        |
   |                | version of an iCalendar object.                  |
   |                |                                                  |
   | COUNTER        | Used by an Attendee to negotiate a change in an  |
   |                | iCalendar object.  Examples include the request  |
   |                | to change a proposed event time or change the    |
   |                | due date for a task.                             |
   |                |                                                  |
   | DECLINECOUNTER | Used by the Organizer to decline the proposed    |
   |                | counter proposal.                                |
   +----------------+--------------------------------------------------+

Top      ToC       Page 9 
   Group scheduling in iTIP is accomplished using the set of "request"
   and "response" methods described above.  The following table shows
   the methods broken down by who can send them.

   +------------+------------------------------------------------------+
   | Originator | Methods                                              |
   +------------+------------------------------------------------------+
   | Organizer  | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER        |
   |            |                                                      |
   | Attendee   | REPLY, REFRESH, COUNTER, REQUEST (only when          |
   |            | delegating)                                          |
   +------------+------------------------------------------------------+

   Note that for some calendar component types, the allowable methods
   are a subset of the above set.  In addition, apart from "VTIMEZONE"
   iCalendar components, only one component type is allowed in a single
   iTIP message.

2.  Interoperability Models

   There are two distinct protocols relevant to interoperability: an
   "application protocol" and a "transport protocol".  The application
   protocol defines the content of the iCalendar objects sent between
   sender and receiver to accomplish the scheduling transactions listed
   above.  The transport protocol defines how the iCalendar objects are
   sent between the sender and receiver.  This document focuses on the
   application protocol.  Binding documents such as [iMIP] focus on the
   transport protocol.

   The connection between sender and receiver in the diagram below
   refers to the application protocol.  The iCalendar objects passed
   from the sender to the receiver are presented in Section 3,
   "Application Protocol Elements".

           +----------+                +----------+
           |          |      iTIP      |          |
           |  Sender  |<-------------->| Receiver |
           |          |                |          |
           +----------+                +----------+

   There are several variations of this diagram in which the sender and
   receiver take on various roles of a "Calendar User Agent" (CUA) or a
   "Calendar Service" (CS).

   The architecture of iTIP is depicted in the diagram below.  An
   application written to this specification may work with bindings for
   the store-and-forward transport, the real-time transport, or both.
   Also note that iTIP could be bound to other transports.

Top      ToC       Page 10 
      +--------------------------------------------------------+
      |                     iTIP Protocol                      |
      +--------------------------------------------------------+
      |                       Transport                        |
      +  -  -  -  -  -  +  -  -  -  -  -  -  +  -  -  -  -  -  +
      | Real-Time       | Store-and-Forward  | Others          |
      +-----------------+--------------------+-----------------+

2.1.  Application Protocol

   In the iTIP model, an iCalendar object is created and managed by an
   "Organizer".  The "Organizer" interacts with other CUs by sending one
   or more of the iTIP messages listed above.  "Attendees" use the
   "REPLY" method to communicate their status.  "Attendees" do not make
   direct changes to the master iCalendar object.  They can, however,
   use the "COUNTER" method to suggest changes to the "Organizer".  In
   any case, the "Organizer" has complete control over the master
   iCalendar object.

2.1.1.  Scheduling State

   There are two distinct states relevant to iCalendar objects used in
   scheduling: the overall state of the iCalendar object and the state
   associated with an "Attendee" in that iCalendar object.

   The state of an iCalendar object is defined by the "STATUS" property
   and is controlled by the "Organizer."  There is no default value for
   the "STATUS" property.  The "Organizer" sets the "STATUS" property to
   the appropriate value for each iCalendar object.

   The state of a particular "Attendee" relative to an iCalendar object
   used for scheduling is defined by the "PARTSTAT" parameter in the
   "ATTENDEE" property for each "Attendee".  When an "Organizer" issues
   the initial iCalendar object, "Attendee" status is typically unknown.
   The "Organizer" specifies this by setting the "PARTSTAT" parameter to
   "NEEDS-ACTION".  Each "Attendee" modifies their "ATTENDEE" property
   "PARTSTAT" parameter to an appropriate value as part of a "REPLY"
   message sent back to the "Organizer".

2.1.2.  Delegation

   Delegation is defined as the process by which an "Attendee" grants
   another CU (or several CUs) the right to attend on their behalf.  The
   "Organizer" is made aware of this change because the delegating
   "Attendee" informs the "Organizer".  These steps are detailed in the
   "REQUEST" method sections for the appropriate components.

Top      ToC       Page 11 
2.1.3.  Acting on Behalf of Other Calendar Users

   In many organizations, one user will act on behalf of another to
   organize and/or respond to meeting requests. iTIP provides two
   mechanisms that support these activities.

   First, the "Organizer" is treated as a special entity, separate from
   "Attendees".  All responses from "Attendees" flow to the "Organizer",
   making it easy to separate a "Calendar User" organizing a meeting
   from "Calendar Users" attending the meeting.  Additionally, iCalendar
   provides descriptive roles for each "Attendee".  For instance, a role
   of "chair" may be ascribed to one or more "Attendees".  The "chair"
   and the "Organizer" may or may not be the same "Calendar User".  This
   maps well to scenarios where an assistant may manage meeting
   logistics for another individual who chairs a meeting.

   Second, a "SENT-BY" parameter may be specified in either the
   "Organizer" or "Attendee" properties.  When specified, the "SENT-BY"
   parameter indicates that the responding CU acted on behalf of the
   specified "Attendee" or "Organizer".

2.1.4.  Component Revisions

   The "SEQUENCE" property is used by the "Organizer" to indicate
   revisions to the calendar component.  When the "Organizer" makes
   changes to one of the following properties, the sequence number MUST
   be incremented:

   o  "DTSTART"

   o  "DTEND"

   o  "DURATION"

   o  "DUE"

   o  "RRULE"

   o  "RDATE"

   o  "EXDATE"

   o  "STATUS"

   In addition, changes made by the "Organizer" to other properties MAY
   also require the sequence number to be incremented.  The "Organizer"
   CUA MUST increment the sequence number whenever it makes changes to
   properties in the calendar component that the "Organizer" deems will

Top      ToC       Page 12 
   jeopardize the validity of the participation status of the
   "Attendees".  For example, changing the location of a meeting from
   one location to another distant location could effectively impact the
   participation status of the "Attendees".

   Depending on the "METHOD", the "SEQUENCE" property MUST follow these
   rules in the context of iTIP:

   o  For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
      value is incremented according to the rules stated above.

   o  The "SEQUENCE" property value MUST be incremented each time the
      "Organizer" uses the "ADD" or "CANCEL" methods.

   o  The "SEQUENCE" property value MUST NOT be incremented when using
      "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
      delegation "REQUEST".

   In some circumstances, the "Organizer" may not have received
   responses to the final revision sent out.  In this situation, the
   "Organizer" may wish to send an update "REQUEST" and set "RSVP=TRUE"
   for all "Attendees" so that current responses can be collected.

   The value of the "SEQUENCE" property contained in a response from an
   "Attendee" may not always match the "Organizer's" revision.
   Implementations may choose to have the CUA indicate to the CU that
   the response is to an iCalendar object that has been revised, and
   allow the CU to decide whether or not to accept the response.

   Whilst a change in sequence number is indicative of a significant
   change to a previously scheduled item, "Attendee" CUAs SHOULD NOT
   rely solely on a change in sequence number as a means of detecting a
   significant change.  Instead, CUAs SHOULD compare the old and new
   versions of the calendar components, determine the exact nature of
   the changes, and make decisions -- possibly based on "Calendar User"
   preferences -- as to whether the user needs to be explicitly informed
   of the change.

2.1.5.  Message Sequencing

   CUAs that handle the iTIP application protocol must often correlate a
   component in a calendar store with a component received in the iTIP
   message.  For example, an event may be updated with a later revision
   of the same event.  To accomplish this, a CUA must correlate the
   version of the event already in its calendar store with the version
   sent in the iTIP message.  In addition to this correlation, there are
   several factors that can cause iTIP messages to arrive in an
   unexpected order.  That is, an "Organizer" could receive a reply to

Top      ToC       Page 13 
   an earlier revision of a component after receiving a reply to a later
   revision.

   To maximize interoperability and to handle messages that arrive in an
   unexpected order, use the following rules:

   1.  The primary key for referencing a particular iCalendar component
       is the "UID" property value.  To reference an instance of a
       recurring component, the primary key is composed of the "UID" and
       the "RECURRENCE-ID" properties.

   2.  The secondary key for referencing a component is the "SEQUENCE"
       property value.  For components where the "UID" and
       "RECURRENCE-ID" property values are the same, the component with
       the highest numeric value for the "SEQUENCE" property obsoletes
       all other revisions of the component with lower values.

   3.  "Attendees" send "REPLY" messages to the "Organizer".  For
       replies where the "UID" and "RECURRENCE-ID" property values are
       the same, the value of the "SEQUENCE" property indicates the
       revision of the component to which the "Attendee" is replying.
       The reply with the highest numeric value for the "SEQUENCE"
       property obsoletes all other replies with lower values.

   4.  In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE"
       property values match, the "DTSTAMP" property is used as the tie-
       breaker.  The component with the latest "DTSTAMP" overrides all
       others.  Similarly, for "Attendee" responses where the "UID",
       "RECURRENCE-ID", and "SEQUENCE" property values match, the
       response with the latest "DTSTAMP" overrides all others.

   Hence, CUAs will need to persist the following component properties
   in order to correctly process iTIP messages: "UID", "RECURRENCE-ID",
   "SEQUENCE", and "DTSTAMP".  Furthermore, for each "ATTENDEE" property
   of a component, "Organizer" CUAs will need to persist the "SEQUENCE"
   and "DTSTAMP" property values associated with the "Attendee's" last
   response, so that any earlier responses from an "Attendee" that are
   received out of order (e.g., due to a delay in the transport) can be
   correctly discarded.



(page 13 continued on part 2)

Next RFC Part