All right, good afternoon, everyone, and welcome to the Address Book Server session. So this is a new product that we introduced yesterday. Oops, I don't have my slide yet. There I am. I'm Juussi Mantere. I'm the engineering manager for Address Book Server, and this is our agenda today. So we are introducing a new component in Mac OS X Server, which will ship as part of Snow Leopard, and that is Address Book. So we have all these collaboration applications. So we have mail, we have calendar, we have chat, we have Address Book.

So these are all the client applications. And, of course, on Mac OS X Server, we have corresponding server pieces. So we have server for mail, we have server for calendaring, we have a server for chat, and there is something missing. Like, what's wrong with this picture? And to get us where we need to be, we are introducing the Address Book Server. So the fourth leg in our server component to support Address Book sharing and server-stored Address Books.

When we were developing the Address Book Server, we looked at the various options on how to actually create a system to store your contacts in. And we looked at LDAP, so Lightweight Directory Access. Yeah, that's probably good for accounts, but accounts are not contacts. And directories are rarely writable, so you don't necessarily have write access to the directory.

And adding attributes or elements into your directory, like if you want to store a field that's not supported by the LDAP schema, that would be challenging to get your directory administrators to add schema elements is usually an uphill battle. And lightweight, yeah. I think hippopotamus is lightweight compared to an elephant. Like LDAP is lightweight compared to X500. Still lightweight if you want to do open directory, open active directory.

If you want to do open directory, e-directer compatibility, the lightweight kind of goes out the window and it really becomes a heavy framework to deal with. And other choices, so let's see OpenID. So new emerging standards, open authentication. Well, the name pretty much says it all. Authentication, that's identity and logging in credentials. It's not really contacts. Other things, Google. So Google just announced some months ago their contacts data API.

The problem with that is it is proprietary. So if you're willing to trust the Google Cloud, great, good for you. But doesn't necessarily do much for interoperability or ability to take your contacts out of that back end and put them into another back end. Ditto for Yahoo. So Yahoo just introduced an address book API as well. Suffers pretty much the same issue as Google where it is proprietary to that one vendor. So.

So we already have some experience developing dev-based services. So if you look at how the calendar client talks to the calendar server on Mac OS X Server, it's using CalDAV, which is another recognized protocol. There's an RFC for that. And it's leveraging web dev and using the iCalendar data format. And we have a client server service. And to do CardDAV, this pretty much fits the same model. So we have, again, the dev foundation.

And instead of doing a payload for calendaring, we have a payload for contacts. And out of that comes CardDAV. So this pretty much follows the methodologies we've already set in place for other services that we offer. So we're leveraging all the backend work that we already have in place when we implemented the calendar server. So we can reuse pretty much our expertise in developing this solution.

So, Address Book Server, new in Snow Leopard. So, what do we get with this? This is a server for your contacts. Any contact, be it public, private, allows you to share contacts, allows you to search on the server, and the solution is standards-based, which means that other clients that will come out there or other servers that will implement CardDAV will all interoperate, just like you have interoperability with CalDAV, or let's say, web, which is kind of interoperable from client server. Or mail clients talking to mail servers. So, this is probably the right choice for the long term.

How do you use the server? On the client side, we use Address Book. The Address Book Server on Mac OS X Server can be directly used from Address Book on Mac OS X Client. Instead of having all your contacts stored locally, we now have an option to point the Address Book Client to an Address Book Server and gather your contacts from there.

And of course, just like with Mail and iCal and iChat, you can have multiple accounts that are offered through the Address Book. So you can have one server that is your primary Address Book Server, and you can have other servers that you can connect to to store other contacts that you don't necessarily want to store on your primary server.

And this behaves as you'd expect. So it's just like using Address Book with local contacts except now everything's stored on the server. So editing works, creating groups, creating shared groups, and you can access the contacts you have from any client, be it from a system at home, be it a system at the office, or a mobile device that will support CardDAV. And like any account, it's just another account and you can have multiple accounts inside Address Book.

