rfc2446.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,535 行 · 第 1/5 页

        "Attendee" to another CU;
     .  For an existing "VEVENT" calendar component, changing the role of
        "Organizer" to another CU.

   The "Organizer" originates the "REQUEST". The recipients of the
   "REQUEST" method are the CUs invited to the event, the "Attendees".
   "Attendees" use the "REPLY" method to convey attendance status to the
   "Organizer".

   The "UID" and "SEQUENCE" properties are used to distinguish the
   various uses of the "REQUEST" method. If the "UID" property value in
   the "REQUEST" is not found on the recipient's calendar, then the
   "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
   property value is found on the recipient's calendar, then the
   "REQUEST" is for a rescheduling, an update, or a reconfirm of the
   "VEVENT" calendar component.

   For the "REQUEST" method, multiple "VEVENT" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have
   instance-specific information.  In this case, multiple "VEVENT"
   components are needed to express the entire series.










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


   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
-----------------------------------------------------------------
METHOD              1       MUST be "REQUEST"
VEVENT              1+      All components MUST have the same UID
    ATTENDEE        1+
    DTSTAMP         1
    DTSTART         1
    ORGANIZER       1
    SEQUENCE        0 or 1  MUST be present if value is greater than 0,
                            MAY be present if 0
    SUMMARY         1       Can be null
    UID             1

    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1  Can be null
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    RELATED-TO      0+
    REQUEST-STATUS  0+
    RESOURCES       0 or 1  This property MAY contain a list of values
    RRULE           0+
    STATUS          0 or 1  MAY be one of TENTATIVE/CONFIRMED
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

VALARM              0+
VTIMEZONE           0+      MUST be present if any date/time refers to
                            a timezone
X-COMPONENT         0+



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


VFREEBUSY           0
VJOURNAL            0
VTODO               0

3.2.2.1 Rescheduling an Event

   The "REQUEST" method may be used to reschedule an event. A
   rescheduled event involves a change to the existing event in terms of
   its time or recurrence intervals and possibly the location or
   description. If the recipient CUA of a "REQUEST" method finds that
   the "UID" property value already exists on the calendar, but that the
   "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
   greater than the value for the existing event, then the "REQUEST"
   method describes a rescheduling of the event.

3.2.2.2 Updating or Reconfirmation of an Event

   The "REQUEST" method may be used to update or reconfirm an event. An
   update to an existing event does not involve changes to the time or
   recurrence intervals, and might not involve a change to the location
   or description for the event. If the recipient CUA of a "REQUEST"
   method finds that the "UID" property value already exists on the
   calendar and that the "SEQUENCE" property value in the "REQUEST" is
   the same as the value for the existing event, then the "REQUEST"
   method describes an update of the event details, but no rescheduling
   of the event.

   The update "REQUEST" method is the appropriate response to a
   "REFRESH" method sent from an "Attendee" to the "Organizer" of an
   event.

   The "Organizer" of an event may also send unsolicited "REQUEST"
   methods.  The unsolicited "REQUEST" methods may be used to update the
   details of the event without rescheduling it, to update the
   "partstat" parameter of "Attendees", or to reconfirm the event.

3.2.2.3 Delegating an Event to another CU

   Some calendar and scheduling systems allow "Attendees" to delegate
   their presence at an event to another calendar user. ITIP supports
   this concept using the following workflow. Any "Attendee" may
   delegate their right to participate in a calendar VEVENT to another
   CU. The implication is that the delegate participates in lieu of the
   original "Attendee"; NOT in addition to the "Attendee". The delegator
   MUST notify the "Organizer" of this action using the steps outlined
   below.  Implementations may support or restrict delegation as they
   see fit. For instance, some implementations may restrict a delegate
   from delegating a "REQUEST" to another CU.



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


   The "Delegator" of an event forwards the existing "REQUEST" to the
   "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
   with the calendar address of the "Delegate". The "Delegator" MUST
   also send a "REPLY" method to the "Organizer" with the "Delegator's"
   "ATTENDEE" property "partstat" parameter value set to "delegated". In
   addition, the "delegated-to" parameter MUST be included with the
   calendar address of the "Delegate".

   In response to the request, the "Delegate" MUST send a "REPLY" method
   to the "Organizer" and optionally, to the "Delegator". The "REPLY"
   method " SHOULD include the "ATTENDEE" property with the "delegated-
   from" parameter value of the "Delegator's" calendar address.

   The "Delegator" may continue to receive updates to the event even
   though they will not be attending. This is accomplished by the
   "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in
   the "REPLY" to the "Organizer"

