Subject: CAP issue: Fallback/fanout to iTIP

From: [email-masked] (Steve Mansour)
Date: Thu, 19 Jul 2001 09:59:21 -0700

- "Fallback/fanout to iTIP" concerns:

  If a CAP request must get turned into iTIP then some extra coding must
occur
  (ie: rewriting the proper ATTENDEE and ORGANIZER values from cap://...
to
  mailto:.. ).  Since this may happen anywhere down stream from the
  originating CS, it is not guaranteed that the mapping/rewrites are
accurate
  or correct; they are 'assumed' to be usable ("or the request is
bounced
  back.").  Unfortunately correctness is only positively done at the
starting
  point and not @ Yahoo on the way to Lotus. There are also cases like
signed
  or encrypted data that would prevent this from being either doable or
run
  the risk of voiding the signature. (from Bruce)

I think that, in general, it is too difficult of a problem for us to
provide instructions in CAP as to how a given implementation can
guarantee a correct mapping between an email address (a mailto: calid)
and a CAP calid. That responsibility lies at some point between a
messaging server and a calendar server and will likeley involve a
directory server. I think we should explicitly not attempt solve that
problem in CAP and leave this to implementations.

Thoughts on this?

-Steve

---

From: Martijn van Beers <[email-masked]>
Date: Thu, 19 Jul 2001 22:50:43 +0200

>   If a CAP request must get turned into iTIP then some extra coding must

Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of
this completely?

Martijn

---

From: [email-masked] (Steve Mansour)
Date: Thu, 19 Jul 2001 16:57:15 -0700

> Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of

yes. Sometimes we use those two interchangeably.  It should be something like
a CAP request gets translated into an iTIP equivalent and sent via iMIP.  But
I think you get the idea.

-Steve

---

From: Martijn van Beers <[email-masked]>
Date: Fri, 20 Jul 2001 02:08:58 +0200

> I think you get the idea.

Hmm, does that mean CAP scheduling messages aren't
(encapsulated) iTIP messages?

Martijn

---

From: [email-masked] (Steve Mansour)
Date: Sat, 28 Jul 2001 15:05:36 -0700

correction below...

Steve Mansour wrote:

> Martijn van Beers wrote:
>
>>On Sat, Jul 28, 2001 at 10:32:22AM -0700, Steve Mansour wrote:
>>
>>>Martijn van Beers wrote:
>>>
>>>...
>>>     BEGIN:VCOMMAND
>>>     METHOD:CREATE
>>>
>>... but to continue nit-picking, doesn't the CREATE here mean it's
>>a calendaring command instead of a scheduling command?
>>
> yep
>
>>>     TARGET:cap://a.b.com/sman
>>>     TARGET:mailto:[email-masked]
>>>      BEGIN:VEVENT
>>>      ...
>>>     ORGANIZER:cap://a.b.com/sman
>>>     ATTENDEE;<bla bla bla>:cap://a.b.com/sman
>>>     ATTENDEE;<bla bla bla>:mailto:[email-masked]
>>>     ...
>>>
>>>The intent of the the fanout capability in CAP is that when the target
>>>mailto:[email-masked] is processed, the CREATE method is automagically transformed into an iTIP REQUEST method and that the VEVENT information is transformed as needed to become a valid iTIP message.
>>>
>>
>>That sounds strange to me. CREATE is a command to put a component in
>>a calendar, while REQUEST is like asking if you're available, right?
>>How come they are considered to be interchangable then when the
>>message uses several transports?
>>
> Is everyone concerned yet?   REQUEST is the closest thing to in iTIP 
> to CREATE in CAP.  That's what I was saying in my earlier message. The 
> mapping is probably not going to work out in all cases. That's why I'm 
> scared of this. I do not consider the commands to be interchangable 
> between passports.

and, of course, by "passports" I mean "transports".
-Steve

---

From: [email-masked] (Steve Mansour)
Date: Sat, 28 Jul 2001 12:57:19 -0700

yep

>message uses several transports?
Is everyone concerned yet?   REQUEST is the closest thing to in iTIP to 
CREATE in CAP.  That's what I was saying in my earlier message. The 
mapping is probably not going to work out in all cases. That's why I'm 
scared of this. I do not consider the commands to be interchangable 
between passports.

-Steve

---

From: Martijn van Beers <[email-masked]>
Date: Sat, 28 Jul 2001 20:44:35 +0200

On Sat, Jul 28, 2001 at 10:32:22AM -0700, Steve Mansour wrote:
> I think the answer is "no, cap scheduling messages are not iTIP messages"
> but I'm not sure what you mean by "encapsulated".  The issue we're
I meant the "SENDDATA\n" and "\n.\n" bits around the actual MIME message

> talking about here involves a request that gets sent to a CAP server
> that has a mixture of cap addresses and mailto addresses in the
> attendee list.  For example:
Ok, I guess I should have found out what fan-out was before saying
anything, since I wasn't really talking in that context.

> mailto:[email-masked] is processed, the CREATE method is automagically
> transformed into an iTIP REQUEST method and that the VEVENT information is
> transformed as needed to become a valid iTIP message.

Martijn

---

From: [email-masked] (Steve Mansour)
Date: Sat, 28 Jul 2001 10:32:22 -0700

Sorry for the delayed response on this.  The day gig gets in the way sometimes.

Martijn van Beers wrote:

> > > > Shouldn't that be iMIP, not iTIP, or am I misunderstanding all of this
> completely?

I think the answer is "no, cap scheduling messages are not iTIP messages" but I'm
not sure what you mean by "encapsulated".  The issue we're talking about here
involves a request that gets sent to a CAP server that has a mixture of cap
addresses and mailto addresses in the attendee list.  For example:

     ...
     BEGIN:VCOMMAND
     METHOD:CREATE

     [ed note: if this sort of transformation doesn't make you nervous, it
     should. iTIP methods are not as rich as CAP's and I see big potential for
     the wrong thing to happen.  I'd be happy if we got rid of the notion of
     fanout altogether, but I'll go with the masses on this]

Anyway, back to the problem.  In order to send this component in an iTIP/iMIP
message, we have to transform all the calids into something iMIP-compatible. That
would be "mailto:" addresses. Now, how do you guarantee a transformation between
cap://a.b.com/sman and the appropriate "mailto:" address?  Without this
transformation, you can't produce a valid iMIP message.  Maybe someone has an
inspired idea to deal with this, but the recommendation is to leave this as an
exercise for the implementation.

-Steve

---

From: Martijn van Beers <[email-masked]>
Date: Sun, 29 Jul 2001 14:56:10 +0200

> and, of course, by "passports" I mean "transports".

Hrm. All of this implies that CREATE and the other calendaring
commands in CAP aren't going back into iTIP (or get their own
document). Are they really so tied to CAP?

And so far I've only heard Steve's opinion on fan-out. Could anyone
who was in favour of it speak up on why it is a good idea?

Martijn

---

From: [email-masked] (Steve Mansour)
Date: Sun, 29 Jul 2001 10:10:41 -0700

I'm interested in the opinion of others as well. Maybe someone can clear 
it up for me and make it seem like a workable idea.  Still, I have a 
couple of comments on your question below.
-Steve

>document). Are they really so tied to CAP?
note section 2.8 of the current cap draft. The model for thinking about 
this is shown in the diagram. Components that have been sent via iMIP 
are saved in the calstore with their METHOD value set to the iTIP METHOD 
value. That way, a client  can simply query on things like

