From groupdav@opengroupware.org  Fri Aug  1 16:02:21 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Fri, 1 Aug 2008 17:02:21 +0200
Subject: [GroupDAV] GroupDAVv2 PROPFIND request
Message-ID: <012FFAC4-1AB4-4A0F-B702-F864CF794741@opengroupware.org>

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/

From groupdav@opengroupware.org  Mon Aug  4 07:07:13 2008
From: groupdav@opengroupware.org (Ralf Becker)
Date: Mon, 04 Aug 2008 08:07:13 +0200
Subject: [GroupDAV] GroupDAVv2 PROPFIND request
In-Reply-To: <012FFAC4-1AB4-4A0F-B702-F864CF794741@opengroupware.org>
References: <012FFAC4-1AB4-4A0F-B702-F864CF794741@opengroupware.org>
Message-ID: <48969C91.1030908@outdoor-training.de>

Hi Helge,

both, the enhanced PROPFIND and the CalDAV multiget REPORT, make sense 
to me.

Maybe you should also add the CardDAV multiget REPORT.

Ralf

Helge Hess schrieb:
> 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

-- 
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

From groupdav@opengroupware.org  Mon Aug  4 07:08:33 2008
From: groupdav@opengroupware.org (groupdav@opengroupware.org)
Date: Mon, 04 Aug 2008 06:08:33 -0000
Subject: [GroupDAV] GroupDAVv2 PROPFIND request
Message-ID: <20080804060833.C0F3052C92C@cmsfwd02.mx.net>

<html>
<body>
<div style=3D"font-family: verdana,arial,helvetica,sans-serif; font-size:=
 10pt; color: #000000;">
<div style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: verdana,arial=
,helvetica,sans-serif">
  <div style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: verdana,ari=
al,helvetica,sans-serif">I am currently out of the office.  I will return=
 11 Aug.
  </div>
</div>
<br />

</div>

<br>
<BR>
<HR noshade width=3D"90%">
This email message is for the sole use of the intended recipient(s) and m=
ay contain confidential and privileged information. Any unauthorized revi=
ew, use, disclosure or distribution is prohibited. If you are not the int=
ended recipient, please contact the sender by reply email and destroy all=
 copies of the original message.
</body>
</html>

From groupdav@opengroupware.org  Mon Aug  4 07:16:40 2008
From: groupdav@opengroupware.org (Ralf Becker)
Date: Mon, 04 Aug 2008 08:16:40 +0200
Subject: [GroupDAV] GroupDAVv2 PROPFIND request
In-Reply-To: <48969C91.1030908@outdoor-training.de>
References: <012FFAC4-1AB4-4A0F-B702-F864CF794741@opengroupware.org> <48969C91.1030908@outdoor-training.de>
Message-ID: <48969EC8.40905@outdoor-training.de>

You also mentioned CardDAV multiget in the text, I just looked at the 
request itself, which was CalDAV.

So I'm happy with the whole proposal :-)

Ralf

Ralf Becker schrieb:
> Hi Helge,
> 
> both, the enhanced PROPFIND and the CalDAV multiget REPORT, make sense 
> to me.
> 
> Maybe you should also add the CardDAV multiget REPORT.
> 
> Ralf
> 
> Helge Hess schrieb:
>> 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
> 

-- 
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

From groupdav@opengroupware.org  Mon Aug 11 12:28:49 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Mon, 11 Aug 2008 13:28:49 +0200
Subject: [GroupDAV] Brief Header
Message-ID: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org>

Hi,

I think it would be nice if GroupDAV servers would support the  
Microsoft 'Brief' HTTP header. Its a very useful hack which should  
have no side effects on existing standards.

Its a simple HTTP request header, which looks like this:

   Brief: t

This is used to cut down PROPFIND responses, eg:
---snip---
  <D:response>
   <D:propstat>
    <D:prop>
      <D:displayname>Helge Calendar</D:displayname>
      <D:resourcetype>
       <D:collection />
      </D:resourcetype>
      <D:getcontenttype>httpd/unix-directory</D:getcontenttype>
    </D:prop>
    <D:status>HTTP/1.1 200 OK</D:status>
   </D:propstat>
   <D:propstat>
    <D:prop>
      <D:getetag />
      <D:current-user-privilege-set />
      <ns1:component-set />
      <ns2:supported-calendar-component-set />
      <ns2:supported-calendar-data />
      <ns2:calendar-description />
      <ns3:supported-address-data />
      <ns3:addressbook-description />
      <ns4:getctag />
    </D:prop>
    <D:status>HTTP/1.1 404 Not Found</D:status>
   </D:propstat>
  </D:response>
