Foreword
This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) Documents as located at
July 2004 CalConnect Interoperability Test Results Spreadsheet
1. Spreadsheet
| RFC 2445 | Internet Calendaring and Scheduling Core Object Specification | |||
|---|---|---|---|---|
| Feature Set | Requirement | Condition | V1 | V2 |
| 2.3 International Considerations | MUST | If a non-US-ASCII compatible character set is used, appropriate code-point from that character set MUST be chosen instead | Y | Y |
| 4.1 Content Lines | SHOULD NOT | Lines of text SHOULD NOT be longer than 75 octets, excluding the line break | Y | Y |
| 4.1 Content Lines | SHOULD | Long content lines SHOULD be split into a multiple line representations using a line “folding” technique | Y | Y |
| 4.1.1 List and Field Separators | MUST | Values in a list of values MUST be separated by a COMMA character (US-ASCII decimal 44). | N | N |
| 4.1.1 List and Field Separators | MUST | Structured property values MUST have their value parts separated by a SEMICOLON character (US-ASCII decimal 59) | N | N |
| 4.1.1 List and Field Separators | MUST | Each property parameter in a list of property parameters MUST be separated by a SEMICOLON character (US-ASCII decimal 59). | N | N |
| 4.1.1 List and Field Separators | MUST | Property parameters with values containing a COLON, a SEMICOLON or a COMMA character MUST be placed in quoted text | N | N |
| 4.1.3 Binary Content | SHOULD | Binary content information in an iCalendar object SHOULD be referenced using a URI within a property value | Y | N |
| 4.1.3 Binary Content | MUST | Binary content information placed external to the iCalendar object MUST be referenced by a uniform resource identifier (URI) | Y | N |
| 4.2 Property Parameters | MUST | Property parameter values that contain the COLON (US-ASCII decimal 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) character separators MUST be specified as quoted-string text value | Y | Y |
| 4.2 Property Parameters | MUST NOT | Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII decimal 22) character. | Y | Y? |
| 4.2.1 Alternate Text Representation | MUST | A property specifying alternate text representation parameter MUST also include a value that reflects the default representation of the text value | Y | N |
| 4.2.1 Alternate Text Representation | MUST | The individual URI parameter values MUST each be specified in a quoted-string | Y | N |
| 4.2.4 Delegators | MUST | The value of the DELEGATED-FROM parameter MUST be a MAILTO URI as defined in IETF RFC 1738 | Y | N |
| 4.2.4 Delegators | MUST | The individual calendar address parameter values MUST each be specified in a quoted-string. | Y | N |
| 4.2.5 Delegatees | MUST | The value of the DELEGATED-TO parameter MUST be a MAILTO URI as defined in IETF RFC 1738. | Y | N |
| 4.2.5 Delegatees | MUST | The individual calendar address parameter values MUST each be specified in a quoted-string. | Y | N |
| 4.2.6 Directory Entry Reference | MUST | The individual URI parameter values of DIR= MUST each be specified in a quoted-string. | ? | N |
| 4.2.7 Inline Encoding | MUST | If the value type parameter is “;VALUE=BINARY”, then the inline encoding parameter MUST be specified with the value “;ENCODING=BASE64” | Y | N |
| 4.2.8 Format Type | MUST | The parameter value of FMTTYPE=MUST be the TEXT for either an IANA registered content type or a non-standard content type | Y | N |
| 4.2.11 Group or List Membership | MUST | The individual calendar address parameter values MUST each be specified in a quoted-string. | N? | N |
| 4.2.12 Participation Status | MUST | The values to PARTSTAT=MUST match one of the values allowed for the given calendar component. | Y | Y |
| 4.2.18 Sent By | MUST | The parameter value of SENT-BY MUST be a MAILTO URI as defined in IETF RFC 1738. | Y | N |
| 4.2.18 Sent By | MUST | The individual calendar address parameter values MUST each be specified in a quoted-string. | Y | N |
| 4.2.19 Time Zone Identifier | MUST | The parameter MUST be specified on the “DTSTART”, “DTEND”, “DUE”, “EXDATE” and “RDATE” properties when either a DATE-TIME or TIME value type is specified and when the value is not either a UTC or a “floating” time | Y | Y |
| 4.2.19 Time Zone Identifier | MUST | An individual “VTIMEZONE” calendar component MUST be specified for each unique “TZID” parameter value specified in the iCalendar object | Y | Y |
| 4.2.19 Time Zone Identifier | MUST NOT | The TZID property parameter MUST NOT be applied to DATE-TIME or TIME properties whose time values are specified in UTC. | Y | Y |
| 4.2.20 Value Data Types | MUST | The property values MUST be of a single value type. | Y | Y |
| 4.2.20 Value Data Types | MUST | If the property’s value is the default value type, then this parameter need not be specified. However, if the property’s default value type is overridden by some other allowable value type, then this parameter MUST be specified | Y | Y |
| 4.3.1 Binary | MUST | Property values with this value type MUST also include the inline encoding parameter sequence of “;ENCODING=BASE64”. | Y | N |
| 4.3.3 Calendar User Address | MUST | When used to address an Internet email transport address for a calendar user, the value MUST be a MAILTO URI, as defined by IETF RFC 1738 | Y | Y |
| 4.3.5 Date-Time | MUST NOT | The form of date and time with UTC offset MUST NOT be used. | Y | Y |
| 4.3.5 Date-Time | SHOULD | The recipient of an iCalendar object with a property value consisting of a local time, without any relative time zone information, SHOULD interpret the value as being fixed to whatever time zone the ATTENDEE is in at any given moment | Y | Y |
| 4.3.5 Date-Time | SHOULD | Floating time SHOULD only be used where that is the reasonable behavior | Y | Y |
| 4.3.5 Date-Time | MUST | In most cases, a fixed time is desired. To properly communicate a fixed time in a property value, either UTC time or local time with time zone reference MUST be specified | Y | Y |
| 4.3.5 Date-Time | MUST NOT | The TZID property parameter MUST NOT be applied to DATE-TIME properties whose time values are specified in UTC | Y | Y |
| 4.3.5 Date-Time | MUST ONLY | A time value MUST ONLY specify 60 seconds when specifying the periodic “leap second” in the time value | ? | Y |
| 4.3.9 Period of Time | MUST | The start of the period MUST be before the end of the period. | ? | ? |
| 4.3.10 Recurrence Rule | MUST | Individual rule parts MUST only be specified once | Y | Y |
| 4.3.10 Recurrence Rule | MUST | The FREQ rule part identifies the type of recurrence rule. This rule part MUST be specified in the recurrence rule | Y | Y |
| 4.3.10 Recurrence Rule | MUST | If UNTIL is specified as a date-time value, then it MUST be specified in an UTC time format. | Y | Y |
| 4.3.10 Recurrence Rule | MUST | BYSETPOS MUST only be used in conjunction with another BYxxx rule part | Y | Y? |
| 4.3.11 Text | MUST | An intentional formatted text line break MUST only be included in a “TEXT” property value by representing the line break with the character sequence of BACKSLASH (US-ASCII decimal 92), followed by a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER N (US-ASCII decimal 78), that is “\n” or “\N” | Y | Y |
| 4.3.12 Time | MUST NOT | The form of time with UTC offset MUST NOT be used. | Y | Y |
| 4.3.12 Time | SHOULD | The recipient of an iCalendar object with a property value consisting of a local time, without any relative time zone information, SHOULD interpret the value as being fixed to whatever time zone the ATTENDEE is in at any given moment | Y | Y |
| 4.3.12 Time | SHOULD | Floating time SHOULD only be used where that is reasonable behavior | Y | Y |
| 4.3.12 Time | MUST | To properly communicate a fixed time in a property value, either UTC time or local time with time zone reference MUST be specified. | Y | Y |
| 4.3.12 Time | MUST NOT | The TZID property parameter MUST NOT be applied to TIME properties whose time values are specified in UTC | Y | Y |
| 4.3.14 UTC Offset | MUST | The PLUS SIGN character MUST be specified for positive UTC offsets (i.e., ahead of UTC). | Y | Y |
| 4.4 iCalendar Object | MUST | The first line and last line of the iCalendar object MUST contain a pair of iCalendar object delimiter strings | Y | Y |
| 4.6 Calendar Components | MUST | An iCalendar object MUST include the “PRODID” and “VERSION” calendar properties. | Y | Y |
| 4.6 Calendar Components | MUST NOT | ‘calscale’ and ‘method’ are optional, but MUST NOT occur more than once | Y | Y |
| 4.6 Calendar Components | MUST | An iCalendar object MUST include at least one calendar component. | Y | Y? |
| 4.6.1 Event Component | MUST NOT | the following are optional, but MUST NOT occur more than once: class / created / description / dtstart / geo / last-mod / location / organizer / priority / dtstamp / seq / status / summary / transp / uid / url / recurid | Y | Y |
| 4.6.1 Event Component | MUST NOT | either ‘dtend’ or ‘duration’ may appear in a ‘eventprop’, but ‘dtend’ and ‘duration’ MUST NOT occur in the same ‘eventprop’ | Y | Y |
| 4.6.1 Event Component | MAY | the following are optional, and MAY occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-pro | Y | Y |
| 4.6.2 To-do Component | MUST NOT | the following are optional, but MUST NOT occur more than once: class / completed / created / description / dtstamp / dtstart / geo / last-mod / location / organizer / percent / priority / recurid / seq / status / summary / uid / ur | Y | Y |
| 4.6.2 To-do Component | MUST NOT | either ‘due’ or ‘duration’ may appear in a ‘todoprop’, but ‘due’ and ‘duration’ MUST NOT occur in the same ‘todoprop’ | Y | Y |
| 4.6.2 To-do Component | MAY | the following are optional, and MAY occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-pro | Y | Y |
| 4.6.3 Journal Component | MUST NOT | the following are optional, but MUST NOT occur more than once: class / created / description / dtstart / dtstamp / last-mod / organizer / recurid / seq / status / summary / uid / url | N | N |
| 4.6.3 Journal Component | MAY | the following are optional, and MAY occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / related / rdate / rrule / rstatus / x-pro | N | N |
| 4.6.3 Journal Component | MUST NOT | The “VJOURNAL” calendar component cannot be nested within another calendar component | N | N |
| 4.6.4 Free/Busy Component | MUST NOT | the following are optional, but MUST NOT occur more than once: contact / dtstart / dtend / duration / dtstamp / organizer / uid / url | N | Y |
| 4.6.4 Free/Busy Component | MAY | the following are optional, and MAY occur more than once: attendee / comment / freebusy / rstatus / x-prop | N | Y |
| 4.6.4 Free/Busy Component | MUST NOT | The recurrence properties (“RRULE”, “EXRULE”, “RDATE”, “EXDATE”) are not permitted within a “VFREEBUSY” calendar component. Any recurring events are resolved into their individual busy time periods using the “FREEBUSY” property | N | Y |
| 4.6.5 Time Zone Component | MUST NOT | ‘tzid’ is required, but MUST NOT occur more than once | Y | Y |
| 4.6.5 Time Zone Component | MUST NOT | ‘last-mod’ and ‘tzurl’ are optional, but MUST NOT occur more than once | Y | Y |
| 4.6.5 Time Zone Component | MUST | one of ‘standardc’ or ‘daylightc’ MUST occur and each MAY occur more than once | Y | Y |
| 4.6.5 Time Zone Component | MAY | the following is optional, and MAY occur more than once: x-prop | Y | Y |
| 4.6.5 Time Zone Component | MAY | Multiple “VTIMEZONE” calendar components can exist in an iCalendar object. | Y | Y |
| 4.6.5 Time Zone Component | MUST | If multiple “VTIMEZONE” calendar components exist in an iCalendar object, each “VTIMEZONE” MUST represent a unique time zone definition | Y | Y |
| 4.6.5 Time Zone Component | MUST | The “VTIMEZONE” calendar component MUST be present if the iCalendar object contains an RRULE that generates dates on both sides of a time zone shift | Y | Y |
| 4.6.5 Time Zone Component | MAY | A “VTIMEZONE” calendar component can be present if the iCalendar object does not contain such an RRULE that generates dates on both sides of a time zone shift. | Y | Y |
| 4.6.5 Time Zone Component | MUST | If a RRULE that generates dates on both sides of a time zone shift is present, there MUST be valid time zone information for all recurrence instances | Y | Y |
| 4.6.5 Time Zone Component | MUST | The “VTIMEZONE” calendar component MUST include the “TZID” property and at least one definition of a standard or daylight component. | Y | Y |
| 4.6.5 Time Zone Component | MUST | The standard or daylight component MUST include the “DTSTART”, “TZOFFSETFROM” and “TZOFFSETTO” properties. | Y | Y |
| 4.6.5 Time Zone Component | MUST | An individual “VTIMEZONE” calendar component MUST be specified for each unique “TZID” parameter value specified in the iCalendar object. | Y | Y |
| 4.6.5 Time Zone Component | SHOULD | TZURL SHOULD refer to a resource that is accessible by anyone who might need to interpret the object. | N | N |
| 4.6.5 Time Zone Component | SHOULD NOT | TZURL SHOULD NOT normally be a file: URL or other URL that is not widely-accessible. | N | N |
| 4.6.6 Alarm Component | REQUIRED | ‘action’ and ‘trigger’ are both REQUIRED, but MUST NOT occur more than once | N | N |
| 4.6.6 Alarm Component | MUST NOT | ‘duration’ and ‘repeat’ are both optional, and MUST NOT occur more than once each, but if one occurs, so MUST the other | N | N |
| 4.6.6 Alarm Component | MUST NOT | the following is optional, but MUST NOT occur more than once: attach | N | N |
| 4.6.6 Alarm Component | MAY | the following is optional, and MAY occur more than once: x-prop | N | N |
| 4.6.6 Alarm Component | REQUIRED | the following are all REQUIRED, but MUST NOT occur more than once: action / description / trigger | N | N |
| 4.6.6 Alarm Component | MUST NOT | ‘duration’ and ‘repeat’ are both optional, and MUST NOT occur more than once each, but if one occurs, so MUST the other | N | N |
| 4.6.6 Alarm Component | MAY | the following is optional, and MAY occur more than once: x-prop | N | N |
| 4.6.6 Alarm Component | REQUIRED | the following are all REQUIRED, but MUST NOT occur more than once: action / description / trigger / summary | N | N |
| 4.6.6 Alarm Component | REQUIRED | the following is REQUIRED, and MAY occur more than once: attendee | N | N |
| 4.6.6 Alarm Component | MUST NOT | ‘duration’ and ‘repeat’ are both optional, and MUST NOT occur more than once each, but if one occurs, so MUST the other | N | N |
| 4.6.6 Alarm Component | MAY | the following are optional, and MAY occur more than once: attach / x-prop | N | N |
| 4.6.6 Alarm Component | REQUIRED | the following are all REQUIRED, but MUST NOT occur more than once: action / attach / trigger | N | N |
| 4.6.6 Alarm Component | MUST NOT | ‘duration’ and ‘repeat’ are both optional, and MUST NOT occur more than once each, but if one occurs, so MUST the other | N | N |
| 4.6.6 Alarm Component | MUST NOT | ‘description’ is optional, and MUST NOT occur more than once | N | N |
| 4.6.6 Alarm Component | MAY | the following is optional, and MAY occur more than once: x-prop | N | N |
| 4.6.6 Alarm Component | MUST | The “VALARM” calendar component MUST include the “ACTION” and “TRIGGER” properties. | N | N |
| 4.6.6 Alarm Component | MUST | When the action is “AUDIO”, the alarm can also include one and only one “ATTACH” property, which MUST point to a sound resource, which is rendered when the alarm is triggered. | N | N |
| 4.6.6 Alarm Component | MUST | When the action is “DISPLAY”, the alarm MUST also include a “DESCRIPTION” property, which contains the text to be displayed when the alarm is triggered. | N | N |
| 4.6.6 Alarm Component | MUST | When the action is “EMAIL”, the alarm MUST include a “DESCRIPTION” property, which contains the text to be used as the message body, a “SUMMARY” property, which contains the text to be used as the message subject, and one or more “ATTENDEE” properties, which contain the email address of attendees to receive the message. | N | N |
| 4.6.6 Alarm Component | MAY | It can also include one or more “ATTACH” properties, which are intended to be sent as message attachments. | N | N |
| 4.6.6 Alarm Component | MUST | When the action is “PROCEDURE”, the alarm MUST include one and only one “ATTACH” property, which MUST point to a procedure resource, which is invoked when the alarm is triggered. | N | N |
| 4.6.6 Alarm Component | MUST | The “VALARM” calendar component MUST only appear within either a “VEVENT” or “VTODO” calendar component. | N | N |
| 4.6.6 Alarm Component | MUST NOT | “VALARM” calendar components cannot be nested. | N | N |
| 4.6.6 Alarm Component | MUST | In an alarm set to trigger on the “START” of an event or to-do, the “DTSTART” property MUST be present in the associated event or to-do. | N | Y |
| 4.6.6 Alarm Component | MUST | In an alarm in a “VEVENT” calendar component set to trigger on the “END” of the event, either the “DTEND” property MUST be present, or the “DTSTART” and “DURATION” properties MUST both be present. | N | |
| 4.6.6 Alarm Component | MUST | In an alarm in a “VTODO” calendar component set to trigger on the “END” of the to-do, either the “DUE” property MUST be present, or the “DTSTART” and “DURATION” properties MUST both be present. | N | Y |
| 4.6.6 Alarm Component | MUST | A definition of an alarm with a repeating trigger MUST include both the “DURATION” and “REPEAT” properties. | N | |
| 4.6.6 Alarm Component | MUST | Both “DURATION” and “REPEAT” properties MUST be present in order to specify a repeating alarm. If one of these two properties is absent, then the alarm will not repeat beyond the initial trigger. | N | Y |
| 4.6.6 Alarm Component | MUST | The “ACTION” property MUST specify one and only one of “AUDIO”, “DISPLAY”, “PROCEDURE”, “EMAIL”. | N | Y |
| 4.6.6 Alarm Component | MUST | In an AUDIO alarm, if the optional “ATTACH” property is included, it MUST specify an audio sound resource. | N | Y |
| 4.6.6 Alarm Component | MUST | For an “EMAIL” alarm, the “DESCRIPTION” property of the “VALARM” calendar component MUST be used as the body text of the message, and the “SUMMARY” property MUST be used as the subject text. | N | Y |
| 4.6.6 Alarm Component | SHOULD | Any “ATTACH” properties in the “VALARM” calendar component SHOULD be sent as attachments to the message. | N | Y |
| 4.6.6 Alarm Component | MUST | In a PROCEDURE alarm, the “ATTACH” property in the “VALARM” calendar component MUST specify a procedure or program that is intended to be invoked as the alarm effect. | N | Y |
| 4.6.6 Alarm Component | SHOULD | While a very useful alarm capability, the PROCEDURE type of alarm SHOULD be treated by the “Calendar User Agent” as a potential security risk. | N | Y |
| 4.7 Calendar Properties | SHOULD | Calendar Properties SHOULD be specified after the “BEGIN:VCALENDAR” property and prior to any calendar component. | Y | Y |
| 4.7.2 Method | MUST | When used in a MIME message entity, the value of this property MUST be the same as the Content-Type “method” parameter value. This property can only appear once within the iCalendar object. | Y | Y |
| 4.7.2 Method | MUST | If either the “METHOD” property or the Content-Type “method” parameter is specified, then the other MUST also be specified. | Y | Y |
| 4.7.2 Method | MUST NOT | If this property is not present in the iCalendar object, then a scheduling transaction MUST NOT be assumed. | Y | Y |
| 4.7.3 Product Identifier | MUST | The property MUST be specified once in an iCalendar object. | Y | Y |
| 4.7.3 Product Identifier | SHOULD | The vendor of the implementation SHOULD assure that this is a globally unique identifier; using some technique such as an FPI value, as defined in ISO 9070. | Y | Y |
| 4.7.3 Product Identifier | SHOULD NOT | This property SHOULD not be used to alter the interpretation of an iCalendar object beyond the semantics specified in this memo. | Y | Y |
| 4.7.4 Version | MUST | This property MUST be specified by an iCalendar object, but MUST only be specified once. | Y | Y |
| 4.8.1.1 Attachment | MUST | the following is optional, but MUST NOT occur more than once: fmttypeparam | Y | N |
| 4.8.1.1 Attachment | MAY | the following is optional, and MAY occur more than once: xparam | Y | N |
| 4.8.1.2 Categories | MUST NOT | the following is optional, but MUST NOT occur more than once: languageparam | N | Y |
| 4.8.1.2 Categories | MAY | the following is optional, and MAY occur more than once: xparam | N | Y |
| 4.8.1.4 Comment | MUST NOT | the following are optional, but MUST NOT occur more than once: altrepparam, languageparam | Y | Y |
| 4.8.1.4 Comment | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.1.5 Description | MUST NOT | the following are optional, but MUST NOT occur more than once: altrepparam, languageparam | Y | Y |
| 4.8.1.5 Description | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.1.6 Geographic Position | MUST | The value MUST be two SEMICOLON separated FLOAT values. | Y | Y |
| 4.8.1.7 Location | MUST | the following are optional, but MUST NOT occur more than once: altrepparam, languageparam | Y | Y |
| 4.8.1.7 Location | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.1.10 Resources | MUST NOT | the following are optional, but MUST NOT occur more than once: altrepparam, languageparam | Y | Y |
| 4.8.1.10 Resources | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.1.12 Summary | MUST NOT | the following are optional, but MUST NOT occur more than once: altrepparam, languageparam | Y | Y |
| 4.8.1.12 Summary | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.2.1 Date/Time Completed | MUST | The date and time MUST be in a UTC format. | Y | Y |
| 4.8.2.2 Date/Time End | MUST NOT | the following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATETIME” / “DATE”)), tzidparam | Y | Y |
| 4.8.2.2 Date/Time End | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.2.3 Date/Time Due | MUST NOT | the following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATETIME” / “DATE”)), tzidparam | Y | N |
| 4.8.2.3 Date/Time Due | MAY | the following is optional, and MAY occur more than once: xparam | Y | N |
| 4.8.2.4 Date/Time Start | MUST | The time value MUST be one of the forms defined for the DATE-TIME value type. | Y | Y |
| 4.8.2.4 Date/Time Start | MUST NOT | the following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATETIME” / “DATE”)), tzidparam | Y | Y |
| 4.8.2.4 Date/Time Start | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.2.6 Free/Busy Time | MUST | The date and time values MUST be in an UTC time format. | N | Y? |
| 4.8.2.6 Free/Busy Time | MUST | the following is optional, but MUST NOT occur more than once: fbtypeparam | N | Y |
| 4.8.2.6 Free/Busy Time | MAY | the following is optional, and MAY occur more than once: xparam | N | Y |
| 4.8.2.7 Time Transparency | SHOULD | Events that consume actual time for the individual or resource associated with the calendar SHOULD be recorded as OPAQUE, allowing them to be detected by free-busy time searches. | Y | Y |
| 4.8.2.7 Time Transparency | SHOULD | Other events, which do not take up the individual’s (or resource’s) time SHOULD be recorded as TRANSPARENT, making them invisible to free-busy time searches. | Y | Y |
| 4.8.3.1 Time Zone Identifier | MUST | This property MUST be specified in a “VTIMEZONE” calendar component. | Y | Y |
| 4.8.3.2 Time Zone Name | MUST NOT | the following is optional, but MUST NOT occur more than once: languageparam | Y | Y |
| 4.8.3.2 Time Zone Name | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.3.3 Time Zone Offset From | MUST | This property MUST be specified in a “VTIMEZONE” calendar component. | Y | Y |
| 4.8.3.4 Time Zone Offset To | MUST | This property MUST be specified in a “VTIMEZONE” calendar component. | Y | Y |
| 4.8.4.1 Attendee | MUST | This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. | Y | Y |
| 4.8.4.1 Attendee | MUST NOT | This property MUST NOT be specified in an iCalendar object when publishing the calendar information. | Y | N |
| 4.8.4.1 Attendee | MUST | The property MUST only be specified within calendar components to specify participants, non-participants and the chair of a group scheduled calendar entity. | Y | Y |
| 4.8.4.1 Attendee | MUST NOT | The ROLE, PARSTAT, RSVP, CUTYPE, etc. MUST NOT be specified in an “ATTENDEE” property in a “VFREEBUSY” or “VALARM” calendar component. | Y | Y |
| 4.8.4.1 Attendee | MUST | A recipient delegated a request MUST inherit the RSVP and ROLE values from the attendee that delegated the request to them. | Y | N |
| 4.8.4.1 Attendee | MUST NOT | the following are optional, but MUST NOT occur more than once: cutypeparam, memberparam, roleparam, partstatparam, rsvpparam, deltoparam, delfromparam, sentbyparam, cnparam, dirparam, languageparam | Y | Y |
| 4.8.4.1 Attendee | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.4.2 Contact | MUST | the following are optional, but MUST NOT occur more than once: altrepparam, languageparam | Y | Y |
| 4.8.4.2 Contact | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.4.3 Organizer | MUST | This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. | Y | Y |
| 4.8.4.3 Organizer | MUST | This property MUST be specified in an iCalendar object that specifies the publication of a calendar user’s busy time. | N | Y |
| 4.8.4.3 Organizer | MUST NOT | This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user’s calendar. | N | N |
| 4.8.4.3 Organizer | MUST NOT | the following are optional, but MUST NOT occur more than once: cnparam, dirparam, sentbyparam, languageparam | Y | Y |
| 4.8.4.3 Organizer | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.4.4 Recurrence ID | MUST | If the value of the “DTSTART” property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. | Y | Y |
| 4.8.4.4 Recurrence ID | MUST NOT | the following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATETIME” / “DATE”), tzidparam, rangeparam | Y | Y |
| 4.8.4.4 Recurrence ID | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.4.5 Related To | MUST NOT | the following is optional, but MUST NOT occur more than once: reltypeparam | N | N |
| 4.8.4.5 Related To | MAY | the following is optional, and MAY occur more than once: xparam | N | N |
| 4.8.4.7 Unique Identifier | MUST | The property MUST be specified in the “VEVENT”, “VTODO”, “VJOURNAL” or “VFREEBUSY” calendar components. | Y | Y |
| 4.8.4.7 Unique Identifier | MUST | The UID itself MUST be a globally unique identifier. | Y | Y |
| 4.8.4.7 Unique Identifier | MUST | The generator of the identifier MUST guarantee that the identifier is unique. | Y | Y |
| 4.8.4.7 Unique Identifier | MUST | Implementations MUST be able to receive and persist values of at least 255 characters for this property. | Y | Y |
| 4.8.5.1 Exception Date/Times | MUST | The “EXDATE” property can be used to exclude the value specified in “DTSTART”. However, in such cases the original “DTSTART” date MUST still be maintained by the calendaring and scheduling system because the original “DTSTART” value has inherent usage dependencies by other properties such as the “RECURRENCE-ID”. | Y | Y |
| 4.8.5.1 Exception Date/Times | MUST NOT | the following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATETIME” / “DATE”), tzidparam | Y | Y |
| 4.8.5.1 Exception Date/Times | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.5.3 Recurrence Date/Times | MUST NOT | the following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATETIME” / “DATE” / “PERIOD”), tzidparam | Y | Y |
| 4.8.5.3 Recurrence Date/Times | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 4.8.5.4 Recurrence Rule | MUST | Any duration associated with the iCalendar object applies to all members of the generated recurrence set. Any modified duration for specific recurrences MUST be explicitly specified using the “RDATE” property. | Y | Y |
| 4.8.6.1 Action | MUST | This property MUST be specified once in a “VALARM” calendar component. | Y | Y |
| 4.8.6.3 Trigger | MUST | The value type can be set to a DATE-TIME value type, in which case the value MUST specify a UTC formatted DATE-TIME value. | N | |
| 4.8.6.3 Trigger | MUST | The trigger relationship property parameter MUST only be specified when the value type is DURATION. | N | Y |
| 4.8.6.3 Trigger | MUST | This property MUST be specified in the “VALARM” calendar component. | N | Y |
| 4.8.6.3 Trigger | MUST | If a value type of DATE-TIME is specified, then the property value MUST be specified in the UTC time format. | N | N |
| 4.8.6.3 Trigger | MUST | If the trigger is set relative to START, then the “DTSTART” property MUST be present in the associated “VEVENT” or “VTODO” calendar component. | N | Y |
| 4.8.6.3 Trigger | MUST | If an alarm is specified for an event with the trigger set relative to the END, then the “DTEND” property or the “DSTART” and “DURATION” properties MUST be present in the associated “VEVENT” calendar component. | N | N |
| 4.8.6.3 Trigger | MUST | If the alarm is specified for a to-do with a trigger set relative to the END, then either the “DUE” property or the “DSTART” and “DURATION” properties MUST be present in the associated “VTODO” calendar component. | N | Y |
| 4.8.6.3 Trigger | MUST NOT | the following are optional, but MUST NOT occur more than once: “VALUE” “=” “DURATION”, trigrelparam | N | Y |
| 4.8.6.3 Trigger | MAY | the following is optional, and MAY occur more than once: xparam | N | Y |
| 4.8.6.3 Trigger | REQUIRED | the following is REQUIRED, but MUST NOT occur more than once: “VALUE” “=” “DATETIME” | N | ? |
| 4.8.7.2 Date/Time Stamp | MUST | This property MUST be included in the “VEVENT”, “VTODO”, “VJOURNAL” or “VFREEBUSY” calendar components. | Y | Y |
| 4.8.7.2 Date/Time Stamp | MUST | The value MUST be specified in the UTC time format. | Y | Y |
| 4.8.7.4 Sequence Number | MUST | When the “Organizer” makes changes to one of the following properties, the sequence number MUST be incremented: “DTSTART”, “DTEND”, “DUE”, “RDATE”, “RRULE”, “EXDATE”, “EXRULE”, “STATUS” | Y | Y |
| 4.8.7.4 Sequence Number | MUST | The “Organizer” CUA MUST increment the sequence number when ever it makes changes to properties in the calendar component that the “Organizer” deems will jeopardize the validity of the participation status of the “Attendees”. | ? | ? |
| 4.8.8.2 Request Status | MUST NOT | the following is optional, but MUST NOT occur more than once: languageparm | Y | Y |
| 4.8.8.2 Request Status | MAY | the following is optional, and MAY occur more than once: xparam | Y | Y |
| 6 Recommended Practices | MUST NOT | 2. A calendar entry with a “DTSTART” property but no “DTEND” property does not take up any time. It is intended to represent an event that is associated with a given calendar date and time of day, such as an anniversary. Since the event does not take up any time, it MUST NOT be used to record busy time no matter what the value for the “TRANSP” property. | Y | Y |
| 6 Recommended Practices | SHOULD | 4. When the combination of the “RRULE” and “RDATE” properties on an iCalendar object produces multiple instances having the same start date/time, they should be collapsed to, and considered as, a single instance. | Y | Y |
| RFC 2446 | iCalendar Transport-Independent Interoperability Protocol | |||
|---|---|---|---|---|
| Feature Set | Requirement | Condition | V1 | V2 |
| 3.1 Common Component Restrictions | MUST | CALSCALE 0 or 1 | N | N |
| 3.1 Common Component Restrictions | MUST | PRODID MUST appear | Y | Y |
| 3.1 Common Component Restrictions | MUST | VERSION MUST be 2.0 | Y | Y |
| 3.1 Common Component Restrictions | MUST | VTIMEZONE MUST contain specified required values | Y | Y |
| 3.1 Common Component Restrictions | MUST | VALARM MUST contain specified required values | Y | N |
| 3.2.1 VEVENT PUBLISH | MUST | MUST contain specified required values | N | Y |
| 3.2.1 VEVENT PUBLISH | MUST | MUST contain “Organizer” | N | Y |
| 3.2.1 VEVENT PUBLISH | MUST NOT | MUST NOT contain “Attendees” | N | Y |
| 3.2.2 VEVENT REQUEST | MUST | MUST contain specified required values | Y | Y |
| 3.2.2.1 Rescheduling an Event | MUST | MUST contain existing “UID” but incremented “SEQUENCE” or higher “DTSTAMP” | Y | Y |
| 3.2.2.2 Updating or Reconfirmation of an Event | MUST | MUST contain existing “UID” and current “SEQUENCE” | Y | Y |
| 3.2.2.3 Delegating an Event to another CU | MUST | “Delegator” MUST forward VEVENT REQUEST to “Delegate” showing the “Delegate” as an “Atendee” | Y | N |
| 3.2.2.3 Delegating an Event to another CU | MUST | “Delegator” MUST send VEVENT REPLY to “Organizer” showing “Deletator’s” “Atendee” parstat as “delegated” plus “delegated-to” value | Y | N |
| 3.2.2.3 Delegating an Event to another CU | MUST | “Delegate” MUST send VEVENT REPLY to “Organizer” showing “delegated-from” value | Y | N |
| 3.2.2.6 Forwarding to An Uninvited CU | MAY | 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. | N | N |
| 3.2.2.6 Forwarding to An Uninvited CU | MUST NOT | When forwarding a “REQUEST” to another CU, the forwarding “Attendee” MUST NOT make changes to the VEVENT property set. | N | N |
| 3.2.3 VEVENT REPLY | MUST NOT | The optional properties of the original VEVENT REQUEST MUST NOT be changed from those of the original request. If property changes are desired the COUNTER message must be used. | Y | Y? |
| 3.2.4 VEVENT ADD | MUST | The “UID” MUST be that of an existing VEVENT. | Y | Y |
| 3.2.4 VEVENT ADD | SHOULD | If the “UID” property value in the “ADD” is not found on the recipient’s calendar, then the recipient SHOULD send a “REFRESH” to the “Organizer” in order to be updated with the latest version of the “VEVENT”. | Y | Y? |
| 3.2.4 VEVENT ADD | SHOULD | If an “Attendee” implementation does not support the “ADD” method it should respond with a “REQUEST-STATUS” value of 3.14 and ask for a “REFRESH”. | Y | Y |
| 3.2.4 VEVENT CANCEL | MUST | To cancel the complete range of recurring event, the “UID” property value for the event MUST be specified and a “RECURRENCE-ID” MUST NOT be specified in the “CANCEL” method. | N | Y |
| 3.2.4 VEVENT CANCEL | MUST | In order to cancel an individual instance of the event, the “RECURRENCE-ID” property value for the event MUST be specified in the “CANCEL” method. | Y | Y |
| 3.2.4 VEVENT CANCEL | MUST | Canceling multiple VEVENT instances MUST be done with either “RECURRENCE-ID” and “RANGE” OR multiple “RECURRENCE-ID” values. | Y | Y |
| 3.2.4 VEVENT CANCEL | MUST | When a “VEVENT” is cancelled, the “SEQUENCE” property value MUST be incremented. | N? | Y |
| 3.3 Methods For VFREEBUSY Components | MUST | This document only addresses the transfer of busy time information. Applications desiring free time information MUST infer this from available busy time information. | N | Y |
| 3.3 Methods For VFREEBUSY Components | MAY | The busy time information within the iCalendar object MAY be grouped into more than one “VFREEBUSY” calendar component. | N | N |
| 3.3 Methods For VFREEBUSY Components | MAY | The “FREEBUSY” property value MAY include a list of values, separated by the COMMA character ([US-ASCII] decimal 44). | N | N |
| 3.3 Methods For VFREEBUSY Components | MAY | Alternately, multiple busy time periods MAY be specified with multiple instances of the “FREEBUSY” property. | N | N |
| 3.3 Methods For VFREEBUSY Components | MUST | Both forms MUST be supported by implementations conforming to this document. | N | N |
| 3.3 Methods For VFREEBUSY Components | SHOULD NOT | Duplicate busy time periods SHOULD NOT be specified in an iCalendar object | N | Y |
| 3.3 Methods For VFREEBUSY Components | MAY | However, two different busy time periods MAY overlap. | N | Y |
| 3.3 Methods For VFREEBUSY Components | SHOULD | “FREEBUSY” properties should be sorted such that their values are in ascending order, based on the start time, and then the end time, with the earliest periods first. | N | Y |
| 3.3.1 VFREEBUSY PUBLISH | MUST | The “ATTENDEE” property must be specified in the busy time information. The value is the CU address of the originator of the busy time information. | N | Y |
| 3.3.2 VFREEBUSY `REQUEST | SHOULD | If the originator of the “REQUEST” method is not authorized to make a busy time request on the recipient’s calendar system, then an exception message SHOULD be returned in a “REPLY” method, but no busy time data need be returned. | N | N |
| 3.3.3 VFREEBUSY REPLY | MAY | The “REPLY” method may also be used to respond to an unsuccessful “REQUEST” method. Depending on the “REQUEST-STATUS” value, no busy time information may be returned. | N | N |
| 3.4.1 VTODO PUBLISH | MUST | VTODO PUBLISH MUST have an “Organizer” | ? | N |
| 3.4.1 VTODO PUBLISH | MUST NOT | VTODO PUBLISH MUST NOT have “Attendees” | ? | N |
| 3.4.1 VTODO PUBLISH | MAY | 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 “VTODO” calendar component. | ? | N |
| 3.4.2 VTODO REQUEST | MAY | VTODO REQUEST MAY be a new request or a rescheduling of a VTODO depending on the values of the “UID”, “SEQUENCE”, and “DTSTAMP” properties. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | MUST NOT | An “Attendee” of a “VTODO” calendar component MUST NOT delegate to the “Organizer” of the event. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | MUST | The “Delegator” of a “VTODO” calendar component MUST forward the existing “REQUEST” method for a “VTODO” calendar component to the “Delegate”. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | MUST | The “VTODO” calendar component description MUST include the “Delegator’s” up-to-date “VTODO” calendar component definition. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | MUST | The “REQUEST” method MUST also include an “ATTENDEE” property with the calendar address of the “Delegate”. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | MUST | The “Delegator” MUST also send a “REPLY” method back to the “Organizer” with the “Delegator’s” “Attendee” property “partstat” parameter value set to “DELEGATED”. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | MUST | The “delegated-to” parameter MUST be included with the calendar address of the “Delegate”. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | SHOULD | The “REPLY” method from the “Delegate” SHOULD include the “ATTENDEE” property with their calendar address and the “delegated-from” parameter with the value of the “Delegator’s” calendar address. | Y | N |
| 3.4.2.3 REQUEST for Delegating a VTODO | MUST | The delegation “REQUEST” method MUST assign a value for the “RSVP” property parameter associated with the “Delegator’s” “Attendee” property to that of the “Delegate’s” “ATTENDEE” property. For example if the “Delegator’s” “ATTENDEE” property specifies “RSVP=TRUE”, then the “Delegate’s” “ATTENDEE” property MUST specify “RSVP=TRUE”. | Y | N |
| 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User | MAY | An “Attendee” assigned a “VTODO” calendar component may send the “VTODO” calendar component to another new CU, not previously associated with the “VTODO” calendar component. | N | N |
| 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User | MAY | The new CU can send a “REPLY” to the “Organizer” of the “VTODO” calendar component. | N | N |
| 3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User | MAY | The “Organizer” MAY send the CU a “CANCEL” message to indicate that they will not be added to the to-do. | N | N |
| 3.4.3 VTODO REPLY | MUST | When used to provide a delegation response, the “Delegator” MUST include the calendar address of the “Delegate” in the “delegated-to” parameter of the “Delegator’s” “ATTENDEE” property. | Y | N |
| 3.4.3 VTODO REPLY | MUST | The “Delegate” MUST include the calendar address of the “Delegator” on the “delegated-from” parameter of the “Delegate’s” “ATTENDEE” property. | Y | N |
| 3.4.3 VTODO REPLY | MAY | The “REPLY” method MAY also be used to respond to an unsuccessful “VTODO” calendar component “REQUEST” method. | Y | N |
| 3.4.3 VTODO REPLY | MAY | The “Organizer” of a “VTODO” calendar component MAY receive a “REPLY” method from a “Calendar User” not in the original “REQUEST”. This uninvited “Attendee” MAY be accepted, or the “Organizer” MAY cancel the “VTODO” calendar component for the uninvited “Attendee” by sending them a “CANCEL” method. | Y | N |
| 3.4.4 VTODO ADD | SHOULD | If the “UID” property value in the “ADD” is not found on the recipient’s calendar, then the recipient SHOULD send a “REFRESH” to the “Organizer” in order to be updated with the latest version of the “VTODO”. If an “Attendee” implementation does not support the “ADD” method it should respond with a “REQUEST-STATUS” value of 5.3 and ask for a “REFRESH”. | Y | N |
| 3.4.5 VTODO CANCEL | MUST | To cancel the complete range of a recurring “VTODO” calendar component, the “UID” property value for the “VTODO” calendar component MUST be specified and a “RECURRENCE-ID” MUST NOT be specified in the “CANCEL” method. | Y | N |
| 3.4.5 VTODO CANCEL | MUST | In order to cancel an individual instance of a recurring “VTODO” calendar component, the “RECURRENCE-ID” property value for the “VTODO” calendar component MUST be specified in the “CANCEL” method. | Y | N |
| 3.4.5 VTODO CANCEL | MUST | When a “VTODO” is cancelled, the “SEQUENCE” property value MUST be incremented. | N | N |
| 3.4.6 VTODO REFRESH | MAY | The “Organizer” of the “VTODO” calendar component MAY use this method to request an updated status from the “Attendees”. | N | N |
| 3.4.6 VTODO REFRESH | MUST | The “REFRESH” method MUST specify the “UID” property corresponding to the “VTODO” calendar component needing update. | N | N |
| 3.4.6 VTODO REFRESH | MUST | A refresh of a recurrence instance of a “VTODO” calendar component may be requested by specifying the “RECURRENCE-ID” property corresponding to the associated “VTODO” calendar component. The “Organizer” responds with the latest description and rendition of the “VTODO” calendar component. In most cases this will be a REQUEST unless the “VTODO” has been cancelled, in which case the ORGANIZER MUST send a “CANCEL”. This method is intended to facilitate machine processing of requests for updates to a “VTODO” calendar component. | N | N |
| 3.4.7 VTODO COUNTER | SHOULD | The “Organizer” accepts the counter proposal by sending all of the “Attendees” of the “VTODO” calendar component a “REQUEST” method rescheduling the “VTODO” calendar component. In the latter case, the “Organizer” SHOULD reset the individual “RSVP” property parameter values to TRUE on each “ATTENDEE” property; in order to force a response by the “Attendees”. | Y | N |
| 3.5.1 VJOURNAL PUBLISH | MUST | VJOURNAL PUBLISH MUST have an “Organizer”. | N | N |
| 3.5.1 VJOURNAL PUBLISH | MUST NOT | VJOURNAL PUBLISH MUST NOT have “Attendees”. | N | N |
| 3.5.1 VJOURNAL PUBLISH | MAY | The “Organizer” MAY subsequently update (with another “PUBLISH” method) or cancel (with a “CANCEL” method) a previously published journal entry. | N | N |
| 3.5.2 VJOURNAL ADD | MAY | If the “UID” property value in the “ADD” is not found on the recipient’s calendar, then the recipient MAY treat the “ADD” as a “PUBLISH”. | N | N |
| 3.5.3 VJOURNAL CANCEL | MUST | To cancel the complete range of a recurring journal entry, the “UID” property value for the journal entry MUST be specified and a “RECURRENCE-ID” property MUST NOT be specified in the “CANCEL” method. | N | N |
| 3.5.3 VJOURNAL CANCEL | MUST | In order to cancel an individual instance of the journal entry, the “RECURRENCE-ID” property value for the journal entry MUST be specified in the “CANCEL” method. | N | N |
| 3.5.3 VJOURNAL CANCEL | MUST | When a “VJOURNAL” is cancelled, the “SEQUENCE” property value MUST be incremented. | N | N |
| 3.6 Status Replies | MAY | Various optional responses MAY be added to the various Status Replies to explain the particular Status value | Y | Y |
| 3.7.2 Attendee Property Considerations | MUST | The “ORGANIZER” property is required on published events, to-dos, and journal entries for two reasons. First, only the “Organizer” is allowed to update and redistribute an event or to-do component. It follows that the “ORGANIZER” property MUST be present in the event, to-do, or journal entry component so that the CUA has a basis for authorizing an update. Second, it is prudent to provide a point of contact for anyone who receives a published component in case of problems. | Y | Y |
| 3.7.2 Attendee Property Considerations | MAY | There are valid <rfc822>> addresses that represent groups. Sending email to such an address results in mail being sent to multiple recipients. Such an address may be used as the value of an “ATTENDEE” property. | Y | Y |
| 3.7.2 Attendee Property Considerations | MUST | Look for attendees where “TYPE=GROUP” or “TYPE=UNKNOWN”. The CUA then determines if the “Calendar User” is a member of one of these groups. If so, the “REPLY” method sent to the “Organizer” MUST contain a new “ATTENDEE” property in which:
| N | N |
| 5 Application Protocol Fallbacks | SHOULD | Applications that support this memo are not required to support the entire protocol. The following describes how methods and properties SHOULD “fallback” in applications that do not support the complete protocol. | Y | Y |
| RFC 2447 | iCalendar Message-Based Interoperability Protocol | |||
|---|---|---|---|---|
| Feature Set | Requirement | Condition | V1 | V2 |
| 2.2.1 Authorization | SHOULD | Implementations of iMIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action. The methods for doing this are presented later in this document. | Y | Y |
| 2.3 IETF RFC 822 Addresses | MUST | The calendar address specified within the “ATTENDEE” property in an iCalendar object MUST be a fully qualified, IETF RFC 822 address specification for the corresponding “Organizer” or “Attendee” of the “VEVENT” or “VTODO”. | Y | Y |
| 2.3 IETF RFC 822 Addresses | MUST | The addresses of “Organizers” or “Attendees” MUST be ascertained by opening the “text/calendar” MIME body part and examining the “ATTENDEE” and “ORGANIZER” properties. | Y | N |
| 2.4 Content Type | MUST | A MIME body part containing content information that conforms to this document MUST have an IETF RFC 2045 “Content-Type” value of text/calendar”. | Y | Y |
| 2.4 Content Type | MUST | The IETF RFC 2045 “Content-Type” header field must also include the type parameter “method”. The value MUST be the same as the value of the “METHOD” calendar property within the iCalendar object. This means that a MIME message containing multiple iCalendar objects with different method values must be further encapsulated with a “multipart/mixed” MIME entity. This will allow each of the iCalendar objects to be encapsulated within their own “text/calendar” MIME entity. | Y | Y |
| 2.4 Content Type | MUST | A “charset” parameter MUST be present if the iCalendar object contains characters that are not part of the US-ASCII character set. IETF RFC 2046 discusses the selection of an appropriate “charset” value. | Y | Y |
| 2.4 Content Type | SHOULD | In order to permit the information in the scheduling message to be understood by MIME user agents (UA) that do not support the “text/calendar” content type, scheduling messages SHOULD be sent with an alternative, human-readable form of the information. | Y | Y |
| 2.5 Content-Transfer-Encoding | SHOULD | A transfer encoding SHOULD be used for iCalendar objects containing any characters that are not part of the US-ASCII character set. | Y | Y |
| 2.6 Content-Disposition | SHOULD | The handling of a MIME part should be based on its IETF RFC 2045 “Content-Type”. However, this is not guaranteed to work in all environments. Some environments handle MIME attachments based on their file type or extension. To operate correctly in these environments, implementations may wish to include a “Content-Disposition” property to define a file name. | Y | Y |
| 3 Security Considerations | MUST | Compliant applications MUST support signing and encrypting text/calendar attachments using a mechanism based on Security Multiparts for MIME IETF RFC 1847 to facilitate the authentication the originator of the iCalendar object. | N | N |
| 3 Security Considerations | MAY | Implementations MAY provide a means for users to disable signing and encrypting. | N | N |
| 3 Security Considerations | MUST | 1. The iCalendar object MUST be signed by the “Organizer” sending an update or the “Attendee” sending a reply. | N | N |
| 3 Security Considerations | SHOULD | To address the confidentiality security threats, signed iMIP messages SHOULD be encrypted by a mechanism based on Security Multiparts for MIME IETF RFC 1847. | N | N |
| 3 Security Considerations | MUST | Implementations MUST provide mechanisms for the “Calendar Users” to make that decision before applying changes from someone working on behalf of a “Calendar User”. | N | N |
Bibliography
[1] IETF RFC 1738, T. BERNERS-LEE, L. MASINTER and M. MCCAHILL. Uniform Resource Locators (URL). 1994. RFC Publisher. https://www.rfc-editor.org/info/rfc1738.
[2] IETF RFC 822, D. CROCKER. STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. 1982. RFC Publisher. https://www.rfc-editor.org/info/rfc822.
[3] IETF RFC 1847, J. GALVIN, S. MURPHY, S. CROCKER and N. FREED. Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. 1995. RFC Publisher. https://www.rfc-editor.org/info/rfc1847.
[4] IETF RFC 2045, N. FREED and N. BORENSTEIN. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. 1996. RFC Publisher. https://www.rfc-editor.org/info/rfc2045.
[5] IETF RFC 2046, N. FREED and N. BORENSTEIN. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. 1996. RFC Publisher. https://www.rfc-editor.org/info/rfc2046.
[6] ISO 9070, International Organization for Standardization. Information processing — SGML support facilities — Registration procedures for public text owner identifiers. First edition. Geneva. https://www.iso.org/standard/16644.html.