and application support. So out of the box, any application that uses the standard Address Book interfaces to match, let's say, autocomplete for you, Mail does that because it's already hooked up into Address Book calendar and chat as well. So you get application support for free. So any contacts that you store on the Address Book Server will become all immediately available on the clients when they just support the Address Book APIs to navigate your contacts.

And when will we ship this? So this will be part of Mac OS X Snow Leopard. So we don't have a version of the server in the current seed build that you have. So if you're not an ADC member who has access to the seed builds, please sign up and get your status in such a state that you can receive future Snow Leopard builds because we will be seeding builds of Snow Leopard with Address Book Server built in in the future, but it's not in the current build that you received at the developer conference. So up your membership if you need to do so. Open source.

Just like with the calendar server, we will release Address Book Server under Mac OS Forge. So this will be under the Darwin license. And we will have this just like you can have the current calendar server implementation. It will be available on the site we have for Address Book Server, which will be addressbookserver.org. The site isn't up there yet, but once we have something to show for you, it will be there. And with that, let's talk a little bit more about CardDAV and let me introduce Bruce Gaya, who is the lead engineer for the Address Book Server. Bruce.

That was so good. Good job. Okay, we're going to talk about CardDAV. So CardDAV, it's actually a very thin layer on top of WebDAV and vCard. I have a picture here of WebDAV. When I mean WebDAV, it's a modern WebDAV server which has ACLs. Of course, WebDAV uses XML. It's on top of HTTP. So we get this thin layer on top of that, and that's CardDAV. And one of the things it does, it defines Address Books as collections of vCards. WebDAV collections. And they can only contain vCards, nothing else.

There's a data model, which we'll get into a little bit more in a later talk, which we're going to describe where the address books will be found and what the URLs will be. and the other thing CardDAV does is support reports. And reports mean queries. So it means it defines how you can query Address Book Server and get various vCards back.

Okay, this is the full name of CardDAV. Vcard Extensions to WebDAV, and this is the name of the current internet's draft. It's an IETF draft on the standards track. You can look it up, read it yourself, and it depends on these things. And what I mean depends here, if you read RFCs, these are the things which a valid CardDAV server must implement to be valid.

First of all, Vcards, WebDAV Class 3, that's a modern WebDAV server, and for those of you, what really WebDAV is, it's an internet, I would call it an internet or HTTP-friendly file service. WebDAV Access Control Lists. This is going to allow our Address Book Server to have various access controls on various address books. So we can have public address books, private address books, shared address books using the ACLs.

SSL, TLS, this will give us stream encryption so you can access your Address Book Server securely. And ETags and WebDAV versioning. ETags are like change IDs and that with versioning will allow our Address Book clients or your Address Book clients to cache vCards locally from the server and when you get offline you can use them, make changes.

When you get back to the network you'll be able to upload those changes and see what has changed on the server. The Make Collection Extension, this is one of those things in the RFC that you should implement and our Address Book Server will implement this. It's simply a method so that you can create an address book on the server and that's the name of the internet draft.

Okay, let's talk about vCards. Ubiquitous, it is a ubiquitous standard for storing contact information. So let's see how ubiquitous this is. So would you raise your hand if you've used vCards? Okay, look at that. Is there anybody whose hand didn't go up? There's no one. Okay, so that's why I say it's ubiquitous. We're all using this. It's been around since 1995. Versit cards. Juussi gave some of the history of that.

Essentially, when you look at it, it's a key value property list. If you look at this example I have here, there's various properties such as FN, that stands for full name, N stands for name, there's email, telephone, various other things. And the RFC defines how those things are stored, what those property names are.

In CardDAV, in address book collections, each vCard must have a unique ID, In the vCard standard, one unique ID is supposed to be associated with a real object, like a real user should have the same UID in all of his vCards. And in our Address Book Server, there'll be multiple address books. So essentially, you can have the same vCard in many places.

