Subject: Questions to answer for the METHOD issue

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 24 May 2002 15:24:46 -0400

Just to make sure we are all on the same page about
the current issue to solve, here's the questions I
think we need to answer:

A- Mary wants to invite Bob to a meeting.

   Q1: What is the format of the iCalendar object
       Mary needs to send to the CS to deposit a
       calendar invitation in Bob's agenda?

B- Bob wants to find all the calendar invitations
   he did not already processed.

   Q2: What is the format of the iCalendar object
       Bob needs to send to the CS to get all
       unprocessed calendar invitations?

   Q3: In which format will the iCalendar objects
       of the unprocessed calendar invitations be
       returned to Bob?

Can someone provide *complete* iCalendar objects
for all 3 questions?

Cheers,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Fri, 24 May 2002 13:54:19 -0600

>        calendar invitation in Bob's agenda?

	METHOD:REQUEST

>        unprocessed calendar invitations?

	SELECT * FROM VAGENDA WHERE STATE() = 'UNPROCESSED'

>        of the unprocessed calendar invitations be

	100% of all 'UNPROCESSED' iCalendar objects are iTIP
	objects.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 27 May 2002 09:10:17 -0400

>         SELECT * FROM VAGENDA WHERE STATE() = 'UNPROCESSED'

In your previous post you specified that the following
query (SELECT * FROM VEVENT) would return all unprocessed
VEVENT components :

        SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED'

How can the query you specified here (SELECT * FROM VAGENDA)
also return all unprocessed VEVENT components?

The STATE() function is ambiguous.  It is not clear to which
object it applies.  We don't need a new function in CAP-QL
to solve the issue at hand.

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 27 May 2002 09:23:31 -0400

> the current issue to solve, here's the questions I

I had ask people to provide *complete* iCalendar objects
for all 3 questions, yet no one did.  How can we reach
consensus with vague answers?

Anyway, here's a proposal with *complete* iCalendar objects.

>        calendar invitation in Bob's agenda?

  BEGIN:VCALENDAR
  VERSION:2.0
  PRODID:-//ACME/DesktopCalendar//EN
  BEGIN:VCOMMAND
  CMD:CREATE
  CMDID:abc123
  TARGET:cap://cal/bob-relcalid
  BEGIN:VITIP
  VERSION:2.0
  PRODID:-//TOTO/MyCalendar//EN
  X-FOO:bar
  METHOD:REQUEST
  BEGIN:VEVENT
  UID:abcd12345
  ORGAGNIZER:cap://cal/mary-relcalid
  ATTENDEE;PARTSTAT=ACCEPTED:cap://cal/mary-relcalid
  ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal/bob-relcalid
  DTSTART:20010920T180000Z
  DTEND:20010920T190000Z
  SUMMARY:Mary invites Bob
  END:VEVENT
  END:VITIP
  END:VCOMMAND
  END:VCALENDAR

The VCOMMAND component, which was used in draft-05, is
reinstated essentially for the same reasons it was first
introduced in draft-05.  In a nutshell, this component
allow us to use the property CMD, CMDID and TARGET without
breaking the iCalendar syntax specified in RFC 2445 (i.e.,
these 3 properties aren't allowed directly in a VCALENDAR
component).

A new VITIP component is introduced to allow iTIP objects
to easily be contained in VAGENDA components.  This new
component solves the issue about where the METHOD property
should be "stored", or more precisely (since CAP doesn't
specify how components should be stored) how to search for
components based on their METHOD.

The introduction of this new VITIP component also solves
the issue about where the properties VERSION, PRODID,
CALSCALE and X-PROP should be stored and how they can
be queried.  All these properties can now be stored in
VITIP components.

>        unprocessed calendar invitations?

  BEGIN:VCALENDAR
  VERSION:2.0
  PRODID:-//ABC/AnyCalendar//EN
  BEGIN:VCOMMAND
  CMD:SEARCH
  CMDID:def456
  TARGET:cap://cal/bob-relcalid
  BEGIN:VQUERY
  QUERY:SELECT * FROM VITIP WHERE METHOD = 'REQUEST'
  END:VQUERY
  END:VCOMMAND
  END:VCALENDAR

>        of the unprocessed calendar invitations be

  BEGIN:VCALENDAR
  VERSION:2.0
  PRODID:-//XYZZY/CalendarServer//EN
  BEGIN:VRESULT
  CMDID:def456
  REQUEST-STATUS:2.0
  TARGET:cap://cal/bob-relcalid
  BEGIN:VITIP
  VERSION:2.0
  PRODID:-//TOTO/MyCalendar//EN
  X-FOO:bar
  METHOD:REQUEST
  BEGIN:VEVENT
  UID:abcd12345
  ORGAGNIZER:cap://cal/mary-relcalid
  ATTENDEE;PARTSTAT=ACCEPTED:cap://cal/mary-relcalid
  ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal/bob-relcalid
  DTSTART:20010920T180000Z
  DTEND:20010920T190000Z
  SUMMARY:Mary invites Bob
  END:VEVENT
  END:VITIP
  END:VRESULT
  END:VCALENDAR

A new component VRESULT is introduced to allow us to use the
property CMDID, REQUEST-STATUS and TARGET without breaking
the iCalendar syntax specified in RFC 2445 (i.e., these 3
properties aren't allowed directly in a VCALENDAR component).

Cheers,
Bernard