idnits 2.17.1
draft-ietf-calsch-many-xcal-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 21 instances of too long lines in the document, the longest
one being 12 characters in excess of 72.
** The abstract seems to contain references ([RFC2119], [XML], [RFC2445]),
which it shouldn't. Please replace those with straight textual mentions
of the documents in question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords -- however, there's a paragraph with a matching beginning.
Boilerplate error?
RFC 2119 keyword, line 142: '... use namespaces MUST NOT include othe...'
RFC 2119 keyword, line 180: '... This FPI MUST be used on the DOCTYP...'
RFC 2119 keyword, line 183: '... This FPI SHOULD also be used to ide...'
RFC 2119 keyword, line 214: '... MUST be able to properly parse and ...'
RFC 2119 keyword, line 218: '...orming to this memo MUST only send the...'
(19 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 459 has weird spacing: '...alendar xmln...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 15, 2002) is 8104 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? 'XML' on line 1992 looks like a reference
-- Missing reference section? 'RFC 2445' on line 1985 looks like a reference
-- Missing reference section? 'RFC 2119' on line 1981 looks like a reference
-- Missing reference section? 'RFC 2146' on line 130 looks like a reference
-- Missing reference section? 'XMLNS' on line 671 looks like a reference
-- Missing reference section? 'RFC2445' on line 242 looks like a reference
-- Missing reference section? 'RFC 2045' on line 1977 looks like a reference
-- Missing reference section? 'ISO 9070' on line 1928 looks like a reference
-- Missing reference section? 'FPI' on line 1967 looks like a reference
-- Missing reference section? 'ISO9070' on line 1972 looks like a reference
Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group F Dawson
3 Internet-Draft Nokia Corporation
4 Expires: August 16, 2002 S Reddy
5 Oracle
6 D Royer
7 INET-Consulting LLC
8 E Plamondon
9 Steltor
10 February 15, 2002
12 iCalendar DTD Document (xCal)
13 draft-ietf-calsch-many-xcal-01
15 Status of this Memo
17 This document is an Internet-Draft and is in full conformance with
18 all provisions of Section 10 of RFC2026.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as
23 Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six
26 months and may be updated, replaced, or obsoleted by other documents
27 at any time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 To view the entire list of Internet-Draft Shadow Directories, see
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on August 16, 2002.
35 Copyright Notice
37 Copyright (C) The Internet Society (2002). All Rights Reserved.
39 Abstract
41 This memo defines a [XML] Document Type Definition (DTD) that
42 corresponds to the iCalendar, Internet Calendaring and Scheduling
43 Core Object Specification defined by [RFC 2445]. This DTD provides
44 equivalent functionality to the standard format defined by [RFC
45 2445]. Documents structured in accordance with this DTD may also be
46 known as "XML iCalendar" documents or "xCal".
48 The mailing list for discussion of this memo is
49 "ietf-calendar@imc.org". Send an email to
50 "ietf-calendar-request@imc.org" with the message "SUBSCRIBE" to add
51 your email address to this mailing list. Send an email to
52 "ietf-calendar-request@imc.org" with the message "UNSUBSCRIBE" to
53 remove your email address from this mailing list.
55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
57 document are to be interpreted as described in [RFC 2119].
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
62 2. Using XML For Representating iCalendar . . . . . . . . . . . 6
63 2.1 XML Dependencies . . . . . . . . . . . . . . . . . . . . . . 6
64 2.2 Document Type Definition . . . . . . . . . . . . . . . . . . 6
65 2.3 Working With Standard and XML iCalendar Representations . . 6
66 2.3.1 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 6
67 2.3.2 Mixed Use of Both Representations . . . . . . . . . . . . . 7
68 2.4 Using Data Types . . . . . . . . . . . . . . . . . . . . . . 7
69 2.5 Including Binary Content . . . . . . . . . . . . . . . . . . 8
70 2.6 Including Multiple iCalendar Objects . . . . . . . . . . . . 9
71 2.7 Mapping Property Parameters to XML . . . . . . . . . . . . . 10
72 2.8 Mapping Calendar Properties to XML . . . . . . . . . . . . . 11
73 2.9 Mapping Component Properties to XML . . . . . . . . . . . . 13
74 2.10 Parameter Entities . . . . . . . . . . . . . . . . . . . . . 16
75 2.11 Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 17
76 2.12 Emailing the iCalendar XML Representation . . . . . . . . . 17
77 2.13 iCalendar XML Representation and File Systems . . . . . . . 18
78 3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . 19
79 3.1 A well-formed and valid iCalendar XML document . . . . . . . 19
80 3.2 Adding non-standard, experimental extensions . . . . . . . . 19
81 3.3 Including binary content in attachments . . . . . . . . . . 20
82 3.4 iCalendar XML document with multiple iCalendar objects . . . 22
83 3.5 Using the iCalendar namespace . . . . . . . . . . . . . . . 23
84 3.6 Publish meeting information . . . . . . . . . . . . . . . . 24
85 3.7 Publish transparent annual event . . . . . . . . . . . . . . 24
86 3.8 Meeting invitation . . . . . . . . . . . . . . . . . . . . . 25
87 3.9 Assign a to-do . . . . . . . . . . . . . . . . . . . . . . . 26
88 3.10 Publish a journal entry . . . . . . . . . . . . . . . . . . 27
89 3.11 Publish busy time . . . . . . . . . . . . . . . . . . . . . 27
90 3.12 Request busy time . . . . . . . . . . . . . . . . . . . . . 28
91 3.13 Response to a busy time request . . . . . . . . . . . . . . 28
92 3.14 Published event that references time zone information . . . 29
93 3.15 An event with an alarm . . . . . . . . . . . . . . . . . . . 30
94 4. iCalendar XML Document Type Definition . . . . . . . . . . . 32
95 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 45
96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
97 7. Security Considerations . . . . . . . . . . . . . . . . . . 47
98 8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 48
99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
100 Full Copyright Statement . . . . . . . . . . . . . . . . . . 50
102 1. Introduction
104 The Extended Markup Language (XML) as defined in [XML] is gaining
105 widespread attention as a "web friendly" syntax for representing and
106 exchanging documents and data on the Internet. This interest
107 includes requests for and discussion of possible document type
108 definitions (DTD) and name-space for IETF standard formats such as
109 that defined by [RFC 2445].
111 This memo defines how XML can be used to represent iCalendar
112 objects. This memo includes the definition of the XML DTD for a XML
113 document representation of an iCalendar object.
115 NOTE: The [RFC 2445] is the definitive reference for the definition
116 of iCalendar semantics. This memo only provides an alternative, XML
117 representation for the standard syntax defined in [RFC 2445]. This
118 memo does not introduce any semantics not already defined by [RFC
119 2445].
121 An attempt has been made to leverage the standard features of the
122 XML syntax in order to represent the component iCalendar semantics.
123 For example, strong data typing is specified using the XML notation
124 declaration. The element type attributes are used to represent many
125 of the calendar properties that provide a "global attribute"
126 capability in an iCalendar object. Binary content in the ATTACH
127 component property may either be specified through an external
128 entity reference to a non-XML binary content or may be included in
129 the XML document's content information, after first being encoding
130 using the BASE64 scheme of [RFC 2146]. Parameter entities are used
131 to logically group content particles in the XML DTD in order to
132 facilitate reading and comprehension of the structure specified by
133 the iCalendar XML DTD.
135 The publication of XML version 1.0 was followed by the publication
136 of a World-wide Web Consortium (W3C) recommendation on "Namespaces
137 in XML". A XML name-space is a collection of names, identified by a
138 URI. In anticipation of the broader use of XML namespaces, this memo
139 includes the definition of the URI to be used to identify the
140 namespace associated with the iCalendar DTD element types in other
141 XML documents. XML applications that conform to this memo and also
142 use namespaces MUST NOT include other non-iCalendar namespaces in an
143 iCalendar XML document.
145 It is expected that the DTD defined in this memo will not normally
146 be included with iCalendar XML documents that are distributed.
147 Instead, the DTD will be referenced in the document type declaration
148 in the document entity. Such iCalendar XML documents will be
149 well-formed and valid, as defined in [XML]. In addition, other
150 iCalendar XML documents will be specified that do not include the
151 XML prolog. Such iCalendar XML documents will be well-formed but not
152 valid.
154 2. Using XML For Representating iCalendar
156 XML is a simplified version of the text markup syntax defined by ISO
157 8879, Standard Generalized Markup Language (SGML). XML was published
158 as a proposed recommendation [XML] by the World-wide Web Consortium
159 (W3C) on February 10, 1998.
161 2.1 XML Dependencies
163 This memo specifies the XML representation for the standard
164 iCalendar format defined by [RFC 2445]. There are no XML
165 dependencies other than the [XML] and the [XMLNS] recommendations.
167 2.2 Document Type Definition
169 A XML DTD for iCalendar is defined by the DTD specified in section
170 3.
172 The formal public identifier (FPI) for the DTD is:
174 -//IETF//DTD XCAL//iCalendar XML//EN
176 NOTE: The "DTD XCAL" text in the FPI value will be replaced with the
177 text "RFC xxxx", where "xxxx" is the RFC number, when the memo is
178 published as a RFC.
180 This FPI MUST be used on the DOCTYPE statement within a XML document
181 referencing the DTD defined by this memo.
183 This FPI SHOULD also be used to identify iCalendar XML documents
184 within operating system registries of file, clipboard and
185 interactive rendering (e.g., memory clipboard or drag/drop) formats.
187 2.3 Working With Standard and XML iCalendar Representations
189 This memo defines an alternative, XML representation for the
190 standard iCalendar format defined in [RFC 2445]. This alternative
191 representation provides the same semantics as that defined in the
192 standard format.
194 2.3.1 Conversion
196 The standard format can be converted to and from this XML format
197 without loss of any calendaring information. When the XML
198 representation was defined, every attempt was made to use existing
199 component, property and parameter naming conventions. This greatly
200 facilitates transformations between the two representations.
202 2.3.2 Mixed Use of Both Representations
204 As previously indicated, conversion between the standard and XML
205 representations of iCalendar is a straightforward process. In
206 addition, mixed use of both representations is also possible.
208 With the use of the MIME multipart content-types, compound MIME
209 entities containing a mix of the standard and XML representations
210 can be specified. This capability is useful in applications where
211 both representations might be encountered. In addition, this
212 capability demonstrates the isomeric nature of the two
213 representations. XML applications conforming to this specification
214 MUST be able to properly parse and process a MIME multipart entity
215 containing the MIME type associated with this iCalendar XML document
216 type.
218 Internet applications conforming to this memo MUST only send the
219 iCalendar XML document in a "multipart/alternative" MIME entity that
220 also contains an equivalent iCalendar object in the standard format
221 defined by [RFC2445]. This restriction will guarantee that the
222 iCalendar object can also be processed by Internet applications that
223 only support the standard iCalendar representation.
225 2.4 Using Data Types
227 Strong "data typing" is an integral design principle to the
228 iCalendar format. Strong data typing in iCalendar means that the
229 format type for each property value is well known. Within [RFC
230 2445], the data type is called the "value type". The standard format
231 defined by [RFC 2445] specifies a default value type for each
232 calendar and component property. In addition, many of the property
233 definitions allow for the specification of alternate value types.
234 This XML representation continues this design principle.
236 Explicit value/data typing in the XML representation is specified
237 with the "value" attribute on each element type. In addition, the
238 XML DTD specifies a default value/data type for each element type.
239 XML documents conforming to this memo need only specify the "value"
240 attribute on element types when the value needs to override the
241 default value/data type. The standard value types defined in
242 [RFC2445] are specified in the XML DTD by individual NOTATION
243 declarations. The formal public identifier for standard value types
244 all have the common string format of:
246 -//IETF//NOTATION XCAL/Value Type/xxx//EN
248 NOTE: The "XCAL" text in the FPI value will be replaced with the
249 text "RFC xxxx", where "xxxx" is the RFC number, when the memo is
250 published as a RFC.
252 Where "xxx" is replaced with the text specified in the table below.
254 The following table specifies the XML value/data type that
255 corresponds to each of the standard value types defined in [RFC
256 2445].
258 +--------------+------------+-------------------------+
259 | RFC 2445 | XML Value | Notation FPI Text |
260 | Value Type | Type | |
261 +--------------+------------+-------------------------+
262 | BINARY | BINARY | Binary |
263 | BOOLEAN | BOOLEAN | Boolean |
264 | CALADR | CALADR | Calendar User Address |
265 | DATE | DATE | Date |
266 | DATE-TIME | DATE-TIME | Date-Time |
267 | DURATION | DURATION | Duration |
268 | FLOAT | FLOAT | Float |
269 | INTEGER | INTEGER | Integer |
270 | PERIOD | PERIOD | Period of Time |
271 | RECUR | RECUR | Recurrence Rule |
272 | TEXT | TEXT | Text |
273 | TIME | TIME | Time |
274 | URI | URI | URI |
275 | UTC-OFFSET | UTC-OFFSET | UTC-Offset |
276 | Non-standard | X-NAME | X-Name |
277 +--------------+------------+-------------------------+
279 Other standard XML data types can be specified by including a
280 NOTATION declaration that specifies the formal public identifier
281 associated with the other standard format. In addition, the name of
282 the format specified in the NOTATION declaration is specified in the
283 "value" attribute of any element type that caste to the other
284 standard format.
286 2.5 Including Binary Content
288 Binary content can be included in an iCalendar object with the
289 "ATTACH" component property. In the standard iCalendar format this
290 content may either be specified through an external entity
291 reference, using a URI value type, or maybe specified within the
292 iCalendar object, after first BASE64 encoding the content.
294 The XML representation for iCalendar also supports including binary
295 content in an iCalendar object with the "attach" element type. It
296 also supports either an external reference to the non-XML binary
297 content or inclusion of the binary content after first encoding the
298 binary information using the BASE64 encoding of [RFC 2045].
300 Any iCalendar properties defined in [RFC 2445] that can be used to
301 include binary content are defined in the XML representation as an
302 element type with a content model that consists of either the
303 "extref" or the "b64bin" element type. The "extref" element type is
304 used to reference an external entity containing the binary content.
305 An external reference to the binary content is specified by the
306 "uri" attribute on the "extref" element type. For every external
307 reference, an ENTITY declaration and a corresponding NOTATION
308 declaration MUST also be specified in an internal DTD to identify
309 the location and format of the external entity. For example, the
310 following XML snippets would be needed to include a reference to the
311 executable "foo.exe" in the "attach" element type; which corresponds
312 to the "ATTACH" iCalendar component property:
314
316
317
319
321
323 The "b64bin" element type is used to include the binary content
324 within the XML document, after first character encoding the binary
325 information using the BASE64 encoding method of [RFC 2045]. For
326 example, the following XML snippets would be needed to include the
327 executable "foo.exe" in the "attach" element type; after first
328 BASE64 encoding the binary information:
330
332 MIICajCC
333 AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
334 dHNjYXBlIENvbW11bmljYXR5z...and so on...IENvcnBvc==
335
337 2.6 Including Multiple iCalendar Objects
339 The iCalendar format has the capability for including multiple,
340 individual iCalendar objects in a single data stream. The XML
341 representation can support this also. Individual iCalendar objects
342 are specified by the "vcalendar" element type. One or more
343 "vcalendar" element types are permitted within the parent element
344 type, called "iCalendar". For example:
346
347
348
349
351
352
353
354
356 2.7 Mapping Property Parameters to XML
358 The property parameters defined in the standard iCalendar format are
359 represented in the XML representation as an attribute on element
360 types. The following table specifies the attribute name
361 corresponding to each property parameter.
363 +----------------+----------------+-----------+-----------------+
364 | Property | Attribute | Attribute | Default |
365 | Parameter Name | Name | Type | Value |
366 +----------------+----------------+-----------+-----------------+
367 | ALTREP | altrep | ENTITY | IMPLIED |
368 | CN | cn | CDATA | Null String |
369 | CUTYPE | cutype | NMTOKEN | INDIVIDUAL |
370 | DELEGATED-FROM | delegated-from | CDATA | IMPLIED |
371 | DELEGATED-TO | delegated-to | CDATA | IMPLIED |
372 | DIR | dir | ENTITY | IMPLIED |
373 | ENCODING | Not Used | n/a | n/a |
374 | FMTTYPE | fmttype | CDATA | REQUIRED |
375 | FBTYPE | fbtype | NMTOKEN | BUSY |
376 | LANGUAGE | language | CDATA | IMPLIED |
377 | MEMBER | member | CDATA | IMPLIED |
378 | PARTSTAT | partstat | NMTOKEN | NEEDS-ACTION |
379 | RANGE | range | NMTOKEN | THISONLY |
380 | RELATED | related | NMTOKEN | START |
381 | RELTYPE | reltype | NMTOKEN | PARENT |
382 | ROLE | role | NMTOKEN | REQ-PARTICIPANT |
383 | RSVP | rsvp | NMTOKEN | FALSE |
384 | SENT-BY | sent-by | CDATA | IMPLIED |
385 | TZID | tzid | CDATA | IMPLIED |
386 | VALUE | value | NOTATION | See elements |
387 +----------------+----------------+-----------+-----------------+
389 The inline "ENCODING" property parameter is not needed in the XML
390 representation. Inline binary information is always included as
391 parsable character data, after first being encoded using the BASE64
392 encoding of [RFC 2045].
394 The "RANGE" property parameter defined by [RFC 2445] does not
395 include the "THISONLY" enumeration. This is the implicit default, if
396 the parameter is not specified on the "RECURRENCE-ID" property.
397 However, the value is needed in the XML representation because all
398 attributes need to explicitly specify a default value in the
399 attribute's declaration in the DTD. This enumeration has been added
400 to the XML representation.
402 A non-standard, experimental parameter can be added to the XML
403 representation by declaring it in an ATTLIST declaration and
404 assigning it a XML attribute type and corresponding default value.
406 2.8 Mapping Calendar Properties to XML
408 Calendar properties defined in the standard iCalendar format provide
409 information about an iCalendar object, as a whole. The calendar
410 properties are represented in the XML representation as an attribute
411 on the "iCalendar" and the "vcalendar" element type. The following
412 table specifies the attribute name permitted on the "iCalendar"
413 element type.
415 +---------------+-----------+-----------+-----------------+
416 | Calendar | Attribute | Attribute | Default |
417 | Property Name | Name | Type | Value |
418 +---------------+-----------+-----------+-----------------+
419 | CALSCALE | calscale | CDATA | IMPLIED |
420 | METHOD | method | NMTOKEN | PUBLISH |
421 | VERSION | version | CDATA | REQUIRED |
422 | PRODID | prodid | CDATA | IMPLIED |
423 +---------------+-----------+-----------+-----------------+
425 In addition to these attributes, the "vcalendar" element type can
426 also have the following attributes:
428 +-----------+-----------+---------+----------------------------+
429 | Attribute | Attribute | Default | Description |
430 | Name | Type | Value | |
431 +-----------+-----------+---------+----------------------------+
432 | xmlns | CDATA | FIXED | Used to specify the default|
433 | | | | iCalendar XML name space. |
434 | xmlns: + | CDATA | FIXED | Used to specify the |
435 | | | | |
437 +-----------+-----------+---------+----------------------------+
439 The semantics of the "xmlns" attribute, and any attribute with
440 "xmlns:" as a prefix, is as specified in [XMLNS]. It is used to
441 declare a namespace in XML. It can be used to declare the iCalendar
442 XML namespace in a XML document with a document type other than the
443 iCalendar XML document type. The iCalendar XML document type MUST
444 only use element types from the iCalendar namespace. Non-standard,
445 experimental element types and attributes lists MUST only be
446 specified by declarations in an internal DTD within the iCalendar
447 XML document. To specify the iCalendar namespace, the attribute
448 value for the "xmlns" and any attribute with the prefix "xmlns:"
449 MUST be:
451 'http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt'
453 NOTE: This attribute value will be replaced with the URL
454 "http://www.ietf.org/rfc/rfcxxxx.txt", where "xxxx" is the RFC
455 number, when this memo is published as a RFC.
457 For example:
459
461
464
466 The following table specifies the attribute name corresponding to
467 each calendar property. These attributes are only permitted on the
468 "vcalendar" element type.
470 +---------------+-----------+-----------+-----------------+
471 | Calendar | Attribute | Attribute | Default |
472 | Property Name | Name | Type | Value |
473 +---------------+-----------+-----------+-----------------+
474 | CALSCALE | calscale | CDATA | IMPLIED |
475 | METHOD | method | NMTOKEN | PUBLISH |
476 | VERSION | version | CDATA | REQUIRED |
477 | PRODID | prodid | CDATA | IMPLIED |
478 +---------------+-----------+-----------+-----------------+
480 The semantics for these attributes is as specified for the
481 corresponding calendar property in [RFC 2445].
483 The following table specifies additional attributes that are
484 permitted on the "vcalendar" element type.
486 +-----------+-----------+---------+----------------------------+
487 | Attribute | Attribute | Default | Description |
488 | Name | Type | Value | |
489 +-----------+-----------+---------+----------------------------+
490 | language | CDATA | IMPLIED | Used to specify the default|
491 +-----------+-----------+---------+----------------------------+
493 The "language" attribute permits the default language to be
494 specified for the whole iCalendar object. If the "language"
495 attribute is specified on the XML document, then if the XML
496 representation is converted into the standard format the "LANGUAGE"
497 property parameter MUST be specified on each TEXT valued property to
498 prevent information loss; when translating into the standard format.
500 2.9 Mapping Component Properties to XML
502 Component properties in the standard iCalendar format provide
503 calendar information about the calendar component. The component
504 properties defined in the standard iCalendar format are represented
505 in the XML representation as element types. The following tables
506 specify the element types corresponding to each of the properties in
507 the specified property category.
509 Descriptive Component Properties
510 +----------------+-------------+-----------------------------+
511 | Component | Element | Element Content Model |
512 | Property Name | Name | |
513 +----------------+-------------+-----------------------------+
514 | ATTACH | attach | extref or b64bin |
515 | | extref | EMPTY |
516 | | b64bin | PCDATA |
517 | CATEGORIES | categories | Any number of item elements |
518 | | item | PCDATA |
519 | CLASS | class | PCDATA |
520 | COMMENT | comment | PCDATA |
521 | DESCRIPTION | description | PCDATA |
522 | GEO | geo | lat followed by lon element |
523 | | lat | PCDATA |
524 | | lon | PCDATA |
525 | LOCATION | location | PCDATA |
526 | PERCENT | percent | PCDATA |
527 | PRIORITY | priority | PCDATA |
528 | RESOURCES | resources | Any number of item elements |
529 | STATUS | status | PCDATA |
530 | SUMMARY | summary | PCDATA |
531 +----------------+-------------+-----------------------------+
533 Date and Time Component Properties
534 +----------------+------------+-----------------------------+
535 | Component | Element | Element Content Model |
536 | Property Name | Name | |
537 +----------------+------------+-----------------------------+
538 | COMPLETED | completed | PCDATA |
539 | DTEND | dtend | PCDATA |
540 | DUE | due | PCDATA |
541 | DTSTART | dtstart | PCDATA |
542 | DURATION | duration | PCDATA |
543 | FREEBUSY | freebusy | PCDATA |
544 | TRANSP | transp | PCDATA |
545 +----------------+------------+-----------------------------+
547 Time Zone Component Properties
548 +----------------+-------------+-----------------------------+
549 | Component | Element | Element Content Model |
550 | Property Name | Name | |
551 +----------------+-------------+-----------------------------+
552 | TZID | tzid | PCDATA |
553 | TZNAME | tzname | PCDATA |
554 | TZOFFSETFROM | tzoffsetfrom| PCDATA |
555 | TZOFFSETTO | tzoffsetto | PCDATA |
556 | TZURL | tzurl | EMPTY |
557 +----------------+-------------+-----------------------------+
559 Relationship Component Properties
560 +----------------+---------------+--------------------------+
561 | Component | Element | Element Content Model |
562 | Property Name | Name | |
563 +----------------+---------------+--------------------------+
564 | ATTENDEE | attendee | PCDATA |
565 | CONTACT | contact | PCDATA |
566 | ORGANIZER | organizer | PCDATA |
567 | RECURRENCE-ID | recurrence-id | PCDATA |
568 | RELATED-TO | related-to | PCDATA |
569 | URL | url | EMPTY |
570 | UID | uid | PCDATA |
571 +----------------+---------------+--------------------------+
573 Recurrence Component Properties
574 +----------------+------------+-----------------------------+
575 | Component | Element | Element Content Model |
576 | Property Name | Name | |
577 +----------------+------------+-----------------------------+
578 | EXDATE | exdate | PCDATA |
579 | EXRULE | exrule | PCDATA |
580 | RDATE | rdate | PCDATA |
581 | RRULE | rrule | PCDATA |
582 +----------------+------------+-----------------------------+
584 Alarm Component Properties
585 +----------------+------------+-----------------------------+
586 | Component | Element | Element Content Model |
587 | Property Name | Name | |
588 +----------------+------------+-----------------------------+
589 | ACTION | action | PCDATA |
590 | REPEAT | repeat | PCDATA |
591 | TRIGGER | trigger | PCDATA |
592 +----------------+------------+-----------------------------+
594 Change Management Component Properties
595 +----------------+---------------+--------------------------+
596 | Component | Element | Element Content Model |
597 | Property Name | Name | |
598 +----------------+---------------+--------------------------+
599 | CREATED | created | PCDATA |
600 | DTSTAMP | dtstamp | PCDATA |
601 | LAST-MODIFIED | last-modified | PCDATA |
602 | SEQUENCE | sequence | PCDATA |
603 +----------------+---------------+--------------------------+
605 Miscellaneous Component Properties
606 +----------------+----------------+-------------------------+
607 | Component | Element | Element Content Model |
608 | Property Name | Name | |
609 +----------------+----------------+-------------------------+
610 | REQUEST-STATUS | request-status | PCDATA |
611 +----------------+----------------+-------------------------+
613 The following table specifies the element types that represent each
614 of the calendar components.
616 Component Structuring Properties
617 +----------------+------------+-------------------------------+
618 | Component | Element | Element Content Model |
619 | Property Name | Name | |
620 +----------------+------------+-------------------------------+
621 | Multiple iCal- | iCalendar | One or more iCal elements |
622 | endar objects | | |
623 | VCALENDAR | vcalendar | calcomp parameter entity |
624 | VEVENT | vevent | vevent.opt1 and vevent.optm |
625 | | | parameter entity and valarm |
626 | | | element |
627 | VTODO | vtodo | vtodo.opt1 and vtodo.optm |
628 | | | parameter entity and valarm |
629 | | | element |
630 | VJOURNAL | vjournal | vjournal.opt1 and |
631 | | | vjournal.optm parameter |
632 | | | entity |
633 | VFREEBUSY | vfreebusy | vfreebusy.opt1 and |
634 | | | vfreebusy.optm parameter |
635 | | | entity |
636 | VTIMEZONE | vtimezone | vtimezone.man, |
637 | | | vtimezone.opt1, |
638 | | | vtimezone.mann parameter |
639 | | | entity |
640 | STANDARD | standard | standard.man or standard.optm |
641 | | | entity |
642 | DAYLIGHT | daylight | daylight.man or daylight.optm |
643 | | | entity |
644 | VALARM | valarm | valarm.audio, valarm.display, |
645 | | | valarm.email and |
646 | | | valarm.procedure entity |
647 +----------------+------------+-------------------------------+
649 The [RFC 2445] specification specifies that the equivalent component
650 properties to the "comment", "description", "location", "summary"
651 and "contact" element types can contain formatted content, such as
652 is specified by multiple lines of text. In such cases, the formatted
653 text should be specified in as CDATA Section content. The CDATA
654 section specifies arbitrary character data that is not meant to be
655 interpretted. It is not scanned for markup by the XML parser. The
656 CDATA Section in these element types MUST NOT contain markup or
657 other such alternate representation of the property value. The
658 "altrep" attribute is used to reference any such alternate
659 representation for the textual content of these element types.
661 2.10 Parameter Entities
663 The external, iCalendar XML DTD specified in section 3 makes use of
664 parameter entity declarations. This XML feature is used to group
665 declarations within the DTD. This technique has been used in DTD
666 design in order to facilitate the reading and comprehension of the
667 structure specified by the DTD.
669 2.11 Namespace
671 [XMLNS] defines "Namespaces in XML" to be a collection of names,
672 identified by a URI, which are used in XML documents as element
673 types and attribute names. The [XML] specification does not include
674 a definition for namespaces, but does set down some guidelines for
675 experimental naming of namespaces.
677 XML namespaces allow multiple markup vocabulary in a single
678 document. Considering the utility of the iCalendar properties in
679 other applications, it is important for the iCalendar XML DTD to
680 define a namespace for the iCalendar element types.
682 This memo defines the value that MUST be used in non-iCalendar XML
683 documents that reference element types or attribute lists from the
684 iCalendar namespace.
686 The following is an example of a well-formed but invalid "xdoc"
687 document type that includes elements and attribute lists from the
688 iCalendar namespace:
690
691
692
695
696
698
699
701 2.12 Emailing the iCalendar XML Representation
703 It is expected that iCalendar XML documents will need to be sent
704 over SMTP/MIME email. The "text/xml" and "application/xml"
705 content-types have been registered for XML documents. However, use
706 of these content-type definitions present some problems for XML
707 applications such as calendaring and scheduling.
709 The "text/xml" and "application/xml" content-type definitions do not
710 provide for any header field parameters to identify the type of XML
711 document contained in the MIME entity. This means that a recipient
712 mail user agent must (MUA) open up each "text/xml" or
713 "application/xml" content in order to determine what object handler
714 is needed to process the information. To a MUA, all XML documents
715 look like just plain "text/xml" or "application/xml" content.
717 Additionally, it is accepted practice for a MUA to provide iconic
718 feedback to the user for individual content-types that are supported
719 by the MUA. For example, not only would feedback be provided for a
720 calendaring and scheduling content. Some further unique
721 identification would also be provided for each different scheduling
722 message; such as a meeting invitation, response to an invitation,
723 reschedule notice, cancellation notice, etc. In such cases,
724 acceptable performance by the MUA is dependent on the existence of
725 header field information, such as it provided in the definition of
726 the "text/calendar" content-type by [RFC 2445].
728 Internet application conforming to this memo MUST identify iCalendar
729 XML documents with the experimental content-type
730 "application/calendar+xml". The content-type header field SHOULD
731 also contain a "component" and "method" parameter to clearly
732 identify a comma-separated list of components and the singular
733 method used in the iCalendar XML document. For example, an iCalendar
734 XML document specifying a REQUEST for a VEVENT and VTODO would be
735 specified with the following content-type header field:
737 content-type:application/calendar+xml;method=REQUEST;component=VEVENT,VTODO
739 The content-type can also include the "optinfo" parameter to specify
740 any other optional iCalendar information. The semantics of these
741 content-type parameters is as defined in [RFC 2445].
743 Internet applications conforming to this memo MUST only send the
744 iCalendar XML document in a "multipart/alternative" MIME entity that
745 also contains an equivalent iCalendar object in the standard format
746 defined by [RFC 2445]. This restrict will guarantee that the
747 iCalendar object can also be processed by internet applications that
748 only support the standard iCalendar format.
750 An XML application supporting the iCalendar XML document type MUST
751 be able to receive and properly process the
752 "application/calendar+xml" document contained within a "multipart"
753 message content-type.
755 2.13 iCalendar XML Representation and File Systems
757 The iCalendar XML documents will be stored in file systems. The
758 accepted practice for file extensions for XML documents is the text
759 "XML". However, in order to uniquely identify iCalendar XML
760 documents for file association with applications that can directly
761 process this document type, it is RECOMMENDED that the file
762 extension be the text "XCS".
764 3. Example Usage
766 The following sections provide various examples of iCalendar XML
767 documents.
769 3.1 A well-formed and valid iCalendar XML document
771 The following is a simple example of a iCalendar XML document. This
772 document is both a well-formed and valid XML document. The iCalendar
773 object specifies an appointment.
775
776
779
780
783
784 19981116T150000@cal10.host.com
785 19981116T145958Z
786 Project XYZ Review
787 Conference Room 23A
788 19981116T163000Z
789 19981116T190000Z
790
791 - Appointment
792
793
794
795
797 3.2 Adding non-standard, experimental extensions
799 The following is an example of a valid iCalendar XML document that
800 also includes a non-standard, experimental extension, as provided
801 for by [RFC 2445]. The iCalendar object specifies the publication of
802 a to-do with a non-standard experimental property for a customer
803 charge code.
805 The non-standard experimental property is identified by the "X-"
806 prefix to the element name. All non-standard properties MUST be
807 specified with element types with an "X-" type element name. In
808 addition, a text identifier for the vendor specifying the extension
809 SHOULD be appended to the "X-" text prefix. In this case, the
810 example specifies a "foo" for the name of the vendor specifying the
811 non- standard property.
813
814
824
825
826 ]>
828
829
832
833 19981104T130000@cal1.host.com
834 19981104T125957Z
835 19981105T133000Z
836 19981106T133000Z
837 Draft a test plan
838 1998-ABC Corp-1234
839 1
840
841
842
844 3.3 Including binary content in attachments
846 The following is an example of a valid iCalendar XML document that
847 also includes an external reference to an attachment. The iCalendar
848 object specifies a meeting invitation with an attachment.
850
851
857
859 ]>
861
862
865
866 19981211T133000@cal1.host.com
867 19981211T132928Z
868 jim@host.com
869 19981212T150000Z
870 19981212T160000Z
871 Department Meeting
872 Conference Room 23A
873 jim@host.com
874 MAILTO:joe@host.com
876 MAILTO:steve@host.com
878
879
880
881
883 The following is an example of a well-formed and valid iCalendar XML
884 document that includes an attachment as inline binary content. The
885 iCalendar object specifies a meeting invitation with an attachment.
887
888
891
892
895
896 19981211T133000@cal1.host.com
897 19981211T132928Z
898 MAILTO:jim@host.com
899 19981212T150000Z
900 19981212T160000Z
901 Department Meeting
902 Conference Room 23A
903 MAILTO:jim@host.com
904 MAILTO:joe@host.com
906 MAILTO:steve@host.com
908 MIICajCCAdOgAwIBAgI
909 CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB
910 lIEjYXRpb25z...and so on...IENvcnBvc==
911
912
913
915 3.4 iCalendar XML document with multiple iCalendar objects
917 The following is an example of a well-formed and valid iCalendar XML
918 document that includes more than one iCalendar object.
920
921
924
925
928
929 19981009T233000@cal1.host.com
930 19981009T232928Z
931 19981010T000000Z
932 19981010T235959Z
933 Register for conference
934 2
935
936
937
940
941 19981009T233010@cal1.host.com
942 19981009T233000Z
943 19981120T133000Z
944 19981122T183000Z
945 IT Conference
946 Downtowner Hotel
947
948
949
951 3.5 Using the iCalendar namespace
953 The following is an example of a snippet of a XML document that
954 includes elements from the iCalendar name-space.
956
959 19981123T133000Z
960 19981123T203000Z
961 1234567
962 999.99
963
965 3.6 Publish meeting information
967 The following is a snippet of an iCalendar XML document that
968 publishes information about a meeting. The "method" attribute isn't
969 specified since it is the default value.
971
972
974
975 19970901T130000Z-123401@host.com
976 19970901T130000Z
977 19970903T163000Z
978 19970903T190000Z
979 Annual Employee Review
980 PRIVATE
981
982 - Business
983 - Human Resources
984
985
986
987
989 3.7 Publish transparent annual event
991 The following is a snippet of an iCalendar XML document that
992 publishes information about an annually repeating event that is
993 transparent to busy time searches.
995
996
998
999 19990101T125957Z-123403@host.com
1000 19990101T130000Z
1001 19991102
1002 19991102
1003 Our Blissful Anniversary
1004 CONFIDENTIAL
1005 TRANSPARENT
1006
1007 - Anniversary
1008 - Personal
1009 - Special Occasion
1010
1011 FREQ=YEARLY
1012
1013
1014
1016 3.8 Meeting invitation
1018 The following is a snippet of an iCalendar XML document that
1019 specifies an invitation for a meeting. The meeting occurs on the
1020 first Monday of each year for five years.
1022
1023
1026
1027 19981220T130000Z-123403@host.com
1028 19981220T130050Z
1029 MAILTO:corprel@host.com
1030 19990104T140000Z
1031 19990104T220000Z
1032 Annual Stockholders Meeting
1033 One Corporate Drive, Wilmington, DL
1034 MAILTO:mrbig@host.com
1035 MAILTO:stockholders@host.com
1037
1038 - Business
1039 - Meeting
1040 - Special Occasion
1041
1042 FREQ=YEARLY;COUNT=5;BYDAY=1MO
1043
1044
1045
1047 3.9 Assign a to-do
1049 The following is a snippet of an iCalendar XML document that assigns
1050 a to-do.
1052
1053
1056
1057 19990104T133402@ical1.host.com
1058 19990104T133410Z
1059 19990104
1060 19990129
1061 MAILTO:dboss@host.com
1062 Periodic Self Review
1063 Complete your self review.
1064 Contact me if you questions.
1065 1
1066 CONFIDENTIAL
1067 MAILTO:dilbert@host.com
1068
1069
1070
1072 3.10 Publish a journal entry
1074 The following is a snippet of an iCalendar XML document that
1075 publishes a journal entry.
1077
1078
1081
1082 19990104T170003@ical1.host.com
1083 19990104T170001Z
1084 19990104
1085 MAILTO:corprel@host.com
1086 PUBLIC
1087 Year end report for Worldwide Calendar Company
1088 The complete report can be found at the Corporate website.
1089 http://www.host.com/annualreport
1090
1091 - Annual Report
1092 - Business
1093
1094
1095
1096
1098 3.11 Publish busy time
1100 The following is an iCalendar XML document that publishes busy time
1101 information. The default value for the "method" attribute is
1102 "PUBLISH" and does not need to be specified in this example.
1104
1105
1109 ]>
1111
1112
1114
1115 19980313T133000@ical1.host.com
1116 19990104T133010Z
1117 MAILTO:jsmith@host.com
1118 19980313T141711Z
1119 19980410T141711Z
1120
1121 19980314T233000Z/19980315T003000Z
1122 19980316T153000Z/19980316T163000Z
1123 19980318T030000Z/19980318T040000Z
1124
1125
1126
1128 3.12 Request busy time
1130 The following is a snippet of an iCalendar XML document that
1131 requests a calendar user's busy time information.
1133
1134
1137
1138 19970901T083000@ical1.host.com
1139 19970901T083000Z
1140 MAILTO:jane_doe@host1.com
1141 19971015T050000Z
1142 19971016T050000Z
1143 MAILTO:john_public@host2.com
1144
1145
1146
1148 3.13 Response to a busy time request
1150 The following is an iCalendar XML document that responds to request
1151 for busy time information.
1153
1154
1157 ]>
1159
1160
1163
1164 19970901T083000@ical1.host.com
1165 19970901T100000Z
1166 MAILTO:jane_doe@host1.com
1167
1168 MAILTO:john_public@host2.com
1169 19971015T050000Z/PT8H30M,
1170 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
1171
1172
1173
1175 3.14 Published event that references time zone information
1177 The following is a snippet of an iCalendar XML document that
1178 publishes calendar information about an event that includes
1179 date/time values that reference a time zone definition.
1181
1182
1184
1185 US-Eastern
1186
1187 19981025T020000
1188 -0400
1189 0500
1190 19981025T020000
1191 EST
1192
1193
1194 19990404T020000
1195 -0500
1196 -0400
1197 19990404T020000
1198 EDT
1199
1200
1201
1202 19980309T231000Z
1203 guid-1.host1.com
1204 19980312T083000
1205 19980312T093000
1206 MAILTO:mrbig@host.com
1207 Project XYZ Review Meeting
1208 PUBLIC
1209 XYZ Project Review
1210 1CP Conference Room 4350
1211
1212 - Meeting
1213
1214 MAILTO:employee-@host.com
1217
1218
1219
1220
1222 3.15 An event with an alarm
1224 The following is an iCalendar XML with associated alarms. The event
1225 specifies alarm definitions for a "display", "audio", "email" and
1226 "procedure" type of alarms. The "method" attribute isn't specified
1227 since it is the default value.
1229
1230
1234
1235
1237
1238 ]>
1239
1240
1242
1243 19990104T130000@host.com
1244 19990104T130100Z
1245 19990704T230000Z
1246 19970705T040000Z
1247 Firework Celebration
1248
1249 - Holiday
1250 - Special Occasion
1252
1253
1254 DISPLAY
1255 Firework Celebration Tonight at
1256 6 PM !!!
1257 19990704T224500Z
1258 2
1259 PT15M
1260
1261
1262 AUDIO
1263 19990704T224500Z
1264 2
1265 PT15M
1266
1267
1268
1269 EMAIL
1270 Firework Celebration Tonight
1271 at 6 PM on Channel 6!!!
1272 *** Firework Celebration On TV ***
1273 19990704T224500Z
1274 MAILTO:PIN1234@pager.host.com
1275
1276
1277 PROCEDURE
1278
1279 19990704T230000Z
1280
1281
1282
1283
1285 4. iCalendar XML Document Type Definition
1287 The following DTD conforms to XML version 1.0, as specified by
1288 [XML].
1290
1292
1293
1294
1296
1300
1304
1307
1308
1309
1311
1314
1316
1319
1321
1324
1326
1329
1331
1334
1335
1336
1338
1341
1343
1346
1348
1351
1352
1353
1355
1356
1357
1358
1359
1360
1361
1363
1366
1367
1369
1372
1374
1377
1378
1380
1383
1384
1385
1387
1390
1392
1395
1397
1400
1402
1406
1412
1413
1418
1420
1426
1428
1433
1435
1439
1441
1445
1447
1451
1453
1456
1457
1459
1462
1464
1467
1469
1472
1473
1475
1478
1480
1483
1485
1488
1490
1493
1495
1498
1500
1503
1504
1506
1509
1511
1515
1518
1519
1522
1523
1525
1529
1532
1534
1537
1538
1540
1543
1544
1546
1549
1550
1552
1557
1560
1562
1565
1566
1568
1571
1572
1576
1577
1578
1579
1583
1585
1587
1590
1592
1595
1598
1600
1602
1605
1608
1610
1612
1614
1617
1619
1620
1621
1623
1624
1626
1627
1628
1629
1630
1632
1633
1636
1637
1641
1643
1644
1648
1649
1653
1654
1659
1660
1665
1667
1668
1669
1671
1672
1673
1675
1676
1681
1682
1685
1686
1689
1690
1695
1696
1700
1701
1703
1704
1709
1711
1712
1716
1717
1721
1722
1725
1726
1729
1730
1733
1734
1738
1739
1741
1743
1745
1746
1749
1750
1754
1755
1758
1759
1762
1763
1766
1768
1769
1783
1784
1789
1790
1797
1798
1803
1804
1808
1809
1812
1813
1816
1818
1819
1822
1823
1826
1827
1831
1832
1835
1837
1838
1840
1842
1843
1846
1847
1851
1852
1854
1855
1858
1859
1862
1863
1866
1867
1870
1871
1872
1876
1878
1880
1881
1889
1890
1891
1892
1894
1895
1897
1898
1900
1901
1903
1904
1906
1907
1910
1912
1914
1917 5. Acknowledgments
1919 The following have participated in the drafting and discussion of
1920 this memo:
1922 Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert,
1923 Thomas Rowe.
1925 6. IANA Considerations
1927 This document defines a XML Formal Public Identifier (FPI), based on
1928 a format defined in [ISO 9070], that identifies a XML document type
1929 corresponding to this memo. Publication of this memo constitutes
1930 registration of this identifier.
1932 In addition, this memo defines the XML FPIs corresponding to each of
1933 the value types specified in [RFC 2445].
1935 7. Security Considerations
1937 CDATA Sections - - A XML iCalendar document may contain CDATA
1938 sections to represent content for specific element types. The CDATA
1939 section specifies arbitrary character data that is not meant to be
1940 interpretted. It is not scanned by the XML parser for markup. While
1941 this memo restricts that any CDATA section MUST NOT contain markup
1942 or other such alternate representation for the property value, in
1943 general, CDATA section from a non-conformant implementation can
1944 contain content such as HTML markup. HTML text can be used to invoke
1945 programs. Implementors should be aware that this may leave an
1946 implementation open to malicious attack that might occur as a result
1947 of executing the markup in the CDATA section.
1949 PROCEDURAL ALARMS - - A XML iCalendar document can be created that
1950 contains a "VEVENT" and "VTODO" calendar component with "VALARM"
1951 calendar components. The "VALARM" calendar component can be of type
1952 PROCEDURE and can have an attachment containing some sort of
1953 executable program. Implementations that incorporate these types of
1954 alarms are subject to any virus or malicious attack that might occur
1955 as a result of executing the attachment.
1957 ATTACHMENTS - - A XML iCalendar document can include references to
1958 Uniform Resource Locators that can be programmed resources.
1959 Implementers and users of this memo should be aware of the network
1960 security implications of accepting and parsing such information.
1962 In addition, the security considerations observed by implementations
1963 of electronic mail systems should be followed for this memo.
1965 8. Bibliography
1967 [FPI] F. Dawson, "iCalendar Formal Public Identifier", Internet
1968 Draft,
1969 http://www.internic.net/internet-drafts/draft-calsch-icalfpi-00.txt,
1970 September 1998.
1972 [ISO9070] "Information Technology_SGML Support Facilities_
1973 Registration Procedures for Public Text Owner Identifiers", ISO/IEC
1974 9070, Second Edition, International Organization for
1975 Standardization, April 1991.
1977 [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
1978 Extensions (MIME) - Part One: Format of Internet Message Bodies",
1979 RFC 2045, November 1996.
1981 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
1982 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt,
1983 March 1997.
1985 [RFC 2445] F. Dawson and D. Stenerson, "Internet Calendaring and
1986 Scheduling Core Object Specification (iCalendar)", RFC 2445,
1987 http://www.ietf.org/rfc/rfc2445.txt, November 1998.
1989 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium,
1990 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
1992 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium,
1993 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
1995 Authors' Addresses
1997 Frank Dawson
1998 Nokia Corporation
2000 Phone: +1 (972) 894 4083
2001 EMail: frank.dawson@nokia.com
2003 Surendra K. Reddy
2004 Oracle
2005 M/S 6op3
2006 500 Oracle Parkway
2007 Redwoodshores, CA 94065
2008 US
2010 Phone: +1 (650) 506 5441
2011 Fax: +1 (650) 654 6205
2012 EMail: skreddy@us.oracle.com
2013 Doug Royer
2014 INET-Consulting LLC
2015 1795 W. Broadway #266
2016 Idaho Falls, ID 83402
2017 US
2019 Phone: +1 (208) 520 4044
2020 Fax: +1 (208) 552 1179
2021 EMail: doug@royer.com
2023 Eric R. Plamondon
2024 Steltor
2025 2000 Peel Street, 4th Floor
2026 Montreal, QC H3A 2W5
2027 Canada
2029 Phone: +1 (514) 733 8500
2030 Fax: +1 (514) 733 8878
2031 EMail: ericp@steltor.com
2033 Full Copyright Statement
2035 Copyright (C) The Internet Society (2002). All Rights Reserved.
2037 This document and translations of it may be copied and furnished to
2038 others, and derivative works that comment on or otherwise explain it
2039 or assist in its implmentation may be prepared, copied, published
2040 and distributed, in whole or in part, without restriction of any
2041 kind, provided that the above copyright notice and this paragraph
2042 are included on all such copies and derivative works.However, this
2043 document itself may not be modified in any way, such as by removing
2044 the copyright notice or references to the Internet Society or other
2045 Internet organizations, except as needed for the purpose of
2046 developing Internet standards in which case the procedures for
2047 copyrights defined in the Internet Standards process MUST be
2048 followed, or as required to translate it into languages other than
2049 English.
2051 The limited permissions granted above are perpetual and will not be
2052 revoked by the Internet Society or its successors or assigns.
2054 This document and the information contained herein is provided on an
2055 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2056 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2057 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2058 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2059 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2061 Acknowledgement
2063 Funding for the RFC editor function is currently provided by the
2064 Internet Society.