Robert Chien's Blog

The next release of Sun Calendar Server will be CalDAV-based. It is codenamed "Project Aries". We have a beta instance running internally, and with some tinkering, it can work on iPhone 3.0.

To configure for Sun's CalDAV Server:

1. Go to Settings > Mail, Contacts, Calendars
2. Tap "Add Account...", then "Other"
3. Under Calendars, "Add CalDAV Account"
4. Enter account information:
   • Server: [cal.domain.com]
   • User Name: [your username]
   • Password: [your password]
   • Description: [e.g aries]
5. Tap "Next"

Here, if your CalDAV server is configured only on SSL, you might get a "Cannot Connect Using SSL" error. Just ignore and tap Save. Then edit the new CalDAV account, go into "Advanced Settings", change the port from 8443 to 443, and fix the Account URL to this format: https://cal.domain.com/davserver/dav/principals/[username]/ (don't forget the trailing slash).

Also see this entry by Arnaud on setting up against non-production CalDAV servers.

Another new feature in iPhone 3.0 software update is a built-in LDAP client. Previously, a third-party app such as Directory or LDAPeople is required.

To configure LDAP:

1. Go to Settings > Mail, Contacts, Calendars
2. Tap "Add Account...", then "Other"
3. Under Contacts, "Add LDAP Account"
4. Enter account information:
   • Server: ldap.company.com
   • User Name: [e.g. cn=First Last (employee ID), ou=people, dc=company,dc=com]
   • Password: [your password]
   • Description: [e.g. book]
5. Tap "Next"

Unfortunately, it doesn't work with Sun's book.sun.com. It gives a "Cannot Connect Using SSL" error. A reader already reported that this could be due to lack of ca-cert three months ago so looks like this might be an open iPhone bug.

Come to think of it, this could be an underlying OS X bug. Using the Address Book app in OS X 10.5 configured for book.sun.com, if "Allow self-signed certificates" is checked, lookup works; if it is unchecked, lookup fails, even though book.sun.com has a legitimate chained cert with Versign as CA.

In the meantime, if you want to use LDAPS on iPhone 3.0, the workaround is to buy a third-party app.

[UPDATE Jun 23, 2009] Bug ID# 7000490 filed with Apple.

Today, the iPhone 3.0 software update finally came out and about the first thing I did after upgrading mine was to check out the new CalDAV and LDAP functionalities.

This is how I configured CalDAV for Google Calendar:

1. Go to Settings > Mail, Contacts, Calendars
2. Tap "Add Account...", then "Other"
3. Under Calendars, "Add CalDAV Account"
4. Enter account information:
   • Server: www.google.com
   • User Name: [your username]
   • Password: [your password]
   • Description: [e.g. Personal]
5. Tap "Next"

That's it! Now you can launch the Calendar app, tap "Calendars", then select the CalDAV calendar. Events can be created or modified on the iPhone and they'll be reflected on the server instantly.

Secondary calendars: This only shows the main calendar. To get your other calendars, you'll need to repeat the above for each (with distinct Descriptions otherwise it'll be confusing), then edit that CalDAV account, and under "Advanced Settings" change the "Account URL". You can get this Account URL by clicking the down arrow next to your calendar at calendar.google.com and selecting "Calendar Settings". You should find your Calendar ID next to the XML, iCal, HTML links in the Calendar Address section. Insert this Calendar ID into an URL like so: https://www.google.com/calendar/dav/ccogk69iprl3zyfa1ijeep0oj5@group.calendar.google.com/user . You can email this to yourself, then leverage the new copy&paste feature of 3.0 to avoid typos. Why is this so cumbersome? Here's a possible explanation.

Offline access: Works in both directions. Changes are sync'd upon network reconnection.

CalDAV or Google Sync? Either way will give you read/write access to your Google Calendar. A major deciding factor is whether you already have an active Exchange account (e.g. for work), since iPhone only allows one Exchange account at any time, and Google Sync uses Exchange ActiveSync protocol.

[Updated per suggestions in the comments]

Of all the new features Apple announced today in the upcoming iPhone 3.0 update, the two that get me most excited are CalDAV and LDAP support. It's great to see CalDAV come to mobile devices finally; I hope more smartphone manufacturers and developers will follow suit.

Many people wondered why Apple doesn't allow API access to the Calendar app. I had a suspicion it was because they had bigger plans for Calendar, and if they had allowed API access to Calendar data it would have precluded Apple from making these plans happen. Then came ActiveSync support, and now CalDAV. Perhaps Apple will open Calendar API access now?

Unfortunately, there isn't a lot of detail around CalDAV and LDAP yet, so we'll have to wait until summer to find out. I wonder how offline access to a CalDAV calendar will be handled? Will it be read-only, or will changes sync back to the server? Does LDAP integrate well with other iPhone apps like Mail and Contacts? Will it support LDAPS?

[UPDATE Jun 17, 2009] iPhone 3.0 was released today and I posted a few entries related to configuring CalDAV and LDAP:

• Configuring CalDAV on iPhone 3.0 for Google Calendar
• Configuring CalDAV on iPhone 3.0 for Sun Calendar Server
• Configuring LDAP on iPhone 3.0

