Thoughts on relation to WebDAV

Hi,

here are a few thoughts about how to handle the WebDAV
dependencies of 
CardDAV (mostly based on what was discussed in the VCARDDAV
WG meeting 
in Philadelphia):

1) WebDAV base requirements

I think CardDAV should require WebDAV level 3 support, as
defined by RFC 
4918. It seems there was some confusion about what level 3
actually is: 
although 3 > 2, 3 does *not* include locking, it's just
level 1 plus a 
few RFC 4918 extensions. And yes, it would be really great
if Apache 
mod_dav would incorporate these few extensions.

2) Extended MKCOL, Reporting, Syncing

There are several things where CardDAV would benefit from
generic WebDAV 
extensions, most of which are covered by Cyrus' proposals:

- using MKCOL to create "special" collections
(instead of inventing new 
methods all the time) 
(<http://tools.ietf.org/html/draft-daboo-webdav-mkc
ol-00.html>)

- potentially extract the REPORT method definition from
RFC3253, and 
move it into a separate spec, including clarifications

- enhancements for syncing; Cyrus has proposed a new REPORT
for this 
(<http://tools.ietf.org/html/draft-daboo-webdav-sync-00&g
t;); I think we 
should try come up with a more generic solution to the 
GET-unfriendliness of PROPFIND and REPORT 
(<http://tools.ietf.org/html/draft-reschke-http-g
et-location-00> and 
<http://greenbytes.de/tech/webdav
/draft-reschke-http-get-location-latest.html>).

3) Where to discuss

I think it would be great if we would discuss everything
that is not 
strictly related to CardDAV on the WebDAV mailing list (it's
still an 
IETF mailing list, after all). This would help us to avoid
introducing 
special solutions where generic solutions are needed.

These specifications still could be working group items; I'm
neutral on 
whether they need to be, as long as they are developed in an
open way, 
and get the necessary attention from the IESG when done
(hint, hint).

BR, Julian

(crossposted to vcarddav and webdav mailing list)

On 23.04.2008, at 16:25, Cyrus Daboo wrote:
> suspect push notifications for WebDAV will need to
integrate with a  
> more generic notification protocol/service that many
different  
> protocols can use (IMAP etc) so that may well require
its own WG.


I haven't read anything about WebDAV push so far (are there
any  
documents available on it?).

Do you already have an idea on how to approach push in an
HTTP  
environment?
Comet like open connections?
XMPP?
Exchange SUBSCRIBE/NOTIFY, possibly support for httpu?

Thanks a lot,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

On Sat, Mar 15, 2008 at 11:55:44AM +0100, Julian Reschke
wrote:
> 
> Hi,
> 
> here are a few thoughts about how to handle the WebDAV
dependencies of 
> CardDAV (mostly based on what was discussed in the
VCARDDAV WG meeting 
> in Philadelphia):
> 
> 1) WebDAV base requirements
> 
> I think CardDAV should require WebDAV level 3 support,
as defined by RFC 
> 4918. It seems there was some confusion about what
level 3 actually is: 

I think this is a big error, requiring all that stuff.
Consider if one
would want to implement read-only CardDAV implementation.
Why should one worry about locking, MKCOL and the other
stuff?

-- 
Petr Tomasek <http://www.etf.cu
ni.cz/~tomasek>
Jabber: butrusjabbim.cz
SIP: butrusekiga.net

Petr Tomasek wrote:
> On Sat, Mar 15, 2008 at 11:55:44AM +0100, Julian
Reschke wrote:
>> Hi,
>>
>> here are a few thoughts about how to handle the
WebDAV dependencies of 
>> CardDAV (mostly based on what was discussed in the
VCARDDAV WG meeting 
>> in Philadelphia):
>>
>> 1) WebDAV base requirements
>>
>> I think CardDAV should require WebDAV level 3
support, as defined by RFC 
>> 4918. It seems there was some confusion about what
level 3 actually is: 
> 
> I think this is a big error, requiring all that stuff.
Consider if one
> would want to implement read-only CardDAV
implementation.
> Why should one worry about locking, MKCOL and the other
stuff?

