iCalendar attachment may not be available in notification message

Another example of the multipart/alternative problem. We se

Fri, 08 Apr 2011 22:16:37 +0000

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.

If it's just the wording, we can replace it. Or is this stru

Fri, 08 Apr 2011 22:23:41 +0000

If it's just the wording, we can replace it. Or is this structure causing real-world problems?

Other than the fact that the iCalendar file won't show up as

Fri, 08 Apr 2011 22:31:25 +0000

Other than the fact that the iCalendar file won't show up as an attachment?

Since they are the most rich part of the multipart/alternati

Fri, 08 Apr 2011 22:51:49 +0000

Since they are the most rich part of the multipart/alternative message, they should show up, if the MUA supports it, right? If not, the user can't make much use of it anyway.

> Since they are the most rich part of the multipart/alterna

Fri, 08 Apr 2011 23:02:53 +0000

> Since they are the most rich part of the multipart/alternative > message, they should show up, if the MUA supports it, right? This is correct. > If not, the user can't make much use of it anyway. I don't agree with this statement. What if I receive an event notification and want to import it into a calendar not associated with my MUA program. For example, I want to import to a shared calendar on Google Calendar. It would be nice to be able to download the .ics file to upload to Google Calendar.

What structure do outlook and google calendar invites use? D

Sat, 09 Apr 2011 15:39:41 +0000

What structure do outlook and google calendar invites use? Do those programs, and programs like thunderbird, handle Michael's proposed structure gracefully?

> What structure do outlook and google calendar invites use?

Sat, 25 Jun 2011 16:45:27 +0000

> What structure do outlook and google calendar invites use? Do those > programs, and programs like thunderbird, handle Michael's proposed > structure gracefully? I've just received an iTip response the other from what identified itself as "Mozilla Calendar", and that did you use this structure (leaving out the multipart/related part with the html version). A bit awkward though was the fact that it used text/calendar for the iCalendar part inside the multipart/alternative part, but application/ics inside the multipart/mixed part.

This is what iCloud uses: 0 [multipart/mixed] [-] 1 [m

Tue, 01 Nov 2011 18:37:24 +0000

This is what iCloud uses: 0 [multipart/mixed] [-] 1 [multipart/alternative] [-] 1.1 [text/plain; charset=utf-8] 1.2 [text/html; charset=utf-8] 2 iCal-20111013-134128.ics [text/calendar]

Google: 0 [multipart/mixed] [-] 1 [multipart/alternati

Tue, 01 Nov 2011 19:35:10 +0000

Google: 0 [multipart/mixed] [-] 1 [multipart/alternative] [-] 1.1 [text/plain; charset=windows-1252] 1.2 [text/html; charset=windows-1252] 1.3 [text/calendar; charset=utf-8] 2 invite.ics [application/ics]

Lightning: 0 [multipart/mixed] [-] 1 [multipart/altern

Tue, 01 Nov 2011 19:44:33 +0000

Lightning: 0 [multipart/mixed] [-] 1 [multipart/alternative] [-] 1.1 [text/plain; charset=utf-8] 1.2 [text/calendar; charset=utf-8] 2 invite.ics [application/ics] And in Outlook-compatibility-mode: 1 [text/calendar; charset=utf-8]

Awesome, there aren't any two clients that do the same :) ca

Tue, 01 Nov 2011 19:46:25 +0000

Awesome, there aren't any two clients that do the same :) can somebody send me Outlook and iCal invites?

Outlook: 1 [text/calendar; charset=utf-8]

Wed, 02 Nov 2011 13:57:34 +0000

Outlook: 1 [text/calendar; charset=utf-8]

And finally iCal (which looks most broken of all): 0 [mul

Wed, 02 Nov 2011 14:13:50 +0000

And finally iCal (which looks most broken of all): 0 [multipart/alternative] [-] 1 [text/plain; charset=iso-8859-1] 2 [multipart/mixed] [-] 2.1 [text/html; charset=iso-8859-1] 2.2 iCal-20111102-100028.ics [text/calendar] 2.3 [text/html; charset=iso-8859-1]

Ben promised to do some cross-client tests to find out which

Wed, 30 Nov 2011 13:23:35 +0000

Ben promised to do some cross-client tests to find out which of those structures is most portable.

> Ben promised to do some cross-client tests to find out whi

Mon, 10 Sep 2012 14:41:21 +0000

> Ben promised to do some cross-client tests to find out which of those > structures is most portable. IMHO, the google method is the best: 0 [multipart/mixed] [-] 1 [multipart/alternative] [-] 1.1 [text/plain] 1.2 [text/html] 1.3 [text/calendar] 2 invite.ics [application/ics]

Changes have been made in Git (master): commit d94d32963740

Tue, 16 Oct 2012 16:46:51 +0000

Changes have been made in Git (master): commit d94d32963740fda3026fea230c2854a26dc35255 Author: Jan Schneider Date: Tue Oct 16 18:46:24 2012 +0200 [jan] Use more compatible message format for iTip notifications (Bug #9854). kronolith/docs/CHANGES | 1 + kronolith/lib/Kronolith.php | 13 +++++++++++-- kronolith/package.xml | 2 ++ 3 files changed, 14 insertions(+), 2 deletions(-) http://git.horde.org/horde-git/-/commit/d94d32963740fda3026fea230c2854a26dc35255

Changes have been made in Git (develop): commit d94d3296374

Sat, 27 Oct 2012 00:56:06 +0000

Changes have been made in Git (develop): commit d94d32963740fda3026fea230c2854a26dc35255 Author: Jan Schneider Date: Tue Oct 16 18:46:24 2012 +0200 [jan] Use more compatible message format for iTip notifications (Bug #9854). kronolith/docs/CHANGES | 1 + kronolith/lib/Kronolith.php | 13 +++++++++++-- kronolith/package.xml | 2 ++ 3 files changed, 14 insertions(+), 2 deletions(-) http://git.horde.org/horde-git/-/commit/d94d32963740fda3026fea230c2854a26dc35255