377761 - Outlook 200x does not recognize iTIP/iMIP invitation because of MIME type issues

Status: VERIFIED FIXED

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Description

[klint]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Lightning 2007041406

iMiP/iTiP invitations generated by Lightning are not recognized by Outlook 2003 due to mail MIME structure. It may be specific to Outlook 2003, but I think we need to be able to send proper invitations to the stilllarge installed base of OL 2003! 

Reproducible: Always

Steps to Reproduce:
1.Create an event in Lighting on a local iCAL calendar
2.Save the event, then edit it and add attendees using OL 2003, and send invitations to them.
3.Open OL 2003 as one of the attendees
4. Look at the invitation
Actual Results:  
The invitation appears in OL 2003 as a *message* in the list of messages.
Opening the message will display a mail with an attachment.
Clicking on the invitation will open the calendar window, but all buttons are inactive.
==> No way to add the event to the calendar

Expected Results:  
The invitation should appear in OL 2003 as a *calendar event* in the list of messages.
Opening the message should display a calendar event with Accept/Decline button.
Then, when clicking on "Accept", the event is added to the calendar

My findings so far are related to the way the mail body is structured, and are as follows :

- Outlook 2003 will not recognize a VCALENDAR part where there is a Content-Disposition parameter. 
Currently, the following is generated by Lightning :

Content-Type: text/calendar; method=REQUEST;
 name="calendar.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="calendar.ics"

Removing the Content-Dispositions seems to be needed by Outlook 2003.

- In addition to the above, it appears that the text/calendar part of the mail (containing the VCALENDAR object) must :
- either be alone in the mail (no multipart)
- or, in case of a *multipart/mixed* MIME message, it must be embedded in its own *multipart/alternative* part (as a part of the global multipart/mixed structure)


If this is not clear enough, I have examples that I will add as attachment to the bug.

Comment 1

[klint]

Attachment: Sample of a NOK mail body generated by LTG, with MLT/MIXED

Comment 2

[klint]

Attachment: Sample of an OK mail body generated by LTG, with MLT/MIXED+ALTERNATIVE

Comment 3

[klint]

Attachment: Sample of an OK mail body generated by LTG, with MLT/ALTERNATIVE only

Comment 4

[klint]

One last comments : I have checked at Google Calendar, and the invitations they send do embed the text/calendar part in a multipart/alternative structure.

Comment 5

[klint]

Attachment: Sample of an OK mail body, updated manually, with MLT/MIXED+ALTERNATIVE

Sorry, the description of the attachment was wrong.
By the way, it seems that in case of this structure, a MP/MIXED containing a MP/ALTERNATIVE containing a text/calendar, there must be no other text element in the MP/MIXED (but apparently, a "application/ics" is ok, as in Google Calendar invitations).

Comment 6

[klint]

Attachment: Sample of an OK mail body, updated manually, with MLT/ALTERNATIVE only

Sorry, wrong description in the attachement.

Comment 7

[klint]

Attachment: Screenshoot showing good and wrong behaviour

It's in French, but pretty self-understanding anyway !!

Comment 8

[Stefan Sitter [:ssitter]]

What Thunderbird version was used to create the iTIP/iMIP invitation?

Comment 9

[cmtalbert]

I can confirm this with Thunderbird 2.0pre (20070417) on Windows and Lightning (2007041704).

Thanks for the initial research on the types of mime bits that Outlook prefers.  I think this may be broader than just Outlook 2003, I think this also applies to Outlook 2000, 2002, and 2007. I'm going to change the summary to reflect that.

Comment 10

[klint]

I used Thunderbird/2.0.0.0 ID:2007032620.
You're welcome, for the research :) Glad I could contribute.

Comment 11

[klint]

By the way, bug 377641 (missing UID) has just been marked as a blocker for 0.5
Don't you think this one also should be on the release path ? Even if it will now be recognized as a calendar attachment thanks to the UID bug, this one makes the invitation quite useless at least on my OL 2003 install, as I can't add it to the calendar ! Thanks for considering this option.

(I'll be offline for a couple of days :) May the Force, or whatever, be with you for the last run to the release)

Comment 12

[Bas van den Bosch]

Can't confirm this with outlook 2000, even though there's a content-disposition sending invites and accepting them works. The confirmation of accepting can't be processed in lightning (this has to be added still I guess). See screenshot. Outlook 2000 doesn't support subscribing to ics like you did in step 2? 

Comment 13

[Bas van den Bosch]

Attachment: receiving invent in outlook2000

Comment 15

[klint]

(In reply to comment #12)
> Outlook 2000 doesn't support subscribing to ics like you did in step 2? 
> 

Hello Bas

I'm sorry, I did not get your last question ! Could you please reword it ? Thanks a lot.

I have a few remarks to add :

- My initial "Step 2" should be rephrased as follows, to avoid misunderstanding :
"2.Save the event, then edit it and add attendees WHO ARE using OL 2003, and send invitations to them. THIS OPERATION HAS TO BE DONE IN LIGHTNING, NOT IN OL 2003, of course"
By the way, in the latest builds, you can directly do that when you create the event (no need anymore to save and edit the event)

- There are actually 2 behaviours (see https://bugzilla.mozilla.org/attachment.cgi?id=261801) :
+ either the invitation is displayed as a *calendar event* (not as an email), with an "Accept" button in the header (which is the case with OL 2003 only if the content-disposition is correct)
+ or the invitation  is displayed as an *email*, with an calendar entry as an attachment (which is the case with OL 2003 if the content-disposition is incorrect, which is the case at the moment). Clicking on the attachment should open a calendar popup window with "Accept" button (like in the attachment in comment #13 for instance with OL 2000)

I do have an additional issue, which seems to be linked to the OL 2003 installation at my company : so, we still are in the second case, but when I click on the calendar attachment, the calendar pop up opens and says "the event is unknown", and all "Accept" and other buttons are inactive.
Note that this bad behaviour, *which makes the invitation pretty unusable*, is not happening on every OL 2003 installations, as reported in the Calendar forum.

Comment 16

[Bas van den Bosch]

First part is understood now, thought you meant editing the event in OL2003...

What happens when you open the message with the attachment, not using the preview and not opening the attachment? (there's another bug for this) When I did that outlook was showing the accept/decline-buttons. When I looked at the preview it wasn't and doubleclicking the attachment doesn't work yet...

Comment 17

[klint]

Attachment: Test result in OL 2003

Bas,
Here are the results you are asking  :
1) Previewing the message : no cal. buttons
2) Double clicking on the message to open it : no cal. buttons
3) Double clicking on the attachment to open it : cal. buttons are there, but inactive !

None of these cases is fine : previewing or displaying the message should interpret the attachment as an even and display buttons ; the icon in the message list on the left should be a calendar one ; and the ICS attachment should even not appear in the message

Comment 18

[Grant Basharm]

I tested the 20070501 lightning.xpi on thunderbird 2.0.0.3 on Linux (RHEL5) and Windows (XPsp2).  I sent invitations to Outlook 2003(SP2) and Outlook 2007.  For all combinations I was able to double-click the calendar.ics attachment, get the meeting window, have active accept/decline buttons, and have the event added to the outlook calendar on acceptance.  My Outlook users have a hard time with the idea of having to double-click the attachment to process it as a meeting.  They are used to having the meeting window open when it is a meeting invitation.  It would be really nice to have this open automatically in Outlook as a part of 0.5.

Comment 21

[Simon Paquet [:sipaq]]

IMO this should be fixed in the 0.7 timeframe.

Comment 22

[Simon Paquet [:sipaq]]

Clint, we should really try to fix this before 0.7. Can you foresee yourself fixing that in the coming weeks?

If yes, can you please assign this bug to yourself and mark it as blocking0.7+

Comment 23

[cmtalbert]

Yes, I want to fix this for 0.7.  The only caveat here is that it may require a Mime level change, and if that happens, it will only work on trunk.  But, I will see what I can do.  I'll cross fingers (about the mime level) and take this bug.

Comment 24

[Willie]

Clint, is there a way that I can help?

Comment 25

[cmtalbert]

(In reply to comment #24)
> Clint, is there a way that I can help?
> 
Certainly!  Thanks for the interest.  This is the function that creates the email: http://mxr.mozilla.org/mozilla1.8/source/calendar/itip/calItipEmailTransport.js#185

You can see that we merely use the mailnews interfaces to create the Mime Encoding wrapper.  If you'd like to research those interfaces and determine if we can create something that Outlook will recognize.  It would be good to determine if we can generate the types of Mime wrappers using Multipart/Alternative as discussed above.  You may need to ping mscott and/or bienvenue on IRC (they are the primary Thunderbird developers) to get more information.

Feel free to document the results of your research here in this bug, or submit a patch if you feel comfortable enough with that.

Thanks again for the help!!

Comment 26

[Willie]

I've been looking around some in the code -- boy, it's confusing for someone to look at.  It's nice to have that cross-linked database though.

Anyway, I did some tests on my own and found this:
1) I sent an invitation from Lightning 0.5 (older version) to Outlook 2003 -- didn't work (meaning Outlook didn't show the Accept/Reject buttons).  For each of the following tests, I reverted to the original first.
2) Changing the Content-Type of the .ics attachment to application/calendar did not fix it.
3) Changing the Content-Disposition line from inline to attachment did not fix it.
4) Removing the Content-Disposition line did not fix it (seems a little different than described above).
5) Changing the Content-Type (of the entire message) from multipart/mixed to multipart/alternative caused the file to be recognized automatically by Outlook -- although Outlook ignored any other text in the message.
6) Added a multipart/alternative section inside of the multipart/mixed had the same result as #5: the .ics file works but lose the text message with it

