Tickets :: Comment on [#9854] iCalendar attachment may not be available in notification message

* Your Email Address
* Spam protection	Enter the letters below: _ _ _______ ___ _______ \| \| \| \|___ / \| \| \ \ / / ____\| \| \|__\| \| / /\| \|__\| \|\ \_/ / \| __ \| __ \| / / \| __ \| \ /\| \| \|_ \| \| \| \| \|/ /__\| \| \| \| \| \| \| \|__\| \| \|_\| \|_/_____\|_\| \|_\| \|_\| \_____\|
Comment	> Another example of the multipart/alternative problem. We send out > notification messages that look like this: > > multipart/alternative > text/plain > multipart/related > text/html > image/png > text/calendar > > The problem comes if a MUA does not know how to handle text/calendar. > Both the plain and html contains language about an attached > iCalendar file. But as discussed in other bugs, text/calendar, if it > can't be displayed, must NOT be shown as an attachment. > Multipart/alternative is only designed to provide different viewable > representations, it is not intended to be a container for > downloadable attachments. > > The proper way of doing this would be as follows: > > multipart/alternative > multipart/mixed > multipart/alternative > text/plain > multipart/related > text/html > image/png > text/calendar > text/calendar > > Yes - text/calendar is repeated twice. However, this is expected > (and necessary) behavior. > > A rarely used MIME type (message/external-body - RFC 1873) was > designed to solve such issues - it allows data to be defined in one > MIME part, and the data to be duplicated in other body parts by > reference to the first MIME part. But I'm not sure how many MUAs > support this.
Attachment
Watch this ticket