[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MIME encapsulation of multipart responses


Mark Davidson <markd@xxxxxxxxxxxxxxxxxx> wrote on 09/10/2002 12:13:44 PM:
> 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.
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.

> 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.
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:12345.DESC@xxxxxxx:CAP Design review\:
                ...
        text/html (Content-ID: 12345.DESC@xxxxxxx)
                <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.

> Either we need some commands for storing and retrieving attachments
> in the CS, or we change search
> 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
> command format.
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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...