UPDATE 2 4/8/2012: It’s been a year and a half (almost), but Apple finally fixed CalDAV SRV record discovery in, I believe, iOS 5.0.2 (and therefore 5.1). So all of this is now completely valid, and supported by Apple (finally)!
UPDATE 12/18/2010: It’s taken me a bit to post this (sorry), but I can say that iOS 4.2.1 (the released version of 4.2) supports discovery of CardDAV servers over SRV records. However, CalDAV does NOT work. I’ve been told by people in the know that it’s coming, it just didn’t make it into 4.2.1. Now, I have no idea why… one would think it’s the same back-end, but who knows. Anyway, CardDAV works, CalDAV doesn’t, but hopefully 4.3 (or whatever they call it) will fix that.
Part of being a systems administrator is making the life of your customers easier. Whether it’s having a file share auto-mount when they login, having to only remember a single password (or just having to login once via SSO), or in this case, not having to remember what server provides what services. So, over the past few days I’ve been playing with autodiscovery of CalDAV and CardDAV for Mac OS X and iOS.
Address Book and iCal in 10.6 use SRV records nicely. If I tell iCal that my server is www.example.com, and I have an SRV records that say:
_caldav._tcp.www.example.com. 86400 IN SRV 0 0 8008 caldav.example.com.
_caldavs._tcp.www.example.com. 86400 IN SRV 0 0 8443 caldav.example.com.
iCal magically figures out that my actual caldav server is caldav.example.com (it defaults to lookup caldavs first, then caldav if caldavs isn’t available). I have a similar SRV record set up for CardDAV:
_carddav._tcp.www.example.com. 86400 IN SRV 0 0 8800 carddav.example.com.
_carddavs._tcp.www.example.com. 86400 IN SRV 0 0 8843 carddav.example.com.
And once again, Address Book on 10.6 magically figures it out (again, defaulting to carddavs and falling back to carddav if carddavs isn’t available).
The PROBLEM is that iOS (iPhone 4, 4.1, and from what I can tell, 4.2b1) don’t pay attention to SRV records, at all (Submitted bug 8447498 with Apple). They look for http(s)://www.example.com/.well-known/caldav (or /.well-known/carddav). And if they can’t find those, it tries /, then /principals, then /principals/
Thing is, I’ve tried just about every type of redirect I can figure out that redirects www.example.com/.well-known/caldav to caldav.example.com, but no matter what, iOS keeps trying to login to caldav on www.example.com. So if it gets a 301, it doesn’t pay attention, it just keeps trying.
The RFC for /.well-known/ (here) just establishes a registry for .well-known. For all we know, iOS is looking for actual data inside that caldav or carddav file in /.well-known/ rather than just a 301 to the proper location.
I’m going to keep playing with this over the weekend, and in my free time for the next few weeks. I’ve emailed a couple Apple mailing lists, and I’ll probably shoot an email or two to some Apple employee friends and see if they can point me in the right direction. I think I need to find an iOS dev (or register myself) that can look up the discovery information in the dev docs (if it’s documented).
Some more discussion on this can be found: here. Will follow up when I know more…
On a related note, I also set up SRV records for imaps, pop3s, smtp, and submission, like the following:
_smtp._tcp.www.example.com. 86400 IN SRV 0 0 25 mail.example.com.
_imaps._tcp.www.example.com. 86400 IN SRV 0 0 993 mail.example.com.
_pop3s._tcp.www.example.com. 86400 IN SRV 10 0 995 mail.example.com.
_submission._tcp.www.example.com. 86400 IN SRV 0 0 587 mail.example.com.
Alas, nothing seems to support discovery this way yet. Tomorrow, I’ll post about how you can make Mail.app in 10.5 and above auto-configure mail accounts for users based upon their email address (like Mail.app does for @mac.com, @me.com, @gmail.com, etc).