Some thoughts: I'm not sure if Outlook ever shows a message with an invitation.  An invitation created with Outlook is simply a Content-Type: text/calendar --- there is no attachment and it is not multipart.  Is that the way to go?

Comment 27

[klint]

The invitations my Outlook 2003 is generating are not simply text/calendar, but multipart/alternative, with a text/plain, a text/html and a text/calendar entry.


Let's take the following example at the end of this post.
It is a invitation generated by Litghning 0.5 where I have done the following simple changes (you can test it against your own install) :
- alternative instead of mixed, for the global content
- I have updated manually the description : there is a different value within the text/html part and the EVENT block in the text/calendar.

The result is :
- displayed as an event in Thunderbird, showing the VEVENT description
- displayed as an event in Outlook, showing the HTML description

So, if we put the same values (the description) ih the HTML and in the VEVENT blocks, wouldn't it be ok ?

By the way, Thunderbird behaves better than Outlook : as it is an ALTERNATIVE composite contents, parts should exclude themselves. Showing data taken from the text/calendar only, but not from different parts as OL does.


Can you check all that on your end too ? Thanks

Olivier



From - Tue Apr 17 11:49:23 2007
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Message-ID: <[e-mail]>
Date: Tue, 17 Apr 2007 11:44:35 +0200
From: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To:  [e-mail]
Subject: Invit Lightning NOK
Content-Type: multipart/alternative;
 boundary="------------030407030103060707090007"
Return-Path: [e-mail]
X-OriginalArrivalTime: 17 Apr 2007 09:44:31.0264 (UTC) FILETIME=[FF93B200:01C780D4]

This is a multi-part message in MIME format.
--------------030407030103060707090007
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[e-mail] has invited you to test lighnting
description within HTML block

--------------030407030103060707090007
Content-Type: text/calendar; method=REQUEST;
 name="calendar.ics"
Content-Transfer-Encoding: 7bit

BEGIN:VCALENDAR
PRODID:-//Mozilla Calendar//NONSGML Sunbird//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:/mozilla.org/20070129_1/Europe/Paris
X-LIC-LOCATION:Europe/Paris
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20070417T094408Z
LAST-MODIFIED:20070417T094431Z
DTSTAMP:20070417T094431Z
UID:71d47efc-1cfd-405f-8236-a77d59c7e912
SUMMARY:test lighnting
DESCRIPTION:description within EVENT block
PRIORITY:0
CLASS:PUBLIC
ORGANIZER;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT:mailto:[e-mail]
ATTENDEE;RSVP=true;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:[e-mail]
DTSTART;TZID=/mozilla.org/20070129_1/Europe/Paris:20070418T083000
DTEND;TZID=/mozilla.org/20070129_1/Europe/Paris:20070418T093000
SEQUENCE:1
X-MOZ-SEND-INVITATIONS:TRUE
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Mozilla Alarm: test lighnting
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR

--------------030407030103060707090007--

Comment 28

[klint]

Hello
I'm coming back to this issue with a last (?? :( ) question.
If the solution was to generate an alternative multipart or even a simple text/calendar monopart, will the compose window from TB that is called by Lightning be able to generate such format ?
or should the invitation message be generated automatically by Lightning (based on the info of the invitation only, including the description of course) and sent to the outbox directly ? I suppose this is the way it works when the calendar server is sending the invites (like Google Calendar) ; even my Outlook works that way.
 
or maybe depending on a setting, the user could choose the behaviour....

But this would go far beyond this bug !
And I still hope my initial question is irrelevant :) !

Thanks

Comment 29

[Willie]

(Disclaimer that all the information below is AFAIK -- which isn't much)

I guess that is maybe some of the problem.  Lightning seems to generate some of the fields for the compose window (who the invite is to, what the subject is, creates the .ics attachment, etc) but then it opens the compose window -- and it isn't Lightning's problem any longer.  Instead, the compose window is in charge of deciding the MIME types, etc.

So, perhaps there is a way to inform the compose window of what MIME type it should use (although I kind of doubt it).

Or, perhaps we could skip the compose window altogether (like some other clients) and it sends a basic invitation using the Title, Location, Description, and URL fields.  I assume that way Lightning could maintain control over the invite message.  Somehow that sounds easier than modifying the Compose window code, but I'm not for certain about that.

What do others think?

Comment 30

[klint]

I think that we may run into similar troubles with other calendar apps than Outlook regarding the MIME format. If you look at the format of invites generated by Google Calendar, it is quite complex, and likely they had to face the same issues as discussed here. Maybe this complexity is the result of their search of being compliant with various calendar apps.

That's why, IMHO, Lightning itself should be in charge of accurately formating the invite, and not the compose window, which Lightning has no grasp on.

Of course, I must display the same disclaimer as Willie above, this is AFAIK, which is even less than him ;)

Comment 31

[cmtalbert]

We do set the mime type direction in the Lightning code here:
http://mxr.mozilla.org/mozilla1.8/source/calendar/itip/calItipEmailTransport.js#206

As you can see we are directing it to use multipart alternative.  But, the compose window could be overriding us, which is certainly something to research.  The current code does have the ability to send without using the compose window.  To enable that functionality, you'll need to change this line:
http://mxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/imip-bar.js#82
to: itipItem.autoResponse = Components.interfaces.calIItipItem.AUTO;

