CAP & Latency

[Bruce_Kahn@xxxxxxxx]

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

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 reply) but it figures out/decides that it must use iTIP to reach the second TARGET (CU2).
3. 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.
4. 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).
5. 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: Bruce_Kahn@iris.com
   Iris Associates                          Phone: 978.392.5335
   Westford, MA, USA 01886                    FAX: and nothing but the FAX...
   Standard disclaimers apply, even where prohibited by law...

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature