icalendar 1.1.1 → 1.1.2

Sign up to get free protection for your applications and to get access to all the features.
Files changed (124) hide show
  1. data/History.txt +3 -0
  2. data/Manifest.txt +61 -0
  3. data/PostInstall.txt +5 -0
  4. data/{README → README.rdoc} +4 -0
  5. data/Rakefile +28 -133
  6. data/config/website.yml +2 -0
  7. data/icalendar.gemspec +55 -0
  8. data/lib/icalendar/base.rb +2 -0
  9. data/lib/icalendar/component.rb +9 -7
  10. data/script/console +10 -0
  11. data/script/destroy +14 -0
  12. data/script/generate +14 -0
  13. data/script/recur1.ics +38 -0
  14. data/script/tryit.rb +13 -0
  15. data/script/txt2html +71 -0
  16. data/test.ical +33 -0
  17. data/test.ics +33 -0
  18. data/test.rb +48 -0
  19. data/test/component/{event_test.rb → test_event.rb} +0 -0
  20. data/test/component/{timezone_test.rb → test_timezone.rb} +1 -1
  21. data/test/component/{todo_test.rb → test_todo.rb} +0 -0
  22. data/test/fixtures/folding.ics +7 -7
  23. data/test/{calendar_test.rb → test_calendar.rb} +1 -4
  24. data/test/{component_test.rb → test_component.rb} +0 -0
  25. data/test/{conversions_test.rb → test_conversions.rb} +8 -8
  26. data/test/test_helper.rb +3 -0
  27. data/test/{parameter_test.rb → test_parameter.rb} +4 -0
  28. data/test/{parser_test.rb → test_parser.rb} +0 -0
  29. data/test2.rb +28 -0
  30. data/website/index.html +11 -0
  31. data/website/index.txt +79 -0
  32. data/website/javascripts/rounded_corners_lite.inc.js +285 -0
  33. data/website/stylesheets/screen.css +159 -0
  34. data/website/template.html.erb +50 -0
  35. metadata +135 -135
  36. data/docs/api/classes/Array.html +0 -155
  37. data/docs/api/classes/Bignum.html +0 -148
  38. data/docs/api/classes/Date.html +0 -172
  39. data/docs/api/classes/DateTime.html +0 -200
  40. data/docs/api/classes/Fixnum.html +0 -148
  41. data/docs/api/classes/Float.html +0 -148
  42. data/docs/api/classes/HashAttrs.html +0 -212
  43. data/docs/api/classes/Icalendar/Alarm.html +0 -228
  44. data/docs/api/classes/Icalendar/Base.html +0 -179
  45. data/docs/api/classes/Icalendar/Calendar.html +0 -504
  46. data/docs/api/classes/Icalendar/Component.html +0 -853
  47. data/docs/api/classes/Icalendar/DateProp.html +0 -187
  48. data/docs/api/classes/Icalendar/DateProp/ClassMethods.html +0 -195
  49. data/docs/api/classes/Icalendar/Daylight.html +0 -156
  50. data/docs/api/classes/Icalendar/Event.html +0 -671
  51. data/docs/api/classes/Icalendar/Freebusy.html +0 -266
  52. data/docs/api/classes/Icalendar/Geo.html +0 -211
  53. data/docs/api/classes/Icalendar/InvalidPropertyValue.html +0 -117
  54. data/docs/api/classes/Icalendar/Journal.html +0 -443
  55. data/docs/api/classes/Icalendar/Parameter.html +0 -166
  56. data/docs/api/classes/Icalendar/Parser.html +0 -352
  57. data/docs/api/classes/Icalendar/RRule.html +0 -428
  58. data/docs/api/classes/Icalendar/RRule/Weekday.html +0 -199
  59. data/docs/api/classes/Icalendar/Standard.html +0 -156
  60. data/docs/api/classes/Icalendar/Timezone.html +0 -450
  61. data/docs/api/classes/Icalendar/Todo.html +0 -480
  62. data/docs/api/classes/Icalendar/TzidSupport.html +0 -118
  63. data/docs/api/classes/Icalendar/UnknownComponentClass.html +0 -117
  64. data/docs/api/classes/Icalendar/UnknownPropertyMethod.html +0 -117
  65. data/docs/api/classes/Object.html +0 -272
  66. data/docs/api/classes/String.html +0 -148
  67. data/docs/api/classes/TZInfo.html +0 -119
  68. data/docs/api/classes/TZInfo/Timezone.html +0 -153
  69. data/docs/api/classes/TZInfo/TimezonePeriod.html +0 -200
  70. data/docs/api/classes/TZInfo/TimezoneTransitionInfo.html +0 -229
  71. data/docs/api/classes/Time.html +0 -180
  72. data/docs/api/classes/URI.html +0 -111
  73. data/docs/api/classes/URI/Generic.html +0 -148
  74. data/docs/api/created.rid +0 -1
  75. data/docs/api/files/COPYING.html +0 -163
  76. data/docs/api/files/GPL.html +0 -531
  77. data/docs/api/files/README.html +0 -401
  78. data/docs/api/files/lib/hash_attrs_rb.html +0 -107
  79. data/docs/api/files/lib/icalendar/base_rb.html +0 -108
  80. data/docs/api/files/lib/icalendar/calendar_rb.html +0 -101
  81. data/docs/api/files/lib/icalendar/component/alarm_rb.html +0 -101
  82. data/docs/api/files/lib/icalendar/component/event_rb.html +0 -101
  83. data/docs/api/files/lib/icalendar/component/freebusy_rb.html +0 -101
  84. data/docs/api/files/lib/icalendar/component/journal_rb.html +0 -101
  85. data/docs/api/files/lib/icalendar/component/timezone_rb.html +0 -101
  86. data/docs/api/files/lib/icalendar/component/todo_rb.html +0 -101
  87. data/docs/api/files/lib/icalendar/component_rb.html +0 -108
  88. data/docs/api/files/lib/icalendar/conversions_rb.html +0 -109
  89. data/docs/api/files/lib/icalendar/helpers_rb.html +0 -101
  90. data/docs/api/files/lib/icalendar/parameter_rb.html +0 -101
  91. data/docs/api/files/lib/icalendar/parser_rb.html +0 -110
  92. data/docs/api/files/lib/icalendar/rrule_rb.html +0 -110
  93. data/docs/api/files/lib/icalendar/tzinfo_rb.html +0 -101
  94. data/docs/api/files/lib/icalendar_rb.html +0 -121
  95. data/docs/api/files/lib/meta_rb.html +0 -107
  96. data/docs/api/fr_class_index.html +0 -64
  97. data/docs/api/fr_file_index.html +0 -47
  98. data/docs/api/fr_method_index.html +0 -123
  99. data/docs/api/index.html +0 -24
  100. data/docs/api/rdoc-style.css +0 -208
  101. data/docs/rfcs/itip_notes.txt +0 -69
  102. data/docs/rfcs/rfc2425.pdf +0 -0
  103. data/docs/rfcs/rfc2426.pdf +0 -0
  104. data/docs/rfcs/rfc2445.pdf +0 -0
  105. data/docs/rfcs/rfc2446.pdf +0 -0
  106. data/docs/rfcs/rfc2447.pdf +0 -0
  107. data/docs/rfcs/rfc3283.txt +0 -738
  108. data/test/coverage/STUB +0 -0
  109. data/test/coverage/index.html +0 -272
  110. data/test/coverage/lib-hash_attrs_rb.html +0 -235
  111. data/test/coverage/lib-icalendar-base_rb.html +0 -249
  112. data/test/coverage/lib-icalendar-calendar_rb.html +0 -324
  113. data/test/coverage/lib-icalendar-component-alarm_rb.html +0 -250
  114. data/test/coverage/lib-icalendar-component-event_rb.html +0 -353
  115. data/test/coverage/lib-icalendar-component-freebusy_rb.html +0 -245
  116. data/test/coverage/lib-icalendar-component-journal_rb.html +0 -278
  117. data/test/coverage/lib-icalendar-component-timezone_rb.html +0 -326
  118. data/test/coverage/lib-icalendar-component-todo_rb.html +0 -277
  119. data/test/coverage/lib-icalendar-component_rb.html +0 -733
  120. data/test/coverage/lib-icalendar-conversions_rb.html +0 -358
  121. data/test/coverage/lib-icalendar-parser_rb.html +0 -671
  122. data/test/coverage/lib-icalendar-rrule_rb.html +0 -357
  123. data/test/coverage/lib-icalendar_rb.html +0 -243
  124. data/test/coverage/lib-meta_rb.html +0 -234
