While Microsoft products follow many RFC guidelines for VCALENDAR/iCAL, it does not mean that they support development of VCALENDAR/iCAL directly. Microsoft has APIs which can build and read such content. Working with those APIs is supported; however working with VCALENDAR/iCAL text programmatically is not supported. This means if you build a message via code (not using a Microsoft API) or manually, you will not be in a supported scenario. If you do find though that Exchange or Outlook is not following a standard its supposed to follow, then that’s a different matter.
VCALENDAR messages can be complex and the responses will vary depending upon the situation. You should really go over the specs in great detail. Any company trying to build their own VCALANDAR code will find that they will need to generate several dozen types of messages which are appropriate at different times - I won't cover that aspect, because it’s just way too much. You'll just need to do a lot of research and testing. Always remember this: The calendaring message sent should reflect the state of the meeting to which the message is being constructed for. By "state of the meeting", I mean everything about the meeting - accepted/tentative accepted recipients, cancelation, location of recipients, recurrence, recurrence exceptions, etc... the list goes on. Again, do a lot of research and testing.
Microsoft does not support WebDAV for complex calendaring operations. Can you guess why this is? WebDAV is great for certain things, however calendaring is quite complex and proper handling of calendaring operations including calendaring messages requires quite a bit of business logic. WebDAV has no business logic. Yep - not good if you want to use WebDAV. With WebDAV, you would need to have quite a bit of expertise in VCALENDAR construction and still it might not be enough in many cases. EWS however is a great solution for doing calendaring operations - the only drawback is that you must go against an Exchange 2007 or later server.
Available support for applications that use the WebDAV protocol to access Exchange 2000 Server or Exchange Server 2003
Also, while articles such as KB287625 show how to send an iCal file as an attachment, this is not the same as sending a meeting request. KB287625 only shows that you can export a calendar entry to a file and include it in a message as an attachment and then the recipient can import it into their Outlook. This article does not say that you can create a meeting request by turning that exported iCal into a meeting request. Further, the iCal generated was generated by Outlook and not by custom code.
How to use vCalendar in Outlook
Developer support limitations for public protocols
Generally, how this all works:
Meeting functionality requires storage of meetings by both the meeting organizer and recipients. It also requires specifically crafted messages be exchanged between the organizer and recipients. Here is how basic calendaring might work:
I) Create the meeting
A) Organizer creates a meeting (a UID is set - it’s a unique id which identifies the meeting).
II) Send Meeting Request:
A) The organizer sends a meeting “REQUEST” to the recipients (the UID is included).
D) These calendaring messages would have:
1) A message with these headers:
2) A text/htmlbody part - shows in the body of the message.
3) A VCalendar attachment with the following headings like the following:
4) Note that "METHOD" in the VCALENDAR will vary depending upon the operation
5) The VCALENDAR will have the same UID as the meeting in the organizer’s calendar.
III) Recipient Replies
Now, the “REPLY” message from the attendee (Accepted, Rejected, etc) will have much of the same content. The UID in the reply message will be the same as in the organizers’ calendar and in the meeting request. There will only be one ATTENDEE in the VCALENDAR of the reply since this message is for the organizer to update his/her calendar.
IV) Organizers’ calendar is updated.
Again: I'm providing some general information which you might use for seeing how VCALENDAR messages might work. There is no support for working with such content outside of a MICROSOFT API.
Here are RFC reference links:
iCalendar Core Specification
RFC 822 covers message format
Outlook and other products will likely encapsulate calendaring information into TNEF files when it sends messages. However, you probably can use plain text MIME messages to do many of the same things. However, there will likely be situations where you won't get the exact same behavior as you might with a calendaring message sent from Outlook.
Since this is a non-supported area, I'm going to blog a little bit about this so that you can work-out your own solution. However, please note that doing this is not advised - you should use Microsoft APIs for doing such work. I'm just going to provide some ideas on how one might find what to send in a VCALENDAR message. Note that if you choose this path, you really should test all clients and server versions which you might want to support.
You need to account for things like DST and Timezone issues in your code. It’s important to be sure to account for these things or you will likely run into them later. Let me point these out so you can code and test for them (at least these).
1) Time zone changes (When they change, where the attendees are, what the settings are, etc)
2) Daylight Savings Time Changes
3) Organizer and Attendee being in different time zones.
4) Recurring meetings.
5) Recurring meeting Exceptions.
DST changes happen all the time – some countries change when they happen very often (it almost seems they toss a dart at a calendar to decide when DST will begin/end each year). Some countries can have 30minute DST shifts or even Timezone changes which are at :15, :30 or :45 after the hour. Time zones also sometimes change, merge, divide, etc.
You might look into setting reminders:
Another area of issues is cancelation of meetings. This is quite tricky and requires accounting for any state a meeting maybe in relative to each recipient. Here there is some round-tripping to get the work done, however I won't cover it. Cancellation of a meeting is far more complex than just deleting the meeting item or sending a message - the meeting must be removed, proper cancellation messages must be sent, etc. This is something which should be well tested.
APIs such as CDOEX is useful in finding out what might be the appropriate for VCALENDAR text:
HOWTO CDOEX C#: How to extract VCalendar stream from an appointment.
You might also use WebDAV to get the MIME and then extract the VCALENDAR from it. If you right click on an item in OWA from Exchange 2000 or 2003, you can get the URL to that item and use it in WebDAV code. BTW: This is one area where APIs like Exchange Web Services (EWS) shine.
Ok, for WebDAV - let’s see how to get the MIME message and find the VCALENDAR...
Howto: Get the MIME of an item from a mailbox.
If you’re working with a MIME text stream, here is how you might get to the VALENDAR content:
1) VCALENDAR information is stored in a body part of a mime message.
2) Bodyparts are seperated by lines starting with "--". What follows the "--" is established by the "boundary" header. The final seperator line will also end with a "--"
3) These are multipart/mixed MIME messages (Content-Type set to "multipart/mixed")
4) The code needs to find the bodypart part which has a heading
This is the body part of the VCALENDAR.
5) Extract all of the content from the lines starting with "BEGIN:VCALENDAR"
and ending with "END:VCALENDAR".
When you look at a MIME/VCALENDAR message using WebDAV or Extracted from a message created by CDOEX, you would normally see a document containing several sections. A calendar message is usually in 3 sections: mail header, body text, vcalendar. If you got a netmon trace from a message sent from Outlook/OWA another server/client, you would probably see a TNEF file instead of text VCALENDAR content.
A Few VCALENDAR Samples:
Send Meeting Request:
Here "Administrator" sends an meeting request to "myuser".
To: "MyUser" <firstname.lastname@example.org <mailto:myuser@mydom>>
Subject: Accepted: 3
Date: Fri, 9 Jun 2007 0:29:00 -0700
X-Mailer: My mailer
Content-Type: multipart/alternative; boundary="====_NextPart_0===="
This is a multi-part message in MIME format.
<!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><A NAME=3D""><FONT FACE=3D"Times New Roman">When: Tuesday, March =
25, 2008 04:00 PM-06:00 PM. Eastern Standard Time</FONT><BR>
<FONT FACE=3D"Times New Roman">Where: test</FONT><BR>
<FONT FACE=3D"Times New Roman">*~*~*~*~*~*~*~*~*~*</FONT><BR>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Tahoma">test</FONT>
SUMMARY:Test meeting request
Meeting Request Reply:
Lets now have "myuser" send an Acceptance in reply to "Administrator"...
Note: For a tentative acceptance response, just user "PARTSTAT=TENTATIVE" instead of "PARTSTAT=ACCEPTED".
To: "administrator" <email@example.com <mailto:administrator@<firstname.lastname@example.org>>
<FONT FACE=3D"Times New Roman">Where: In My Office</FONT><BR>
LOCATION: My Office
Some things to watch-out for
The problem with trying to send a meeting request without having it tied to Outlook or Exchange is that when a meeting request is sent, there needs to be a meeting already created in a calendar some place. The UID of that meeting is central in making meeting requests work. The UID would be used in the original meeting, the meeting request, meeting request response and on accepting the meeting request response. If the same UID is not used across all points, then the whole process will fail.
Be careful to have the UID match across all places that the meeting exists. So, when the meeting request is created, you should already have a meeting created in the calendar. The UID of the meeting in the calendar needs to be used in the meeting request. The same UID must be used in the meeting response. Failure to do this will result in breakage in the flow of the meeting.
All MIME headers must be pure ASCII (7-bit). Anything outside ASCII charset in a header must be properly encoded (e.g. using RFC2047 and/or RFC2231). MIME entity body can be in any charset (but, if no encoding is used, it must be marked with appropriate Content-Transfer-Encoding, such as 8bit or binary).
A meeting Request can have multiple ATTENDEEs. However a meeting request response can only have one ATTENDEE listed since it is a message going only from that attendee to the organizer.
Watch out for formatting, line length and encoding. The rules for general MIME will not be the same for VCALENDAR. Remember there may be multiple levels of encoding which may be needed.
Test everything against every platform. Since this is not a supported path, you will need to live the code which you write. There may be some things which you just cannot do using code as described above and MS does not support programaticly working with VCALENDAR content in this way.