Subject: Re: CAP & Latency

From: [email-masked]
Date: Mon, 27 Dec 1999 19:49:19 -0500

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 [email-masked] gets to me. Same issue.

Not quite the same issue.  The issue of addressing SMTP based email to 
[email-masked] 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 
[email-masked]'.  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: [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: [email-masked]
Date: Wed, 29 Dec 1999 17:55:07 -0500

Paul replied in part with:
>Existing examples of this include large corporations which service their 
internet
>mail through a large gateway mail machine and don't want the outside 
world to
>know the names of internal machines and consider it a service so that
>others don't have to keep track if someone moves machines within a 
company.
>
>They also can provide the mapping from "droyer" to the more readable 
"Doug.Royer"
>on the outgoing address.

There is one slight difference I think you may have overlooked.  They 
rewrite meta information NOT the acutal data.  If they rewrote the actual 
data it would blow signed emails and be totally impossible in the 
encrypted data case.

In CAP and iCalendar we do not have the concept of unencapsulated data; 
all iCalendar/CAP messages are 'self contained'.  There are good reasons 
for this (ie: Clipboard copy/paste).  There are also drawbacks to this 
(the CS cannot make simple rewrites w/o mucking w/the data itself).

Another subtle difference is that the rewritting server belongs to the 
same 'domain' that Doug does.  You wont find, say, myriad.com rewriting 
Dougs software.com address!  In Dougs diagram, CS-1 is doing the rewrite 
for CUA-1.  However in the CAP case, it could be CS-2 (or an intermediate 
CS-1.5) that does the CAP->iTIP conversion and and such CANNOT do a 
rewrite safely!  (Assuming CS-1 didnt do a rewrite already that is).

All this digresses though from the base issue I originally raised: The 
'fallback' from CAP to iTIP case has some handwaiving that needs to be 
cleared up.  As Doug already noted, there are still areas that need 
fleshing out still.  This is one of them.

Bruce