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

From: [email-masked]
Date: Fri, 22 Feb 2002 15:47:23 -0500

Doug replied:
> >    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. 

iTIP has to deal with the possibility that messages will arrive out of 
order due to its mulitple bindings (ie: iMIP).  However since CAP is NOT a 
binding of iTIP you are going to need to have some text in CAP that is the 
CAP equivalent of Section 2.1.5 Message Sequencing of iTIP.

Since I strongly doubt that you implicitly expect a scheduling CUA to be 
able to remove 'older' entries (right!?),  the receiving CUA MUST have 
some guidance on how it should sort out multiple instances of the same CAP 
request.

This is even more critical if CUAs are going to be allowed to do 'partial' 
processing of the scheduled entries (as the text near the bottom of 6.3.2 
seems to imply)!

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: Fri, 22 Feb 2002 14:33:54 -0700

> Not to rain on anyones parade but I think some text may still be in

Yes. But not of the magnitude that was in the draft. I think
is all we have to do is say something like that the CS may have
iTIP messages that the CUA will have to process, refer to iTIP
for how to process them. PLUS

	o Take the result and store/modify it as METHOD:CREATE
	  in the CS.

 	o And the CUA MUST preserve any un-processable objects in
	  the CS so when the rest of any out of order objects arrive,
	  the CUA can process them using iTIP rules.

> iTIP has to deal with the possibility that messages will arrive out
> of order due to its mulitple bindings (ie: iMIP).  However since CAP
> is NOT a binding of iTIP you are going to need to have some text in
> CAP that is the CAP equivalent of Section 2.1.5 Message Sequencing
> of iTIP. 

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.

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

> ... the receiving CUA MUST have some guidance on how it should sort
> out multiple instances of the same CAP request. 

> This is even more critical if CUAs are going to be allowed to
> do 'partial' processing of the scheduled entries (as the text near
> the bottom of 6.3.2 seems to imply)!

Yes - more like a bad example. We need to go over the examples
more closely.