idnits 2.17.1 draft-royer-calsch-xcal-03.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 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. ** 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 3 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 187: '... to this specification MUST be able to...' RFC 2119 keyword, line 191: '...orming to this memo MUST only send the...' RFC 2119 keyword, line 351: '... Values MUST NOT be mapped to lower ...' RFC 2119 keyword, line 355: '...forbidden by XML MUST be encoded using...' RFC 2119 keyword, line 395: '...ing to this memo MUST identify iCalend...' (4 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 (October 22, 2005) is 6761 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 757 looks like a reference -- Missing reference section? 'XML' on line 774 looks like a reference -- Missing reference section? 'XMLNS' on line 157 looks like a reference -- Missing reference section? 'BASIC' on line 744 looks like a reference -- Missing reference section? 'ISO9070' on line 748 looks like a reference -- Missing reference section? 'MIME' on line 753 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 13 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: April 25, 2006 October 22, 2005 6 iCalendar in XML Format (xCal-Basic) 7 draft-royer-calsch-xcal-03 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 April 25, 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 Including Multiple iCalendar Objects . . . . . . . . . . . 5 60 2.4 Mapping Property Parameters to XML . . . . . . . . . . . . 6 61 2.5 Mapping VCALENDAR object Properties to XML . . . . . . . . 7 62 2.6 Mapping All Components to XML . . . . . . . . . . . . . . 8 63 2.7 Mapping All Values to XML . . . . . . . . . . . . . . . . 9 64 2.8 Emailing the iCalendar XML Representation . . . . . . . . 10 65 2.9 iCalendar XML Representation and File Systems . . . . . . 11 66 3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.1 A well-formed and valid iCalendar XML document . . . . . . 12 68 3.2 Including binary content in attachments . . . . . . . . . 12 69 3.3 iCalendar XML document with multiple iCalendar objects . . 14 70 3.4 Using the iCalendar namespace . . . . . . . . . . . . . . 15 71 3.5 Publish meeting information . . . . . . . . . . . . . . . 15 72 3.6 Publish transparent annual event . . . . . . . . . . . . . 16 73 3.7 Meeting invitation . . . . . . . . . . . . . . . . . . . . 16 74 3.8 Publish busy time . . . . . . . . . . . . . . . . . . . . 17 75 3.9 Request busy time . . . . . . . . . . . . . . . . . . . . 18 76 3.10 Issue a CAP command . . . . . . . . . . . . . . . . . . . 18 77 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 82 Intellectual Property and Copyright Statements . . . . . . . . 23 84 1. Introduction 86 xCal is a representation of iCalendar objects in XML. xCal is not an 87 alternative or next generation of iCalendar. This memo defines how 88 to use XML to represent iCalendar objects in XML. These XML object 89 can be embedded into other XML documents using the XML syntax here. 90 xCal does represent iCalendar componnts, properties, and parameters 91 as defined in iCalendar. As iCalendar evolves the one to one mapping 92 of iCalendar objects into xCal will continue to work as this memo 93 describes the mapping of iCalendar objects.. Within this memo the 94 term "xCal" will mean the XML namespace usage as described in this 95 memo. 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: That [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 [iCAL]. 106 2. Using XML For Representating iCalendar 108 In iCalendar names can be in upper case, lower case, or mixed case. 109 In xCal the predefined iCaledars names will be represented in lower 110 case only as XML element and attribute names are case sensitive. 111 Values to properties and parameters that are user specified may be in 112 upper, lower, or mixed case. 114 All iCalendar component names will be represented in xCal as XML 115 element names in lower case. The "BEGIN:" iCalendar component are 116 represen in xCal as the component name it self in lower case. 117 (BEGIN:VEVENT becomes ). 119 All iCalendar property names will be represented in xCal as XML 120 element names in lower case. 122 All iCalendar parameter names will be represented in xCal as XML 123 attribute names in lower case. 125 All iCalendar property and parameter values will be represented in 126 xCal unchanged. 128 BEGIN:VCALENDAR 129 VERSION:2.0 130 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 131 BEGIN:VEVENT 132 DTSTART:19970714T170000Z 133 DTEND:19970715T035959Z 134 SUMMARY;LANGUAGE="en_US":Bastille Day Party 135 END:VEVENT 136 END:VCALENDAR 138 Is represented in xCal as: 140 141 142 143 2.0 144 -//hacksw/handcal//NONSGML v1.0//EN 145 146 19970714T170000Z 147 19970715T035959Z 148 Bastille Day Party 149 150 151 153 2.1 XML Dependencies 155 This memo specifies the XML representation for the standard iCalendar 156 format defined by [iCAL]. There are no XML dependencies other than 157 the [XML] and the [XMLNS] recommendations. 159 2.2 Working With Standard and XML iCalendar Representations 161 This memo defines an alternative, XML representation for the standard 162 iCalendar format defined in [iCAL]. This alternative representation 163 provides the same semantics as that defined in the standard format. 164 It is the goal of this memo to allow all [iCAL] extensions and 165 modifications to be translated into and from this XML format. 167 2.2.1 Conversion 169 The standard format can be converted to and from this XML format 170 without loss of any calendaring information. When the XML 171 representation was defined, every attempt was made to use existing 172 component, property and parameter naming conventions. This greatly 173 facilitates transformations between the two representations. 175 2.2.2 Mixed Use of Both Representations 177 As previously indicated, conversion between the standard and XML 178 representations of iCalendar is a straightforward process. In 179 addition, mixed use of both representations is also possible using 180 MIME objects. 182 With the use of the MIME multipart content-types, compound MIME 183 entities containing a mix of the standard and XML representations can 184 be specified. This capability is useful in applications where both 185 representations might be encountered. In addition, this capability 186 demonstrates the isomeric nature of the two representations. XML 187 applications conforming to this specification MUST be able to 188 properly parse and process a MIME multipart entity containing the 189 MIME type associated with this iCalendar XML document type. 191 Internet applications conforming to this memo MUST only send the 192 iCalendar XML document in a "multipart/alternative" MIME entity that 193 also contains an equivalent iCalendar object in the standard format 194 defined by [iCAL]. This restriction will guarantee that the 195 iCalendar object can also be processed by Internet applications that 196 only support the standard iCalendar representation. 198 2.3 Including Multiple iCalendar Objects 200 The iCalendar format has the capability for including multiple, 201 individual iCalendar objects in a single data stream, as can be 202 needed by [iTIP]. The XML representation can support this also. 203 Individual iCalendar objects are specified by the "vcalendar" element 204 type. One or more "vcalendar" element types are permitted within the 205 parent element type, called "iCalendar". For example: 207 208 209 2.0 210 211 212 213 2.0 214 215 > 216 218 2.4 Mapping Property Parameters to XML 220 The property parameters defined in the standard iCalendar format are 221 represented in the XML representation as an attribute on element 222 types. The following table specifies some of the attribute name 223 corresponding to each property parameter. This is true for all 224 iCalendar object parameters defined in any iCalendar specification. 225 The property and paramater names will be all lower case. Here are 226 some iCalendar parameter names and how they are mapped to their lower 227 case xCal names. 229 NOTE: that the iCalendar "language" parameter is converted to the 230 "xml:lang" attribute as an exception to the one to one mapping. 232 +----------------+----------------+ 233 | Property | Attribute | 234 | Parameter Name | Name | 235 +----------------+----------------+ 236 | ALTREP | altrep | 237 | CN | cn | 238 | CUTYPE | cutype | 239 | DELEGATED-FROM | delegated-from | 240 | DELEGATED-TO | delegated-to | 241 | DIR | dir | 242 | FMTTYPE | fmttype | 243 | FBTYPE | fbtype | 244 | LANGUAGE | xml:lang | 245 | MEMBER | member | 246 | PARTSTAT | partstat | 247 | RANGE | range | 248 | RELATED | related | 249 | RELTYPE | reltype | 250 | ROLE | role | 251 | RSVP | rsvp | 252 | SENT-BY | sent-by | 253 | TZID | tzid | 254 | VALUE | value | 255 | X-... | x-... | 256 | ..... | ..... | 257 +----------------+----------------+ 259 2.5 Mapping VCALENDAR object Properties to XML 261 Calendar properties defined in the standard iCalendar format provide 262 information about an iCalendar object, as a whole. The calendar 263 properties are represented in the XML representation as element types 264 as shown in lower case. Here is a list of some iCalendar properties 265 and them mapped to xCal lower case names: 267 +------------------+------------------+ 268 | Calendar | Tag | 269 | Property Name | Name | 270 +------------------+------------------+ 271 | ACTION | action | 272 | ATTACH | attach | 273 | ATTENDEE | attendee | 274 | CALSCALE | calscale | 275 | CATEGORIES | categories | 276 | CLASS | class | 277 | COMMENT | comment | 278 | COMPLETED | completed | 279 | CONTACT | contact | 280 | CREATED | created | 281 | DESCRIPTION | description | 282 | DTEND | dtend | 283 | DTSTART | dtstart | 284 | DTSTAMP | dtstamp | 285 | DUE | due | 286 | DURATION | duration | 287 | EXDATE | exdate | 288 | EXRULE | exrule | 289 | FREEBUSY | freebusy | 290 | GEO | geo | 291 | LAST-MODIFIED | last-modified | 292 | LOCATION | location | 293 | METHOD | method | 294 | ORGANIZER | organizer | 295 | PERCENT-COMPLETE | percent-complete | 296 | PRIORITY | priority | 297 | PRODID | prodid | 298 | RECURRENCE-ID | recrrence-id | 299 | RDATE | rdate | 300 | RELATED-TO | related-to | 301 | REPEAT | repeat | 302 | RESORCES | resources | 303 | RRULE | rrule | 304 | SEQUENCE | sequence | 305 | STATUS | status | 306 | SUMMARY | summary | 307 | TRANSP | transp | 308 | TRIGGER | trigger | 309 | TZID | tzid | 310 | TZNAME | tzname | 311 | TZOFFSETTO | tzoffsetto | 312 | TZOFFSETFROM | tzoffsetfrom | 313 | TZURL | tzurl | 314 | URL | url | 315 | UID | uid | 316 | VERSION | version | 317 | X-... | x-... | 318 | ... | ... | 319 +------------------+------------------+ 321 The semantics for these are as specified for the corresponding 322 calendar property in [iCAL]. 324 2.6 Mapping All Components to XML 326 All components in xCal are mapped to their component name without the 327 BEGIN tag. This example show how many component names are mapped to 328 xCal lower case names: 330 +----------------+-------------+------------------------------+ 331 | Component | Element | Example | 332 +----------------+-------------+------------------------------+ 333 | VEVENT | vevent | ... | 334 | VTODO | vtodo | ... | 335 | VJOURNAL | vjournal | ... | 336 | VTIMEZONE | vtimezone | ... | 337 | STANDARD | standard | ... | 338 | DAYLIGHT | daylight | ... | 339 | X-... | x-... | ... | 340 | ... | ... | ... | 341 +----------------+-------------+------------------------------- 343 2.7 Mapping All Values to XML 345 The [iCAL] specification specifies that the equivalent component 346 properties to the "comment", "description", "location", "summary" and 347 "contact" element types can contain formatted content, such as is 348 specified by multiple lines of text. In such cases, the formatted 349 text should be specified using standard XML escaping. 351 Values MUST NOT be mapped to lower case. iCalendar property values 352 and iCalendar parameter values are used without lower case 353 conversion. 355 Vaues that have characters forbidden by XML MUST be encoded using 356 standard XML escaping mechanisms. 358 Values that containe XML tags like in this example: 360 DESCRIPTION:How to map xml DESCRIPTION into 361 an XML element. 363 Would be encoded using standard XML encoding as shown here: 365 How to map xml DESCRIPTION into 366 an XML <description> element. 368 2.8 Emailing the iCalendar XML Representation 370 It is expected that iCalendar XML documents will need to be sent over 371 SMTP/MIME email. The "text/xml" and "application/xml" content-types 372 have been registered for XML documents. However, use of these 373 content-type definitions present some problems for XML applications 374 such as calendaring and scheduling. 376 The "text/xml" and "application/xml" content-type definitions do not 377 provide for any header field parameters to identify the type of XML 378 document contained in the MIME entity. This means that a recipient 379 mail user agent must (MUA) open up each "text/xml" or "application/ 380 xml" content in order to determine what object handler is needed to 381 process the information. To a MUA, all XML documents look like just 382 plain "text/xml" or "application/xml" content. 384 Additionally, it is accepted practice for a MUA to provide iconic 385 feedback to the user for individual content-types that are supported 386 by the MUA. For example, not only would feedback be provided for a 387 calendaring and scheduling content. Some further unique 388 identification would also be provided for each different scheduling 389 message; such as a meeting invitation, response to an invitation, 390 reschedule notice, cancellation notice, etc. In such cases, 391 acceptable performance by the MUA is dependent on the existence of 392 header field information, such as it provided in the definition of 393 the "text/calendar" content-type by [iCAL]. 395 Internet application conforming to this memo MUST identify iCalendar 396 XML documents with the experimental content-type "application/ 397 calendar+xml". 399 content-type:application/calendar+xml 401 The content-type can also include the "optinfo" parameter to specify 402 any other optional iCalendar information. The semantics of these 403 content-type parameters is as defined in [iCAL]. 405 Internet applications conforming to this memo MUST only send the 406 iCalendar XML document in a "multipart/alternative" MIME entity that 407 also contains an equivalent iCalendar object in the standard format 408 defined by [iCAL]. This restrict will guarantee that the iCalendar 409 object can also be processed by internet applications that only 410 support the standard iCalendar format. 412 An XML application supporting the iCalendar XML document type MUST be 413 able to receive and properly process the "application/calendar+xml" 414 document contained within a "multipart" message content-type. 416 2.9 iCalendar XML Representation and File Systems 418 The iCalendar XML documents will be stored in file systems. The 419 accepted practice for file extensions for XML documents is the text 420 "XML". However, in order to uniquely identify iCalendar XML 421 documents for file association with applications that can directly 422 process this document type, it is RECOMMENDED that the file extension 423 be the text "XCS". 425 3. Example Usage 427 The following sections provide various examples of iCalendar XML 428 documents. 430 3.1 A well-formed and valid iCalendar XML document 432 The following is a simple example of a iCalendar XML document. This 433 document is both a well-formed and valid XML document. The iCalendar 434 object specifies an appointment. 436 437 438 439 PUBLISH 440 2.0 441 -//HandGen//NONSGML vGen v1.0//EN 442 443 19981116T150000@cal10.host.com 444 19981116T145958Z 445 Project XYZ Review 446 Conference Room 23A 447 19981116T163000Z 448 19981116T190000Z 449 1998-ABC Corp-1234 450 Appointment,Work 451 452 453 455 3.2 Including binary content in attachments 457 The following is an example of a valid iCalendar XML document that 458 also includes an external reference to an attachment. The iCalendar 459 object specifies a meeting invitation with an attachment. 461 462 466 467 REQUEST 468 2.0 469 -//HandGen//NONSGML vGen v1.0//EN 470 471 19981211T133000@cal1.host.com 472 19981211T132928Z 473 cap://host.com/jim 474 19981212T150000Z 475 19981212T160000Z 476 Department Meeting 477 Conference Room 23A 478 jim@host.com 479 MAILTO:joe@host.com 481 MAILTO:steve@host.com 483 http://host.com/pub/photos/holiday.jpg 484 485 486 488 The following is an example of a well-formed and valid iCalendar XML 489 document that includes an attachment as inline binary content. The 490 iCalendar object specifies a meeting invitation with an attachment. 492 493 496 497 498 REQUEST 499 2.0 500 -//HandGen//NONSGML vGen v1.0//EN 501 502 19981211T133000@cal1.host.com 503 19981211T132928Z 504 MAILTO:jim@host.com 505 19981212T150000Z 506 19981212T160000Z 507 Department Meeting 508 Conference Room 23A 509 MAILTO:jim@host.com 510 MAILTO:joe@host.com 512 MAILTO:steve@host.com 514 MIICajCCAdOgAwIBAgI 515 CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB 516 lIEjYXRpb25z...and so on...IENvcnBvc== 517 518 519 521 3.3 iCalendar XML document with multiple iCalendar objects 523 The following is an example of a well-formed and valid iCalendar XML 524 document that includes more than one iCalendar object. 526 527 530 531 532 PUBLISH 533 2.0 534 -//HandGen//NONSGML vGen v1.0//EN 535 536 537 2.0 538 -//HandGen//NONSGML vGen v1.0//EN 539 PUBLISH 540 541 19981009T233010@cal1.host.com 542 19981009T233000Z 543 19981120T133000Z 544 19981122T183000Z 545 IT Conference 546 Downtowner Hotel 547 548 549 551 3.4 Using the iCalendar namespace 553 The following is an example of a snippet of a XML document that 554 includes elements from the iCalendar name-space. 556 557 xmlns:pdi="http://pdi.org/schema"> 558 19981123T133000Z 559 19981123T203000Z 560 1234567 561 999.99 562 564 3.5 Publish meeting information 566 The following is a snippet of an iCalendar XML document that 567 publishes information about a meeting. 569 570 571 2.0 572 -//hacksw/handcal//NONSGML 1.0//EN 573 PUBLISH 574 575 19970901T130000Z-123401@host.com 576 19970901T130000Z 577 19970903T163000Z 578 19970903T190000Z 579 Annual Employee Review 580 PRIVATE 581 Business,Human Resources 582 583 584 586 3.6 Publish transparent annual event 588 The following is a snippet of an iCalendar XML document that 589 publishes information about an annually repeating event that is 590 transparent to busy time searches. 592 593 594 2.0 595 596 PUBLISH 597 598 19990101T125957Z-123403@host.com 599 19990101T130000Z 600 19991102 601 Our Blissful Anniversary 602 CONFIDENTIAL 603 TRANSPARENT 604 Anniversary,Personal,Special Occasion 605 FREQ=YEARLY 606 607 608 610 3.7 Meeting invitation 612 The following is a snippet of an iCalendar XML document that 613 specifies an invitation for a meeting. The meeting occurs on the 614 first Monday of each year for five years. 616 617 618 REQUEST 619 2.0 620 -//hacksw/handcal//NONSGML 1.0//EN 621 622 19981220T130000Z-123403@host.com 623 19981220T130050Z 624 MAILTO:corprel@host.com 625 19990104T140000Z 626 19990104T220000Z 627 Annual Stockholders Meeting 628 One Corporate Drive, Wilmington, DL 629 MAILTO:mrbig@host.com 630 CAP:host.com/stockholders 632 Business,Meeting,Special Occasion 633 FREQ=YEARLY;COUNT=5;BYDAY=1MO 634 635 636 638 3.8 Publish busy time 640 The following is an iCalendar XML document that publishes busy time 641 information. The default value for the "method" attribute is 642 "PUBLISH" and does not need to be specified in this example. 644 645 646 2.0 647 -//hacksw/handcal//NONSGML 1.0//EN 648 649 19980313T133000@ical1.host.com 650 19990104T133010Z 651 CAP:host.com/jsmith 652 19980313T141711Z 653 19980410T141711Z 654 jsmith.ifb 655 19980314T233000Z/19980315T003000Z 656 19980316T153000Z/19980316T163000Z 657 19980318T030000Z/19980318T040000Z 658 659 660 662 3.9 Request busy time 664 The following is a snippet of an iCalendar XML document that requests 665 a calendar user's busy time information. 667 668 669 REQUEST 670 2.0 671 -//hacksw/handcal//NONSGML 1.0//EN 672 673 19970901T083000@ical1.host.com 674 19970901T083000Z 675 MAILTO:jane_doe@host1.com 676 19971015T050000Z 677 19971016T050000Z 678 MAILTO:john_public@host2.com 679 680 681 683 3.10 Issue a CAP command 685 The following is a snippet of an iCalendar XML document that issues a 686 CAP command to delete a UID. 688 689 690 2.0 691 -//hacksw/handcal//NONSGML 1.0//EN 692 relcalid-22 693 DELETE 694 695 SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345' 696 697 698 700 4. Acknowledgments 702 The following have participated in the drafting and discussion of 703 this memo: 705 Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert, 706 Thomas Rowe. 708 5. IANA Considerations 710 TODO - registration if application/calendar+xml 712 6. Security Considerations 714 CDATA Sections - - A XML iCalendar document may contain CDATA 715 sections to represent content for specific element types. The CDATA 716 section specifies arbitrary character data that is not meant to be 717 interpretted. It is not scanned by the XML parser for markup. While 718 this memo restricts that any CDATA section MUST NOT contain markup or 719 other such alternate representation for the property value, in 720 general, CDATA section from a non-conformant implementation can 721 contain content such as HTML markup. HTML text can be used to invoke 722 programs. Implementors should be aware that this may leave an 723 implementation open to malicious attack that might occur as a result 724 of executing the markup in the CDATA section. 726 PROCEDURAL ALARMS - - A XML iCalendar document can be created that 727 contains a "VEVENT" calendar component with "VALARM" calendar 728 components. The "VALARM" calendar component can be of type PROCEDURE 729 and can have an attachment containing some sort of executable 730 program. Implementations that incorporate these types of alarms are 731 subject to any virus or malicious attack that might occur as a result 732 of executing the attachment. 734 ATTACHMENTS - - A XML iCalendar document can include references to 735 Uniform Resource Locators that can be programmed resources. 736 Implementers and users of this memo should be aware of the network 737 security implications of accepting and parsing such information. 739 In addition, the security considerations observed by implementations 740 of electronic mail systems should be followed for this memo. 742 7. Bibliography 744 [BASIC] D. Royer, "Basic Internet Calendaring and Scheduling Core 745 Object Specification", Internet Draft, http://www.internic.net/ 746 internet-drafts/draft-royer-ical-basic-03.txt, June 2005. 748 [ISO9070] "Information Technology_SGML Support Facilities_ 749 Registration Procedures for Public Text Owner Identifiers", ISO/IEC 750 9070, Second Edition, International Organization for Standardization, 751 April 1991. 753 [MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail 754 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 755 2045, November 1996. 757 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 758 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt, 759 March 1997. 761 [iCAL] F. Dawson and D. Stenerson, "Internet Calendaring and 762 Scheduling Core Object Specification (iCalendar)", RFC 2445, 763 http://www.ietf.org/rfc/rfc2445.txt, November 1998. This is the 764 current version of iCalednar used in examples in this memo. 766 [iTIP] S. Silverbert, S. Mansour, F. Dawson, R. Hopson, "iCalendar 767 Transport-Independent Interoperability Protocol"", RFC 2446, 768 http://www.ietf.org/rfc/rfc2446.txt, November 1998. This is the 769 current version of iTIP used in examples in this memo. 771 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 772 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 774 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 775 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 777 Author's Address 779 Doug Royer 780 IntelliCal LLC 781 267 Kentlands Blvd., #3041 782 Gaithersburg, MD 20878 783 US 785 Phone: (208)881-0380 786 Email: Doug@Royer.com 788 Intellectual Property Statement 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Disclaimer of Validity 814 This document and the information contained herein are provided on an 815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 817 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 818 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 822 Copyright Statement 824 Copyright (C) The Internet Society (2005). This document is subject 825 to the rights, licenses and restrictions contained in BCP 78, and 826 except as set forth therein, the authors retain all their rights. 828 Acknowledgment 830 Funding for the RFC Editor function is currently provided by the 831 Internet Society.