Subject: CAP & Latency

From: [email-masked]
Date: Wed, 1 Dec 1999 13:42:59 -0500

After several chats in DC w/the CAP editors and others I think that one 
CAP requirement (http://www.imc.org/draft-ietf-calsch-capreq, see 4.2.4 
Exception Reporting) has not been addressed (yet?) or has been changed. In 
particular:

   CAP MUST provide a way to determine the results of delayed
   operations. Delayed operations arise from the use of other protocols
   (IMIP, IRIP), which may take a long time to resolve.

The 'flow' that was described to me in DC differs from this.  Here is the 
way it was described to me (Doug/Steve/Paul feel free to update my flow if 
I transcribe wrong):

(This is for the most basic case of CU1 inviting CU2 to a meeting.  Each 
is on a different CS.)

CUA1 sends a CAP request to CS1 that TARGETs both CU1s and CU2s calendar.
CS1 can perform the operation just fine for CU1 (and returns the proper 
reply) but it figures out/decides that it must use iTIP to reach the 
second TARGET (CU2).
CS1 would create the proper iTIP message for CS2 but it would have to 
rewrite the original request since the ATTENDEE values would be CAP 
addresses and not iTIP mailto addresses.
The iTIP message arrives @ CS2 and CU2 responds with his CUA.  However, 
CU2 will be sending back an iTIP (not CAP) message _and_ it will be going 
to a different address than the original request (since iTIP addresses are 
not CAP addresses the iTIP REPLY MUST go back to CU1s iTIP address instead 
of their CAP address).
CU1s MUA/CUA would see the iTIP REPLY and do "the proper thing" to get 
CU2s reply into CS1 via CAP.  CUA1 may be "smart enough" to know to 
reformat the iTIP message before its saves it into CS1 but it may not.  If 
not, CUA1 must first save the REPLY into CS1, query for it to retrieve it 
and then use CAP to remove it from the queue and update the actual entry 
w/the proper info (an additional set of I/O to CS1).  Now CU1 can use 
their CUA to see the status of CU2 by doing CAP queries against their 
"scheduling queue" (I forgot the drafts term for this new concept; do not 
apply mental baggate to this term!) or by reading the updated entry in the 
calendar.

This workflow is not the same as originally layed out in the CAP 
requirements.  Although I personally do not like this bit of hand waving 
for step #5 I would like to see what others think of this scenario.  Does 
the CAP draft need to be tightened up to better address the 'fall back' 
case over iTIP?  Do we need to revise the requirements to remove the cited 
one?  Is there some middle ground?

WRT the possible scenario where CS1 can use CAP to send the request to 
CS2, the flow is fairly straightforward.  The only issue that may be 
hanging out is dealing with operations that complete but the CUA issues an 
ABORT before the response is recieved and returned to them.  (We reached 
some closure on this in DC so it should be reflected in the next draft I 
hope.).

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 01 Dec 1999 11:52:39 -0800

[email-masked] wrote:

>   1. CUA1 sends a CAP request to CS1 that TARGETs both CU1s and CU2s calendar.
>   2. CS1 can perform the operation just fine for CU1 (and returns the proper
>   3. CS1 would create the proper iTIP message for CS2 but it would have to

If it knows them, else fail.

>   4. The iTIP message arrives @ CS2 and CU2 responds with his CUA.  However,
>      to a different address than the original request (since iTIP addresses
>      are not CAP addresses the iTIP REPLY MUST go back to CU1s iTIP address
>      instead of their CAP address).

Yes. However this is something we MUST be able to deal with. I may have
no way in advance to know if you have direct CAP access to my CS.
So I might have access to your CS, but you might not have access to my CS.
Different routes.

>   5. CU1s MUA/CUA would see the iTIP REPLY and do "the proper thing" to get
>      reformat the iTIP message before its saves it into CS1 but it may not.

Yes and No. That is the job of a CUA that talks CAP.
CAP can store unprocessed iTIP objects in the CS. That was the debate on
pending queue vs. marked as unprocessed debate. (scheduling queue).

>       If not, CUA1 must first save the REPLY into CS1, query for it to
>      retrieve it and then use CAP to remove it from the queue and update the
>      actual entry w/the proper info (an additional set of I/O to CS1).  Now
>      CU1 can use their CUA to see the status of CU2 by doing CAP queries
>      against their "scheduling queue" (I forgot the drafts term for this new
>      concept; do not apply mental baggate to this term!) or by reading the
>      updated entry in the calendar.
> 
>      case over iTIP?  Do we need to revise the requirements to remove the
>      cited one?  Is there some middle ground?

There are empty sections of iTIP in CAP. The reason it can not go away
(and I am sure there are more):

		CUA-1
	         |
		 |
		CS-1
		 |
		 |
		Company-1 firewall (no CAP access from outside)
		 ^
		 |
		 v
		Company-2 firewall (no CAP access from outside)
		 |
		 |
		CUA-2

When CUA-1 stores a component in CS-1, and invites the user at CUA-2
there are 2 options:

	1) CUA-1 uses iMIP to invite CUA-2 and CAP for CUA-1. This
	   requires a thicker client.

	2) CUA-1 uses CAP for CUA-1 and CUA-2 and the CS does the
	   work (if it can).

I think of this like EMAIL. I do not know your physical address.
My real intranet address is droyer@<some hidden host>.software.com.
Yet [email-masked] gets to me. Same issue. We have
not yet defined the methods for locating the information. We
just recognize that the problem exists and know that we are
going to have to deal with it. Just like in email, you
can not get to <some hidden host>.software.com.