---snap---

Would be cut down to (only if Brief is set to 't'!):
---snip---
  <D:response>
   <D:propstat>
    <D:prop>
      <D:displayname>Helge Calendar</D:displayname>
      <D:resourcetype>
       <D:collection />
      </D:resourcetype>
      <D:getcontenttype>httpd/unix-directory</D:getcontenttype>
    </D:prop>
    <D:status>HTTP/1.1 200 OK</D:status>
   </D:propstat>
  </D:response>
---snap---

The rational is that it doesn't matter for the client :-) Its rather  
obvious that requested properties are 404 if they are not listed in  
any other propstat :-)


Just a minor hack, but a quite useful one.

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

From groupdav@opengroupware.org  Mon Aug 11 16:11:47 2008
From: groupdav@opengroupware.org (Wolfgang Sourdeau)
Date: Mon, 11 Aug 2008 11:11:47 -0400
Subject: [GroupDAV] Brief Header
In-Reply-To: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org>
References: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org>
Message-ID: <48A056B3.6060807@inverse.ca>

Helge Hess a écrit :
> Hi,
> 
> I think it would be nice if GroupDAV servers would support the Microsoft 
> 'Brief' HTTP header. Its a very useful hack which should have no side 
> effects on existing standards.

I agree. Returning 404 error code for missing properties looks a bit 
useless to me.

-- 
Wolfgang Sourdeau   ::   +1 (514) 755-3520   ::   wsourdeau@inverse.ca


From groupdav@opengroupware.org  Mon Aug 11 16:40:55 2008
From: groupdav@opengroupware.org (Adam Tauno Williams)
Date: Mon, 11 Aug 2008 11:40:55 -0400
Subject: [GroupDAV] Brief Header
In-Reply-To: <48A056B3.6060807@inverse.ca>
References: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org>
 <48A056B3.6060807@inverse.ca>
Message-ID: <1218469255.8286.13.camel@linux-nnci.site>

> > I think it would be nice if GroupDAV servers would support the Microsoft 
> > 'Brief' HTTP header. Its a very useful hack which should have no side 
> > effects on existing standards.
> I agree. Returning 404 error code for missing properties looks a bit 
> useless to me.

Yep.  

Once upon a time, until I asked here, I just assumed it was a bug. :)


From groupdav@opengroupware.org  Wed Aug 13 08:38:05 2008
From: groupdav@opengroupware.org (Ralf Becker)
Date: Wed, 13 Aug 2008 09:38:05 +0200
Subject: [GroupDAV] Brief Header
In-Reply-To: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org>
References: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org>
Message-ID: <48A28F5D.1090601@outdoor-training.de>

Does this "Brief" header only apply to PROPSTAT, or also to REPORT requests?

Ralf

Helge Hess schrieb:
> Hi,
> 
> I think it would be nice if GroupDAV servers would support the Microsoft 
> 'Brief' HTTP header. Its a very useful hack which should have no side 
> effects on existing standards.
> 
> Its a simple HTTP request header, which looks like this:
> 
>   Brief: t
> 
> This is used to cut down PROPFIND responses, eg:
> ---snip---
>  <D:response>
>   <D:propstat>
>    <D:prop>
>      <D:displayname>Helge Calendar</D:displayname>
>      <D:resourcetype>
>       <D:collection />
>      </D:resourcetype>
>      <D:getcontenttype>httpd/unix-directory</D:getcontenttype>
>    </D:prop>
>    <D:status>HTTP/1.1 200 OK</D:status>
>   </D:propstat>
>   <D:propstat>
>    <D:prop>
>      <D:getetag />
>      <D:current-user-privilege-set />
>      <ns1:component-set />
>      <ns2:supported-calendar-component-set />
>      <ns2:supported-calendar-data />
>      <ns2:calendar-description />
>      <ns3:supported-address-data />
>      <ns3:addressbook-description />
>      <ns4:getctag />
>    </D:prop>
>    <D:status>HTTP/1.1 404 Not Found</D:status>
>   </D:propstat>
>  </D:response>
> ---snap---
> 
> Would be cut down to (only if Brief is set to 't'!):
> ---snip---
>  <D:response>
>   <D:propstat>
>    <D:prop>
>      <D:displayname>Helge Calendar</D:displayname>
>      <D:resourcetype>
>       <D:collection />
>      </D:resourcetype>
>      <D:getcontenttype>httpd/unix-directory</D:getcontenttype>
>    </D:prop>
>    <D:status>HTTP/1.1 200 OK</D:status>
>   </D:propstat>
>  </D:response>
> ---snap---
> 
> The rational is that it doesn't matter for the client :-) Its rather 
> obvious that requested properties are 404 if they are not listed in any 
> other propstat :-)
> 
> 
> Just a minor hack, but a quite useful one.
> 
> Thanks,
>   Helge

