What is the status quo for vCard support by common e-mail clients (Outlook, Gmail, Apple's mail thing)? From what I can tell Outlook's support is a bit backwards; it has its own "standards" for vCard, but I can't find anything that specifies what they are, or if they have changed in the last couple versions (2010, 2013, mac:2011) to be more standard.
The RFCs for v4.0 and v3.0 seem readily available, but if I want to go to the lowest common denominator, 2.1(?), I can't find that RFC (or was it pre-RFC?).
Version 2.1 came out before the IETF took over the vCard standard. You can find the spec here:
http://www.imc.org/pdi/vcard-21.rtf
My experience with parsing Outlook vCards has been that they generally stick to the standard. However, there is some quirkiness with how Outlook folds the lines of property values that use quoted-printable encoding.
Related
We have a project that has numerous Outlook OFT files. Users download these files and use them to send prewritten emails in Outlook.
I have been looking for a way to convert these files into plain text. Ideally, this conversion functionality would be incorporated into the web app that runs on Linux servers. I mention Linux because Outlook and OFT are Microsoft products.
I have not found any libraries, class, tutorials around this topic. I have found very little conversation besides trying to do HTML->OFT which points to a Microsoft only library. I am most experienced with PHP, but I am open to any approach.
FWIW, I believe OFT can have templating information in it. I am only interested in extracting the message content/body.
OFT is the same an MSG (with a different class signature GUID). Whatever library you can find for working with MSG files, will work with OFT as well.
In the work we actively use IMAP flags (user-defined, for example: FIRSTCLASS) with Thunderbird client. But now we need to move to Outlook (reason: better search engine, although Thunderbird will be always in my heart).
Unfortunately Outlook doesn't support IMAP STORE command for flags. (RFC 3501)
How I can change this behavior? For example with Outlook VSTO. Or COM add-in?
I just need at least a way.
You can't. And categories do not work with IMAP4 accounts either - see http://www.slipstick.com/outlook/outlook-categories-flags-and-imap-accounts/
Under PST with POP3/SMTP the categories will work.
Can anyone point me to an example of an Outlook Contact custom sync provider for the Microsoft Sync Framework? I would like to use that Framework to build a bidirectional sync between my CRM and Outlook. I've found a reference to this SO question: Sync Microsoft Outlook with my own data
Unfortunately, the link to MSDN example is no longer valid. It simply redirects to the MSDN sample gallery which has no such sample.
Any help would be much appreciated.
I am very curious to what the link was to, as well. I have not found anything short of either a "Wrapped PST Store" or "Custom MAPI Store" or "Custom MAPI Transport Provider". MAPI itself provides a synchronization process, but it is not designed to be used from managed code and is very complicated.
The best "roundup" I have found is the Outlook MAPI Samples on codeplex. These do not deal with any pretty "Sync Framework" though; presumably that is used as the back-end? (Most samples neglect how to get to the back-end processing.)
We are evaluating an entirely managed in-Addin synchronization process here to avoid having to deal with the complications of MAPI, but the viability is still not entirely known. (This approach also introduces different problems and limitations.)
Good luck and happy coding.
I'm working on a web application that allows users to create a calendar of events, then download those events into their calendar program of choice (e.g., Outlook, Lotus Notes, iCal, Google Calendar, etc.)
The web app outputs the event data as an attachment in iCalendar (ics) format.
I'm running into a variety of problems...
If I use "VERSION:1.0", Outlook 2003 will recognize and import the attachment. However, Apple iCal will not. If it's "VERSION:2.0", iCal works, but Outlook 2003 will not.
If the attachment has more than one event (VEVENT), then Outlook 2003 only imports the first event, unless the user uses Outlook's import function.
I don't have Lotus Notes, or multiple versions of Outlook (2007, 2010), so I can't how those behave easily.
I don't mind having to implement a little dialog that asks the user what calendar program they use so I can customize the output accordingly. However, I don't know what each of the major programs supports or requires.
Has anyone found a resource that lists, by calendar program, what works and what doesn't? E.g., does Outlook 2007 or 2010 support "VERSION:1.0"? Is there a way to get Outlook 2003 to support "VERSION:2.0", or handle multiple events? What does Lotus Notes support? What about Yahoo and Google?
I don't need to support EVERY program, but I'd like to support as many of the major ones as possible.
Many thanks in advance!
Regarding Lotus Notes, you can download a trial version of the Notes client software from the IBM site, which may be all you really need to test your application. Notes can import ical entries through an Import menu, or dragging and dropping the iCal file into the Notes client. (If you need to do further Notes-specific development, you can also download a free version of the "Domino Designer" software from the IBM web site - IBM makes the Designer software available free for single machine use - no server access.)
There is a KBase article on the IBM site with some details of iCal support in the latest version of Notes (8.5) - http://www.ibm.com/developerworks/lotus/library/notes85-icalendar/index.html
I can't seem to find a good forum focusing on iCalendar format. Specifically how iCalendar is implemented with Outlook.
If you are producing iCalendar data and want to check for problems with Outlook then you could try validating it with Douglas Day's validator.
His validator not only measures your iCalendar data against the RFC 5545 specification but also advises of potential compatibility issues.
The validator is based on DDay.iCal which aims "at being as RFC 5545 compliant as possible, while targeting compatibility with popular calendaring applications, like Apple iCal, Outlook 2007, etc.".
The best solution is usually to try it. Of course, that means installing Outlook or having a friend/user you can work with who does. I realise this is often a problem, but it's really the only way to know for sure how an application will behave.
On the interop side: if you get it working in Apple Mail/iCal, GMail, and Outlook, you should be pretty good with other mailers too, from my experience.