Subject: CAP: storing new components

From: Doug Royer <[email-masked]>
Date: Mon, 19 Nov 2001 13:32:31 -0700

I would like to see the following text added to CAP. (someone
might want to re-check these against the iTIP and CAP restriction
tables - I did - but checking your own work often misses things).

Add?:

In addition to being able to create new components, a CS
must be able to store iTIP methods. Here are some examples:

This example adds to the calendar in one operation, a booked
VEVENT; an iTIP, REPLY, ADD, CANCEL, REFRESH, COUNTER,
DECLINECOUNTER, PUBLISH, and REQUEST. It is not likely
that a CUA will need to do all of this in one operation. This
example simply shows how all of these are done using CAP.
(spaces between components for ease of reading only.
 Hash (#) marks denote comments in this text only and are not
 part of the data).

BEGIN:VCAP
VERSION:2.1
CMDID:big-command
BEGIN:VCOMMAND
METHOD:CREATE
TARGET:cap://Royer.com/Doug

BEGIN:VEVENT
METHOD:CREATE			# This one is created - booked
DTSTAMP:20011119T101214
ORGANIZER:cap://cal.example.com/BigBadWolf
DTSTART:19580205T0631Z
DTEND:19580205T0730Z
UID:unique#1
SUMMARY:A big day
END:VEVENT

BEGIN:VEVENT
METHOD:REPLY			# The iTIP REPLY is stored.
DTSTAMP:20011119T130124
ORGANIZER:cap://Royer.com/Doug
UID:unique#2
ATTENDEE;PARTSTAT=ACCEPTED:[email-masked]
END:VEVENT

BEGIN:VEVENT
METHOD:ADD			# Stores an iTIP notification of a
DTSTAMP:20011119T123000         # new instance of an existing
UID:unique#3                    # VEVENT.
DTSTART:20011226
DTEND:20011227
ORGANIZER:cap://Royer.com/CompanyHolidays
SEQUENCE:1
SUMMARY:Additional HOLIDAY
END:VEVENT

BEGIN:VEVENT                    # Stores the iTIP CANCEL
METHOD:CANCEL			# notification.
DTSTAMP:20011119T130138
UID:unique#4
ATTENDEE:user1
ATTENDEE:user2
END:VEVENT

BEGIN:VEVENT
METHOD:REFRESH                  # Stores the request for REFRESH.
DTSTAMP:20011119T131123
ORGANIZER:cap://cal.example.com/cal
ATTENDEE:[email-masked]
UID:some-unique-id
END:VEVENT

BEGIN:VEVENT
METHOD:COUNTER                  # Stores the request for change.
DTSTAMP:20011119T131254
DTSTART:20011124T110000
SUMMARY:Weekly meeting
UID:a-unique-value
LOCATION:The other building
END:VEVENT

BEGIN:VEVENT
METHOD:DECLINECOUNTER		# Stores the denial for request
DTSTAMP:20011119T131514		# of the COUNTER.
ORGANIZER:cap://cal.example.com/cal
UID:some-unique-id
END:VEVENT

BEGIN:VEVENT
METHOD:PUBLISH			# Stores the published VEVENT
DTSTAMP:20011119T131744		# for review by the OWNER.
DTSTART:20011123T110000
DTEND:20011123T120000
UID:another-unique-id
SUMMARY:Another open meeting
ORGINIZER:cap://Royer.com/Doug
END:VEVENT

BEGIN:VEVENT
METHOD:REQUEST			# Stores the VEVENT that the OWNER
DTSTAMP:20011119T131744		# is requested to attend.
DTSTART:20011201T120000
DTEND:20011207T180000
UID:a-good-uid
SUMMARY:Salt Lake IETF meeting
ORGINIZER:cap://cal.ietf.com/ietf
ATTENDEE;RSVP=YES:cap://Royer.com/Doug
END:VEVENT

BEGIN:VEVENT
METHOD:REPLY			# Stores the REPLY recieved.
DTSTAMP:20011119T122413
ORGANIZER:cap://cal.ietf.com/ietf
UID:a-good-uid
ATTENDEE;PARTSTAT=ACCEPTED:cap://Royer.com/Doug
END:VEVENT

END:VCMD
END:VCAP