draft-ietf-calsify-rfc2445bis-06.txt   draft-ietf-calsify-rfc2445bis-07.txt 
Network Working Group B. Desruisseaux, Ed. Network Working Group B. Desruisseaux, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Obsoletes: 2445 (if approved) March 2, 2007 Obsoletes: 2445 (if approved) July 8, 2007
Intended status: Standards Track Intended status: Standards Track
Expires: September 3, 2007 Expires: January 9, 2008
Internet Calendaring and Scheduling Core Object Specification Internet Calendaring and Scheduling Core Object Specification
(iCalendar) (iCalendar)
draft-ietf-calsify-rfc2445bis-06 draft-ietf-calsify-rfc2445bis-07
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines a MIME media type for representing and This document defines the iCalendar data format for representing and
exchanging calendaring and scheduling information such as events, to- exchanging calendaring and scheduling information such as events, to-
dos, journal entries and free/busy information. The definition of dos, journal entries and free/busy information, independent of any
the text/calendar media type, known as iCalendar, is independent of particular calendar service or protocol.
any particular calendar service or protocol.
Editorial Note (To be removed by RFC Editor prior to publication) Editorial Note (To be removed by RFC Editor prior to publication)
This document is a product of the Calendaring and Scheduling This document is a product of the Calendaring and Scheduling
Standards Simplification (Calsify) working group of the Internet Standards Simplification (Calsify) working group of the Internet
Engineering Task Force. Comments on this draft are welcomed, and Engineering Task Force. Comments on this draft are welcomed, and
should be addressed to the ietf-calsify@osafoundation.org [1] mailing should be addressed to the ietf-calsify@osafoundation.org [1] mailing
list. The issues raised on this mailing list are being tracked at list.
the following web site:
http://www.ofcourseimright.com/cgi-bin/roundup/calsify.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 7 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 7
2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 7 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 7
2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8
2.3. International Considerations . . . . . . . . . . . . . . 8
3. iCalendar Object Specification . . . . . . . . . . . . . . . 9 3. iCalendar Object Specification . . . . . . . . . . . . . . . 9
3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11
3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12
3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12
3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13
3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13
3.2.1. Alternate Text Representation . . . . . . . . . . . . 14 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14
3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15
3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16
3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16
3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17
3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18
3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18
3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19
3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19
3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20
3.2.11. Group or List Membership . . . . . . . . . . . . . . 21 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21
3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 3.2.12. Participation Status . . . . . . . . . . . . . . . . 22
3.2.13. Alarm Trigger Relationship . . . . . . . . . . . . . 23 3.2.13. Alarm Trigger Relationship . . . . . . . . . . . . . 24
3.2.14. Relationship Type . . . . . . . . . . . . . . . . . . 23 3.2.14. Relationship Type . . . . . . . . . . . . . . . . . . 24
3.2.15. Participation Role . . . . . . . . . . . . . . . . . 24 3.2.15. Participation Role . . . . . . . . . . . . . . . . . 25
3.2.16. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 3.2.16. RSVP Expectation . . . . . . . . . . . . . . . . . . 26
3.2.17. Sent By . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.17. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.18. Time Zone Identifier . . . . . . . . . . . . . . . . 26 3.2.18. Time Zone Identifier . . . . . . . . . . . . . . . . 27
3.2.19. Value Data Types . . . . . . . . . . . . . . . . . . 27 3.2.19. Value Data Types . . . . . . . . . . . . . . . . . . 28
3.3. Property Value Data Types . . . . . . . . . . . . . . . . 28 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29
3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31
3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32
3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 33 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34
3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 35 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 37
3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 36 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38
3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 46 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49
3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 47 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50
3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 47 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 48 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51
3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 49 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52
3.6.2. To-do Component . . . . . . . . . . . . . . . . . . . 52 3.6.2. To-do Component . . . . . . . . . . . . . . . . . . . 56
3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 54 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58
3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 56 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60
3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 59 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63
3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 68 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72
3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 74 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77
3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 74 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77
3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 74 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78
3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 75 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79
3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 76 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80
3.8. Component Properties . . . . . . . . . . . . . . . . . . 77 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81
3.8.1. Descriptive Component Properties . . . . . . . . . . 77 3.8.1. Descriptive Component Properties . . . . . . . . . . 81
3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 77 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81
3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 79 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82
3.8.1.3. Classification . . . . . . . . . . . . . . . . . 80 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83
3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 81 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84
3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 82 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85
3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 83 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 86
3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 84 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88
3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 86 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89
3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 86 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90
3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 88 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92
3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 89 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93
3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 91 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94
3.8.2. Date and Time Component Properties . . . . . . . . . 92 3.8.2. Date and Time Component Properties . . . . . . . . . 95
3.8.2.1. Date/Time Completed . . . . . . . . . . . . . . . 92 3.8.2.1. Date/Time Completed . . . . . . . . . . . . . . . 95
3.8.2.2. Date/Time End . . . . . . . . . . . . . . . . . . 92 3.8.2.2. Date/Time End . . . . . . . . . . . . . . . . . . 96
3.8.2.3. Date/Time Due . . . . . . . . . . . . . . . . . . 93 3.8.2.3. Date/Time Due . . . . . . . . . . . . . . . . . . 97
3.8.2.4. Date/Time Start . . . . . . . . . . . . . . . . . 95 3.8.2.4. Date/Time Start . . . . . . . . . . . . . . . . . 99
3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 96 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100
3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 97 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101
3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 98 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102
3.8.3. Time Zone Component Properties . . . . . . . . . . . 99 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103
3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 99 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103
3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 101 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105
3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 102 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106
3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 102 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106
3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 103 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107
3.8.4. Relationship Component Properties . . . . . . . . . . 104 3.8.4. Relationship Component Properties . . . . . . . . . . 108
3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 104 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108
3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 107 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111
3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 108 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 112
3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 110 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114
3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 112 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 116
3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 114 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118
3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 114 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 118
3.8.5. Recurrence Component Properties . . . . . . . . . . . 116 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120
3.8.5.1. Exception Date/Times . . . . . . . . . . . . . . 116 3.8.5.1. Exception Date/Times . . . . . . . . . . . . . . 120
3.8.5.2. Recurrence Date/Times . . . . . . . . . . . . . . 118 3.8.5.2. Recurrence Date/Times . . . . . . . . . . . . . . 122
3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 119 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 123
3.8.6. Alarm Component Properties . . . . . . . . . . . . . 130 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134
3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 130 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134
3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 130 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 134
3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 131 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135
3.8.7. Change Management Component Properties . . . . . . . 134 3.8.7. Change Management Component Properties . . . . . . . 138
3.8.7.1. Date/Time Created . . . . . . . . . . . . . . . . 134 3.8.7.1. Date/Time Created . . . . . . . . . . . . . . . . 138
3.8.7.2. Date/Time Stamp . . . . . . . . . . . . . . . . . 134 3.8.7.2. Date/Time Stamp . . . . . . . . . . . . . . . . . 138
3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 135 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 139
3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 136 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 140
3.8.8. Miscellaneous Component Properties . . . . . . . . . 138 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142
3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 138 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142
3.8.8.2. Non-standard Properties . . . . . . . . . . . . . 138 3.8.8.2. Non-standard Properties . . . . . . . . . . . . . 143
3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 139 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144
4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 143 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 147
5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 147 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 151
6. Registration of Content Type Elements . . . . . . . . . . . . 148 6. Internationalization Considerations . . . . . . . . . . . . . 152
6.1. Registration of New and Modified iCalendar Object 7. Security Considerations . . . . . . . . . . . . . . . . . . . 152
Methods . . . . . . . . . . . . . . . . . . . . . . . . . 148 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 152
6.2. Registration of New Properties . . . . . . . . . . . . . 148 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 153
6.2.1. Define the property . . . . . . . . . . . . . . . . . 149 8.2. New iCalendar Elements Registration . . . . . . . . . . . 156
6.2.2. Post the Property definition . . . . . . . . . . . . 150 8.2.1. iCalendar Elements Registration Procedure . . . . . . 156
6.2.3. Allow a comment period . . . . . . . . . . . . . . . 150 8.2.2. Registration Template for Components . . . . . . . . 156
6.2.4. Submit the property for approval . . . . . . . . . . 150 8.2.3. Registration Template for Properties . . . . . . . . 157
6.3. Property Change Control . . . . . . . . . . . . . . . . . 151 8.2.4. Registration Template for Parameters . . . . . . . . 158
7. Internationalization Considerations . . . . . . . . . . . . . 151 8.2.5. Registration Template for Value Data Types . . . . . 158
8. Security Considerations . . . . . . . . . . . . . . . . . . . 151 8.2.6. Registration Template for Values . . . . . . . . . . 158
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 152 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 159
9.1. Components Registry . . . . . . . . . . . . . . . . . . . 152 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 159
9.2. Properties Registry . . . . . . . . . . . . . . . . . . . 153 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 160
9.3. Property Parameters Registry . . . . . . . . . . . . . . 154 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161
9.4. Value Data Type Values Registry . . . . . . . . . . . . . 155 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162
9.5. Calendar User Type Values Registry . . . . . . . . . . . 156 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 163
9.6. Free/Busy Time Type Values Registry . . . . . . . . . . . 156 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163
9.7. Participation Status Values Registry . . . . . . . . . . 157 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163
9.8. Relationship Type Values Registry . . . . . . . . . . . . 157 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164
9.9. Participation Role Values Registry . . . . . . . . . . . 158 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164
9.10. Action Values Registry . . . . . . . . . . . . . . . . . 158 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 164
9.11. Method Values Registry . . . . . . . . . . . . . . . . . 158 8.3.11. Classifications Registry . . . . . . . . . . . . . . 164
9.12. Media Type Registration Information . . . . . . . . . . . 158 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 161 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 165
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 162 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 165
11.1. Normative References . . . . . . . . . . . . . . . . . . 162 10.1. Normative References . . . . . . . . . . . . . . . . . . 165
11.2. Informative References . . . . . . . . . . . . . . . . . 163 10.2. Informative References . . . . . . . . . . . . . . . . . 167
Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 164 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 168
A.1. New restrictions . . . . . . . . . . . . . . . . . . . . 164 A.1. New restrictions . . . . . . . . . . . . . . . . . . . . 168
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 165 A.2. Restrictions removed . . . . . . . . . . . . . . . . . . 168
A.3. Deprecated features . . . . . . . . . . . . . . . . . . . 168
Appendix B. Change Log (to be removed by RFC Editor prior to Appendix B. Change Log (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 165 publication) . . . . . . . . . . . . . . . . . . . . 169
B.1. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 165 B.1. Changes in -07 . . . . . . . . . . . . . . . . . . . . . 169
B.2. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 166 B.2. Changes in -06 . . . . . . . . . . . . . . . . . . . . . 170
B.3. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 167 B.3. Changes in -05 . . . . . . . . . . . . . . . . . . . . . 172
B.4. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 169 B.4. Changes in -04 . . . . . . . . . . . . . . . . . . . . . 172
B.5. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 169 B.5. Changes in -03 . . . . . . . . . . . . . . . . . . . . . 174
B.6. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 170 B.6. Changes in -02 . . . . . . . . . . . . . . . . . . . . . 174
B.7. Changes in -01 . . . . . . . . . . . . . . . . . . . . . 175
Appendix C. Open issues (to be removed by RFC Editor prior to Appendix C. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 170 publication) . . . . . . . . . . . . . . . . . . . . 175
C.1. update_intro . . . . . . . . . . . . . . . . . . . . . . 170 C.1. introduction . . . . . . . . . . . . . . . . . . . . . . 175
C.2. update_vtimezone_examples . . . . . . . . . . . . . . . . 170 C.2. #issue11+4.3.10_byxxx_rule_part_examples . . . . . . . . 175
C.3. #issue10+end_date_not_inclusive . . . . . . . . . . . . . 171 C.3. #issue63+4.8.5.3_rdate_and_dtstart . . . . . . . . . . . 176
C.4. #issue61+ianaparam . . . . . . . . . . . . . . . . . . . 171
C.5. #issue11+4.3.10_byxxx_rule_part_examples . . . . . . . . 171
C.6. #issue75+4.6.5_rdate_format_in_vtimezone . . . . . . . . 171
C.7. #issue79+4.6.5_dtstart_and_rdate_in_vtimezone . . . . . . 172
C.8. 4.8.1.1_attach_description_incomplete . . . . . . . . . . 172
C.9. 4.8.1.4_comment_description_incomplete . . . . . . . . . 172
C.10. 4.8.2.1_completed_description_incomplete . . . . . . . . 172
C.11. #issue76+4.8.2.2_dtend_dtstart_value_type . . . . . . . . 172
C.12. #issue77+4.8.2.3_due_dtstart_value_type . . . . . . . . . 173
C.13. 4.8.2.3_due_description_incomplete . . . . . . . . . . . 173
C.14. #issue63+4.8.5.3_rdate_and_dtstart . . . . . . . . . . . 173
C.15. 4.8.6.2_repeat_description_incomplete . . . . . . . . . . 173
C.16. 4.8.7.1_created_description_incomplete . . . . . . . . . 174
C.17. 4.8.7.2_dtstamp_description_incomplete . . . . . . . . . 174
C.18. #issue65+6_recommended_practices_tzid . . . . . . . . . . 174
C.19. add_i18n_section . . . . . . . . . . . . . . . . . . . . 174
C.20. #issue19+iana_considerations . . . . . . . . . . . . . . 174
1. Introduction 1. Introduction
The use of calendaring and scheduling has grown considerably in the The use of calendaring and scheduling has grown considerably in the
last decade. Enterprise and inter-enterprise business has become last decade. Enterprise and inter-enterprise business has become
dependent on rapid scheduling of events and actions using this dependent on rapid scheduling of events and actions using this
information technology. However, the longer term growth of information technology. However, the longer term growth of
calendaring and scheduling is currently limited by the lack of calendaring and scheduling is currently limited by the lack of
Internet standards for the message content types that are central to Internet standards for the message content types that are central to
these knowledgeware applications. This memo is intended to progress these knowledgeware applications. This memo is intended to progress
skipping to change at page 8, line 26 skipping to change at page 8, line 26
defined by this memo are referred to with lowercase, quoted-strings defined by this memo are referred to with lowercase, quoted-strings
of text, followed by the word "parameter". For example, "value" of text, followed by the word "parameter". For example, "value"
parameter refers to the iCalendar property parameter used to override parameter refers to the iCalendar property parameter used to override
the default value type for a property value. Enumerated values the default value type for a property value. Enumerated values
defined by this memo are referred to with capitalized text, either defined by this memo are referred to with capitalized text, either
alone or followed by the word "value". For example, the "MINUTELY" alone or followed by the word "value". For example, the "MINUTELY"
value can be used with the "FREQ" component of the "RECUR" value type value can be used with the "FREQ" component of the "RECUR" value type
to specify repeating components based on an interval of one minute or to specify repeating components based on an interval of one minute or
more. more.
In this document, descriptions of characters are of the form
"character name (codepoint)", where "codepoint" is from the US-ASCII
character set. The "character name" is the authoritative
description; (codepoint) is a reference to that character in US-
ASCII.
2.2. Related Memos 2.2. Related Memos
Implementers will need to be familiar with several other memos that, Implementers will need to be familiar with several other memos that,
along with this memo, form a framework for Internet calendaring and along with this memo, form a framework for Internet calendaring and
scheduling standards. This memo specifies a core specification of scheduling standards. This memo specifies a core specification of
objects, value types, properties and property parameters. objects, value types, properties and property parameters.
o iTIP [I-D.ietf-calsify-2446bis] specifies an interoperability o iTIP [I-D.ietf-calsify-2446bis] specifies an interoperability
protocol for scheduling between different implementations; protocol for scheduling between different implementations;
o iMIP [I-D.ietf-calsify-rfc2447bis] specifies an Internet email o iMIP [I-D.ietf-calsify-rfc2447bis] specifies an Internet email
binding for [I-D.ietf-calsify-2446bis]. binding for [I-D.ietf-calsify-2446bis].
This memo does not attempt to repeat the specification of concepts or This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are definitions from these other memos. Where possible, references are
made to the memo that provides for the specification of these made to the memo that provides for the specification of these
concepts or definitions. concepts or definitions.
2.3. International Considerations
In the rest of this document, descriptions of characters are of the
form "character name (codepoint)", where "codepoint" is from the US-
ASCII character set. The "character name" is the authoritative
description; (codepoint) is a reference to that character in US-
ASCII.
3. iCalendar Object Specification 3. iCalendar Object Specification
The following sections define the details of a Calendaring and The following sections define the details of a Calendaring and
Scheduling Core Object Specification. This information is intended Scheduling Core Object Specification. This information is intended
to be an integral part of the MIME content type registration. In to be an integral part of the MIME content type registration. In
addition, this information can be used independent of such content addition, this information can be used independent of such content
registration. In particular, this memo has direct applicability for registration. In particular, this memo has direct applicability for
use as a calendaring and scheduling exchange format in file-, memory- use as a calendaring and scheduling exchange format in file-, memory-
or network-based transport mechanisms. or network-based transport mechanisms.
skipping to change at page 14, line 34 skipping to change at page 14, line 34
/ other-param / other-param
other-param = (iana-param / x-param) other-param = (iana-param / x-param)
iana-param = iana-token "=" param-value *("," param-value) iana-param = iana-token "=" param-value *("," param-value)
; Some other IANA registered iCalendar parameter. ; Some other IANA registered iCalendar parameter.
x-param = x-name "=" param-value *("," param-value) x-param = x-name "=" param-value *("," param-value)
; A non-standard, experimental parameter. ; A non-standard, experimental parameter.
Applications MUST ignore x-param and iana-param value they don't
recognized.
3.2.1. Alternate Text Representation 3.2.1. Alternate Text Representation
Parameter Name: ALTREP Parameter Name: ALTREP
Purpose: To specify an alternate text representation for the Purpose: To specify an alternate text representation for the
property value. property value.
Format Definition: This property parameter is defined by the Format Definition: This property parameter is defined by the
following notation: following notation:
skipping to change at page 16, line 34 skipping to change at page 16, line 40
/ "UNKNOWN" ; Otherwise not known / "UNKNOWN" ; Otherwise not known
/ x-name ; Experimental type / x-name ; Experimental type
/ iana-token) ; Other IANA registered / iana-token) ; Other IANA registered
; type ; type
; Default is INDIVIDUAL ; Default is INDIVIDUAL
Description: This parameter can be specified on properties with a Description: This parameter can be specified on properties with a
CAL-ADDRESS value type. The parameter identifies the type of CAL-ADDRESS value type. The parameter identifies the type of
calendar user specified by the property. If not specified on a calendar user specified by the property. If not specified on a
property that allows this parameter, the default is INDIVIDUAL. property that allows this parameter, the default is INDIVIDUAL.
Applications MUST treat x-name and iana-token value they don't
recognized the same way as the INDIVIDUAL value.
Example: Example:
ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org
3.2.4. Delegators 3.2.4. Delegators
Parameter Name: DELEGATED-FROM Parameter Name: DELEGATED-FROM
Purpose: To specify the calendar users that have delegated their Purpose: To specify the calendar users that have delegated their
participation to the calendar user specified by the property. participation to the calendar user specified by the property.
Format Definition: This property parameter is defined by the Format Definition: This property parameter is defined by the
following notation: following notation:
delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address
DQUOTE *("," DQUOTE cal-address DQUOTE) DQUOTE *("," DQUOTE cal-address DQUOTE)
skipping to change at page 20, line 14 skipping to change at page 20, line 27
Description: This parameter specifies the free or busy time type. Description: This parameter specifies the free or busy time type.
The value FREE indicates that the time interval is free for The value FREE indicates that the time interval is free for
scheduling. The value BUSY indicates that the time interval is scheduling. The value BUSY indicates that the time interval is
busy because one or more events have been scheduled for that busy because one or more events have been scheduled for that
interval. The value BUSY-UNAVAILABLE indicates that the time interval. The value BUSY-UNAVAILABLE indicates that the time
interval is busy and that the interval can not be scheduled. The interval is busy and that the interval can not be scheduled. The
value BUSY-TENTATIVE indicates that the time interval is busy value BUSY-TENTATIVE indicates that the time interval is busy
because one or more events have been tentatively scheduled for because one or more events have been tentatively scheduled for
that interval. If not specified on a property that allows this that interval. If not specified on a property that allows this
parameter, the default is BUSY. parameter, the default is BUSY. Applications MUST treat x-name
and iana-token value they don't recognized the same way as the
BUSY value.
Example: The following is an example of this parameter on a Example: The following is an example of this parameter on a
"FREEBUSY" property. "FREEBUSY" property.
FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z
3.2.10. Language 3.2.10. Language
Parameter Name: LANGUAGE Parameter Name: LANGUAGE
skipping to change at page 23, line 7 skipping to change at page 24, line 7
; Default is NEEDS-ACTION. ; Default is NEEDS-ACTION.
Description: This parameter can be specified on properties with a Description: This parameter can be specified on properties with a
CAL-ADDRESS value type. The parameter identifies the CAL-ADDRESS value type. The parameter identifies the
participation status for the calendar user specified by the participation status for the calendar user specified by the
property value. The parameter values differ depending on whether property value. The parameter values differ depending on whether
they are associated with a group scheduled "VEVENT", "VTODO" or they are associated with a group scheduled "VEVENT", "VTODO" or
"VJOURNAL". The values MUST match one of the values allowed for "VJOURNAL". The values MUST match one of the values allowed for
the given calendar component. If not specified on a property that the given calendar component. If not specified on a property that
allows this parameter, the default value is NEEDS-ACTION. allows this parameter, the default value is NEEDS-ACTION.
Applications MUST treat x-name and iana-token value they don't
recognized the same way as the NEEDS-ACTION value.
Example: Example:
ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com
3.2.13. Alarm Trigger Relationship 3.2.13. Alarm Trigger Relationship
Parameter Name: RELATED Parameter Name: RELATED
Purpose: To specify the relationship of the alarm trigger with Purpose: To specify the relationship of the alarm trigger with
skipping to change at page 24, line 24 skipping to change at page 25, line 24
Description: This parameter can be specified on a property that Description: This parameter can be specified on a property that
references another related calendar. The parameter specifies the references another related calendar. The parameter specifies the
hierarchical relationship type of the calendar component hierarchical relationship type of the calendar component
referenced by the property. The parameter value can be PARENT, to referenced by the property. The parameter value can be PARENT, to
indicate that the referenced calendar component is a superior of indicate that the referenced calendar component is a superior of
calendar component; CHILD to indicate that the referenced calendar calendar component; CHILD to indicate that the referenced calendar
component is a subordinate of the calendar component; SIBLING to component is a subordinate of the calendar component; SIBLING to
indicate that the referenced calendar component is a peer of the indicate that the referenced calendar component is a peer of the
calendar component. If this parameter is not specified on an calendar component. If this parameter is not specified on an
allowable property, the default relationship type is PARENT. allowable property, the default relationship type is PARENT.
Applications MUST treat x-name and iana-token value they don't
recognized the same way as the PARENT value.
Example: Example:
RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@ RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@
example.com example.com
3.2.15. Participation Role 3.2.15. Participation Role
Parameter Name: ROLE Parameter Name: ROLE
skipping to change at page 25, line 4 skipping to change at page 26, line 18
/ "REQ-PARTICIPANT" ; Indicates a participant whose / "REQ-PARTICIPANT" ; Indicates a participant whose
; participation is required ; participation is required
/ "OPT-PARTICIPANT" ; Indicates a participant whose / "OPT-PARTICIPANT" ; Indicates a participant whose
; participation is optional ; participation is optional
/ "NON-PARTICIPANT" ; Indicates a participant who / "NON-PARTICIPANT" ; Indicates a participant who
; is copied for information ; is copied for information
; purposes only ; purposes only
/ x-name ; Experimental role / x-name ; Experimental role
/ iana-token) ; Other IANA role / iana-token) ; Other IANA role
; Default is REQ-PARTICIPANT ; Default is REQ-PARTICIPANT
Description: This parameter can be specified on properties with a Description: This parameter can be specified on properties with a
CAL-ADDRESS value type. The parameter specifies the participation CAL-ADDRESS value type. The parameter specifies the participation
role for the calendar user specified by the property in the group role for the calendar user specified by the property in the group
schedule calendar component. If not specified on a property that schedule calendar component. If not specified on a property that
allows this parameter, the default value is REQ-PARTICIPANT. allows this parameter, the default value is REQ-PARTICIPANT.
Applications MUST treat x-name and iana-token value they don't
recognized the same way as the REQ-PARTICIPANT value.
Example: Example:
ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com
3.2.16. RSVP Expectation 3.2.16. RSVP Expectation
Parameter Name: RSVP Parameter Name: RSVP
Purpose: To specify whether there is an expectation of a favor of a Purpose: To specify whether there is an expectation of a favor of a
skipping to change at page 27, line 18 skipping to change at page 28, line 33
as the public-domain TZ database [TZDB]. The specification of as the public-domain TZ database [TZDB]. The specification of
globally unique time zone identifiers is not addressed by this globally unique time zone identifiers is not addressed by this
document and is left for future study. document and is left for future study.
The following are examples of this property parameter: The following are examples of this property parameter:
DTSTART;TZID=America/New_York:19980119T020000 DTSTART;TZID=America/New_York:19980119T020000
DTEND;TZID=America/New_York:19980119T030000 DTEND;TZID=America/New_York:19980119T030000
The "TZID" property parameter MUST NOT be applied to DATE-TIME or The "TZID" property parameter MUST NOT be applied to DATE
TIME properties whose time values are specified in UTC. properties, and DATE-TIME or TIME properties whose time values are
specified in UTC.
The use of local time in a DATE-TIME or TIME value without the The use of local time in a DATE-TIME or TIME value without the
"TZID" property parameter is to be interpreted as a local time "TZID" property parameter is to be interpreted as a local time
value, regardless of the existence of "VTIMEZONE" calendar value, regardless of the existence of "VTIMEZONE" calendar
components in the iCalendar object. components in the iCalendar object.
For more information see the sections on the value types DATE-TIME For more information see the sections on the value types DATE-TIME
and TIME. and TIME.
3.2.19. Value Data Types 3.2.19. Value Data Types
skipping to change at page 28, line 36 skipping to change at page 29, line 41
Description: This parameter specifies the value type and format of Description: This parameter specifies the value type and format of
the property value. The property values MUST be of a single value the property value. The property values MUST be of a single value
type. For example, a "RDATE" property cannot have a combination type. For example, a "RDATE" property cannot have a combination
of DATE-TIME and TIME value types. of DATE-TIME and TIME value types.
If the property's value is the default value type, then this If the property's value is the default value type, then this
parameter need not be specified. However, if the property's parameter need not be specified. However, if the property's
default value type is overridden by some other allowable value default value type is overridden by some other allowable value
type, then this parameter MUST be specified. type, then this parameter MUST be specified.
Applications MUST treat x-name and iana-token value they don't
recognized the same way as the TEXT value.
3.3. Property Value Data Types 3.3. Property Value Data Types
The properties in an iCalendar object are strongly typed. The The properties in an iCalendar object are strongly typed. The
definition of each property restricts the value to be one of the definition of each property restricts the value to be one of the
value data types, or simply value types, defined in this section. value data types, or simply value types, defined in this section.
The value type for a property will either be specified implicitly as The value type for a property will either be specified implicitly as
the default value type or will be explicitly specified with the the default value type or will be explicitly specified with the
"VALUE" parameter. If the value type of a property is one of the "VALUE" parameter. If the value type of a property is one of the
alternate valid types, then it MUST be explicitly specified with the alternate valid types, then it MUST be explicitly specified with the
"VALUE" parameter. "VALUE" parameter.
skipping to change at page 31, line 4 skipping to change at page 32, line 5
Format Definition: This value type is defined by the following Format Definition: This value type is defined by the following
notation: notation:
date = date-value date = date-value
date-value = date-fullyear date-month date-mday date-value = date-fullyear date-month date-mday
date-fullyear = 4DIGIT date-fullyear = 4DIGIT
date-month = 2DIGIT ;01-12 date-month = 2DIGIT ;01-12
date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
;based on month/year ;based on month/year
Description: If the property permits, multiple "date" values are Description: If the property permits, multiple "date" values are
specified as a COMMA character (US-ASCII decimal 44) separated specified as a COMMA character (US-ASCII decimal 44) separated
list of values. The format for the value type is expressed as the list of values. The format for the value type is based on the
[ISO.8601.1988] complete representation, basic format for a [ISO.8601.2004] complete representation, basic format for a
calendar date. The textual format specifies a four-digit year, calendar date. The textual format specifies a four-digit year,
two-digit month, and two-digit day of the month. There are no two-digit month, and two-digit day of the month. There are no
separator characters between the year, month and day component separator characters between the year, month and day component
text. text.
No additional content value encoding (i.e., BACKSLASH character No additional content value encoding (i.e., BACKSLASH character
encoding) is defined for this value type. encoding) is defined for this value type.
Example: The following represents July 14, 1997: Example: The following represents July 14, 1997:
skipping to change at page 31, line 40 skipping to change at page 32, line 42
date-time = date "T" time ;As specified in the date and time date-time = date "T" time ;As specified in the date and time
;value definitions ;value definitions
Description: If the property permits, multiple "date-time" values Description: If the property permits, multiple "date-time" values
are specified as a COMMA character (US-ASCII decimal 44) separated are specified as a COMMA character (US-ASCII decimal 44) separated
list of values. No additional content value encoding (i.e., list of values. No additional content value encoding (i.e.,
BACKSLASH character encoding) is defined for this value type. BACKSLASH character encoding) is defined for this value type.
The "DATE-TIME" value type is used to identify values that contain The "DATE-TIME" value type is used to identify values that contain
a precise calendar date and time of day. The format is based on a precise calendar date and time of day. The format is based on
the [ISO.8601.1988] complete representation, basic format for a the [ISO.8601.2004] complete representation, basic format for a
calendar date and time of day. The text format is a concatenation calendar date and time of day. The text format is a concatenation
of the "date", followed by the LATIN CAPITAL LETTER T character of the "date", followed by the LATIN CAPITAL LETTER T character
(US-ASCII decimal 84) time designator, followed by the "time" (US-ASCII decimal 84) time designator, followed by the "time"
format. format.
The "DATE-TIME" value type expresses time values in three forms: The "DATE-TIME" value type expresses time values in three forms:
The form of date and time with UTC offset MUST NOT be used. For The form of date and time with UTC offset MUST NOT be used. For
example, the following is not valid for a date-time value: example, the following is not valid for a date-time value:
skipping to change at page 33, line 15 skipping to change at page 34, line 17
FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE
The date and local time with reference to time zone information is The date and local time with reference to time zone information is
identified by the use the "TZID" property parameter to reference identified by the use the "TZID" property parameter to reference
the appropriate time zone definition. "TZID" is discussed in the appropriate time zone definition. "TZID" is discussed in
detail in Section 3.2.18. For example, the following represents detail in Section 3.2.18. For example, the following represents
2:00 A.M. in New York on Janurary 19, 1998: 2:00 A.M. in New York on Janurary 19, 1998:
TZID=America/New_York:19980119T020000 TZID=America/New_York:19980119T020000
If, based on the definition of the referenced time zone, the local
time described occurs more than once (when changing from daylight
to standard time), the DATE-TIME value refers to the first
occurence of the referenced time. Thus, TZID=America/
New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M.
EDT (UTC-04:00). If the local time described does not occur (when
changing from standard to daylight time), the DATE-TIME value is
interpreted using the UTC offset before the gap in local times.
Thus, TZID=America/New_York:20070311T023000 indicates March 11,
2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST
(UTC-05:00).
A time value MUST only specify the second 60 when specifying a
positive leap second. For example:
19970630T235960Z
Implementations which do not support leap seconds SHOULD interpret
the second 60 as equivalent to the second 59.
Example: The following represents July 14, 1997, at 1:30 PM in New Example: The following represents July 14, 1997, at 1:30 PM in New
York City in each of the three time formats, using the "DTSTART" York City in each of the three time formats, using the "DTSTART"
property. property.
DTSTART:19970714T133000 ; Local time DTSTART:19970714T133000 ; Local time
DTSTART:19970714T173000Z ; UTC time DTSTART:19970714T173000Z ; UTC time
DTSTART;TZID=America/New_York:19970714T133000 DTSTART;TZID=America/New_York:19970714T133000
; Local time and time ; Local time and time
; zone reference ; zone reference
A time value MUST only specify the second 60 when specifying a
positive "leap second" . For example:
19970630T235960Z
3.3.6. Duration 3.3.6. Duration
Value Name: DURATION Value Name: DURATION
Purpose: This value type is used to identify properties that contain Purpose: This value type is used to identify properties that contain
a duration of time. a duration of time.
Format Definition: This value type is defined by the following Format Definition: This value type is defined by the following
notation: notation:
dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
skipping to change at page 34, line 4 skipping to change at page 35, line 21
dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
dur-date = dur-day [dur-time] dur-date = dur-day [dur-time]
dur-time = "T" (dur-hour / dur-minute / dur-second) dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-week = 1*DIGIT "W" dur-week = 1*DIGIT "W"
dur-hour = 1*DIGIT "H" [dur-minute] dur-hour = 1*DIGIT "H" [dur-minute]
dur-minute = 1*DIGIT "M" [dur-second] dur-minute = 1*DIGIT "M" [dur-second]
dur-second = 1*DIGIT "S" dur-second = 1*DIGIT "S"
dur-day = 1*DIGIT "D" dur-day = 1*DIGIT "D"
Description: If the property permits, multiple "duration" values are Description: If the property permits, multiple "duration" values are
specified by a COMMA character (US-ASCII decimal 44) separated specified by a COMMA character (US-ASCII decimal 44) separated
list of values. The format is expressed as the [ISO.8601.1988] list of values. The format is based on the [ISO.8601.2004]
basic format for the duration of time. The format can represent complete representation basic format with designators for the
durations in terms of weeks, days, hours, minutes, and seconds. duration of time. The format can represent nominal durations
(weeks and days) and accurate durations (hours, minutes, and
seconds). Note that unlike [ISO.8601.2004] this value type
doesn't support the "Y" and "M" designators to specify durations
in terms of years and months.
The duration of a week or a day depends on its position in the
calendar. In the case of discontinuities in the time scale, such
as the change from standard time to daylight time and back, the
computation of the exact duration requires the substraction or
addition of the change of duration of the discontinuity. Leap
seconds MUST NOT be considered when computing an exact duration.
When computing an exact duration, the greatest order time
components MUST be added first, that is, the number of weeks MUST
be added first, followed by the number of days, number of hours,
number of minutes, and number of seconds.
Negative durations are typically used to schedule an alarm to Negative durations are typically used to schedule an alarm to
trigger before an associated time (see Section 3.8.6.3). trigger before an associated time (see Section 3.8.6.3).
No additional content value encoding (i.e., BACKSLASH character No additional content value encoding (i.e., BACKSLASH character
encoding) are defined for this value type. encoding) are defined for this value type.
Example: A duration of 15 days, 5 hours and 20 seconds would be: Example: A duration of 15 days, 5 hours and 20 seconds would be:
P15DT5H0M20S P15DT5H0M20S
skipping to change at page 35, line 46 skipping to change at page 37, line 33
Purpose: This value type is used to identify values that contain a Purpose: This value type is used to identify values that contain a
precise period of time. precise period of time.
Format Definition: This value type is defined by the following Format Definition: This value type is defined by the following
notation: notation:
period = period-explicit / period-start period = period-explicit / period-start
period-explicit = date-time "/" date-time period-explicit = date-time "/" date-time
; [ISO.8601.1988] complete representation basic format for a ; [ISO.8601.2004] complete representation basic format for a
; period of time consisting of a start and end. The start MUST ; period of time consisting of a start and end. The start MUST
; be before the end. ; be before the end.
period-start = date-time "/" dur-value period-start = date-time "/" dur-value
; [ISO.8601.1988] complete representation basic format for a ; [ISO.8601.2004] complete representation basic format for a
; period of time consisting of a start and positive duration ; period of time consisting of a start and positive duration
; of time. ; of time.
Description: If the property permits, multiple "period" values are Description: If the property permits, multiple "period" values are
specified by a COMMA character (US-ASCII decimal 44) separated specified by a COMMA character (US-ASCII decimal 44) separated
list of values. There are two forms of a period of time. First, list of values. There are two forms of a period of time. First,
a period of time is identified by its start and its end. This a period of time is identified by its start and its end. This
format is expressed as the [ISO.8601.1988] complete format is based on the [ISO.8601.2004] complete representation,
representation, basic format for "DATE-TIME" start of the period, basic format for "DATE-TIME" start of the period, followed by a
followed by a SOLIDUS character (US-ASCII decimal 47), followed by SOLIDUS character (US-ASCII decimal 47), followed by the "DATE-
the "DATE-TIME" of the end of the period. The start of the period TIME" of the end of the period. The start of the period MUST be
MUST be before the end of the period. Second, a period of time before the end of the period. Second, a period of time can also
can also be defined by a start and a positive duration of time. be defined by a start and a positive duration of time. The format
The format is expressed as the [ISO.8601.1988] complete is based on the [ISO.8601.2004] complete representation, basic
representation, basic format for the "DATE-TIME" start of the format for the "DATE-TIME" start of the period, followed by a
period, followed by a SOLIDUS character (US-ASCII decimal 47), SOLIDUS character (US-ASCII decimal 47), followed by the
followed by the [ISO.8601.1988] basic format for "DURATION" of the [ISO.8601.2004] basic format for "DURATION" of the period.
period.
Example: The period starting at 18:00:00 UTC, on January 1, 1997 and Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
ending at 07:00:00 UTC on January 2, 1997 would be: ending at 07:00:00 UTC on January 2, 1997 would be:
19970101T180000Z/19970102T070000Z 19970101T180000Z/19970102T070000Z
The period start at 18:00:00 on January 1, 1997 and lasting 5 The period start at 18:00:00 on January 1, 1997 and lasting 5
hours and 30 minutes would be: hours and 30 minutes would be:
19970101T180000Z/PT5H30M 19970101T180000Z/PT5H30M
skipping to change at page 39, line 21 skipping to change at page 41, line 10
meaning every second for a SECONDLY rule, or every minute for a meaning every second for a SECONDLY rule, or every minute for a
MINUTELY rule, every hour for an HOURLY rule, every day for a MINUTELY rule, every hour for an HOURLY rule, every day for a
DAILY rule, every week for a WEEKLY rule, every month for a DAILY rule, every week for a WEEKLY rule, every month for a
MONTHLY rule and every year for a YEARLY rule. MONTHLY rule and every year for a YEARLY rule.
The UNTIL rule part defines a DATE or DATE-TIME value which bounds The UNTIL rule part defines a DATE or DATE-TIME value which bounds
the recurrence rule in an inclusive manner. If the value the recurrence rule in an inclusive manner. If the value
specified by UNTIL is synchronized with the specified recurrence, specified by UNTIL is synchronized with the specified recurrence,
this DATE or DATE-TIME becomes the last instance of the this DATE or DATE-TIME becomes the last instance of the
recurrence. The value of the UNTIL rule part MUST have the same recurrence. The value of the UNTIL rule part MUST have the same
value type as the "DTSTART" property. If specified as a DATE-TIME value type as the "DTSTART" property. Furthermore, if the
value, then it MUST be specified in a UTC time format. If not "DTSTART" property is specified as a date with local time, then
present, and the COUNT rule part is also not present, the "RRULE" the UNTIL rule part MUST also be specified as a date with local
is considered to repeat forever. time. Else, if the "DTSTART" property is specified as a date with
UTC time or a date with local time and time zone reference, then
the UNTIL rule part MUST be specified as a date with UTC time. In
the case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL
rule part MUST always be specified as a date with UTC time. If
specified as a DATE-TIME value, then it MUST be specified in a UTC
time format. If not present, and the COUNT rule part is also not
present, the "RRULE" is considered to repeat forever.
The COUNT rule part defines the number of occurrences at which to The COUNT rule part defines the number of occurrences at which to
range-bound the recurrence. The "DTSTART" property value always range-bound the recurrence. The "DTSTART" property value always
counts as the first occurrence. counts as the first occurrence.
The BYSECOND rule part specifies a COMMA character (US-ASCII The BYSECOND rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of seconds within a minute. Valid decimal 44) separated list of seconds within a minute. Valid
values are 0 to 60. The BYMINUTE rule part specifies a COMMA values are 0 to 60. The BYMINUTE rule part specifies a COMMA
character (US-ASCII decimal 44) separated list of minutes within character (US-ASCII decimal 44) separated list of minutes within
an hour. Valid values are 0 to 59. The BYHOUR rule part an hour. Valid values are 0 to 59. The BYHOUR rule part
skipping to change at page 40, line 8 skipping to change at page 41, line 52
indicates Thursday; FR indicates Friday; SA indicates Saturday. indicates Thursday; FR indicates Friday; SA indicates Saturday.
Each BYDAY value can also be preceded by a positive (+n) or Each BYDAY value can also be preceded by a positive (+n) or
negative (-n) integer. If present, this indicates the nth negative (-n) integer. If present, this indicates the nth
occurrence of the specific day within the MONTHLY or YEARLY occurrence of the specific day within the MONTHLY or YEARLY
"RRULE". For example, within a MONTHLY rule, +1MO (or simply 1MO) "RRULE". For example, within a MONTHLY rule, +1MO (or simply 1MO)
represents the first Monday within the month, whereas -1MO represents the first Monday within the month, whereas -1MO
represents the last Monday of the month. If an integer modifier represents the last Monday of the month. If an integer modifier
is not present, it means all days of this type within the is not present, it means all days of this type within the
specified frequency. For example, within a MONTHLY rule, MO specified frequency. For example, within a MONTHLY rule, MO
represents all Mondays within the month. represents all Mondays within the month. The BYDAY rule part MUST
NOT be specified with a numeric value when the FREQ rule part is
not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part
MUST NOT be specified with a numeric value with the FREQ rule part
set to YEARLY when the BYWEEKNO rule part is specified. The
numeric value in a BYDAY rule part with the FREQ rule part set to
YEARLY corresponds to an offset within the month when the BYMONTH
rule part is present, and corresponds to an offset within the year
when the BYWEEKNO or BYMONTH rule parts are present.
The BYMONTHDAY rule part specifies a COMMA character (US-ASCII The BYMONTHDAY rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of days of the month. Valid values are decimal 44) separated list of days of the month. Valid values are
1 to 31 or -31 to -1. For example, -10 represents the tenth to 1 to 31 or -31 to -1. For example, -10 represents the tenth to
the last day of the month. the last day of the month. The BYMONTHDAY rule part MUST NOT be
specified when the FREQ rule part is set to WEEKLY.
The BYYEARDAY rule part specifies a COMMA character (US-ASCII The BYYEARDAY rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of days of the year. Valid values are decimal 44) separated list of days of the year. Valid values are
1 to 366 or -366 to -1. For example, -1 represents the last day 1 to 366 or -366 to -1. For example, -1 represents the last day
of the year (December 31st) and -306 represents the 306th to the of the year (December 31st) and -306 represents the 306th to the
last day of the year (March 1st). last day of the year (March 1st). The BYYEARDAY rule part MUST
NOT be specified when the FREQ rule part is set to DAILY, WEEKLY,
and MONTHLY.
The BYWEEKNO rule part specifies a COMMA character (US-ASCII The BYWEEKNO rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of ordinals specifying weeks of the decimal 44) separated list of ordinals specifying weeks of the
year. Valid values are 1 to 53 or -53 to -1. This corresponds to year. Valid values are 1 to 53 or -53 to -1. This corresponds to
weeks according to week numbering as defined in [ISO.8601.1988]. weeks according to week numbering as defined in [ISO.8601.2004].
A week is defined as a seven day period, starting on the day of A week is defined as a seven day period, starting on the day of
the week defined to be the week start (see WKST). Week number one the week defined to be the week start (see WKST). Week number one
of the calendar year is the first week which contains at least of the calendar year is the first week which contains at least
four (4) days in that calendar year. This rule part is only valid four (4) days in that calendar year. This rule part MUST NOT be
for YEARLY rules. For example, 3 represents the third week of the used when the FREQ rule part is not set to YEARLY. For example, 3
year. represents the third week of the year.
Note: Assuming a Monday week start, week 53 can only occur when Note: Assuming a Monday week start, week 53 can only occur when
Thursday is January 1 or if it is a leap year and Wednesday is Thursday is January 1 or if it is a leap year and Wednesday is
January 1. January 1.
The BYMONTH rule part specifies a COMMA character (US-ASCII The BYMONTH rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of months of the year. Valid values decimal 44) separated list of months of the year. Valid values
are 1 to 12. are 1 to 12.
The WKST rule part specifies the day on which the workweek starts. The WKST rule part specifies the day on which the workweek starts.
Valid values are MO, TU, WE, TH, FR, SA and SU. This is Valid values are MO, TU, WE, TH, FR, SA and SU. This is
significant when a WEEKLY "RRULE" has an interval greater than 1, significant when a WEEKLY "RRULE" has an interval greater than 1,
and a BYDAY rule part is specified. This is also significant when and a BYDAY rule part is specified. This is also significant when
in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The
default value is MO. default value is MO.
The BYSETPOS rule part specifies a COMMA character (US-ASCII The BYSETPOS rule part specifies a COMMA character (US-ASCII
decimal 44) separated list of values which corresponds to the nth decimal 44) separated list of values which corresponds to the nth
occurrence within the set of events specified by the rule. Valid occurrence within the set of recurrence instances specified by the
values are 1 to 366 or -366 to -1. It MUST only be used in rule. BYSETPOS operates on a set of recurrence instances in one
conjunction with another BYxxx rule part. For example "the last interval of the recurrence rule. For a WEEKLY rule, the interval
work day of the month" could be represented as: is one week, for a MONTHLY rule, one month, and for a YEARLY rule,
one year. Valid values are 1 to 366 or -366 to -1. It MUST only
be used in conjunction with another BYxxx rule part. For example
"the last work day of the month" could be represented as:
FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
Each BYSETPOS value can include a positive (+n) or negative (-n) Each BYSETPOS value can include a positive (+n) or negative (-n)
integer. If present, this indicates the nth occurrence of the integer. If present, this indicates the nth occurrence of the
specific occurrence within the set of occurences specified by the specific occurrence within the set of occurences specified by the
rule. rule.
Recurrence rules may generate recurrence instances with invalid Recurrence rules may generate recurrence instances with invalid
date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM
skipping to change at page 41, line 45 skipping to change at page 44, line 5
days within the yearly recurrence set from 1 (if BYMONTH rule part days within the yearly recurrence set from 1 (if BYMONTH rule part
is not present) to 2. is not present) to 2.
If multiple BYxxx rule parts are specified, then after evaluating If multiple BYxxx rule parts are specified, then after evaluating
the specified FREQ and INTERVAL rule parts, the BYxxx rule parts the specified FREQ and INTERVAL rule parts, the BYxxx rule parts
are applied to the current set of evaluated occurrences in the are applied to the current set of evaluated occurrences in the
following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY,
BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are
evaluated. evaluated.
The table below summarizes the dependency of BYxxx rule part
expand or limit behaviour on the FREQ rule part value.
The term "N/A" means that the corresponding BYxxx rule part MUST
NOT be used with the corresponding FREQ value.
BYDAY has some special behaviour depending on the FREQ value and
this is described in separate notes below the table.
+----------+--------+--------+-------+-------+------+-------+------+
| |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY|
+----------+--------+--------+-------+-------+------+-------+------+
|BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2|
+----------+--------+--------+-------+-------+------+-------+------+
|BYHOUR |Limit |Limit |Limit |Expand |Expand|Expand |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYMINUTE |Limit |Limit |Expand |Expand |Expand|Expand |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYSECOND |Limit |Expand |Expand |Expand |Expand|Expand |Expand|
+----------+--------+--------+-------+-------+------+-------+------+
|BYSETPOS |Limit |Limit |Limit |Limit |Limit |Limit |Limit |
+----------+--------+--------+-------+-------+------+-------+------+
Note 1: Limit if BYMONTHDAY is present, otherwise special expand
for MONTHLY.
Note 2: Limit if BYYEARDAY or BYMONTHDAY is present, otherwise
special expand for WEEKLY if BYWEEKNO present, otherwise
special expand for MONTHLY if BYMONTH present, otherwise
special expand for YEARLY.
Here is an example of evaluating multiple BYxxx rule parts. Here is an example of evaluating multiple BYxxx rule parts.
DTSTART;TZID=America/New_York:19970105T083000 DTSTART;TZID=America/New_York:19970105T083000
RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
BYMINUTE=30 BYMINUTE=30
First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to
arrive at "every other year". Then, "BYMONTH=1" would be applied arrive at "every other year". Then, "BYMONTH=1" would be applied
to arrive at "every January, every other year". Then, "BYDAY=SU" to arrive at "every January, every other year". Then, "BYDAY=SU"
would be applied to arrive at "every Sunday in January, every would be applied to arrive at "every Sunday in January, every
other year". Then, "BYHOUR=8,9" would be applied to arrive at other year". Then, "BYHOUR=8,9" would be applied to arrive at
"every Sunday in January at 8 AM and 9 AM, every other year". "every Sunday in January at 8 AM and 9 AM, every other year".
Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in
January at 8:30 AM and 9:30 AM, every other year". Then, lacking January at 8:30 AM and 9:30 AM, every other year". Then, lacking
information from "RRULE", the second is derived from "DTSTART", to information from "RRULE", the second is derived from "DTSTART", to
end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM,
skipping to change at page 42, line 18 skipping to change at page 45, line 19
"every Sunday in January at 8 AM and 9 AM, every other year". "every Sunday in January at 8 AM and 9 AM, every other year".
Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in
January at 8:30 AM and 9:30 AM, every other year". Then, lacking January at 8:30 AM and 9:30 AM, every other year". Then, lacking
information from "RRULE", the second is derived from "DTSTART", to information from "RRULE", the second is derived from "DTSTART", to
end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM,
every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY,
BYMONTHDAY or BYMONTH rule part were missing, the appropriate BYMONTHDAY or BYMONTH rule part were missing, the appropriate
minute, hour, day or month would have been retrieved from the minute, hour, day or month would have been retrieved from the
"DTSTART" property. "DTSTART" property.
If the computed local start time of a recurrence instance does not
exist, or occurs more than once, for the specified time zone, the
time of the recurrence instance is interpreted in the same manner
as an explicit DATE-TIME value describing that date and time, as
specified in Section 3.3.5.
No additional content value encoding (i.e., BACKSLASH character No additional content value encoding (i.e., BACKSLASH character
encoding) is defined for this value type. encoding) is defined for this value type.
Example: The following is a rule which specifies 10 occurences which Example: The following is a rule which specifies 10 occurences which
occur every other day: occur every other day:
FREQ=DAILY;COUNT=10;INTERVAL=2 FREQ=DAILY;COUNT=10;INTERVAL=2
There are other examples specified in Section 3.8.5.3. There are other examples specified in Section 3.8.5.3.
skipping to change at page 44, line 20 skipping to change at page 47, line 30
;The "60" value is used to account for positive "leap" seconds. ;The "60" value is used to account for positive "leap" seconds.
time-utc = "Z" time-utc = "Z"
Description: If the property permits, multiple "time" values are Description: If the property permits, multiple "time" values are
specified by a COMMA character (US-ASCII decimal 44) separated specified by a COMMA character (US-ASCII decimal 44) separated
list of values. No additional content value encoding (i.e., list of values. No additional content value encoding (i.e.,
BACKSLASH character encoding) is defined for this value type. BACKSLASH character encoding) is defined for this value type.
The "TIME" value type is used to identify values that contain a The "TIME" value type is used to identify values that contain a
time of day. The format is based on the [ISO.8601.1988] complete time of day. The format is based on the [ISO.8601.2004] complete
representation, basic format for a time of day. The text format representation, basic format for a time of day. The text format
consists of a two-digit 24-hour of the day (i.e., values 00-23), consists of a two-digit 24-hour of the day (i.e., values 00-23),
two-digit minute in the hour (i.e., values 00-59), and two-digit two-digit minute in the hour (i.e., values 00-59), and two-digit
seconds in the minute (i.e., values 00-60). The seconds value of seconds in the minute (i.e., values 00-60). The seconds value of
60 MUST only be used to account for positive "leap" seconds. 60 MUST only be used to account for positive "leap" seconds.
Fractions of a second are not supported by this format. Fractions of a second are not supported by this format.
In parallel to the "DATE-TIME" definition above, the "TIME" value In parallel to the "DATE-TIME" definition above, the "TIME" value
type expresses time values in three forms: type expresses time values in three forms:
skipping to change at page 47, line 41 skipping to change at page 50, line 47
The following is a simple example of an iCalendar object: The following is a simple example of an iCalendar object:
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT BEGIN:VEVENT
UID:19970610T172345Z-AF23B2@example.com UID:19970610T172345Z-AF23B2@example.com
DTSTAMP:19970610T172345Z DTSTAMP:19970610T172345Z
DTSTART:19970714T170000Z DTSTART:19970714T170000Z
DTEND:19970715T035959Z DTEND:19970715T040000Z
SUMMARY:Bastille Day Party SUMMARY:Bastille Day Party
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
3.5. Property 3.5. Property
A property is the definition of an individual attribute describing a A property is the definition of an individual attribute describing a
calendar object or a calendar component. A property takes the form calendar object or a calendar component. A property takes the form
defined by the "contentline" notation defined in Section 3.1. defined by the "contentline" notation defined in Section 3.1.
skipping to change at page 49, line 45 skipping to change at page 52, line 45
An iCalendar object MUST include the "PRODID" and "VERSION" calendar An iCalendar object MUST include the "PRODID" and "VERSION" calendar
properties. In addition, it MUST include at least one calendar properties. In addition, it MUST include at least one calendar
component. Special forms of iCalendar objects are possible to component. Special forms of iCalendar objects are possible to
publish just busy time (i.e., only a "VFREEBUSY" calendar component) publish just busy time (i.e., only a "VFREEBUSY" calendar component)
or time zone (i.e., only a "VTIMEZONE" calendar component) or time zone (i.e., only a "VTIMEZONE" calendar component)
information. In addition, a complex iCalendar object that is used to information. In addition, a complex iCalendar object that is used to
capture a complete snapshot of the contents of a calendar is possible capture a complete snapshot of the contents of a calendar is possible
(e.g., composite of many different calendar components). More (e.g., composite of many different calendar components). More
commonly, an iCalendar object will consist of just a single "VEVENT", commonly, an iCalendar object will consist of just a single "VEVENT",
"VTODO" or "VJOURNAL" calendar component. "VTODO" or "VJOURNAL" calendar component. Applications MUST ignore
x-comp and iana-comp they don't recognized.
3.6.1. Event Component 3.6.1. Event Component
Component Name: VEVENT Component Name: VEVENT
Purpose: Provide a grouping of component properties that describe an Purpose: Provide a grouping of component properties that describe an
event. event.
Format Definition: A "VEVENT" calendar component is defined by the Format Definition: A "VEVENT" calendar component is defined by the
following notation: following notation:
skipping to change at page 52, line 44 skipping to change at page 55, line 44
UID:19970901T130000Z-123403@example.com UID:19970901T130000Z-123403@example.com
DTSTAMP:19970901T130000Z DTSTAMP:19970901T130000Z
DTSTART;VALUE=DATE:19971102 DTSTART;VALUE=DATE:19971102
SUMMARY:Our Blissful Anniversary SUMMARY:Our Blissful Anniversary
TRANSP:TRANSPARENT TRANSP:TRANSPARENT
CLASS:CONFIDENTIAL CLASS:CONFIDENTIAL
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
RRULE:FREQ=YEARLY RRULE:FREQ=YEARLY
END:VEVENT END:VEVENT
The following is an example of the "VEVENT" calendar component
used to represent a multi-day event scheduled from June 28th, 2007
to July 8th, 2007 inclusively. Note that the "DTEND" property is
set to July 9th, 2007, since the "DTEND" property specifies the
non-inclusive end of the event.
BEGIN:VEVENT
UID:20070423T123432Z-541111@example.com
DTSTAMP:20070423T123432Z
DTSTART;VALUE=DATE:20070628
DTEND;VALUE=DATE:20070709
SUMMARY:Festival International de Jazz de Montreal
TRANSP:TRANSPARENT
END:VEVENT
3.6.2. To-do Component 3.6.2. To-do Component
Component Name: VTODO Component Name: VTODO
Purpose: Provide a grouping of calendar properties that describe a Purpose: Provide a grouping of calendar properties that describe a
to-do. to-do.
Format Definition: A "VTODO" calendar component is defined by the Format Definition: A "VTODO" calendar component is defined by the
following notation: following notation:
skipping to change at page 54, line 19 skipping to change at page 58, line 14
The "VTODO" calendar component cannot be nested within another The "VTODO" calendar component cannot be nested within another
calendar component. However, "VTODO" calendar components can be calendar component. However, "VTODO" calendar components can be
related to each other or to a "VEVENT" or to a "VJOURNAL" calendar related to each other or to a "VEVENT" or to a "VJOURNAL" calendar
component with the "RELATED-TO" property. component with the "RELATED-TO" property.
A "VTODO" calendar component without the "DTSTART" and "DUE" (or A "VTODO" calendar component without the "DTSTART" and "DUE" (or
"DURATION") properties specifies a to-do that will be associated "DURATION") properties specifies a to-do that will be associated
with each successive calendar date, until it is completed. with each successive calendar date, until it is completed.
Example: The following is an example of a "VTODO" calendar Examples: The following is an example of a "VTODO" calendar
component: component that needs to be completed before May 1st, 2007. On
midnight May 1st, 2007 this to-do would be considered overdue.
BEGIN:VTODO BEGIN:VTODO
UID:19970901T130000Z-123404@example.com UID:20070313T123432Z-456553@example.com
DTSTAMP:19970901T130000Z DTSTAMP:20070313T123432Z
DTSTART:19970415T133000Z DUE;VALUE=DATE:20070501
DUE:19970416T045959Z SUMMARY:Submit Quebec Income Tax Return for 2006
SUMMARY:1996 Income Tax Preparation
CLASS:CONFIDENTIAL CLASS:CONFIDENTIAL
CATEGORIES:FAMILY,FINANCE CATEGORIES:FAMILY,FINANCE
STATUS:NEEDS-ACTION
END:VTODO
The following is an example of a "VTODO" calendar component that
was due before 1:00 P.M. UTC on July 9th, 2007 and was completed
on July 7th, 2007 at 10:00 A.M. UTC.
BEGIN:VTODO
UID:20070514T103211Z-123404@example.com
DTSTAMP:20070514T103211Z
DTSTART:20070514T110000Z
DUE:20070709T130000Z
COMPLETED:20070707T100000Z
SUMMARY:Submit Revised Internet-Draft
PRIORITY:1 PRIORITY:1
STATUS:NEEDS-ACTION STATUS:NEEDS-ACTION
END:VTODO END:VTODO
3.6.3. Journal Component 3.6.3. Journal Component
Component Name: VJOURNAL Component Name: VJOURNAL
Purpose: Provide a grouping of component properties that describe a Purpose: Provide a grouping of component properties that describe a
journal entry. journal entry.
skipping to change at page 61, line 24 skipping to change at page 65, line 24
Time in certain countries. The following table shows the changes Time in certain countries. The following table shows the changes
in time zone rules in effect for New York City starting from 1967. in time zone rules in effect for New York City starting from 1967.
Each line represents a description or rule for a particular Each line represents a description or rule for a particular
observance. observance.
Effective Observance Rule Effective Observance Rule
+-----------+--------------------------+--------+--------------+ +-----------+--------------------------+--------+--------------+
| Date | (Date/Time) | Offset | Abbreviation | | Date | (Date/Time) | Offset | Abbreviation |
+-----------+--------------------------+--------+--------------+ +-----------+--------------------------+--------+--------------+
| 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST |
| 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT | | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT |
| 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST |
| 1974-1974 | Jan 6, 02:00 | -0400 | EDT | | 1974-1974 | Jan 6, 02:00 | -0400 | EDT |
| 1975-1975 | Feb 23, 02:00 | -0400 | EDT | | 1975-1975 | Feb 23, 02:00 | -0400 | EDT |
| 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT | | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT |
| 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT | | 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT |
| 2007-* | first Sun in Nov, 02:00 | -0500 | EST |
| 2007-* | second Sun in Mar, 02:00 | -0400 | EDT | | 2007-* | second Sun in Mar, 02:00 | -0400 | EDT |
| 2007-* | first Sun in Nov, 02:00 | -0500 | EST |
+-----------+--------------------------+--------+--------------+ +-----------+--------------------------+--------+--------------+
Note: The specification of a global time zone registry is not Note: The specification of a global time zone registry is not
addressed by this document and is left for future study. addressed by this document and is left for future study.
However, implementers may find the TZ database [TZDB] a useful However, implementers may find the TZ database [TZDB] a useful
reference. It is an informal, public-domain collection of time reference. It is an informal, public-domain collection of time
zone information, which is currently being maintained by zone information, which is currently being maintained by
volunteer Internet participants, and is used in several volunteer Internet participants, and is used in several
operating systems. This database contains current and operating systems. This database contains current and
historical time zone information for a wide variety of historical time zone information for a wide variety of
skipping to change at page 64, line 10 skipping to change at page 68, line 10
The mandatory "TZOFFSETTO" property gives the UTC offset for the The mandatory "TZOFFSETTO" property gives the UTC offset for the
time zone sub-component (Standard Time or Daylight Saving Time) time zone sub-component (Standard Time or Daylight Saving Time)
when this observance is in use. when this observance is in use.
The optional "TZNAME" property is the customary name for the time The optional "TZNAME" property is the customary name for the time
zone. It may be specified multiple times, to allow for specifying zone. It may be specified multiple times, to allow for specifying
multiple language variants of the time zone names. This could be multiple language variants of the time zone names. This could be
used for displaying dates. used for displaying dates.
If specified, the onset for the observance defined by the time The onset date-times for the observance defined by the time zone
zone sub-component is defined by either the "RRULE" or "RDATE" sub-component is defined by the "DTSTART", "RRULE", and "RDATE"
property. If neither is specified, only one sub-component can be properties.
specified in the "VTIMEZONE" calendar component and it is assumed
that the single observance specified is always in effect.
The "RRULE" property defines the recurrence rule for the onset of The "RRULE" property defines the recurrence rule for the onset of
the observance defined by this time zone sub-component. Some the observance defined by this time zone sub-component. Some
specific requirements for the usage of "RRULE" for this purpose specific requirements for the usage of "RRULE" for this purpose
include: include:
* If observance is known to have an effective end date, the * If observance is known to have an effective end date, the
"UNTIL" recurrence rule parameter MUST be used to specify the "UNTIL" recurrence rule parameter MUST be used to specify the
last valid onset of this observance (i.e., the UNTIL date-time last valid onset of this observance (i.e., the UNTIL date-time
will be equal to the last instance generated by the recurrence will be equal to the last instance generated by the recurrence
pattern). It MUST be specified in UTC time. pattern). It MUST be specified in UTC time.
* The "DTSTART" and the "TZOFFSETFROM" properties MUST be used * The "DTSTART" and the "TZOFFSETFROM" properties MUST be used
when generating the onset date-time values (instances) from the when generating the onset date-time values (instances) from the
"RRULE". "RRULE".
Alternatively, the "RDATE" property can be used to define the Alternatively, the "RDATE" property can be used to define the
onset of the observance by giving the individual onset date and onset of the observance by giving the individual onset date and
times. "RDATE" in this usage MUST be specified as a local DATE- times. "RDATE" in this usage MUST be specified as a local DATE-
TIME value . TIME value, relative to the UTC offset specified in the
"TZOFFSETFROM" property.
The optional "COMMENT" property is also allowed for descriptive The optional "COMMENT" property is also allowed for descriptive
explanatory text. explanatory text.
Example: The following are examples of the "VTIMEZONE" calendar Example: The following are examples of the "VTIMEZONE" calendar
component: component:
This is an example showing all the time zone rules for New York This is an example showing all the time zone rules for New York
City since April 30, 1967 at 03:00:00 EDT. City since April 30, 1967 at 03:00:00 EDT.
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America/New_York TZID:America/New_York
LAST-MODIFIED:20050809T050000Z LAST-MODIFIED:20050809T050000Z
BEGIN:DAYLIGHT
DTSTART:19670430T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
BEGIN:STANDARD BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19671029T020000 DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:-0400 TZOFFSETFROM:-0400
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:EST TZNAME:EST
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19740106T020000
RDATE:19750223T020000
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
DTSTART:19670430T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19740106T020000
RDATE:19750223T020000
END:DAYLIGHT END:DAYLIGHT
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19760425T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
DTSTART:19760425T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z
END:DAYLIGHT END:DAYLIGHT
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z
END:DAYLIGHT END:DAYLIGHT
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
END:VTIMEZONE END:VTIMEZONE
This is an example showing time zone information for New York City This is an example showing time zone information for New York City
using "RDATE" property. Note that this is only suitable for a using "RDATE" property. Note that this is only suitable for a
recurring event that starts on or later than March 11, 2007 at 03: recurring event that starts on or later than March 11, 2007 at 03:
00:00 EDT (i.e., the earliest effective transition date and time) 00:00 EDT (i.e., the earliest effective transition date and time)
and ends no later than April 7, 1998 02:00:00 EST (i.e., latest and ends no later than March 9, 2008 at 01:59:59 EST (i.e., latest
valid date and time for EST in this scenario). For example, this valid date and time for EST in this scenario). For example, this
can be used for a recurring event that occurs every Friday, 8:00 can be used for a recurring event that occurs every Friday, 8:00
A.M.-9:00 A.M., starting June 1, 1997, ending December 31, 1997. A.M.-9:00 A.M., starting June 1, 2007, ending December 31, 2007,
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America/New_York TZID:America/New_York
LAST-MODIFIED:19870101T000000Z LAST-MODIFIED:20050809T050000Z
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19971026T020000 DTSTART:20071104T020000
RDATE:19971026T020000
TZOFFSETFROM:-0400 TZOFFSETFROM:-0400
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:EST TZNAME:EST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19970406T020000 DTSTART:20070311T020000
RDATE:19970406T020000
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
END:DAYLIGHT END:DAYLIGHT
END:VTIMEZONE END:VTIMEZONE
This is a simple example showing the current time zone rules for This is a simple example showing the current time zone rules for
the Eastern United States using a "RRULE" recurrence pattern. New York City using a "RRULE" recurrence pattern. Note that there
Note that there is no effective end date to either of the Standard is no effective end date to either of the Standard Time or
Time or Daylight Time rules. This information would be valid for Daylight Time rules. This information would be valid for a
a recurring event starting today and continuing indefinitely. recurring event starting today and continuing indefinitely.
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America/New_York TZID:America/New_York
LAST-MODIFIED:19870101T000000Z LAST-MODIFIED:20050809T050000Z
TZURL:http://zones.example.com/tz/America-New_York.ics TZURL:http://zones.example.com/tz/America-New_York.ics
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19671029T020000 DTSTART:20071104T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
TZOFFSETFROM:-0400 TZOFFSETFROM:-0400
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:EST TZNAME:EST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000 DTSTART:20070311T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
END:DAYLIGHT END:DAYLIGHT
END:VTIMEZONE END:VTIMEZONE
This is an example showing a fictitious set of rules for the This is an example showing a set of rules for a fictitious time
Eastern United States, where the Daylight Time rule has an zone where the Daylight Time rule has an effective end date (i.e.,
effective end date (i.e., after that date, Daylight Time is no after that date, Daylight Time is no longer observed).
longer observed).
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:Fictitious--America/New_York TZID:Fictitious
LAST-MODIFIED:19870101T000000Z LAST-MODIFIED:19870101T000000Z
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19671029T020000 DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0400 TZOFFSETFROM:-0400
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:EST TZNAME:EST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000 DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
END:DAYLIGHT END:DAYLIGHT
END:VTIMEZONE END:VTIMEZONE
This is an example showing a fictitious set of rules for the This is an example showing a set of rules for a fictitious time
Eastern United States, where the first Daylight Time rule has an zone where the first Daylight Time rule has an effective end date.
effective end date. There is a second Daylight Time rule that There is a second Daylight Time rule that picks up where the other
picks up where the other left off. left off.
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:Fictitious--America/New_York TZID:Fictitious
LAST-MODIFIED:19870101T000000Z LAST-MODIFIED:19870101T000000Z
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19671029T020000 DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0400 TZOFFSETFROM:-0400
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:EST TZNAME:EST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19870405T020000 DTSTART:19870405T020000
skipping to change at page 68, line 46 skipping to change at page 72, line 46
Component Name: VALARM Component Name: VALARM
Purpose: Provide a grouping of component properties that define an Purpose: Provide a grouping of component properties that define an
alarm. alarm.
Format Definition: A "VALARM" calendar component is defined by the Format Definition: A "VALARM" calendar component is defined by the
following notation: following notation:
alarmc = "BEGIN" ":" "VALARM" CRLF alarmc = "BEGIN" ":" "VALARM" CRLF
(audioprop / dispprop / emailprop / procprop) (audioprop / dispprop / emailprop)
"END" ":" "VALARM" CRLF "END" ":" "VALARM" CRLF
audioprop = *( audioprop = *(
; 'action' and 'trigger' are both REQUIRED, ; 'action' and 'trigger' are both REQUIRED,
; but MUST NOT occur more than once ; but MUST NOT occur more than once
action / trigger / action / trigger /
; 'duration' and 'repeat' are both OPTIONAL, ; 'duration' and 'repeat' are both OPTIONAL,
skipping to change at page 70, line 22 skipping to change at page 74, line 22
duration / repeat / duration / repeat /
; the following are OPTIONAL, ; the following are OPTIONAL,
; and MAY occur more than once ; and MAY occur more than once
attach / x-prop / iana-prop attach / x-prop / iana-prop
) )
procprop = *(
; the following are all REQUIRED,
; but MUST NOT occur more than once
action / attach / trigger /
; 'duration' and 'repeat' are both OPTIONAL,
; and MUST NOT occur more than once each,
; but if one occurs, so MUST the other
duration / repeat /
; 'description' is OPTIONAL,
; and MUST NOT occur more than once
description /
; the following is OPTIONAL,
; and MAY occur more than once
x-prop / iana-prop
)
Description: A "VALARM" calendar component is a grouping of Description: A "VALARM" calendar component is a grouping of
component properties that is a reminder or alarm for an event or a component properties that is a reminder or alarm for an event or a
to-do. For example, it may be used to define a reminder for a to-do. For example, it may be used to define a reminder for a
pending event or an overdue to-do. pending event or an overdue to-do.
The "VALARM" calendar component MUST include the "ACTION" and The "VALARM" calendar component MUST include the "ACTION" and
"TRIGGER" properties. The "ACTION" property further constrains "TRIGGER" properties. The "ACTION" property further constrains
the "VALARM" calendar component in the following ways: the "VALARM" calendar component in the following ways:
When the action is "AUDIO", the alarm can also include one and When the action is "AUDIO", the alarm can also include one and
skipping to change at page 78, line 15 skipping to change at page 81, line 30
document object with a calendar component. document object with a calendar component.
Value Type: The default value type for this property is URI. The Value Type: The default value type for this property is URI. The
value type can also be set to BINARY to indicate inline binary value type can also be set to BINARY to indicate inline binary
encoded content information. encoded content information.
Property Parameters: IANA, non-standard, inline encoding, format Property Parameters: IANA, non-standard, inline encoding, format
type and value data type property parameters can be specified on type and value data type property parameters can be specified on
this property. this property.
Conformance: The property can be specified in a "VEVENT", "VTODO", Conformance: This property can be specified multiple times in a
"VJOURNAL" or "VALARM" calendar components. "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar component with
the exception of AUDIO alarm which only allow this property to
occur once.
Description: This property can be specified within "VEVENT", Description: This property is used in "VEVENT", "VTODO", and
"VTODO", "VJOURNAL", or "VALARM" calendar components. This "VJOURNAL" calendar components to associate a resource (e.g.,
property can be specified multiple times within an iCalendar document) with the calendar component. This property is used in
object. "VALARM" calendar components to specify an audio sound resource or
an email message attachment. This property can be specified as a
URI pointing to a resource or as inline binary encoded content.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
attach = "ATTACH" attachparam ":" uri CRLF attach = "ATTACH" attachparam ":" uri CRLF
/ "ATTACH" attachparam ";" "ENCODING" "=" "BASE64" / "ATTACH" attachparam ";" "ENCODING" "=" "BASE64"
";" "VALUE" "=" "BINARY" ":" binary ";" "VALUE" "=" "BINARY" ":" binary
attachparam = *( attachparam = *(
skipping to change at page 80, line 34 skipping to change at page 84, line 11
calendar entry. The access classification of an individual calendar entry. The access classification of an individual
iCalendar component is useful when measured along with the other iCalendar component is useful when measured along with the other
security components of a calendar system (e.g., calendar user security components of a calendar system (e.g., calendar user
authentication, authorization, access rights, access role, etc.). authentication, authorization, access rights, access role, etc.).
Hence, the semantics of the individual access classifications Hence, the semantics of the individual access classifications
cannot be completely defined by this memo alone. Additionally, cannot be completely defined by this memo alone. Additionally,
due to the "blind" nature of most exchange processes using this due to the "blind" nature of most exchange processes using this
memo, these access classifications cannot serve as an enforcement memo, these access classifications cannot serve as an enforcement
statement for a system receiving an iCalendar object. Rather, statement for a system receiving an iCalendar object. Rather,
they provide a method for capturing the intention of the calendar they provide a method for capturing the intention of the calendar
owner for the access to the calendar component. owner for the access to the calendar component. If not specified
in a component that allows this property, the default value is
PUBLIC. Applications MUST treat x-name and iana-token value they
don't recognized the same way as the PRIVATE value.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
class = "CLASS" classparam ":" classvalue CRLF class = "CLASS" classparam ":" classvalue CRLF
classparam = *(";" other-param) classparam = *(";" other-param)
classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
/ x-name / x-name
skipping to change at page 81, line 18 skipping to change at page 84, line 44
Purpose: This property specifies non-processing information intended Purpose: This property specifies non-processing information intended
to provide a comment to the calendar user. to provide a comment to the calendar user.
Value Type: TEXT Value Type: TEXT
Property Parameters: IANA, non-standard, alternate text Property Parameters: IANA, non-standard, alternate text
representation and language property parameters can be specified representation and language property parameters can be specified
on this property. on this property.
Conformance: This property can be specified one or more times in Conformance: This property can be specified multiple times in
"VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components "VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components
as well as in the "STANDARD" and "DAYLIGHT" sub-components. as well as in the "STANDARD" and "DAYLIGHT" sub-components.
Description: The property can be specified multiple times. Description: This property is used to specify a comment to the
calendar user.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
comment = "COMMENT" commparam ":" text CRLF comment = "COMMENT" commparam ":" text CRLF
commparam = *( commparam = *(
; the following are OPTIONAL, ; the following are OPTIONAL,
; but MUST NOT occur more than once ; but MUST NOT occur more than once
skipping to change at page 92, line 23 skipping to change at page 96, line 15
Purpose: This property defines the date and time that a to-do was Purpose: This property defines the date and time that a to-do was
actually completed. actually completed.
Value Type: DATE-TIME Value Type: DATE-TIME
Property Parameters: IANA and non-standard property parameters can Property Parameters: IANA and non-standard property parameters can
be specified on this property. be specified on this property.
Conformance: The property can be specified in a "VTODO" calendar Conformance: The property can be specified in a "VTODO" calendar
component. component. The value MUST be specified as a date with UTC time.
Description: The date and time MUST be in a UTC format. Description: This property defines the date and time that a to-do
was actually completed.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
completed = "COMPLETED" compparam ":" date-time CRLF completed = "COMPLETED" compparam ":" date-time CRLF
compparam = *(";" other-param) compparam = *(";" other-param)
Example: The following is an example of this property: Example: The following is an example of this property:
skipping to change at page 93, line 9 skipping to change at page 96, line 49
be set to a DATE value type. be set to a DATE value type.
Property Parameters: IANA, non-standard, value data type, and time Property Parameters: IANA, non-standard, value data type, and time
zone identifier property parameters can be specified on this zone identifier property parameters can be specified on this
property. property.
Conformance: This property can be specified in "VEVENT" or Conformance: This property can be specified in "VEVENT" or
"VFREEBUSY" calendar components. "VFREEBUSY" calendar components.
Description: Within the "VEVENT" calendar component, this property Description: Within the "VEVENT" calendar component, this property
defines the date and time by which the event ends. The value MUST defines the date and time by which the event ends. The value type
be later in time than the value of the "DTSTART" property. of this property MUST be the same as the "DTSTART" property, and
its value MUST be later in time than the value of the "DTSTART"
property. Furthermore, this property MUST be specified as a date
with local time if and only if the "DTSTART" property is also
specified as a date with local time.
Within the "VFREEBUSY" calendar component, this property defines Within the "VFREEBUSY" calendar component, this property defines
the end date and time for the free or busy time information. The the end date and time for the free or busy time information. The
time MUST be specified in the UTC time format. The value MUST be time MUST be specified in the UTC time format. The value MUST be
later in time than the value of the "DTSTART" property. later in time than the value of the "DTSTART" property.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
dtend = "DTEND" dtendparam ":" dtendval CRLF dtend = "DTEND" dtendparam ":" dtendval CRLF
skipping to change at page 94, line 19 skipping to change at page 98, line 15
Value Type: The default value type is DATE-TIME. The value type can Value Type: The default value type is DATE-TIME. The value type can
be set to a DATE value type. be set to a DATE value type.
Property Parameters: IANA, non-standard, value data type, and time Property Parameters: IANA, non-standard, value data type, and time
zone identifier property parameters can be specified on this zone identifier property parameters can be specified on this
property. property.
Conformance: The property can be specified once in a "VTODO" Conformance: The property can be specified once in a "VTODO"
calendar component. calendar component.
Description: The value MUST be a date/time equal to or after the Description: This property defines the date and time that a to-do is
"DTSTART" value, if specified. expected to be completed. For cases where this property is
specified in a "VTODO" calendar component that also specifies a
"DTSTART" property, the value type of this property MUST be the
same as the "DTSTART" property, and the value of this property
MUST be later in time than the value of the "DTSTART" property.
Furthermore, this property MUST be specified as a date with local
time if and only if the "DTSTART" property is also specified as a
date with local time.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
due = "DUE" dueparam ":" dueval CRLF due = "DUE" dueparam ":" dueval CRLF
dueparam = *( dueparam = *(
; the following are OPTIONAL, ; the following are OPTIONAL,
; but MUST NOT occur more than once ; but MUST NOT occur more than once
skipping to change at page 97, line 4 skipping to change at page 100, line 51
"VFREEBUSY" or "VALARM" calendar components. "VFREEBUSY" or "VALARM" calendar components.
Description: In a "VEVENT" calendar component the property may be Description: In a "VEVENT" calendar component the property may be
used to specify a duration of the event, instead of an explicit used to specify a duration of the event, instead of an explicit
end date/time. In a "VTODO" calendar component the property may end date/time. In a "VTODO" calendar component the property may
be used to specify a duration for the to-do, instead of an be used to specify a duration for the to-do, instead of an
explicit due date/time. In a "VFREEBUSY" calendar component the explicit due date/time. In a "VFREEBUSY" calendar component the
property may be used to specify the interval of free time being property may be used to specify the interval of free time being
requested. In a "VALARM" calendar component the property may be requested. In a "VALARM" calendar component the property may be
used to specify the delay period prior to repeating an alarm. used to specify the delay period prior to repeating an alarm.
When the "DURATION" property relates to a "DTSTART" property that
is specified as a DATE value, then the "DURATION" property MUST be
specified as a "dur-day" or "dur-week" value.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
duration = "DURATION" durparam ":" dur-value CRLF duration = "DURATION" durparam ":" dur-value CRLF
;consisting of a positive duration of time. ;consisting of a positive duration of time.
durparam = *(";" other-param) durparam = *(";" other-param)
Example: The following is an example of this property that specifies Example: The following is an example of this property that specifies
skipping to change at page 130, line 27 skipping to change at page 134, line 27
Value Type: TEXT Value Type: TEXT
Property Parameters: IANA and non-standard property parameters can Property Parameters: IANA and non-standard property parameters can
be specified on this property. be specified on this property.
Conformance: This property MUST be specified once in a "VALARM" Conformance: This property MUST be specified once in a "VALARM"
calendar component. calendar component.
Description: Each "VALARM" calendar component has a particular type Description: Each "VALARM" calendar component has a particular type
of action associated with it. This property specifies the type of of action associated with it. This property specifies the type of
action. action. Applications MUST ignore alarms with x-name and iana-
token value they don't recognized.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
action = "ACTION" actionparam ":" actionvalue CRLF action = "ACTION" actionparam ":" actionvalue CRLF
actionparam = *(";" other-param) actionparam = *(";" other-param)
actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" actionvalue = "AUDIO" / "DISPLAY" / "EMAIL"
/ iana-token / x-name / iana-token / x-name
skipping to change at page 131, line 17 skipping to change at page 135, line 17
be repeated, after the initial trigger. be repeated, after the initial trigger.
Value Type: INTEGER Value Type: INTEGER
Property Parameters: IANA and non-standard property parameters can Property Parameters: IANA and non-standard property parameters can
be specified on this property. be specified on this property.
Conformance: This property can be specified in a "VALARM" calendar Conformance: This property can be specified in a "VALARM" calendar
component. component.
Description: If the alarm triggers more than once, then this Description: This property defines the number of time an alarm
property MUST be specified along with the "DURATION" property. should be repeated after its initial trigger. If the alarm
triggers more than once, then this property MUST be specified
along with the "DURATION" property.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
repeat = "REPEAT" repparam ":" integer CRLF repeat = "REPEAT" repparam ":" integer CRLF
;Default is "0", zero. ;Default is "0", zero.
repparam = *(";" other-param) repparam = *(";" other-param)
Example: The following is an example of this property for an alarm Example: The following is an example of this property for an alarm
skipping to change at page 134, line 27 skipping to change at page 138, line 27
Note: This is analogous to the creation date and time for a Note: This is analogous to the creation date and time for a
file in the file system. file in the file system.
Value Type: DATE-TIME Value Type: DATE-TIME
Property Parameters: IANA and non-standard property parameters can Property Parameters: IANA and non-standard property parameters can
be specified on this property. be specified on this property.
Conformance: The property can be specified once in "VEVENT", "VTODO" Conformance: The property can be specified once in "VEVENT", "VTODO"
or "VJOURNAL" calendar components. or "VJOURNAL" calendar components. The value MUST be specified as
a date with UTC time.
Description: The date and time is a UTC value. Description: This property specifies the date and time that the
calendar information was created by the calendar user agent in the
calendar store.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
created = "CREATED" creaparam ":" date-time CRLF created = "CREATED" creaparam ":" date-time CRLF
creaparam = *(";" other-param) creaparam = *(";" other-param)
Example: The following is an example of this property: Example: The following is an example of this property:
CREATED:19960329T133000Z CREATED:19960329T133000Z
3.8.7.2. Date/Time Stamp 3.8.7.2. Date/Time Stamp
Property Name: DTSTAMP Property Name: DTSTAMP
Purpose: This property indicates the date/time that the instance of Purpose: In the case of an iCalendar object that specifies a
the iCalendar object was created. "METHOD" property, this property specifies the date and time that
the instance of the iCalendar object was created. In the case of
an iCalendar object that doesn't specify a "METHOD" property, this
property specifies the date and time that the information
associated with the calendar component was last revised in the
calendar store.
Value Type: DATE-TIME Value Type: DATE-TIME
Property Parameters: IANA and non-standard property parameters can Property Parameters: IANA and non-standard property parameters can
be specified on this property. be specified on this property.
Conformance: This property MUST be included in the "VEVENT", Conformance: This property MUST be included in the "VEVENT",
"VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
Description: The value MUST be specified in the UTC time format. Description: The value MUST be specified in the UTC time format.
This property is also useful to protocols such as This property is also useful to protocols such as
[I-D.ietf-calsify-rfc2447bis] that have inherent latency issues [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues
skipping to change at page 135, line 17 skipping to change at page 139, line 23
Conformance: This property MUST be included in the "VEVENT", Conformance: This property MUST be included in the "VEVENT",
"VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
Description: The value MUST be specified in the UTC time format. Description: The value MUST be specified in the UTC time format.
This property is also useful to protocols such as This property is also useful to protocols such as
[I-D.ietf-calsify-rfc2447bis] that have inherent latency issues [I-D.ietf-calsify-rfc2447bis] that have inherent latency issues
with the delivery of content. This property will assist in the with the delivery of content. This property will assist in the
proper sequencing of messages containing iCalendar objects. proper sequencing of messages containing iCalendar objects.
This property is different than the "CREATED" and "LAST-MODIFIED" In the case of an iCalendar object that specifies a "METHOD"
properties. These two properties are used to specify when the property, this property is different than the "CREATED" and "LAST-
particular calendar data in the calendar store was created and MODIFIED" properties. These two properties are used to specify
last modified. This is different than when the iCalendar object when the particular calendar data in the calendar store was
representation of the calendar service information was created or created and last modified. This is different than when the
last modified. iCalendar object representation of the calendar service
information was created or last modified.
In the case of an iCalendar object that doesn't specify a "METHOD"
property, this property is equivalent to the "LAST-MODIFIED"
property.
Format Definition: This property is defined by the following Format Definition: This property is defined by the following
notation: notation:
dtstamp = "DTSTAMP" stmparam ":" date-time CRLF dtstamp = "DTSTAMP" stmparam ":" date-time CRLF
stmparam = *(";" other-param) stmparam = *(";" other-param)
Example: Example:
skipping to change at page 144, line 12 skipping to change at page 148, line 12
calendar users in a group. A time zone specification for Eastern calendar users in a group. A time zone specification for Eastern
United States has been specified. United States has been specified.
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0 VERSION:2.0
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America/New_York TZID:America/New_York
BEGIN:STANDARD BEGIN:STANDARD
DTSTART:19981025T020000 DTSTART:19981025T020000
RDATE:19981025T020000
TZOFFSETFROM:-0400 TZOFFSETFROM:-0400
TZOFFSETTO:-0500 TZOFFSETTO:-0500
TZNAME:EST TZNAME:EST
END:STANDARD END:STANDARD
BEGIN:DAYLIGHT BEGIN:DAYLIGHT
DTSTART:19990404T020000 DTSTART:19990404T020000
RDATE:19990404T020000
TZOFFSETFROM:-0500 TZOFFSETFROM:-0500
TZOFFSETTO:-0400 TZOFFSETTO:-0400
TZNAME:EDT TZNAME:EDT
END:DAYLIGHT END:DAYLIGHT
END:VTIMEZONE END:VTIMEZONE
BEGIN:VEVENT BEGIN:VEVENT
DTSTAMP:19980309T231000Z DTSTAMP:19980309T231000Z
UID:guid-1.example.com UID:guid-1.example.com
ORGANIZER;ROLE=CHAIR:mailto:mrbig@example.com ORGANIZER;ROLE=CHAIR:mailto:mrbig@example.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
skipping to change at page 147, line 29 skipping to change at page 151, line 29
END:VFREEBUSY END:VFREEBUSY
END:VCALENDAR END:VCALENDAR
5. Recommended Practices 5. Recommended Practices
These recommended practices should be followed in order to assure These recommended practices should be followed in order to assure
consistent handling of the following cases for an iCalendar object. consistent handling of the following cases for an iCalendar object.
1. Content lines longer than 75 octets SHOULD be folded. 1. Content lines longer than 75 octets SHOULD be folded.
2. When the "DTSTART" and "DTEND" properties , for "VEVENT"and 2.
"VJOURNAL" calendar components, and "DTSTART" and "DUE"
properties , for "VTODO" calendar components, have the same
value data type (e.g., DATE-TIME), they SHOULD specify values in
the same time format (e.g., date with local time, date with UTC
time, or date with local time and time zone reference). In the
case of date with local time and time zone reference, a
different time zone MAY be used for each property.
3. When the combination of the "RRULE" and "RDATE" properties in a 3. When the combination of the "RRULE" and "RDATE" properties in a
recurring component produces multiple instances having the same recurring component produces multiple instances having the same
start DATE-TIME value, they should be collapsed to, and start DATE-TIME value, they should be collapsed to, and
considered as, a single instance. If the "RDATE" property is considered as, a single instance. If the "RDATE" property is
specified as a PERIOD value the duration of the recurrence specified as a PERIOD value the duration of the recurrence
instance will be the one specified by the "RDATE" property, and instance will be the one specified by the "RDATE" property, and
not the duration of the recurrence instance defined by the not the duration of the recurrence instance defined by the
"DTSTART" property. "DTSTART" property.
skipping to change at page 148, line 15 skipping to change at page 152, line 9
property) which mailing list they are a member of. property) which mailing list they are a member of.
5. An implementation can truncate a "SUMMARY" property value to 255 5. An implementation can truncate a "SUMMARY" property value to 255
octets, but MUST NOT truncate the value in the middle of a UTF-8 octets, but MUST NOT truncate the value in the middle of a UTF-8
multi-octet sequence. multi-octet sequence.
6. If seconds of the minute are not supported by an implementation, 6. If seconds of the minute are not supported by an implementation,
then a value of "00" SHOULD be specified for the seconds then a value of "00" SHOULD be specified for the seconds
component in a time value. component in a time value.
7. If the value type parameter (VALUE=) contains an unknown value 7.
type, it SHOULD be treated as TEXT.
8. "TZURL" values SHOULD NOT be specified as a file URI type. This 8. "TZURL" values SHOULD NOT be specified as a file URI type. This
URI form can be useful within an organization, but is URI form can be useful within an organization, but is
problematic in the Internet. problematic in the Internet.
9. Some possible English values for "CATEGORIES" property include 9. Some possible English values for "CATEGORIES" property include
"ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
"HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
OCCASION", "TRAVEL", "VACATION". Categories can be specified in OCCASION", "TRAVEL", "VACATION". Categories can be specified in
any registered language. any registered language.
10. Some possible English values for "RESOURCES" property include 10. Some possible English values for "RESOURCES" property include
"CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
PHONE", "VEHICLE". Resources can be specified in any registered PHONE", "VEHICLE". Resources can be specified in any registered
language. language.
6. Registration of Content Type Elements 6. Internationalization Considerations
This section provides the process for registration of MIME Applications MUST generate iCalendar stream in the UTF-8 charset and
Calendaring and Scheduling Content Type iCalendar object methods and MUST accept iCalendar stream in the UTF-8 or US-ASCII charset.
new or modified properties.
6.1. Registration of New and Modified iCalendar Object Methods 7. Security Considerations
New MIME Calendaring and Scheduling Content Type iCalendar object Because calendaring and scheduling information is very privacy-
methods are registered by the publication of an IETF Request for sensitive, the protocol used for the transmission of calendaring and
Comments (RFC). Changes to an iCalendar object method are registered scheduling information should have capabilities to protect the
by the publication of a revision of the RFC defining the method. information from possible threats, such as eavesdropping, replay,
message insertion, deletion, modification and man-in-the-middle
attacks.
6.2. Registration of New Properties As this document only defines the data format and media type of text/
calendar that is independent of any calendar service or protocol, it
is up to the actual protocol specifications such as iTIP
[I-D.ietf-calsify-2446bis], iMIP [I-D.ietf-calsify-rfc2447bis], and
CalDAV [RFC4791] to describe the threats that the above attacks
present, as well as ways in which to mitigate them.
This section defines procedures by which new properties or enumerated 8. IANA Considerations
property values for the MIME Calendaring and Scheduling Content Type
can be registered with the IANA. Non-IANA properties can be used by
bilateral agreement, provided the associated properties names follow
the "X-" convention.
The procedures defined here are designed to allow public comment and 8.1. iCalendar Media Type Registration
review of new properties, while posing only a small impediment to the
definition of new properties.
Registration of a new property is accomplished by the following The Calendaring and Scheduling Core Object Specification is intended
steps. for use as a MIME content type. However, the implementation of the
memo is in no way limited solely as a MIME content type.
6.2.1. Define the property To: ietf-types@iana.org
Subject: Registration of media type text/calendar
A property is defined by completing the following template. Type name: text
To: ietf-calendar@imc.org Subtype name: calendar
Subject: Registration of text/calendar MIME property XXX Required parameters: none
Property name: Optional parameters: charset, method, component and optinfo
Property purpose: The "charset" parameter is defined in [RFC2046] for subtypes of
the "text" media type. It is used to indicate the charset used in
the body part. The charset supported by this revision of
iCalendar is UTF-8. The use of any other charset is deprecated by
this revision of iCalendar; however note that this revision
requires that compliant applications MUST accept iCalendar streams
using either the UTF-8 or US-ASCII charset.
Property value type(s): The "method" parameter is used to convey the iCalendar object
method or transaction semantics for the calendaring and scheduling
information. It also is an identifier for the restricted set of
properties and values that the iCalendar object consists of. The
parameter is to be used as a guide for applications interpreting
the information contained within the body part. It SHOULD NOT be
used to exclude or require particular pieces of information unless
the identified method definition specifically calls for this
behavior. Unless specifically forbidden by a particular method
definition, a text/calendar content type can contain any set of
properties permitted by the Calendaring and Scheduling Core Object
Specification. The "method" parameter MUST be specified and MUST
be set to the same value as the "METHOD" component property of the
iCalendar objects of the iCalendar stream if and only if the
iCalendar objects in the iCalendar stream all have a "METHOD"
component property set to the same value.
Property parameter (s): The value for the "method" parameter is defined as follows:
Conformance: method = 1*(ALPHA / DIGIT / "-")
; IANA registered iCalendar object method
Description: The "component" parameter conveys the type of iCalendar calendar
component within the body part. If the iCalendar object contains
more than one calendar component type, then multiple component
parameters MUST be specified.
Format definition: The value for the "component" parameter is defined as follows:
Examples: component = "VEVENT"
/ "VTODO"
/ "VJOURNAL"
/ "VFREEBUSY"
/ "VTIMEZONE"
/ iana-token
/ x-name
The meaning of each field in the template is as follows. The "optinfo" parameter conveys optional information about the
iCalendar object within the body part. This parameter can only
specify semantics already specified by the iCalendar object and
that can be otherwise determined by parsing the body part. In
addition, the optional information specified by this parameter
MUST be consistent with that information specified by the
iCalendar object. For example, it can be used to convey the
"Attendee" response status to a meeting request. The parameter
value consists of a string value.
Property name: The name of the property, as it will appear in the The parameter can be specified multiple times.
body of an text/calendar MIME Content-Type "property: value" line
to the left of the colon ":".
Property purpose: The purpose of the property (e.g., to indicate a The value for the "optinfo" parameter is defined as follows:
delegate for the event or to-do, etc.). Give a short but clear
optinfo = infovalue / qinfovalue
infovalue = iana-token / x-name
qinfovalue = DQUOTE (infovalue) DQUOTE
Encoding considerations: This media type can contain 8bit
characters, so the use of quoted-printable or base64 MIME Content-
Transfer-Encodings might be necessary when iCalendar objects are
transferred across protocols restricted to the 7bit repertoire.
Note that a text valued property in the content entity can also
have content encoding of special characters using a BACKSLASH
character (US-ASCII decimal 92) escapement technique. This means
that content values can end up encoded twice.
Security considerations: See Section 7.
Interoperability considerations: This media type is intended to
define a common format for conveying calendaring and scheduling
information between different systems. It is heavily based on the
earlier [VCAL] industry specification.
Published specification: This specification.
Applications which use this media type: This media type is designed
for widespread use by Internet calendaring and scheduling
applications. In addition, applications in the workflow and
document management area might find this content-type applicable.
The iTIP [I-D.ietf-calsify-2446bis], iMIP
[I-D.ietf-calsify-rfc2447bis] and CalDAV [RFC4791] Internet
protocols directly use this media type also.
Additional information:
Magic number(s): None.
File extension(s): The file extension of "ics" is to be used to
designate a file containing (an arbitrary set of) calendaring
and scheduling information consistent with this MIME content
type.
The file extension of "ifb" is to be used to designate a file
containing free or busy time information consistent with this
MIME content type.
Macintosh file type code(s): The file type code of "iCal" is to
be used in Apple MacIntosh operating system environments to
designate a file containing calendaring and scheduling
information consistent with this MIME media type.
The file type code of "iFBf" is to be used in Apple MacIntosh
operating system environments to designate a file containing
free or busy time information consistent with this MIME media
type.
Person & email address to contact for further information: See the
"Author's Address" section of this document.
Intended usage: COMMON
Restrictions on usage: There are no restrictions on where this media
type can be used.
Author: See the "Author's Address" section of this document.
Change controller: IETF
8.2. New iCalendar Elements Registration
This section defines the process to register new or modified
iCalendar elements, that is, components, properties, parameters,
value data types, and values, with IANA.
8.2.1. iCalendar Elements Registration Procedure
The IETF will create a mailing list, icalendar@ietf.org [2], which
can be used for public discussion of iCalendar elements proposals
prior to registration. Use of the mailing list is strongly
encouraged. The IESG will appoint a designated expert who will
monitor the icalendar@ietf.org [2] mailing list and review
registrations.
Registration of new iCalendar elements MUST be reviewed by the
designated expert and published in an RFC. A Standard Tracks RFC is
REQUIRED for the regisration of new value data types that modify
existing properties, as well as for the registration of participation
statuses values to be used in "VEVENT" calendar components. A
Standard Tracks RFC is also REQUIRED for registration of iCalendar
elements that modify iCalendar elements previously documented in a
Standard Tracks RFC.
The registration procedure begins when a completed registration
template, defined in the sections below, is sent to
icalendar@ietf.org [2] and iana@iana.org [3]. The designated expert
is expected to tell IANA and the submitter of the registration within
two weeks whether the registration is approved, approved with minor
changes, or rejected with cause. When a registration is rejected
with cause, it can be re-submitted if the concerns listed in the
cause are addressed. Decisions made by the designated expert can be
appealed to the IESG Applications Area Director, then to the IESG.
They follow the normal appeals procedure for IESG decisions.
8.2.2. Registration Template for Components
A component is defined by completing the following template.
Component name: The name of the component.
Purpose: The purpose of the component. Give a short but clear
description. description.
Property value type (s): Any of the valid value types for the Format definition: The ABNF for the component definition needs to
property value needs to be specified. The default value type also be specified.
needs to be specified. If a new value type is specified, it needs
to be declared in this section.
Property parameter (s): Any of the valid property parameters for the Description: Any special notes about the component, how it is to
property needs to be specified. be used, etc.
Conformance: The calendar components that the property can appear in Example(s): One or more examples of instances of the component
needs to be specified. needs to be specified.
Description: Any special notes about the property, how it is to be 8.2.3. Registration Template for Properties
used, etc.
Format definition: The ABNF for the property definition needs to be A property is defined by completing the following template.
Property name: The name of the property.
Purpose: The purpose of the property. Give a short but clear
description.
Value type: Any of the valid value types for the property value
needs to be specified. The default value type also needs to be
specified. specified.
Examples: One or more examples of instances of the property needs to Property parameters: Any of the valid property parameters for the
property MUST be specified.
Conformance: The calendar components that the property can appear
in MUST be specified.
Description: Any special notes about the property, how it is to
be used, etc.
Format definition: The ABNF for the property definition needs to
be specified. be specified.
6.2.2. Post the Property definition Example(s): One or more examples of instances of the property
needs to be specified.
The property description MUST be posted to the new property 8.2.4. Registration Template for Parameters
discussion list, ietf-calendar@imc.org.
6.2.3. Allow a comment period A parameter is defined by completing the following template.
Discussion on the new property MUST be allowed to take place on the Parameter name: The name of the parameter.
list for a minimum of two weeks. Consensus MUST be reached on the
property before proceeding to the next step.
6.2.4. Submit the property for approval Purpose: The purpose of the parameter. Give a short but clear
description.
Once the two-week comment period has elapsed, and the proposer is Format definition: The ABNF for the parameter definition needs to
convinced consensus has been reached on the property, the be specified.
registration application should be submitted to the Method Reviewer
for approval. The Method Reviewer is appointed by the Application
Area Directors and can either accept or reject the property
registration. An accepted registration should be passed on by the
Method Reviewer to the IANA for inclusion in the official IANA method
registry. The registration can be rejected for any of the following
reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
Technical deficiencies raised on the list or elsewhere have not been
addressed. The Method Reviewer's decision to reject a property can
be appealed by the proposer to the IESG, or the objections raised can
be addressed by the proposer and the property resubmitted.
6.3. Property Change Control Description: Any special notes about the parameter, how it is to
be used, etc.
Existing properties can be changed using the same process by which Example(s): One or more examples of instances of the parameter
they were registered. needs to be specified.
1. Define the change 8.2.5. Registration Template for Value Data Types
2. Post the change A value data type is defined by completing the following template.
3. Allow a comment period Value name: The name of the value type.
4. Submit the property for approval Purpose: The purpose of the value type. Give a short but clear
description.
Note that the original author or any other interested party can Format definition: The ABNF for the value type definition needs
propose a change to an existing property, but that such changes to be specified.
should only be proposed when there are serious omissions or errors in
the published memo. The Method Reviewer can object to a change if it
is not backward compatible, but is not required to do so.
Property definitions can never be deleted from the IANA registry, but Description: Any special notes about the value type, how it is to
properties which are no longer believed to be useful can be declared be used, etc.
OBSOLETE by a change to their "intended use" field.
7. Internationalization Considerations Example(s): One or more examples of instances of the value type
needs to be specified.
8. Security Considerations 8.2.6. Registration Template for Values
SPOOFING: In this memo, the "Organizer" is the only person A value is defined by completing the following template.
authorized to make changes to an existing "VEVENT", "VTODO",
"VJOURNAL" calendar component and redistribute the updates to the
"Attendees". An iCalendar object that maliciously changes or
cancels an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY"
calendar component might be constructed by someone other than the
"Organizer" and sent to the "Attendees". In addition in this
memo, other than the "Organizer", an "Attendee" of a "VEVENT",
"VTODO", "VJOURNAL" calendar component is the only other person
authorized to update any parameter associated with their
"ATTENDEE" property and send it to the "Organizer". An iCalendar
object that maliciously changes the "ATTENDEE" parameters can be
constructed by someone other than the real "Attendee" and sent to
the "Organizer".
ATTACHMENTS: An iCalendar object can include references to Uniform Value: The value literal.
Resource Locators that can be programmed resources.
Implementers and users of this memo should be aware of the network Purpose: The purpose of the value. Give a short but clear
security implications of accepting and parsing such information. description.
In addition, the security considerations observed by
implementations of electronic mail systems should be followed for
this memo.
9. IANA Considerations Conformance: The calendar properties and/or parameters that can
take this value needs to be specified.
The IANA is requested to create and maintain a number of registries. Example(s): One or more examples of instances of the value needs
The table below describes each. Subsections below contain the to be specified.
initial registrations and additional instructions for registrations.
+---------------+------------------------------------+--------------+ The following is a fictitious example of a registration of an
| Registry Name | Registration Requirements | Reference | iCalendar value:
+---------------+------------------------------------+--------------+
| Components | RFC, Expert Review | Section 9.1 |
| Properties | RFC, Expert Review | Section 9.2 |
| Property | RFC, Expert Review | Section 9.3 |
| Parameters | | |
| Value Data | Standards Action Required for new | Section 9.4 |
| Type Values | values that modify existing | |
| | parameters | |
| Calendar User | RFC, Expert Review | Section 9.5 |
| Type Values | | |
| Free/Busy | RFC, Expert Review | Section 9.6 |
| Time Type | | |
| Values | | |
| Participation | Internet Standards Action for | Section 9.7 |
| Status Values | VEVENTs, otherwise Expert Review | |
| Relationship | RFC, Expert Review | Section 9.8 |
| Type Values | | |
| Participation | RFC, Expert Review | Section 9.9 |
| Role Values | | |
| Action Values | RFC, Expert Review | Section 9.10 |
| Method Values | RFC, Expert Review | Section 9.11 |
+---------------+------------------------------------+--------------+
Each of the above is described in separate sub-sections below. Value: TOP-SECRET
9.1. Components Registry Purpose: This value is used to specify the access classification
of top-secret calendar components.
Conformance: This value can be used with the "CLASS" property.
Example(s): The following is an example of this value used with
the "CLASS" property:
CLASS:TOP-SECRET
8.3. Initial iCalendar Elements Registries
The IANA is requested to create and maintain the following registries
for iCalendar elements with pointers to appropriate reference
documents.
8.3.1. Components Registry
The following table is to be used to initialize the components The following table is to be used to initialize the components
registry. registry.
+----------------+---------+------------------------+ +-----------+---------+------------------------+
| Component Name | Status | Reference | | Component | Status | Reference |
+----------------+---------+------------------------+ +-----------+---------+------------------------+
| VCALENDAR | Current | RFCXXXX, Section 3.4 | | VCALENDAR | Current | RFCXXXX, Section 3.4 |
| VEVENT | Current | RFCXXXX, Section 3.6.1 | | VEVENT | Current | RFCXXXX, Section 3.6.1 |
| VTODO | Current | RFCXXXX, Section 3.6.2 | | VTODO | Current | RFCXXXX, Section 3.6.2 |
| VJOURNAL | Current | RFCXXXX, Section 3.6.3 | | VJOURNAL | Current | RFCXXXX, Section 3.6.3 |
| VFREEBUSY | Current | RFCXXXX, Section 3.6.4 | | VFREEBUSY | Current | RFCXXXX, Section 3.6.4 |
| VTIMEZONE | Current | RFCXXXX, Section 3.6.5 | | VTIMEZONE | Current | RFCXXXX, Section 3.6.5 |
| VALARM | Current | RFCXXXX, Section 3.6.6 | | VALARM | Current | RFCXXXX, Section 3.6.6 |
| STANDARD | Current | RFCXXXX, Section 3.6.5 | | STANDARD | Current | RFCXXXX, Section 3.6.5 |
| DAYLIGHT | Current | RFCXXXX, Section 3.6.5 | | DAYLIGHT | Current | RFCXXXX, Section 3.6.5 |
+----------------+---------+------------------------+ +-----------+---------+------------------------+
9.2. Properties Registry
Properties that are registered with IANA are to be document via the 8.3.2. Properties Registry
RFC process. It is not necessary for properties to be placed on the
standards track to be registered unless the usage of other standard
properties, parameters, or enumerations are changed. Components
specifically require standards action. However, each property MUST
specify what standard parameters, if any, are allowed, and in what
components the property is valid (e.g., "VEVENT", "VTODO", etc.).
The IANA is requested to maintain a table of such properties with
pointers to appropriate reference documents.
The following table is to be used to initialize the property The following table is to be used to initialize the properties
registry. registry.
+------------------+------------+---------------------------+ +------------------+------------+---------------------------+
| Property Name | Status | Reference | | Property | Status | Reference |
+------------------+------------+---------------------------+ +------------------+------------+---------------------------+
| CALSCALE | Current | RFCXXXX, Section 3.7.1 | | CALSCALE | Current | RFCXXXX, Section 3.7.1 |
| METHOD | Current | RFCXXXX, Section 3.7.2 | | METHOD | Current | RFCXXXX, Section 3.7.2 |
| PRODID | Current | RFCXXXX, Section 3.7.3 | | PRODID | Current | RFCXXXX, Section 3.7.3 |
| VERSION | Current | RFCXXXX, Section 3.7.4 | | VERSION | Current | RFCXXXX, Section 3.7.4 |
| ATTACH | Current | RFCXXXX, Section 3.8.1.1 | | ATTACH | Current | RFCXXXX, Section 3.8.1.1 |
| CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 | | CATEGORIES | Current | RFCXXXX, Section 3.8.1.2 |
| CLASS | Current | RFCXXXX, Section 3.8.1.3 | | CLASS | Current | RFCXXXX, Section 3.8.1.3 |
| COMMENT | Current | RFCXXXX, Section 3.8.1.4 | | COMMENT | Current | RFCXXXX, Section 3.8.1.4 |
| DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 | | DESCRIPTION | Current | RFCXXXX, Section 3.8.1.5 |
skipping to change at page 154, line 37 skipping to change at page 161, line 27
| ACTION | Current | RFCXXXX, Section 3.8.6.1 | | ACTION | Current | RFCXXXX, Section 3.8.6.1 |
| REPEAT | Current | RFCXXXX, Section 3.8.6.2 | | REPEAT | Current | RFCXXXX, Section 3.8.6.2 |
| TRIGGER | Current | RFCXXXX, Section 3.8.6.3 | | TRIGGER | Current | RFCXXXX, Section 3.8.6.3 |
| CREATED | Current | RFCXXXX, Section 3.8.7.1 | | CREATED | Current | RFCXXXX, Section 3.8.7.1 |
| DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 | | DTSTAMP | Current | RFCXXXX, Section 3.8.7.2 |
| LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 | | LAST-MODIFIED | Current | RFCXXXX, Section 3.8.7.3 |
| SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 | | SEQUENCE | Current | RFCXXXX, Section 3.8.7.4 |
| REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 | | REQUEST-STATUS | Current | RFCXXXX, Section 3.8.8.3 |
+------------------+------------+---------------------------+ +------------------+------------+---------------------------+
9.3. Property Parameters Registry 8.3.3. Parameters Registry
The IANA is requested to establish and maintain a table of property
parameters for the iCalendar standard. Additional parameters may be
added to this table as follows:
o Those parameters that do not modify standard properties or
parameters may be added through the publishing of informational or
experimental RFCs with expert review through the APPS Area of the
IETF.
o Those property parameters that modify existing standard properties
or parameters MUST update this memo, and hence be promoted through
the Internet standards process.
In all cases, each parameter MUST list the property it will be used
with. Implementations that are unable to recognize a property
parameter MUST ignore the property.
The following table is to be initialized with the following values: The following table is to be used to initialize the parameters
registry.
+-------------------------+------------+-------------------------+ +----------------+------------+-------------------------+
| Property Parameter Name | Status | Reference | | Parameter | Status | Reference |
+-------------------------+------------+-------------------------+ +----------------+------------+-------------------------+
| ALTREP | Current | RFCXXXX, Section 3.2.1 | | ALTREP | Current | RFCXXXX, Section 3.2.1 |
| CN | Current | RFCXXXX, Section 3.2.2 | | CN | Current | RFCXXXX, Section 3.2.2 |
| CUTYPE | Current | RFCXXXX, Section 3.2.3 | | CUTYPE | Current | RFCXXXX, Section 3.2.3 |
| DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 | | DELEGATED-FROM | Current | RFCXXXX, Section 3.2.4 |
| DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 | | DELEGATED-TO | Current | RFCXXXX, Section 3.2.5 |
| DIR | Current | RFCXXXX, Section 3.2.6 | | DIR | Current | RFCXXXX, Section 3.2.6 |
| ENCODING | Current | RFCXXXX, Section 3.2.7 | | ENCODING | Current | RFCXXXX, Section 3.2.7 |
| FMTTYPE | Current | RFCXXXX, Section 3.2.8 | | FMTTYPE | Current | RFCXXXX, Section 3.2.8 |
| FBTYPE | Current | RFCXXXX, Section 3.2.9 | | FBTYPE | Current | RFCXXXX, Section 3.2.9 |
| LANGUAGE | Current | RFCXXXX, Section 3.2.10 | | LANGUAGE | Current | RFCXXXX, Section 3.2.10 |
| MEMBER | Current | RFCXXXX, Section 3.2.11 | | MEMBER | Current | RFCXXXX, Section 3.2.11 |
| PARTSTAT | Current | RFCXXXX, Section 3.2.12 | | PARTSTAT | Current | RFCXXXX, Section 3.2.12 |
| RANGE | Deprecated | RFC2445, Section 4.2.13 | | RANGE | Deprecated | RFC2445, Section 4.2.13 |
| RELATED | Current | RFCXXXX, Section 3.2.13 | | RELATED | Current | RFCXXXX, Section 3.2.13 |
| RELTYPE | Current | RFCXXXX, Section 3.2.14 | | RELTYPE | Current | RFCXXXX, Section 3.2.14 |
| ROLE | Current | RFCXXXX, Section 3.2.15 | | ROLE | Current | RFCXXXX, Section 3.2.15 |
| RSVP | Current | RFCXXXX, Section 3.2.16 | | RSVP | Current | RFCXXXX, Section 3.2.16 |
| SENT-BY | Current | RFCXXXX, Section 3.2.17 | | SENT-BY | Current | RFCXXXX, Section 3.2.17 |
| TZID | Current | RFCXXXX, Section 3.2.18 | | TZID | Current | RFCXXXX, Section 3.2.18 |
| VALUE | Current | RFCXXXX, Section 3.2.19 | | VALUE | Current | RFCXXXX, Section 3.2.19 |
+-------------------------+------------+-------------------------+ +----------------+------------+-------------------------+
9.4. Value Data Type Values Registry 8.3.4. Value Data Types Registry
The IANA is requested to establish a registry of Property Value Data The following table is to be used to initialize the value data types
Types for the iCalendar standard. Additional data types may only be registry.
added through the Internet standards process. The initial values are
as follows:
+-------------------------------+---------+-------------------------+ +-----------------+---------+-------------------------+
| Property Parameter Value Type | Status | Reference | | Value Data Type | Status | Reference |
+-------------------------------+---------+-------------------------+ +-----------------+---------+-------------------------+
| BINARY | Current | RFCXXXX, Section 3.3.1 | | BINARY | Current | RFCXXXX, Section 3.3.1 |
| BOOLEAN | Current | RFCXXXX, Section 3.3.2 | | BOOLEAN | Current | RFCXXXX, Section 3.3.2 |
| CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 | | CAL-ADDRESS | Current | RFCXXXX, Section 3.3.3 |
| DATE | Current | RFCXXXX, Section 3.3.4 | | DATE | Current | RFCXXXX, Section 3.3.4 |
| DATE-TIME | Current | RFCXXXX, Section 3.3.5 | | DATE-TIME | Current | RFCXXXX, Section 3.3.5 |
| DURATION | Current | RFCXXXX, Section 3.3.6 | | DURATION | Current | RFCXXXX, Section 3.3.6 |
| FLOAT | Current | RFCXXXX, Section 3.3.7 | | FLOAT | Current | RFCXXXX, Section 3.3.7 |
| INTEGER | Current | RFCXXXX, Section 3.3.8 | | INTEGER | Current | RFCXXXX, Section 3.3.8 |
| PERIOD | Current | RFCXXXX, Section 3.3.9 | | PERIOD | Current | RFCXXXX, Section 3.3.9 |
| RECUR | Current | RFCXXXX, Section 3.3.10 | | RECUR | Current | RFCXXXX, Section 3.3.10 |
| TEXT | Current | RFCXXXX, Section 3.3.11 | | TEXT | Current | RFCXXXX, Section 3.3.11 |
| TIME | Current | RFCXXXX, Section 3.3.12 | | TIME | Current | RFCXXXX, Section 3.3.12 |
| URI | Current | RFCXXXX, Section 3.3.13 | | URI | Current | RFCXXXX, Section 3.3.13 |
| UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 | | UTC-OFFSET | Current | RFCXXXX, Section 3.3.14 |
+-------------------------------+---------+-------------------------+ +-----------------+---------+-------------------------+
9.5. Calendar User Type Values Registry 8.3.5. Calendar User Types Registry
Calendar user types (CUTYPEs) are used to indicate the sort of user The following table is to be used to initialize the calendar user
associated with a CAL-ADDRESS. It is described in more detail in types registry.
Section 3.2.3. Expert review is required for an IANA assignment.
The following values are currently allowed:
+--------------------+---------+------------------------+ +--------------------+---------+------------------------+
| Calendar User Type | Status | Reference | | Calendar User Type | Status | Reference |
+--------------------+---------+------------------------+ +--------------------+---------+------------------------+
| INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 | | INDIVIDUAL | Current | RFCXXXX, Section 3.2.3 |
| GROUP | Current | RFCXXXX, Section 3.2.3 | | GROUP | Current | RFCXXXX, Section 3.2.3 |
| RESOURCE | Current | RFCXXXX, Section 3.2.3 | | RESOURCE | Current | RFCXXXX, Section 3.2.3 |
| ROOM | Current | RFCXXXX, Section 3.2.3 | | ROOM | Current | RFCXXXX, Section 3.2.3 |
| UNKNOWN | Current | RFCXXXX, Section 3.2.3 | | UNKNOWN | Current | RFCXXXX, Section 3.2.3 |
+--------------------+---------+------------------------+ +--------------------+---------+------------------------+
Implementations that do not recognize a calendar user type MUST treat 8.3.6. Free/Busy Time Types Registry
the CAL-ADDRESS as an INDIVIDUAL.
9.6. Free/Busy Time Type Values Registry
This parameter is described in Section 3.2.9. New entries require The following table is to be used to initialize the free/busy time
expert review. The table below specifies the initial registry: types registry.
+------------------+---------+------------------------+ +---------------------+---------+------------------------+
| Free/Busy Type | Status | Reference | | Free/Busy Time Type | Status | Reference |
+------------------+---------+------------------------+ +---------------------+---------+------------------------+
| FREE | Current | RFCXXXX, Section 3.2.9 | | FREE | Current | RFCXXXX, Section 3.2.9 |
| BUSY | Current | RFCXXXX, Section 3.2.9 | | BUSY | Current | RFCXXXX, Section 3.2.9 |
| BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 | | BUSY-UNAVAILABLE | Current | RFCXXXX, Section 3.2.9 |
| BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 | | BUSY-TENTATIVE | Current | RFCXXXX, Section 3.2.9 |
+------------------+---------+------------------------+ +---------------------+---------+------------------------+
Implementations that do not recognize a particular fbtype MUST treat
that calendar user as BUSY.
9.7. Participation Status Values Registry 8.3.7. Participation Statuses Registry
PARTSTAT denotes participate status and is described in The following table is to be used to initialize the participation
Section 3.2.12. The following table initializes the registry for statuses registry.
participant status:
+--------------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
| Participant Status Value | Status | Reference | | Participant Status | Status | Reference |
+--------------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
| NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 | | NEEDS-ACTION | Current | RFCXXXX, Section 3.2.12 |
| ACCEPTED | Current | RFCXXXX, Section 3.2.12 | | ACCEPTED | Current | RFCXXXX, Section 3.2.12 |
| DECLINED | Current | RFCXXXX, Section 3.2.12 | | DECLINED | Current | RFCXXXX, Section 3.2.12 |
| TENTATIVE | Current | RFCXXXX, Section 3.2.12 | | TENTATIVE | Current | RFCXXXX, Section 3.2.12 |
| DELEGATED | Current | RFCXXXX, Section 3.2.12 | | DELEGATED | Current | RFCXXXX, Section 3.2.12 |
| COMPLETED | Current | RFCXXXX, Section 3.2.12 | | COMPLETED | Current | RFCXXXX, Section 3.2.12 |
| IN-PROCESS | Current | RFCXXXX, Section 3.2.12 | | IN-PROCESS | Current | RFCXXXX, Section 3.2.12 |
+--------------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
Existing implementations MUST treat an unknown PARTSTAT value as
NEEDS-ACTION.
9.8. Relationship Type Values Registry 8.3.8. Relationship Types Registry
This parameter is described in Section 3.2.14. Expert review is The following table is to be used to initialize the property
required for an addition. The table below initializes the registry. parameters registry.
+-------------------+---------+-------------------------+ +-------------------+---------+-------------------------+
| Relationship Type | Status | Reference | | Relationship Type | Status | Reference |
+-------------------+---------+-------------------------+ +-------------------+---------+-------------------------+
| CHILD | Current | RFCXXXX, Section 3.2.14 | | CHILD | Current | RFCXXXX, Section 3.2.14 |
| PARENT | Current | RFCXXXX, Section 3.2.14 | | PARENT | Current | RFCXXXX, Section 3.2.14 |
| SIBLING | Current | RFCXXXX, Section 3.2.14 | | SIBLING | Current | RFCXXXX, Section 3.2.14 |
+-------------------+---------+-------------------------+ +-------------------+---------+-------------------------+
Implementations MUST treat an unknown relationship as a PARENT. 8.3.9. Participation Roles Registry
9.9. Participation Role Values Registry
Roles are described in Section 3.2.15. The initial registration is The following table is to be used to initialize the participation
as follows: roles registry.
+-----------------+---------+-------------------------+ +-----------------+---------+-------------------------+
| Role Type | Status | Reference | | Role Type | Status | Reference |
+-----------------+---------+-------------------------+ +-----------------+---------+-------------------------+
| CHAIR | Current | RFCXXXX, Section 3.2.15 | | CHAIR | Current | RFCXXXX, Section 3.2.15 |
| REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | | REQ-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
| OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | | OPT-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
| NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 | | NON-PARTICIPANT | Current | RFCXXXX, Section 3.2.15 |
+-----------------+---------+-------------------------+ +-----------------+---------+-------------------------+
Implementations that do not recognize a specific ROLE should treat 8.3.10. Actions Registry
the calendar user as REQ-PARTICIPANT.
9.10. Action Values Registry
Actions are covered in Section 3.8.6.1. The following table The following table is to be used to initialize the actions registry.
intializes the registry.
+-----------------------+------------+--------------------------+ +-----------+------------+--------------------------+
| ACTION Property Value | Status | Reference | | Action | Status | Reference |
+-----------------------+------------+--------------------------+ +-----------+------------+--------------------------+
| AUDIO | Current | RFCXXXX, Section 3.8.6.1 | | AUDIO | Current | RFCXXXX, Section 3.8.6.1 |
| DISPLAY | Current | RFCXXXX, Section 3.8.6.1 | | DISPLAY | Current | RFCXXXX, Section 3.8.6.1 |
| EMAIL | Current | RFCXXXX, Section 3.8.6.1 | | EMAIL | Current | RFCXXXX, Section 3.8.6.1 |
| PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 | | PROCEDURE | Deprecated | RFC2445, Section 4.8.6.1 |
+-----------------------+------------+--------------------------+ +-----------+------------+--------------------------+
Implementations MUST ignore unrecognized "ACTION" property values.
9.11. Method Values Registry
Methods are covered in Section 3.7.2. No values are defined in this
document for the "METHOD" property.
9.12. Media Type Registration Information
The Calendaring and Scheduling Core Object Specification is intended
for use as a MIME content type. However, the implementation of the
memo is in no way limited solely as a MIME content type.
To: ietf-types@iana.org
Subject: Registration of media type text/calendar
Type name: text
Subtype name: calendar
Required parameters: none
Optional parameters: charset, method, component and optinfo
The "charset" parameter is defined in [RFC2046] for subtypes of
the "text" media type. It is used to indicate the charset used in
the body part. The charset supported by this revision of
iCalendar is UTF-8. The use of any other charset is deprecated by
this revision of iCalendar; however note that this revision
requires that compliant applications MUST accept iCalendar objects
using either the UTF-8 or US-ASCII charset.
The "method" parameter is used to convey the iCalendar object
method or transaction semantics for the calendaring and scheduling
information. It also is an identifier for the restricted set of
properties and values that the iCalendar object consists of. The
parameter is to be used as a guide for applications interpreting
the information contained within the body part. It SHOULD NOT be
used to exclude or require particular pieces of information unless
the identified method definition specifically calls for this
behavior. Unless specifically forbidden by a particular method
definition, a text/calendar content type can contain any set of
properties permitted by the Calendaring and Scheduling Core Object
Specification. The "method" parameter MUST be specified and MUST
be set to the same value as the "METHOD" component property of the
iCalendar objects of the iCalendar stream if and only if the
iCalendar objects in the iCalendar stream all have a "METHOD"
component property set to the same value.
The value for the "method" parameter is defined as follows:
method = 1*(ALPHA / DIGIT / "-")
; IANA registered iCalendar object method
The "component" parameter conveys the type of iCalendar calendar
component within the body part. If the iCalendar object contains
more than one calendar component type, then multiple component
parameters MUST be specified.
The value for the "component" parameter is defined as follows:
component = "VEVENT"
/ "VTODO"
/ "VJOURNAL"
/ "VFREEBUSY"
/ "VTIMEZONE"
/ iana-token
/ x-name
The "optinfo" parameter conveys optional information about the
iCalendar object within the body part. This parameter can only
specify semantics already specified by the iCalendar object and
that can be otherwise determined by parsing the body part. In
addition, the optional information specified by this parameter
MUST be consistent with that information specified by the
iCalendar object. For example, it can be used to convey the
"Attendee" response status to a meeting request. The parameter
value consists of a string value.
The parameter can be specified multiple times.
The value for the "optinfo" parameter is defined as follows:
optinfo = infovalue / qinfovalue
infovalue = iana-token / x-name
qinfovalue = DQUOTE (infovalue) DQUOTE
Encoding considerations: This media type can contain 8bit
characters, so the use of quoted-printable or base64 MIME Content-
Transfer-Encodings might be necessary when iCalendar objects are
transferred across protocols restricted to the 7bit repertoire.
Note that a text valued property in the content entity can also
have content encoding of special characters using a BACKSLASH
character (US-ASCII decimal 92) escapement technique. This means
that content values can end up encoded twice.
Security considerations: See Section 8.
Interoperability considerations: This media type is intended to
define a common format for conveying calendaring and scheduling
information between different systems. It is heavily based on the
earlier [VCAL] industry specification.
Published specification: This specification.
Applications which use this media type: This media type is designed
for widespread use by Internet calendaring and scheduling
applications. In addition, applications in the workflow and
document management area might find this content-type applicable.
The iTIP [I-D.ietf-calsify-2446bis], iMIP
[I-D.ietf-calsify-rfc2447bis] and CalDAV [I-D.dusseault-caldav]
Internet protocols directly use this media type also.
Additional information:
Magic number(s): None.
File extension(s): The file extension of "ics" is to be used to
designate a file containing (an arbitrary set of) calendaring
and scheduling information consistent with this MIME content
type.
The file extension of "ifb" is to be used to designate a file
containing free or busy time information consistent with this
MIME content type.
Macintosh file type code(s): The file type code of "iCal" is to
be used in Apple MacIntosh operating system environments to
designate a file containing calendaring and scheduling
information consistent with this MIME media type.
The file type code of "iFBf" is to be used in Apple MacIntosh
operating system environments to designate a file containing
free or busy time information consistent with this MIME media
type.
Person & email address to contact for further information: TBD 8.3.11. Classifications Registry
Intended usage: COMMON The following table is to be used to initialize the classifications
registry.
Restrictions on usage: There are no restrictions on where this media +----------------+---------+--------------------------+
type can be used. | Classification | Status | Reference |
+----------------+---------+--------------------------+
| PUBLIC | Current | RFCXXXX, Section 3.8.1.3 |
| PRIVATE | Current | RFCXXXX, Section 3.8.1.3 |
| CONFIDENTIAL | Current | RFCXXXX, Section 3.8.1.3 |
+----------------+---------+--------------------------+
Author: TBD 8.3.12. Methods Registry
Change controller: IETF No values are defined in this document for the "METHOD" property.
10. Acknowledgements 9. Acknowledgements
The editor of this document wish to thank Frank Dawson and Stenerson The editor of this document wish to thank Frank Dawson and Derik
Derik, the original authors of RFC2445, as well as the following Stenerson, the original authors of RFC2445, as well as the following
individuals who have participated in the drafting, review and individuals who have participated in the drafting, review and
discussion of this memo: discussion of this memo:
Joe Abley, Hervey Allen, Jay Batson, Oliver Block, Stephane Joe Abley, Hervey Allen, Jay Batson, Oliver Block, Stephane
Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus Daboo, Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus Daboo,
Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Ned Freed, Ted Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Ned Freed, Ted
Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Leif Johansson, Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Leif Johansson,
Reinhold Kainhofer, Eliot Lear, Michiel van Leeuwen, Jonathan Lennox, Reinhold Kainhofer, Eliot Lear, Michiel van Leeuwen, Jonathan Lennox,
Jeff McCullough, Bill McQuillan, Alexey Melnikov, Aki Niemi, John W. Jeff McCullough, Bill McQuillan, Alexey Melnikov, Aki Niemi, John W.
Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, Arnaud Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, Arnaud
Quillaud, Robert Ransdell, Julian F. Reschke, Caleb Richardson, Sam Quillaud, Robert Ransdell, Julian F. Reschke, Caleb Richardson, Sam
Roberts, George Sexton, Nigel Swinson, Simon Vaillancourt, and Sandy Roberts, George Sexton, Nigel Swinson, Simon Vaillancourt, and Sandy
Wills. Wills.
The editor would also like to thank the Calendaring and Scheduling The editor would also like to thank the Calendaring and Scheduling
Consortium for advice with this specification, and for organizing Consortium for advice with this specification, and for organizing
interoperability testing events to help refine it. interoperability testing events to help refine it.
11. References 10. References
11.1. Normative References 10.1. Normative References
[ISO.8601.1988] International Organization for [ISO.8601.2004] International Organization for
Standardization, "Data elements and Standardization, "Data elements and
interchange formats - Information interchange formats -- Information
interchange - Representation of dates interchange -- Representation of dates
and times", and times", 2004.
<http://www.w3.org/TR/NOTE-datetime>.
[ISO.9070.1991] International Organization for [ISO.9070.1991] International Organization for
Standardization, "Information Standardization, "Information
Technology_SGML Support Facilities -- Technology_SGML Support Facilities --
Registration Procedures for Public Registration Procedures for Public
Text Owner Identifiers, Second Text Owner Identifiers, Second
Edition", April 1991, <http:// Edition", April 1991.
www.ietf.org/proceedings/98dec/I-D/
draft-ietf-calsch-icalfpi-00.txt>.
[RFC2045] Freed, N. and N. Borenstein, [RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, Message Bodies", RFC 2045,
November 1996. November 1996.
[RFC2046] Freed, N. and N. Borenstein, [RFC2046] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", (MIME) Part Two: Media Types",
skipping to change at page 163, line 35 skipping to change at page 167, line 5
October 2005. October 2005.
[RFC4646] Phillips, A. and M. Davis, "Tags for [RFC4646] Phillips, A. and M. Davis, "Tags for
Identifying Languages", BCP 47, Identifying Languages", BCP 47,
RFC 4646, September 2006. RFC 4646, September 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, [RFC4648] Josefsson, S., "The Base16, Base32,
and Base64 Data Encodings", RFC 4648, and Base64 Data Encodings", RFC 4648,
October 2006. October 2006.
11.2. Informative References 10.2. Informative References
[I-D.dusseault-caldav] Daboo, C., Desruisseaux, B., and L.
Dusseault, "Calendaring Extensions to
WebDAV (CalDAV)",
draft-dusseault-caldav-15 (work in
progress), September 2006.
[I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport- [I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport-
Independent Interoperability Protocol Independent Interoperability Protocol
(iTIP)", draft-ietf-calsify-2446bis-02 (iTIP)", draft-ietf-calsify-2446bis-03
(work in progress), June 2006. (work in progress), March 2007.
[I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based
Interoperability Protocol(iMIP)", Interoperability Protocol(iMIP)",
draft-ietf-calsify-rfc2447bis-02 (work draft-ietf-calsify-rfc2447bis-03 (work
in progress), June 2006. in progress), February 2007.
[RFC2392] Levinson, E., "Content-ID and [RFC2392] Levinson, E., "Content-ID and
Message-ID Uniform Resource Locators", Message-ID Uniform Resource Locators",
RFC 2392, August 1998. RFC 2392, August 1998.
[RFC2425] Howes, T., Smith, M., and F. Dawson, [RFC2425] Howes, T., Smith, M., and F. Dawson,
"A MIME Content-Type for Directory "A MIME Content-Type for Directory
Information", RFC 2425, Information", RFC 2425,
September 1998. September 1998.
[RFC2426] Dawson, F. and T. Howes, "vCard MIME [RFC2426] Dawson, F. and T. Howes, "vCard MIME
Directory Profile", RFC 2426, Directory Profile", RFC 2426,
September 1998. September 1998.
[RFC4516] Smith, M. and T. Howes, "Lightweight [RFC4516] Smith, M. and T. Howes, "Lightweight
Directory Access Protocol (LDAP): Directory Access Protocol (LDAP):
Uniform Resource Locator", RFC 4516, Uniform Resource Locator", RFC 4516,
June 2006. June 2006.
[RFC4791] Daboo, C., Desruisseaux, B., and L.
Dusseault, "Calendaring Extensions to
WebDAV (CalDAV)", RFC 4791,
March 2007.
[TZDB] Eggert, P. and A. Olson, "Sources for [TZDB] Eggert, P. and A. Olson, "Sources for
Time Zone and Daylight Saving Time Time Zone and Daylight Saving Time
Data", January 2007, <http:// Data", January 2007, <http://
www.twinsun.com/tz/tz-link.htm>. www.twinsun.com/tz/tz-link.htm>.
[Note to RFC Editor: Change "A. Olson" [Note to RFC Editor: Change "A. Olson"
to "A.D. Olson".] to "A.D. Olson".]
[VCAL] Internet Mail Consortium, "vCalendar: [VCAL] Internet Mail Consortium, "vCalendar:
The Electronic Calendaring and The Electronic Calendaring and
Scheduling Exchange Format", Scheduling Exchange Format",
September 1996, September 1996,
<http://www.imc.org/pdi/vcal-10.txt>. <http://www.imc.org/pdi/vcal-10.txt>.
URIs URIs
[1] <mailto:ietf-calsify@osafoundation.org> [1] <mailto:ietf-calsify@osafoundation.org>
[2] <mailto:icalendar@ietf.org>
[3] <mailto:iana@iana.org>
Appendix A. Differences from RFC 2445 Appendix A. Differences from RFC 2445
This appendix contains a list of changes that have been made in the This appendix contains a list of changes that have been made in the
Internet Calendaring and Scheduling Core Object Specification from Internet Calendaring and Scheduling Core Object Specification from
RFC 2445. RFC 2445.
A.1. New restrictions A.1. New restrictions
1. The "DTSTART" property SHOULD match the pattern of the recurrence 1. The "DTSTART" property SHOULD be synchronized with the recurrence
rule, if specified. rule, if specified.
2. The "RRULE" property SHOULD NOT occur more than once in a 2. The "RRULE" property SHOULD NOT occur more than once in a
component. component.
A.2. Deprecated features 3. The BYHOUR, BYMINUTE and BYSECOND rule parts MUST NOT be
specified in the "RRULE" property when the "DTSTART" property is
specified as a DATE value.
4. The value type of the "DTEND" or "DUE" properties MUST match the
value type of "DTSTART" property.
A.2. Restrictions removed
1. The "DTSTART" and "DTEND" properties are no longer required to be
specified as date with local time and time zone reference when
used with a recurrence rule.
A.3. Deprecated features
1. The "EXRULE" property can no longer be specified in a component. 1. The "EXRULE" property can no longer be specified in a component.
2. The "RANGE" parameter can no longer be specified on the 2. The "RANGE" parameter can no longer be specified on the
"RECURRENCE-ID" property. "RECURRENCE-ID" property.
3. The "PROCEDURE" value can no longer be used with the "ACTION" 3. The "PROCEDURE" value can no longer be used with the "ACTION"
property. property.
4. x-name rule parts can no longer be specified in properties of
RECUR value type (e.g., RRULE). x-param can be used on RECUR
value type properties instead.
Appendix B. Change Log (to be removed by RFC Editor prior to Appendix B. Change Log (to be removed by RFC Editor prior to
publication) publication)
B.1. Changes in -06 B.1. Changes in -07
A detailed list of changes is available at the following page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
draft-ietf-calsify-rfc2445bis-07.changes.html.
a. Issue 8: Clarified how to compute the exact duration of a nominal
duration.
b. Issue 10: Added new examples for "VEVENT" and "VTODO" to
demonstrate that end times are always non-inclusive, that is,
even end times specified as DATE values.
c. Issue 11: Added a table that shows the dependency of BYxxx rule
part expand or limit behaviour on the FREQ value in the rule.
d. Issue 19: Removed section "Registration of Content Type
Elements". Added registration templates in IANA Considerations
section. Specified how applications should treat x-name and
x-token they don't recognize.
e. Issue 65: Removed 3rd recommended practice. Added new
requirements to require "DTEND" and "DUE" to be a local date time
if and only if "DTSTART" is a local date time.
f. Issue 68: Clarified handling of date-times that fall in time
discontinutities.
g. Issue 69: Clarified handling of recurrence instances that fall in
time discontinutities
h. Issue 71: Clarified handling of leap seconds.
i. Issue 75: Clarified that the "RDATE" property MUST be specified
as a local DATE-TIME value in "VTIMEZONE" sub-components.
j. Issue 76: Clarified that the value type of the "DTEND" property
MUST be the same as the "DTSTART" property.
k. Issue 77: Clarified that the value type of the "DUE" property
MUST be the same as the "DTSTART" property.
l. Issue 79: Clarified that "DTSTART" always specify an onset date-
time of an observance and that its value does not need to be
repeated in an "RDATE" property.
m. Issue 80: Rewrote Security Considerations section.
n. Issue 81: Clarified the meaning of "the set of events specified
by the rule" in the description of the BYSETPOS rule part.
o. Modified Abstract section.
p. Moved text of section 2.3 International Considerations at the end
of sectino 2.1 Formatting Conventions.
q. Added Internationalization Considerations section.
r. Modified the description of the following properties: "ATTACH",
"COMMENT", "COMPLETED", "CREATED" "DTSTAMP" "DUE", and "REPEAT".
s. Clarified some differences with ISO 8601.
t. Updated reference to CalDAV and ISO 8601.
u. Updated section "Differences from RFC 2445": added new
restrictions and added list of removed restrictions.
v. Numerous editorial changes.
B.2. Changes in -06
A detailed list of changes is available at the following page: A detailed list of changes is available at the following page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
draft-ietf-calsify-rfc2445bis-06.changes.html. draft-ietf-calsify-rfc2445bis-06.changes.html.
a. Issue 19: Defined new IANA registries. [Work in progress]; a. Issue 19: Defined new IANA registries. [Work in progress];
b. Issue 23: Clarified that the UNTIL rule part MUST specify a value b. Issue 23: Clarified that the UNTIL rule part MUST specify a value
of the same type as the value specified by "DTSTART"; of the same type as the value specified by "DTSTART";
skipping to change at page 166, line 42 skipping to change at page 172, line 4
q. Issue 78: Fixed the text to specify that "TZOFFSETFROM" and not q. Issue 78: Fixed the text to specify that "TZOFFSETFROM" and not
"TZOFFSETTO" must be used with "DTSTART" when generating the "TZOFFSETTO" must be used with "DTSTART" when generating the
onset date-time values from the "RRULE" in a "VTIMEZONE" onset date-time values from the "RRULE" in a "VTIMEZONE"
component; component;
r. Clarified that the "DTSTART" property MUST be specified in a r. Clarified that the "DTSTART" property MUST be specified in a
"VTODO" component when the "DURATION" property is specified; "VTODO" component when the "DURATION" property is specified;
s. Started to update the time zone information / examples; s. Started to update the time zone information / examples;
t. Numerous editorial changes. t. Numerous editorial changes.
B.2. Changes in -05 B.3. Changes in -05
A detailed list of changes is available at the following page: A detailed list of changes is available at the following page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
draft-ietf-calsify-rfc2445bis-05.changes.html. draft-ietf-calsify-rfc2445bis-05.changes.html.
a. Fixed ABNF with references in .txt version of the draft; a. Fixed ABNF with references in .txt version of the draft;
b. Numerous editorial changes; b. Numerous editorial changes;
c. Clarified that normative statements in ABNF comments should be c. Clarified that normative statements in ABNF comments should be
skipping to change at page 167, line 29 skipping to change at page 172, line 36
g. Changed the partstatparam ABNF rule for clarity; g. Changed the partstatparam ABNF rule for clarity;
h. Clarified the purpose of negative durations; h. Clarified the purpose of negative durations;
i. Added informational references to RFC 2392 (CID URL) and RFC 4516 i. Added informational references to RFC 2392 (CID URL) and RFC 4516
(LDAP URL). (LDAP URL).
j. Updated TZDB reference. j. Updated TZDB reference.
B.3. Changes in -04 B.4. Changes in -04
A detailed list of changes is available at the following page: A detailed list of changes is available at the following page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
draft-ietf-calsify-rfc2445bis-04.changes.html. draft-ietf-calsify-rfc2445bis-04.changes.html.
a. Issue 16: Clarified that recurrence instances, generated by a a. Issue 16: Clarified that recurrence instances, generated by a
recurrence rule, with an invalid date or nonexistent local time recurrence rule, with an invalid date or nonexistent local time
must be ignored and not counted as part of the recurrence set. must be ignored and not counted as part of the recurrence set.
b. Issue 26: Clarified how to handle the BYHOUR, BYMINUTE and b. Issue 26: Clarified how to handle the BYHOUR, BYMINUTE and
skipping to change at page 169, line 5 skipping to change at page 174, line 9
specified as a "dur-day" or "dur-week" value when the "DTSTART" specified as a "dur-day" or "dur-week" value when the "DTSTART"
is a DATE. is a DATE.
q. Issue 58: Changed the jourprop ABNF rule to allow the q. Issue 58: Changed the jourprop ABNF rule to allow the
"DESCRIPTION" property to occur more than once. "DESCRIPTION" property to occur more than once.
r. Numerous editorial changes. r. Numerous editorial changes.
s. Changed reference to RFC 4646 for Language-Tag. s. Changed reference to RFC 4646 for Language-Tag.
B.4. Changes in -03 B.5. Changes in -03
A detailed list of changes is available at the following page: A detailed list of changes is available at the following page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
draft-ietf-calsify-rfc2445bis-03.changes.html. draft-ietf-calsify-rfc2445bis-03.changes.html.
a. Numerous editorial changes. a. Numerous editorial changes.
b. Specified that "DTSTART" should match the pattern of "RRULE" and b. Specified that "DTSTART" should match the pattern of "RRULE" and
is always part of the "COUNT". is always part of the "COUNT".
skipping to change at page 169, line 27 skipping to change at page 174, line 31
components. components.
d. Deprecated "EXRULE". d. Deprecated "EXRULE".
e. Fixed all ABNF errors reported by Bill Fenner's ABNF parsing web e. Fixed all ABNF errors reported by Bill Fenner's ABNF parsing web
service available at: service available at:
http://rtg.ietf.org/~fenner/abnf.cgi. http://rtg.ietf.org/~fenner/abnf.cgi.
f. Changed reference to RFC 4648 for Base64 encoding. f. Changed reference to RFC 4648 for Base64 encoding.
B.5. Changes in -02 B.6. Changes in -02
A detailed list of changes is available at the following page: A detailed list of changes is available at the following page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
draft-ietf-calsify-rfc2445bis-02.changes.html. draft-ietf-calsify-rfc2445bis-02.changes.html.
a. Numerous editorial changes including the typos listed in the a. Numerous editorial changes including the typos listed in the
"RFC2445 Errata": "RFC2445 Errata":
http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445& http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2445&
and in the "RFC2445 Issues List": and in the "RFC2445 Issues List":
http://www.softwarestudio.org/iCal/2445Issues.html. http://www.softwarestudio.org/iCal/2445Issues.html.
skipping to change at page 170, line 13 skipping to change at page 175, line 15
g. Fixed all the examples to use RFC2606-compliant FQDNs. g. Fixed all the examples to use RFC2606-compliant FQDNs.
h. Fixed the Content-ID URLs in the examples. h. Fixed the Content-ID URLs in the examples.
i. Fixed the LDAP URLs in the examples. i. Fixed the LDAP URLs in the examples.
j. Moved multiple references in the Informative References section. j. Moved multiple references in the Informative References section.
k. Updated the Acknowledgments section. k. Updated the Acknowledgments section.
B.6. Changes in -01 B.7. Changes in -01
A detailed list of changes is available at the following page: A detailed list of changes is available at the following page:
http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/
draft-ietf-calsify-rfc2445bis-01.changes.html. draft-ietf-calsify-rfc2445bis-01.changes.html.
a. Numerous editorial changes (typos, errors in examples, etc.). a. Numerous editorial changes (typos, errors in examples, etc.).
b. Fixed invalid media types in examples. b. Fixed invalid media types in examples.
c. Fixed the "DTSTAMP" values in the examples. c. Fixed the "DTSTAMP" values in the examples.
skipping to change at page 170, line 37 skipping to change at page 175, line 39
e. Added Internationalization Considerations section. e. Added Internationalization Considerations section.
f. Added Security Considerations section. f. Added Security Considerations section.
g. Updated the Acknowledgments section. g. Updated the Acknowledgments section.
Appendix C. Open issues (to be removed by RFC Editor prior to Appendix C. Open issues (to be removed by RFC Editor prior to
publication) publication)
C.1. update_intro C.1. introduction
Type: edit
bernard.desruisseaux@oracle.com (2007-02-20): Update Introduction
section.
C.2. update_vtimezone_examples
Type: edit Type: edit
bernard.desruisseaux@oracle.com (2007-02-07): The time zone bernard.desruisseaux@oracle.com (2007-02-20): The Introduction
information for US/Eastern needs to be updated. section should be updated.
Resolution: Done.
C.3. #issue10+end_date_not_inclusive
Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2006-June/
000983.html>
reinhold@kainhofer.com (2006-06-03):
Resolution:
C.4. #issue61+ianaparam
Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/
001344.html>
bernard.desruisseaux@oracle.com (2006-11-05): All properties should
allow ianaparam the same way they allow xparam. All components
should allow iana-prop the same way they allow x-prop.
Resolution: Changed all ABNF accordingly.
C.5. #issue11+4.3.10_byxxx_rule_part_examples C.2. #issue11+4.3.10_byxxx_rule_part_examples
Type: change Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2006-June/ <http://lists.osafoundation.org/pipermail/ietf-calsify/2006-June/
000983.html> 000983.html>
reinhold@kainhofer.com (2006-06-03): We should add more BYXXX rule reinhold@kainhofer.com (2006-06-03): We should add more BYXXX rule
parts examples. parts examples.
Resolution: Resolution:
C.6. #issue75+4.6.5_rdate_format_in_vtimezone C.3. #issue63+4.8.5.3_rdate_and_dtstart
Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/
001490.html>
bernard.desruisseaux@oracle.com (2007-02-07): We need to clarify the
DATE-TIME format required for the "RDATE" property in "VTIMEZONE"
components.
Resolution: The "RDATE" property MUST be specified as a local DATE-
TIME value.
C.7. #issue79+4.6.5_dtstart_and_rdate_in_vtimezone
Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/
001525.html>
bernard.desruisseaux@oracle.com (2007-02-15): We need to clarify that
"DTSTART" always specify a onset date-time of an observance and that
its value does not need to be repeated in an "RDATE" property.
Resolution:
C.8. 4.8.1.1_attach_description_incomplete
Type: change
bernard.desruisseaux@oracle.com (2007-02-14): The description of the
"ATTACH" property is incomplete.
Resolution:
C.9. 4.8.1.4_comment_description_incomplete
Type: change
bernard.desruisseaux@oracle.com (2007-02-14): The description of the
"COMMENT" property is incomplete.
Resolution:
C.10. 4.8.2.1_completed_description_incomplete
Type: change
bernard.desruisseaux@oracle.com (2007-02-14): The description of the
"COMPLETED" property is incomplete.
Resolution:
C.11. #issue76+4.8.2.2_dtend_dtstart_value_type
Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/
001519.html>
bernard.desruisseaux@oracle.com (2007-02-13): We should clarify that
the value type of the "DTEND" property MUST be the same as the
"DTSTART" property
Resolution: Done.
C.12. #issue77+4.8.2.3_due_dtstart_value_type
Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/
001519.html>
bernard.desruisseaux@oracle.com (2007-02-13): We should clarify that
the value type of the "DUE" property MUST be the same as the
"DTSTART" property
Resolution: Done.
C.13. 4.8.2.3_due_description_incomplete
Type: change
bernard.desruisseaux@oracle.com (2007-02-14): The description of the
"DUE" property is incomplete.
Resolution:
C.14. #issue63+4.8.5.3_rdate_and_dtstart
Type: change Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/ <http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/
001349.html> 001349.html>
bernard.desruisseaux@oracle.com (2006-11-05): We need to clarify bernard.desruisseaux@oracle.com (2006-11-05): We need to clarify
whether RDATE can specify a value earlier in time than DTSTART. whether RDATE can specify a value earlier in time than DTSTART.
Resolution: Resolution:
C.15. 4.8.6.2_repeat_description_incomplete
Type: change
bernard.desruisseaux@oracle.com (2007-02-14): The description of the
"REPEAT" property is incomplete.
Resolution:
C.16. 4.8.7.1_created_description_incomplete
Type: change
bernard.desruisseaux@oracle.com (2007-02-14): The description of the
"CREATED" property is incomplete.
Resolution:
C.17. 4.8.7.2_dtstamp_description_incomplete
Type: change
bernard.desruisseaux@oracle.com (2007-02-14): The description of the
"DTSTAMP" property is incomplete.
Resolution:
C.18. #issue65+6_recommended_practices_tzid
Type: change
<http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/
001351.html>
bernard.desruisseaux@oracle.com (2006-11-05): We should clarify the
3rd recommendations to specify that DTSTART and DTEND/DUE of DATE-
TIME value type may be specified with different TZID parameter
values.
Resolution: Done.
C.19. add_i18n_section
Type: change
bernard.desruisseaux@oracle.com (2006-06-21): Add
Internationalization Considerations section.
C.20. #issue19+iana_considerations
Type: change
<>
lear@cisco.com (): The IANA Considerations sections needs to define
new registries and templates for new registrations.
Resolution:
Author's Address Author's Address
Bernard Desruisseaux (editor) Bernard Desruisseaux (editor)
Oracle Corporation Oracle Corporation
600 blvd. de Maisonneuve West 600 blvd. de Maisonneuve West
Suite 1900 Suite 1900
Montreal, QC H3A 3J2 Montreal, QC H3A 3J2
CANADA CANADA
EMail: bernard.desruisseaux@oracle.com EMail: bernard.desruisseaux@oracle.com
 End of changes. 224 change blocks. 
945 lines changed or deleted 923 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/