data/docs/api/index.html DELETED
@@ -1,24 +0,0 @@
1
- <?xml version="1.0" encoding="iso-8859-1"?>
2
- <!DOCTYPE html
3
- PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
4
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
5
-
6
- <!--
7
-
8
- iCalendar -- Internet Calendaring for Ruby
9
-
10
- -->
11
- <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
12
- <head>
13
- <title>iCalendar -- Internet Calendaring for Ruby</title>
14
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
15
- </head>
16
- <frameset rows="20%, 80%">
17
- <frameset cols="25%,35%,45%">
18
- <frame src="fr_file_index.html" title="Files" name="Files" />
19
- <frame src="fr_class_index.html" name="Classes" />
20
- <frame src="fr_method_index.html" name="Methods" />
21
- </frameset>
22
- <frame src="files/README.html" name="docwin" />
23
- </frameset>
24
- </html>
data/docs/api/rdoc-style.css DELETED
@@ -1,208 +0,0 @@
1
-
2
- body {
3
- font-family: Verdana,Arial,Helvetica,sans-serif;
4
- font-size: 90%;
5
- margin: 0;
6
- margin-left: 40px;
7
- padding: 0;
8
- background: white;
9
- }
10
-
11
- h1,h2,h3,h4 { margin: 0; color: #efefef; background: transparent; }
12
- h1 { font-size: 150%; }
13
- h2,h3,h4 { margin-top: 1em; }
14
-
15
- a { background: #eef; color: #039; text-decoration: none; }
16
- a:hover { background: #039; color: #eef; }
17
-
18
- /* Override the base stylesheet's Anchor inside a table cell */
19
- td > a {
20
- background: transparent;
21
- color: #039;
22
- text-decoration: none;
23
- }
24
-
25
- /* and inside a section title */
26
- .section-title > a {
27
- background: transparent;
28
- color: #eee;
29
- text-decoration: none;
30
- }
31
-
32
- /* === Structural elements =================================== */
33
-
34
- div#index {
35
- margin: 0;
36
- margin-left: -40px;
37
- padding: 0;
38
- font-size: 90%;
39
- }
40
-
41
-
42
- div#index a {
43
- margin-left: 0.7em;
44
- }
45
-
46
- div#index .section-bar {
47
- margin-left: 0px;
48
- padding-left: 0.7em;
49
- background: #ccc;
50
- font-size: small;
51
- }
52
-
53
-
54
- div#classHeader, div#fileHeader {
55
- width: auto;
56
- color: white;
57
- padding: 0.5em 1.5em 0.5em 1.5em;
58
- margin: 0;
59
- margin-left: -40px;
60
- border-bottom: 3px solid #006;
61
- }
62
-
63
- div#classHeader a, div#fileHeader a {
64
- background: inherit;
65
- color: white;
66
- }
67
-
68
- div#classHeader td, div#fileHeader td {
69
- background: inherit;
70
- color: white;
71
- }
72
-
73
-
74
- div#fileHeader {
75
- background: #057;
76
- }
77
-
78
- div#classHeader {
79
- background: #048;
80
- }
81
-
82
-
83
- .class-name-in-header {
84
- font-size: 180%;
85
- font-weight: bold;
86
- }
87
-
88
-
89
- div#bodyContent {
90
- padding: 0 1.5em 0 1.5em;
91
- }
92
-
93
- div#description {
94
- padding: 0.5em 1.5em;
95
- background: #efefef;
96
- border: 1px dotted #999;
97
- }
98
-
99
- div#description h1,h2,h3,h4,h5,h6 {
100
- color: #125;;
101
- background: transparent;
102
- }
103
-
104
- div#validator-badges {
105
- text-align: center;
106
- }
107
- div#validator-badges img { border: 0; }
108
-
109
- div#copyright {
110
- color: #333;
111
- background: #efefef;
112
- font: 0.75em sans-serif;
113
- margin-top: 5em;
114
- margin-bottom: 0;
115
- padding: 0.5em 2em;
116
- }
117
-
118
-
119
- /* === Classes =================================== */
120
-
121
- table.header-table {
122
- color: white;
123
- font-size: small;
124
- }
125
-
126
- .type-note {
127
- font-size: small;
128
- color: #DEDEDE;
129
- }
130
-
131
- .xxsection-bar {
132
- background: #eee;
133
- color: #333;
134
- padding: 3px;
135
- }
136
-
137
- .section-bar {
138
- color: #333;
139
- border-bottom: 1px solid #999;
140
- margin-left: -20px;
141
- }
142
-
143
-
144
- .section-title {
145
- background: #79a;
146
- color: #eee;
147
- padding: 3px;
148
- margin-top: 2em;
149
- margin-left: -30px;
150
- border: 1px solid #999;
151
- }
152
-
153
- .top-aligned-row { vertical-align: top }
154
- .bottom-aligned-row { vertical-align: bottom }
155
-
156
- /* --- Context section classes ----------------------- */
157
-
158
- .context-row { }
159
- .context-item-name { font-family: monospace; font-weight: bold; color: black; }
160
- .context-item-value { font-size: small; color: #448; }
161
- .context-item-desc { color: #333; padding-left: 2em; }
162
-
163
- /* --- Method classes -------------------------- */
164
- .method-detail {
165
- background: #efefef;
166
- padding: 0;
167
- margin-top: 0.5em;
168
- margin-bottom: 1em;
169
- border: 1px dotted #ccc;
170
- }
171
- .method-heading {
172
- color: black;
173
- background: #ccc;
174
- border-bottom: 1px solid #666;
175
- padding: 0.2em 0.5em 0 0.5em;
176
- }
177
- .method-signature { color: black; background: inherit; }
178
- .method-name { font-weight: bold; }
179
- .method-args { font-style: italic; }
180
- .method-description { padding: 0 0.5em 0 0.5em; }
181
-
182
- /* --- Source code sections -------------------- */
183
-
184
- a.source-toggle { font-size: 90%; }
185
- div.method-source-code {
186
- background: #262626;
187
- color: #ffdead;
188
- margin: 1em;
189
- padding: 0.5em;
190
- border: 1px dashed #999;
191
- overflow: hidden;
192
- }
193
-
194
- div.method-source-code pre { color: #ffdead; overflow: hidden; }
195
-
196
- /* --- Ruby keyword styles --------------------- */
197
-
198
- .standalone-code { background: #221111; color: #ffdead; overflow: hidden; }
199
-
200
- .ruby-constant { color: #7fffd4; background: transparent; }
201
- .ruby-keyword { color: #00ffff; background: transparent; }
202
- .ruby-ivar { color: #eedd82; background: transparent; }
203
- .ruby-operator { color: #00ffee; background: transparent; }
204
- .ruby-identifier { color: #ffdead; background: transparent; }
205
- .ruby-node { color: #ffa07a; background: transparent; }
206
- .ruby-comment { color: #b22222; font-weight: bold; background: transparent; }
207
- .ruby-regexp { color: #ffa07a; background: transparent; }
208
- .ruby-value { color: #7fffd4; background: transparent; }
data/docs/rfcs/itip_notes.txt DELETED
@@ -1,69 +0,0 @@
1
- Set of methods used for transactions:
2
-
3
- PUBLISH:
4
- - Publish a calendar entry to one or more users.
5
-
6
- REQUEST:
7
- - Used to schedule a calendar entry with other users.
8
- - Require REPLY messages from others.
9
- - Used by Organizers to update status of entries.
10
-
11
- REPLY:
12
- - Attendees use this to send information back to Organizers who have sent a
13
- REQUEST message.
14
-
15
- ADD:
16
- - Add one or more instances to an existing entry.
17
-
18
- CANCEL:
19
- - Cancel a calendar item.
20
-
21
- REFRESH:
22
- - Attendee's use this to get the latest version of an item.
23
-
24
- COUNTER:
25
- - Used by an attendee to negotiate a change in a calendar entry.
26
-
27
- DECLINE-COUNTER:
28
- - Used by an organizer to decline a COUNTER message.
29
-
30
-
31
- Transports:
32
-
33
- Real-time vs. Store-and-forward?
34
-
35
- Entry Status:
36
- - Only the organizer can set the STATUS property
37
- - Attendee's use the "partstat" parameter of the ATTENDEE property to convey
38
- their personal status.
39
- - Initial value of "partstat" is set to "NEEDS-ACTION" by organizer
40
- - Modifying this state is part of an attendee's REPLY message.
41
-
42
- Sequence Property:
43
- - Used to tell manage different versions of an entry
44
- - Has specific rules so look at these
45
-
46
- Handling messages should be done in this manner:
47
-
48
- 1. The primary key for referencing a particular iCalendar component
49
- is the "UID" property value. To reference an instance of a
50
- recurring component, the primary key is composed of the "UID" and
51
- the "RECURRENCE-ID" properties.
52
- 2. The secondary key for referencing a component is the "SEQUENCE"
53
- property value. For components where the "UID" is the same, the
54
- component with the highest numeric value for the "SEQUENCE"
55
- property obsoletes all other revisions of the component with
56
- lower values.
57
- 3. "Attendees" send "REPLY" messages to the "Organizer". For
58
- replies where the "UID" property value is the same, the value of
59
- the "SEQUENCE" property indicates the revision of the component
60
- to which the "Attendee" is replying. The reply with the highest
61
- numeric value for the "SEQUENCE" property obsoletes all other
62
- replies with lower values.
63
- 4. In situations where the "UID" and "SEQUENCE" properties match,
64
- the "DTSTAMP" property is used as the tie-breaker. The component
65
- with the latest "DTSTAMP" overrides all others. Similarly, for
66
- "Attendee" responses where the "UID" property values match and
67
- the "SEQUENCE" property values match, the response with the
68
- latest "DTSTAMP" overrides all others.
69
-
data/docs/rfcs/rfc2425.pdf DELETED
Binary file
data/docs/rfcs/rfc2426.pdf DELETED
Binary file
data/docs/rfcs/rfc2445.pdf DELETED
Binary file
data/docs/rfcs/rfc2446.pdf DELETED
Binary file
data/docs/rfcs/rfc2447.pdf DELETED
Binary file
data/docs/rfcs/rfc3283.txt DELETED
@@ -1,738 +0,0 @@
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
- &nbsp;<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%">&nbsp;</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">&nbsp;</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
-