iCal, or internet calendaring, generally isn't heavily used or widely understood. When it is used, it generally creates some confusion since it produces different results based on what server and clients are used. Rather than babble on about all the RFC info, lets use an example to show what this is and how Exchange and Outlook use it.
For this discussion, we assume that sending calendaring items means sending them to a recipient over the internet, or outside the organization. Also, the Outlook client is assumed to be Outlook 2003. Legacy clients/servers will be covered later in the doc.
iCal is a body part in the MIME stream that describes a calendaring event. Usually stored in the stream in a totally readable format... Huh? MIME stream? Body part? Messages on the internet are in MIME format. Have a look, here is a MIME stream with a iCal body part...
Received: by Recipient.AlpineDom.com
id <01C4920A.480E1A6D@Recipient.MyDom.com>; Fri, 3 Sep 2004 16:03:52 -0700
Subject: From MAPI
Date: Sat, 4 Sep 2004 16:03:52 -0700
Thread-Topic: From MAPI
From: "Recipient" <Recipient@MyDom.com>
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
To: "Recipient" <Recipient@MyDom.com>
This is a multi-part message in MIME format.
When: Saturday, September 04, 2004 10:00 AM-11:00 AM (GMT-08:00) Pacific =
Time (US & Canada); Tijuana.
Microsoft Outlook Web Access:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
<!-- Converted from text/rtf format -->
<P><FONT SIZE=3D2 FACE=3D"Arial">When: Saturday, September 04, 2004 =
10:00 AM-11:00 AM (GMT-08:00) Pacific Time (US & Canada); =
<BR><FONT SIZE=3D2 FACE=3D"Arial">Where: Here</FONT>
<P><FONT SIZE=3D2 FACE=3D"Arial">*~*~*~*~*~*~*~*~*~*</FONT>
<P>Microsoft Outlook Web Access: <A =
PRODID:Microsoft CDO for Microsoft Exchange
TZID:(GMT-08.00) Pacific Time (US & Canada)/Tijuana
DTSTART;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20040904T1000
DTEND;TZID="(GMT-08.00) Pacific Time (US & Canada)/Tijuana":20040904T110000
Without getting into how MIME streams are built, covered in the various RFC, and what it all means, there are three body parts to this stream we are concerned with.
The last body part, text/calendar, is the iCal blob. As you can see, it's relatively readable. Clients receive this stream have to process it some how. In this case, they are given three options to display the message; these are the three body parts. At least, all clients can display the text/plain since its well, just plain text. If the client knows how to process the text/html body part, it has that option and if it knows how to display a rich meeting request from the text/calendar, it too has that option. Again, it's up to the client to decide what to display.
I'm not going into what each of the lines in the iCal blob means, many of them are self evident, but there are a few lines worth looking at to better understand what is going on
Outlook Express is not a calendaring client and doesn't know how render the text/calendar into a rich meeting request, so it decided to display the plain text body part. However, in addition it also provides the iCal blob to the user as an attachment, this is what the name="meeting.ics" line above provides. Again, this is all up to the client.
The other interesting line is the encoding; Content-Transfer-Encoding: 8bit. This describes how the particular body part is encoded. It could have been encoded in a way that makes it look like total gibberish leaving it unreadable like Base64. You can see the other body parts have different encoding, but they are all still readable.
The URL to direct the users' to their Exchange mailbox with OWA was added in the message body. Exchange knows this is a calendaring item and has added this to the text/plain and text/html body parts giving the recipient the option to book it in the calendar on the Exchange server with a web browser. This option is on the POP/IMAP virtual server in Exchange System Manager.
Finally, a quick note about the Content-Type: multipart/alternative line in the beginning of the stream. This essentially tells the client there are multiple parts to choose from, use the one you (the client) see best fit. Remember this entire stream is handed to the client, and is up to the client to process it.
Ok, so what does this have to do with Exchange? Or Outlook?
- Exchange inside talks MAPI, so MAPI <-> MIME conversions need to take place.
- MIME streams need to be created either by the client or the server.
- Exchange 200x understands iCal but previous version don't.
- Outlook XP doesn't understand multipart/alternative, Outlook 2003 does.
When/where do the iCal MIME streams get created?
Normally Outlook is connected to an Exchange server and talking MAPI. So when Outlook sends a meeting request, it's Exchange that is creating the MIME stream. If Outlook is connecting to a server via POP, it's Outlook that's creating the MIME stream. If connecting with OWA, then of course Exchange is creating the MIME stream.
Isn't it up to the client to decide how to display the iCal item?
It is. Normally Outlook is in MAPI talking to Exchange. When an iCal item arrives, Exchange 200x puts the item in its native form in the store, leaving it there unchanged. When Outlook, in MAPI, requests this item, the store realizes that a MAPI client is asking for a MIME item and then needs to convert it. Exchange 200x is completely iCal aware, understands the multipart/alternative option and selects the text/calendar to convert into a rich MAPI meeting request for Outlook. OWA behaves exactly the same.
Now, Outlook is connecting to the server via POP/IMAP mode, when an iCal item arrives, Exchange 200x does exactly the same thing as before, puts the item in the store in it's native format. Now when Outlook in POP/IMAP mode requests the item, the Exchange 200x store knows the original format arrived as MIME and MIME client is asking for the item, so Exchange just hands Outlook the item unchanged. It's now up to Outlook to process the MIME stream.
If any MIME message arrives in Exchange and any POP/IMAP, or internet client, asks for the message, Exchange simply hands the message over to the client. Outlook Express is not a calendaring client, but still receives the iCal blob just as any other internet client would, and exposes it as an attachment. Other clients may do the same or something different.
How about Outlook XP or older Outlook clients?
Outlook XP in POP/IMAP mode can handle iCal blobs, but doesn't understand multipart/alternative. So if a calendaring item is handed to Outlook XP in POP/IMAP mode with multipart/alternative, which is the default Exchange uses, it will only display the text/plain. The only way Outlook XP will render iCal is if the content type is text/calendar and is the only body type. This means the calendaring item had to enter Exchange in MIME format originally. Older than Outlook XP? Well don't expect any improvements over what Outlook XP does. If Outlook XP is talking MAPI and a meeting request arrives in MIME, Exchange converts it for Outlook into a rich meeting request, just as it would for basically any MAPI client. It's Exchange that's converting the MIME stream into MAPI since MAPI is asking for the item.
The Mac clients...
Outlook Mac doesn't have options for a POP account, it's a pure MAPI client. The latest Microsoft Mac mail client is Entourage which only connects via POP/IMAP/HTTP and is completely iCal aware. This is one client that in addition to Outlook 2003 works very well in iCal environments.
What about Exchange 5.5?
All inbound and outbound MIME mail is handled by the IMC, the IMC converts all MIME to MAPI immediately upon delivery and doesn't understand iCal, or text/calendar, so it can't produce a rich meeting request. This is why the recipient gets a plain text message regardless of what mode Outlook is in. In Exchange 200x all inbound MIME mail is held in its native format in the store until a conversion is necessary, this helps improve performance.
A final word on TNEF. Exchange uses a method to send a MAPI message over the internet in TNEF format, see example header snippet below. Transport Neutral Encoding Format allowed Exchange to wrap all the MAPI properties up and encode them in the MIME stream as a body part. It kind of looks something like Base64 encoding. This was a safe thing to do if you knew your recipient server was an Exchange server and how calendaring items were sent over the internet before iCal. But as the internet grew to what it is today, Exchange needed to be more robust to accommodate this change and added full support for iCal in Exchange 200x.
- Eric Hartmann