SELECT * FROM VEVENT WHERE METHOD = 'REQUEST'

to find all the scheduling requests.  So, I think we're OK on finding 
things.

However, the is the concern is the following. We use TARGET to identify 
the calids. We use the VCOMMAND component to specify the action to apply 
to the targets. The possibility for problems comes up when the TARGET is 
a mailto calid (mailto:[email-masked], which means iMIP to me) and the 
VCOMMAND has no iTIP equivalent, such as READ.

>who was in favour of it speak up on why it is a good idea?
 From a pure *functionality* point of view, I think the desired 
functionality is great. A CUA does not have to concern itself with all 
the messy details of sending some create requests to a cap server, and 
some imip requests to individual mail recipients. It doesn't have to 
worry about the calendar address translations between cap and imip. It 
can send down one command and have the server take care of all this. 
 So, small devices that want to be CAP clients don't need a lot of fancy 
code to deal with all this. But this functionality seems to be problematic.

-Steve

---

From: John Stracke <[email-masked]>
Date: Mon, 30 Jul 2001 09:51:04 -0400

Steve Mansour wrote:

> Anyway, back to the problem.  In order to send this component in an 
> iTIP/iMIP message, we have to transform all the calids into something 
> iMIP-compatible. That would be "mailto:" addresses.

I think that's what CRISP was for: so you could use cap: addresses for 
everything, and iTIP messages could go over CAP instead of email.  (This 
could happen without CRISP; CRISP was just a way to set up a CAP server 
that just did iTIP, for security reasons.)