The questions about whether we send the email automatically or allow the user to edit the message before sending is being tracked in bug 377403.

I plan to work on a patch for this at some point this week.  What types of Outlook do you have available for testing?  Ideally, I'd like to test this with Outlook 2000, 2003 and 2007.  I think I can download a trial version of 2007 to test with, but I'm not sure if I can get my hands on 2000 or 2003 since those are old and probably no longer supported/downloadable from Microsoft.

Comment 32

[Bas van den Bosch]

I have outlook 2000 running and could install 2003 though I assume Klint will be more help there... mail me at [e-mail] (feel like a contact-ad here...)

Comment 33

[klint]

I am ready to do any test on OL2003 until Friday eve (CET time).

But how can we send these invite mails from the current 0.7pre builds as this capability has temporarily been removed since the new event dialog was moved there (Bug 377403) ?

Comment 34

[cmtalbert]

Guys, I appreciate the responses.  I have an emergency that I have to attend to, and will be offline until Thursday.  Hopefully I can work out a patch on thursday for testing. WRT the dialog, I'll work out a test build that will address that issue.

Comment 35

[cmtalbert]

I have been consumed by many issues since August, not the least of which is the giant timezone bug 314339 which has been eating my lunch for a while.  So, I am unfortunately not going to get to this before our cut off date for 0.7.

If anyone can help here...please please come forward.  I really want to get this done, but there is only so much one person can do. :-(

Until we have a solid assignee, we're moving this back to "?" blocking status.

Comment 36

[Pete Riley]

(In reply to comment #31)
> The current code does have the ability to send without using the
> compose window.  To enable that functionality, you'll need to change this line:
> http://mxr.mozilla.org/mozilla1.8/source/calendar/lightning/content/imip-bar.js#82
> to: itipItem.autoResponse = Components.interfaces.calIItipItem.AUTO;

I changed the referenced line and restarted Thunderbird, but I still see the composition window after I create a new event.  Thus I'm not able to successfully test iMIP from Lightning to Outlook.

(I'm using the latest Lightning nightly and TB 2.0.0.6)

Comment 37

[Pete Riley]

Okay, I searched for 'Components.interfaces.calIItipItem' in the source code and discovered a second file (calendar-item-editing.js) where I changed USER to AUTO.  Restarted Thunderbird.

1) The invitation was sent without opening the composition window (good).

2) Unfortunately it was still sent with "Content-Type: multipart/mixed;" instead of multipart/alternative.

3) The procedure hosed Lightning/Thunderbird.
Calendar Mode ignored my mouse clicks.  I switched to Mail Mode and could click mailboxes, but nothing happened.  In the status bar it said, "Loading Message..." forever.  There was an hourglass.  I had to kill Thunderbird and restart it to recover.

4) It would be nice to have some kind of visual feedback when we send iMIP emails.  Maybe a progress meter or maybe simply some messages in the status bar for a few seconds that say, "Sending invitation..." and "Successfully sent invitation" or something like that.

Comment 38

[klint]

(In reply to comment #37)

I can confirm that I obtained the same results as Pete, for all topics 1) to 3).

I haven't tested by I suppose that the imap-bar.js is being used to send the answer to a received invitation, while the calendar-item-editing.js is used to send the invitation itself.

For topic 3 actually, my TB at home does not hang while TB at work does; the main difference between both TB is that at work, I get my mail via IMAP, while I only use POP at home. Not sure though it's related !

Comment 39

[Pete Riley]

Unfortunately I don't use IMAP so it seems to me that that might not be the cause.  Plus I tested everything in a clean profile so the problem does not seem to be specific to any of my settings or extensions.