The vCard standard properties, non-standard properties start with X and that will allow us to be forward compatible with a new standard which is coming along which is vCard v4.0. I should have said CardDAV supports vCard 3.0. It has some limitations. There are some new things coming in 4.0, and here is the name of the IETF draft if you want to look at what's coming in vCard 4.0. Okay, let's look at the CardDAV data model. Okay, this is the whole thing. Two main things I'm going to go in here, principles and address books. So let's take a quick look at principles.

So what are principles? Well, the users and groups-- and I have a picture here which shows three users. The Address Book Server is going to get these users from a directory service. And in our Address Book Server implementation, we're going to be using the OS X Directory Services API.

And if you're familiar with that API, it has a back-end plug-in architecture such that through that API, we can access all sorts of address books. We can access open directory-- excuse me, I should say we can access all sorts of directory services. We can access open directory. We can access access directory, LDAP, Apache. Or you can have an XML file which defines users and groups. Groups are the same thing-- excuse me, another form of principles. A group essentially contains users.

Now what does a principle mean? A principle is someone who can live-- is an object which can be in the access control list of WebDAV. And also, when you authenticate, you authenticate as a principle. So you can authenticate to an Address Book Server as a principle, let's say, the user. So let's now look at a address book with the address book arm of this graph.

So, in our Address Book Server, we're going to have a collection called Users, and in that users collection will be various users. I have a home icon there, and that's just a collection point for the users, because a user can have multiple address books. If you look at the user Bruce here, there's three address books. One's called Address Book, because that happens to be the name we're using in our current implementation. Another one called Public, and there can be more address books. And in each of those address books will be various vCards, and each of the vCards will have a unique URL.

OK, now, I said that the address book is-- OK, let's get this right. So we've got CardDAV. CardDAV is based on WebDAV, WebDAV ACL. That means that each of these address books can have various access controls. So in our address book server, how we plan to do this is a user's primary address book will be readable and writable to that user. But other people will not be able to see cards in that address book.

But we have another address book here belonging to the user called Public. And that address book, the user will be able to read and write and make changes in, add and delete vCards. But other people will have read-only access to that. So this will allow the user to have his own private address book on the server and then have a public address book which others can see so he can publish contact information to everyone else.

So now let's look at groups. So I have three groups here, engineering, management, and staff. In our Address Book Server, each of these groups are principals, and each of these can have associated with a number of address books. I have here an address book called Lunch Club, and I have one vCard in that-- or three vCards. The first one's called Beatrice. And they each have a unique URL.

So because we can assign access control list to all of our address books, what we're going to do is have it so that everyone in the group can read and write to these address books. There's no one person who owns it. Everyone in the group owns it equally. And then, as our implementation goes on, we'll have to make decisions about this.

But we have the opportunity to have different access controls on each of these address books or group address books. And so that will allow us to have shared address books shared across the group. We can decide later-- we haven't decided yet-- whether the whole world will have read-only access or whether it will be private to the group. But we are going to do that. We're going to make those decisions and hopefully do a good job in our address book server implementation. So let's look at the data model in full once.

and let's talk about CalDAV reports. The other thing CalDAV defines as reports, reports are queries. They're two queries. Address Book Query, that returns vCards that match a given filter. So you can have a query which says, "Show me all the vCards in a particular address book that have the nickname, let's say, 'me,'" and it will return you all the address books. Excuse me, all the vCards that match that filter. You can also specify which vCard properties you can return and use that to save data traffic to the server. There's another call, a companion called Address Book Multi-Git. It returns a set of vCards by a DAV href.

It also only returns the specified properties. And unlike the Address Book Query, you can target this at the entire address book collection. So if you're writing your own client, you could kind of use it this way. So someone could type something in an address book query, an address book search, and the server would come around and return all of the vCards which match that query.