That doesn't answer the question of how to transform CREATE into 
REQUEST, though.

-- 
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |Dave Barry for President! He'll Keep Dan Quayle.|
[email-masked]|(OK, it's old)                                  |
\=================================================================/

---

From: George Babics <[email-masked]>
Date: Mon, 30 Jul 2001 09:52:19 -0400

I agree that it can be very useful from a functionality point
of view. It will save the CUA much trouble. However, we should
go through the exercise of making sure it can work. 

For instance, as mentioned earlier, can we properly map all the
CAP methods to all the iTIP methods?

CREATE & MODIFY        -> REQUEST
MODIFY (as attendee)   -> REPLY
MOVE entry             -> ?
MOVE calendar          -> ? nothing to do if email address of organizer stays the same?
DELETE calendar        -> send a CANCEL for each entry in the calendar
DELETE entry           -> send a CANCEL
READ                   -> ?

Some other issues. With CAP how can one send out a COUNTER,
or a request for free busy time to a user who only supports
iMIP? I'm sure there are many other similar questions.

George

Steve Mansour wrote:
> 
> I'm interested in the opinion of others as well. Maybe someone can clear it up for me and make it
> seem like a workable idea.  Still, I have a couple of comments on your question below.
> -Steve
> 
> Martijn van Beers wrote:
> 
> note section 2.8 of the current cap draft. The model for thinking about this is shown in the
> diagram. Components that have been sent via iMIP are saved in the calstore with their METHOD value
> set to the iTIP METHOD value. That way, a client  can simply query on things like
> 
> to find all the scheduling requests.  So, I think we're OK on finding things.
> 
> However, the is the concern is the following. We use TARGET to identify the calids. We use the
> VCOMMAND component to specify the action to apply to the targets. The possibility for problems
> comes up when the TARGET is a mailto calid (mailto:[email-masked], which means iMIP to me) and
> the VCOMMAND has no iTIP equivalent, such as READ.
> 
> From a pure *functionality* point of view, I think the desired functionality is great. A CUA does
> not have to concern itself with all the messy details of sending some create requests to a cap
> server, and some imip requests to individual mail recipients. It doesn't have to worry about the
> calendar address translations between cap and imip. It can send down one command and have the
> server take care of all this.  So, small devices that want to be CAP clients don't need a lot of
> fancy code to deal with all this. But this functionality seems to be problematic.
> 
> -Steve

---

From: [email-masked] (Steve Mansour)
Date: Mon, 30 Jul 2001 08:00:03 -0700

John Stracke wrote:

> everything, and iTIP messages could go over CAP instead of email.  
> (This could happen without CRISP; CRISP was just a way to set up a CAP 
> server that just did iTIP, for security reasons.)
>

So... any opinions on whether or not to try to keep fanout in CAP ?   
 John?    Anybody?

-Steve

---

From: John Stracke <[email-masked]>
Date: Mon, 30 Jul 2001 11:11:32 -0400

>CREATE & MODIFY        -> REQUEST
Almost certainly not.  What happens if I get a REQUEST by iMIP, my MUA 
passes it to my CUA, and the CUA tells the CS to CREATE it?

>DELETE entry           -> send a CANCEL
Possibly not--deleting an event from my CS does not necessarily imply 
anything about whether the event will take place.  For example, maybe 
I've got more than one CS.

I suspect it'll turn out that the only reliable way to do fanout is if 
the CUA actually talks iTIP to the CS, so there's no translation going on.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Until you stalk and overrun, you can't devour|
[email-masked]|anyone. --Hobbes                             |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Mon, 30 Jul 2001 16:30:49 -0400

> So... any opinions on whether or not to try to keep fanout in CAP ?   

Having just reread the fanout section in the I-D, I'd say cut it.  It 
doesn't introduce any truly new capabilities, and it does introduce some 
potentially serious security problems.  Either the servers trust each 
other, or the server doing fanout has to be able to exercise the user's 
credentials on the remote server.  Either way, it permits an attacker 
who subverts one server to use it against other servers, instead of 
limiting the damage to a single server.

-- 
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |There are footprints on the moon. No feet, just|
[email-masked]|footprints.                                    |
\================================================================/

---

From: [email-masked] (Steve Mansour)
Date: Mon, 30 Jul 2001 22:31:39 -0700

Alright John!  Any other opinions on this.  It's a pretty major change
(simplification) to CAP. I want to make sure that there's general buy-in
before doing anything.
-Steve