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.