Now, when you're making that query, if I was doing this, I would only get the properties out of the vCards that really matter to the HI. I wouldn't get all the properties. But then later, if the user selects a few of those address books and drags them to his server-based directory, you now need to do a copy. So you could turn around and make the address multi-git using the information returned in the first call. And in this call, you can get all the properties back. So this is kind of a data-saving technique using these two calls.

I'm going to do a quick example. This is an address book query example. One thing I'd like you to note is that's it. So it's very simple. That's the whole query. If we look at the filter, there's the filter. This filter says, "Find the nickname properties which match the string me, M-E." And right above it, that's where you get to decide what properties you're going to get back.

In this case, just five properties. So I make that call on the request, and I get a response. And if there's only one vCard that matches, here's the response. That's all of it. See how simple that is? And just by looking at it, you can find the vCard information right there.

So I want to have a word about the Address Book implementation. Since we're in the same company, there's another server out there and it's called Calendar Server and it has a fully compliant WebDAV implementation already. So we are going to use that WebDAV implementation and then we're adding CardDAV elements on top of that to make our own server.

So the whole thing is coded in Python using the Twisted Framework. We will make a fully compliant CardDAV server with all the good stuff that happens when you have a fully compliant WebDAV server. We will be using the directory service, the open directory APIs to get our principles, users and groups.

And of course, when you use that API, you get to be put back in plug-ins, which means we can go to Active Directory, etc., all those different things, XML, Apache, whatever you like. And we will get all the rich authentication and authorization services that is associated with OWA. OS X Leopard server.

So I have some reference material. If you want to find more information, this is the first one is where we're going to be posting our sources. And if you want more information of Twisted and Python, get those. Or you can Google them. And here is another slide which gives the exact link of all the RFCs which I've talked about during my portion of this talk. I'll leave it up there just a minute. And then we're going to have Juussi come and give us a demo.

All right, thank you, Bruce. So if you can go to the demo system. So this will be demo three, please. Before we do this, could have a show of hands up. So you all came here to hear about the Address Book Server. So could have a show of hands of how many of you are interested in the client side of the Address Book Server? As in like, I just want to be a user of that.

Could I have a show of hands, please? Okay, that's about half the crowd. What about either, let's say, server-side implementation? Like, you're interested in, wow. Okay, we have more server people than client people, so we'll have lots of CardDAV servers out there. So this is going to be just a short demo of the client-side feature. So this is how Address Book Server is integrated into the client.

So the way we use Address Book and CardDAV inside OS X, and this is a preview version of Snow Leopard client, and this is not on your Snow Leopard DVDs either. So again, I implore you to get the seeds once they come out in the later. And the Address Book integration will only be on the Snow Leopard shipping DVDs, so this will not be open-sourced. This will be directly integrated into Address Book itself. And no open-source components there, so the client-side components are still only in the Apple products and not on Darwin or OS X Forge.

So let's see what we have here. So this pretty much looks like the address book as you'd expect. So there's nothing really new. I have contacts, I have one company. I could have multiple companies, but this time I just happen to have users here. And the only real difference between the regular address book in Mac OS X Leopard and here is that I really don't have many contacts on my local system. So I have a few contacts here, but only two of them are really local.

Well, three. That's all I have. Everything else is stored on an address book server. So here I have one address book server that I have configured for my primary address book contacts. And just for the WWDC show, I have created another configuration, which is tied into the WWDC address book server setup.

So here we might have a different set of users. So let's say my primary address book is stored at my company's site or at my home site or office site. And this WWDC server could be more like an ad hoc server. So something that's set up once and after the show is done, then it's turned on. It's primarily to share contacts with a work group that you're working on or working with at this time. Or it could be a long-term server.

So you could have your ISP, for example, offer a address book server in their setup, just like you have services like Mail and iChat and web offered to you by your ISP. Your ISP could also offer address book services to you. So that's where we have the two servers. So, let's see.

