rfc2446.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,535 行 · 第 1/5 页

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

   This memo does not attempt to repeat the specification of concepts or
   definitions from these other memos. Where possible, references are
   made to the memo that provides for the specification of these
   concepts or definitions.

1.3 ITIP Roles and Transactions

   ITIP defines methods for exchanging [iCAL] objects for the purposes
   of group calendaring and scheduling between "Calendar Users" (CUs).
   CUs take on one of two roles in iTIP. The CU who initiates an
   exchange takes on the role of "Organizer". For example, the CU who
   proposes a group meeting is the "Organizer". The CUs asked to
   participate in the group meeting by the "Organizer" take on the role
   of "Attendee". Note that "role" is also a descriptive parameter to
   the _ATTENDEE_ property. Its use is to convey descriptive context to
   an "Attendee" such as "chair", "req-participant" or "non-participant"
   and has nothing to do with the calendaring workflow.










Silverberg, et. al.         Standards Track                     [Page 6]

RFC 2446                          iTIP                     November 1998


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

   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Used to publish a calendar entry 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 a calendar entry 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 VTODOs to    |
   |                | other Calendar Users are all examples.           |
   |                | Requests are also used by the "Organizer" to     |
   |                | update the status of a calendar entry.           |
   |                |                                                  |
   | 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 instances to an existing         |
   |                | VEVENT, VTODO, or VJOURNAL.                      |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | VEVENT, VTODO, or VJOURNAL.                      |
   |                |                                                  |
   | REFRESH        | The Refresh method is used by an "Attendee" to   |
   |                | request the latest version of a calendar entry.  |
   |                |                                                  |
   | COUNTER        | The Counter method is used by an "Attendee" to   |
   |                | negotiate a change in the calendar entry.        |
   |                | Examples include the request to change a         |
   |                | proposed Event time or change the due date for a |
   |                | VTODO.                                           |
   |                |                                                  |
   | DECLINE-       | Used by the "Organizer" to decline the proposed  |
   | COUNTER        | counter-proprosal.                               |
   +================+==================================================+







Silverberg, et. al.         Standards Track                     [Page 7]

RFC 2446                          iTIP                     November 1998


   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.

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.





Silverberg, et. al.         Standards Track                     [Page 8]

RFC 2446                          iTIP                     November 1998


   +------------------------------------------+
   |                   iTIP                   |
   +------------------------------------------+
   |Real-time | Store-and-Fwd | Other         |
   |Transport | Transport     | Transports... |
   +------------------------------------------+

2.1 Application Protocol

   In the iTIP model, a calendar entry 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 calendar entry. They can, however, use
   the "COUNTER" method to suggest changes to the "Organizer". In any
   case, the "Organizer" has complete control over the master calendar
   entry.

2.1.1 Calendar Entry State

   There are two distinct states relevant to calendar entries: the
   overall state of the entry and the state associated with an
   "Attendee" to that entry.

   The state of an entry 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 calendar entry.

   The state of a particular "Attendee" relative to an entry is defined
   by the "partstat" parameter in the "ATTENDEE" property for each
   "Attendee".  When an "Organizer" issues the initial entry, "Attendee"
   status is 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 section.







Silverberg, et. al.         Standards Track                     [Page 9]

RFC 2446                          iTIP                     November 1998


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. The rules for incrementing the
   "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are
   paraphrased here in terms of how they are applied in [iTIP]. For a
   given "UID" in a calendar component:

   . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
      value is incremented according to the rules defined in [iCAL].

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

   . 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.








Silverberg, et. al.         Standards Track                    [Page 10]

RFC 2446                          iTIP                     November 1998


   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 entry that has been revised and allow the CU to
   decide whether or not to accept the response.

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 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" is 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" property value is 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" and "SEQUENCE" properties 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" property values match and
       the "SEQUENCE" property values match, the response with the
       latest "DTSTAMP" overrides all others.