idnits 2.17.1 draft-ietf-calsch-many-xcal-00.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 20 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 (August 20, 2001) is 8278 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 1991 looks like a reference -- Missing reference section? 'RFC 2445' on line 1984 looks like a reference -- Missing reference section? 'RFC 2119' on line 1980 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 1976 looks like a reference -- Missing reference section? 'ISO 9070' on line 1927 looks like a reference -- Missing reference section? 'FPI' on line 1966 looks like a reference -- Missing reference section? 'ISO9070' on line 1971 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 Lotus 4 Expires: February 18, 2002 S Reddy 5 Oracle 6 D Royer 7 Sun Microsystems 8 E Plamondon 9 Steltor 10 August 20, 2001 12 iCalendar DTD Document (xCal) 13 draft-ietf-calsch-many-xcal-00 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 February 18, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). 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-vcard-xml-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-00.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 "text/x-xcal". The 730 content-type header field SHOULD also contain a "component" and 731 "method" parameter to clearly identify a comma-separated list of 732 components and the singular method used in the iCalendar XML 733 document. For example, an iCalendar XML document specifying a 734 REQUEST for a VEVENT and VTODO would be specified with the following 735 content-type header field: 737 content-type:text/x-xcal;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 "text/x-xcal" document 752 contained within a "multipart" message content-type. 754 2.13 iCalendar XML Representation and File Systems 756 The iCalendar XML documents will be stored in file systems. The 757 accepted practice for file extensions for XML documents is the text 758 "XML". However, in order to uniquely identify iCalendar XML 759 documents for file association with applications that can directly 760 process this document type, it is RECOMMENDED that the file 761 extension be the text "XCS". 763 3. Example Usage 765 The following sections provide various examples of iCalendar XML 766 documents. 768 3.1 A well-formed and valid iCalendar XML document 770 The following is a simple example of a iCalendar XML document. This 771 document is both a well-formed and valid XML document. The iCalendar 772 object specifies an appointment. 774 775 778 779 782 783 19981116T150000@cal10.host.com 784 19981116T145958Z 785 Project XYZ Review 786 Conference Room 23A 787 19981116T163000Z 788 19981116T190000Z 789 790 Appointment 791 792 793 794 796 3.2 Adding non-standard, experimental extensions 798 The following is an example of a valid iCalendar XML document that 799 also includes a non-standard, experimental extension, as provided 800 for by [RFC 2445]. The iCalendar object specifies the publication of 801 a to-do with a non-standard experimental property for a customer 802 charge code. 804 The non-standard experimental property is identified by the "X-" 805 prefix to the element name. All non-standard properties MUST be 806 specified with element types with an "X-" type element name. In 807 addition, a text identifier for the vendor specifying the extension 808 SHOULD be appended to the "X-" text prefix. In this case, the 809 example specifies a "foo" for the name of the vendor specifying the 810 non- standard property. 812 813 823 824 825 ]> 827 828 831 832 19981104T130000@cal1.host.com 833 19981104T125957Z 834 19981105T133000Z 835 19981106T133000Z 836 Draft a test plan 837 1998-ABC Corp-1234 838 1 839 840 841 843 3.3 Including binary content in attachments 845 The following is an example of a valid iCalendar XML document that 846 also includes an external reference to an attachment. The iCalendar 847 object specifies a meeting invitation with an attachment. 849 850 856 858 ]> 860 861 864 865 19981211T133000@cal1.host.com 866 19981211T132928Z 867 jim@host.com 868 19981212T150000Z 869 19981212T160000Z 870 Department Meeting 871 Conference Room 23A 872 jim@host.com 873 MAILTO:joe@host.com 875 MAILTO:steve@host.com 877 878 879 880 882 The following is an example of a well-formed and valid iCalendar XML 883 document that includes an attachment as inline binary content. The 884 iCalendar object specifies a meeting invitation with an attachment. 886 887 890 891 894 895 19981211T133000@cal1.host.com 896 19981211T132928Z 897 MAILTO:jim@host.com 898 19981212T150000Z 899 19981212T160000Z 900 Department Meeting 901 Conference Room 23A 902 MAILTO:jim@host.com 903 MAILTO:joe@host.com 905 MAILTO:steve@host.com 907 MIICajCCAdOgAwIBAgI 908 CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB 909 lIEjYXRpb25z...and so on...IENvcnBvc== 910 911 912 914 3.4 iCalendar XML document with multiple iCalendar objects 916 The following is an example of a well-formed and valid iCalendar XML 917 document that includes more than one iCalendar object. 919 920 923 924 927 928 19981009T233000@cal1.host.com 929 19981009T232928Z 930 19981010T000000Z 931 19981010T235959Z 932 Register for conference 933 2 934 935 936 939 940 19981009T233010@cal1.host.com 941 19981009T233000Z 942 19981120T133000Z 943 19981122T183000Z 944 IT Conference 945 Downtowner Hotel 946 947 948 950 3.5 Using the iCalendar namespace 952 The following is an example of a snippet of a XML document that 953 includes elements from the iCalendar name-space. 955 958 19981123T133000Z 959 19981123T203000Z 960 1234567 961 999.99 962 964 3.6 Publish meeting information 966 The following is a snippet of an iCalendar XML document that 967 publishes information about a meeting. The "method" attribute isn't 968 specified since it is the default value. 970 971 973 974 19970901T130000Z-123401@host.com 975 19970901T130000Z 976 19970903T163000Z 977 19970903T190000Z 978 Annual Employee Review 979 PRIVATE 980 981 Business 982 Human Resources 983 984 985 986 988 3.7 Publish transparent annual event 990 The following is a snippet of an iCalendar XML document that 991 publishes information about an annually repeating event that is 992 transparent to busy time searches. 994 995 997 998 19990101T125957Z-123403@host.com 999 19990101T130000Z 1000 19991102 1001 19991102 1002 Our Blissful Anniversary 1003 CONFIDENTIAL 1004 TRANSPARENT 1005 1006 Anniversary 1007 Personal 1008 Special Occasion 1009 1010 FREQ=YEARLY 1011 1012 1013 1015 3.8 Meeting invitation 1017 The following is a snippet of an iCalendar XML document that 1018 specifies an invitation for a meeting. The meeting occurs on the 1019 first Monday of each year for five years. 1021 1022 1025 1026 19981220T130000Z-123403@host.com 1027 19981220T130050Z 1028 MAILTO:corprel@host.com 1029 19990104T140000Z 1030 19990104T220000Z 1031 Annual Stockholders Meeting 1032 One Corporate Drive, Wilmington, DL 1033 MAILTO:mrbig@host.com 1034 MAILTO:stockholders@host.com 1036 1037 Business 1038 Meeting 1039 Special Occasion 1040 1041 FREQ=YEARLY;COUNT=5;BYDAY=1MO 1042 1043 1044 1046 3.9 Assign a to-do 1048 The following is a snippet of an iCalendar XML document that assigns 1049 a to-do. 1051 1052 1055 1056 19990104T133402@ical1.host.com 1057 19990104T133410Z 1058 19990104 1059 19990129 1060 MAILTO:dboss@host.com 1061 Periodic Self Review 1062 Complete your self review. 1063 Contact me if you questions. 1064 1 1065 CONFIDENTIAL 1066 MAILTO:dilbert@host.com 1067 1068 1069 1071 3.10 Publish a journal entry 1073 The following is a snippet of an iCalendar XML document that 1074 publishes a journal entry. 1076 1077 1080 1081 19990104T170003@ical1.host.com 1082 19990104T170001Z 1083 19990104 1084 MAILTO:corprel@host.com 1085 PUBLIC 1086 Year end report for Worldwide Calendar Company 1087 The complete report can be found at the Corporate website. 1088 http://www.host.com/annualreport 1089 1090 Annual Report 1091 Business 1092 1093 1094 1095 1097 3.11 Publish busy time 1099 The following is an iCalendar XML document that publishes busy time 1100 information. The default value for the "method" attribute is 1101 "PUBLISH" and does not need to be specified in this example. 1103 1104 1108 ]> 1110 1111 1113 1114 19980313T133000@ical1.host.com 1115 19990104T133010Z 1116 MAILTO:jsmith@host.com 1117 19980313T141711Z 1118 19980410T141711Z 1119 1120 19980314T233000Z/19980315T003000Z 1121 19980316T153000Z/19980316T163000Z 1122 19980318T030000Z/19980318T040000Z 1123 1124 1125 1127 3.12 Request busy time 1129 The following is a snippet of an iCalendar XML document that 1130 requests a calendar user's busy time information. 1132 1133 1136 1137 19970901T083000@ical1.host.com 1138 19970901T083000Z 1139 MAILTO:jane_doe@host1.com 1140 19971015T050000Z 1141 19971016T050000Z 1142 MAILTO:john_public@host2.com 1143 1144 1145 1147 3.13 Response to a busy time request 1149 The following is an iCalendar XML document that responds to request 1150 for busy time information. 1152 1153 1156 ]> 1158 1159 1162 1163 19970901T083000@ical1.host.com 1164 19970901T100000Z 1165 MAILTO:jane_doe@host1.com 1166 1167 MAILTO:john_public@host2.com 1168 19971015T050000Z/PT8H30M, 1169 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M 1170 1171 1172 1174 3.14 Published event that references time zone information 1176 The following is a snippet of an iCalendar XML document that 1177 publishes calendar information about an event that includes 1178 date/time values that reference a time zone definition. 1180 1181 1183 1184 US-Eastern 1185 1186 19981025T020000 1187 -0400 1188 0500 1189 19981025T020000 1190 EST 1191 1192 1193 19990404T020000 1194 -0500 1195 -0400 1196 19990404T020000 1197 EDT 1198 1199 1200 1201 19980309T231000Z 1202 guid-1.host1.com 1203 19980312T083000 1204 19980312T093000 1205 MAILTO:mrbig@host.com 1206 Project XYZ Review Meeting 1207 PUBLIC 1208 XYZ Project Review 1209 1CP Conference Room 4350 1210 1211 Meeting 1212 1213 MAILTO:employee-@host.com 1216 1217 1218 1219 1221 3.15 An event with an alarm 1223 The following is an iCalendar XML with associated alarms. The event 1224 specifies alarm definitions for a "display", "audio", "email" and 1225 "procedure" type of alarms. The "method" attribute isn't specified 1226 since it is the default value. 1228 1229 1233 1234 1236 1237 ]> 1238 1239 1241 1242 19990104T130000@host.com 1243 19990104T130100Z 1244 19990704T230000Z 1245 19970705T040000Z 1246 Firework Celebration 1247 1248 Holiday 1249 Special Occasion 1251 1252 1253 DISPLAY 1254 Firework Celebration Tonight at 1255 6 PM !!! 1256 19990704T224500Z 1257 2 1258 PT15M 1259 1260 1261 AUDIO 1262 19990704T224500Z 1263 2 1264 PT15M 1265 1266 1267 1268 EMAIL 1269 Firework Celebration Tonight 1270 at 6 PM on Channel 6!!! 1271 *** Firework Celebration On TV *** 1272 19990704T224500Z 1273 MAILTO:PIN1234@pager.host.com 1274 1275 1276 PROCEDURE 1277 1278 19990704T230000Z 1279 1280 1281 1282 1284 4. iCalendar XML Document Type Definition 1286 The following DTD conforms to XML version 1.0, as specified by 1287 [XML]. 1289 1291 1292 1293 1295 1299 1303 1306 1307 1308 1310 1313 1315 1318 1320 1323 1325 1328 1330 1333 1334 1335 1337 1340 1342 1345 1347 1350 1351 1352 1354 1355 1356 1357 1358 1359 1360 1362 1365 1366 1368 1371 1373 1376 1377 1379 1382 1383 1384 1386 1389 1391 1394 1396 1399 1401 1405 1411 1412 1417 1419 1425 1427 1432 1434 1438 1440 1444 1446 1450 1452 1455 1456 1458 1461 1463 1466 1468 1471 1472 1474 1477 1479 1482 1484 1487 1489 1492 1494 1497 1499 1502 1503 1505 1508 1510 1514 1517 1518 1521 1522 1524 1528 1531 1533 1536 1537 1539 1542 1543 1545 1548 1549 1551 1556 1559 1561 1564 1565 1567 1570 1571 1575 1576 1577 1578 1582 1584 1586 1589 1591 1594 1597 1599 1601 1604 1607 1609 1611 1613 1616 1618 1619 1620 1622 1623 1625 1626 1627 1628 1629 1631 1632 1635 1636 1640 1642 1643 1647 1648 1652 1653 1658 1659 1664 1666 1667 1668 1670 1671 1672 1674 1675 1680 1681 1684 1685 1688 1689 1694 1695 1699 1700 1702 1703 1708 1710 1711 1715 1716 1720 1721 1724 1725 1728 1729 1732 1733 1737 1738 1740 1742 1744 1745 1748 1749 1753 1754 1757 1758 1761 1762 1765 1767 1768 1782 1783 1788 1789 1796 1797 1802 1803 1807 1808 1811 1812 1815 1817 1818 1821 1822 1825 1826 1830 1831 1834 1836 1837 1839 1841 1842 1845 1846 1850 1851 1853 1854 1857 1858 1861 1862 1865 1866 1869 1870 1871 1875 1877 1879 1880 1888 1889 1890 1891 1893 1894 1896 1897 1899 1900 1902 1903 1905 1906 1909 1911 1913 1916 5. Acknowledgments 1918 The following have participated in the drafting and discussion of 1919 this memo: 1921 Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert, 1922 Thomas Rowe. 1924 6. IANA Considerations 1926 This document defines a XML Formal Public Identifier (FPI), based on 1927 a format defined in [ISO 9070], that identifies a XML document type 1928 corresponding to this memo. Publication of this memo constitutes 1929 registration of this identifier. 1931 In addition, this memo defines the XML FPIs corresponding to each of 1932 the value types specified in [RFC 2445]. 1934 7. Security Considerations 1936 CDATA Sections - - A XML iCalendar document may contain CDATA 1937 sections to represent content for specific element types. The CDATA 1938 section specifies arbitrary character data that is not meant to be 1939 interpretted. It is not scanned by the XML parser for markup. While 1940 this memo restricts that any CDATA section MUST NOT contain markup 1941 or other such alternate representation for the property value, in 1942 general, CDATA section from a non-conformant implementation can 1943 contain content such as HTML markup. HTML text can be used to invoke 1944 programs. Implementors should be aware that this may leave an 1945 implementation open to malicious attack that might occur as a result 1946 of executing the markup in the CDATA section. 1948 PROCEDURAL ALARMS - - A XML iCalendar document can be created that 1949 contains a "VEVENT" and "VTODO" calendar component with "VALARM" 1950 calendar components. The "VALARM" calendar component can be of type 1951 PROCEDURE and can have an attachment containing some sort of 1952 executable program. Implementations that incorporate these types of 1953 alarms are subject to any virus or malicious attack that might occur 1954 as a result of executing the attachment. 1956 ATTACHMENTS - - A XML iCalendar document can include references to 1957 Uniform Resource Locators that can be programmed resources. 1958 Implementers and users of this memo should be aware of the network 1959 security implications of accepting and parsing such information. 1961 In addition, the security considerations observed by implementations 1962 of electronic mail systems should be followed for this memo. 1964 8. Bibliography 1966 [FPI] F. Dawson, "iCalendar Formal Public Identifier", Internet 1967 Draft, 1968 http://www.internic.net/internet-drafts/draft-calsch-icalfpi-00.txt, 1969 September 1998. 1971 [ISO9070] "Information Technology_SGML Support Facilities_ 1972 Registration Procedures for Public Text Owner Identifiers", ISO/IEC 1973 9070, Second Edition, International Organization for 1974 Standardization, April 1991. 1976 [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1977 Extensions (MIME) - Part One: Format of Internet Message Bodies", 1978 RFC 2045, November 1996. 1980 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 1981 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt, 1982 March 1997. 1984 [RFC 2445] F. Dawson and D. Stenerson, "Internet Calendaring and 1985 Scheduling Core Object Specification (iCalendar)", RFC 2445, 1986 http://www.ietf.org/rfc/rfc2445.txt, November 1998. 1988 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 1989 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 1991 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 1992 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 1994 Authors' Addresses 1996 Frank Dawson 1997 Lotus 1998 6544 Battleford Drive 1999 Raleigh, NC 27613-3502 2000 US 2002 Phone: +1 (617) 693 8728 2003 EMail: Frank_Dawson@Lotus.com 2004 Surendra K. Reddy 2005 Oracle 2006 M/S 6op3 2007 500 Oracle Parkway 2008 Redwoodshores, CA 94065 2009 US 2011 Phone: +1 (650) 506 5441 2012 Fax: +1 (650) 654 6205 2013 EMail: skreddy@us.oracle.com 2015 Doug Royer 2016 Sun Microsystems 2017 MS MPK17-105 2018 901 San Antonio Road 2019 Palo Alto, CA 94303-4900 2020 US 2022 Phone: +1 (650) 786 7599 2023 EMail: doug.royer@sun.com 2025 Eric R. Plamondon 2026 Steltor 2027 2000 Peel Street, 4th Floor 2028 Montreal, QC H3A 2W5 2029 Canada 2031 Phone: +1 (514) 733 8500 2032 Fax: +1 (514) 733 8878 2033 EMail: ericp@steltor.com 2035 Full Copyright Statement 2037 Copyright (C) The Internet Society (2001). All Rights Reserved. 2039 This document and translations of it may be copied and furnished to 2040 others, and derivative works that comment on or otherwise explain it 2041 or assist in its implmentation may be prepared, copied, published 2042 and distributed, in whole or in part, without restriction of any 2043 kind, provided that the above copyright notice and this paragraph 2044 are included on all such copies and derivative works.However, this 2045 document itself may not be modified in any way, such as by removing 2046 the copyright notice or references to the Internet Society or other 2047 Internet organizations, except as needed for the purpose of 2048 developing Internet standards in which case the procedures for 2049 copyrights defined in the Internet Standards process MUST be 2050 followed, or as required to translate it into languages other than 2051 English. 2053 The limited permissions granted above are perpetual and will not be 2054 revoked by the Internet Society or its successors or assigns. 2056 This document and the information contained herein is provided on an 2057 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2058 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2059 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2060 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2061 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2063 Acknowledgement 2065 Funding for the RFC editor function is currently provided by the 2066 Internet Society.