If I look at what the Address Book Server contains, so I have several address books that are now shared. So for the WDC server, I don't really have any private contacts that are just my contacts that I only see. Most of the contacts that I have on the WDC server are shared. So these are shared address books. Anyone who is a member of this group can edit, modify, add, delete members of this group or the contacts in this group.

So I have one address book group or shared address book for our speaker support staff and one for our presentation team. So this could be our list of reviewers of slides or webcasts. And let's say I wanted to add -- I know that we're missing a person from the support staff, and it's obviously not Steve Jobs. It might be Xavier. So I have his V-card information here.

So all I need to do to get him to add it into the shared address book on the server is I can just drag it, drag the V-card into the shared address book, and right now it's available for everyone who is a member of the group. So the next time the other members of the team log on to the server or bring up their address book client, they'll get the up-to-date information.

And same for me. If anyone else updates the contact information on the server, I will get those updates to my client as soon as they're, again, available. And let's see how the address book context that I have are used in an application. So if I go to the mail application, oops, did I just kill mail? No, there is mail.

So in mail, obviously everybody is used to using autocomplete to address messages. So if I autocomplete just typing a few letters, these actually translate into Address Book Server queries. So these contacts are not stored in my previous recipient's list. They're not stored on my local address book. These contacts come from the Address Book Server contacts. So anything that I see here is actually server originated. So that's pretty much the way you'd expect Mail to work with Address Book, and Address Book just gets this functionality for free, or the clients get the functionality for free.

And that's mail. So what if I'm offline? So the queries go back to the server, but when you're offline, actually the contacts that you have on the server, they are cached for offline use. So anything that I had in my private address books, anything that I had in the shared address books, all those contacts are stored locally.

And if I'm disconnected from the network, you can still use mail auto-completion and addressing from the local cached copy of those addresses. So you're not stranded without a network connection. So if you don't have access to the cloud, your server is down for whatever reason, you still have access to the contacts that you had previously in your address book. So you can still use mail auto-completion and addressing from the local cached copy of those addresses.

So here, Address Book's actually populating the server here. And I know that I should have a contact for John here. So let's look for John. And the only John I have is John White. But I know there's supposed to be another John. And the reason I'm trying to find this person, I know I want to carry his contact information on my local Address Book so that it will then be available to me offline. So if I only have one John in my Address Book, then I need to search the Address Book Server for more contacts. So here, I can just query.

and I are going to query the server for other users called John. And it looks like we have quite a few. So these contacts are now queried through the CardDAV protocol against the Address Book Server. And this is the view of the search that you got back from the server. And these are just vCards.

So anything that I see here, I can treat it as if it was a vCard. So obviously I can use drag and drop. So let's say I'd want to add John Dewberry into our presentation team. So all I have to do is take his vCard and drag him into the shared address book. And here he is.

So John's contact information was directly added into the group there. And again, any other client that is connected to the same address book into the same shared group will get this updated information as soon as the clients connect with the server again. So your contact's available from anywhere, accessible offline, and directly integrated with all the applications.

and others have done a big improvement over having your contacts stored locally without really disrupting your work behavior. So anything that you'd expect to work with addresses still works, except now you have the cloud to store your contacts on. So with that, let's move on to the slides, please. and let me introduce Sarris Dabou, who is the author of Mulberry. and Sauris is the author of the RFC for CardDAV and also an Apple engineer. So, Sauris. Thank you, Juussi.

Obviously, one of the biggest goals for adopting an open standard is interoperability. We want to be able to have different clients and different servers work together to get addressed contact information between clients and between servers. So what we want to show now is two different clients talking to the Address Book Server.

So here I am, and this is the Mulberry client, and this is set up with an account for the same WWDC Address Book Server that Juussi was just showing us. So if I actually log in here, it will actually pull up the My Contact section of that address book that we were looking at before. So looking at this address book, I see that there's no contact information for me in here, so I'm going to go ahead and add an entry for myself.

