Principal URL
So, just what the hell is a Principal URL, anyway?
Some ultimately-fruitless Googling lead me much of nowhere on this question. I've manually configured dozens of phones with my own two thumbs, and the Account Setup on iOS doesn't even begin to mention a Principal URL. The best thing I came up with showed how I could potentially extract this information from an iPhone backup via its Address Book's SQLite database.
Trampling headfirst into someone else's absurd DB schema isn't my idea of fun.
So I'm digging through this database, with Google Apps for Business telephone support on my ear the whole time. He had never even heard of a Principal URL. The guy wasn't dumb, either. And then my power went out. I knew I should have plugged my desktop into my UPS, but alas, it's in my server room and I'd probably trip over the extension cord more frequently than I would lose my utility service :P
So after throwing my hands up in frustration, I came back to it hours later and went with my gut instinct, finding the solution myself...
Problem Solved -- Or TL;DR:
As the picture above suggests, for the Principal URL field in the iPhone Configuration Utility... just leave it blank.
Digging Deeper
During my search on how to fill this field out, I found myself deep in one of my nerd-favorite things to do: Ctrl-F'ing through RFCs because they're the only thing that comes up on a web search when I try to look for some answers. It's like Apple themselves doesn't even have a KB article on it... Hey everybody! Look! It's a bunch of confused admins! :-\
So digging around RFC 6352 shows that servers supporting CardDAV:
SHOULD support the DAV:current-user-principal-URL property as defined in RFC5397 to give clients a fast way to locate user principals.
Fortunately, Google's implementation of CardDAV appears to have taken that recommendation. If I'm reading it right, RFC 5397 provides a standard method to allow a DAV-type client to query the server to determine this URL. I can only really speculate that this URL is some type of shortcut that a DAV client can utilize to keep its exchanges with the server short and sweet; when you're interested in maintaining authentication with a server and don't want to fool around with cookies, unique HTTPS links make a vastly simpler substitute.
SHOULD vs. MUST: Why You Can Leave It Blank
That's the fun thing about RFCs: they're very explicit with their use of language. Since a CardDAV server only should provide an easy method for discovering this URL, then there's a possibility that the CardDAV server you're provisioning your iPhones against won't support Principal URL discovery. If it was something that all CardDAV servers must support, that would be a different story. Since the possibility exists, though, the iPhone Configuration Utility gives you the option to fill it in.... it just doesn't bother telling you how unlikely it is that you would need to.
Closing Thoughts
It'd be nice if I could test the settings inside of the configuration app... but that's probably asking too much from Apple. A determined individual could probably test a WebDAV, CalDAV, or CardDAV account's credentials with cURL---the entire point of the protocols is that they piggyback on HTTP!
Ease of use actually seems to go down the closer you get to Enterprise-grade tools with Apple. I can't even configure an Exchange account for Mail only, I had to instruct my user to shut off Contacts and Calendar sync after he installs the profile.
As long as you're somehow involved, the farther you are from the exchange of money that got you involved in supporting Apple's products in the first place, the more of a pain in the ass things seem to become. I guess I could write a script to hammer out a bunch of unique configuration profiles for me, but quite frankly, programming the tools I have to use so that they make my job easier... isn't my job. When it comes to iOS devices, it's Apple's. The lockdown of their platform (which is, I'm sure, the only reason I can't just remote into the f***ing phone and configure it on the fly like I do with REAL computers) tells the truth of this much louder than their continually-shrinking market share ever really could.
No comments:
Post a Comment