687063 - Calendar invitations don't show details

Status: RESOLVED DUPLICATE of bug 505024

(MailNews Core :: MIME, defect)

Description

[WBT]

Attachment: Message source of an example problematic invitation

When using IMAP to receive calendar invites sent via Outlook over an Exchange server, the details (such as date, time and place) are not shown.

Attached is a test case, copied out of View Source of an affected message, with some anonymizing modification that should preserve all technically important details.

In Thunderbird, I can see the message headers: the sender, recipient, and subject line, but the window where the message content would normally be displayed is blank.  There is no way for me to see the date, time, place, or details of the event invitation.

There are no "working" examples of calendar invites that I've received from this particular organization.  Most folks there use a relatively recent Outlook on desktop or web.  Calendar invites sent from Google Calendar are displayed as expected. 

Manual workaround: CTRL+U to View Source, copy out the base64 message body, manually decode that through a home-hacked base64 string decoder, read plaintext structure, extract details.

Flagged as critical per example of Bug 588373, which is less of a limitation than not even being able to SEE the details of a calendar invitation.  Correct both if that's wrong, but calendar invites from Outlook are not an unusual use case and should be handled well. 

I observed this in TB6 as well as TB3, and am currently running/testing on TB3 (because it allows me to import & export mail filters; TB6 regressed on that).

Comment 1

[Aki Sasaki (not active)]

This is also true of Zimbra invites. I'm using Daily (9.0a1) but IIRC this started happening before the rapid release process.

The old behavior was bug 342443, which was ugly but preferable imo since I could see the details in the text.

Comment 2

[Jim Porter (:squib)]

Is this with or without the Lightning add-on?

Comment 3

[Aki Sasaki (not active)]

With; will I see details without?

Comment 4

[Jim Porter (:squib)]

Probably not. I thought Lightning did something to support invites, though.

Comment 5

[John Hopkins (:jhopkins)]

I am running Thunderbird 7.0 beta 2 (Linux x86) and see this also: no meeting invite details.

Comment 6

[Jim Porter (:squib)]

This isn't actually a Lightning bug, since people who use an external calendar application (e.g. iCal) need a way to get at this data too. I'm guessing Lightning could benefit from this change too, since I'm not sure how/if they handle text/calendar subparts in mime/alternative objects.

Comment 7

[Mike Kaganski]

(In reply to Aki Sasaki [:aki] from comment #1)
> The old behavior was bug 342443, which was ugly but preferable imo since I
> could see the details in the text.

This is not a regression from "old behavoir"; the message from bug 342443 will most probably look the same in the current versions. The message attached to this bug is multipart/alternative, that has two alternative parts: text/plain with no text at all, and text/calendar with base64-encoded VCALENDAR. The message from the former bug contains only text/calendar part.

The proper behavior of a mail client when displaying a multipart/alternative MIME mail is to look for the most "advanced" alternative part that is supported by this application, and then display its contents, without displaying other alternatives. From the other hand, the proper way to _send_ a multipart/alternative message is to create the alternative parts in such a way that every such part would contain as much of the information as it is possible to represent using that part's format (see MIME specs). And the sending party that sent this bug's attachment apparently didn't follow this rule; it has inserted the empty text/plain part that happens to be the best match for TB that currently cannot handle text/calendar properly. If the sending application inserted some meaningful text there; or if it wouldn't send the text/plain at all - then TB would produce much better results: in first case, it would display the meaningful text properly, and in the second case, it would display text/calendar verbatim (at least you would be able to read it).

By the way, it's possible to manually edit the message source to convert it from multipart/alternative to text/calendar to produce the second alternative; this way, you will not need other base64 decoders - TB should do it for you.

That said, I agree that the text/calendar handling would be beneficial; however, as this is a specific type of messages, IMO its handling is barely suitable for TB: probably, Lightning (or some other module) should advertise its ability to handle text/calendar MIME type to the MIME core, so that handling of such parts would be redirected to those specialized modules. Those modules could, of course, develop some library for handling that type of messages, so that they could benefit from sharing the code.

Edit: I installed the Lightning extension, and everything is showing OK now. The message is displayed as it should, and I am even able to open the original VCALENDAR as attachment. So, I guess, the support for this message is OK (at least in TB 6.0.2 with Lightning 1.0b5). And anyway, the sending application violates the standard by sending a useless and misleading empty alternative part.

Comment 8

[Mike Kaganski]

By the way, Attachment 560548 [details] violates rfc822 in that it contains a line that is more than 998 characters long.

Comment 9

[Jim Porter (:squib)]

(In reply to Mike Kaganski from comment #7)
> The proper behavior of a mail client when displaying a multipart/alternative
> MIME mail is to look for the most "advanced" alternative part that is
> supported by this application, and then display its contents, without
> displaying other alternatives.

Sort of... it depends on how you read RFC 2046 and what you mean by "display". Depending on how you interpret the following, it could be acceptable to show multipart/alternative parts that Thunderbird doesn't directly handle as attachments:

  It may be the case that some user agents, if they can recognize more than one of the
  formats, will prefer to offer the user the choice of which format to view. ... What is
  most critical, however, is that the user not automatically be shown multiple versions of
  the same data.

Treating a text/calendar part as an attachment (not inline) would probably meet this requirement, but it all depends on how broadly you want to define "shown" in the last sentence.

More practically, even if the text/plain and text/html versions contained all the information that was stored in the text/calendar part, it would still be useful to show the text/calendar part to let people open it in an external application (iCal, Sunbird, etc).

Comment 10

[Mike Kaganski]

(In reply to Jim Porter (:squib) from comment #9)
Well, I agree that this is a sensible approach. However, I disagree that the current handling is a bug. It's simply that TB is unavare of this type, and as it is text/*, it correctly displays it as text (if there's no other alternatives). Ant the Lightning already does what you say: it shows the data in the message window _and_ allows to save it as attachment.

I think that, as the specialized extension exist, it's inappropriate to include a patrial handling for this in TB (at most, a note would be enough that would suggest to get this extension). Othervise, this would unnesesarily duplicate already existing functionality.

Comment 11

[Mike Kaganski]

If TB will allow to save any unknown type of body as an attachment, there should be a clear notice that informs the user that this isn't an attachment of the original message, but just an alternative representation of the body.

Probably, if such unknown-type part exists, a new bar should be shown at the bottom with a message describing this and the controls similar to attachments bar, where each such part and its MIME type would be listed.

Comment 12

[WBT]

(In reply to Mike Kaganski from comment #7)
> The proper way to _send_
> a multipart/alternative message is to create the alternative parts in such a
> way that every such part would contain as much of the information as it is
> possible to represent using that part's format (see MIME specs). And the
> sending party that sent this bug's attachment apparently didn't follow this
> rule; it has inserted the empty text/plain part that happens to be the best
> match for TB that currently cannot handle text/calendar properly. If the
> sending application inserted some meaningful text there; or if it wouldn't
> send the text/plain at all - then TB would produce much better results.
...
> And anyway, the sending
> application violates the standard by sending a useless and misleading empty
> alternative part.

(In reply to Mike Kaganski from comment #8)
> By the way, Attachment 560548 [details] violates rfc822 in that it contains
> a line that is more than 998 characters long.

The sending application is Microsoft Outlook.

(In reply to Aki Sasaki [:aki] from comment #1)
> This is also true of Zimbra invites. 

We may not like it, and MS or others might thumb its nose at standards, but it's in wide use.  If TB can't at least read invitations from Outlook, those of us who would prefer to use TB will have to switch over to Outlook in order to handle required workplace (or other organization) communications.  The workarounds noted here are OK for once in a great while for a technically advanced user, but not several times per day or for most users. 

(In reply to Mike Kaganski from comment #7)
> The proper behavior of a mail client when displaying a multipart/alternative
> MIME mail is to look for the most "advanced" alternative part that is
> supported by this application, and then display its contents, without
> displaying other alternatives. 

What about modifying that to say:
"... look for the most "advanced" *nonempty* alternative part that is supported by this application... "

Another (complementary) approach is to have buttons for each type included in the message, and clicking on the button will show you the other part. I think that is related to Mike Kaganski's suggestion in comment 11.

Comment 13

[Mike Kaganski]

(In reply to WBT from comment #12)
> The sending application is Microsoft Outlook.
:)

I didn't mean that this problem doesn't need a fix. A workaround here is indeed a must for an application that needs to compete with a (buggy) industry leader.

I just wanted to emphasize that this is, _strictly speaking_, not the TB bug. And simply fixing it isn't enough; it was the usual modus operandi several years ago when every IE glitch automatically became a de-facto "standard" that had to be addressed in every browser. However, you may see that this has changed when the alternatives became more prominent. Hopefully, when alternative time manager solutions will become stronger this will also happen to Outlook. Still, someone should at least file this bug to MS in addition to making changes to TB.

> What about modifying that to say:
> "... look for the most "advanced" *nonempty* alternative part that is
> supported by this application... "

Well, you may file your Request For Comments to IETF to make RFC 2046 obsolete :)

> Another (complementary) approach is to have buttons for each type included
> in the message, and clicking on the button will show you the other part. I
> think that is related to Mike Kaganski's suggestion in comment 11.

Yes, or at least "save to disk" those that it is unable to display. I believe this would give other advantages as well.

Comment 14

[WBT]

> By the way, it's possible to manually edit the message source to convert it
> from multipart/alternative to text/calendar to produce the second
> alternative; this way, you will not need other base64 decoders - TB should
> do it for you.

How do you do this?  I can only View Source, it's not letting me edit the source & save changes.

Decoding the base64 isn't all that helpful for recurring meetings; it looks like the readable fields show the first occurrence and I'm interested primarily in the next. 

Also, the text body contains the "DESCRIPTION" field of the calendar item, so it won't always be blank for this bug to still be just as much of an issue.

-WBT

Comment 15

[Mike Kaganski]

Well, you cannot do it this way. You need to save the message as .eml and then edit it using any plain text editor, then open in TB. (Yes, I understand that this is cumbersome.)

But why don't you use the Lightning capabilities? (I don't understand the comment #3 where :aki says that the same bad experience is with the Lightning; I can say the opposite: the offending message attached to this bug opens beautifully on TB 6.0.2 with Lightning 1.0b5, but if Lightning is disabled or absent, the symthoms you described in the first post are experienced.) Of course, the general enhancement of handling different body types (including unknown) is more than welcome, and I can understand a desire to avoid installing a redundant software (in case when another software is used and preferred), but you can treat this extension as just a workaround to extract this information, nothing more.