The answer is still no, firmware 2.0 on the iPhone does not appear to support IMAP IDLE. The push email feature works only with Microsoft Exchange, MobileMe, and Yahoo!. If you go to Settings > Fetch New Data > Advanced, and select an IMAP server, only two choices are given: Fetch [periodically] or Manual. No Push. This is reaffirmed by my IMAP telemetry log. Just like in firmware 1.x, iPhone's mail client never sends the IDLE command.

Since I installed the new firmware on my original iPhone, I've noticed drastic battery life reduction. Following Apple's advice, I turned off push email and saw significant improvement. With push email enabled, I had to recharge it almost daily; now my iPhone can go 2-3 days between charges, which is still more frequent than, but closer to my experience on 1.x firmware.

To facilitate push Email to mobile devices? I'm doubtful, here are the reasons:

First, IMAP IDLE relies on keeping the IMAP connection alive. Mobile devices are more likely than desktop clients to experience network errors and timeouts as they travel. And devices capable of both Wi-Fi and cellular, like Apple's iPhone, automatically switches from one network to the other, terminating the connection as they do so. I feel that a true push solution should not depend on a persistent connection.

Second, an IMAP IDLE session only monitors a single mailbox. If you need to watch multiple folders simultaneously (like if you use server-side filtering or subaddressing), you need multiple sessions. Is any client capable of that?

Third, maintaining the session not only drains the battery, of which mobile devices have limited amount, it also hogs the data channels so I don't think telcos like that idea very much.

Michael told me OMA-EMN uses sideband SMS for notification, so it's designed to be friendlier to battery and network operators compare to IMAP IDLE. But I've yet to come across a client that supports OMA-EMN.

Last Friday, we got a Samsung Blackjack II (not by choice) in the family and naturally, being the Chief Geek, I had the "honor" of setting the phone up. I have to say this Q/BlackBerry killer turns out to be quite a disappointment. The WM6 user interface is convoluted, the device is cluttered with AT&T junkware and the thumb keyboard feels cramped. Motorola's mobile enterprise messaging and calendaring suite called Good is a pain to use.

But the biggest turn-off is the booklet of manual that comes with the phone. Why couldn't the product designers make a feature so intuitive that it needs little to no explanation?

As WSJ's review of the Flip says: "[Devices should be] so simple, mastery is immediate, and so is your sense of pride and happiness."

The importance of that latter part is what the collective Microsoft-AT&T-Samsung-Motorola team did not understand and embrace. While they packed the smartphone with an impressive list of functionalities, they also overlooked the experience of unboxing the gadget for the first time. Result: customers are overwhelmed with features they can't use unless they read the manual first.

In contrast, Apple's approach to product design reflects in their minimalistic user manual. The entire iPhone manual comes on a single double-sided sheet with large screenshots.

If you make a consumer product, it's best to assume they won't read the manual at all.

If your product has features that are fragile or unusable without some manual reading up front, you need to rethink your design.

If you're improving on a product, slashing the existing manual by 50% or more should be a top priority. Then slash it again. Why do it if people aren't going to read it? Because the exercise forces you to create intuitive features, leading to a better experience, therefore a better product.

This is a follow-up and correction to my previous post: iPhone supports IMAP IDLE.

After more testing, turns out iPhone does not support IMAP IDLE (on a Wi-Fi connection, firmware 1.1.3), it instead Auto-Checks every 2-5 minutes despite the Setting says don't. I verified this by enabling IMAP telemetry in Dovecot 1.0 through its rawlog facility. Even though the server advertises IDLE in its CAPABILITY response, iPhone's client never issues the IDLE command.

Is that a loss? Probably not. According to this thread, beta testers of the iMapIdle utility report significant battery drain while IDLE runs on a Wi-Fi connection. On an EDGE connection, the drain is not as bad. But when iPhone switches between Wi-Fi and EDGE, the IDLE session gets dropped. For these reasons, I can see why Apple designers chose to not implement IMAP IDLE on iPhone.

Now that IMAP IDLE support in Gmail is confirmed, the logical next step is to see if iPhone supports it as well, and more importantly perhaps, how much value does it add over client-side polling? The short answer is yes, iPhone has IMAP IDLE, but updates don't come in real time. Here's how I tested it (on a Wi-Fi connection, firmware 1.1.1):

1. Under Settings -> Mail, make sure Auto-Check is set to Manual
2. Under Settings -> General, make sure Auto-Lock is set of Never
3. Open my Gmail Inbox on the iPhone
4. Create an IMAP IDLE session to my Gmail Inbox using openssl(1)
5. Send a test message to my Gmail account

I repeated the test 3 times. The messages took 2-4 minutes to show up on the iPhone so there's quite a bit of delay. Header information shows end-to-end delivery times of 3-14 seconds so the delay isn't in SMTP. In the IMAP IDLE session, the server transmitted updates also within seconds so the delay isn't in IMAP either. I believe it's fair to conclude that the delay is caused by iPhone, specifically the way it handles IMAP IDLE. My guess is the designers opted for battery conservation over speed of new mail notification.

Then how much better is push IMAP than pull IMAP? Based on the above, I'd have to say not much, at least not on iPhone.

[UPDATE Feb 21, 2008] Part 2: turns out iPhone does not support IDLE.