[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
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
> 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
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
> 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 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
Messaging & Collaboration
IBM Software Group
FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...