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.