Subject: Re: MIME encapsulation of multipart responses

From: Mark Davidson <[email-masked]>
Date: Tue, 10 Sep 2002 17:13:44 +0100

[email-masked] wrote:

> I will ask the same question again so that I hear the answer from those 
> that think multipart support is NOT necessary in CAP: How do you expect 
> to deal with ATTACHments and richer content renderings (ie: ALTREPs) if 
> you do NOT have multipart support in the protocol/engine?  (Will they 
> magically appear in my local CUA or will it have to download them using 
> some undocumented CAP command or OOB mechanism??)
> 

I must admit, that because there was nothing about this in the draft, I assumed that the CS just 
stored URIs or encoded attachments. But I did forget about ALTREP.

But I still don't think multipart it the way to go.

If we allow multipart/related with URIs pointing to attachments, then how do we get the data back 
out of the CS. If I do a search, then I just get objects and properties.

Either we need some commands for storing and retrieving attachments in the CS, or we change search 
to return multipart/related.

I would prefer some new commands and stick to text/icalendar as our command format.

Mark

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 12:42:32 -0400

Mark Davidson wrote:

> Either we need some commands for storing and retrieving attachments in 
> the CS,

...which would duplicate the functionality of WebDAV (RFC-2518).

Actually, that gives me an idea.  The problem Bruce and Doug have raised 
is that an iMIP-aware MUA which forwards text/calendar to a CAP CS needs 
some place to store attached non-text/calendar content.  Why not copy 
those body parts into a WebDAV repository, and rewrite the text/calendar 
that goes to the CS to use an http: URL?  Or, if the MUA is getting its 
mail from an IMAP server, it could rewrite the text/calendar to use an 
imap: URL.  Either way, the arbitrary MIME blobs would live in an actual 
MIME store, and the CS would be relieved of the burden of having to cope 
with them.

-- 
/=====================================================\
|John Stracke      [email-masked]            |
|Principal Engineer|http://www.centivinc.com          |
|Centiv            |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 10:52:22 -0600

Mark Davidson wrote:
> I must admit, that because there was nothing about this in the draft, I
> assumed that the CS just stored URIs or encoded attachments. But I did
> forget about ALTREP.
> 
> If we allow multipart/related with URIs pointing to attachments, then
> how do we get the data back out of the CS. If I do a search, then I
> just get objects and properties.

SELECT * FROM VEVENT where UID = 'a-id'

If it has inline attachments, they will be included. Where in
CAP did it say that we only allow for some valid iCalendar objects?
If your CUA could not support multipart, then you could not have
put it into the CS. If your CUA can not support multipart and
you contact a CS that is not yours, and the CS replies with
a multipart message, then the CU has two choices, live with the
error, or get another CUA.

ATTACHMENTS are part of iCalendar as is ALTREP. If a CUA/CS does
not wish to fully implement iCalendar - fine. But we can not
mandate that no CUA or CS can fully implement iCalendar.

> Either we need some commands for storing and retrieving attachments 
> in the CS, or we change search to return multipart/related.

No, an iCalendar object is the root of its tree. A CREATE, DELETE,
MODIFY, and VQUERY can work with any iCalendar object. What is
broken?

> I would prefer some new commands and stick to text/icalendar as our

Where in CAP do we limit iCalendar objects to no attach or altrep?
Do you want new commands that say CREATE-NOT-COMPLEX, ... ?

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Sep 2002 14:01:53 -0400

Doug Royer wrote:

>If it has inline attachments, they will be included.
>
Strawman alert: the question was about external attachments, not inline 
ones.

-- 
/===============================================================\
|John Stracke      [email-masked]                      |
|Principal Engineer|http://www.centivinc.com                    |
|Centiv            |My opinions are my own.                     |
|===============================================================|
|"Call me a Nervous Nellie, but I am concerned about the sale of|
|nuclear arms in my general neighborhood." -- Dave Barry        |
\===============================================================/

---

From: Doug Royer <[email-masked]>
Date: Tue, 10 Sep 2002 13:35:01 -0600

> Strawman alert: the question was about external attachments, not inline

No, it was about attachments inside the MIME multipart vs
inline in the same text/calendar.

