Friday May 27, 2011

100% XML CardDAV query

The CARDDAV:address-data request XML Element allows a client to specify in which format it wishes the address book resources to be returned via the content-type and version XML parameters (See draft-ietf-vcarddav-carddav-10#section-10.4 ).

This, coupled with the soon to be published xCard format (http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml), can be used to request a 100% XML CardDAV query response: Instead of making a request using:

 <CARDDAV:address-data/>

the client can use something like:

 <CARDDAV:address-data content-type="application/vcard+xml" version="4.0" />

The complete  Request/Response looks like:

>> Request <<


   REPORT /home/bernard/addressbook/ HTTP/1.1
   Host: addressbook.example.com
   Depth: 1
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <C:addressbook-query xmlns:D="DAV:"
                     xmlns:C="urn:ietf:params:xml:ns:carddav">
     <D:prop>
       <D:getetag/>
       <C:address-data content-type="application/vcard+xml" version="4.0"/>
     </D:prop>
     <C:filter/>
   </C:addressbook-query>

>> Response <<


   HTTP/1.1 207 Multi-Status
   Date: Sat, 11 Nov 2006 09:32:12 GMT
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D="DAV:"
                  xmlns:C="urn:ietf:params:xml:ns:carddav">
     <D:response>
       <D:href>/home/bernard/addressbook/v102.vcf</D:href>
       <D:propstat>
         <D:prop>
           <D:getetag>"23ba4d-ff11fb"</D:getetag>
           <C:address-data content-type="application/vcard+xml" version="4.0">
             <vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
               <vcard>
                 <fn><text>J. Doe</text></fn>
                 <uid><uri>xxx:12</uri></uid>
                 <email>
                   <parameters><type><text>work</text></type></parameters>
                   <text>john.doe@example.ca</text>
                 </email>
               </vcard>
             </vcards>
           </C:address-data>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
       </D:propstat>
     </D:response>
   </D:multistatus>

Now if you combine the above with the use of the "X-HTTP-Method-Override" HTTP header to wrap the REPORT using HTTP POST, you get an "almost browser friendly" CardDAV query.

Monday May 07, 2007

Liberty Alliance Contact Book Service

Spending some time on the (just expired) CardDAV Draft.

From the author's own words "CardDAV does for vCards what CalDAV does for iCalendar. i.e. it provides a set of WebDAV extensions and a data model for access to vCard objects stored on a server. CardDAV is very similar to CalDAV because of the similarities between iCalendar and vCard formats."

In the CardDAV mailing list, someone mentioned the "Employee Profile Service Specification and the Personal Profile Service Specification created by the Liberty Alliance".

So here I went, to discover that not only do they have such services, but they have also defined a Contact Book Service:

The spec defines a mapping between vCard 2.1 (http://www.imc.org/pdi/vcard-21.txt), vCard v3 (http://tools.ietf.org/html/rfc2426), vCardRDF (http://www.w3.org/TR/vcard-rdf) and a "Generic vCard" data model, itself based on some XML representation of vCards (http://www.xmpp.org/extensions/xep-0054.html). All (XPATH) queries are done against the data model but the data can be returned (or stored) in any of the other vCard formats (2.1, 3, RDF).

The spec is a little bit hard to digest for someone not familiar with the Liberty Alliance architecture and terminology but it covers 3 functionalities that I would consider key for a Contact Book protocol/service:

  • ability to sort vCards based on some field,

  • ability to group vCards together (they use the term "Distribution List"),

  • ability to get paged results (give me back the first 20 entries, then the next 20,...)

(The third feature is actually define in a more general Data Web Service Specification)

CardDAV lacks those features (but after all, it is still just a -01 draft). While sorting and paging could probably be added as extension to the base protocol, I would consider groups as a core functionality because it defines a new type of object (at least at the conceptual level).

The Liberty Alliance Contact Book Service has taken the approach of modeling groups as regular vCard entries with the membership being define in each child vCard as a backpointer to some UID (CARDID) of the group. This is in a sense similar to the notion of dynamic groups in LDAP. It is also the model that we had adopted a few years back for our proprietary (and private) WABP protocol.

A few other interesting things in the Contact Book Service:

  • ability to tag one vCard as describing SELF (the owner of the book),

  • notion of a predefined "Favorites" group,

  • notion of most frequently/recently requested entries.

I have not spent a lot of time trying to get an in depth understanding of the Liberty Web Services. But my initial feeling is that I don't really see the CardDAV protocol and the Contact Book Web Service as competing technologies. On the other hand, keeping them close enough so that one could "easily" build the Web Service on top of protocol would be nice.

BTW, the Liberty tutorial mentions calendar access as a potential new service ! I don't know if any active work is underway to define such a service but it would be interesting to compare  it with CalDAV...

About

arnaudq

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today
Bookmarks