forked from community-ssu/calendar-backend
-
Notifications
You must be signed in to change notification settings - Fork 0
/
rfc2445.txt
8291 lines (5370 loc) · 285 KB
/
rfc2445.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group F. Dawson
Request for Comments: 2445 Lotus
Category: Standards Track D. Stenerson
Microsoft
November 1998
Internet Calendaring and Scheduling Core Object Specification
(iCalendar)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
There is a clear need to provide and deploy interoperable calendaring
and scheduling services for the Internet. Current group scheduling
and Personal Information Management (PIM) products are being extended
for use across the Internet, today, in proprietary ways. This memo
has been defined to provide the definition of a common format for
openly exchanging calendaring and scheduling information across the
Internet.
This memo is formatted as a registration for a MIME media type per
[RFC 2048]. However, the format in this memo is equally applicable
for use outside of a MIME message content type.
The proposed media type value is 'text/calendar'. This string would
label a media type containing calendaring and scheduling information
encoded as text characters formatted in a manner outlined below.
This MIME media type provides a standard content type for capturing
calendar event, to-do and journal entry information. It also can be
used to convey free/busy time information. The content type is
suitable as a MIME message entity that can be transferred over MIME
based email systems, using HTTP or some other Internet transport. In
Dawson & Stenerson Standards Track [Page 1]
RFC 2445 iCalendar November 1998
addition, the content type is useful as an object for interactions
between desktop applications using the operating system clipboard,
drag/drop or file systems capabilities.
This memo is based on the earlier work of the vCalendar specification
for the exchange of personal calendaring and scheduling information.
In order to avoid confusion with this referenced work, this memo is
to be known as the iCalendar specification.
This memo defines the format for specifying iCalendar object methods.
An iCalendar object method is a set of usage constraints for the
iCalendar object. For example, these methods might define scheduling
messages that request an event be scheduled, reply to an event
request, send a cancellation notice for an event, modify or replace
the definition of an event, provide a counter proposal for an
original event request, delegate an event request to another
individual, request free or busy time, reply to a free or busy time
request, or provide similar scheduling messages for a to-do or
journal entry calendar component. The iCalendar Transport-indendent
Interoperability Protocol (iTIP) defined in [ITIP] is one such
scheduling protocol.
Table of Contents
1 Introduction.....................................................5
2 Basic Grammar and Conventions....................................6
2.1 Formatting Conventions .......................................7
2.2 Related Memos ................................................8
2.3 International Considerations .................................8
3 Registration Information.........................................8
3.1 Content Type .................................................8
3.2 Parameters ...................................................9
3.3 Content Header Fields .......................................10
3.4 Encoding Considerations .....................................10
3.5 Security Considerations .....................................10
3.6 Interoperability Considerations .............................11
3.7 Applications Which Use This Media Type ......................11
3.8 Additional Information ......................................11
3.9 Magic Numbers ...............................................11
3.10 File Extensions ............................................11
3.11 Contact for Further Information: ...........................12
3.12 Intended Usage .............................................12
3.13 Authors/Change Controllers .................................12
4 iCalendar Object Specification..................................13
4.1 Content Lines ...............................................13
4.1.1 List and Field Separators ................................16
4.1.2 Multiple Values ..........................................16
4.1.3 Binary Content ...........................................16
Dawson & Stenerson Standards Track [Page 2]
RFC 2445 iCalendar November 1998
4.1.4 Character Set ............................................17
4.2 Property Parameters .........................................17
4.2.1 Alternate Text Representation ............................18
4.2.2 Common Name ..............................................19
4.2.3 Calendar User Type .......................................20
4.2.4 Delegators ...............................................20
4.2.5 Delegatees ...............................................21
4.2.6 Directory Entry Reference ................................21
4.2.7 Inline Encoding ..........................................22
4.2.8 Format Type ..............................................23
4.2.9 Free/Busy Time Type ......................................23
4.2.10 Language ................................................24
4.2.11 Group or List Membership ................................25
4.2.12 Participation Status ....................................25
4.2.13 Recurrence Identifier Range .............................27
4.2.14 Alarm Trigger Relationship ..............................27
4.2.15 Relationship Type .......................................28
4.2.16 Participation Role ......................................29
4.2.17 RSVP Expectation ........................................29
4.2.18 Sent By .................................................30
4.2.19 Time Zone Identifier ....................................30
4.2.20 Value Data Types ........................................32
4.3 Property Value Data Types ...................................32
4.3.1 Binary ...................................................33
4.3.2 Boolean ..................................................33
4.3.3 Calendar User Address ....................................34
4.3.4 Date .....................................................34
4.3.5 Date-Time ................................................35
4.3.6 Duration .................................................37
4.3.7 Float ....................................................38
4.3.8 Integer ..................................................38
4.3.9 Period of Time ...........................................39
4.3.10 Recurrence Rule .........................................40
4.3.11 Text ....................................................45
4.3.12 Time ....................................................47
4.3.13 URI .....................................................49
4.3.14 UTC Offset ..............................................49
4.4 iCalendar Object ............................................50
4.5 Property ....................................................51
4.6 Calendar Components .........................................51
4.6.1 Event Component ..........................................52
4.6.2 To-do Component ..........................................55
4.6.3 Journal Component ........................................56
4.6.4 Free/Busy Component ......................................58
4.6.5 Time Zone Component ......................................60
4.6.6 Alarm Component ..........................................67
4.7 Calendar Properties .........................................73
4.7.1 Calendar Scale ...........................................73
Dawson & Stenerson Standards Track [Page 3]
RFC 2445 iCalendar November 1998
4.7.2 Method ...................................................74
4.7.3 Product Identifier .......................................75
4.7.4 Version ..................................................76
4.8 Component Properties ........................................77
4.8.1 Descriptive Component Properties .........................77
4.8.1.1 Attachment ...........................................77
4.8.1.2 Categories ...........................................78
4.8.1.3 Classification .......................................79
4.8.1.4 Comment ..............................................80
4.8.1.5 Description ..........................................81
4.8.1.6 Geographic Position ..................................82
4.8.1.7 Location .............................................84
4.8.1.8 Percent Complete .....................................85
4.8.1.9 Priority .............................................85
4.8.1.10 Resources ...........................................87
4.8.1.11 Status ..............................................88
4.8.1.12 Summary .............................................89
4.8.2 Date and Time Component Properties .......................90
4.8.2.1 Date/Time Completed ..................................90
4.8.2.2 Date/Time End ........................................91
4.8.2.3 Date/Time Due ........................................92
4.8.2.4 Date/Time Start ......................................93
4.8.2.5 Duration .............................................94
4.8.2.6 Free/Busy Time .......................................95
4.8.2.7 Time Transparency ....................................96
4.8.3 Time Zone Component Properties ...........................97
4.8.3.1 Time Zone Identifier .................................97
4.8.3.2 Time Zone Name .......................................98
4.8.3.3 Time Zone Offset From ................................99
4.8.3.4 Time Zone Offset To .................................100
4.8.3.5 Time Zone URL .......................................101
4.8.4 Relationship Component Properties .......................102
4.8.4.1 Attendee ............................................102
4.8.4.2 Contact .............................................104
4.8.4.3 Organizer ...........................................106
4.8.4.4 Recurrence ID .......................................107
4.8.4.5 Related To ..........................................109
4.8.4.6 Uniform Resource Locator ............................110
4.8.4.7 Unique Identifier ...................................111
4.8.5 Recurrence Component Properties .........................112
4.8.5.1 Exception Date/Times ................................112
4.8.5.2 Exception Rule ......................................114
4.8.5.3 Recurrence Date/Times ...............................115
4.8.5.4 Recurrence Rule .....................................117
4.8.6 Alarm Component Properties ..............................126
4.8.6.1 Action ..............................................126
4.8.6.2 Repeat Count ........................................126
4.8.6.3 Trigger .............................................127
Dawson & Stenerson Standards Track [Page 4]
RFC 2445 iCalendar November 1998
4.8.7 Change Management Component Properties ..................129
4.8.7.1 Date/Time Created ...................................129
4.8.7.2 Date/Time Stamp .....................................130
4.8.7.3 Last Modified .......................................131
4.8.7.4 Sequence Number .....................................131
4.8.8 Miscellaneous Component Properties ......................133
4.8.8.1 Non-standard Properties .............................133
4.8.8.2 Request Status ......................................134
5 iCalendar Object Examples......................................136
6 Recommended Practices..........................................140
7 Registration of Content Type Elements..........................141
7.1 Registration of New and Modified iCalendar Object Methods ..141
7.2 Registration of New Properties .............................141
7.2.1 Define the property .....................................142
7.2.2 Post the Property definition ............................143
7.2.3 Allow a comment period ..................................143
7.2.4 Submit the property for approval ........................143
7.3 Property Change Control ....................................143
8 References.....................................................144
9 Acknowledgments................................................145
10 Authors' and Chairs' Addresses................................146
11 Full Copyright Statement......................................148
1 Introduction
The use of calendaring and scheduling has grown considerably in the
last decade. Enterprise and inter-enterprise business has become
dependent on rapid scheduling of events and actions using this
information technology. However, the longer term growth of
calendaring and scheduling, is currently limited by the lack of
Internet standards for the message content types that are central to
these knowledgeware applications. This memo is intended to progress
the level of interoperability possible between dissimilar calendaring
and scheduling applications. This memo defines a MIME content type
for exchanging electronic calendaring and scheduling information. The
Internet Calendaring and Scheduling Core Object Specification, or
iCalendar, allows for the capture and exchange of information
normally stored within a calendaring and scheduling application; such
as a Personal Information Manager (PIM) or a Group Scheduling
product.
The iCalendar format is suitable as an exchange format between
applications or systems. The format is defined in terms of a MIME
content type. This will enable the object to be exchanged using
several transports, including but not limited to SMTP, HTTP, a file
system, desktop interactive protocols such as the use of a memory-
based clipboard or drag/drop interactions, point-to-point
asynchronous communication, wired-network transport, or some form of
Dawson & Stenerson Standards Track [Page 5]
RFC 2445 iCalendar November 1998
unwired transport such as infrared might also be used.
The memo also provides for the definition of iCalendar object methods
that will map this content type to a set of messages for supporting
calendaring and scheduling operations such as requesting, replying
to, modifying, and canceling meetings or appointments, to-dos and
journal entries. The iCalendar object methods can be used to define
other calendaring and scheduling operations such a requesting for and
replying with free/busy time data. Such a scheduling protocol is
defined in the iCalendar Transport-independent Interoperability
Protocol (iTIP) defined in [ITIP].
The memo also includes a formal grammar for the content type based on
the Internet ABNF defined in [RFC 2234]. This ABNF is required for
the implementation of parsers and to serve as the definitive
reference when ambiguities or questions arise in interpreting the
descriptive prose definition of the memo.
2 Basic Grammar and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and
"OPTIONAL" in this document are to be interoperated as described in
[RFC 2119].
This memo makes use of both a descriptive prose and a more formal
notation for defining the calendaring and scheduling format.
The notation used in this memo is the ABNF notation of [RFC 2234].
Readers intending on implementing this format defined in this memo
should be familiar with this notation in order to properly interpret
the specifications of this memo.
All numeric and hexadecimal values used in this memo are given in
decimal notation.
All names of properties, property parameters, enumerated property
values and property parameter values are case-insensitive. However,
all other property values are case-sensitive, unless otherwise
stated.
Note: All indented editorial notes, such as this one, are
intended to provide the reader with additional information. The
information is not essential to the building of an
implementation conformant with this memo. The information is
provided to highlight a particular feature or characteristic of
the memo.
Dawson & Stenerson Standards Track [Page 6]
RFC 2445 iCalendar November 1998
The format for the iCalendar object is based on the syntax of the
[RFC 2425] content type. While the iCalendar object is not a profile
of the [RFC 2425] content type, it does reuse a number of the
elements from the [RFC 2425] specification.
2.1 Formatting Conventions
The mechanisms defined in this memo are defined in prose. Many of the
terms used to describe these have common usage that is different than
the standards usage of this memo. In order to reference within this
memo elements of the calendaring and scheduling model, core object
(this memo) or interoperability protocol [ITIP] some formatting
conventions have been used. Calendaring and scheduling roles are
referred to in quoted-strings of text with the first character of
each word in upper case. For example, "Organizer" refers to a role of
a "Calendar User" within the scheduling protocol defined by [ITIP].
Calendar components defined by this memo are referred to with
capitalized, quoted-strings of text. All calendar components start
with the letter "V". For example, "VEVENT" refers to the event
calendar component, "VTODO" refers to the to-do calendar component
and "VJOURNAL" refers to the daily journal calendar component.
Scheduling methods defined by [ITIP] are referred to with
capitalized, quoted-strings of text. For example, "REQUEST" refers to
the method for requesting a scheduling calendar component be created
or modified, "REPLY" refers to the method a recipient of a request
uses to update their status with the "Organizer" of the calendar
component.
The properties defined by this memo are referred to with capitalized,
quoted-strings of text, followed by the word "property". For example,
"ATTENDEE" property refers to the iCalendar property used to convey
the calendar address of a calendar user. Property parameters defined
by this memo are referred to with lowercase, quoted-strings of text,
followed by the word "parameter". For example, "value" parameter
refers to the iCalendar property parameter used to override the
default data type for a property value. Enumerated values defined by
this memo are referred to with capitalized text, either alone or
followed by the word "value". For example, the "MINUTELY" value can
be used with the "FREQ" component of the "RECUR" data type to specify
repeating components based on an interval of one minute or more.
Dawson & Stenerson Standards Track [Page 7]
RFC 2445 iCalendar November 1998
2.2 Related Memos
Implementers will need to be familiar with several other memos that,
along with this memo, form a framework for Internet calendaring and
scheduling standards. This memo, [ICAL], specifies a core
specification of objects, data types, properties and property
parameters.
[ITIP] - specifies an interoperability protocol for scheduling
between different implementations;
[IMIP] specifies an Internet email binding for [ITIP].
This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are
made to the memo that provides for the specification of these
concepts or definitions.
2.3 International Considerations
In the rest of this document, descriptions of characters are of the
form "character name (codepoint)", where "codepoint" is from the US-
ASCII character set. The "character name" is the authoritative
description; (codepoint) is a reference to that character in US-ASCII
or US-ASCII compatible sets (for example the ISO-8859-x family, UTF-
8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set
is used, appropriate code-point from that character set MUST be
chosen instead. Use of non-US-ASCII-compatible character sets is NOT
recommended.
3 Registration Information
The Calendaring and Scheduling Core Object Specification is intended
for use as a MIME content type. However, the implementation of the
memo is in no way limited solely as a MIME content type.
3.1 Content Type
The following text is intended to register this memo as the MIME
content type "text/calendar".
Subject: Registration of MIME content type text/calendar.
MIME media type name: text
MIME subtype name: calendar
Dawson & Stenerson Standards Track [Page 8]
RFC 2445 iCalendar November 1998
3.2 Parameters
Required parameters: none
Optional parameters: charset, method, component and optinfo
The "charset" parameter is defined in [RFC 2046] for other body
parts. It is used to identify the default character set used within
the body part.
The "method" parameter is used to convey the iCalendar object method
or transaction semantics for the calendaring and scheduling
information. It also is an identifier for the restricted set of
properties and values that the iCalendar object consists of. The
parameter is to be used as a guide for applications interpreting the
information contained within the body part. It SHOULD NOT be used to
exclude or require particular pieces of information unless the
identified method definition specifically calls for this behavior.
Unless specifically forbidden by a particular method definition, a
text/calendar content type can contain any set of properties
permitted by the Calendaring and Scheduling Core Object
Specification. The "method" parameter MUST be the same value as that
specified in the "METHOD" component property in the iCalendar object.
If one is present, the other MUST also be present.
The value for the "method" parameter is defined as follows:
method = 1*(ALPHA / DIGIT / "-")
; IANA registered iCalendar object method
The "component" parameter conveys the type of iCalendar calendar
component within the body part. If the iCalendar object contains more
than one calendar component type, then multiple component parameters
MUST be specified.
The value for the "component" parameter is defined as follows:
component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
/ "VTIMEZONE" / x-name / iana-token)
The "optinfo" parameter conveys optional information about the
iCalendar object within the body part. This parameter can only
specify semantics already specified by the iCalendar object and that
can be otherwise determined by parsing the body part. In addition,
the optional information specified by this parameter MUST be
consistent with that information specified by the iCalendar object.
For example, it can be used to convey the "Attendee" response status
to a meeting request. The parameter value consists of a string value.
Dawson & Stenerson Standards Track [Page 9]
RFC 2445 iCalendar November 1998
The parameter can be specified multiple times.
This parameter MAY only specify semantics already specified by the
iCalendar object and that can be otherwise determined by parsing the
body part.
The value for the "optinfo" parameter is defined as follows:
optinfo = infovalue / qinfovalue
infovalue = iana-token / x-name
qinfovalue = DQUOTE (infovalue) DQUOTE
3.3 Content Header Fields
Optional content header fields: Any header fields defined by [RFC
2045].
3.4 Encoding Considerations
This MIME content type can contain 8bit characters, so the use of
quoted-printable or BASE64 MIME content-transfer-encodings might be
necessary when iCalendar objects are transferred across protocols
restricted to the 7bit repertoire. Note that a text valued property
in the content entity can also have content encoding of special
characters using a BACKSLASH character (US-ASCII decimal 92)
escapement technique. This means that content values can end up
encoded twice.
3.5 Security Considerations
SPOOFING - - In this memo, the "Organizer" is the only person
authorized to make changes to an existing "VEVENT", "VTODO",
"VJOURNAL" calendar component and redistribute the updates to the
"Attendees". An iCalendar object that maliciously changes or cancels
an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar
component might be constructed by someone other than the "Organizer"
and sent to the "Attendees". In addition in this memo, other than the
"Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL"
calendar component is the only other person authorized to update any
parameter associated with their "ATTENDEE" property and send it to
the "Organizer". An iCalendar object that maliciously changes the
"ATTENDEE" parameters can be constructed by someone other than the
real "Attendee" and sent to the "Organizer".
Dawson & Stenerson Standards Track [Page 10]
RFC 2445 iCalendar November 1998
PROCEDURAL ALARMS - - An iCalendar object can be created that
contains a "VEVENT" and "VTODO" calendar component with "VALARM"
calendar components. The "VALARM" calendar component can be of type
PROCEDURE and can have an attachment containing some sort of
executable program. Implementations that incorporate these types of
alarms are subject to any virus or malicious attack that might occur
as a result of executing the attachment.
ATTACHMENTS - - An iCalendar object can include references to Uniform
Resource Locators that can be programmed resources.
Implementers and users of this memo should be aware of the network
security implications of accepting and parsing such information. In
addition, the security considerations observed by implementations of
electronic mail systems should be followed for this memo.
3.6 Interoperability Considerations
This MIME content type is intended to define a common format for
conveying calendaring and scheduling information between different
systems. It is heavily based on the earlier [VCAL] industry
specification.
3.7 Applications Which Use This Media Type
This content-type is designed for widespread use by Internet
calendaring and scheduling applications. In addition, applications in
the workflow and document management area might find this content-
type applicable. The [ITIP] and [IMIP] Internet protocols directly
use this content-type also. Future work on an Internet calendar
access protocol will utilize this content-type too.
3.8 Additional Information
This memo defines this content-type.
3.9 Magic Numbers
None.
3.10 File Extensions
The file extension of "ics" is to be used to designate a file
containing (an arbitrary set of) calendaring and scheduling
information consistent with this MIME content type.
Dawson & Stenerson Standards Track [Page 11]
RFC 2445 iCalendar November 1998
The file extension of "ifb" is to be used to designate a file
containing free or busy time information consistent with this MIME
content type.
Macintosh file type codes: The file type code of "iCal" is to be used
in Apple MacIntosh operating system environments to designate a file
containing calendaring and scheduling information consistent with
this MIME media type.
The file type code of "iFBf" is to be used in Apple MacIntosh
operating system environments to designate a file containing free or
busy time information consistent with this MIME media type.
3.11 Contact for Further Information:
Frank Dawson
6544 Battleford Drive
Raleigh, NC 27613-3502
919-676-9515 (Telephone)
919-676-9564 (Data/Facsimile)
[email protected] (Internet Mail)
Derik Stenerson
One Microsoft Way
Redmond, WA 98052-6399
425-936-5522 (Telephone)
425-936-7329 (Facsimile)
[email protected] (Internet Mail)
3.12 Intended Usage
COMMON
3.13 Authors/Change Controllers
Frank Dawson
6544 Battleford Drive
Raleigh, NC 27613-3502
919-676-9515 (Telephone)
919-676-9564 (Data/Facsimile)
[email protected] (Internet Mail)
Derik Stenerson
One Microsoft Way
Redmond, WA 98052-6399
425-936-5522 (Telephone)
425-936-7329 (Facsimile)
[email protected] (Internet Mail)
Dawson & Stenerson Standards Track [Page 12]
RFC 2445 iCalendar November 1998
4 iCalendar Object Specification
The following sections define the details of a Calendaring and
Scheduling Core Object Specification. This information is intended to
be an integral part of the MIME content type registration. In
addition, this information can be used independent of such content
registration. In particular, this memo has direct applicability for
use as a calendaring and scheduling exchange format in file-, memory-
or network-based transport mechanisms.
4.1 Content Lines
The iCalendar object is organized into individual lines of text,
called content lines. Content lines are delimited by a line break,
which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
decimal 10).
Lines of text SHOULD NOT be longer than 75 octets, excluding the line
break. Long content lines SHOULD be split into a multiple line
representations using a line "folding" technique. That is, a long
line can be split between any two characters by inserting a CRLF
immediately followed by a single linear white space character (i.e.,
SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
of CRLF followed immediately by a single linear white space character
is ignored (i.e., removed) when processing the content type.
For example the line:
DESCRIPTION:This is a long description that exists on a long line.
Can be represented as:
DESCRIPTION:This is a lo
ng description
that exists on a long line.
The process of moving from this folded multiple line representation
to its single line representation is called "unfolding". Unfolding is
accomplished by removing the CRLF character and the linear white
space character that immediately follows.
When parsing a content line, folded lines MUST first be unfolded
according to the unfolding procedure described above. When generating
a content line, lines longer than 75 octets SHOULD be folded
according to the folding procedure described above.
Dawson & Stenerson Standards Track [Page 13]
RFC 2445 iCalendar November 1998
The content information associated with an iCalendar object is
formatted using a syntax similar to that defined by [RFC 2425]. That
is, the content information consists of CRLF-separated content lines.
The following notation defines the lines of content in an iCalendar
object:
contentline = name *(";" param ) ":" value CRLF
; This ABNF is just a general definition for an initial parsing
; of the content line into its property name, parameter list,
; and value string
; When parsing a content line, folded lines MUST first
; be unfolded according to the unfolding procedure
; described above. When generating a content line, lines
; longer than 75 octets SHOULD be folded according to
; the folding procedure described above.
name = x-name / iana-token
iana-token = 1*(ALPHA / DIGIT / "-")
; iCalendar identifier registered with IANA
x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
; Reservered for experimental use. Not intended for use in
; released products.
vendorid = 3*(ALPHA / DIGIT) ;Vendor identification
param = param-name "=" param-value
*("," param-value)
; Each property defines the specific ABNF for the parameters
; allowed on the property. Refer to specific properties for
; precise parameter ABNF.
param-name = iana-token / x-token
param-value = paramtext / quoted-string
paramtext = *SAFE-CHAR
value = *VALUE-CHAR
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
NON-US-ASCII = %x80-F8
; Use restricted by charset parameter
; on outer MIME object (UTF-8 preferred)
Dawson & Stenerson Standards Track [Page 14]
RFC 2445 iCalendar November 1998
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
; Any character except CTLs and DQUOTE
SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
/ NON-US-ASCII
; Any character except CTLs, DQUOTE, ";", ":", ","
VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
; Any textual character
CR = %x0D
; carriage return
LF = %x0A
; line feed
CRLF = CR LF
; Internet standard newline
CTL = %x00-08 / %x0A-1F / %x7F
; Controls
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; Quotation Mark
WSP = SPACE / HTAB
SPACE = %x20
HTAB = %x09
The property value component of a content line has a format that is
property specific. Refer to the section describing each property for
a definition of this format.
All names of properties, property parameters, enumerated property
values and property parameter values are case-insensitive. However,
all other property values are case-sensitive, unless otherwise
stated.
Dawson & Stenerson Standards Track [Page 15]
RFC 2445 iCalendar November 1998
4.1.1 List and Field Separators
Some properties and parameters allow a list of values. Values in a
list of values MUST be separated by a COMMA character (US-ASCII
decimal 44). There is no significance to the order of values in a
list. For those parameter values (such as those that specify URI
values) that are specified in quoted-strings, the individual quoted-
strings are separated by a COMMA character (US-ASCII decimal 44).
Some property values are defined in terms of multiple parts. These
structured property values MUST have their value parts separated by a
SEMICOLON character (US-ASCII decimal 59).
Some properties allow a list of parameters. Each property parameter
in a list of property parameters MUST be separated by a SEMICOLON
character (US-ASCII decimal 59).
Property parameters with values containing a COLON, a SEMICOLON or a
COMMA character MUST be placed in quoted text.
For example, in the following properties a SEMICOLON is used to
separate property parameters from each other, and a COMMA is used to
separate property values in a value list.
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
4.1.2 Multiple Values
Some properties defined in the iCalendar object can have multiple
values. The general rule for encoding multi-valued items is to simply
create a new content line for each value, including the property
name. However, it should be noted that some properties support
encoding multiple values in a single property by separating the
values with a COMMA character (US-ASCII decimal 44). Individual
property definitions should be consulted for determining whether a
specific property allows multiple values and in which of these two
forms.
4.1.3 Binary Content
Binary content information in an iCalendar object SHOULD be
referenced using a URI within a property value. That is the binary
content information SHOULD be placed in an external MIME entity that
can be referenced by a URI from within the iCalendar object. In
applications where this is not feasible, binary content information
Dawson & Stenerson Standards Track [Page 16]
RFC 2445 iCalendar November 1998
can be included within an iCalendar object, but only after first
encoding it into text using the "BASE64" encoding method defined in
[RFC 2045]. Inline binary contact SHOULD only be used in applications
whose special circumstances demand that an iCalendar object be
expressed as a single entity. A property containing inline binary
content information MUST specify the "ENCODING" property parameter.
Binary content information placed external to the iCalendar object
MUST be referenced by a uniform resource identifier (URI).
The following example specifies an "ATTACH" property that references
an attachment external to the iCalendar object with a URI reference:
ATTACH:http://xyz.com/public/quarterly-report.doc
The following example specifies an "ATTACH" property with inline
binary encoded content information:
ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
<...remainder of "BASE64" encoded binary data...>
4.1.4 Character Set
There is not a property parameter to declare the character set used
in a property value. The default character set for an iCalendar
object is UTF-8 as defined in [RFC 2279].
The "charset" Content-Type parameter can be used in MIME transports
to specify any other IANA registered character set.
4.2 Property Parameters
A property can have attributes associated with it. These "property
parameters" contain meta-information about the property or the
property value. Property parameters are provided to specify such
information as the location of an alternate text representation for a
property value, the language of a text property value, the data type
of the property value and other attributes.
Property parameter values that contain the COLON (US-ASCII decimal
58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44)
character separators MUST be specified as quoted-string text values.
Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII
decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22)
character is used as a delimiter for parameter values that contain
restricted characters or URI text. For example:
Dawson & Stenerson Standards Track [Page 17]
RFC 2445 iCalendar November 1998
DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
Conference - - Las Vegas, NV, USA
Property parameter values that are not in quoted strings are case
insensitive.
The general property parameters defined by this memo are defined by
the following notation:
parameter = altrepparam ; Alternate text representation
/ cnparam ; Common name
/ cutypeparam ; Calendar user type
/ delfromparam ; Delegator
/ deltoparam ; Delegatee
/ dirparam ; Directory entry
/ encodingparam ; Inline encoding
/ fmttypeparam ; Format type
/ fbtypeparam ; Free/busy time type
/ languageparam ; Language for text
/ memberparam ; Group or list membership
/ partstatparam ; Participation status
/ rangeparam ; Recurrence identifier range
/ trigrelparam ; Alarm trigger relationship
/ reltypeparam ; Relationship type
/ roleparam ; Participation role
/ rsvpparam ; RSVP expectation
/ sentbyparam ; Sent by
/ tzidparam ; Reference to time zone object
/ valuetypeparam ; Property value data type
/ ianaparam
; Some other IANA registered iCalendar parameter.
/ xparam
; A non-standard, experimental parameter.
ianaparam = iana-token "=" param-value *("," param-value)
xparam =x-name "=" param-value *("," param-value)
4.2.1 Alternate Text Representation
Parameter Name: ALTREP