idnits 2.17.1
draft-reddy-scap-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-23) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack an Authors' Addresses Section.
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 180 instances of too long lines in the document, the longest
one being 12 characters in excess of 72.
== There are 8 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 36 has weird spacing: '...ntially and e...'
== Line 613 has weird spacing: '...Objects from ...'
== Line 963 has weird spacing: '...he base offse...'
== Line 1002 has weird spacing: '... and time)...'
== Line 1003 has weird spacing: '...nd time for E...'
== (2 more instances...)
== The document seems to lack 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?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
New Calendar Objects added to a Calendar store with the MKCSOBJ
command MUST contain all required iCalendar properties specified in well
formed XML request body. If a required property is missing the server
MUST return a response and MUST not modify any of the specified Calendar
stores.
-- 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 27, 1998) is 9310 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: 'XML' is mentioned on line 690, but not defined
== Missing Reference: 'RFC 822' is mentioned on line 1637, but not defined
** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822)
== Missing Reference: '3' is mentioned on line 1817, but not defined
== Missing Reference: '4' is mentioned on line 1817, but not defined
== Unused Reference: 'CSCOS' is defined on line 2033, but no explicit
reference was found in the text
== Unused Reference: 'Alvestrand' is defined on line 2040, but no explicit
reference was found in the text
== Unused Reference: '1995' is defined on line 2037, but no explicit
reference was found in the text
== Unused Reference: 'ISO-639' is defined on line 2063, but no explicit
reference was found in the text
== Unused Reference: 'ISO-8601' is defined on line 2066, but no explicit
reference was found in the text
== Unused Reference: 'Leach' is defined on line 2070, but no explicit
reference was found in the text
== Unused Reference: 'Salz' is defined on line 2070, but no explicit
reference was found in the text
== Unused Reference: 'Yergeau' is defined on line 2074, but no explicit
reference was found in the text
== Unused Reference: '1996' is defined on line 2077, but no explicit
reference was found in the text
== Unused Reference: 'Hollander' is defined on line 2080, but no explicit
reference was found in the text
== Unused Reference: 'Layman' is defined on line 2080, but no explicit
reference was found in the text
== Outdated reference: A later version (-11) exists of
draft-ietf-calsch-ical-00
** Obsolete normative reference: RFC 1766 (ref. '1995') (Obsoleted by RFC
3066, RFC 3282)
-- Possible downref: Non-RFC (?) normative reference: ref. '1998'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Bray'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Paoli'
-- Possible downref: Non-RFC (?) normative reference: ref.
'Sperberg-McQueen'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-639'
-- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8601'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Leach'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Salz'
** Obsolete normative reference: RFC 2279 (ref. 'Yergeau') (Obsoleted by
RFC 3629)
-- Duplicate reference: RFC2026, mentioned in '1996', was also mentioned in
'Bradner'.
-- Possible downref: Non-RFC (?) normative reference: ref. 'Hollander'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Layman'
Summary: 13 errors (**), 0 flaws (~~), 26 warnings (==), 13 comments
(--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 CALSCH Working Group Surendra Reddy
3 Internet Draft Oracle Corporation
4 draft-reddy-scap-00.txt April 27, 1998
5 Expires October 27, 1998
7 Web based Simple Calendar Access Protocol - SCAP
9 Status of this Memo
11 This document is an Internet-Draft. Internet-Drafts are working docu-
12 ments of the Internet Engineering Task Force (IETF), its areas, and
13 its working groups. Note that other groups may also distribute work-
14 ing documents as Internet-Drafts.
16 Internet-Drafts are draft documents valid for a maximum of six months
17 and may be updated, replaced, or made obsolete by other documents at
18 any time. It is inappropriate to use Internet-Drafts as reference
19 material or to cite them other than as "work in progress".
21 To view the entire list of current Internet-Drafts, please check the
22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
27 Distribution of this document is unlimited. Please send comments to
28 the CALSCH working group at ietf-calendar@imc.org, which may be
29 joined by sending a message with subject "subscribe" to ietf-
30 calendar-request@imc.org.
32 Abstract
34 Distributed calendaring is gradually becoming more demanding than
35 standalone calendaring and scheduling. The use of calendaring and
36 scheduling has grown exponentially and enterprise and inter-
37 enterprise business has become so dependent on group scheudling
38 applications. But there is no Internet standard to provide
39 interoperability among various calendaring applications.
40 Consequently, user need to install different conduit programs to
41 access these calendaring stores. This memo proposes a HTTP based
42 simple calendaring access protocol which allows web, email and any
43 HTTP compliant clients to access and manipulate calendar store.
45 The motivation for this proposal is the expanded scope and diversity
46 of the World Wide Web. The World Wide Web provides a simple and
47 effective means for users to search, browse, retrieve, and publish
48 information of their own available for others. Now that Web browsers
49 and servers are ubiquitous on the Internet, it is worthwhile to use
50 HTTP as transport protocol and XML to encode calendar objects. The
51 power and extensibility of XML allows us to represent calendar data
52 objects as well-formed XML documents.
54 Simple Calendar Access Protocol(SCAP) allows exchanging calendaring
55 information between scheduling systems using the Hypertext Transfer
56 Protocol (HTTP). This allows users to schedule meetings with anyone
57 else, no matter what scheduling software they use.
59 This document specifies a set of methods, headers, and content-types
60 ancillary to HTTP/1.1 for the management of calender properties,
61 creation and management of calendar objects, and namespace
62 manipulation.
64 Table of Contents
66 i. Status of this Memo .......................................... 1
67 ii. Abstract .................................................... 1
68 1. Introduction ................................................ 4
69 2. Notational Conventions ...................................... 4
70 3. Calendar Object Model ....................................... 5
71 3.1 The Calendar Property Model ............................. 5
72 3.2 Property Values ......................................... 5
73 3.3 Property Names .......................................... 5
74 3.4 Calendar Names and User Names ........................... 5
75 4. HTTP Methods of Calendar Access ............................. 5
76 4.1 CSOP Method ............................................. 6
77 4.1.1 Create Calendar Store ............................. 6
78 4.1.2 Example: Create Calendar Store .................... 6
79 4.1.3 Example - Select Calendar Store ................... 7
80 4.1.4 Delete Calendar Store ............................. 8
81 4.1.5 Example: Delete Calendar Store .................... 8
82 4.1.6 Copy and Move Calendar Stores ..................... 9
83 4.1.7 Example: Rename Calendar Store .................... 9
84 4.1.8 List Calendar Store ............................... 10
85 4.1.9 Examples: List Calendar Store ..................... 10
86 4.1.10 Set Calendar View by Range ....................... 11
87 4.1.11 Example: Calendar View by Range .................. 11
88 4.2 MKCSOBJ ................................................. 12
89 4.2.1 Examples: ........................................ 12
90 4.3 CSPROP Method ........................................... 13
91 4.3.1 Example:Get Freebusy time ......................... 14
92 5. Calendar XML Element Definitions ............................ 15
93 5.1 Calendar Message ........................................ 15
94 5.2 vevent XML element ...................................... 16
95 5.2.1 Example: vevent ................................... 16
96 5.3 vtodo XML element ....................................... 17
97 5.3.1 Example: vtodo .................................... 18
98 5.4 vjournal XML element ................................... 18
99 5.4.1 Example: vjournal ................................ 19
100 5.5 vfreebusy XML element ................................... 19
101 5.5.1 Example: vfreebusy ................................ 20
102 5.5 vtimezone XML element ................................... 21
103 5.6.1 Example: vtimezone ................................ 22
104 5.6 valarm XML element ...................................... 23
105 5.6.1 Example: valarm ................................... 24
106 6. Calendar Properties ......................................... 25
107 6.1 attach Property ......................................... 25
108 6.2 categories Property ..................................... 26
109 6.3 class Property .......................................... 26
110 6.4 comment Property ........................................ 26
111 6.5 description Property .................................... 27
112 6.6 location Property ....................................... 27
113 6.7 percentcomplete Property ................................ 27
114 6.8 priority Property ....................................... 28
115 6.9 resources Property ...................................... 28
116 6.10 status Property ........................................ 28
117 6.11 summary Property ....................................... 29
118 6.12 completed property ..................................... 29
119 6.13 dtend Property ......................................... 29
120 6.14 due Property ........................................... 30
121 6.15 dtstart Property ....................................... 30
122 6.16 duration Property ...................................... 31
123 6.17 freebusy Property ...................................... 31
124 6.18 attendee Property ...................................... 32
125 6.19 contact Property ....................................... 33
126 6.20 organizer Property ..................................... 33
127 6.21 recurid Property ....................................... 34
128 6.22 relatedto Property ..................................... 35
129 6.23 url property ........................................... 35
130 6.24 uid Property ........................................... 35
131 6.25 exdate Property ........................................ 36
132 6.26 exrule Property ........................................ 36
133 6.27 rdate Property ......................................... 36
134 6.28 rrule Property ......................................... 37
135 6.29 trigger Property ....................................... 37
136 6.30 created Property ....................................... 38
137 6.31 dtstamp Property ....................................... 38
138 6.32 lastmodified Property .................................. 38
139 6.33 sequence Property ...................................... 39
140 6.34 requeststatus Property ................................. 39
141 7. Security Considerations ..................................... 40
142 8. Calendar Object Specification - XML DTD ..................... 40
143 8. References .................................................. 44
144 9. Author's Address ............................................ 45
146 1. Introduction
148 This document describes an extension to the HTTP/1.1 protocol that
149 allows clients to perform remote calendaring operations. This
150 extension provides a coherent set of methods, headers, request
151 entity body formats, and response entity body formats that provide
152 operations for:
154 Properties: The ability to create, remove, and query information
155 about Calendar resources, such as their freetime, todo etc.
157 Namespace Operations: The ability to instruct the server to copy and
158 move calendar objects.
160 SCAP, encodes method parameter information either in an Extensible
161 Markup Language (XML) [Bray, Paoli, Sperberg-McQueen, 1998] request
162 entity body, or in an HTTP header. The use of XML to encode method
163 parameters was motivated by the ability to add extra XML elements to
164 existing structures, providing extensibility, and by XML's ability
165 to encode information in ISO 10646 character sets, providing
166 internationalization support. As a rule of thumb, parameters are
167 encoded in XML entity bodies when they have unbounded length, or
168 when they may be shown to a human user and hence require encoding in
169 an ISO 10646 character set. Otherwise, parameters are encoded
170 within HTTP headers.
172 In addition to encoding method parameters, XML is used in SCAP to
173 encode the responses from methods, providing the extensibility and
174 internationalization advantages of XML for method output, as well as
175 input.
177 2. Notational Conventions
178 Since this document describes a set of extensions to the HTTP/1.1
179 protocol, the augmented BNF used herein to describe protocol
180 elements is exactly the same as described in section 2.1 of
181 [Fielding et al., 1997]. Since this augmented BNF uses the basic
182 production rules provided in section 2.2 of [Fielding et al., 1997],
183 these rules apply to this document as well.
185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
186 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
187 document are to be interpreted as described in RFC 2119 [Bradner,
188 1997].
190 3. Calendar Object Model
192 3.1. The Calendar Property Model
193 Properties are pieces of data that describe the state of Calendar
194 objects. Properties are data about data. [Refer iCalendar]
196 The SCAP property model consists of name/value pairs. The name of a
197 property identifies the property's syntax and semantics, and
198 provides an address by which to refer to its syntax and semantics.
200 3.2. Property Values
201 The value of a property is, at minimum, well formed XML.
203 XML has been chosen because it is a flexible, self-describing,
204 structured data format that supports rich schema definitions, and
205 because of its support for multiple character sets. XML's self-
206 describing nature allows any property's value to be extended by
207 adding new elements. Older clients will not break when they
208 encounter extensions because they will still have the data specified
209 in the original schema and will ignore elements they do not
210 understand. XML's support for multiple character sets allows any
211 human-readable property to be encoded and read in a character set
212 familiar to the user.
214 3.3. Property Names
215 A property name is a universally unique identifier that is
216 associated with a schema that provides information about the syntax
217 and semantics of the property.
219 Because a property's name is universally unique, clients can depend
220 upon consistent behavior for a particular property across multiple
221 resources, so long as that property is "live" on the resources in
222 question.
224 The XML namespace mechanism, which is based on URIs, is used to name
225 properties because it prevents namespace collisions and provides for
226 varying degrees of administrative control.
228 3.4. Calendar Names and User Names
229 The name parameter can be the name of a Calendar and optionally a
230 user name.
232 4. HTTP Methods of Calendar Access
233 The following new HTTP methods use XML as a request and response
234 format. All SCAP compliant clients and resources MUST use XML
235 parsers that are complaint with [Bray, Paoli, Sperberg-McQueen,
236 1998]. All XML used in either requests or responses MUST be, at
237 minimum, well formed. If a server receives ill-formed XML in a
238 request it MUST reject the entire request with a 400 Bad Request.
239 If a client receives ill-formed XML in response then it SHOULD treat
240 the server as malfunctioning.
242 4.1. CSOP Method
243 The Calendar Store Operation(CSOP) method processes instructions
244 specified in the request body. All SCAP compliant servers MUST
245 support CSOP and MUST process instructions that are specified using
246 csoperation XML element of SCAP schema. The request message body of
247 a CSOP MUST contain at least one csoperation XML element.
249 A client MUST submit csoperation XML element in the body of the
250 request method decribing what action is being requested on the
251 Request-URI. All SCAP complaiance servers MUST support returing a
252 response of content type text/xml that contains a multistatus XML
253 element that describes the results of the attempts to perform the
254 various actions.
256 If any requested operation is resulted in an error then the error
257 result MUST be included in the response XML element.
259 4.1.1. Create Calendar Store
260 Creates a new Calendar store with the given name. Calendar store
261 names must begin with an alphabetic character and consist of
262 alphanumeric characters. Calendar names are not case sensitive. It
263 is illegal to create more than one Calendar store with the same
264 name. "create" does not automatically select the Calendar store
265 created.
267 SCAP servers are NOT required to support hierarchical names. If a
268 client attempts to create a Calendar Store with a hierarchical name
269 on a server which does not support hierarchical names, the server
270 MUST return an error response of to the "create" action request.
272 If the Calendar name is suffixed with the hierarchy separator "/",
273 this is a declaration that the client intends to create Calendar
274 names under this name in the hierarchy. Server implementations that
275 do not require this declaration MUST ignore it.
277 4.1.2. Example: Create Calendar Store
278 >>Request
280 CSOP HTTP/1.1
281 HOST: www.foo.com
282 Content-Type: text/xml
283 Content-Length: xxxx
285
286
287
288 Projects/
289 Projects
290
292 >>Response
294 HTTP/1.1 207 MULTI-STATUS
295 Content-Type: text/xml
296 Content-Length: xxxx
298
299
300
302
303 HTTP/1.1 415 Unsupported
304
305
306 HTTP/1.1 201 OK
307
309
310 The above example creates two Calendar stores for the default user. First
311 operation failed as creating hierarchical Calendar store is not supported,
312 hence server responded with a response code 415.
314 4.2. Example - Select Calendar Store
315 >>Request
317 CSOP HTTP/1.1
318 HOST: www.foo.com
319 Content-Type: text/xml
320 Content-Length: xxxx
322
323
324
325
326
327
330 >>Response
332 HTTP/1.1 207 Multi-Status
333 Content-Type: text/xml
334 Content-Length: xxxx
336
337
338
339
340 HTTP/1.1 424 Method Failure
341
342
343 HTTP/1.1 424 Method Failure
344
345
347 This sequence uses multiple SELECT commands to open the current
348 user's default Calendar store plus the default Calendar stores of Bob
349 and Sally.
351 4.3. Delete Calendar Store
352 Deletes the Calendar store with the given name. If this command is
353 given from the Selected state, a currently selected Calendar cannot
354 be deleted.
356 4.3.1. Example: Delete Calendar Store
357 >>Request
359 CSOP HTTP/1.1
360 HOST: www.foo.com
361 Content-Type: text/xml
362 Content-Length: xxxx
364
365
366
367 Projects
368 Purple/
369
371 >>Response
373 HTTP/1.1 207 MULTI-STATUS
374 Content-Type: text/xml
375 Content-Length: xxxx
376
377
378
380
381 HTTP/1.1 2O1 OK
382
383
384 HTTP/1.1 415 Unsupported
385
387
389 4.4. Copy and Move Calendar Stores
390 "copy" action transfer a given set of Objects to a different
391 Calendar store.
393 The "rename" action changes the name of a Calendar store. It is an
394 error to attempt to rename from a Calendar name that does not exist
395 or to a Calendar name that already exists and it MUST be responded
396 to the client.
398 If the hierarchy separator character appears in the new Calendar
399 store name, the server SHOULD return an error response to the
400 client. No actions MUST be performed on the Calendar Store.
402 The Calendar store to "rename" or "copy" to MUST exist before the
403 operation is initiated.
405 4.4.1. Example: Rename Calendar Store
406 >>Request
408 CSOP HTTP/1.1
409 HOST: www.foo.com
410 Content-Type: text/xml
411 Content-Length: xxxx
413
414
415
416
417
418
420 >>Response
421 HTTP/1.1 207 MULTI-STATUS
422 Content-Type: text/xml
423 Content-Length: xxxx
425
426
427
429
430 HTTP/1.1 2O1 OK
431
432
433 HTTP/1.1 415 Unsupported
434
436
438 4.5. List Calendar Store
439 The "list" action returns listresp XML for each Calendar store that
440 matches the given reference and store name. The "*" character is a
441 wildcard and can be used to matche any length string of valid
442 Calendar Store name characters.
444 The SCAP complaince servers must hide all Calendar stores that the
445 current user does not have access to.
447 These reference names should be interpreted in the following manner:
449 allstores XML element - lists all top level Calendar stores
450 accessible
451 to the current user. allusers XML element - list all
452 users accessible by the server curuser XML element - lists the
453 currently authenticated user
455 4.5.1. Examples: List Calendar Store
456 >>Request
458 CSOP HTTP/1.1
459 HOST: www.foo.com
460 Content-Type: text/xml
461 Content-Length: xxxx
463
464
465
466
467
469 >>Response
471 HTTP/1.1 207 Multi-Status
472 Content-Type: text/xml
473 Content-Length: xxxx
475
476
477
478 skreddy
479 oracle
480 nobody
481
483 4.6. Set Calendar View by Range
485 The "range" action sets a date/time range for the currently selected
486 Calendars and returns a response with the number of items in the
487 range.
489 Either the start time(dtstart) or end time(dtend) can be replaced
490 with the wildcard character "*" in which case lower or upper bound,
491 respectively, is placed on the current date range.
493 The start time given must be included in the range. The end time
494 given must be excluded from the range.
496 If any Object in the selected Calendar store contains a set of
497 recurrence rules that resolve to dates within the specified date
498 range, then that Object MUST appear once for each date resolved
499 within the specified range. In other words, an Object may count for
500 more than one Object in the response returned by the "range" action
501 if it is a recurring Object.
503 4.6.1. Example:
504 >>Request
506 CSOP HTTP/1.1
507 HOST: www.foo.com
508 Content-Type: text/xml
509 Content-Length: xxxx
511
512
513
514
515 19971230T0900-0500
516 19971230T1700-0500
517
519 >>Response
521 HTTP/1.1 207 Multi-Status
522 Content-Type: text/xml
523 Content-Length: xxxx
525
526
527
528 9
529
531 4.7. MKCSOBJ
533 The MKCSOBJ method creates a new Calendar Object in the Calendar
534 Store identified by the Request-URI. If the Calendar Store
535 identified by the Request-URI does not exist, the server must return
536 an error response with status codei 424.
538 New Calendar Objects added to a Calendar store with the MKCSOBJ
539 command MUST contain all required iCalendar properties specified in
540 well formed XML request body. If a required property is missing the
541 server MUST return a response and MUST not modify any of the
542 specified Calendar stores.
544 If a Calendar Object has been created on the Request-URI Calendar
545 Store, the response SHOULD be 201(Created) and contain a response
546 XML element which describes the status of the request.
548 4.7.1. Examples:
549 >>Request
551 MKCSOBJ Personal_Calendar HTTP/1.1
552 HOST: www.foo.com
553 Content-Type: text/xml
554 Content-Length: xxxx
556
557
558
559 19970606T140000-0800
560 19970606T150000-0800
561 Meeting with Pete.
562
563 >>Response
565 HTTP/1.1 207 MULTI-STATUS
566 Content-Type: text/xml
567 Content-Length: xxxx
569
570
571 HTTP/1.1 2O1 OK
573
575 4.8. CSPROP Method
577 The CSPROP method returns information requested by the csprop XML
578 element as a request body on the Calendar Store specified by the
579 Request-URI.
581 The CSPROP method currently supports the XML request bodies to
582 retrive the various Calendar Store properties.
584 getcsid The unique identifier of this Calendar store.
585 getcomponents An iCalendar object
586 gettimezone An iCalendar object containing a TIMEZONE Component
587 getfreebusy Get freebusy time for the specified "resource"
588 fetch Fecthes the specifies properites from the Calendar
589 Store
590 store Update the Calendar Objects specfied by the vcalendar
591 XML request body in the calendar store specified by
592 the Request-URI.
593 search Searches the Calendar store for given properties.
595 The "getcomponents" XML element can be used by a client to determine
596 which Calendar Components that can be stored within a Calendar
597 Store, along with the names and types of the properties of those
598 Calendar Components. The server MUST return an iCalendar object
599 which contains a "model" of all the Components the Calendar Store
600 supports. The "model" Components MUST contain all of the properties
601 that the Component can store. The Properties should specify a VALUE
602 property parameter that identifies the data-type of the property. The
603 property value MUST be an null string.
605 The server does not have to return a TIMEZONE Component to
606 indicate that this Component is supported. The server MUST return an
607 ALARM Component if this Component is supported.
609 The "getfreebusy" action searches the currently selected Calendars,
610 bounded by a start and end time, and returns a list of intervals during
611 which an event of the given length of time can be scheduled.
613 The "fetch" action fetches all the specified calendar Objects from the
614 Calendar store specified by the Request-URI.
616 Note that items returned by "fetch" action should always be returned in
617 ascending chronological order, even when multiple Calendar stores are
618 selected.
620 The "store" action updates the iCalendar data associated with this
621 Calendar Object. The request body must contain well formed vcalendar
622 XML elements and Calendar Store must be specified by Request-URI.
624 If there is more than one Calendar store selected in the given
625 selected object, then the "store" action will add the new Object to
626 all of the Calendar stores.
628 New Calendar Objects added to a Calendar store must contain all
629 required iCalendar properties. Updates to existing Calendar Objects
630 need only contain the actual data to be updated. Duplicate attributes
631 names are not allowed, whenever a value is given for a attribute name
632 that already exists, the new value replaces the old value.
634 The "search" action searches the Calendar store for Objects that
635 match the given searching criteria. Searching criteria consist of one or
636 more search keys. The untagged SEARCH response from the server
637 contains a listing of Object numbers corresponding to those Objects
638 that match the searching criteria.
640 When multiple keys are specified, the result is the intersection (AND
641 function) of all the messages that match those keys. A search key can
642 also be a parenthesized list of one or more search keys (e.g. for use
643 with the OR and NO keys).
645 4.8.0.1. Example:Get Freebusy time
646 >>Request
648 CSPROP / HTTP/1.1
649 HOST: www.foo.com
650 Content-Type: text/xml
651 Content-Length: xxxx
653
654
655
656 Ann
657 Bob
658 19970930T0900-0700
659 19970930T1700-0700
660
662 >>Response
664 HTTP/1.1 200 OK
665 Content-Type: text/xml
666 Content-Length: xxxx
668
669
670
671
672 Ann
673 19970930T0900-0700
674 19970930T1700-0700
675
676 19970930T1000-0700/PT1H
677
678
679 19970930T1200-0700/PT1H
680
681
682
683 In the example above, only two busy periods were found for the given
684 time range: Ann is busy from 10 to 11 on 19970903 and also busy from
685 12 to 1 o'clock on the same day.
687 5. Calendar XML Element Definitions
689 5.1. Calendar Message
690 Calendar messages are [XML] documents which are sent between SCAP
691 client and server. the XML definition of a Calendar message is as
692 follows:
693
698
702 5.2. vevent XML element
703 Name: vevent
705 Purpose: Provide a grouping of component properties that describe an
706 event.
708 Description: A vevent XML element is a grouping of component
709 properties and an OPTIONAL "valarm" XML element that represent
710 a scheduled amount of time on a calendar.
712
721 The "vevent" calendar component MUST include the "dtstamp", "dtstart", "summary"
722 And "uid" properties.`In addition, it MUST include the "sequence" property, if
723 It's value is greater than zero.
725 5.2.1. Example
726 The following is an example of the "vevent" calendar component used
727 to represent a meeting that will also be opaque to searches for busy
728 time:
729
730 19970901T130000Z-123401@host.com
731 19970901T1300Z
732 19970903T163000Z
733 19970903T190000Z
734 Annual Employee ReviewPRIVATE
736
737 HUMAN RESOURCES
738
739 The following is an example of the "vevent" calendar component used
740 to represent a reminder that will not be opaque, but rather
741 transparent, to searches for busy time:
742
743 19970901T130000Z-123402@host.com
744 19970901T1300Z
745 19970401T163000Z
746 19970402T010000Z
747 Laurel is in sensitivity awareness class.
748 PUBLIC
749 BUSINESS
750 HUMAN RESOURCES
751 transpARENT
752
753 The following is an example of the "vevent" calendar component used
754 to represent an anniversary that will occur annually. Since it takes
755 up no time, it will not appear as opaque in a search for busy time;
756 no matter what the value of the "transp" property indicates:
757
758 19970901T130000Z-123403@host.com
759 19970901T1300Z
760 19971102
761 Our Blissful Anniversary
762 CONFIDENTIAL
763 ANNIVERSARY
764 PERSONAL
765 SPECIAL OCCASION
766
767
769 5.3. vtodo XML element
770 Name: vtodo
772 Purpose: Provide a grouping of calendar properties that describe a
773 to-do.
775 Description: A "vtodo" calendar component is a grouping of component
776 properties and an OPTIONAL "valarm" calendar component that
777 represent an action-item or assignment.
779
787 The "vtodo" calendar component MUST include the "dtstamp", "priority",
788 "summary" and "uid" properties. In addition, it MUST include the "sequence"
789 property, if it's value is greater than zero.
791 A "vtodo" calendar component without the "dtstart" and "due" (or
792 "duration") properties specifies a to-do that is associated with each
793 successive calendar dates, until it is completed.
795 5.3.1. Example: vtodo
796 The following is an example of a "vtodo" calendar component:
797
798 19970901T130000Z-123404@host.com
799 19970901T1300Z
800 19970415T133000Z
801 19970416T045959Z
802 1996 Income Tax Preparation
803 CONFIDENTIAL
804 FAMILY
805 FINANCE
806 1
807 NEEDS-ACTION
810 5.4. vjournal XML element
811 Name: vjournal
813 Purpose: Provide a grouping of component properties that describe a
814 journal entry.
816 Description: A "vjournal" calendar component is a grouping of
817 component properties that represent one or more descriptive text
818 notes on a particular calendar date. The "dtstart" property is used
819 to specify the calendar date that the journal entry is associated
820 with. Generally, it will have a DATE value data type, but it MAY
821 also be used to specify a DATE-TIME value data type. Examples of a
822 journal entry include a daily record of a legislative body or a
823 journal entry of individual telephone contacts for the day or an
824 ordered list of accomplishments for the day. The "vjournal" calendar
825 component can also be used to associate a document with a calendar
826 date.
828 The "vjournal" calendar component does not take up time on a
829 calendar. Hence, it does not play a role in free or busy time
830 searches - - it is as though it has a time transparency value of
831 transpARENT. It is transparent to any such searches.
833
840 The "vjournal" calendar component MUST include the "dtstamp",
841 "dtstart", "description", "summary" an "uid" properties. In addition,
842 it MUST include the "sequence" property, if it's value is greater
843 than zero.
845 The "vjournal" calendar component cannot be nested within another
846 calendar component. If "vjournal" calendar components need to be
847 related to each other or to a "vevent" or "vtodo" calendar component,
848 they can specify a relationship with the "RELATED-TO" property.
850 5.4.1. Example:
851 The following is an example of the "vjournal" calendar component:
852
853 19970901T130000Z-123405@host.com
854 19970901T1300Z
855 19970317
856 Staff meeting minutes
857 1. Staff meeting: Participants include Joe, Lisa
858 and Bob. Aurora project plans were reviewed. There is currently
859 no budget reserves for this project. Lisa will escalate to
860 management. Next meeting on Tuesday.
861 2. Telephone Conference: ABC Corp. sales representative called
862 to discuss new printer. Promised to get us a demo by Friday.
863 3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
864 Is looking into a loaner car. 654-2323 (tel).
865
866
868 5.5. vfreebusy XML element
870 Name: vfreebusy
872 Purpose: Provide a grouping of component properties that describe
873 either a request for free/busy time, describe a response to a
874 request for free/busy time or describe a published set of busy time.
876 Description: A "vfreebusy" calendar component is a grouping of
877 component properties that represents either a request for, a reply
878 to a request for free or busy time information or a published set of
879 busy time information.
881 The "vfreebusy" calendar component is intended for use in iCalendar
882 object methods involving requests for free time, requests for busy
883 time, requests for both free and busy, and the associated replies.
885 The recurrence properties ("rrule", "exrule", "rdate", "exdate") are
886 not permitted within a "vfreebusy" calendar component. Any recurring
887 events are resolved into their individual busy time periods using
888 the "freebusy" property.
890
891
893
894
896 The "vfreebusy" calendar component MUST include one of the "freebusyreq",
897 "freebusyresp" or "busytime" calendar components.
899 The "freebusyreq" component MUST include the "attendee", "dtstamp",
900 "dtstart", "dtend", and "uid" properties. In addition, it MUST
901 include the "sequence" property, if it's value is greater than zero.
903 The "freebusyresp" component MUST include the "attendee", "dtstamp",
904 "freebusy", and "uid" properties. In addition, it MUST include the
905 "sequence" property, it's value is greater than zero.
907 The "busytime" component MUST include the "attendee", "dtstamp",
908 "dtstart", dtend", and "freebusy" properties.
910 5.5.1. Example:
911 The following is an example of a "vfreebusy" calendar component used
912 to request free or busy time information:
913
914
915 jane_doe@host1.com
916
917 19971015T050000Z
918 19971016T050000Z
919 19970901T083000Z
920 0
921 19970901T0830000-uid1@host1.com
922
923
924 The following is an example of a "vfreebusy" calendar component used
925 to reply to the request with busy time information:
926
927
928 john_public@host2.com
929 19970901T100000Z
930 0
931 19970901T0830000-uid1@host1.com
932 19971015T050000Z/PT8H30M,
933 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
934 http://host2.com/pub/busy/jpublic-01.vcs
935
936
937 This iCalendar file contains busy time information for
938 the next three months.
939
940 The following is an example of a "vfreebusy" calendar component used
941 to published busy time information.
942
943
944 19980314T233000Z/19980315T003000Z
948 19980316T153000Z/19980316T163000Z
949 19980318T030000Z/19980318T040000Z
950 http://www.host.com/calendar/busytime/jsmith.ifb
951
952
954 5.6. vtimezone XML element
956 Name: vtimezone
958 Purpose: Provide a grouping of component properties that defines a
959 time zone.
961 Description: A time zone is unambiguously defined by the set of time
962 measurement rules determined by the governing body for a given
963 geographic area. These rules describe at a minimum the base offset
964 from UTC for the time zone, often referred to as the Standard Time
965 offset.
967 If present, the "vtimezone" calendar component defines the set of
968 Standard Time and Daylight Saving Time observances (or rules) for a
969 particular time zone for a given interval of time. The "vtimezone"
970 calendar component cannot be nested within other calendar
971 components. Multiple "vtimezone" calendar components MAY exist in
972 an iCalendar object. In this situation, each "vtimezone" MUST
973 represent a unique time zone definition. This is necessary for some
974 classes of events, such as airline flights, that start in one time
975 zone and end in another.
977
979
981
984 The properties in a "vtimezone" calendar componets are:
985 The mandatory "tzid" property is a text value that uniquely idenifies
986 the "vtimezone" calendar component within the scope of an iCalendar
987 object.
989 The optional "lastmodified" property is a UTC value that specifies the
990 date and time that this timezone definition was updated.
992 The optional "tzurl" property is a url value that points to a published
993 "vtimezone" definiton.
995 5.6.1. Example:
996 The following are examples of the "vtimezone" calendar component:
998 This is a simple example showing time zone information for the
999 Eastern United States using "rdate" property. Note that this is only
1000 suitable for a recurring event that starts on or later than April 6,
1001 1997 at 02:00:00 EST (i.e., the earliest effective transition date
1002 and time) and ends no later than April 7, 1998 02:00:00 EST (i.e.,
1003 latest valid date and time for EST in this scenario). For example,
1004 this can be used for a recurring event that occurs every Friday,
1005 8am-9am, starting June 1, 1997, ending December 31, 1997.
1006
1007 America-New_York
1008 19870101T000000Z
1009
1010 19971026T020000
1011 19971026T020000
1012 -0400
1013 -0500
1014 EST
1015 19971026T020000
1018 19970406T020000
1019 -0500
1020 -0400
1021 EDT
1022
1023 END:vtimezone
1024 This is a simple example showing the current time zone rules for the
1025 Eastern United States using a rrule recurrence pattern. Note that
1026 there is no effective end date to either of the Standard Time or
1027 Daylight Time rules. This information would be valid for a recurring
1028 event starting today and continuing on into the known future.
1029
1030 America-New_York
1031 19870101T000000Z
1032 http://zones.stds_r_us.net/tz/America-New_York
1033
1034 19671029T020000
1035
1036 -0400
1037 -0500
1038 EST
1039
1040
1041 19870405T020000
1042
1043 -0500
1044 -0400
1045 EDT
1046
1047
1048 This is an example showing a fictitious set of rules for the Eastern
1049 United States, where the Daylight Time rule has an effective end date
1050 (i.e., after that date, Daylight Time is no longer observed).
1052
1053 America-New_York
1054 19870101T000000Z
1055
1056 19671029T020000
1057
1058 -0400
1059 -0500
1060 EST
1061
1062
1063 19870405T020000
1064
1065 -0500
1066 -0400
1067 EDT
1068
1069
1071 5.7. valarm XML element
1073 Name: valarm
1075 Purpose: Provide a grouping of component properties that define an
1076 alarm.
1078 Description: A "valarm" calendar component is a grouping of
1079 component properties that is a reminder or alarm for an event or a
1080 to-do. For example, it may be used to define a reminder for a
1081 pending event or an overdue to-do.
1083 The "valarm" calendar component MUST include the "alarmtype" and
1084 "trigger" properties. In addition, an AUDIO type of alarm MUST
1085 include the "attach" property to point to a digital sound resource
1086 to be played. The DISPLAY type of alarm MUST include the
1087 "description" property. The EMAIL type of alarm MUST include the
1088 "attendee", "description" and "summary" properties. The PROCEDURE
1089 type of alarm MUST include the "attach" property to point to a
1090 procedure resource to be invoked.
1092 The "valarm" calendar component MUST only appear within either a
1093 "vevent" or "vtodo" calendar component. The "valarm" calendar
1094 components cannot be nested. Multiple "valarm" calendar components
1095 MAY be specified.
1097
1103 5.7.1. Example:
1104 The following example is for a "valarm" calendar component that
1105 specifies an audio alarm that will sound at a precise time and
1106 repeat 4 more times at 15 minute intervals:
1107
1108 AUDIO
1109 19970317T133000Z
1110 4
1111 PT15M
1112 ftp://host.com/pub/sounds/bell-01.wav
1113
1114 The following example is for a "valarm" calendar component that
1115 specifies a display alarm that will trigger 15 minutes before the
1116 scheduled start of the event or the due date/time of the to-do it is
1117 associated with and will repeat 2 more times at 15 minute intervals:
1119
1120 DISPLAY
1121 Breakfast meeting with executive
1122 team at 8:30 AM EST.
1123 PT30M
1124 2
1125 PT15M
1126
1127 The following example is for a "valarm" calendar component that
1128 specifies an email alarm that will trigger 2 days before the
1129 scheduled due date/time of a to-do it is associated with. It does not
1130 repeat. The email has a subject, body and attachment link.
1131
1132 EMAIL
1133 mailto:john_doe@host.com
1134 P2D
1135
1136 *** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
1137
1138
1139 A draft agenda needs to be sent out to the attendees
1140 to the weekly managers meeting (MGR-LIST). Attached is a
1141 pointer the document template for the agenda file.
1142
1143 http://host.com/templates/agenda.doc
1144
1145 The following example is for a "valarm" calendar component that
1146 specifies a procedural alarm that will trigger at a precise date/time
1147 and will repeat 23 more times at one hour intervals. The alarm will
1148 invoke a procedure file.
1149
1150 PROCEDURE
1151
1152 19980101T050000Z
1153
1154 23
1155 PT1H
1156 ftp://host.com/novo-procs/felizano.exe
1157
1159 6. Calendar Properties
1160 Property: A property is the definition of an individual attribute
1161 describing a calendar property or a calendar component.
1163 Property names, attribute names and attribute values are case
1164 insensitive.
1166 6.1. attach Property
1167 Name: attach
1168 Purpose: The property provides the capability to associate a document
1169 object with a calendar component.
1170 Value: URI ; The default value type for this property is URI. The
1171 value type MAY also be reset to BINARY in order to include inline
1172 binary encoded content information.
1174 Description: The property MAY only be specified within "vevent",
1175 "vtodo", "vjournal", or "VALARM" calendar components. This property
1176 MAY be specified multiple times within an iCalendar object.
1178
1179
1183 6.2. categories Property
1184 Name: categories
1186 Purpose: This property defines the categories for a calendar
1187 component.
1189 Description: This property is used to specify categories or subtypes
1190 of the calendar component. The categories are useful in searching for
1191 a calendar component of a particular type and category. Within the
1192 "vevent", "vtodo" or "vjournal" calendar components, more than one
1193 category MAY be specified as a list of categories separated by the
1194 COMMA character (ASCII decimal 44).
1196
1197
1200 6.3. class Property
1201 Name: class
1203 Purpose: This property defines the access classification for a
1204 calendar component.
1206 Description: An access classification is only one component of the
1207 general security system within a calendar application. It provides a
1208 method of capturing the scope of the access the calendar owner
1209 intends for information within an individual calendar entry.
1211
1213 6.4. comment Property
1214 Name: comment
1216 Purpose: This property specifies non-processing information intended
1217 to provide a comment to the calendar user.
1219 Description: The property MAY be specified multiple times.
1221
1222
1226 6.5. description Property
1227 Name: description
1229 Purpose: This property provides a more complete description of the
1230 calendar component, than that provided by the "summary" property.
1232 Description: This property is used to capture lengthy textual decriptions
1233 associated with the activity.
1235
1236
1240 6.6. location Property
1242 Name: location
1244 Purpose: The property defines the intended venue for the activity
1245 defined by a calendar component.
1247 Description: Specific venues such as conference or meeting rooms may
1248 be explicitly specified using this property. An alternate
1249 representation may be specified that is a URI that points to
1250 directory information with more structured specification of the
1251 location.
1253
1254
1258 6.7. percentcomplete Property
1260 Name: percentcomplete
1262 Purpose: This property is used by an assignee or delegatee of a to-do
1263 to convey the percent completion of a to-do to the Organizer.
1265 Description: The property value is a postive integer between zero and
1266 one hundred. A valu e of "0" indicates the to-do has not yet been
1267 started. A value of "100" indicates that the to-do has been
1268 completed. Integer values in between indicate the percent partially
1269 complete.
1271 6.8. priority Property
1272 Name: priority
1274 Purpose: The property defines the relative priority for a calendar
1275 component.
1277 Description: The priority is specified as an integer in the range
1278 zero to nine. A value of zero (ASCII decimal 48) specifies an
1279 undefined priority. A value of one (ASCII decimal 49) is the highest
1280 priority. A value of two (ASCII decimal 50) is the second highest
1281 priority. Subsequent numbers specify a decreasing ordinal priority. A
1282 value of nine (ASCII decimal 58) is the lowest priority.
1284 Within a "vevent" calendar component, this property specifies a
1285 priority for the event. This property may be useful when more than
1286 one event is scheduled for a given time period.
1288 Within a "vtodo" calendar component, this property specified a
1289 priority for the to-do. This property is useful in prioritizing
1290 multiple action items for a given time period.
1292 6.9. resources Property
1294 Name: resources
1296 Purpose: This property defines the equipment or resources anticipated
1297 for an activity specified by a calendar entity..
1299 Description: The property value is an arbitrary text. More than one
1300 resource MAY be specified as a list of resources separated by the
1301 COMMA character (ASCII decimal 44).
1303
1304
1307 6.10. status Property
1308 Name: status
1309 Purpose: This property defines the overall status or confirmation for
1310 the calendar component.
1312 Description: In a group scheduled calendar component, the property is
1313 used by the "Organizer" to provide a confirmation of the event to the
1314 "Attendees". For example in a "vevent" calendar component, the
1315 "Organizer" can indicate that a meeting is tentative, confirmed or
1316 cancelled. In a "vtodo" calendar component, the "Organizer" can
1317 indicate that an action item needs action, is completed, is in
1318 process or being worked on, or has been cancelled. In a "vjournal"
1319 calendar component, the "Organizer" can indicate that a journal entry
1320 is draft, final or has been cancelled or removed.
1322 6.11. summary Property
1324 Name: summary
1326 Purpose: This property defines a short summary or subject for the
1327 calendar component.
1329 Description: This property is used to capture a short, one line summary
1330 about the activity or journal entry.
1332
1333
1337 6.12. completed property
1339 Property Name: completed
1341 Purpose: This property defines the date and time that a to-do was
1342 actually completed.
1344 Value : DATE-TIME
1346 Description: The date and time must be in a UTC format.
1348 6.13. dtend Property
1350 Name: dtend
1352 Purpose: This property specifies the date and time that a calendar
1353 component ends.
1355 Value: DATE-TIME; The default value type is DATE-TIME. The value type MAY
1356 BE reset to a DATE value type.
1358 Description: Within the "vevent" calendar component, this property
1359 defines the date and time by which the event ends. The value MUST be
1360 later in time than the value of the "dtstart" property.
1362 Within the "VFREEBUSY" calendar component, this property defines the
1363 end date and time for the free or busy time information. The time
1364 MUST be specified as in the UTC time format. The value MUST be later
1365 in time than the value of the "dtstart" property.
1367
1368
1372 6.14. due Property
1374 Name: due
1376 Purpose: This property defines the date and time that a to-do is
1377 expected to be completed.
1379 Value: DATE-TIME ; The default value type is DATE-TIME. The value type MAY
1380 BE reset to a DATE value type.
1382 Description: The value MUST be a date/time equal to or after the
1383 dtstart value, if specified.
1385
1386
1390 6.15. dtstart Property
1392 Name: dtstart
1394 Purpose: This property specifies when the calendar component begins.
1396 Value: DATE-TIME; The default value type is DATE-TIME. The DATE-TYPE value
1397 will be one of the forms defined for the DATE-TIME value type. The
1398 value type MAY BE reset to a DATE value type.
1400 Description: Within the "vevent" calendar component, this property
1401 defines the start date and time for the event. The property is
1402 REQUIRED in "vevent" calendar components. Events MAY have a start
1403 date/time but no end date/time. In that case, the event does not take
1404 up any time.
1406 Within the "VFREEBUSY" calendar component, this property defines the
1407 start date and time for the free or busy time information. The time
1408 MUST be specified in UTC time.
1410 Within the "VTIMEZONE" calendar component, this property defines the
1411 effective start date and time for a time zone specification. This
1412 property is REQUIRED within "VTIMEZONE" calendar components. The time
1413 MUST be specified in the UTC time format.
1415
1416
1420 6.16. duration Property
1422 Name: duration
1424 Purpose: The property specifies a duration of time .
1426 Value : duration
1428 Description: In a "vevent" calendar component the property may be
1429 used to specify a duration of the event, instead of an explicit end
1430 date/time. In a "vtodo" calendar component the property may be used
1431 to specify a duration for the to-do, instead of an explicit due
1432 date/time. In a "VFREEBUSY" calendar component the property may be
1433 used to specify the interval of free time being requested. In a
1434 "VALARM" calendar component the property may be used to specify the
1435 delay period prior to repeating an alarm.
1437 6.17. freebusy Property
1439 Name: freebusy
1441 Purpose: The property defines one or more free or busy time
1442 intervals.
1444 Value : PERIOD; The data and time value MUST be in a UTC time
1445 format.
1447 Description: These time periods MAY be specified as either a start
1448 and end date-time or a start date-time and duration. The date and
1449 time MUST be a UTC time format.
1451 The "FREEBUSY" property MAY include the "TYPE" property parameter to
1452 specify whether the information defines a FREE or BUSY time interval.
1453 The default "TYPE" property parameter value is BUSY.
1455 If the "TYPE" property parameter is set to "BUSY", then the property
1456 MAY also include the "BSTAT" property parameter to provide added
1457 information about the busy time. For example, if the busy time is
1458 associated with a time interval that would be unavailable for
1459 scheduling in any case the parameter MAY BE set to UNAVAILABLE or if
1460 the busy time that has been tentatively scheduled the parameter MAY
1461 BE set to TENTATIVE. The default "BSTAT" property parameter value is
1462 BUSY, providing no additional busy status information.
1464 "FREEBUSY" properties within the "VFREEBUSY" calendar component
1465 should be sorted in ascending order, based on start time and then end
1466 time, with the earliest periods first.
1468 The "FREEBUSY" property MAY specify more than one value, separated by
1469 the COMMA character (ASCII decimal 44). In such cases, the "FREEBUSY"
1470 property values should all be of the same "TYPE" and "BSTAT" property
1471 parameter type (e.g., all values of a particular "TYPE" and "BSTAT"
1472 listed together in a single property).
1474
1475
1518
1522 6.20. organizer Property
1524 Name: organizer
1526 Purpose: The property defines the organizer for a calendar component.
1528 Value: CAL-ADDRESS
1530 Description: The property is specified within the "vevent", "vtodo",
1531 "vjournal calendar components to specify the organizer of a group
1532 scheduled calendar entity. The property is specified within the
1533 "VFREEBUSY" calendar component to specify the calendar user
1534 requesting the free or busy time.
1536
1537
1542 The property has the property parameters CN, for specifying the
1543 common or display name associated with the "Organizer", DIR, for
1544 specifying a pointer to the directory information associated with the
1545 "Organizer", SENT-BY, for specifying another calendar user that is
1546 acting on behalf of the "Organizer". No other parameters MAY be
1547 specified on this property.
1549 6.21. recurid Property
1551 Name: recurid
1553 Purpose: This property is used in conjunction with the "uid" and
1554 "sequence" property to identify a specific instance of a recurring
1555 "vevent", "vtodo" or "vjournal" calendar component. The property
1556 value is the effective value of the "dtstart" property of the
1557 recurrence instance.
1559 Value Type: DATE-TIME; The default value type for this property is DATE-TIME.
1560 The time format MAY BE any of the valid forms defined for a DATE-TIME
1561 value type. See DATE-TIME value type definition for specific
1562 interpretations of the various forms. The value type MAY be reset to
1563 DATE.
1565 Description: The full range of calendar components specified by a
1566 recurrence set is referenced by referring to just the "uid" property
1567 value corresponding to the calendar component. The "recurrence-id"
1568 property allows the reference to an individual instance within the
1569 recurrence set.
1571 If the value of the "dtstart" property is a DATE type value, then the
1572 value MUST be the calendar date for the recurrence instance.
1574 The date/time value is set to the time when the original recurrence
1575 instance would occur - - meaning that if the intent is to change a
1576 Friday meeting to Thursday, the date/time is still set to the
1577 original Friday meeting.
1579 The "recurrence-id" property is used in conjunction with the "uid"
1580 and "SEQUENCE" property to identify a particular instance of a
1581 recurring event, to-do or journal. For a given pair of "uid" and
1582 "SEQUENCE" property values, the "recurrence-id" value for a
1583 recurrence instance is fixed.
1585
1586
1590 6.22. relatedto Property
1592 Name: relatedto
1594 Purpose: The property is used to represent a relationship or
1595 reference between one calendar component and another.
1597 Description: The property value consists of the persistent, globally
1598 unique identifier of another calendar component. This value would be
1599 represented in a calendar component by the "uid" property.
1601 By default, the property value points to another calendar component
1602 that has a PARENT relationship to the referencing object. The
1603 "RELTYPE" property parameter is used to either explicitly state the
1604 default PARENT relationship type to the referenced calendar component
1605 or to override the default PARENT relationship type and specify
1606 either a CHILD or SIBLING relationship.
1607
1608
1611 6.23. url property
1613 Name: url
1615 Purpose: This property defines a Uniform Resource Locator (URL)
1616 associated with the iCalendar object.
1618 Value: URI
1620 Description: This property may be used in a calendar component to
1621 convey a location where a more dynamic rendition of the calendar
1622 information associated with the calendar component can be found. This
1623 memo does not attempt to standardize the form of the URI, nor the
1624 format of the resource pointed to by the property value. If the
1626 6.24. uid Property
1628 Name: uid
1630 Purpose: This property defines the persistent, globally unique
1631 identifier for the calendar component.
1633 Description: The uid itself MUST be a globally unique identifier. The
1634 generator of the identifier MUST guarantee that the identifier is
1635 unique. There are several algorithms that can be used to accomplish
1636 this. The identifier is RECOMMENDED to be the identical syntax to the
1637 [RFC 822] addr-spec.
1639 6.25. exdate Property
1641 Name: exdate
1643 Purpose: This property defines the list of date/time exceptions for a
1644 recurring calendar component.
1646 Value: DATE-TIME ; The default value type for this property is DATE-TIME.
1647 The value type MAY be reset to DATE.
1649 Description: The exception dates, if specified, is used in computing
1650 the recurrence set. The recurrence set is the complete set of
1651 recurrence instances for a calendar component.
1653 6.26. exrule Property
1655 Name: exrule
1657 Purpose: This property defines a rule or repeating pattern for an
1658 exception to a recurrence set.
1660 Value: RECUR
1662 Description: The exception rule, if specified, is used in computing
1663 the recurrence set. The recurrence set is the complete set of
1664 recurrence instances for a calendar component.
1666 6.27. rdate Property
1668 Name: rdate
1670 Purpose: This property defines the list of date/times for a
1671 recurrence set.
1673 Value : DATE-TIME ; The default value type for this property is DATE-TIME.
1674 The value type MAY be reset to DATE or PERIOD.
1676 Description: This property MAY appear along with the "rrule" property
1677 to define an aggregate set of repeating occurrences. When they both
1678 appear in an iCalendar object, the recurring events are defined by
1679 the union of occurrences defined by both the "rdate" and "rrule".
1681 The recurrence dates, if specified, is used in computing the
1682 recurrence set. The recurrence set is the complete set of recurrence
1683 instances for a calendar component.
1684
1685
1689 6.28. rrule Property
1691 Name: rrule
1693 Purpose: This property defines a rule or repeating pattern for a
1694 recurring events, to-dos, or time zone definitions.
1696 Value: RECUR
1698 Description: The recurring rule, if specified, is used in computing
1699 the recurrence set. The recurrence set is the complete set of
1700 recurrence instances for a calendar component.
1702 6.29. trigger Property
1704 Name: trigger
1706 Purpose: This property specifies when an alarm will trigger.
1708 Value: duration ; The default value type is duration. The value type MAY BE
1709 reset to a DATE-TIME value type.
1711 Description: Within the "VALARM" calendar component, this property
1712 defines when the alarm will trigger. The default value type is
1713 duration, specifying a relative time for the trigger of the alarm.
1714 The default duration is relative to the start of an event or to-do
1715 that the alarm is associated with. The duration can be explicitly set
1716 to trigger from either the end or the start of the associated event
1717 or to-do with the "RELATED" parameter. A value of START will set the
1718 alarm to trigger off the start of the associated event or to-do. A
1719 value of END will set the alarm to trigger off the end of the
1720 associated event or to-do.
1722
1723
1728 6.30. created Property
1730 Name: created
1732 Purpose: This property specifies the date and time that the calendar
1733 information was created in the calendar user agent.
1735 Value : DATE-TIME
1737 Description: The date and time is a UTC value.
1739 6.31. dtstamp Property
1741 Name: dtstamp
1743 Purpose: The property indicates the date/time that the instance of
1744 the iCalendar object was created.
1746 Value: DATE-TIME
1748 Description: The value must be specified in the UTC time format.
1750 This property will assist in the proper sequencing of messages
1751 containing iCalendar objects.
1753 This property is different than the "created" and "lastmodified"
1754 properties. These two properties are used to specify when the
1755 calendar service information was created and last modified. This is
1756 different than when the iCalendar object representation of the
1757 calendar service information was created or last modified.
1759 6.32. lastmodified Property
1761 Name: lastmodified
1763 Purpose: The property specifies the date and time that the
1764 information associated with the calendar component was last revised.
1766 Value: DATE-TIME
1768 Description: The property value MUST be specified in the UTC time
1769 format.
1771 6.33. sequence Property
1773 Name: sequence
1775 Purpose: This property defines the revision sequence of the calendar
1776 component used in a request.
1778 Value: INTEGER
1780 Description: This property is needed to properly handle the receipt
1781 and processing of a sequence of calendar components that have been
1782 delivered out of order. Such is the case for store-and-forward based
1783 transports. The first request is created with a sequence number of
1784 "0" (ASCII decimal 48). It is incremented each time the organizer or
1785 OWNER issues a revision to the request.
1787 6.34. requeststatus Property
1789 Name: requeststatus
1791 Purpose: This property defines the status code returned for a
1792 scheduling request.
1794 Description: This property is used to return status code information
1795 related to the processing of an associated iCalendar object. The data
1796 type for this property is TEXT.
1798 The value consists of a short return status, a longer return status
1799 description, and optionally the offending data. The components of the
1800 value are separated by the SEMICOLON character (ASCII decimal 59).
1802 The short return status is a PERIOD character (ASCII decimal 46)
1803 separated 3-tuple of integers. For example, "3.1.1". The successive
1804 levels of integers provide for a successive level of status code
1805 granularity.
1807
1808
1812 7. Security Considerations
1813 Since calendaring interoperability may involve the exchange of
1814 sensitive information, any calendaring interoperability mechanism
1815 must provide for encryption and authentication. Several techniques
1816 such as SSL and HTTP Access Authorization are available for use with
1817 HTTP as described in [3] and [4]. Without such techniques, SCAP
1818 clients and servers are wide open to forged or snooped meeting
1819 proposals or responses.
1821 8. Calendar Object Specification - XML DTD
1822
1824
1825
1826
1828
1831
1839
1848
1855
1857
1860
1862
1864
1867
1870
1873
1880
1881
1885
1886
1889
1891
1892
1896
1897
1901
1902
1906
1907
1909
1910
1913
1915
1920
1922
1923
1927
1928
1932
1933
1937
1939
1940
1947
1951
1952
1957
1958
1962
1963
1966
1968
1970
1972
1974
1976
1977
1981
1982
1987
1991
1993
1995
1997
1999
2001
2002
2004
2006
2008
2010
2012
2014
2016
2018
2020
2022
2024
2025
2029 ]>
2031 9. References
2033 [CSCOS] F. Dawson, D. Stenerson, Internet Calendaring and Scheduling
2034 Core Object Specification, Internet Draft, draft-ietf-calsch-ical-00.txt,
2035 February 1997.
2037 [Alvestrand, 1995] H. T. Alvestrand, "Tags for the Identification of
2038 Languages." RFC 1766. Uninett. March, 1995.
2040 [Alvestrand, 1998] H. T. Alvestrand, "IETF Policy on Character Sets
2041 and Languages." RFC 2277, BCP 18. Uninett. January, 1998.
2043 [Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate
2044 Requirement Levels." RFC 2119, BCP 14. Harvard University. March,
2045 1997.
2047 [Bray, Paoli, Sperberg-McQueen, 1998] T. Bray, J. Paoli, C. M.
2048 Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web
2049 Consortium Recommendation REC-xml-19980210.
2051 http://www.w3.org/TR/1998/REC-xml-19980210.
2053 [Franks et al., 1997] J. Franks, P. Hallam-Baker, J. Hostetler, P.
2054 Leach, A. Luotonen, E. Sink, and L. Stewart. "An Extension to HTTP :
2055 Digest Access Authentication" RFC 2069. Northwestern University,
2056 CERN, Spyglass Inc., Microsoft Corp., Netscape Communications Corp.,
2057 Spyglass Inc., Open Market Inc. January 1997.
2059 [Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H.
2060 Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
2061 RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997.
2063 [ISO-639] ISO (International Organization for Standardization). ISO
2064 639:1988. "Code for the representation of names of languages."
2066 [ISO-8601] ISO (International Organization for Standardization). ISO
2067 8601:1988. "Data elements and interchange formats - Information
2068 interchange - Representation of dates and times."
2070 [Leach, Salz, 1998] P. J. Leach, R. Salz, "UUIDs and GUIDs."
2071 Internet-draft, work-in-progress, February, 1998.
2072 ftp://ietf.org/internet-drafts/draft-leach-uuids-guids-01.txt
2074 [Yergeau, 1998] F. Yergeau, "UTF-8, a transformation format of
2075 Unicode and ISO 10646." RFC 2279. Alis Technologies. January, 1998.
2077 [Bradner, 1996] S. Bradner, "The Internet Standards Process -
2078 Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996.
2080 [Bray, Hollander, Layman, 1998] T. Bray, D. Hollander, A. Layman,
2081 "Name Spaces in XML" World Wide Web Consortium Working Draft,
2082 http://www.w3.org/TR/WD-xml-names.
2084 10. Author's Address
2086 Surendra Reddy
2087 Oracle Corporation
2088 500 Oracle Parkway
2089 M/S 6op3
2090 Redwoodshores, CA 94065
2091 Phone: +1(650) 506 5441
2092 Fax: +1(650) 654 6205
2093 Email: skreddy@us.oracle.com