rfc2446.txt

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

TXT
1,535
字号
Silverberg, et. al.         Standards Track                    [Page 11]RFC 2446                          iTIP                     November 1998   Hence, CUAs must persist the following component properties: "UID",   "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP".  Furthermore, for each   "ATTENDEE" property of a component CUAs must persist the "SEQUENCE"   and "DTSTAMP" property values associated with the "Attendee's"   response.3 Application Protocol Elements   ITIP messages are "text/calendar" MIME entities that contain   calendaring and scheduling information. The particular type of [iCAL]   message is referred to as the "method type". Each method type is   identified by a "METHOD" property specified as part of the   "text/calendar" content type.  The table below shows various   combinations of calendar components and the method types that this   memo supports.   +=================================================+   |         | VEVENT | VTODO | VJOURNAL | VFREEBUSY |   |=================================================|   |Publish  |  Yes   |  Yes  |  Yes     |   Yes     |   |Request  |  Yes   |  Yes  |  No      |   Yes     |   |Refresh  |  Yes   |  Yes  |  No      |   No      |   |Cancel   |  Yes   |  Yes  |  Yes     |   No      |   |Add      |  Yes   |  Yes  |  Yes     |   No      |   |Reply    |  Yes   |  Yes  |  No      |   Yes     |   |Counter  |  Yes   |  Yes  |  No      |   No      |   |Decline- |        |       |          |           |   |Counter  |  Yes   |  Yes  |  No      |   No      |   +=================================================+   Each method type is defined in terms of its associated components and   properties. Some components and properties are required, some are   optional and others are excluded. The restrictions are expressed in   this document using a simple "restriction table". The first column   indicates the name of a component or property. Properties of the   iCalendar object are not indented. Properties of a component are   indented. The second column contains "MUST" if the component or   property must be present, "MAY" if the component or property is   optional, and "NOT" if the component or property must not be present.   Entries in the second column sometimes contain comments for further   clarification.Silverberg, et. al.         Standards Track                    [Page 12]RFC 2446                          iTIP                     November 19983.1 Common Component Restriction Tables   The restriction table below applies to properties of the iCalendar   object. That is, the properties at the outermost scope. The presence   column uses the following values to assert whether a property is   required, is optional and the number of times it may appear in the   iCalendar object.   Presence Value       Description   --------------------------------------------------------------   1                 One instance MUST be present   1+                At least one instance MUST be present   0                 Instances of this property Must NOT be present   0+                Multiple instances MAY be present   0 or 1            Up to 1 instance of this property MAY be present   ---------------------------------------------------------------   The tables also call out "X-PROPERTY" and  "X-COMPONENT" to show   where vendor-specific properties and components can appear.  The   tables do not lay out the restrictions of property parameters. Those   restrictions are defined in [iCAL].   Component/Property  Presence   ------------------- ----------------------------------------------   CALSCALE            0 or 1   PRODID              1   VERSION             1       Value MUST be "2.0"   X-PROPERTY          0+   DateTime values MAY refer to a "VTIMEZONE" component. The property   restrictions in the table below apply to any "VTIMEZONE" component in   an ITIP message.   Component/Property  Presence   ------------------- ----------------------------------------------   VTIMEZONE           0+      MUST be present if any date/time refers                               to timezone       DAYLIGHT        0+      MUST be one or more of either STANDARD or                               DAYLIGHT          COMMENT      0 or 1          DTSTART      1       MUST be local time format          RDATE        0+      if present RRULE MUST NOT be present          RRULE        0+      if present RDATE MUST NOT be present          TZNAME       0 or 1          TZOFFSET     1          TZOFFSETFROM 1          TZOFFSETTO   1Silverberg, et. al.         Standards Track                    [Page 13]RFC 2446                          iTIP                     November 1998          X-PROPERTY   0+       LAST-MODIFIED   0 or 1       STANDARD        0+      MUST be one or more of either STANDARD or                               DAYLIGHT          COMMENT      0 or 1          DTSTART      1       MUST be local time format          RDATE        0+      if present RRULE MUST NOT be present          RRULE        0+      if present RDATE MUST NOT be present          TZNAME       0 or 1          TZOFFSETFROM 1          TZOFFSETTO   1          X-PROPERTY   0+       TZID            1       TZURL           0 or 1       X-PROPERTY      0+   The property restrictions in the table below apply to any "VALARM"   component in an ITIP message.   Component/Property  Presence   ------------------- ----------------------------------------------   VALARM              0+       ACTION          1       ATTACH          0+       DESCRIPTION     0 or 1       DURATION        0 or 1  if present REPEAT MUST be present       REPEAT          0 or 1  if present DURATION MUST be present       SUMMARY         0 or 1       TRIGGER         1       X-PROPERTY      0+3.2 Methods for VEVENT Calendar Components   This section defines the property set restrictions for the method   types that are applicable to the "VEVENT" calendar component. Each   method is defined using a table that clarifies the property   constraints that define the particular method.Silverberg, et. al.         Standards Track                    [Page 14]RFC 2446                          iTIP                     November 1998   The following summarizes the methods that are defined for the   "VEVENT" calendar component.   +================+==================================================+   | Method         |  Description                                     |   |================+==================================================|   | PUBLISH        | Post notification of an event. Used primarily as |   |                | a method of advertising the existence of an      |   |                | event.                                           |   |                |                                                  |   | REQUEST        | Make a request for an event. This is an explicit |   |                | invitation to one or more "Attendees". Event     |   |                | Requests are also used to update or change an    |   |                | existing event. Clients that cannot handle       |   |                | REQUEST may degrade the event to view it as an   |   |                | PUBLISH.                                         |   |                |                                                  |   | REPLY          | Reply to an event request. Clients may set their |   |                | status ("partstat") to ACCEPTED, DECLINED,       |   |                | TENTATIVE, or DELEGATED.                         |   |                |                                                  |   | ADD            | Add one or more instances to an existing event.  |   |                |                                                  |   | CANCEL         | Cancel one or more instances of an existing      |   |                | event.                                           |   |                |                                                  |   | REFRESH        | A request is sent to an "Organizer" by an        |   |                | "Attendee" asking for the latest version of an   |   |                | event to be resent to the requester.             |   |                |                                                  |   | COUNTER        | Counter a REQUEST with an alternative proposal,  |   |                | Sent by an "Attendee" to the "Organizer".        |   |                |                                                  |   | DECLINECOUNTER | Decline a counter proposal. Sent to an           |   |                | "Attendee" by the "Organizer".                   |   +================+==================================================+3.2.1 PUBLISH   The "PUBLISH" method in a "VEVENT" calendar component is an   unsolicited posting of an iCalendar object. Any CU may add published   components to their calendar. The "Organizer" MUST be present in a   published iCalendar component. "Attendees" MUST NOT be present. Its   expected usage is for encapsulating an arbitrary event as an   iCalendar object. The "Organizer" may subsequently update (with   another "PUBLISH" method), add instances to (with an "ADD" method),   or cancel (with a "CANCEL" method) a previously published "VEVENT"   calendar component.Silverberg, et. al.         Standards Track                    [Page 15]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 equal "PUBLISH"VEVENT              1+     DTSTAMP        1     DTSTART        1     ORGANIZER      1     SUMMARY        1       Can be null.     UID            1     RECURRENCE-ID  0 or 1  only if referring to an instance of a                            recurring calendar component.  Otherwise                            it MUST NOT be present.     SEQUENCE       0 or 1  MUST be present if value is greater than                            0, 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  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+     RELATED-TO     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/CANCELLED     TRANSP         0 or 1     URL            0 or 1     X-PROPERTY     0+     ATTENDEE       0     REQUEST-STATUS 0VALARM              0+VFREEBUSY           0VJOURNAL            0Silverberg, et. al.         Standards Track                    [Page 16]RFC 2446                          iTIP                     November 1998VTODO               0VTIMEZONE           0+    MUST be present if any date/time refers to                          a timezoneX-COMPONENT         0+3.2.2 REQUEST   The "REQUEST" method in a "VEVENT" component provides the following   scheduling functions:     .  Invite "Attendees" to an event;     .  Reschedule an existing event;     .  Response to a REFRESH request;     .  Update the details of an existing event, without rescheduling it;     .  Update the status of "Attendees" of an existing event, without        rescheduling it;     .  Reconfirm an existing event, without rescheduling it;     .  Forward a "VEVENT" to another uninvited CU.     .  For an existing "VEVENT" calendar component, delegate the role of

⌨️ 快捷键说明

复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?