idnits 2.17.1 draft-royer-calsch-xcal-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 875. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([KEYWORDS]), 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 211: '... to this specification MUST be able to...' RFC 2119 keyword, line 215: '...orming to this memo MUST only send the...' RFC 2119 keyword, line 414: '...se element types MUST NOT contain mark...' RFC 2119 keyword, line 417: '... Values MUST NOT be mapped to lower ...' RFC 2119 keyword, line 421: '...forbidden by XML MUST be encoded using...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 26, 2005) is 6811 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? 'KEYWORDS' on line 828 looks like a reference -- Missing reference section? 'XML' on line 839 looks like a reference -- Missing reference section? 'RFC 2445' on line 104 looks like a reference -- Missing reference section? 'RFC 2146' on line 115 looks like a reference -- Missing reference section? 'XMLNS' on line 181 looks like a reference -- Missing reference section? 'RFC2445' on line 218 looks like a reference -- Missing reference section? 'MIME' on line 824 looks like a reference -- Missing reference section? 'BASIC' on line 815 looks like a reference -- Missing reference section? 'ISO9070' on line 819 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Royer 3 Internet-Draft IntelliCal 4 Expires: February 27, 2006 August 26, 2005 6 iCalendar in XML Format (xCal-Basic) 7 draft-royer-calsch-xcal-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The mailing list for discussion of this memo is "xCal@ 41 INET-Consulting.com" and signup page at 42 "http://INET-Conusulting.com/mailman/listinfo/xcal. This is a 43 rerelease of an expired draft with updates and a much more simplivied 44 approach. This approach uses an exact 1 to 1 mapping between 45 iCalendar and xml objects. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 49 document are to be interpreted as described in [KEYWORDS]. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Using XML For Representating iCalendar . . . . . . . . . . . . 4 55 2.1 XML Dependencies . . . . . . . . . . . . . . . . . . . . . 5 56 2.2 Working With Standard and XML iCalendar Representations . 5 57 2.2.1 Conversion . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2.2 Mixed Use of Both Representations . . . . . . . . . . 5 59 2.3 Using Data Types . . . . . . . . . . . . . . . . . . . . . 6 60 2.4 Including Binary Content . . . . . . . . . . . . . . . . . 6 61 2.5 Including Multiple iCalendar Objects . . . . . . . . . . . 7 62 2.6 Mapping Property Parameters to XML . . . . . . . . . . . . 7 63 2.7 Mapping VCALENDAR object Properties to XML . . . . . . . . 8 64 2.8 Mapping All Components to XML . . . . . . . . . . . . . . 9 65 2.9 Mapping All Values to XML . . . . . . . . . . . . . . . . 10 66 2.10 Emailing the iCalendar XML Representation . . . . . . . . 11 67 2.11 iCalendar XML Representation and File Systems . . . . . . 12 68 3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 13 69 3.1 A well-formed and valid iCalendar XML document . . . . . . 13 70 3.2 Including binary content in attachments . . . . . . . . . 13 71 3.3 iCalendar XML document with multiple iCalendar objects . . 15 72 3.4 Using the iCalendar namespace . . . . . . . . . . . . . . 16 73 3.5 Publish meeting information . . . . . . . . . . . . . . . 16 74 3.6 Publish transparent annual event . . . . . . . . . . . . . 17 75 3.7 Meeting invitation . . . . . . . . . . . . . . . . . . . . 17 76 3.8 Publish busy time . . . . . . . . . . . . . . . . . . . . 18 77 3.9 Request busy time . . . . . . . . . . . . . . . . . . . . 19 78 3.10 Issue a CAP command . . . . . . . . . . . . . . . . . . . 19 79 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 82 7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 84 Intellectual Property and Copyright Statements . . . . . . . . 24 86 1. Introduction 88 The Extended Markup Language (XML) as defined in [XML] is gaining 89 widespread attention as a "web friendly" syntax for representing and 90 exchanging documents and data on the Internet. This interest 91 includes requests for and discussion of possible document type 92 definitions (DTD) and name-space for IETF standard formats such as 93 that defined by [iCAL]. This memo defines how XML can be used to 94 represent iCalendar objects and does not specify a DTD as iCalendar 95 can be extended. 97 This format was selected to ease its translation back to the 98 iCalendar format using an XSLT transform. (See project iCalendar on 99 SourceForge.com - http://sourceforge.net/projects/icalendar/ ) 101 NOTE: The [iCAL] is the definitive reference for the definition of 102 iCalendar semantics. This memo only provides an alternative, XML 103 representation for the standard syntax defined in [iCAL]. This memo 104 does not introduce any semantics not already defined by [RFC 2445]. 106 An attempt has been made to leverage the standard features of the XML 107 syntax in order to represent the component iCalendar semantics. For 108 example, strong data typing is specified using the XML notation 109 declaration. The element type attributes are used to represent many 110 of the calendar properties that provide a "global attribute" 111 capability in an iCalendar object. Binary content in the ATTACH 112 component property may either be specified through an external entity 113 reference to a non-XML binary content or may be included in the XML 114 document's content information, after first being encoding using the 115 BASE64 scheme of [RFC 2146]. 117 The publication of XML version 1.0 was followed by the publication of 118 a World-wide Web Consortium (W3C) recommendation on "Namespaces in 119 XML". A XML name-space is a collection of names, identified by a 120 URI. In anticipation of the broader use of XML namespaces. Within 121 this memo the term "xCal" will mean the XML namespace usage as 122 described in this memo. 124 2. Using XML For Representating iCalendar 126 XML is a simplified version of the text markup syntax defined by ISO 127 8879, Standard Generalized Markup Language (SGML). XML was published 128 as a proposed recommendation [XML] by the World-wide Web Consortium 129 (W3C) on February 10, 1998. 131 In iCalendar names can be in upper case, lower case, or mixed case. 132 In xCal the predefined iCaledars names will be represented in lower 133 case only as XML element and attribute names are case sensitive.. 134 Values to properties and parameters that are user specified may be in 135 upper, lower, or mixed case. 137 All iCalendar component names will be represented in xCal as XML 138 element names in lower case. The "BEGIN" iCalendar component will be 139 represented in xCal as: . 141 All iCalendar property names will be represented in xCal as XML 142 element names in lower case. 144 All iCalendar parameter names will be represented in xCal as XML 145 attribute names in lower case. 147 All iCalendar predefined names that are used as values will be 148 represented in xCal in lower case. 150 This example: 152 BEGIN:VCALENDAR 153 VERSION:2.0 154 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 155 BEGIN:VEVENT 156 DTSTART:19970714T170000Z 157 DTEND:19970715T035959Z 158 SUMMARY;LANGUAGE="en_US":Bastille Day Party 159 END:VEVENT 160 END:VCALENDAR 162 Is represented in xCal as: 164 165 166 167 2.0 168 -//hacksw/handcal//NONSGML v1.0//EN 169 170 19970714T170000Z 171 19970715T035959Z 172 Bastille Day Party 173 174 175 177 2.1 XML Dependencies 179 This memo specifies the XML representation for the standard iCalendar 180 format defined by [iCAL]. There are no XML dependencies other than 181 the [XML] and the [XMLNS] recommendations. 183 2.2 Working With Standard and XML iCalendar Representations 185 This memo defines an alternative, XML representation for the standard 186 iCalendar format defined in [iCAL]. This alternative representation 187 provides the same semantics as that defined in the standard format. 188 It is the goal of this memo to allow all [iCAL] extensions and 189 modifications to be translated into and from this XML format. 191 2.2.1 Conversion 193 The standard format can be converted to and from this XML format 194 without loss of any calendaring information. When the XML 195 representation was defined, every attempt was made to use existing 196 component, property and parameter naming conventions. This greatly 197 facilitates transformations between the two representations. 199 2.2.2 Mixed Use of Both Representations 201 As previously indicated, conversion between the standard and XML 202 representations of iCalendar is a straightforward process. In 203 addition, mixed use of both representations is also possible using 204 MIME objects. 206 With the use of the MIME multipart content-types, compound MIME 207 entities containing a mix of the standard and XML representations can 208 be specified. This capability is useful in applications where both 209 representations might be encountered. In addition, this capability 210 demonstrates the isomeric nature of the two representations. XML 211 applications conforming to this specification MUST be able to 212 properly parse and process a MIME multipart entity containing the 213 MIME type associated with this iCalendar XML document type. 215 Internet applications conforming to this memo MUST only send the 216 iCalendar XML document in a "multipart/alternative" MIME entity that 217 also contains an equivalent iCalendar object in the standard format 218 defined by [RFC2445]. This restriction will guarantee that the 219 iCalendar object can also be processed by Internet applications that 220 only support the standard iCalendar representation. 222 2.3 Using Data Types 224 Strong "data typing" is an integral design principle to the iCalendar 225 format. Strong data typing in iCalendar means that the format type 226 for each property value is well known. Within [iCAL], the data type 227 is called the "value type". The standard format defined by [RFC 228 2445] specifies a default value type for each calendar and component 229 property. In addition, many of the property definitions allow for 230 the specification of alternate value types. This XML representation 231 continues this design principle. 233 Explicit value/data typing in the XML representation is specified 234 with the "value" attribute on each element type. XML documents 235 conforming to this memo need only specify the "value" attribute on 236 element types when the value needs to override the default value/data 237 type defined in the iCalendar specifications. The formal public 238 identifier for standard value types all have the common string format 239 of: 241 2.4 Including Binary Content 243 Binary content can be included in an iCalendar object with the 244 "ATTACH" component property. In the standard iCalendar format this 245 content may either be specified through an external entity reference, 246 using a URI value type, or maybe specified within the iCalendar 247 object, after first BASE64 encoding the content. 249 The XML representation for iCalendar also supports including binary 250 content in an iCalendar object with the "attach" element type. It 251 also supports either an external reference to the non-XML binary 252 content or inclusion of the binary content after first encoding the 253 binary information using the BASE64 encoding of [MIME]. 255 http://host.com/bin/foo.exe 256 MIICajCC 257 AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l 258 dHNjYXBlIENvbW11bmljYXR5z...and so on...IENvcnBvc== 260 2.5 Including Multiple iCalendar Objects 262 The iCalendar format has the capability for including multiple, 263 individual iCalendar objects in a single data stream. The XML 264 representation can support this also. Individual iCalendar objects 265 are specified by the "vcalendar" element type. One or more 266 "vcalendar" element types are permitted within the parent element 267 type, called "iCalendar". For example: 269 270 271 2.0 272 273 274 275 2.0 276 277 > 278 280 2.6 Mapping Property Parameters to XML 282 The property parameters defined in the standard iCalendar format are 283 represented in the XML representation as an attribute on element 284 types. The following table specifies some of the attribute name 285 corresponding to each property parameter. This is true for all 286 iCalendar object parameters defined in any iCalendar specification. 287 The property and paramater names will be all lower case. Here are 288 some iCalendar parameter names and how they are mapped to their lower 289 case xCal names. 291 NOTE: that the iCalendar "language" parameter is converted to the 292 "xml:lang" attribute as an exception to the one to one mapping. 294 +----------------+----------------+ 295 | Property | Attribute | 296 | Parameter Name | Name | 297 +----------------+----------------+ 298 | ALTREP | altrep | 299 | CN | cn | 300 | CUTYPE | cutype | 301 | DELEGATED-FROM | delegated-from | 302 | DELEGATED-TO | delegated-to | 303 | DIR | dir | 304 | FMTTYPE | fmttype | 305 | FBTYPE | fbtype | 306 | LANGUAGE | xml:lang | 307 | MEMBER | member | 308 | PARTSTAT | partstat | 309 | RANGE | range | 310 | RELATED | related | 311 | RELTYPE | reltype | 312 | ROLE | role | 313 | RSVP | rsvp | 314 | SENT-BY | sent-by | 315 | TZID | tzid | 316 | VALUE | value | 317 | X-... | x-... | 318 | ..... | ..... | 319 +----------------+----------------+ 321 2.7 Mapping VCALENDAR object Properties to XML 323 Calendar properties defined in the standard iCalendar format provide 324 information about an iCalendar object, as a whole. The calendar 325 properties are represented in the XML representation as element types 326 as shown in lower case. Here is a list of some iCalendar properties 327 and them mapped to xCal lower case names: 329 +------------------+------------------+ 330 | Calendar | Tag | 331 | Property Name | Name | 332 +------------------+------------------+ 333 | ACTION | action | 334 | ATTACH | attach | 335 | ATTENDEE | attendee | 336 | CALSCALE | calscale | 337 | CATEGORIES | categories | 338 | CLASS | class | 339 | COMMENT | comment | 340 | COMPLETED | completed | 341 | CONTACT | contact | 342 | CREATED | created | 343 | DESCRIPTION | description | 344 | DTEND | dtend | 345 | DTSTART | dtstart | 346 | DTSTAMP | dtstamp | 347 | DUE | due | 348 | DURATION | duration | 349 | EXDATE | exdate | 350 | EXRULE | exrule | 351 | FREEBUSY | freebusy | 352 | GEO | geo | 353 | LAST-MODIFIED | last-modified | 354 | LOCATION | location | 355 | METHOD | method | 356 | ORGANIZER | organizer | 357 | PERCENT-COMPLETE | percent-complete | 358 | PRIORITY | priority | 359 | PRODID | prodid | 360 | RECURRENCE-ID | recrrence-id | 361 | RDATE | rdate | 362 | RELATED-TO | related-to | 363 | REPEAT | repeat | 364 | RESORCES | resources | 365 | RRULE | rrule | 366 | SEQUENCE | sequence | 367 | STATUS | status | 368 | SUMMARY | summary | 369 | TRANSP | transp | 370 | TRIGGER | trigger | 371 | TZID | tzid | 372 | TZNAME | tzname | 373 | TZOFFSETTO | tzoffsetto | 374 | TZOFFSETFROM | tzoffsetfrom | 375 | TZURL | tzurl | 376 | URL | url | 377 | UID | uid | 378 | VERSION | version | 379 | X-... | x-... | 380 | ... | ... | 381 +------------------+------------------+ 383 The semantics for these are as specified for the corresponding 384 calendar property in [iCAL]. 386 2.8 Mapping All Components to XML 388 All components in xCal are mapped to their component name without the 389 BEGIN tag. This example show how many component names are mapped to 390 xCal lower case names: 392 +----------------+-------------+------------------------------+ 393 | Component | Element | Example | 394 +----------------+-------------+------------------------------+ 395 | VEVENT | vevent | ... | 396 | VTODO | vtodo | ... | 397 | VJOURNAL | vjournal | ... | 398 | VTIMEZONE | vtimezone | ... | 399 | STANDARD | standard | ... | 400 | DAYLIGHT | daylight | ... | 401 | X-... | x-... | ... | 402 | ... | ... | ... | 403 +----------------+-------------+------------------------------- 405 2.9 Mapping All Values to XML 407 The [iCAL] specification specifies that the equivalent component 408 properties to the "comment", "description", "location", "summary" and 409 "contact" element types can contain formatted content, such as is 410 specified by multiple lines of text. In such cases, the formatted 411 text should be specified in as CDATA Section content. The CDATA 412 section specifies arbitrary character data that is not meant to be 413 interpretted. It is not scanned for markup by the XML parser. The 414 CDATA Section in these element types MUST NOT contain markup or other 415 such alternate representation of the property value. 417 Values MUST NOT be mapped to lower case. iCalendar property values 418 and iCalendar parameter values are used without lower case 419 conversion. 421 Vaues that have characters forbidden by XML MUST be encoded using 422 standard XML escaping mechanisms. 424 Values that containe XML tags like in this example: 426 DESCRIPTION:How to map xml DESCRIPTION into 427 an XML element. 429 Would be encoded using standard XML encoding as shown here: 431 How to map xml DESCRIPTION into 432 an XML <description> element. 434 2.10 Emailing the iCalendar XML Representation 436 It is expected that iCalendar XML documents will need to be sent over 437 SMTP/MIME email. The "text/xml" and "application/xml" content-types 438 have been registered for XML documents. However, use of these 439 content-type definitions present some problems for XML applications 440 such as calendaring and scheduling. 442 The "text/xml" and "application/xml" content-type definitions do not 443 provide for any header field parameters to identify the type of XML 444 document contained in the MIME entity. This means that a recipient 445 mail user agent must (MUA) open up each "text/xml" or "application/ 446 xml" content in order to determine what object handler is needed to 447 process the information. To a MUA, all XML documents look like just 448 plain "text/xml" or "application/xml" content. 450 Additionally, it is accepted practice for a MUA to provide iconic 451 feedback to the user for individual content-types that are supported 452 by the MUA. For example, not only would feedback be provided for a 453 calendaring and scheduling content. Some further unique 454 identification would also be provided for each different scheduling 455 message; such as a meeting invitation, response to an invitation, 456 reschedule notice, cancellation notice, etc. In such cases, 457 acceptable performance by the MUA is dependent on the existence of 458 header field information, such as it provided in the definition of 459 the "text/calendar" content-type by [iCAL]. 461 Internet application conforming to this memo MUST identify iCalendar 462 XML documents with the experimental content-type "application/ 463 calendar+xml". The content-type header field SHOULD also contain a 464 "component" and "method" parameter to clearly identify a comma- 465 separated list of components and the singular method used in the 466 iCalendar XML document. For example, an iCalendar XML document 467 specifying a REQUEST for a VEVENT would be specified with the 468 following content-type header field: 470 content-type:application/calendar+xml;method=REQUEST;component=VEVENT 472 The content-type can also include the "optinfo" parameter to specify 473 any other optional iCalendar information. The semantics of these 474 content-type parameters is as defined in [iCAL]. 476 Internet applications conforming to this memo MUST only send the 477 iCalendar XML document in a "multipart/alternative" MIME entity that 478 also contains an equivalent iCalendar object in the standard format 479 defined by [iCAL]. This restrict will guarantee that the iCalendar 480 object can also be processed by internet applications that only 481 support the standard iCalendar format. 483 An XML application supporting the iCalendar XML document type MUST be 484 able to receive and properly process the "application/calendar+xml" 485 document contained within a "multipart" message content-type. 487 2.11 iCalendar XML Representation and File Systems 489 The iCalendar XML documents will be stored in file systems. The 490 accepted practice for file extensions for XML documents is the text 491 "XML". However, in order to uniquely identify iCalendar XML 492 documents for file association with applications that can directly 493 process this document type, it is RECOMMENDED that the file extension 494 be the text "XCS". 496 3. Example Usage 498 The following sections provide various examples of iCalendar XML 499 documents. 501 3.1 A well-formed and valid iCalendar XML document 503 The following is a simple example of a iCalendar XML document. This 504 document is both a well-formed and valid XML document. The iCalendar 505 object specifies an appointment. 507 508 509 510 PUBLISH 511 2.0 512 -//HandGen//NONSGML vGen v1.0//EN 513 514 19981116T150000@cal10.host.com 515 19981116T145958Z 516 Project XYZ Review 517 Conference Room 23A 518 19981116T163000Z 519 19981116T190000Z 520 1998-ABC Corp-1234 521 Appointment,Work 522 523 524 526 3.2 Including binary content in attachments 528 The following is an example of a valid iCalendar XML document that 529 also includes an external reference to an attachment. The iCalendar 530 object specifies a meeting invitation with an attachment. 532 533 537 538 REQUEST 539 2.0 540 -//HandGen//NONSGML vGen v1.0//EN 541 542 19981211T133000@cal1.host.com 543 19981211T132928Z 544 cap://host.com/jim 545 19981212T150000Z 546 19981212T160000Z 547 Department Meeting 548 Conference Room 23A 549 jim@host.com 550 MAILTO:joe@host.com 552 MAILTO:steve@host.com 554 http://host.com/pub/photos/holiday.jpg 555 556 557 559 The following is an example of a well-formed and valid iCalendar XML 560 document that includes an attachment as inline binary content. The 561 iCalendar object specifies a meeting invitation with an attachment. 563 564 567 568 569 REQUEST 570 2.0 571 -//HandGen//NONSGML vGen v1.0//EN 572 573 19981211T133000@cal1.host.com 574 19981211T132928Z 575 MAILTO:jim@host.com 576 19981212T150000Z 577 19981212T160000Z 578 Department Meeting 579 Conference Room 23A 580 MAILTO:jim@host.com 581 MAILTO:joe@host.com 583 MAILTO:steve@host.com 585 MIICajCCAdOgAwIBAgI 586 CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB 587 lIEjYXRpb25z...and so on...IENvcnBvc== 588 589 590 592 3.3 iCalendar XML document with multiple iCalendar objects 594 The following is an example of a well-formed and valid iCalendar XML 595 document that includes more than one iCalendar object. 597 598 601 602 603 PUBLISH 604 2.0 605 -//HandGen//NONSGML vGen v1.0//EN 606 607 608 2.0 609 -//HandGen//NONSGML vGen v1.0//EN 610 PUBLISH 611 612 19981009T233010@cal1.host.com 613 19981009T233000Z 614 19981120T133000Z 615 19981122T183000Z 616 IT Conference 617 Downtowner Hotel 618 619 620 622 3.4 Using the iCalendar namespace 624 The following is an example of a snippet of a XML document that 625 includes elements from the iCalendar name-space. 627 628 xmlns:pdi="http://pdi.org/schema"> 629 19981123T133000Z 630 19981123T203000Z 631 1234567 632 999.99 633 635 3.5 Publish meeting information 637 The following is a snippet of an iCalendar XML document that 638 publishes information about a meeting. 640 641 642 2.0 643 -//hacksw/handcal//NONSGML 1.0//EN 644 PUBLISH 645 646 19970901T130000Z-123401@host.com 647 19970901T130000Z 648 19970903T163000Z 649 19970903T190000Z 650 Annual Employee Review 651 PRIVATE 652 Business,Human Resources 653 654 655 657 3.6 Publish transparent annual event 659 The following is a snippet of an iCalendar XML document that 660 publishes information about an annually repeating event that is 661 transparent to busy time searches. 663 664 665 2.0 666 667 PUBLISH 668 669 19990101T125957Z-123403@host.com 670 19990101T130000Z 671 19991102 672 Our Blissful Anniversary 673 CONFIDENTIAL 674 TRANSPARENT 675 Anniversary,Personal,Special Occasion 676 FREQ=YEARLY 677 678 679 681 3.7 Meeting invitation 683 The following is a snippet of an iCalendar XML document that 684 specifies an invitation for a meeting. The meeting occurs on the 685 first Monday of each year for five years. 687 688 689 REQUEST 690 2.0 691 -//hacksw/handcal//NONSGML 1.0//EN 692 693 19981220T130000Z-123403@host.com 694 19981220T130050Z 695 MAILTO:corprel@host.com 696 19990104T140000Z 697 19990104T220000Z 698 Annual Stockholders Meeting 699 One Corporate Drive, Wilmington, DL 700 MAILTO:mrbig@host.com 701 CAP:host.com/stockholders 703 Business,Meeting,Special Occasion 704 FREQ=YEARLY;COUNT=5;BYDAY=1MO 705 706 707 709 3.8 Publish busy time 711 The following is an iCalendar XML document that publishes busy time 712 information. The default value for the "method" attribute is 713 "PUBLISH" and does not need to be specified in this example. 715 716 717 2.0 718 -//hacksw/handcal//NONSGML 1.0//EN 719 720 19980313T133000@ical1.host.com 721 19990104T133010Z 722 CAP:host.com/jsmith 723 19980313T141711Z 724 19980410T141711Z 725 jsmith.ifb 726 19980314T233000Z/19980315T003000Z 727 19980316T153000Z/19980316T163000Z 728 19980318T030000Z/19980318T040000Z 729 730 731 733 3.9 Request busy time 735 The following is a snippet of an iCalendar XML document that requests 736 a calendar user's busy time information. 738 739 740 REQUEST 741 2.0 742 -//hacksw/handcal//NONSGML 1.0//EN 743 744 19970901T083000@ical1.host.com 745 19970901T083000Z 746 MAILTO:jane_doe@host1.com 747 19971015T050000Z 748 19971016T050000Z 749 MAILTO:john_public@host2.com 750 751 752 754 3.10 Issue a CAP command 756 The following is a snippet of an iCalendar XML document that issues a 757 CAP command to delete a UID. 759 760 761 2.0 762 -//hacksw/handcal//NONSGML 1.0//EN 763 relcalid-22 764 DELETE 765 766 SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345' 767 768 769 771 4. Acknowledgments 773 The following have participated in the drafting and discussion of 774 this memo: 776 Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert, 777 Thomas Rowe. 779 5. IANA Considerations 781 TODO - registration if application/calendar+xml 783 6. Security Considerations 785 CDATA Sections - - A XML iCalendar document may contain CDATA 786 sections to represent content for specific element types. The CDATA 787 section specifies arbitrary character data that is not meant to be 788 interpretted. It is not scanned by the XML parser for markup. While 789 this memo restricts that any CDATA section MUST NOT contain markup or 790 other such alternate representation for the property value, in 791 general, CDATA section from a non-conformant implementation can 792 contain content such as HTML markup. HTML text can be used to invoke 793 programs. Implementors should be aware that this may leave an 794 implementation open to malicious attack that might occur as a result 795 of executing the markup in the CDATA section. 797 PROCEDURAL ALARMS - - A XML iCalendar document can be created that 798 contains a "VEVENT" calendar component with "VALARM" calendar 799 components. The "VALARM" calendar component can be of type PROCEDURE 800 and can have an attachment containing some sort of executable 801 program. Implementations that incorporate these types of alarms are 802 subject to any virus or malicious attack that might occur as a result 803 of executing the attachment. 805 ATTACHMENTS - - A XML iCalendar document can include references to 806 Uniform Resource Locators that can be programmed resources. 807 Implementers and users of this memo should be aware of the network 808 security implications of accepting and parsing such information. 810 In addition, the security considerations observed by implementations 811 of electronic mail systems should be followed for this memo. 813 7. Bibliography 815 [BASIC] D. Royer, "Basic Internet Calendaring and Scheduling Core 816 Object Specification", Internet Draft, http://www.internic.net/ 817 internet-drafts/draft-royer-ical-basic-03.txt, June 2005. 819 [ISO9070] "Information Technology_SGML Support Facilities_ 820 Registration Procedures for Public Text Owner Identifiers", ISO/IEC 821 9070, Second Edition, International Organization for Standardization, 822 April 1991. 824 [MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail 825 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 826 2045, November 1996. 828 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 829 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt, 830 March 1997. 832 [iCAL] F. Dawson and D. Stenerson, "Internet Calendaring and 833 Scheduling Core Object Specification (iCalendar)", RFC 2445, 834 http://www.ietf.org/rfc/rfc2445.txt, November 1998. 836 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 837 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 839 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 840 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 842 Author's Address 844 Doug Royer 845 IntelliCal LLC 846 267 Kentlands Blvd., #3041 847 Gaithersburg, MD 20878 848 US 850 Phone: (208)881-0380 851 Email: Doug@Royer.com 853 Intellectual Property Statement 855 The IETF takes no position regarding the validity or scope of any 856 Intellectual Property Rights or other rights that might be claimed to 857 pertain to the implementation or use of the technology described in 858 this document or the extent to which any license under such rights 859 might or might not be available; nor does it represent that it has 860 made any independent effort to identify any such rights. Information 861 on the procedures with respect to rights in RFC documents can be 862 found in BCP 78 and BCP 79. 864 Copies of IPR disclosures made to the IETF Secretariat and any 865 assurances of licenses to be made available, or the result of an 866 attempt made to obtain a general license or permission for the use of 867 such proprietary rights by implementers or users of this 868 specification can be obtained from the IETF on-line IPR repository at 869 http://www.ietf.org/ipr. 871 The IETF invites any interested party to bring to its attention any 872 copyrights, patents or patent applications, or other proprietary 873 rights that may cover technology that may be required to implement 874 this standard. Please address the information to the IETF at 875 ietf-ipr@ietf.org. 877 Disclaimer of Validity 879 This document and the information contained herein are provided on an 880 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 881 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 882 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 883 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 884 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 887 Copyright Statement 889 Copyright (C) The Internet Society (2005). This document is subject 890 to the rights, licenses and restrictions contained in BCP 78, and 891 except as set forth therein, the authors retain all their rights. 893 Acknowledgment 895 Funding for the RFC Editor function is currently provided by the 896 Internet Society.