When I click the "Save & Close" button, Thunderbird crashes sometimes.  Windows says "this program has a problem and needs to close".  Other times it behaves as I previously reported (it hangs but doesn't crash).  Lightning/Thunderbird successfully save the event and send the email regardless if it crashes or hangs.  And whether it crashes or hangs is random.  There are no errors in the Error Console.

klint, I'm surprised that it works on your home computer.  I wonder why?  Are you using a version of Thunderbird/Lightning/OS at home that's different from your work computer and different from mine?  I'm testing this with Thunderbird 2.0.0.6, Lightning 2007-09-19, WinXP Home sp2, and my SMTP server is at Fastmail.  Actually I doubt that it's the SMTP server because the email is successfully sent and I have no problem when I manually send emails in Thunderbird.

Comment 40

[Sebastian Schwieger]

Attachment: perl script to send test emails

Thats a perl script I used to send myself test mails.
It takes a text file as an argument that contains the mail body (including Subject and MIME settings and all). I will attach a sample text file as well.

Comment 41

[Sebastian Schwieger]

Attachment: test mail source with multipart/alternative

I tested various Content-types against Outlook 2002. It recognized only pure "text/calendar" mails as event invitations. In all other cases, the attachment could be double clicked as a workaround.

Comment 42

[Mauro Cicognini]

I'd like to add my $ .02 about the invitation reply.

Outlook Web Access does allow writing something in an event reply, and in fact whenever I reply to an invitation from that interface it pulls up a window with a "Yes, I will attend" or "No, I won't attend" fixed text description, and then will allow me to describe the motives, if needed (esp. for refusals, obviously).

A bit of research showed that this text is inserted directly within the VEVENT: part of the vCalendar, using a COMMENT: section that Lightning currently ignores (my proposed patch for bug ... corrects this though, and makes Lightning display COMMENT: sections when present).

The current behavior puts the invitation reply comments within the text/plain MIME part, outside of the VEVENT, and therefore Outlook users will be unable to see it anyway.

It goes without saying that OWA will also display as messages Lightning invitation replies, with no trace of their actual function except for the subject line (which may also be in a different language than what they're used to, but this is another problem altogether).

Comment 43

[Mauro Cicognini]

Attachment: OWA-generated invitation reply

I attach the source of an invitation reply as generated by OWA (sanitized).

Please also note the unusual Content-class header, both in the message headers and the text/calendar MIME part. It's possible that that is needed, also.

Comment 44

[Mauro Cicognini]

Sorry for the spam, in comment #42 I forgot to paste in the bug number for which I have proposed a patch.
That's bug 387863, if anyone's interested.

Comment 45

[Simon Paquet [:sipaq]]

We want this for 0.8

Comment 46

[Martin Schröder [:mschroeder]]

http://groups.google.com/group/mozilla.dev.apps.calendar/browse_thread/thread/dfbf186a9a37791c/a37c1606f39de22d has following information about the mail header Outlook expects:
"text/calendar;method=REQUEST;charset="UTF-8"

Comment 47

[Daniel Boelzle [:dbo]]

Attachment: home grown multipart/alternative part being attached

I've been toying around manually creating the multipart/alternative section. At least lightning could still detect it. Could somebody check this patch whether Outlook swallows those generated mails?

Comment 48

[cmtalbert]

In my build this evening, lightning did not detect the event.  Neither did outlook 07.

I think you have a good idea here.  It just may not be quite right yet.

Comment 49

[Daniel Boelzle [:dbo]]

That's kind of strange, because my lightning (Windows) does. Maybe it's a CRLF issue only.

Comment 50

[Sebastian Schwieger]

Attachment: test email

(In reply to comment #47)
> Could somebody check this patch whether
> Outlook swallows those generated mails?

I can confirm that Lightning 0.8pre (Windows) recognizes the event that I send from my homegrown Lightning (Windows). Outlook 2002 does however not recognize it. At least Outlook 2002 needs a plain text/calendar section without anything else around. I don't have access to newer versions of Outlook but I will add the email so others can test.

Comment 51

[Daniel Boelzle [:dbo]]

Attachment: home grown multipart/alternative part being attached

Clint and I assume that the enforced base64 encoding disables Outlook and Mac Thunderbird/Lightning from recognizing the faked attachment.
I debugged that code some more and found out that thunderbird enforces base64 if
- CR, LF, CRLF is mixed in the attachment
- pref mail.file_attach_binary is set to true
(all in mozilla/mailnews/compose/src/nsMsgAttachmentHandler.cpp : 282 and following)

When changing the faked attachment to use \r\n (and not using that pref), thunderbird actually sends it out unencoded. So if anybody wants to give it another try with Outlook...

Comment 52

[Praveen A]

I tested it (latest nightly from Feb 10) with Outlook 2003, but it did not work.

Comment 53

[Sven Giermann]

(In reply to comment #51)
> Created an attachment (id=302451) [details]
> home grown multipart/alternative part being attached

I tested this and your test email, but both are not recognized by Outlook 2003 (German) - it is complaining about Gregorian calendar or something else (does anybody understand M$ error messages, that are translated to German?).

But a funny thing: when I try to invite somebody with OL 2003, it does work with Lightning 2008020719...

Comment 54

[Bas van den Bosch]

@Praveen: the patch wasn't checked in yet, did you manually apply the patch before you tested it? 

With the patch and outlook2000, accepting tasks sent from outlook to lightning as well as accepting tasks sent from lightning to outlook still works. 

However, the sample email doesn't show accept- and decline-buttons. 
Content-transfer-encoding: 8BIT in a sent invite from lightning as opposed to a 7bit encoding in your sample-mail?

Comment 55

[Praveen A]

@Bas, I thought it was already checked in, but it turned out to be not the case. So just ignore that comment.

Comment 56

[Praveen A]

Attachment: error opening calender file

This is the error Sven was mentioning. I copied the sample file and saved it as invite.ics and I got this error when double clicked on the file.

Comment 57

[Bas van den Bosch]

(In reply to comment #54)
> However, the sample email doesn't show accept- and decline-buttons. 
> Content-transfer-encoding: 8BIT in a sent invite from lightning as opposed to a
> 7bit encoding in your sample-mail?

It's not the content-encoding. The test-email contains an attatchment part 1.2.1 which is in fact an ics-file.

Comment 58

[Daniel Boelzle [:dbo]]

(In reply to comment #4)
> One last comments : I have checked at Google Calendar, and the invitations they
> send do embed the text/calendar part in a multipart/alternative structure.

I've send out invitation from my google calendar, but they aren't automatically recognized by Outlook, too. So it seems google calendar doesn't set the pace here.

Comment 59

[klint]

(In reply to comment #58)
> I've send out invitation from my google calendar, but they aren't automatically
> recognized by Outlook, too. So it seems google calendar doesn't set the pace
> here.
> 
My Outlook 2003 seems to be able to recognize them automatically though! The Accept/Decline button is there, and accepting will insert it in the calendar. I just have checked.

Comment 60

[Daniel Boelzle [:dbo]]

I need to double click google's invite.ics attachment to get the accept/decline options (running Outlook 2003, too).

Comment 61

[klint]

That's strange, as the Accept/Decline buttons do appear correctly in the displayed mail in my Outlook 2003, without double-clicking in any way! What could be the reason for that? 

Comment 62

[Daniel Boelzle [:dbo]]

Ok, I think the core problem is that OL expects the very first part of the mail being text/calendar (or multipart/alternative with enclosed text/calendar).
The compose API always seems to put a leading text/plain into the message, regardless what massage I do on it. I've sketched this as bug 429314.

Comment 63

[Ion Frantzis]

I'm kind of jumping into this thread very late but I'll my two cent for what is worth.

I recently wrote a script in ruby to add calendar events to Exchange via IMAP specifically for the purpose of dumping my ICS calendar to Exchange so other people in the org can see my Free Busy time.  What I discovered was that Exchange is very particular about the Carriage return + line feed  (it wants both) in the attached vCal and not so particular about the message type.  I would imagine that sending event to Outlook users would have the same problems.  With regard to the message type I checked and I had events both as multipart/alternative with an attached text/calendar and as a simple text/plain message with no attachments that were both recognized correctly by Outlook as proper calendar events.

For my part I went with posting them as multipart/alternative with an attached text/calendar.

Hope that's useful.

Comment 64

[Daniel Boelzle [:dbo]]

Attachment: home grown mail composition v1

This patch prepares a home grown mail file and sends it out (the user actually needs to confirm before). I know it's a big hack around mailnews' compose API, but I've spent a ton of investigation and tried out a lot of stuff: this is what it has boiled down to.
The composited mail's structure is similar to what google sends out, i.e. a multipart/alternative with enclosed text/calendar and text/plain as well as an application/ics part.
I am still a bit worrying about whether all encoding stuff is correct, but over all I consider this patch being a fix for the problem.

Before asking for review, I'd like volunteers to further test the patch(!)

Comment 65

[Pete Riley]

Daniel, I think that a lot of people are quietly following this bug and are probably grateful for your dedicated efforts, month after month.  However, some of us users don't have CVS environments and it would be tedious for us to manually apply each line in the patch to the files in our lightning.xpi file.  Plus we'd have to re-do the changes every time we downloaded a new Nightly.  So, it would be nice if

1) you could check in the patch and leave the bug open.  I have seen the Thunderbird team do this.  IMO it would be safe because the functionality is currently broken so it wouldn't matter so much if this new patch is also broken.  And it is a Nightly after all.

2) Or, maybe someone could build it for us and post a link to a lightning.xpi file that we can download.  Such a link could also be posted to the Calendar mailing lists since it seems there are a lot of potential testers there who are "screaming" for this to be fixed.

With an .xpi file I'd be willing to test it to/from Outlook 2007, Google, and Lightning-to-Lightning.

Comment 66

[klint]

Daniel, I second Pete's request. I'm looking forward to testing Daniel's patch on Monday at the office, but I don't now how to patch manually  :(
Thanks!

Comment 67

[Bas van den Bosch]

Me too :-) I'd go for Pete's first option, after all, these are nightlies... If it really breaks stuff, the patch can be backed out...

Comment 68

[Daniel Boelzle [:dbo]]

I've pushed optimized Mac and Windows builds to <http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/experimental/try/bug377761/>. I haven't tested them, but they should work. TryServers would be really favorable of course...

Comment 69

[Bas van den Bosch]

For outlook 2000: with the patch the preview-pane shows an ics-attachment and no accept/decline-buttons, opening the message shows the accept-decline buttons. With earlier versions the attachment isn't shown. Rest of the behaviour is the same. 

For gmail: Both the earlier version and the new version doesn't make gmail recognize the ics, just an attachment is shown. Problem with gmail imho.

For Thunderbird: the previous version worked, the new does too. The only difference is the message-pane is showing two attachments, part 1.1.1 and invite.ics.

Don't have other versions of outlook, will leave this for pete and klint.

Comment 70

[Sebastian Schwieger]

For Outlook 2002: ics file is shown as attachement. Opening that attachment shows accept/decline buttons. Same behaviour as before. Tested with build mentioned in comment 68.

Comment 71

[Daniel Boelzle [:dbo]]

This indicates that OL2002 (as well as OL2000, tested by Bas) seem to rely on a different structure; I've only tested the patch with OL2003. Sebo, could you please send me an invitation with OL2002, so I could have a look?
Being curious: Do google calendar invitations appear right with the buttons?

Comment 72

[klint]

Hello
I can confirm that OL2003 displays the accept/decline buttons correctly for invitations generated with this build.
I also confirm that invitations generated on Google Calendar website appear correctly with the buttons in OL2003 (if that was the question :)

Comment 73

[Daniel Boelzle [:dbo]]

Attachment: home grown mail composition v2

OL2000 and OL2002 send out a plain text/calendar mails which IMO doesn't suit our needs targeting also calendar-less mail applications. I think it's sensible to add a text/plain part as a fallback.

version 2 -- using a top level multipart/alternative with enclosed text/plain, text/calendar and application/ics.

I am curious to know whether this one directly displays the buttons on all OL versions. It works for me on OL2003 (like the previous patch did).

@klint: I was more interested whether OL2000 and OL2002 display the buttons correctly on google's invitations.

I've pushed builds to <http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/experimental/try/bug377761/>, files 2nd-lightning*.

Comment 74

[Daniel Boelzle [:dbo]]

Attachment: home grown mail composition v3

v3 -- sending out a simple text/calendar message.

This is the only version that seems to offer the buttons on all OL2000-OL2003 (OL2007 not tested).
However, the messages don't have any alternative representation for calendar-less applications (no text/plain). Using a Thunderbird(noLightning), the message body simply shows the ICS which is rather cryptic to users.
I've added COMMENT properties as OWA does.

Comment 75

[Daniel Boelzle [:dbo]]

Summing up, I think we have two options:

1) v1 -- send multipart/mixed with multipart/alternative (text/plain, text/calendar) and application/ics. This enables buttons for OL2003 (and possibly OL2007), and has a text/plain body for calendar-less apps. Moreover this keeps the option to add other content types like application/ics (FWIW in the future).
2) v3 -- send simple text/calendar message. This (presumably) enables buttons on all OL versions, but doesn't have a text/plain fallback.

Comment 76

[Hubert FONGARNAND]

could this be an option in preferences ?

By default send v3... (max compatibility)
and if the user want send v1 (less compat, but more accessibility)

Comment 77

[Sven Giermann]

(In reply to comment #76)
> could this be an option in preferences ?
> 
> By default send v3... (max compatibility)
> and if the user want send v1 (less compat, but more accessibility)
> 

If I would have to implement this (and if others agree to make it configurable), I'd prefer to use v1 as a default and call the (by default disabled) option "Compatibility mode (for MS OL < 2003)"...

I would decide to do so for 2 reasons:
- whenever you invite a person you're not knowing which client he uses, it's best to send a standard mail with a text part "This mail contains an invitation" rather then just sending garbage
- when you invite people with a well known application, you are able to set the appropriate option before sending invitations

IMHO it's more acceptable for OL2000/2002 users to manually open the ICS attachment than for others to read 'garbage'...

Comment 78

[klint]

I full agree with Sven's statements about choosing v1 as the default option.

And if we really make the v3 available as a non-default option, we should warn the user that he will gain OL compatibility but loose text/only compatibility.

Comment 79

[cmtalbert]

I would also concur that it makes more sense to use v1 as the default and have an "outlook compatibility mode" in the preferences that when set switches it to use v3.  We can tell people that live and interoperate exclusively with older versions of Outlook to enable v3.  But for the vast majority of users v1 is the appropriate and most interoperable choice.

Great work Daniel!!!

Comment 80

[Bas van den Bosch]

v3 doesn't work for me, no invites are sent from TB and I have to click "save and close" twice. Version 2 shows the same behaviour in OL2000 as version 1, no buttons in the preview but buttons do appear when opening the message. Just tested, even events originating from outlook don't show the accept-decline-buttons in the preview of outlook, opening the message does. The only difference is the ics which is attachted, even in version 2. So imho, versions 2 and 3 can be dropped completely. Thanks...

Comment 81

[Daniel Boelzle [:dbo]]

(In reply to comment #80)
Damn, the v3 windows builds are not OK; I did those in great hate. I've removed those from stage. Sorry!
Right, v2 is no better than v1 w.r.t. OL2000/2002. It just wanted to reflect what OWA sends out.
About v3: I've sent out v3 events to Sebo who confirmed the buttons on OL2002 this afternoon. Since OL2002 sends out similar itip mails as OL2000, my assumption is that both versions could also could handle the same.

After all, I think the test builds gave me enough input to finalize a patch (v1/v3 with compat mode option) for review. Thanks to you, guys!

Please keep in mind that I am still interested in comments/tests on encoding stuff, exotic characters and the like.

Comment 82

[Daniel Boelzle [:dbo]]

s/hate/haste -- seems to be a Freudian slip... ;)

Comment 83

[Mauro Cicognini]

Keep up the good work, Daniel :-)

I don't have time to test right now, but I sure am eagerly waiting for this fix... maybe I'll be able to help out later on

Comment 84

[Günter]

Also this thread is very much about 'sending' format of a invitation reply, I'm missing the possibility to show the **received** invitation data in form of an attachment part/icon or including the ICS data in the msg body.

Where to find this? Is there a hidden config parameter?

Background: for what ever reason a user may want to see the data or work with it ALSO with other application(s). Having install LG would make this impossible??

Comment 85

[Daniel Boelzle [:dbo]]

Attachment: home grown mail composition - final

Final patch for review, offering a compatibility check box before either sending v1 or v3.

@Günther: IMO your request is different from this bug. Please file an enhancement bug for importing ics attachments if there isn't an existing one.

Comment 86

[Pete Riley]

Sorry for the delay!  Here are my results using the v1 patch:

1) Lightning to Outlook 2007:  It works!
OL2007 automatically showed the Accept/Decline/etc buttons -- I clicked on Accept.  Lightning received this response from OL and correctly showed the blue iMIP bar ("This message contains a reply to an invitation").

2) Lightning to Google Calendar:  It also works roundtrip.  (FYI, I don't use the gdata provider.)

3) Lightning to Lightning:  No problems.

So congrats and thanks again.

Comment 87

[Ingeborg Griffioen]

Thank you so much for this patch! It was exactly what we needed! I´ve tested it with Mac OS X as well (send invitation with windows TB to Mac TB) and the buttons were available!

This patch is called v0.9 which unfortunately causes BirdieSync to malfunction. BirdieSync only recognises V0.8. Is there a way for me to use the functionality of your patch and still use BirdieSynch for synchronisation with my Windows Mobile PDA?

Comment 88

[Daniel Boelzle [:dbo]]

Sorry, I think you either need to wait for 0.9 or convince the Birdiesync guys to allow higher Sunbird/Lightning versions.

Comment 89

[cmtalbert]

Comment on attachment 318581 [details] [diff] [review]
home grown mail composition - final

Hi Daniel,

This looks really good.  I didn't bother spending time to test it because I think other users have already tested this patch and I don't have all the versions of Outlook I'd need to test it against anyway.

I have a few nits, but that's it.  Otherwise, great patch.  Here they are:
>Index: calendar/itip/Makefile.in
>===================================================================
>RCS file: /cvsroot/mozilla/calendar/itip/Makefile.in,v
>retrieving revision 1.1.2.1
>diff -u -8 -p -r1.1.2.1 Makefile.in
>--- calendar/itip/Makefile.in	7 Mar 2007 20:22:36 -0000	1.1.2.1
>+++ calendar/itip/Makefile.in	30 Apr 2008 12:04:34 -0000
>@@ -39,11 +39,11 @@ DEPTH		= ../..
> topsrcdir	= @top_srcdir@
> srcdir		= @srcdir@
> VPATH		= @srcdir@
> 
> include $(DEPTH)/config/autoconf.mk
> 
> MODULE = calItipEmailTransport
> 
>-EXTRA_COMPONENTS = calItipEmailTransport.js
>+EXTRA_PP_COMPONENTS = calItipEmailTransport.js
Why PP_COMPONENTS?  Is this something we are changing project wide?

>Index: calendar/itip/calItipEmailTransport.js
>===================================================================
>     checkForInvitations: function cietCFI(searchStart) {
>         // We only need to do trigger a check for incoming invitations if we
>@@ -195,165 +203,209 @@ calItipEmailTransport.prototype = {
>+    _sendXpcomMail: function cietSXM(aToList, aSubject, aBody, aItem) {
>+        var compatMode = 0;
>         switch (aItem.autoResponse) {
>-            case (Components.interfaces.calIItipItem.USER):
>-                LOG("sendXpcomMail: Found USER autoResponse type.");
>-
>-                // Open a compose window
>-                var url = "chrome://messenger/content/messengercompose/messengercompose.xul"
>-                composeService.OpenComposeWindowWithParams(url, composeParams);
>-                break;
>-            case (Components.interfaces.calIItipItem.AUTO):
>+            case (Components.interfaces.calIItipItem.USER): {
>+                LOG("sendXpcomMail: Found USER autoResponse type.\n" +
>+                    "This type is currently unsupported, the compose API " +
>+                    "will always enter a text/plain or text/html part as first part of the message. " +
>+                    "This will disable OL (up to 2003) to consume the mail as an iTIP invitation showing the usual " +
>+                    "calendar buttons.");
This is just text.  We should wrap this better w.r.t. the 80 character rule

>+                // To somehow have a last resort before sending spam, the user can choose to send the mail.
>+                // XXX todo: We should consider a more sophisticated dialiog,
>+                //           so the user could coose the account for sending.
I think we should file a follow on bug for this and/or file a follow on bug to expose the Outlook compatibility mode in the preferences dialog (perhaps on the Advanced tab) because I think that is an important enough preference to be generally available.
Also, spelling error on the last line: coose-->choose

>+                var promptService = Components.classes["@mozilla.org/embedcomp/prompt-service;1"]
>+                                              .getService(Components.interfaces.nsIPromptService);
>+                var prefCompatMode = getPrefSafe("calendar.itip.compatSendMode", 0);
>+                var inoutCheck = { value: (prefCompatMode == 1) };
>+                if (!promptService.confirmCheck(null,
>+                                                calGetString("lightning", "imipSendMailTitle", null, "lightning"),
>+                                                calGetString("lightning", "imipSendMail", null, "lightning"),
>+                                                calGetString("lightning", "imipSendMailOutlook2000CompatMode", null, "lightning"),
>+                                                inoutCheck)) {
>+                    break;
>+                } // else go on with auto sending for now
>+                compatMode = (inoutCheck.value ? 1 : 0);
>+                if (compatMode != prefCompatMode) {
>+                    setPref("calendar.itip.compatSendMode", "INT", compatMode);
>+                }
>+            }
>+            case (Components.interfaces.calIItipItem.AUTO): {

>+                var mailFile = this._createTempImipFile(compatMode, toList, aSubject, aBody, aItem);
>+                if (mailFile) {
>+#ifdef MOZILLA_1_8_BRANCH
>+                    var mailFileURL = getIOService().newFileURI(mailFile).spec;
>+                    mailFile = Components.classes["@mozilla.org/filespec;1"]
>+                                         .createInstance(Components.interfaces.nsIFileSpec);
>+                    mailFile.URLString = mailFileURL;
>+#endif
In the trunk case, we evidently do not need to set the mailFile.URLString attribute. I think it would make sense to default it to something, perhaps an empty string? Or does that attribute not exist on trunk?

>+                    // compose fields for message: from/to etc need to be specified both here and in the file
>+                    var composeFields = Components.classes["@mozilla.org/messengercompose/composefields;1"]
>+                                                  .createInstance(Components.interfaces.nsIMsgCompFields);
>+                    composeFields.characterSet = "UTF-8";
>+                    composeFields.to = toList;
>+                    composeFields.from = this.mDefaultIdentity.email;
>+                    composeFields.replyTo = this.mDefaultIdentity.replyTo;
>+
>+                    // xxx todo: add send/progress UI, maybe recycle
>+                    //           "@mozilla.org/messengercompose/composesendlistener;1"
>+                    //           and/or "chrome://messenger/content/messengercompose/sendProgress.xul"
Add a follow-on bug for some kind of progress UI and ask Christian to evaluate the need for it.  Maybe he'll say there is no need, but
we might as well track that before getting dinged on it later.

>-    _createTempIcsFile: function cietCTIF(aItem) {
>-        var path;
>+    _createTempImipFile: function cietCTIF(compatMode, aToList, aSubject, aBody, aItem) {
>+        try {
>+            function encodeUTF8(text) {
>+                return convertFromUnicode("UTF-8", text).replace(/(\r\n)|\n/g, "\r\n");
>+            }
>+            function encodeMimeHeader(header) {
>+                var mimeConverter = Components.classes["@mozilla.org/messenger/mimeconverter;1"]
>+                                              .createInstance(Components.interfaces.nsIMimeConverter);
>+                return mimeConverter.encodeMimePartIIStr(encodeUTF8(header), false, "UTF-8", header.indexOf(":") + 2, 72);
>+            }
> 
>-        LOG("ICS to be emailed: " + calText);
>+            var itemList = aItem.getItemList({});
>+            var calText = "";
>+            for (var i = 0; i < itemList.length; i++) {
>+                var item = itemList[i].clone();
>+                // This is a workaround until bug 353369 is fixed.
>+                // Without it, we cannot roundtrip the METHOD property, so we must
>+                // re-add it to the ICS data as we serialize it.
>+                //
>+                // Look at the implicit assumption in the code at:
>+                // http://lxr.mozilla.org/seamonkey/source/calendar/base/src/calEvent.js#162
>+                // and it's easy to see why.
>+                item.setProperty("METHOD", aItem.responseMethod);
>+                // xxx todo: should we consider to include exceptional/overridden items?
>+                calText += item.icalString;
>+            }
>+            var utf8CalText = encodeUTF8(calText);
> 
>-        try {
>-            var dirUtils = Components.classes["@mozilla.org/file/directory_service;1"].
>-                           createInstance(Components.interfaces.nsIProperties);
>+            // Home-grown mail composition; I'd love to use nsIMimeEmitter, but it's not clear to me whether
>+            // it can cope with nested attachments,
>+            // like multipart/alternative with enclosed text/calendar and text/plain.
>+            // xxx todo: we should consider generating the message-id. some mail servers may not do that for us?
I think most mail servers generate their own id's these days.  We'll probably get bugs filed if they don't.  

>Index: calendar/lightning/content/lightning.js
>===================================================================
>RCS file: /cvsroot/mozilla/calendar/lightning/content/lightning.js,v
>retrieving revision 1.2.2.18
>diff -u -8 -p -r1.2.2.18 lightning.js
>--- calendar/lightning/content/lightning.js	11 Dec 2007 14:01:50 -0000	1.2.2.18
>+++ calendar/lightning/content/lightning.js	30 Apr 2008 12:04:34 -0000
>@@ -16,16 +16,17 @@
>  * The Initial Developer of the Original Code is 
>  *   Joey Minta <[e-mail]>
>  * Portions created by the Initial Developer are Copyright (C) 2005
>  * the Initial Developer. All Rights Reserved.
>  *
>  * Contributor(s):
>  *   Stefan Sitter <[e-mail]>
>  *   Philipp Kewisch <[e-mail]>
>+ *   Daniel Boelzle <[e-mail]>
>  *
>  * Alternatively, the contents of this file may be used under the terms of
>  * either the GNU General Public License Version 2 or later (the "GPL"), or 
>  * the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
>  * in which case the provisions of the GPL or the LGPL are applicable instead
>  * of those above. If you wish to allow use of your version of this file only
>  * under the terms of either the GPL or the LGPL, and not to allow others to
>  * use your version of this file under the terms of the MPL, indicate your
>@@ -60,16 +61,21 @@ pref("calendar.alarms.eventalarmunit", "
> pref("calendar.alarms.onfortodos", 0);
> pref("calendar.alarms.todoalarmlen", 15);
> pref("calendar.alarms.todoalarmunit", "minutes");
> 
> // autorefresh settings
> pref("calendar.autorefresh.enabled", true);
> pref("calendar.autorefresh.timeout", 30);
> 
>+// iTIP compatibility send mode
>+// 0 -- Outlook 2003 and following with text/plain and application/ics (default)
>+// 1 -- all Outlook, but no text/plain nor application/ics
>+// We may extend the compat mode if necessary.
>+pref("calendar.itip.compatSendMode", 0);
As I said earlier, we need to file a follow on bug to expose this prefence in the Preference UI. 

r=ctalbert with those nits. Awesome patch thanks so much!!

Comment 90

[Daniel Boelzle [:dbo]]

> >-EXTRA_COMPONENTS = calItipEmailTransport.js
> >+EXTRA_PP_COMPONENTS = calItipEmailTransport.js
> Why PP_COMPONENTS?  Is this something we are changing project wide?
No, the file needs to be preprocessed to separate branch/trunk code; the message send API has different parameter types. I could have used app-info for that, but I prefer filtering code out.

> I think we should file a follow on bug for this and/or file a follow on bug to
> expose the Outlook compatibility mode in the preferences dialog (perhaps on the
> Advanced tab) because I think that is an important enough preference to be
> generally available.
I've filed bug 432660 for choosing an account.
W.r.t. a pref for the compat check: Right now I just preserve the checkbox value, so the user gets what he last has chosen next time. I thought that's more intuitive than having a separate pref pane. Maybe Christian could comment on this.

> In the trunk case, we evidently do not need to set the mailFile.URLString
> attribute. I think it would make sense to default it to something, perhaps an
> empty string? Or does that attribute not exist on trunk?
filespec has vanished from trunk.

> >+                    // xxx todo: add send/progress UI, maybe recycle
> >+                    //           "@mozilla.org/messengercompose/composesendlistener;1"
> >+                    //           and/or "chrome://messenger/content/messengercompose/sendProgress.xul"
> Add a follow-on bug for some kind of progress UI and ask Christian to evaluate
> the need for it.  Maybe he'll say there is no need, but
> we might as well track that before getting dinged on it later.
filed bug 432662

Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.

This is a call for further testing! I am still interested in exotic characters etc...

Comment 91

[Daniel Boelzle [:dbo]]

Andreas has installed Outlook 2000 and the invitations (send with compat OL2000/OL2002 check) haven't been recognized correctly.
Either there's a slight regression in my unified patch or OL2000 seems to be different from OL2002 (which has been acknowledged by Bas & Sebo at that time AFAIR).

Comment 92

[Daniel Boelzle [:dbo]]

Andreas has installed OL2002 and it correctly shows the buttons.

The status is:
a) If you send out mails with checked OL2000/OL2002 mode, OL2000 cannot cope with it (not even via opening the attachment), but OL2002/2003/2007 can. Calendar-less applications don't have a fallback text/plain part.
b) If you send out mails without checked OL2000/OL2002 mode, OL2000/OL2002 don't show the buttons (only via double clicking the attachment), but OL2003/OL2007 do.

I can imagine the following options:
1) We drop OL2000/OL2002 support, don't offer the compat check.
2) We spend more efforts in finding a unified solution for both OL2000/OL2002 that works.
3) We rename the compat mode being "Support OL2002" which would imply the OL2000 users are shot.

IMO we should go with option 1 for now until someone finds a solution for 2. I don't think we should go with 3.

Opinions?

Comment 93

[Bas van den Bosch]

I don't notice any real problems with ol2000, sp-(9.0.0.6627) ???  Before the patch there was a text in the email and no attachment showing. Without the compatibility-modus there's no text and no attachment. With the compatibility-modus there's text and an attchtment. 

In all cases the accept-decline-buttons in ol2000 are only shown when opening the message, not when previewing. The compatibility-mode does show the text so it's better. Perhaps the difference are the service-packs installed for office2k?

Comment 94

[Daniel Boelzle [:dbo]]

Thanks Bas, this makes it even more difficult:
BTW: Even different Outlook versions cannot send/recognize iTIP mails reliably: Sending an iTIP mail invitation with OL2003, OL2000 (Andreas' installation) doesn't recognize it, too.

Comment 95

[Daniel Boelzle [:dbo]]

Maybe we should keep it as it is now, find out the Office 2000 patch level and just relnote it?

Comment 96

[Marcel Berteler]

If I understand the explination correct, than option 1 effects OL2000 and OL2002, while option 3 only effects OL2000.

Why not go with option 3 for now until someone finds a solution for 2. It seems to effect less users.

But maybe I did not understand your explanation correctly.

Is my understanding correct:
a) If you send out mails with checked OL2000/OL2002 mode, OL2000 cannot cope
with it (not even via opening the attachment), but OL2002/2003/2007 can.
Calendar-less applications don't have a fallback text/plain part.

Although the mode is called 2000/2002, OL2000 can not cope with the invitation while OL2002 acts just like OL2003/OL2007?

b) If you send out mails without checked OL2000/OL2002 mode, OL2000/OL2002
don't show the buttons (only via double clicking the attachment), but
OL2003/OL2007 do.

So this mode allows OL2000 to add the invitation is some way. Unfortunately it also effects OL2002 users as they have to deal with the invite the same way a OL2000 user would have to.

It almost loks like this switch/mode should be called OL2000 compatible and should be inverted. Check the box will allow OL2000 users to add the invite (Your option B, currently unchecked) and un-check the box and OL2000 users will not be able to add the invite..(your option A, currently checked)

Comment 97

[Daniel Boelzle [:dbo]]

(In reply to comment #96)
Since Bas doesn't have further problem with OL2000 and the compat mode, it seems to be dependent on the Office2k patch level.

> b) If you send out mails without checked OL2000/OL2002 mode, OL2000/OL2002
> don't show the buttons (only via double clicking the attachment), but
> OL2003/OL2007 do.
> 
> So this mode allows OL2000 to add the invitation is some way. Unfortunately it
> also effects OL2002 users as they have to deal with the invite the same way a
> OL2000 user would have to.
No, at least on Andreas' installation the double click attachment thing didn't work on OL2000.

Comment 98

[Simon Paquet [:sipaq]]

I think we should work with what we have now and find out which patches (or service packs) are needed for Outlook 2000, so that we can adequately relnote our findings.

Comment 99

[Andreas Treumann]

I updated my Outlook 2000 with SP3 , build-id 9.0.0.6627, and now it works as expected.

Comment 100

[Simon Paquet [:sipaq]]

Would everyone be cool with the following release note:

E-Mail invites sent out by Lightning in Outlook 2000/2002/XP compatibility mode, will only be shown by Outlook 2000 if the Service Pack 3 (SP3) has been installed.

One more thing:
Daniel, IMO we should reword the string

-imipSendMailOutlook2000CompatMode=Support Outlook 2000 and Outlook 2002
+imipSendMailOutlook2000CompatMode=Support Outlook 2000 and Outlook 2002/XP

because Office 2002 (which includes OL 2000) is often identified as Office XP.

Comment 101

[Günter]

Also I followed this thread only by reading and expecting my old/personal installation of OL [1] is covered by other testers, I would like to make the following suggestion:

With this Microsoft page [2] we have a detailed info about different OL versions and their changes with updates. How about building a worksheet with all those versions, the results and comments about LG/SB switches? So the LG/SB user can check for HIS requirements to have an compatible LG/SB <--> OL200x version?
Günter

[1] Outlook / version 10.0 / Build 6515 / Product ID 54199-640-0000025-17397 / Sprache Deutsch (Deutschland)
[2]http://support.microsoft.com/kb/870929/EN-US/

Comment 102

[Daniel Boelzle [:dbo]]

(In reply to comment #100)
> Would everyone be cool with the following release note:
> 
> E-Mail invites sent out by Lightning in Outlook 2000/2002/XP compatibility
> mode, will only be shown by Outlook 2000 if the Service Pack 3 (SP3) has been
> installed.
I sm cool with that :)

> Daniel, IMO we should reword the string
> 
> -imipSendMailOutlook2000CompatMode=Support Outlook 2000 and Outlook 2002
> +imipSendMailOutlook2000CompatMode=Support Outlook 2000 and Outlook 2002/XP
> 
> because Office 2002 (which includes OL 2000) is often identified as Office XP.
Makes sense; I just checked that in.

(In reply to comment #101)
> With this Microsoft page [2] we have a detailed info about different OL
> versions and their changes with updates. How about building a worksheet with
> all those versions, the results and comments about LG/SB switches? So the LG/SB
> user can check for HIS requirements to have an compatible LG/SB <--> OL200x
> version?

IMO this doesn't help too much. We have to keep in mind that the sender most often doesn't know about what Outlook versions the attendees are running. To this extend, even the current compat mode is in a sense doubtful: To have maximum compatibility, you should always check it (but loose the text/plain fallback (which BTW isn't too valuable at this stage, but that's a different bug/enh)). This I vote to keep the relnote easy (like Simon suggested).

Comment 103

[Eric Valette]

I tested the latest nightly and was prompted for outlook compatibility flag. But doing this, I have no way to access to send mail content, attach documents and so on.

Although I did not test, I suspect saying "no" will use the old mode where I do access to email content but when send it is not unrecognized as as a calendar event unless clicking on the attachment.

So IMHO, you did not fix the bug and it should stay open until you have a mean to really send a complete mail.

Comment 104

[Eric Valette]

Welle is checked what happens with no and I do not see any composer windows either. This is for me far worse than the old behavior.

Comment 105

[Daniel Boelzle [:dbo]]

(In reply to comment #103)
> I tested the latest nightly and was prompted for outlook compatibility flag.
> But doing this, I have no way to access to send mail content, attach documents
> and so on.
1) Thunderbird's current compose API doesn't offer to tweak the send parts of the mail message, thus we cannot use Thunderbird's composer window.
2) Not even the beloved Outlook or Google calendar offer you to add text or attachments when sending out the invitations. Outlook offers to add attachments to the event (+summary and description as we do in the event dialog), but I see no way to add sole attachments to the sent out mail.

> So IMHO, you did not fix the bug and it should stay open until you have a mean
> to really send a complete mail.
It seems you don't really understand the nature of iMIP messages.

Comment 106

[Eric Valette]

What I say it that your fix makes lightning even less usable than it was for me!
And you are wrong: Outlook enables to attach document and message to invitation

Comment 107

[klint]

Eric, the current bug is fixed as its purpose was to make the IMIP/ITIP invitation readable by Outlook, which they are now.

When it comes to attach documents to the invitation, you still can send any home-brewed email to all attendees (or undecided attendees) by editing the event and clicking on the attendees list. It's pretty straight forward.

This being said, you may want to open another bug the handle the now missing feature, which is to attach documents to the invitation itself. But as Daniel mentionned it, this is rather a Thunderbird limitation.

IMHO sending invitations that are understood by the attendee's calendaring tool is much more important than sending attachements in the same mail!

Comment 108

[Daniel Boelzle [:dbo]]

(In reply to comment #106)
> What I say it that your fix makes lightning even less usable than it was for
> me!
There's no reason to shout.

> And you are wrong: Outlook enables to attach document and message to invitation
1) What you are editing is actually the *event data* rather than the email.
2) Lightning doesn't offer attachment support yet. When that's ready, we could attach those files to the sent out invitation, and will likely do so.
3) W.r.t. the message body: Please file an enhancement bug to garnish the mail body with the event's description, code is <http://mxr.mozilla.org/mozilla1.8/source/calendar/base/src/calUtils.js#2352>.

Comment 109

[Eric Valette]

Attachment: An invitation with document attached and text

Daniel you should check the reality before making affirmation like the last one. I do not say it is fully standard compliant but at least I affirm that when omosing an invitation you can
    - add message
    - add attached document
same when replying.

Comment 110

[Eric Valette]

Replying to 108:

may I suggest a poll to see if people prefer to have access to the compose windows or your solution.

Comment 111

[Daniel Boelzle [:dbo]]

On replies (with message): what you are editing is the event's data (DESCRIPTION); have a look at what Outlook sends out. Please file an enhancement bug if you like to have an option to edit DESCRIPTION (on replies) or COMMENT property (AFAIK used by Outlook on REQUESTs) to the reply.

Again: the composer window doesn't fit here (even if we could use it for sending mails).

Comment 112

[Daniel Boelzle [:dbo]]

(In reply to comment #110)
> may I suggest a poll to see if people prefer to have access to the compose
> windows or your solution.
It doesn't matter really. I constantly try to explain why we currently cannot use the composer window (no ability to tweak the message parts + we need to edit the iTIP data rather than the email). You seem to ignore that.

EOD in this bug -- file the enhancement bugs I mentioned and we'll see what we can do.

Comment 113

[Eric Valette]

I understand that using the composer windows is not the way to go especially for sunbird. But I still want to be able to add text and attachment to event creation, response. Having a GUI like the one poped when editing an event would be fine provided:
     1) it does support mutiple attachment, and text message
     2) Anytime I modify an event a message is end to attendees

Comment 114

[Andreas Treumann]

Checked with nightly build 2008072219 -> VERIFIED

If anyone find new issues around iTIP/iMIP in lightning and outlook then he/she should file new bugs please.