In that case you would simply return 403 Forbidden.

Anyway, what does this have to do with the question whether
CardDAV 
should require level 1 or level 3?

BR, Julian

On Thursday 22 May 2008 15:55:36 Petr Tomasek wrote:
> > I think CardDAV should require WebDAV level 3
support, as defined by RFC
> > 4918. It seems there was some confusion about what
level 3 actually is:
>
> I think this is a big error, requiring all that stuff.
Consider if one
> would want to implement read-only CardDAV
implementation.
> Why should one worry about locking, MKCOL and the other
stuff?

I think you're confused (as I was) about what class 3
implies. It does *not* 
imply locking. This is the very confusion that Julian is
talking about.

I wonder where you got the strange idea that class 3 would
include MKCOL. 

On Friday 23 May 2008 08:00:11 Simon Perreault wrote:
> I wonder where you got the strange idea that class 3
would include MKCOL.
> 

Woah, that didn't make a lot of sense. Let's try again:

I wonder where you got the strange idea that class *1* would
*not* include 
MKCOL. 

...sleepy...

fre 2008-05-23 klockan 09:21 -0400 skrev Simon Perreault:
> On Friday 23 May 2008 08:00:11 Simon Perreault wrote:
> > I wonder where you got the strange idea that class
3 would include MKCOL.
> > 
> 
> Woah, that didn't make a lot of sense. Let's try
again:
> 
> I wonder where you got the strange idea that class *1*
would *not* include 
> MKCOL. 
> 
> ...sleepy...
> 
There is no MUST in RFC4918 for the MKCOL Method so class 1
does not
include MKCOL as far as I can see.

/Henrik

On Friday 23 May 2008 09:36:46 Henrik Holst wrote:
> There is no MUST in RFC4918 for the MKCOL Method so
class 1 does not
> include MKCOL as far as I can see.

Is it intentional? I mean, RFC2518 says "All DAV
compliant resources MUST 
support the MKCOL method." And advertising class 3
would not imply support 
for MKCOL, if I read the definition of class 3 correctly.

fre 2008-05-23 klockan 09:50 -0400 skrev Simon Perreault:
> On Friday 23 May 2008 09:36:46 Henrik Holst wrote:
> > There is no MUST in RFC4918 for the MKCOL Method
so class 1 does not
> > include MKCOL as far as I can see.
> 
> Is it intentional? I mean, RFC2518 says "All DAV
compliant resources MUST 
> support the MKCOL method." And advertising class 3
would not imply support 
> for MKCOL, if I read the definition of class 3
correctly.
> 
Well that is interesting, class 1 would thus be slightly
redefined in
4918 and supporting class 3 tells the client that your
server follows
this redefinition I guess.

Hopefully we can get some info from the people involved with
4918 how
the ideas where when MKCOL was changed from MUST.

/Henrik Holst

Henrik Holst wrote:
> fre 2008-05-23 klockan 09:50 -0400 skrev Simon
Perreault:
>> On Friday 23 May 2008 09:36:46 Henrik Holst wrote:
>>> There is no MUST in RFC4918 for the MKCOL
Method so class 1 does not
>>> include MKCOL as far as I can see.
>> Is it intentional? I mean, RFC2518 says "All
DAV compliant resources MUST 
>> support the MKCOL method." And advertising
class 3 would not imply support 
>> for MKCOL, if I read the definition of class 3
correctly.
>>
> Well that is interesting, class 1 would thus be
slightly redefined in
> 4918 and supporting class 3 tells the client that your
server follows
> this redefinition I guess.
> 
> Hopefully we can get some info from the people involved
with 4918 how
> the ideas where when MKCOL was changed from MUST.

It wasn't intentional. As far as I recall, we lost the first
paragraph 
without considering compliance.

In practice I think it doesn't make any difference at all.

If a server vendor can't implement support for creating
collections, 
he/she simply won't. A 403 always was possible, RFC4918 now
also allows 405.

What difference does this make in practice?

BR, Julian