Re: CAP & Latency

[Bruce_Kahn@xxxxxxxx]

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

You misunderstood this point.  Because the request came in via iTIP instead of CAP, CU2 will NOT be responding (at least by my reading) to CU1 via CAP; he will be using iTIP instead since all the addresses he has are iTIP ones, NOT CAP ones.  This means the 'workflow' is hampered since if CU2 did have CAP access to CU1, it still could not use it.  Kinda like saying your fancy new car has 5 speeds but you can only drive it in 1st on the highway because the Exit ramp you want to get off of eventually only allows 25MPH...  Ugh.

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

Ok, I redid a quick scan of the archives and see no resolution on this.  Was one reached??


>There are empty sections of iTIP in CAP. The reason it can not go away
>(and I am sure there are more):
[Snip]
>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).

Case #1 is not addressable in CAP since its strictly a CUA design issue.  It has nothing to do with how the CS-1 or CS-2 in your diagram behave.  Its totally CUA-1 controlled w/no CS intervention.  My scenario dealt with your case #2 and with some of the 'vagueness' in the latest draft (and on some of the hallway converstations in DC).

>I think of this like EMAIL.

If eMail were totally selfcontained and did not use external meta information to target where it went then Id say I agree w/your 100%.  C&S is kind of like eMail but its more complex.

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

Not quite the same issue.  The issue of addressing SMTP based email to Doug.Royer@Software.com and having it delivered to droyer@<hidden host>.software.com is an issue of naming / aliasing at Software.com (for delivery) and your MUA (for sending).  This scenario is more akin to SMTP vs PROFS vs CEO mailing and having to deal with message conversion and fidelity preservation between them.  There are different address spaces between CAP and iTIP and the set of entities that can properly map between them is tiny (ie: my CUA and maybe my CS but not your CS!)

>We
>just recognize that the problem exists and know that we are
>going to have to deal with it.

Glad to see we have agreement on something... :^}  I wanted to see what others on the list think of this since we already talked briefly about this in DC.  So far, Id say they dont care or they are swapped out... 

WRT:
>>   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.

Even if it knows it, this makes the workflow process touch an go.  For instance, if the CS1 would rewrite the message in iTIP and use an iTIP address ON ITSELF that it could equate to CU1s 'scheduling queue' (or whatever the new term for that abstract concept is now) then we improve the workflow a bit. Yes, it implies that iTIP fanout might only happen on the originating CS but it improves the process.  This idea can be extended to other CS's but its not as pretty.  For example, CS3 gets the CAP request from CS1 and it has to rewrite it in iTIP.  If it were to rewrite the request so that iTIP replies came to it then there is still no guarantee that CS3 could use CAP to pass the reply back to CS1.  

However, w/in a given intranet it may be possible for a set of CS's (besides CS-1) to do this readdressing properly (ie: I have a cluster of mail servers) so perhaps we need some way to indicate from the "CUA" 'Fan this out if you know how to properly readdress CAP requests for user@mycompany.com'.  I put CUA in quotes since it indicates the role, not the originating CUA (ie: CS-1 is a CUA to CS-2, etc).  This is just an impromptu idea here but it could help...  Hmm.

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