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

From: [email-masked]
Date: Mon, 25 Feb 2002 11:37:27 -0500

Doug replied on 02/22/2002 04:33:54 PM:
> > > >    iTIP already addresses the order in which scheduled components
> > > > should be processed. We should remove the text.
> > >
> > > I agree.
> > 
> > Not to rain on anyones parade but I think some text may still be in
> > order.
> 
> Yes. But not of the magnitude that was in the draft. 

I guess I misread your "I agree" to mean that you also wanted to remove 
the text as Bernard had proposed.  Glad to see that I was wrong.

I think we should not rely on just saying "Go read Section x.x.x of iTIP 
on sequencing AND then also do...".  I would suggest that we directly 
include the full text we want in CAP so that its centralized and easily 
found.  It also allows us to make sure we have no disjoins between what 
appears in iTIP and what may change for CAP.

> The CS should care less about message sequencing. The CUA that
> fetches the un-processed iTIP messages is going to care, and
> at that point - they can be treated exactly like iTIP from iMIP.

Its NOT just unprocessed iTIP messages, there can also be multiple 
unprocessed CAP scheduled requests waiting for the CUA.  Its not illogical 
to expect that between the time I re/check my CS that someone may send 
more than 1 CAP request for the same event.  For example, Im out sick for 
1 day and in the mean time the AA for my boss has had to reschedule a team 
meeting 4 times.  When I come back in the next day, my CUA is going to 
have to have some consistant way of dealing w/the scheduled requests 
(preferably it would 'know' to ignore all but the "most recenty" or some 
other such stuff).  Right?

Or are you implicitly assuming that the CS will filter out 'less than 
current' requests so they never show up??

> > Since I strongly doubt that you implicitly expect a scheduling CUA
> > to be able to remove 'older' entries (right!?), ...
> 
> I don't follow "'older' entries". 

'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".

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 11:45:39 -0700

[email-masked] wrote:

> I think we should not rely on just saying "Go read Section x.x.x of
> iTIP on sequencing AND then also do...".  I would suggest that we
> directly include the full text we want in CAP so that its centralized
> and easily found.  It also allows us to make sure we have no disjoins
> between what appears in iTIP and what may change for CAP. 

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?

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

> unprocessed CAP scheduled requests waiting for the CUA.  Its not
> illogical to expect that between the time I re/check my CS that
> someone may send more than 1 CAP request for the same event.  For
> example, Im out sick for 1 day and in the mean time the AA for my boss
> has had to reschedule a team meeting 4 times.  When I come back in the
> next day, my CUA is going to have to have some consistant way of
> dealing w/the scheduled requests (preferably it would 'know' to ignore
> all but the "most recenty" or some other such stuff).  Right?

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.

We are separating iTIP processing from synchronization.

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

Then update older booked entries with the newer ones in both
the CS and CUA.

Then you can process any iTIP requests.

If you don't do it in that order you have a mess that might
not be fixable without asking for a REFRESH.

> current' requests so they never show up??

No. I call anything that does that for you a 'CUA-bot' and
it would have to follow the same rules as any other CUA.

> '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.