[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIME Multiple body parts (Was Re: uid...)
>1 - are we discussing a MULTIPART composed of iCalendar related objects?
>(some encrypted, some not perhaps?)
Only if we adopt Bruce's suggestion of having some fields encrypted and
others not (this could be done by the multipart/alternative approach I
>2 - are we discussing a MULTIPART composed of a text or text/html object
>an iCalendar object?
I think so. For example, it will probably be common to send a
multipart/mixed containing a text/plain and an text/calendar. (Less
common, because it's broken, is the approach taken by Microsoft Entourage:
a multipart/alternative containing first the text/calendar and then the
text/html. A recipient that understands text/html will never see the
>Also - if the iCalendar object has say an Attachment - are we considering
>allowing that ATTACHMENT to be bundled as part of the MULTIPART message,
>and/or for that ATTACHMENT to be encrypted in some manner?
Strictly speaking, it's permitted by RFC-2445; the ATTACH is specified by
a URL, so you can use a cid: to reference bodyparts. Whether a CAP server
would deal with it is another question.
As a practical matter, sending an iMIP message with a cid: attachment is
probably risky. It's easy for a recipient's MUA to take the text/calendar
and pass it off to the CUA for processing; but permitting the CUA to go
back to the MUA to resolve the cid: URL requires more integration. It'd
be trivial for an app that combines the CUA and the MUA (e.g., Evolution,
Outlook, Notes), but not for independent apps.
|John Stracke |Principal Engineer |
|jstracke@xxxxxxxxxxxxxxxxxxxx |Incentive Systems, Inc. |
|http://www.incentivesystems.com |My opinions are my own. |
|"The struggle is always worthwhile, if the end be worthwhile and|
|the means honorable; foreknowledge of defeat is not sufficient |
|reason to withdraw from the contest." -- Adron e'Kieron, by |
|Steven Brust |