idnits 2.17.1 draft-royer-calsch-xcal-01.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 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 940. ** 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 12 instances of too long lines in the document, the longest one being 12 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 212: '... to this specification MUST be able to...' RFC 2119 keyword, line 216: '...orming to this memo MUST only send the...' RFC 2119 keyword, line 402: '... The iCalendar XML document type MUST...' RFC 2119 keyword, line 405: '...bute with the prefix "xmlns:" MUST be:...' RFC 2119 keyword, line 449: '...se element types MUST NOT contain mark...' (9 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 6817 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 893 looks like a reference -- Missing reference section? 'XML' on line 904 looks like a reference -- Missing reference section? 'RFC 2445' on line 105 looks like a reference -- Missing reference section? 'RFC 2146' on line 116 looks like a reference -- Missing reference section? 'XMLNS' on line 471 looks like a reference -- Missing reference section? 'RFC2445' on line 219 looks like a reference -- Missing reference section? 'MIME' on line 889 looks like a reference -- Missing reference section? 'BASIC' on line 880 looks like a reference -- Missing reference section? 'ISO9070' on line 884 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-01 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 . . . . . . . . . . . . . . 10 65 2.9 Mapping All Values to XML . . . . . . . . . . . . . . . . 11 66 2.10 Namespace . . . . . . . . . . . . . . . . . . . . . . . . 12 67 2.11 Emailing the iCalendar XML Representation . . . . . . . . 12 68 2.12 iCalendar XML Representation and File Systems . . . . . . 13 69 3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 70 3.1 A well-formed and valid iCalendar XML document . . . . . . 14 71 3.2 Including binary content in attachments . . . . . . . . . 14 72 3.3 iCalendar XML document with multiple iCalendar objects . . 16 73 3.4 Using the iCalendar namespace . . . . . . . . . . . . . . 17 74 3.5 Publish meeting information . . . . . . . . . . . . . . . 17 75 3.6 Publish transparent annual event . . . . . . . . . . . . . 18 76 3.7 Meeting invitation . . . . . . . . . . . . . . . . . . . . 18 77 3.8 Publish busy time . . . . . . . . . . . . . . . . . . . . 19 78 3.9 Request busy time . . . . . . . . . . . . . . . . . . . . 20 79 3.10 Issue a CAP command . . . . . . . . . . . . . . . . . . . 20 80 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24 85 Intellectual Property and Copyright Statements . . . . . . . . 25 87 1. Introduction 89 The Extended Markup Language (XML) as defined in [XML] is gaining 90 widespread attention as a "web friendly" syntax for representing and 91 exchanging documents and data on the Internet. This interest 92 includes requests for and discussion of possible document type 93 definitions (DTD) and name-space for IETF standard formats such as 94 that defined by [iCAL]. This memo defines how XML can be used to 95 represent iCalendar objects and does not specify a DTD as iCalendar 96 can be extended. 98 This format was selected to ease its translation back to the 99 iCalendar format using an XSLT transform. (See project xxxxx on 100 SourceForge.com - http://xxxx.sourceforge.com ) 102 NOTE: The [iCAL] is the definitive reference for the definition of 103 iCalendar semantics. This memo only provides an alternative, XML 104 representation for the standard syntax defined in [iCAL]. This memo 105 does not introduce any semantics not already defined by [RFC 2445]. 107 An attempt has been made to leverage the standard features of the XML 108 syntax in order to represent the component iCalendar semantics. For 109 example, strong data typing is specified using the XML notation 110 declaration. The element type attributes are used to represent many 111 of the calendar properties that provide a "global attribute" 112 capability in an iCalendar object. Binary content in the ATTACH 113 component property may either be specified through an external entity 114 reference to a non-XML binary content or may be included in the XML 115 document's content information, after first being encoding using the 116 BASE64 scheme of [RFC 2146]. 118 The publication of XML version 1.0 was followed by the publication of 119 a World-wide Web Consortium (W3C) recommendation on "Namespaces in 120 XML". A XML name-space is a collection of names, identified by a 121 URI. In anticipation of the broader use of XML namespaces. Within 122 this memo the term "xCal" will mean the XML namespace usage as 123 described in this memo. 125 2. Using XML For Representating iCalendar 127 XML is a simplified version of the text markup syntax defined by ISO 128 8879, Standard Generalized Markup Language (SGML). XML was published 129 as a proposed recommendation [XML] by the World-wide Web Consortium 130 (W3C) on February 10, 1998. 132 In iCalendar names can be in upper case, lower case, or mixed case. 133 In xCal the predefined iCaledars names will be represented in lower 134 case only as XML element and attribute names are case sensitive.. 135 Values to properties and parameters that are user specified may be in 136 upper, lower, or mixed case. 138 All iCalendar component names will be represented in xCal as XML 139 element names in lower case. The "BEGIN" iCalendar component will be 140 represented in xCal as: . 142 All iCalendar property names will be represented in xCal as XML 143 element names in lower case. 145 All iCalendar parameter names will be represented in xCal as XML 146 attribute names in lower case. 148 All iCalendar predefined names that are used as values will be 149 represented in xCal in lower case. 151 This example: 153 BEGIN:VCALENDAR 154 VERSION:2.0 155 PRODID:-//hacksw/handcal//NONSGML v1.0//EN 156 BEGIN:VEVENT 157 DTSTART:19970714T170000Z 158 DTEND:19970715T035959Z 159 SUMMARY;LANGUAGE="en_US":Bastille Day Party 160 END:VEVENT 161 END:VCALENDAR 163 Is represented in xCal as: 165 166 167 168 2.0 169 -//hacksw/handcal//NONSGML v1.0//EN 170 171 19970714T170000Z 172 19970715T035959Z 173 Bastille Day Party 174 175 176 178 2.1 XML Dependencies 180 This memo specifies the XML representation for the standard iCalendar 181 format defined by [iCAL]. There are no XML dependencies other than 182 the [XML] and the [XMLNS] recommendations. 184 2.2 Working With Standard and XML iCalendar Representations 186 This memo defines an alternative, XML representation for the standard 187 iCalendar format defined in [iCAL]. This alternative representation 188 provides the same semantics as that defined in the standard format. 189 It is the goal of this memo to allow all [iCAL] extensions and 190 modifications to be translated into and from this XML format. 192 2.2.1 Conversion 194 The standard format can be converted to and from this XML format 195 without loss of any calendaring information. When the XML 196 representation was defined, every attempt was made to use existing 197 component, property and parameter naming conventions. This greatly 198 facilitates transformations between the two representations. 200 2.2.2 Mixed Use of Both Representations 202 As previously indicated, conversion between the standard and XML 203 representations of iCalendar is a straightforward process. In 204 addition, mixed use of both representations is also possible using 205 MIME objects. 207 With the use of the MIME multipart content-types, compound MIME 208 entities containing a mix of the standard and XML representations can 209 be specified. This capability is useful in applications where both 210 representations might be encountered. In addition, this capability 211 demonstrates the isomeric nature of the two representations. XML 212 applications conforming to this specification MUST be able to 213 properly parse and process a MIME multipart entity containing the 214 MIME type associated with this iCalendar XML document type. 216 Internet applications conforming to this memo MUST only send the 217 iCalendar XML document in a "multipart/alternative" MIME entity that 218 also contains an equivalent iCalendar object in the standard format 219 defined by [RFC2445]. This restriction will guarantee that the 220 iCalendar object can also be processed by Internet applications that 221 only support the standard iCalendar representation. 223 2.3 Using Data Types 225 Strong "data typing" is an integral design principle to the iCalendar 226 format. Strong data typing in iCalendar means that the format type 227 for each property value is well known. Within [iCAL], the data type 228 is called the "value type". The standard format defined by [RFC 229 2445] specifies a default value type for each calendar and component 230 property. In addition, many of the property definitions allow for 231 the specification of alternate value types. This XML representation 232 continues this design principle. 234 Explicit value/data typing in the XML representation is specified 235 with the "value" attribute on each element type. XML documents 236 conforming to this memo need only specify the "value" attribute on 237 element types when the value needs to override the default value/data 238 type defined in the iCalendar specifications. The formal public 239 identifier for standard value types all have the common string format 240 of: 242 2.4 Including Binary Content 244 Binary content can be included in an iCalendar object with the 245 "ATTACH" component property. In the standard iCalendar format this 246 content may either be specified through an external entity reference, 247 using a URI value type, or maybe specified within the iCalendar 248 object, after first BASE64 encoding the content. 250 The XML representation for iCalendar also supports including binary 251 content in an iCalendar object with the "attach" element type. It 252 also supports either an external reference to the non-XML binary 253 content or inclusion of the binary content after first encoding the 254 binary information using the BASE64 encoding of [MIME]. 256 http://host.com/bin/foo.exe 257 MIICajCC 258 AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l 259 dHNjYXBlIENvbW11bmljYXR5z...and so on...IENvcnBvc== 261 2.5 Including Multiple iCalendar Objects 263 The iCalendar format has the capability for including multiple, 264 individual iCalendar objects in a single data stream. The XML 265 representation can support this also. Individual iCalendar objects 266 are specified by the "vcalendar" element type. One or more 267 "vcalendar" element types are permitted within the parent element 268 type, called "iCalendar". For example: 270 271 272 2.0 273 274 275 276 2.0 277 278 > 279 281 2.6 Mapping Property Parameters to XML 283 The property parameters defined in the standard iCalendar format are 284 represented in the XML representation as an attribute on element 285 types. The following table specifies some of the attribute name 286 corresponding to each property parameter. This is true for all 287 iCalendar object parameters defined in any iCalendar specification. 288 The property and paramater names will be all lower case. Here are 289 some iCalendar parameter names and how they are mapped to their lower 290 case xCal names. 292 +----------------+----------------+ 293 | Property | Attribute | 294 | Parameter Name | Name | 295 +----------------+----------------+ 296 | ALTREP | altrep | 297 | CN | cn | 298 | CUTYPE | cutype | 299 | DELEGATED-FROM | delegated-from | 300 | DELEGATED-TO | delegated-to | 301 | DIR | dir | 302 | FMTTYPE | fmttype | 303 | FBTYPE | fbtype | 304 | LANGUAGE | language | 305 | MEMBER | member | 306 | PARTSTAT | partstat | 307 | RANGE | range | 308 | RELATED | related | 309 | RELTYPE | reltype | 310 | ROLE | role | 311 | RSVP | rsvp | 312 | SENT-BY | sent-by | 313 | TZID | tzid | 314 | VALUE | value | 315 | X-... | x-... | 316 | ..... | ..... | 317 +----------------+----------------+ 319 2.7 Mapping VCALENDAR object Properties to XML 321 Calendar properties defined in the standard iCalendar format provide 322 information about an iCalendar object, as a whole. The calendar 323 properties are represented in the XML representation as element types 324 as shown in lower case. Here is a list of some iCalendar properties 325 and them mapped to xCal lower case names: 327 +------------------+------------------+ 328 | Calendar | Tag | 329 | Property Name | Name | 330 +------------------+------------------+ 331 | ACTION | action | 332 | ATTACH | attach | 333 | ATTENDEE | attendee | 334 | CALSCALE | calscale | 335 | CATEGORIES | categories | 336 | CLASS | class | 337 | COMMENT | comment | 338 | COMPLETED | completed | 339 | CONTACT | contact | 340 | CREATED | created | 341 | DESCRIPTION | description | 342 | DTEND | dtend | 343 | DTSTART | dtstart | 344 | DTSTAMP | dtstamp | 345 | DUE | due | 346 | DURATION | duration | 347 | EXDATE | exdate | 348 | EXRULE | exrule | 349 | FREEBUSY | freebusy | 350 | GEO | geo | 351 | LAST-MODIFIED | last-modified | 352 | LOCATION | location | 353 | METHOD | method | 354 | ORGANIZER | organizer | 355 | PERCENT-COMPLETE | percent-complete | 356 | PRIORITY | priority | 357 | PRODID | prodid | 358 | RECURRENCE-ID | recrrence-id | 359 | RDATE | rdate | 360 | RELATED-TO | related-to | 361 | REPEAT | repeat | 362 | RESORCES | resources | 363 | RRULE | rrule | 364 | SEQUENCE | sequence | 365 | STATUS | status | 366 | SUMMARY | summary | 367 | TRANSP | transp | 368 | TRIGGER | trigger | 369 | TZID | tzid | 370 | TZNAME | tzname | 371 | TZOFFSETTO | tzoffsetto | 372 | TZOFFSETFROM | tzoffsetfrom | 373 | TZURL | tzurl | 374 | URL | url | 375 | UID | uid | 376 | VERSION | version | 377 | X-... | x-... | 378 | ... | ... | 379 +------------------+------------------+ 381 The semantics for these are as specified for the corresponding 382 calendar property in [iCAL]. 384 In addition to these attributes, the "iCalendar" element type can 385 also have the following attributes: 387 +-----------+-----------+---------+----------------------------+ 388 | Attribute | Attribute | Default | Description | 389 | Name | Type | Value | | 390 +-----------+-----------+---------+----------------------------+ 391 | xmlns | CDATA | FIXED | Used to specify the default| 392 | | | | iCalendar XML name space. | 393 | xmlns: + | CDATA | FIXED | Used to specify the | 394 | | | | | 396 +-----------+-----------+---------+----------------------------+ 398 The semantics of the "xmlns" attribute, and any attribute with 399 "xmlns:" as a prefix, is as specified in [XMLNS]. It is used to 400 declare a namespace in XML. It can be used to declare the xCal XML 401 namespace in a XML document with a document type other than the 402 iCalendar XML document type. The iCalendar XML document type MUST 403 only use element types from the iCalendar namespace. To specify the 404 iCalendar namespace, the attribute value for the "xmlns" and any 405 attribute with the prefix "xmlns:" MUST be: 407 "http://www.ietf.org/rfc/rfcXXXX.txt" 409 NOTE: This attribute value will be replaced with the URL 410 "http://www.ietf.org/rfc/rfcxxxx.txt", where "xxxx" is the RFC 411 number, when this memo is published as a RFC. 413 For example: 415 416 419 421 2.8 Mapping All Components to XML 423 All components in xCal are mapped to their component name without the 424 BEGIN tag. This example show how many component names are mapped to 425 xCal lower case names: 427 +----------------+-------------+------------------------------+ 428 | Component | Element | Example | 429 +----------------+-------------+------------------------------+ 430 | VEVENT | vevent | ... | 431 | VTODO | vtodo | ... | 432 | VJOURNAL | vjournal | ... | 433 | VTIMEZONE | vtimezone | ... | 434 | STANDARD | standard | ... | 435 | DAYLIGHT | daylight | ... | 436 | X-... | x-... | ... | 437 | ... | ... | ... | 438 +----------------+-------------+------------------------------- 440 2.9 Mapping All Values to XML 442 The [iCAL] specification specifies that the equivalent component 443 properties to the "comment", "description", "location", "summary" and 444 "contact" element types can contain formatted content, such as is 445 specified by multiple lines of text. In such cases, the formatted 446 text should be specified in as CDATA Section content. The CDATA 447 section specifies arbitrary character data that is not meant to be 448 interpretted. It is not scanned for markup by the XML parser. The 449 CDATA Section in these element types MUST NOT contain markup or other 450 such alternate representation of the property value. 452 Values MUST NOT be mapped to lower case. iCalendar property values 453 and iCalendar parameter values are used without lower case 454 conversion. 456 Vaues that have characters forbidden by XML MUST be entity encoded. 457 Here are some examples. 459 Values that containe XML tags like in this example: 461 DESCRIPTION:How to map xml DESCRIPTION into 462 an XML element. 464 Would be encoded using standard XML encoding as shown here: 466 How to map xml DESCRIPTION into 467 an XML <description> element. 469 2.10 Namespace 471 [XMLNS] defines "Namespaces in XML" to be a collection of names, 472 identified by a URI, which are used in XML documents as element types 473 and attribute names. The [XML] specification does not include a 474 definition for namespaces, but does set down some guidelines for 475 experimental naming of namespaces. 477 XML namespaces allow multiple markup vocabulary in a single document. 478 Considering the utility of the iCalendar properties in other 479 applications. 481 This memo defines the value that MUST be used in non-iCalendar XML 482 documents that reference element types or attribute lists from the 483 iCalendar namespace. 485 The following is an example of a well-formed but invalid "xdoc" 486 document type that includes elements and attribute lists from the 487 iCalendar namespace: 489 490 491 493 494 496 497 499 2.11 Emailing the iCalendar XML Representation 501 It is expected that iCalendar XML documents will need to be sent over 502 SMTP/MIME email. The "text/xml" and "application/xml" content-types 503 have been registered for XML documents. However, use of these 504 content-type definitions present some problems for XML applications 505 such as calendaring and scheduling. 507 The "text/xml" and "application/xml" content-type definitions do not 508 provide for any header field parameters to identify the type of XML 509 document contained in the MIME entity. This means that a recipient 510 mail user agent must (MUA) open up each "text/xml" or "application/ 511 xml" content in order to determine what object handler is needed to 512 process the information. To a MUA, all XML documents look like just 513 plain "text/xml" or "application/xml" content. 515 Additionally, it is accepted practice for a MUA to provide iconic 516 feedback to the user for individual content-types that are supported 517 by the MUA. For example, not only would feedback be provided for a 518 calendaring and scheduling content. Some further unique 519 identification would also be provided for each different scheduling 520 message; such as a meeting invitation, response to an invitation, 521 reschedule notice, cancellation notice, etc. In such cases, 522 acceptable performance by the MUA is dependent on the existence of 523 header field information, such as it provided in the definition of 524 the "text/calendar" content-type by [iCAL]. 526 Internet application conforming to this memo MUST identify iCalendar 527 XML documents with the experimental content-type "application/ 528 calendar+xml". The content-type header field SHOULD also contain a 529 "component" and "method" parameter to clearly identify a comma- 530 separated list of components and the singular method used in the 531 iCalendar XML document. For example, an iCalendar XML document 532 specifying a REQUEST for a VEVENT would be specified with the 533 following content-type header field: 535 content-type:application/calendar+xml;method=REQUEST;component=VEVENT 537 The content-type can also include the "optinfo" parameter to specify 538 any other optional iCalendar information. The semantics of these 539 content-type parameters is as defined in [iCAL]. 541 Internet applications conforming to this memo MUST only send the 542 iCalendar XML document in a "multipart/alternative" MIME entity that 543 also contains an equivalent iCalendar object in the standard format 544 defined by [iCAL]. This restrict will guarantee that the iCalendar 545 object can also be processed by internet applications that only 546 support the standard iCalendar format. 548 An XML application supporting the iCalendar XML document type MUST be 549 able to receive and properly process the "application/calendar+xml" 550 document contained within a "multipart" message content-type. 552 2.12 iCalendar XML Representation and File Systems 554 The iCalendar XML documents will be stored in file systems. The 555 accepted practice for file extensions for XML documents is the text 556 "XML". However, in order to uniquely identify iCalendar XML 557 documents for file association with applications that can directly 558 process this document type, it is RECOMMENDED that the file extension 559 be the text "XCS". 561 3. Example Usage 563 The following sections provide various examples of iCalendar XML 564 documents. 566 3.1 A well-formed and valid iCalendar XML document 568 The following is a simple example of a iCalendar XML document. This 569 document is both a well-formed and valid XML document. The iCalendar 570 object specifies an appointment. 572 573 574 575 PUBLISH 576 2.0 577 -//HandGen//NONSGML vGen v1.0//EN 578 579 19981116T150000@cal10.host.com 580 19981116T145958Z 581 Project XYZ Review 582 Conference Room 23A 583 19981116T163000Z 584 19981116T190000Z 585 1998-ABC Corp-1234 586 Appointment,Work 587 588 589 591 3.2 Including binary content in attachments 593 The following is an example of a valid iCalendar XML document that 594 also includes an external reference to an attachment. The iCalendar 595 object specifies a meeting invitation with an attachment. 597 598 602 603 REQUEST 604 2.0 605 -//HandGen//NONSGML vGen v1.0//EN 606 607 19981211T133000@cal1.host.com 608 19981211T132928Z 609 cap://host.com/jim 610 19981212T150000Z 611 19981212T160000Z 612 Department Meeting 613 Conference Room 23A 614 jim@host.com 615 MAILTO:joe@host.com 617 MAILTO:steve@host.com 619 http://host.com/pub/photos/holiday.jpg 620 621 622 624 The following is an example of a well-formed and valid iCalendar XML 625 document that includes an attachment as inline binary content. The 626 iCalendar object specifies a meeting invitation with an attachment. 628 629 632 633 634 REQUEST 635 2.0 636 -//HandGen//NONSGML vGen v1.0//EN 637 638 19981211T133000@cal1.host.com 639 19981211T132928Z 640 MAILTO:jim@host.com 641 19981212T150000Z 642 19981212T160000Z 643 Department Meeting 644 Conference Room 23A 645 MAILTO:jim@host.com 646 MAILTO:joe@host.com 648 MAILTO:steve@host.com 650 MIICajCCAdOgAwIBAgI 651 CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB 652 lIEjYXRpb25z...and so on...IENvcnBvc== 653 654 655 657 3.3 iCalendar XML document with multiple iCalendar objects 659 The following is an example of a well-formed and valid iCalendar XML 660 document that includes more than one iCalendar object. 662 663 666 667 668 PUBLISH 669 2.0 670 -//HandGen//NONSGML vGen v1.0//EN 671 672 673 2.0 674 -//HandGen//NONSGML vGen v1.0//EN 675 PUBLISH 676 677 19981009T233010@cal1.host.com 678 19981009T233000Z 679 19981120T133000Z 680 19981122T183000Z 681 IT Conference 682 Downtowner Hotel 683 684 685 687 3.4 Using the iCalendar namespace 689 The following is an example of a snippet of a XML document that 690 includes elements from the iCalendar name-space. 692 694 19981123T133000Z 695 19981123T203000Z 696 1234567 697 999.99 698 700 3.5 Publish meeting information 702 The following is a snippet of an iCalendar XML document that 703 publishes information about a meeting. 705 706 707 2.0 708 -//hacksw/handcal//NONSGML 1.0//EN 709 PUBLISH 710 711 19970901T130000Z-123401@host.com 712 19970901T130000Z 713 19970903T163000Z 714 19970903T190000Z 715 Annual Employee Review 716 PRIVATE 717 Business,Human Resources 718 719 720 722 3.6 Publish transparent annual event 724 The following is a snippet of an iCalendar XML document that 725 publishes information about an annually repeating event that is 726 transparent to busy time searches. 728 729 730 2.0 731 732 PUBLISH 733 734 19990101T125957Z-123403@host.com 735 19990101T130000Z 736 19991102 737 Our Blissful Anniversary 738 CONFIDENTIAL 739 TRANSPARENT 740 Anniversary,Personal,Special Occasion 741 FREQ=YEARLY 742 743 744 746 3.7 Meeting invitation 748 The following is a snippet of an iCalendar XML document that 749 specifies an invitation for a meeting. The meeting occurs on the 750 first Monday of each year for five years. 752 753 754 REQUEST 755 2.0 756 -//hacksw/handcal//NONSGML 1.0//EN 757 758 19981220T130000Z-123403@host.com 759 19981220T130050Z 760 MAILTO:corprel@host.com 761 19990104T140000Z 762 19990104T220000Z 763 Annual Stockholders Meeting 764 One Corporate Drive, Wilmington, DL 765 MAILTO:mrbig@host.com 766 CAP:host.com/stockholders 768 Business,Meeting,Special Occasion 769 FREQ=YEARLY;COUNT=5;BYDAY=1MO 770 771 772 774 3.8 Publish busy time 776 The following is an iCalendar XML document that publishes busy time 777 information. The default value for the "method" attribute is 778 "PUBLISH" and does not need to be specified in this example. 780 781 782 2.0 783 -//hacksw/handcal//NONSGML 1.0//EN 784 785 19980313T133000@ical1.host.com 786 19990104T133010Z 787 CAP:host.com/jsmith 788 19980313T141711Z 789 19980410T141711Z 790 jsmith.ifb 791 19980314T233000Z/19980315T003000Z 792 19980316T153000Z/19980316T163000Z 793 19980318T030000Z/19980318T040000Z 794 795 796 798 3.9 Request busy time 800 The following is a snippet of an iCalendar XML document that requests 801 a calendar user's busy time information. 803 804 805 REQUEST 806 2.0 807 -//hacksw/handcal//NONSGML 1.0//EN 808 809 19970901T083000@ical1.host.com 810 19970901T083000Z 811 MAILTO:jane_doe@host1.com 812 19971015T050000Z 813 19971016T050000Z 814 MAILTO:john_public@host2.com 815 816 817 819 3.10 Issue a CAP command 821 The following is a snippet of an iCalendar XML document that issues a 822 CAP command to delete a UID. 824 825 826 2.0 827 -//hacksw/handcal//NONSGML 1.0//EN 828 relcalid-22 829 DELETE 830 831 SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345' 832 833 834 836 4. Acknowledgments 838 The following have participated in the drafting and discussion of 839 this memo: 841 Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert, 842 Thomas Rowe. 844 5. IANA Considerations 846 TODO - registration if application/calendar+xml 848 6. Security Considerations 850 CDATA Sections - - A XML iCalendar document may contain CDATA 851 sections to represent content for specific element types. The CDATA 852 section specifies arbitrary character data that is not meant to be 853 interpretted. It is not scanned by the XML parser for markup. While 854 this memo restricts that any CDATA section MUST NOT contain markup or 855 other such alternate representation for the property value, in 856 general, CDATA section from a non-conformant implementation can 857 contain content such as HTML markup. HTML text can be used to invoke 858 programs. Implementors should be aware that this may leave an 859 implementation open to malicious attack that might occur as a result 860 of executing the markup in the CDATA section. 862 PROCEDURAL ALARMS - - A XML iCalendar document can be created that 863 contains a "VEVENT" calendar component with "VALARM" calendar 864 components. The "VALARM" calendar component can be of type PROCEDURE 865 and can have an attachment containing some sort of executable 866 program. Implementations that incorporate these types of alarms are 867 subject to any virus or malicious attack that might occur as a result 868 of executing the attachment. 870 ATTACHMENTS - - A XML iCalendar document can include references to 871 Uniform Resource Locators that can be programmed resources. 872 Implementers and users of this memo should be aware of the network 873 security implications of accepting and parsing such information. 875 In addition, the security considerations observed by implementations 876 of electronic mail systems should be followed for this memo. 878 7. Bibliography 880 [BASIC] D. Royer, "Basic Internet Calendaring and Scheduling Core 881 Object Specification", Internet Draft, http://www.internic.net/ 882 internet-drafts/draft-royer-ical-basic-03.txt, June 2005. 884 [ISO9070] "Information Technology_SGML Support Facilities_ 885 Registration Procedures for Public Text Owner Identifiers", ISO/IEC 886 9070, Second Edition, International Organization for Standardization, 887 April 1991. 889 [MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail 890 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 891 2045, November 1996. 893 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 894 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt, 895 March 1997. 897 [iCAL] F. Dawson and D. Stenerson, "Internet Calendaring and 898 Scheduling Core Object Specification (iCalendar)", RFC 2445, 899 http://www.ietf.org/rfc/rfc2445.txt, November 1998. 901 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 902 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 904 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, 905 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. 907 Author's Address 909 Doug Royer 910 IntelliCal LLC 911 267 Kentlands Blvd., #3041 912 Gaithersburg, MD 20878 913 US 915 Phone: (208)881-0380 916 Email: doug@royer.com 918 Intellectual Property Statement 920 The IETF takes no position regarding the validity or scope of any 921 Intellectual Property Rights or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; nor does it represent that it has 925 made any independent effort to identify any such rights. Information 926 on the procedures with respect to rights in RFC documents can be 927 found in BCP 78 and BCP 79. 929 Copies of IPR disclosures made to the IETF Secretariat and any 930 assurances of licenses to be made available, or the result of an 931 attempt made to obtain a general license or permission for the use of 932 such proprietary rights by implementers or users of this 933 specification can be obtained from the IETF on-line IPR repository at 934 http://www.ietf.org/ipr. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights that may cover technology that may be required to implement 939 this standard. Please address the information to the IETF at 940 ietf-ipr@ietf.org. 942 Disclaimer of Validity 944 This document and the information contained herein are provided on an 945 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 946 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 947 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 948 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 949 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 950 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 952 Copyright Statement 954 Copyright (C) The Internet Society (2005). This document is subject 955 to the rights, licenses and restrictions contained in BCP 78, and 956 except as set forth therein, the authors retain all their rights. 958 Acknowledgment 960 Funding for the RFC Editor function is currently provided by the 961 Internet Society.