[GroupDAV] GroupDAVv2 PROPFIND request

Helge Hess groupdav@opengroupware.org
Fri, 1 Aug 2008 17:02:21 +0200


Hi everyone,

I consider using this as the PROPFIND request for GroupDAVv2:
---snip---
PROPFIND /collection HTTP/1.1
Depth:           1
Content-Type:    application/xml; charset="utf-8"
Accept:          application/xml; charset="utf-8"
Content-Length:  xxx
Accept-Encoding: gzip
Brief:           t

<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"
  xmlns:I="urn:ietf:params:xml:ns:caldav"
  xmlns:C="urn:ietf:params:xml:ns:carddav"
  xmlns:G="http://groupdav.org/"
  xmlns:A="http://calendarserver.org/ns/"
 >
   <prop>
     <displayname/>
     <resourcetype/>
     <getetag/>
     <getcontenttype/>
     <current-user-privilege-set/>
     <G:component-set/>
     <I:supported-calendar-component-set/>
     <I:supported-calendar-data/>
     <I:calendar-description/>
     <C:supported-address-data/>
     <C:addressbook-description/>
     <A:getctag/>
   </prop>
</propfind>
---snap---
As usual this would be the sole PROPFIND request which servers would  
need to implement for GroupDAV.

The main intention is to allow a client to act as a CalDAV and  
GroupDAV client at the same time, w/o additional OPTIONS requests or  
such. It should not hurt existing GroupDAV servers, they just return  
the usual stuff.

Its has those features:

- I added the GroupDAV:component-set property which
   replaces the GroupDAV collection tags inside
   DAV:resourcetype's.
   (implementors always complained about non-flat props)
   Sample:
     <G:component-set>VEVENT,VTODO</G:component-set>

- As I said, CalDAV, ACL and CardDAV features *if* such
   are available. (NOT required)

- If the server supports it, it can return a ctag
   (like an etag, but says whether the collection
    did change)


I also seriously consider to document one specific variant of the  
CalDAV and CardDAV <multiget/> REPORTs as optional GroupDAV REPORTs  
(if the REPORT request returns 501, the client would be required to do  
individual GETs).

That would look like:
---snip---
REPORT /collection HTTP/1.1
Content-Type:    application/xml; charset="utf-8"
Accept:          application/xml; charset="utf-8"
Content-Length:  xxx
Accept-Encoding: gzip
Brief:           t

<?xml version="1.0" encoding="utf-8"?>
<C:calendar-multiget xmlns="DAV:"
      xmlns:C="urn:ietf:params:xml:ns:caldav">
   <prop>
     <getetag/><getcontenttype/><current-user-privilege-set/>
     <C:calendar-data/>
   </prop>
   <D:href>/collection/1.ics</D:href>
   <D:href>/collection/2.ics</D:href>
   <D:href>/collection/3.ics</D:href>
</C:calendar-multiget>
---snap---
I'm not perfectly happy with the REPORTs. IMHO a generic 'BATCH' HTTP  
method would be better, but getting that standardized and used doesn't  
sound realistic.
As usual the collection of HREFs would be the only variadic part of  
the request.


Opinions?
Additional requests?

Thanks,
   Helge
-- 
Helge Hess
http://helgehess.eu/