Does anyone think that an attachment that is in another
MIME object (imap:, uri:, ...) should be inlined and
stored in the CS? I do not.

---

From: [email-masked]
Date: Tue, 10 Sep 2002 15:48:27 -0400

> stored URIs or encoded attachments. But I did forget about ALTREP.

Im glad that your (and possibly others) assumptions were noticed now 
rather than when we actually tried to code up CAP.  I know Im not immune 
either and Im sure others here will help keep me straight.

BTW: If the ATTACHments were just stored as URIs then it could be 
hard/impossible for someone on a different system to view the ATTACHment 
thats saved on my desktop.  I certainly wont open up my system to incoming 
requests for files and I know my company wont open up the firewall for 
Samsung users to get files from IBM users!  The ATTACHments should be with 
the entry in the MIME stream and the CS; the question is how they get here 
and how they are managed...

> But I still don't think multipart it the way to go.

ALTREP by definition implys multipart (and so does ATTACH).  If you dont 
allow for them you effectively remove those features from the standard.

> out of the CS. If I do a search, then I just get objects and properties.

If you dont request for the ATTACH propery back then you wouldnt get it. 
This may work for ATTACHments but it wont work for ALTREPs since we have 
no way to say "Give me the DESCRIPTION of propery but NO ALTREPs if you 
got 'em." 

As such if you had a richer rendering of the DESCRIPTION your data being 
sent to the CUA should be something like:

multipart/related
        text/calendar
                ...
                DESCRIPTION;ALTREP=CID:[email-masked]:CAP Design 
review\:
                ...
        text/html (Content-ID: [email-masked])
                <HTML><HEAD><TITLE>CAP Meeting</TITLE></HEAD><BODY><P><H1>
                CAP Design review:</H1>
                ...

One approach is to say, "No richer renderings" but that too is a big step 
backwards. 

Another approach is to separate the iCalendar message from the ATTACHment 
and ALTREP data and provide a means to send the data between the CUA and 
CS (bidirectionally). 

Another possible approach is agree that multipart is "a necessary evil and 
the scourge on our efforts" but that we can design CAP so that its 
supported correctly but not necessarily thrust down someones throat.

> to return multipart/related.

It is implicitly there already, its just not explicit nor is it clear. 
Thats one of my concerns. 

If you dont ask for the ATTACH property on your SEARCH, you certainly dont 
want/expect to get one back and the data will probably be just 
text/calendar (assuming no ALTREPs).  If you do ask for ATTACHments then 
you probably should get back some form of multipart...

Of course if your event has an alarm on it that you asked for and the 
alarm has a sound it should play you will probably get back multipart data 
there too...

> I would prefer some new commands and stick to text/icalendar as our 

While it may be simpler to consider new commands that do essentially the 
same thing but that allow multipart data, it effectively means that we 
create duplicate command sets with the sole disctinction being that one 
set is for text/calendar MIME data only and the other is for multipart 
data.  This is interop hell in the making ("My CUA only dues multipart 
data and my CS only does plain iCalendar but both say they are CAP 
complaint.  Why wont they work together???", "Why dont my Alarm sounds 
play?")

Since you still have ALTREPs and ATTACHments to worry about and see plenty 
of uncertainty about how to deal with them in CAP I think that if we try 
we can come up with a single and consistant approach that everyone can 
live with that wont make implementing and interop testing a nightmare.  A 
solution is not unreachable, its just not currently obvious...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Sep 2002 09:10:48 -0400

[email-masked] wrote:

> hard/impossible for someone on a different system to view the 
> ATTACHment thats saved on my desktop.

Strawman.  People already cope with this problem when writing HTML files.

> ALTREP by definition implys multipart (and so does ATTACH).

False.  From 2445, section 4.2:

     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
       Conference - - Las Vegas, NV, USA

And section 4.2.8:

      ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/
       agenda.doc

So, clearly, both ALTREP and ATTACH are useful without multipart.

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Brought to you by the letter Q.            |
\===========================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 11 Sep 2002 09:07:16 -0400

>inline in the same text/calendar.
That is what I meant--external to the text/calendar.