-- 
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

From groupdav@opengroupware.org  Wed Aug 13 08:41:49 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Wed, 13 Aug 2008 09:41:49 +0200
Subject: [GroupDAV] Brief Header
In-Reply-To: <48A28F5D.1090601@outdoor-training.de>
References: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org> <48A28F5D.1090601@outdoor-training.de>
Message-ID: <0095FACE-F670-4602-A802-8D1D62837CB8@opengroupware.org>

On 13.08.2008, at 09:38, Ralf Becker wrote:
> Does this "Brief" header only apply to PROPSTAT, or also to REPORT  
> requests?


This could apply to everything which returns an {DAV:}response  
element. If Brief: t, just omit <propstat> elements with <status> 404.

Greets,
   Helge


From groupdav@opengroupware.org  Tue Aug 26 16:41:52 2008
From: groupdav@opengroupware.org (Adam Tauno Williams)
Date: Tue, 26 Aug 2008 11:41:52 -0400
Subject: [GroupDAV] Re: [eGroupWare-users] Icalsrv & mozilla lightning
In-Reply-To: <488B3BAB.6030407@inverse.ca>
References: <14737014.post@talk.nabble.com> <17693930.post@talk.nabble.com>
 <17699994.post@talk.nabble.com>	 <17704750.post@talk.nabble.com>
 <484A20E2.5010604@outdoor-training.de>	 <17708818.post@talk.nabble.com>
 <484A9D79.7020408@outdoor-training.de>	 <17737331.post@talk.nabble.com>
 <484E073A.8080202@outdoor-training.de>	 <17754502.post@talk.nabble.com>
 <485518DC.1090008@ooip.nl>	 <485769BB.1060201@outdoor-training.de>
 <18330884.post@talk.nabble.com>	 <48730CDD.2040409@outdoor-training.de>
 <D17088B4-3D6C-446B-83A7-A019FBA298F0@opengroupware.org>
 <1215514057.7677.13.camel@linux-nnci.site>
 <48734B00.4010701@outdoor-training.de>
 <1215517777.7677.14.camel@linux-nnci.site>
 <1215518763.7677.22.camel@linux-nnci.site> <4873679B.60101@inverse.ca>
 <6B6CC0B4-8877-4180-AA2D-F2255018D529@opengroupware.org>
 <487372F0.8090107@inverse.ca>
 <68AFD256-F055-471E-A2E7-AC0063283C12@opengroupware.org>
 <48737837.1020107@inv erse.ca>
 <51A194D3-E334-49C4-9C27-9EB9E75D2EBF@opengroupware.org>
 <488B3BAB.6030407@inverse.ca>
Message-ID: <1219765312.9482.18.camel@linux-nnci.site>

On Sat, 2008-07-26 at 10:58 -0400, Wolfgang Sourdeau wrote:
> More on that issue: Mozilla is dropping its webdav component library, 
> which is inefficient, incomplete and requires one Lightning 
> package/platform. This mean that the SOGo Connector will anyway require 
> a change in the way it does its webdav transactions. So this will enable 
> me to fix this particular issue as well in the same batch.

Have there been any further thoughts/developments regarding the GroupDAV
connector going forward?