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

From: [email-masked]
Date: Mon, 25 Feb 2002 14:30:24 -0500

Doug replied on 02/25/2002 01:45:39 PM:

> The text that explains how to do that is multiple pages long. In
> fact it is most of iTIP. As no one paragraph or section in iTIP
> explains how you do that. Do you have suggested text?

Not sure what verison of iTIP you are reading but my copy just has a ~1 
page text for Section 2.1.5 Message Sequencing.  If I take into account 
the text above it (p. 11) and the amount of text that flows onto p. 12 
then its just 1 page long...

In any case (praticing my self focusing) the point is that we do need some 
text to describe how a CAP CUA has to deal with sequencing; the proposal 
to omit _all_ the text is a bad idea. 

<DIGRESSION>
> Understanding iTIP is a MUST for a person reading CAP.
> Just point to the section(s).

This implicit requirement is not always adhered to judging by some of the 
discussions we've had round here.  Perhaps it should become part of the 
introduction along the lines of "It is assumed that the reader has some 
degree of familiarity with the iCalendar and iTIP RFCs (2445 and 2446 
respectively) in order for all design concepts to make sense."
</DIGRESSON>

> I guess I don't understand. It seems your example is 100% 
> iTIP scheduling requests or if your AA did the iTIP processing
> for you - then you just have to re-sync.

NO IT IS NOT.  My AA uses CAP to "schedule" the entrys everyones calendar. 
 She is NOT using iTIP to mail me the requests; she is using CAP.  She 
does NOT "book" them, I dont allow her to!  As such, this is different 
from using iTIP (ie: iMIP really) in that CAP is used to put the entry 
where my CUA finds it, NOT iTIP/iMIP. 

From my perspective as a CU they _SHOULD_ look the same but since only 
iTIP has any text to describe how my CUA should separate the latest from 
the rest the behaviour for CAP originating entries is unclear.

There is a distinction between booking and scheduling entrys.  Since its 
not valid design to say that all CUs who use CAP MUST be able to direct 
"book" me (ie: Actually put the entry on my calendar so that it blocks 
time, requires NO action on my part, etc) is not what we have; CAP MUST 
deal with sequencing of multiple scheduled entries that are awaiting my 
attention.

In any case, we are in agreement that text  _is_ necessary still; we just dont agree on the text or where it should be...

<DIGRESSION>
> First you have to get *all* updated objects where LAST-MODIFIED
> time > CUA's last sync time.

LAST-MODIFIED is the wrong property to use.  It should be DTSTAMP.  See 
RFC 2446, Section 2.1.5.

> > 'Older' entries are entries that created prior to the 'latest' one.
> >  That is, they have a DTSTAMP prior to the "most recent" copy of the
> > same event.  (Thats not just reving SEQUENCE, its also DTSTAMP.)
> >  Perhaps I should have used the term "older instance" or "previously
> > sent entries".
> 
> Your talking synchronization - not iTIP processing - correct?
> 
> So I think we agree.

Im NOT talking sync of any kind.  I just summarized and paraphrased part 
of RFC 2446, Section 2.1.5.  In any case, we agree that some sequencing 
text is appropriate for CAP and Bernards propsal to omit it is NOT good.
</DIGRESSION>

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 14:35:08 -0700

[email-masked] wrote:

> NO IT IS NOT.  My AA uses CAP to "schedule" the entrys everyones
> calendar.  She is NOT using iTIP to mail me the requests; she is using
> CAP.  She does NOT "book" them, I dont allow her to!  As such, this is
> different from using iTIP (ie: iMIP really) in that CAP is used to put
> the entry where my CUA finds it, NOT iTIP/iMIP.

I never said iMIP (She is NOT using iTIP to mail me the requests;), I
said iTIP.

She is doing iTIP, its just that the transport is CAP and not iMIP.
Her CUA would deposit the METHOD:REQUEST (or whatever) into
your CS to be processed by an OWNER CUA later - just as any
other iTIP object. Your CUA should never care if the iTIP
object came via iMIP, CAP, or whatever.

And if she has the VCARs for it, then she could do the iTIP
processing and deposit or modify any entries and book them.
If not, then she leaves iTIP objects in your CS for an OWNER
CUA to do the processing.

> iTIP has any text to describe how my CUA should separate the latest
> from the rest the behaviour for CAP originating entries is unclear.

I think the that examples show how to get iTIP objects out
of your CS. And we should say, once the CUA gets those
iTIP methods, process them just the same as if you got them
from any other iTIP source. If it were not, we broke iTIP.