is going to click OK, and Mulberry has just written that contact up to the Address Book Server. So now I'm going to switch back to our other machine here, and I'm going to fire up Address Book again. and just give that a second to catch up. And if we now look at the WWDC account, we can see that contact is now accessible by Address Book on the other machine. So one contact stored on the CardDAV server, accessible from different machines, different clients.

And again, I can go in here and I can make an edit on this one. So I'm gonna just change the domain here. make that change and Address Book has just gone and written that back up to the CardDAV Server. If I switch back to my other machine and I get Monbre to refresh the Address Book, you can actually see in here that we have the new address.

So again, two clients working together. You can edit on one, edit on the other. Changes get propagated back to the server, stored in that central location. No need to worry about synchronization and missing fields, et cetera. The protocol, the client access of the protocol, allows you to synchronize changes. You can spot when another client has made a change, and you can pull down those changes and merge them locally.

One of the other things we want to do, just to emphasize the fact that this is a HTTP and WebDAV server underneath CardDAV, we can go ahead and actually pull up Safari and point it to the Address Book Collection that we were just looking at in each of these two clients. So this is Safari.

I have it pointed to -- This particular URI here, which is the actual address book collection on the WebDAV server. And there are several vCard files that are actually stored on the server. Now I can go and just download one of these. And if we have a look at that.

And I can open that up in TextEdit down here. And indeed, that's the vCard that I created and stored on the server. And you can just pull that down using regular HTTP protocol that get operations through the web browser to pull that down. One other thing to note, this is, you know, it's a WebDAV server, so at the top we see the collection listing, which shows the actual contacts that are stored in the Address Book.

And below that, the server is actually exposing some of the WebDAV properties that are also stored on this collection. So you can see the basics of WebDAV there. One more thing to, again, emphasize the fact that it is WebDAV. Another thing you can do with a WebDAV server is you can actually mount it in the finder.

So if I go to connect to server here, I conveniently have the address for this server already set up. So I can click connect there and give it a second. And that's just what we're seeing here is, you know, the finder viewing the data that's actually on the WebDAV server.

This is actually a different Address Book collection, which is why you're seeing a lot more contacts in there. And one neat thing you can also, you can obviously do in the finder is just pull up Cover View and you can view your contacts in that way. And that's it for me. So back to Yussi.

All right. Thank you, Cyrus. So that's just proof that we have these clients to interoperate. There are other clients out there such as Malibri that already talk CardDAV. So it's all up and coming and hopefully will be in your hands very soon. So to summarize. We are introducing the Address Book Server and will ship as part of Mac OS X Leopard.

Your address book anywhere. So this is basically your address book on the cloud. Can be any kind of addresses, either private, public, or shared. You can create shared address books, as many as you want, and have everyone that you're sharing your contacts with be up to date and also get updates from them to the contacts that you have stored in your address book.

And it is, the Address Book Server is tightly integrated with the Mac OS X client for addresses, Address Book. So all the applications that you'd expect to work with contacts and addresses will work seamlessly with contacts that you have on the Address Book Server. So Mail, iChat, and iCal all work as you'd expect.

And for offline use, we use caching. So any contacts that you have stored on the Address Book Server will be accessible to you even when you're disconnected from the network because they are cached locally. The Address Book Server, as well as the client pieces of the Address Book application, are based on the Card Dev emerging standard for vCard sharing over the network. And as I said, we'll be part of the Snow Leopard version of the Mac OS X Server. And also the server components will be made available via Mac OS Forge and under... excuse me, idrisbookserver.org.

So that's the session. For more information, please contact Mark Malone, who's the evangelist for internet technologies. For more information on OS X Server, please go to the server site. And there's a lab tomorrow. So if you'd like to meet some of the engineering team, we are at the IT lab tomorrow at 3:30.

And there's also an Address Book Client Lab. I believe it's on Friday. So if you check the lab schedule, if you want to know more about the client side functionality for how to have applications access the contacts that are in Address Book, there's a lab for that later this week.