icalendar 0.95
Sign up to get free protection for your applications and to get access to all the features.
- data/COPYING +56 -0
- data/GPL +340 -0
- data/README +121 -0
- data/Rakefile +101 -0
- data/docs/api/classes/Array.html +146 -0
- data/docs/api/classes/Date.html +157 -0
- data/docs/api/classes/DateTime.html +178 -0
- data/docs/api/classes/Fixnum.html +146 -0
- data/docs/api/classes/Float.html +146 -0
- data/docs/api/classes/Icalendar/Alarm.html +184 -0
- data/docs/api/classes/Icalendar/Base.html +118 -0
- data/docs/api/classes/Icalendar/Calendar.html +411 -0
- data/docs/api/classes/Icalendar/Component.html +306 -0
- data/docs/api/classes/Icalendar/DateProp.html +187 -0
- data/docs/api/classes/Icalendar/DateProp/ClassMethods.html +195 -0
- data/docs/api/classes/Icalendar/Event.html +202 -0
- data/docs/api/classes/Icalendar/Freebusy.html +157 -0
- data/docs/api/classes/Icalendar/InvalidComponentClass.html +117 -0
- data/docs/api/classes/Icalendar/InvalidPropertyValue.html +117 -0
- data/docs/api/classes/Icalendar/Journal.html +190 -0
- data/docs/api/classes/Icalendar/Parameter.html +166 -0
- data/docs/api/classes/Icalendar/Parser.html +447 -0
- data/docs/api/classes/Icalendar/Timezone.html +197 -0
- data/docs/api/classes/Icalendar/Todo.html +199 -0
- data/docs/api/classes/String.html +160 -0
- data/docs/api/classes/Time.html +161 -0
- data/docs/api/created.rid +1 -0
- data/docs/api/files/COPYING.html +163 -0
- data/docs/api/files/GPL.html +531 -0
- data/docs/api/files/README.html +241 -0
- data/docs/api/files/lib/icalendar/base_rb.html +108 -0
- data/docs/api/files/lib/icalendar/calendar_rb.html +101 -0
- data/docs/api/files/lib/icalendar/component/alarm_rb.html +101 -0
- data/docs/api/files/lib/icalendar/component/event_rb.html +101 -0
- data/docs/api/files/lib/icalendar/component/freebusy_rb.html +101 -0
- data/docs/api/files/lib/icalendar/component/journal_rb.html +101 -0
- data/docs/api/files/lib/icalendar/component/timezone_rb.html +101 -0
- data/docs/api/files/lib/icalendar/component/todo_rb.html +101 -0
- data/docs/api/files/lib/icalendar/component_rb.html +101 -0
- data/docs/api/files/lib/icalendar/conversions_rb.html +108 -0
- data/docs/api/files/lib/icalendar/helpers_rb.html +101 -0
- data/docs/api/files/lib/icalendar/parameter_rb.html +101 -0
- data/docs/api/files/lib/icalendar/parser_rb.html +109 -0
- data/docs/api/files/lib/icalendar_rb.html +118 -0
- data/docs/api/fr_class_index.html +48 -0
- data/docs/api/fr_file_index.html +43 -0
- data/docs/api/fr_method_index.html +63 -0
- data/docs/api/index.html +24 -0
- data/docs/api/rdoc-style.css +208 -0
- data/docs/examples/create_cal.rb +40 -0
- data/docs/examples/parse_cal.rb +19 -0
- data/docs/examples/single_event.ics +18 -0
- data/docs/rfcs/rfc2425.pdf +0 -0
- data/docs/rfcs/rfc2426.pdf +0 -0
- data/docs/rfcs/rfc2445.pdf +0 -0
- data/docs/rfcs/rfc2446.pdf +0 -0
- data/docs/rfcs/rfc2447.pdf +0 -0
- data/docs/rfcs/rfc3283.txt +738 -0
- data/lib/icalendar.rb +27 -0
- data/lib/icalendar/#helpers.rb# +92 -0
- data/lib/icalendar/base.rb +31 -0
- data/lib/icalendar/calendar.rb +112 -0
- data/lib/icalendar/component.rb +253 -0
- data/lib/icalendar/component/alarm.rb +35 -0
- data/lib/icalendar/component/event.rb +68 -0
- data/lib/icalendar/component/freebusy.rb +35 -0
- data/lib/icalendar/component/journal.rb +61 -0
- data/lib/icalendar/component/timezone.rb +43 -0
- data/lib/icalendar/component/todo.rb +65 -0
- data/lib/icalendar/conversions.rb +115 -0
- data/lib/icalendar/helpers.rb +109 -0
- data/lib/icalendar/parameter.rb +33 -0
- data/lib/icalendar/parser.rb +395 -0
- data/test/calendar_test.rb +46 -0
- data/test/component/event_test.rb +47 -0
- data/test/component_test.rb +74 -0
- data/test/parser_test.rb +83 -0
- data/test/property_helpers.rb +35 -0
- data/test/simplecal.ics +119 -0
- data/test/single_event.ics +23 -0
- metadata +135 -0
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
## Need this so we can require the library from the samples directory
|
|
2
|
+
$:.unshift(File.dirname(__FILE__) + '/../../lib')
|
|
3
|
+
|
|
4
|
+
require 'icalendar'
|
|
5
|
+
require 'date'
|
|
6
|
+
|
|
7
|
+
# Create a calendar with a single event (Method 1)
|
|
8
|
+
cal = Icalendar::Calendar.new
|
|
9
|
+
event = Icalendar::Event.new
|
|
10
|
+
|
|
11
|
+
# Set some properties for this event
|
|
12
|
+
event.user_id = "joe-bob@somewhere.net"
|
|
13
|
+
event.timestamp = DateTime.now
|
|
14
|
+
event.start = Date.new(2005, 04, 29)
|
|
15
|
+
event.end = Date.new(2005, 04, 28)
|
|
16
|
+
event.summary = "Meeting with the man."
|
|
17
|
+
event.klass = "PRIVATE"
|
|
18
|
+
|
|
19
|
+
# Now add it to the calendar
|
|
20
|
+
cal.add event
|
|
21
|
+
|
|
22
|
+
# Create a calendar with a single event (Method 2)
|
|
23
|
+
cal2 = Icalendar::Calendar.new
|
|
24
|
+
event = cal.event # This automatically adds the event to the calendar
|
|
25
|
+
event.user_id = "joe-bob@somewhere.net"
|
|
26
|
+
event.timestamp = DateTime.now
|
|
27
|
+
|
|
28
|
+
# Create a calendar with a single event (Method 3)
|
|
29
|
+
cal3 = Icalendar::Calendar.new
|
|
30
|
+
cal3.event do
|
|
31
|
+
user_id "joe-bob@somewhere.net"
|
|
32
|
+
event.timestamp DateTime.now
|
|
33
|
+
end
|
|
34
|
+
|
|
35
|
+
# We can output the calendars as strings to write to a file,
|
|
36
|
+
# network port, database etc.
|
|
37
|
+
cal_string = cal.to_ical
|
|
38
|
+
puts cal_string
|
|
39
|
+
|
|
40
|
+
#:startdoc:
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
## Need this so we can require the library from the samples directory
|
|
2
|
+
$:.unshift(File.dirname(__FILE__) + '/../../lib')
|
|
3
|
+
|
|
4
|
+
require 'icalendar'
|
|
5
|
+
require 'date'
|
|
6
|
+
|
|
7
|
+
# Open a file or string to parse
|
|
8
|
+
cal_file = File.open("single_event.ics")
|
|
9
|
+
|
|
10
|
+
# Parser returns an array of calendars because a single file
|
|
11
|
+
# can have multiple calendar objects.
|
|
12
|
+
cals = Icalendar::Parser.new(cal_file).parse
|
|
13
|
+
cal = cals.first
|
|
14
|
+
|
|
15
|
+
# Now you can access the cal object in just the same way I created it
|
|
16
|
+
event = cal.events.first
|
|
17
|
+
|
|
18
|
+
puts "user_id: " + event.user_id
|
|
19
|
+
puts "summary: " + event.summary
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
BEGIN:VCALENDAR
|
|
2
|
+
VERSION:2.0
|
|
3
|
+
PRODID:bsprodidfortestabc123
|
|
4
|
+
BEGIN:VEVENT
|
|
5
|
+
UID:bsuidfortestabc123
|
|
6
|
+
SUMMARY:This is a really long summary
|
|
7
|
+
to test the method of unfolding lines
|
|
8
|
+
so I'm just going to ma
|
|
9
|
+
ke it
|
|
10
|
+
a whol
|
|
11
|
+
e
|
|
12
|
+
bunch of lines.
|
|
13
|
+
CLASS:PRIVATE
|
|
14
|
+
DTSTART;TZID=US-Mountain:20050120T170000
|
|
15
|
+
DTEND:20050120T184500
|
|
16
|
+
DTSTAMP:20050118T211523Z
|
|
17
|
+
END:VEVENT
|
|
18
|
+
END:VCALENDAR
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
Binary file
|
|
@@ -0,0 +1,738 @@
|
|
|
1
|
+
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
|
|
2
|
+
<HTML>
|
|
3
|
+
<HEAD>
|
|
4
|
+
<TITLE>RFC 3283 (rfc3283) - Guide to Internet Calendaring</TITLE>
|
|
5
|
+
<META name="description" content="RFC 3283 - Guide to Internet Calendaring">
|
|
6
|
+
<script language="JavaScript1.2">
|
|
7
|
+
function erfc(s)
|
|
8
|
+
{document.write("<A href=\"/rfccomment.php?rfcnum="+s+"\" target=\"_blank\" onclick=\"window.open('/rfccomment.php?rfcnum="+s+"','Popup','toolbar=no,location=no,status=no,menubar=no,scrollbars=yes,resizable=yes,width=680,height=530,left=30,top=43'); return false;\")>Comment on RFC "+s+"</A>\n");}
|
|
9
|
+
//-->
|
|
10
|
+
</script>
|
|
11
|
+
</HEAD>
|
|
12
|
+
<BODY BGCOLOR="#ffffff" TEXT="#000000">
|
|
13
|
+
<P ALIGN=CENTER><IMG SRC="/images/library.jpg" HEIGHT=62 WIDTH=150 BORDER="0" ALIGN="MIDDLE" ALT=""></P>
|
|
14
|
+
<H1 ALIGN=CENTER>RFC 3283 (RFC3283)</H1>
|
|
15
|
+
<P ALIGN=CENTER>Internet RFC/STD/FYI/BCP Archives</P>
|
|
16
|
+
|
|
17
|
+
<DIV ALIGN=CENTER>[ <a href="/rfcs/">RFC Index</a> | <A HREF="/rfcs/rfcsearch.html">RFC Search</A> | <a href="/faqs/">Usenet FAQs</a> | <a href="/contrib/">Web FAQs</a> | <a href="/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]
|
|
18
|
+
<P>
|
|
19
|
+
<STRONG>Alternate Formats:</STRONG>
|
|
20
|
+
<A HREF="/ftp/rfc/rfc3283.txt">rfc3283.txt</A></DIV>
|
|
21
|
+
<p align=center><script language="JavaScript"><!--
|
|
22
|
+
erfc("3283");
|
|
23
|
+
// --></script></p>
|
|
24
|
+
<h3 align=center>RFC 3283 - Guide to Internet Calendaring</h3>
|
|
25
|
+
<HR SIZE=2 NOSHADE>
|
|
26
|
+
<PRE>
|
|
27
|
+
|
|
28
|
+
Network Working Group B. Mahoney
|
|
29
|
+
Request for Comments: 3283 MIT
|
|
30
|
+
Category: Informational G. Babics
|
|
31
|
+
Steltor
|
|
32
|
+
A. Taler
|
|
33
|
+
June 2002
|
|
34
|
+
|
|
35
|
+
Guide to Internet Calendaring
|
|
36
|
+
|
|
37
|
+
Status of this Memo
|
|
38
|
+
|
|
39
|
+
This memo provides information for the Internet community. It does
|
|
40
|
+
not specify an Internet standard of any kind. Distribution of this
|
|
41
|
+
memo is unlimited.
|
|
42
|
+
|
|
43
|
+
Copyright Notice
|
|
44
|
+
|
|
45
|
+
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|
46
|
+
|
|
47
|
+
Abstract
|
|
48
|
+
|
|
49
|
+
This document describes the various Internet calendaring and
|
|
50
|
+
scheduling standards and works in progress, and the relationships
|
|
51
|
+
between them. Its intent is to provide a context for these
|
|
52
|
+
documents, assist in their understanding, and potentially aid in the
|
|
53
|
+
design of standards-based calendaring and scheduling systems. The
|
|
54
|
+
standards addressed are <A HREF="/rfcs/rfc2445.html">RFC 2445</A> (iCalendar), <A HREF="/rfcs/rfc2446.html">RFC 2446</A> (iTIP), and
|
|
55
|
+
<A HREF="/rfcs/rfc2447.html">RFC 2447</A> (iMIP). The work in progress addressed is "Calendar Access
|
|
56
|
+
Protocol" (CAP). This document also describes issues and problems
|
|
57
|
+
that are not solved by these protocols, and that could be targets for
|
|
58
|
+
future work.
|
|
59
|
+
|
|
60
|
+
Table of Contents
|
|
61
|
+
|
|
62
|
+
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
|
|
63
|
+
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
|
|
64
|
+
1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 4
|
|
65
|
+
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
|
|
66
|
+
2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 4
|
|
67
|
+
2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 5
|
|
68
|
+
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
|
69
|
+
3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
|
70
|
+
3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
|
71
|
+
3.2.1 Standalone Single-user System . . . . . . . . . . . . . . . 8
|
|
72
|
+
3.2.2 Single-user Systems Communicating . . . . . . . . . . . . . 8
|
|
73
|
+
3.2.3 Single-user with Multiple CUAs . . . . . . . . . . . . . . . 9
|
|
74
|
+
3.2.4 Single-user with Multiple Calendars . . . . . . . . . . . . 9
|
|
75
|
+
|
|
76
|
+
3.2.5 Users Communicating on a Multi-user System . . . . . . . . . 10
|
|
77
|
+
3.2.6 Users Communicating through Different Multi-user Systems . . 10
|
|
78
|
+
4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 10
|
|
79
|
+
4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
|
80
|
+
4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 11
|
|
81
|
+
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
|
82
|
+
4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 11
|
|
83
|
+
4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 11
|
|
84
|
+
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 11
|
|
85
|
+
5.1 Scheduling People, not Calendars . . . . . . . . . . . . . . 12
|
|
86
|
+
5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 12
|
|
87
|
+
5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 12
|
|
88
|
+
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
|
|
89
|
+
6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 12
|
|
90
|
+
6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 12
|
|
91
|
+
6.3 Using E-mail . . . . . . . . . . . . . . . . . . . . . . . . 13
|
|
92
|
+
6.4 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 13
|
|
93
|
+
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
|
|
94
|
+
References . . . . . . . . . . . . . . . . . . . . . . . . . 14
|
|
95
|
+
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
|
|
96
|
+
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
|
|
97
|
+
|
|
98
|
+
1. Introduction
|
|
99
|
+
|
|
100
|
+
Calendaring and scheduling protocols are intended to aid individuals
|
|
101
|
+
in obtaining calendaring information and scheduling meetings across
|
|
102
|
+
the Internet, to aid organizations in providing calendaring
|
|
103
|
+
information on the Internet, and to provide for organizations looking
|
|
104
|
+
for a calendaring and scheduling solution to deploy internally.
|
|
105
|
+
|
|
106
|
+
It is the intent of this document to provide a context for these
|
|
107
|
+
documents, assist in their understanding, and potentially help in the
|
|
108
|
+
design of standards-based calendaring and scheduling systems.
|
|
109
|
+
|
|
110
|
+
Problems not solved by these protocols, as well as security issues to
|
|
111
|
+
be kept in mind, are discussed at the end of the document.
|
|
112
|
+
|
|
113
|
+
1.1 Terminology
|
|
114
|
+
|
|
115
|
+
This memo uses much of the same terminology as iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>],
|
|
116
|
+
iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>], iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>], and [CAP]. The following
|
|
117
|
+
definitions are provided as an introduction; the definitions in the
|
|
118
|
+
protocol specifications themselves should be considered canonical.
|
|
119
|
+
|
|
120
|
+
Calendar
|
|
121
|
+
|
|
122
|
+
A collection of events, to-dos, journal entries, etc. A calendar
|
|
123
|
+
could be the content of a person or resource's agenda; it could
|
|
124
|
+
also be a collection of data serving a more specialized need.
|
|
125
|
+
Calendars are the basic storage containers for calendaring
|
|
126
|
+
information.
|
|
127
|
+
|
|
128
|
+
Calendar Access Rights
|
|
129
|
+
|
|
130
|
+
A set of rules defining who may perform what operations, such as
|
|
131
|
+
reading or writing information, on a given calendar.
|
|
132
|
+
|
|
133
|
+
Calendar Service
|
|
134
|
+
|
|
135
|
+
A running server application that provides access to a number of
|
|
136
|
+
calendar stores.
|
|
137
|
+
|
|
138
|
+
Calendar Store (CS)
|
|
139
|
+
|
|
140
|
+
A data store of a calendar service. A calendar service may have
|
|
141
|
+
several calendar stores, and each store may contain several
|
|
142
|
+
calendars, as well as properties and components outside of those
|
|
143
|
+
calendars.
|
|
144
|
+
|
|
145
|
+
Calendar User (CU)
|
|
146
|
+
|
|
147
|
+
An entity (often a human) that accesses calendar information.
|
|
148
|
+
|
|
149
|
+
Calendar User Agent (CUA)
|
|
150
|
+
|
|
151
|
+
Software with which the calendar user communicates with a calendar
|
|
152
|
+
service or local calendar store to access calendar information.
|
|
153
|
+
|
|
154
|
+
Component
|
|
155
|
+
|
|
156
|
+
A piece of calendar data such as an event, a to-do or an alarm.
|
|
157
|
+
Information about components is stored as properties of those
|
|
158
|
+
components.
|
|
159
|
+
|
|
160
|
+
Delegator
|
|
161
|
+
|
|
162
|
+
A calendar user who has assigned his or her participation in a
|
|
163
|
+
scheduled calendar component (e.g. a VEVENT) to another calendar
|
|
164
|
+
user (sometimes called the delegate or delegatee). An example of
|
|
165
|
+
a delegator is a busy executive sending an employee to a meeting
|
|
166
|
+
in his or her place.
|
|
167
|
+
|
|
168
|
+
Delegate
|
|
169
|
+
|
|
170
|
+
A calendar user (sometimes called the delegatee) who has been
|
|
171
|
+
assigned to participate in a scheduled calendar component (e.g. a
|
|
172
|
+
VEVENT) in place of one of the attendees in that component
|
|
173
|
+
(sometimes called the delegator). An example of a delegate is a
|
|
174
|
+
team member sent to a particular meeting.
|
|
175
|
+
|
|
176
|
+
Designate
|
|
177
|
+
|
|
178
|
+
A calendar user authorized to act on behalf of another calendar
|
|
179
|
+
user. An example of a designate is an assistant scheduling
|
|
180
|
+
meetings for his or her superior.
|
|
181
|
+
|
|
182
|
+
Local Store
|
|
183
|
+
|
|
184
|
+
A CS that is on the same device as the CUA.
|
|
185
|
+
|
|
186
|
+
Property
|
|
187
|
+
|
|
188
|
+
A description of some element of a component, such as a start
|
|
189
|
+
time, title or location.
|
|
190
|
+
|
|
191
|
+
Remote Store
|
|
192
|
+
|
|
193
|
+
A CS that is not on the same device as the CUA.
|
|
194
|
+
|
|
195
|
+
1.2 Concepts and Relationships
|
|
196
|
+
|
|
197
|
+
iCalendar is the language used to describe calendar objects. iTIP
|
|
198
|
+
describes a way to use the iCalendar language to do scheduling. iMIP
|
|
199
|
+
describes how to do iTIP scheduling via e-mail. CAP describes a way
|
|
200
|
+
to use the iCalendar language to access a calendar store in real-
|
|
201
|
+
time.
|
|
202
|
+
|
|
203
|
+
The relationship between calendaring protocols is similar to that
|
|
204
|
+
between e-mail protocols. In those terms, iCalendar is analogous to
|
|
205
|
+
<A HREF="/rfcs/rfc2822.html">RFC 2822</A>, iTIP and iMIP are analogous to the Simple Mail Transfer
|
|
206
|
+
Protocol (SMTP), and CAP is analogous to the Post Office Protocol
|
|
207
|
+
(POP) or Internet Message Access Protocol (IMAP).
|
|
208
|
+
|
|
209
|
+
2. Requirements
|
|
210
|
+
|
|
211
|
+
2.1 Fundamental Needs
|
|
212
|
+
|
|
213
|
+
The following scenarios illustrate people and organizations' basic
|
|
214
|
+
calendaring and scheduling needs:
|
|
215
|
+
|
|
216
|
+
a] A doctor wishes to keep track of all her appointments.
|
|
217
|
+
|
|
218
|
+
Need: To read and manipulate one's own calendar with only one CUA.
|
|
219
|
+
|
|
220
|
+
b] A busy musician wants to maintain her schedule with multiple
|
|
221
|
+
devices, such as through an Internet-based agenda and with a PDA.
|
|
222
|
+
|
|
223
|
+
Need: To read and manipulate one's own calendar, possibly with
|
|
224
|
+
solutions from different vendors.
|
|
225
|
+
|
|
226
|
+
c] A software development team wishes to more effectively schedule
|
|
227
|
+
their time through viewing each other's calendar information.
|
|
228
|
+
|
|
229
|
+
Need: To share calendar information between users of the same
|
|
230
|
+
calendar service.
|
|
231
|
+
|
|
232
|
+
d] A teacher wants his students to schedule appointments during
|
|
233
|
+
his office hours.
|
|
234
|
+
|
|
235
|
+
Need: To schedule calendar events, to-dos and journals with other
|
|
236
|
+
users of the same calendar service.
|
|
237
|
+
|
|
238
|
+
e] A movie theater wants to publish its schedule for prospective
|
|
239
|
+
customers.
|
|
240
|
+
|
|
241
|
+
Need: To share calendar information with users of other calendar
|
|
242
|
+
services, possibly from a number of different vendors.
|
|
243
|
+
|
|
244
|
+
f] A social club wants to schedule calendar entries effectively
|
|
245
|
+
with its members.
|
|
246
|
+
|
|
247
|
+
Need: To schedule calendar events and to-dos with users of other
|
|
248
|
+
calendar services, possibly from a number of different vendors.
|
|
249
|
+
|
|
250
|
+
2.2 Protocol Requirements
|
|
251
|
+
|
|
252
|
+
Some of these needs can be met by proprietary solutions (a, c, d),
|
|
253
|
+
but others can not (b, e, f). These latter scenarios show that
|
|
254
|
+
standard protocols are required for accessing information in a
|
|
255
|
+
calendar store and scheduling calendar entries. In addition, these
|
|
256
|
+
protocols require a common data format for representing calendar
|
|
257
|
+
information.
|
|
258
|
+
|
|
259
|
+
These requirements are met by the following protocol specifications.
|
|
260
|
+
|
|
261
|
+
- Data format: iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>]
|
|
262
|
+
|
|
263
|
+
iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] provides a data format for representing
|
|
264
|
+
calendar information, to be used and exchanged by other protocols.
|
|
265
|
+
iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] can also be used in other contexts, such as a
|
|
266
|
+
drag-and-drop interface, or an export/import feature. All the
|
|
267
|
+
other calendaring protocols depend on iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>], so all
|
|
268
|
+
elements of a standards-based calendaring and scheduling systems
|
|
269
|
+
will have to be able to interpret iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>].
|
|
270
|
+
|
|
271
|
+
- Scheduling protocol: iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>]
|
|
272
|
+
|
|
273
|
+
iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] describes the messages used to schedule calendar
|
|
274
|
+
events. Within iTIP messages, events are represented in iCalendar
|
|
275
|
+
[<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] format, and have semantics that identify the message as
|
|
276
|
+
being an invitation to a meeting, an acceptance of an invitation,
|
|
277
|
+
or the assignment of a task.
|
|
278
|
+
|
|
279
|
+
iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] messages are used in the scheduling workflow,
|
|
280
|
+
where users exchange messages in order to organize things such as
|
|
281
|
+
events and to-dos. CUAs generate and interpret iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>]
|
|
282
|
+
messages at the direction of the calendar user. With iTIP [RFC-
|
|
283
|
+
2446] users can create, modify, delete, reply to, counter, and
|
|
284
|
+
decline counters to the various iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] components.
|
|
285
|
+
Furthermore, users can also request the free/busy time of other
|
|
286
|
+
people.
|
|
287
|
+
|
|
288
|
+
iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] is transport-independent, and has one specified
|
|
289
|
+
transport binding: iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>] binds iTIP to e-mail. In
|
|
290
|
+
addition [CAP] will provide a real-time binding of iTIP [RFC-
|
|
291
|
+
2446], allowing CUAs to perform calendar management and scheduling
|
|
292
|
+
over a single connection.
|
|
293
|
+
|
|
294
|
+
- Calendar management protocol: [CAP]
|
|
295
|
+
|
|
296
|
+
[CAP] describes the messages used to manage calendars on a
|
|
297
|
+
calendar store. These messages use iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] to
|
|
298
|
+
describe various components such as events and to-dos. These
|
|
299
|
+
messages make it possible to perform iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] operations,
|
|
300
|
+
as well as other operations relating to a calendar store such as
|
|
301
|
+
searching, creating calendars, specifying calendar properties, and
|
|
302
|
+
specifying calendar access rights.
|
|
303
|
+
|
|
304
|
+
3. Solutions
|
|
305
|
+
|
|
306
|
+
3.1 Examples
|
|
307
|
+
|
|
308
|
+
Returning to the scenarios presented in section 2.1, the calendaring
|
|
309
|
+
protocols can be used in the following ways:
|
|
310
|
+
|
|
311
|
+
a] The doctor can use a proprietary CUA with a local store, and
|
|
312
|
+
perhaps use iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] as a storage mechanism. This
|
|
313
|
+
would allow her to easily import her data store into another
|
|
314
|
+
application that supports iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>].
|
|
315
|
+
|
|
316
|
+
b] The musician who wishes to access her agenda from anywhere can
|
|
317
|
+
use a [CAP]-enabled calendar service accessible over the Internet.
|
|
318
|
+
She can then use any available [CAP] clients to access the data.
|
|
319
|
+
|
|
320
|
+
A proprietary system that provides access through a Web-based
|
|
321
|
+
interface could also be employed, but the use of [CAP] would be
|
|
322
|
+
superior in that it would allow the use of third party
|
|
323
|
+
applications, such as PDA synchronization tools.
|
|
324
|
+
|
|
325
|
+
c] The development team can use a calendar service which supports
|
|
326
|
+
[CAP], and each member can use a [CAP]-enabled CUA of their
|
|
327
|
+
choice.
|
|
328
|
+
|
|
329
|
+
Alternatively, each member could use an iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>]-enabled
|
|
330
|
+
CUA, and they could book meetings over e-mail. This solution has
|
|
331
|
+
the drawback that it is difficult to examine other users' agendas,
|
|
332
|
+
making the organization of meetings more difficult.
|
|
333
|
+
|
|
334
|
+
Proprietary solutions are also available, but they require that
|
|
335
|
+
all members use clients by the same vendor, and disallow the use
|
|
336
|
+
of third party applications.
|
|
337
|
+
|
|
338
|
+
d] The teacher can set up a calendar service, and have students
|
|
339
|
+
book time through any of the iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] bindings. [CAP]
|
|
340
|
+
provides real-time access, but could require additional
|
|
341
|
+
configuration. iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>] would be the easiest to configure,
|
|
342
|
+
but may require more e-mail processing.
|
|
343
|
+
|
|
344
|
+
If [CAP] access is provided then determining the state of the
|
|
345
|
+
teacher's schedule is straightforward. If not, this can be
|
|
346
|
+
determined through iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] free/busy requests. Non-
|
|
347
|
+
standard methods could also be employed, such as serving up
|
|
348
|
+
iCalendar [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>], HTML, or XML over HTTP.
|
|
349
|
+
|
|
350
|
+
A proprietary system could also be used, but would require that
|
|
351
|
+
all students be able to use software from a specific vendor.
|
|
352
|
+
|
|
353
|
+
e] [CAP] would be preferred for publishing a movie theater's
|
|
354
|
+
schedule, since it provides advanced access and search
|
|
355
|
+
capabilities. It also allows easy integration with customers'
|
|
356
|
+
calendar systems.
|
|
357
|
+
|
|
358
|
+
Non-standard methods such as serving data over HTTP could also be
|
|
359
|
+
employed, but would be harder to integrate with customers'
|
|
360
|
+
systems.
|
|
361
|
+
|
|
362
|
+
Using a completely proprietary solution would be very difficult,
|
|
363
|
+
if not impossible, since it would require every user to install
|
|
364
|
+
and use the proprietary software.
|
|
365
|
+
|
|
366
|
+
f] The social club could distribute meeting information in the
|
|
367
|
+
form of iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] messages, sent via e-mail using iMIP
|
|
368
|
+
[<A HREF="/rfcs/rfc2447.html">RFC-2447</A>]. The club could distribute meeting invitations, as
|
|
369
|
+
well as a full published agenda.
|
|
370
|
+
|
|
371
|
+
Alternatively, the club could provide access to a [CAP]-enabled
|
|
372
|
+
calendar service. However, this solution would be more expensive
|
|
373
|
+
since it requires the maintenance of a server.
|
|
374
|
+
|
|
375
|
+
3.2 Systems
|
|
376
|
+
|
|
377
|
+
The following diagrams illustrate possible systems and their usage of
|
|
378
|
+
the various protocols.
|
|
379
|
+
|
|
380
|
+
3.2.1 Standalone Single-user System
|
|
381
|
+
|
|
382
|
+
A single user system that does not communicate with other systems
|
|
383
|
+
need not employ any of the protocols. However, it may use iCalendar
|
|
384
|
+
[<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] as a data format in some places.
|
|
385
|
+
|
|
386
|
+
----------- O
|
|
387
|
+
| CUA w/ | -+- user
|
|
388
|
+
|local store| A
|
|
389
|
+
----------- / \
|
|
390
|
+
|
|
391
|
+
3.2.2 Single-user Systems Communicating
|
|
392
|
+
|
|
393
|
+
Users with single-user systems may schedule meetings with each others
|
|
394
|
+
using iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>]. The easiest binding of iTIP [<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] to use
|
|
395
|
+
would be iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>], since messages can be held in the users'
|
|
396
|
+
mail queues, which we assume to already exist. [CAP] could also be
|
|
397
|
+
used.
|
|
398
|
+
|
|
399
|
+
O ----------- ----------- O
|
|
400
|
+
-+- | CUA w/ | -----[iMIP]----- | CUA w/ | -+- user
|
|
401
|
+
A |local store| Internet |local store| A
|
|
402
|
+
/ \ ----------- ----------- / \
|
|
403
|
+
|
|
404
|
+
3.2.3 Single-user with Multiple CUAs
|
|
405
|
+
|
|
406
|
+
A single user may use more than one CUA to access his or her
|
|
407
|
+
calendar. The user may use a PDA, a Web client, a PC, or some other
|
|
408
|
+
device, depending on accessibility. Some of these clients may have
|
|
409
|
+
local stores and others may not. Those with local stores need to
|
|
410
|
+
synchronize the data on the CUA with the data on the CS.
|
|
411
|
+
|
|
412
|
+
-----------
|
|
413
|
+
| CUA w | -----[CAP]----------+
|
|
414
|
+
|local store| |
|
|
415
|
+
O ----------- ----------
|
|
416
|
+
-+- | CS |
|
|
417
|
+
A | |
|
|
418
|
+
/ \ ----------
|
|
419
|
+
----------- |
|
|
420
|
+
| CUA w/o | -----[CAP]----------+
|
|
421
|
+
|local store|
|
|
422
|
+
-----------
|
|
423
|
+
|
|
424
|
+
3.2.4 Single-user with Multiple Calendars
|
|
425
|
+
|
|
426
|
+
A single user may have many independent calendars; for example, one
|
|
427
|
+
may contain work-related information and another personal
|
|
428
|
+
information. The CUA may or may not have a local store. If it does,
|
|
429
|
+
then it needs to synchronize the data of the CUA with the data on
|
|
430
|
+
both of the CS.
|
|
431
|
+
|
|
432
|
+
----------
|
|
433
|
+
+------------[CAP]------ | CS |
|
|
434
|
+
| | |
|
|
435
|
+
O ----------- ----------
|
|
436
|
+
-+- | CUA |
|
|
437
|
+
A | |
|
|
438
|
+
/ \ -----------
|
|
439
|
+
| ----------
|
|
440
|
+
+------------[CAP]------ | CS |
|
|
441
|
+
| |
|
|
442
|
+
----------
|
|
443
|
+
|
|
444
|
+
3.2.5 Users Communicating on a Multi-user System
|
|
445
|
+
|
|
446
|
+
Users on a multi-user system may schedule meetings with each other
|
|
447
|
+
using [CAP]-enabled CUAs and services. The CUAs may or may not have
|
|
448
|
+
local stores. Those with local stores need to synchronize the data
|
|
449
|
+
on the CUAs with the data on the CS.
|
|
450
|
+
|
|
451
|
+
O -----------
|
|
452
|
+
-+- | CUA w | -----[CAP]----------+
|
|
453
|
+
A |local store| |
|
|
454
|
+
/ \ ----------- ----------
|
|
455
|
+
| CS |
|
|
456
|
+
| |
|
|
457
|
+
----------
|
|
458
|
+
O ----------- |
|
|
459
|
+
-+- | CUA w/o | -----[CAP]----------+
|
|
460
|
+
A |local store|
|
|
461
|
+
/ \ -----------
|
|
462
|
+
|
|
463
|
+
3.2.6 Users Communicating through Different Multi-user Systems
|
|
464
|
+
|
|
465
|
+
Users on a multi-user system may need to schedule meetings with users
|
|
466
|
+
on a different multi-user system. The services can communicate using
|
|
467
|
+
[CAP] or iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>].
|
|
468
|
+
|
|
469
|
+
O ----------- ----------
|
|
470
|
+
-+- | CUA w | -----[CAP]-------| CS |
|
|
471
|
+
A |local store| | |
|
|
472
|
+
/ \ ----------- ----------
|
|
473
|
+
|
|
|
474
|
+
[CAP] or [iMIP]
|
|
475
|
+
|
|
|
476
|
+
O ----------- ----------
|
|
477
|
+
-+- | CUA w/o | -----[CAP]-------| CS |
|
|
478
|
+
A |local store| | |
|
|
479
|
+
/ \ ----------- ----------
|
|
480
|
+
|
|
481
|
+
4. Important Aspects
|
|
482
|
+
|
|
483
|
+
There are a number of important aspects of these calendaring
|
|
484
|
+
standards of which people, especially implementers, should be aware.
|
|
485
|
+
|
|
486
|
+
4.1 Timezones
|
|
487
|
+
|
|
488
|
+
The dates and times in components can refer to a specific time zone.
|
|
489
|
+
Time zones can be defined in a central store, or they may be defined
|
|
490
|
+
by a user to fit his or her needs. All users and applications should
|
|
491
|
+
be aware of time zones and time zone differences. New time zones may
|
|
492
|
+
|
|
493
|
+
need to be added, and others removed. Two different vendors may
|
|
494
|
+
describe the same time zone differently (such as by using a different
|
|
495
|
+
name).
|
|
496
|
+
|
|
497
|
+
4.2 Choice of Transport
|
|
498
|
+
|
|
499
|
+
There are issues to be aware of in choosing between a network
|
|
500
|
+
protocol such as [CAP], or a store and forward protocol, such as iMIP
|
|
501
|
+
[<A HREF="/rfcs/rfc2447.html">RFC-2447</A>].
|
|
502
|
+
|
|
503
|
+
The use of a network ("on-the-wire") mechanism may require some
|
|
504
|
+
organizations to make provisions to allow calendaring traffic to
|
|
505
|
+
traverse a corporate firewall on the required ports. Depending on
|
|
506
|
+
the organizational culture, this may be a challenging social
|
|
507
|
+
exercise.
|
|
508
|
+
|
|
509
|
+
The use of an email-based mechanism exposes time-sensitive data to
|
|
510
|
+
unbounded latency. Large or heavily utilized mail systems may
|
|
511
|
+
experience an unacceptable delay in message receipt.
|
|
512
|
+
|
|
513
|
+
4.3 Security
|
|
514
|
+
|
|
515
|
+
See the "Security Considerations" (Section 6) section below.
|
|
516
|
+
|
|
517
|
+
4.4 Amount of data
|
|
518
|
+
|
|
519
|
+
In some cases, a component may be very large, for instance, a
|
|
520
|
+
component with a very large attachment. Some applications may be
|
|
521
|
+
low-bandwidth or may be limited in the amount of data they can store.
|
|
522
|
+
Maximum component size may be set in [CAP]. It can also be
|
|
523
|
+
controlled in iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>] by restricting the maximum size of the
|
|
524
|
+
e-mail that the application can download.
|
|
525
|
+
|
|
526
|
+
4.5 Recurring Components
|
|
527
|
+
|
|
528
|
+
In iCAL [<A HREF="/rfcs/rfc2445.html">RFC-2445</A>], one can specify complex recurrence rules for
|
|
529
|
+
VEVENTs, VTODOs, and VJOURNALs. One must be careful to correctly
|
|
530
|
+
interpret these recurrence rules and pay extra attention to being
|
|
531
|
+
able to interoperate using them.
|
|
532
|
+
|
|
533
|
+
5. Open Issues
|
|
534
|
+
|
|
535
|
+
Many issues are not currently resolved by these protocols, and many
|
|
536
|
+
desirable features are not yet provided. Some of the more prominent
|
|
537
|
+
ones are outlined below.
|
|
538
|
+
|
|
539
|
+
5.1 Scheduling People, not Calendars
|
|
540
|
+
|
|
541
|
+
Meetings are scheduled with people; however, people may have many
|
|
542
|
+
calendars, and may store these calendars in many places. There may
|
|
543
|
+
also be many routes to contact them. The calendaring protocols do
|
|
544
|
+
not attempt to provide unique access for contacting a given person.
|
|
545
|
+
Instead, 'calendar addresses' are booked, which may be e-mail
|
|
546
|
+
addresses or individual calendars. It is up to the users themselves
|
|
547
|
+
to orchestrate mechanisms to ensure that the bookings go to the right
|
|
548
|
+
place.
|
|
549
|
+
|
|
550
|
+
5.2 Administration
|
|
551
|
+
|
|
552
|
+
The calendaring protocols do not address the issues of administering
|
|
553
|
+
users and calendars on a calendar service. This must be handled by
|
|
554
|
+
proprietary mechanisms for each implementation.
|
|
555
|
+
|
|
556
|
+
5.3 Notification
|
|
557
|
+
|
|
558
|
+
People often wish to be notified of upcoming events, new events, or
|
|
559
|
+
changes to existing events. The calendaring protocols do not attempt
|
|
560
|
+
to address these needs in a real-time system. Instead, the ability
|
|
561
|
+
to store alarm information on events is provided, which can be used
|
|
562
|
+
to provide client-side notification of upcoming events. To organize
|
|
563
|
+
notification of new or changed events, clients have to poll the data
|
|
564
|
+
store.
|
|
565
|
+
|
|
566
|
+
6. Security Considerations
|
|
567
|
+
|
|
568
|
+
6.1 Access Control
|
|
569
|
+
|
|
570
|
+
There has to be reasonable granularity in the configuration options
|
|
571
|
+
for access to data through [CAP], so that what should be released to
|
|
572
|
+
requesters is released, and what shouldn't is not. Details of
|
|
573
|
+
handling this are described in [CAP].
|
|
574
|
+
|
|
575
|
+
6.2 Authentication
|
|
576
|
+
|
|
577
|
+
Access control must be coupled with a good authentication system, so
|
|
578
|
+
that the right people get the right information. For [CAP], this
|
|
579
|
+
means requiring authentication before any database access can be
|
|
580
|
+
performed, and checking access rights and authentication credentials
|
|
581
|
+
before releasing information. [CAP] uses the Simple Authentication
|
|
582
|
+
Security Layer (SASL) for this authentication. In iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>],
|
|
583
|
+
this may present some challenges, as authentication is often not a
|
|
584
|
+
consideration in store-and-forward protocols.
|
|
585
|
+
|
|
586
|
+
Authentication is also important for scheduling, in that receivers of
|
|
587
|
+
scheduling messages should be able to validate the apparent sender.
|
|
588
|
+
Since scheduling messages are wrapped in MIME [<A HREF="/rfcs/rfc2045.html">RFC-2045</A>], signing and
|
|
589
|
+
encryption are freely available. For messages transmitted over mail,
|
|
590
|
+
this is the only available alternative. It is suggested that
|
|
591
|
+
developers take care in implementing the security features in iMIP
|
|
592
|
+
[<A HREF="/rfcs/rfc2447.html">RFC-2447</A>], bearing in mind that the concept and need may be foreign
|
|
593
|
+
or non-obvious to users, yet essential for the system to function as
|
|
594
|
+
they might expect.
|
|
595
|
+
|
|
596
|
+
The real-time protocols provide for the authentication of users, and
|
|
597
|
+
the preservation of that authentication information, allowing for
|
|
598
|
+
validation by the receiving end-user or server.
|
|
599
|
+
|
|
600
|
+
6.3 Using E-mail
|
|
601
|
+
|
|
602
|
+
Because scheduling information can be transmitted over mail without
|
|
603
|
+
any authentication information, e-mail spoofing is extremely easy if
|
|
604
|
+
the receiver is not checking for authentication. It is suggested
|
|
605
|
+
that implementers consider requiring authentication as a default,
|
|
606
|
+
using mechanisms such as are described in Section 3 of iMIP [RFC-
|
|
607
|
+
2447]. The use of e-mail, and the potential for anonymous
|
|
608
|
+
connections, means that 'calendar spam' is possible. Developers
|
|
609
|
+
should consider this threat when designing systems, particularly
|
|
610
|
+
those that allow for automated request processing.
|
|
611
|
+
|
|
612
|
+
6.4 Other Issues
|
|
613
|
+
|
|
614
|
+
The current security context should be obvious to users. Because the
|
|
615
|
+
underlying mechanisms may not be clear to users, efforts to make
|
|
616
|
+
clear the current state in the UI should be made. One example of
|
|
617
|
+
this is the 'lock' icon used in some Web browsers during secure
|
|
618
|
+
connections.
|
|
619
|
+
|
|
620
|
+
With both iMIP [<A HREF="/rfcs/rfc2447.html">RFC-2447</A>] and [CAP], the possibilities of Denial of
|
|
621
|
+
Service attacks must be considered. The ability to flood a calendar
|
|
622
|
+
system with bogus requests is likely to be exploited once these
|
|
623
|
+
systems become widely deployed, and detection and recovery methods
|
|
624
|
+
will need to be considered.
|
|
625
|
+
|
|
626
|
+
Acknowledgments
|
|
627
|
+
|
|
628
|
+
Thanks to the following, who have participated in the development of
|
|
629
|
+
this document:
|
|
630
|
+
|
|
631
|
+
Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn,
|
|
632
|
+
Alan Davies, Robb Surridge.
|
|
633
|
+
|
|
634
|
+
References
|
|
635
|
+
|
|
636
|
+
[<A HREF="/rfcs/rfc2445.html">RFC-2445</A>] Dawson, F. and D. Stenerson, "Internet Calendaring and
|
|
637
|
+
Scheduling Core Object Specification - iCalendar", RFC
|
|
638
|
+
2445, November 1998.
|
|
639
|
+
|
|
640
|
+
[<A HREF="/rfcs/rfc2446.html">RFC-2446</A>] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
|
|
641
|
+
"iCalendar Transport-Independent Interoperability Protocol
|
|
642
|
+
(iTIP): Scheduling Events, Busy Time, To-dos and Journal
|
|
643
|
+
Entries", <A HREF="/rfcs/rfc2446.html">RFC 2446</A>, November 1998.
|
|
644
|
+
|
|
645
|
+
[<A HREF="/rfcs/rfc2447.html">RFC-2447</A>] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
|
|
646
|
+
Message-Based Interoperability Protocol - iMIP", <A HREF="/rfcs/rfc2447.html">RFC 2447</A>,
|
|
647
|
+
November 1998.
|
|
648
|
+
|
|
649
|
+
[<A HREF="/rfcs/rfc2045.html">RFC-2045</A>] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|
650
|
+
Extensions (MIME) - Part One: Format of Internet Message
|
|
651
|
+
Bodies", <A HREF="/rfcs/rfc2045.html">RFC 2045</A>, November 1996.
|
|
652
|
+
|
|
653
|
+
[CAP] Mansour, S., Royer, D., Babics, G., and Hill, P.,
|
|
654
|
+
"Calendar Access Protocol (CAP)", Work in Progress.
|
|
655
|
+
|
|
656
|
+
Authors' Addresses
|
|
657
|
+
|
|
658
|
+
Bob Mahoney
|
|
659
|
+
MIT
|
|
660
|
+
E40-327
|
|
661
|
+
77 Massachusetts Avenue
|
|
662
|
+
Cambridge, MA 02139
|
|
663
|
+
US
|
|
664
|
+
|
|
665
|
+
Phone: (617) 253-0774
|
|
666
|
+
EMail: <A HREF="mailto:bobmah@mit.edu">bobmah@mit.edu</A>
|
|
667
|
+
|
|
668
|
+
George Babics
|
|
669
|
+
Steltor
|
|
670
|
+
2000 Peel Street
|
|
671
|
+
Montreal, Quebec H3A 2W5
|
|
672
|
+
CA
|
|
673
|
+
|
|
674
|
+
Phone: (514) 733-8500 x4201
|
|
675
|
+
EMail: <A HREF="mailto:georgeb@steltor.com">georgeb@steltor.com</A>
|
|
676
|
+
|
|
677
|
+
Alexander Taler
|
|
678
|
+
|
|
679
|
+
EMail: <A HREF="mailto:alex@0--0.org">alex@0--0.org</A>
|
|
680
|
+
|
|
681
|
+
Full Copyright Statement
|
|
682
|
+
|
|
683
|
+
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|
684
|
+
|
|
685
|
+
This document and translations of it may be copied and furnished to
|
|
686
|
+
others, and derivative works that comment on or otherwise explain it
|
|
687
|
+
or assist in its implementation may be prepared, copied, published
|
|
688
|
+
and distributed, in whole or in part, without restriction of any
|
|
689
|
+
kind, provided that the above copyright notice and this paragraph are
|
|
690
|
+
included on all such copies and derivative works. However, this
|
|
691
|
+
document itself may not be modified in any way, such as by removing
|
|
692
|
+
the copyright notice or references to the Internet Society or other
|
|
693
|
+
Internet organizations, except as needed for the purpose of
|
|
694
|
+
developing Internet standards in which case the procedures for
|
|
695
|
+
copyrights defined in the Internet Standards process must be
|
|
696
|
+
followed, or as required to translate it into languages other than
|
|
697
|
+
English.
|
|
698
|
+
|
|
699
|
+
The limited permissions granted above are perpetual and will not be
|
|
700
|
+
revoked by the Internet Society or its successors or assigns.
|
|
701
|
+
|
|
702
|
+
This document and the information contained herein is provided on an
|
|
703
|
+
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
704
|
+
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
705
|
+
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
706
|
+
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
707
|
+
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
708
|
+
|
|
709
|
+
Acknowledgement
|
|
710
|
+
|
|
711
|
+
Funding for the RFC Editor function is currently provided by the
|
|
712
|
+
Internet Society.
|
|
713
|
+
|
|
714
|
+
</PRE>
|
|
715
|
+
<p align=center><script language="JavaScript"><!--
|
|
716
|
+
erfc("3283");
|
|
717
|
+
// --></script></p>
|
|
718
|
+
<br>
|
|
719
|
+
<div align="center">
|
|
720
|
+
<table border="0" cellpadding="3" width="100%" cellspacing="3">
|
|
721
|
+
<tr><td width="45%">
|
|
722
|
+
<p align="left">Previous: <a href="/rfcs/rfc3282.html">RFC 3282 - Content Language Headers</a>
|
|
723
|
+
</p></td><td width="10%"> </td><td width="45%">
|
|
724
|
+
<p align="right">Next: <a href="/rfcs/rfc3284.html">RFC 3284 - The VCDIFF Generic Differencing and Compression Data Format</a>
|
|
725
|
+
</p></td></tr></table></div><p align="right"> </p>
|
|
726
|
+
<HR SIZE=2 NOSHADE>
|
|
727
|
+
<DIV ALIGN=CENTER>[ <a href="/rfcs/">RFC Index</a> | <A HREF="/rfcs/rfcsearch.html">RFC Search</A> | <a href="/faqs/">Usenet FAQs</a> | <a href="/contrib/">Web FAQs</a> | <a href="/docs/">Documents</a> | <a href="http://www.city-data.com/">Cities</a> ]
|
|
728
|
+
<P>
|
|
729
|
+
</DIV>
|
|
730
|
+
<ADDRESS>
|
|
731
|
+
<P ALIGN=CENTER>
|
|
732
|
+
|
|
733
|
+
</P>
|
|
734
|
+
</ADDRESS>
|
|
735
|
+
</SMALL>
|
|
736
|
+
</BODY>
|
|
737
|
+
</HTML>
|
|
738
|
+
|