Bruce_Kahn@iris.com 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 > 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. If it knows them, else fail. > 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). 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 > 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. 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. > > 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? 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 Doug.Royer@Software.com 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.
begin:vcard n:Royer;Doug tel;pager:pager@royer.com or 650-274-8960 tel;cell:650-274-8960 tel;fax:805-957-1544 tel;work:805-957-1790 x541 x-mozilla-html:FALSE url:http://Royer.com/People/Doug org:Software.com version:2.1 email;internet:Doug.Royer@Software.com title:Architect adr;quoted-printable:;;530 E. Montecito St.=0D=0A;Santa Barbara;CA;93103;U.S.A fn:Doug Royer end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature