Subject: CAP Issue: Where to store METHOD info

From: [email-masked] (Steve Mansour)
Date: Thu, 18 Apr 2002 23:35:15 -0700

All,

Here's a summary of the next CAP issue to nail. We have not yet defined
what we're going to do with METHOD information. We have stated that we
want to move METHOD information into components. But we have not yet
defined a property in which to store the info.  We may not want to store
it in a property named METHOD because that property is already used in
iTIP and it appears in the VCALENDAR container (not a component
container). We need to define the property we want to use.

Once the method information is stored in a VEVENT, VTODO, or VJOURNAL,
it is less an action and more a state. It's name should reflect its
use.  So, something like WORKFLOWSTATE is probably better (though I'm
not wed to that name).

We also need to define how the WORKFLOWSTATE property is added to a
component, especially in the iTIP workflow.  That is, when we store an
iTIP request like

          BEGIN:VCALENDAR
          PRODID:-//ACME/DesktopCalendar//EN
          METHOD:REQUEST
          VERSION:2.0
          BEGIN:VEVENT
          UID:012345
          ORGAGNIZER:cap://cal.example.com/mary-relcalid
          ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.example.com/mary-relcalid

ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/john-relcalid

ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:cap://cal.example.com/bob-relcalid

          DTSTART:20010920T180000Z
          DTEND:20010920T190000Z
          SUMMARY:Mary invites John and Robert
          END:VEVENT
          END:VCALENDAR

then we do a query for the VEVENT with UID equal to 012345, will it have
a WORKFLOWSTATE property?  Put another way, is the WORKFLOWSTATE
automatically added when we write the request to the calstore?  Or do we
require the CUA to specifically add the WORKFLOWSTATE property?

Another problem is that if we only store the METHOD information into
WORKFLOWSTATE, then we have a lossy transformation. There is other
information in the iTIP request that we have not stored.  For example,
consider the following ITIP request:

          BEGIN:VCALENDAR
          PRODID:-//ACME/DesktopCalendar//EN
          METHOD:REQUEST
          VERSION:2.0
          BEGIN:VEVENT
          ...
          END:VEVENT
          END:VCALENDAR

We are talking about migrating the METHOD:REQUEST value into a new
component property like WORKFLOWSTATE. But what about information like
PRODID and VERSION ?  Might those or other values contained in the
VCALENDAR become significant over time?  Do we just toss them?

One suggestion in Minneapolis was to create a new component called VITIP
that would contain everything in the ITIP request.

Do we need something like VITIP ?  or is migrating the METHOD value into
WORKFLOWSTATE good enough?  Other thoughts?

-Steve

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 19 Apr 2002 09:20:06 -0400

> WORKFLOWSTATE good enough?  Other thoughts?

Tossing PRODID, VERSION and CALSCALE is probably acceptable, but
we should not forget that VCALENDAR components may have x-prop.
Tossing x-prop is probably not acceptable.

The VITIP component proposed in Minneapolis would cover this issue.

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, 19 Apr 2002 10:19:43 -0600

> container). We need to define the property we want to use.

(I'll address your VERSION and PRODID questions in a separate email)

I think we are making this too complicated - lets go back to simple.
So forget what you know and listen to my proposal :-)

There are two kinds of objects - iTIP and non-iTIP objects.
Non-iTIP objects are anything not defined in iTIP (or any later
version of iTIP). These are also called scheduling requests (not REQUEST).

The METHOD is never 'moved' into the component. It is an implementation
detail on how the CS 'knows' that any object was stored into the
CS where the iTIP object had a iTIP METHOD:{whatever} .

	SELECT * from VEVENT where METHOD = 'REQUEST'

As long as the CS returns all VEVENTs that were stored into the CS
with iTIP METHOD:REQUEST. And the CS returns a VALID iTIP object, it
does not matter how the CS stored or tagged the data. It matters
that the CS can respond to a valid query with valid data as
defined in iTIP or CAP.

We do NOT need to specify how the CS knows that it was METHOD:REQUEST.
We MUST BE able to query by METHOD.

We do NOT need to invent another over the wire format for METHOD:REQUEST
when 100% of the time it is 'iTIP' METHOD:REQUEST (lets NOT add WORKFLOWSTATE
over the wire). And 100% of all non-booked objects are iTIP objects.
(you can not schedule a stored VCAR).

Lets just say that when the CS stores iTIP objects, the CS MUST
be able to somehow know that is there state to enable queries to work.
Because 100% of all iTIP objects are non-booked.

And for booked items, they have a mythical METHOD of CREATE that
tells the CS to store them and not think of them as scheduling requests.

---

From: Doug Royer <[email-masked]>
Date: Fri, 19 Apr 2002 10:43:29 -0600

Steve Mansour wrote:

> All,
> 
> Here's a summary of the next CAP issue to nail.
> ...
> 

VERSION - it is the VERSION of the iCalendar wire format - not data.
As long as the CS returns VALID iCalednar objects, and the CUA sends valid 
iCalendar objects - it DOES NOT MATTER if the CS stores VERSION or not.
I say we leave it un-specified. I'll store it in case we ever bump
the iCalednar object format version. I'll always return the correct
VERSION over the wire to the CUA.

How about we add to CAP:

	 It is not valid to query by VERSION as it has no meaning.
          VERSION is the format over the wire format of the iCalendar object
          and it is NOT the VERSION of the data.

          A CS MAY store the VERSION. The CS MUST always return
          a correct VERSION in the iCalendar objects. A CUA
          MUST always send a valid VERSION.

PRODID - It is my experience with working with IMAP that implementations
sometimes need to know the PRODID so that an implementation can work
around other implementation bugs or quirks.  I would say that an
implementation MAY store the PRODID with the data, however the
PRODID over the wire MUST BE the CS (or CUA) PRODID.
So like VERSION how about we add to CAP:

	 It is not valid to query by PRODID as it has no meaning.
          PRODID is the product id of the implementation that
          created the over the wire iCalendar object. PRODID is NOT the
          PRODID of the data and is not the PRODID of the ATTENDEE
          or ORGANIZERs product.

          A CS MAY store the PRODID. The CS MUST always send
          the PRODID of the CS and the CUA MUST always send
          the PRODID of the CUA.

> that would contain everything in the ITIP request.

NO - they are 100% complete objects now.

> WORKFLOWSTATE good enough?  Other thoughts?

Nether - we just need to specify that the CS MUST be able to query
by METHOD. We do not need to specify HOW the CS knows how
to do that.

-- 
-
Doug Royer
[email-masked]
http://Royer.com/People/Doug