Subject: Re: CAP: Consensus?: Order In Which Scheduled Components Are ProcessedIsSpecified In iTIP

From: [email-masked]
Date: Mon, 25 Feb 2002 17:18:46 -0500

Doug replied on 02/25/2002 04:39:10 PM:
> If you recall - we dropped iRIP and added the iRIP iTIP processing
> into CAP. Part of CAP is iTIP. All iTIP objects are valid in CAP
> and mean the same thing. 

I grok that we need this for iTIP compatability for several reasons but 
its never been expressly said in any text/drafts.  I think it MUST be 
expressly written so that motivations for why something is or is not 
allowable is crystal clear.  Otherwise we revert to "Well I see it as..." 
kinds of discussions instead of having clear cut guidelines for making 
decisions.

The reason Im more than a bit skeptical is that some CAP commands use 
"deltas" instead of "full snapshots" and thats why I want to be 100% 
clear.  An example of this "delta" use is the "add" element in Section 
6.2.4.3 where only the 'changes' get sent.  This is 100% NOT iTIP legal 
because the 'delta' is just that; its not a complete snapshot that iTIP 
expects or that an iMIP CUA would need.  The same goes for much of the 
"modify" command.

To make sure Im clear, when I say 'delta' I mean that the sender sends 
only the information that is to be changed and not ALL of the information 
relevant to that entity (or a "full snapshot" of the entry according to 
the sender).  The example in Section 6.2.4.3 simply adds an attachment and 
thats NOT legal in iTIP.

I am 110% behind the "CAP must not break iTIP" mantra but we have some 
work to do to make this correct in all cases (where appropriate).

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 Feb 2002 16:14:36 -0700

[email-masked] wrote:

> only the information that is to be changed and not ALL of the
> information relevant to that entity (or a "full snapshot" of the entry
> according to the sender).  The example in Section 6.2.4.3 simply adds
> an attachment and thats NOT legal in iTIP.

True - but CAP is MORE than iTIP. The CU could add an attachment,
increment the SEQUENCE using MODIFY. Not an iTIP process. Then the
CUA could send out the updated object using iMIP.

A CUA could also modify an iTIP object. Consider iTIP processing.
The CUA could do some optimizing in its calendar and modify
an existing iTIP object into a merged result of any iTIP processing
done by the CUA. Until that object is sent over the wire, it does
not matter what the CUA does with it as long as the end result
is that over the wire objects (NON-local data) is the same as
the ORGANIZERs given the same UID, SEQUENCE, ... .

Another example, I get a REQUEST and accept it. The CUA could MODIFY
the METHOD from REQUEST to CREATE in the CS to mark it as booked. Not
an iTIP process on an iTIP object, but still valid CAP.

> work to do to make this correct in all cases (where appropriate).

Yes, many of the examples suck!

Until we get the document ready for pushing the next revision,
the examples should be considered flaky.

We need to somehow say that a the ORGANIZER's object is the
correct object (minus data marked local only). And a CUA
MUST NOT modify non-local data to objects where OWNER != ORGANIZER,
even in their own calendar - else it breaks iTIP.