3.2.2.4 Changing the Organizer

   The situation may arise where the "Organizer" of a VEVENT is no
   longer able to perform the "Organizer" role and abdicates without
   passing on the "Organizer" role to someone else. When this occurs the
   "Attendees" of the VEVENT may use out-of-band mechanisms to
   communicate the situation and agree upon a new "Organizer".  The new
   "Organizer" should then send out a new "REQUEST" with a modified
   version of the VEVENT in which the "SEQUENCE" number has been
   incremented and value of the "ORGANIZER" property has been changed to
   the calendar address of the new "Organizer".

3.2.2.5 Sending on Behalf of the Organizer

   There are a number of scenarios that support the need for a calendar
   user to act on behalf of the "Organizer" without explicit role
   changing.  This might be the case if the CU designated as "Organizer"
   was sick or unable to perform duties associated with that function.
   In these cases iTIP supports the notion of one CU acting on behalf of
   another. Using the "sent-by" parameter, a calendar user could send an
   updated "VEVENT" REQUEST. In the case where one CU sends on behalf of
   another CU, the "Attendee" responses are still directed back towards
   the CU designated as "Organizer".

3.2.2.6 Forwarding to An Uninvited CU

   An "Attendee" invited to an event may invite another uninvited CU to
   the event. The invited "Attendee" accomplishes this by forwarding the
   original "REQUEST" method to the uninvited CU. The "Organizer"
   decides whether or not the uninvited CU is added to the attendee



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


   list. If the "Organizer" decides not to add the uninvited CU no
   further action is required, however the "Organizer" MAY send the
   uninvited CU a "CANCEL" message.  If the "Organizer" decides to add
   an uninvited CU, a new "ATTENDEE" property is added for the uninvited
   CU with its property parameters set as the "Organizer" deems
   appropriate. When forwarding a "REQUEST" to another CU, the
   forwarding "Attendee" MUST NOT make changes to the VEVENT property
   set.

3.2.2.7 Updating Attendee Status

   The "Organizer" of an event may also request updated status from one
   or more "Attendees. The "Organizer" sends a "REQUEST" method to the
   "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
   "SEQUENCE" property for the event is not changed from its previous
   value. A recipient will determine that the only change in the
   "REQUEST" is that their "RSVP" property parameter indicates a request
   for updated status. The recipient SHOULD respond with a "REPLY"
   method indicating their current status with respect to the "REQUEST".

3.2.3 REPLY

   The "REPLY" method in a "VEVENT" calendar component is used to
   respond (e.g., accept or decline) to a "REQUEST" or to reply to a
   delegation "REQUEST". When used to provide a delegation response, the
   "Delegator" SHOULD include the calendar address of the "Delegate" on
   the "delegated-to" property parameter of the "Delegator's" "ATTENDEE"
   property. The "Delegate" SHOULD include the calendar address of the
   "Delegator" on the "delegated-from" property parameter of the
   "Delegate's" "ATTENDEE" property.

   The "REPLY" method may also be used to respond to an unsuccessful
   "REQUEST" method. Depending on the value of the "REQUEST-STATUS"
   property no scheduling action may have been performed.

   The "Organizer" of an event may receive the "REPLY" method from a CU
   not in the original "REQUEST". For example, a "REPLY" may be received
   from a "Delegate" to an event. In addition, the "REPLY" method may be
   received from an unknown CU (a "Party Crasher"). This uninvited
   "Attendee" may be accepted, or the "Organizer" may cancel the event
   for the uninvited "Attendee" by sending a "CANCEL" method to the
   uninvited "Attendee".

   An "Attendee" can include a message to the "Organizer" using the
   "COMMENT" property. For example, if the user indicates tentative
   acceptance and wants to let the "Organizer" know why, the reason can
   be expressed in the "COMMENT" property value.




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


   The "Organizer" may also receive a "REPLY" from one CU on behalf of
   another. Like the scenario enumerated above for the "Organizer",
   "Attendees" may have another CU respond on their behalf. This is done
   using the "sent-by" parameter.

   The optional properties listed in the table below (those listed as
   "0+" or "0 or 1") MUST NOT be changed from those of the original
   request.  If property changes are desired the COUNTER message must be
   used.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "REPLY"
VEVENT              1+      All components MUST have the same UID
    ATTENDEE        1       MUST be the address of the Attendee
                            replying.
    DTSTAMP         1
    ORGANIZER       1
    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise
                            it must NOT be present.
    UID             1       MUST be the UID of the original REQUEST

    SEQUENCE        0 or 1  MUST if non-zero, MUST be the sequence
                            number of the original REQUEST. MAY be
                            present if 0.

    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DTSTART         0 or 1
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1