ACID-transaction on a set of files over WebDAV?

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-mkcol-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>); 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-get-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)

BIND and cross-server binds

Rather late to the list I'm afraid...

Cyrus pointed out this draft to me in relation to some issues with 
CalDAV and it seemed it would offer a solution to some practical 
difficulties we ran into with the use of CalDAV - how do we make users 
subscriptions appear in a CalDAV client.

The solution I was looking at was essentially some form of alias scheme 
which would allow us to implant an alias to a resource in the users 
calendar hierarchy. This works for shred calendars on the same system 
and will work fine for shared calendars on any other system except that 
it's unlikely they are going to tell us that the resource has been 
deleted - nor do they care there is a link to that resource e.g. google.

Given that the server can behave perfectly reasonably in the event that 
a targetted resource has gone missing why was it felt necessary to 
require that the targetted server a) know about all such bindings and b) 
inform the targetting servers?

And if I implement BIND such that it simply treats the target as empty 
or non-existant how would anybody know different? By which I mean 
wouldn't it be better to define the response if a targetted resource 
disappears or becomes unavailable? The conditions as laid out in draft 
20 seem to make this feature unusable for many purposes

--

-- 

Mike Douglass                           douglm <at> rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Re: BIND and cross-server binds

Mike Douglass wrote:
> 
> Rather late to the list I'm afraid...
> 
> Cyrus pointed out this draft to me in relation to some issues with 
> CalDAV and it seemed it would offer a solution to some practical 
> difficulties we ran into with the use of CalDAV - how do we make users 
> subscriptions appear in a CalDAV client.
> 
> The solution I was looking at was essentially some form of alias scheme 
> which would allow us to implant an alias to a resource in the users 
> calendar hierarchy. This works for shred calendars on the same system 
> and will work fine for shared calendars on any other system except that 
> it's unlikely they are going to tell us that the resource has been 
> deleted - nor do they care there is a link to that resource e.g. google.
> 
> Given that the server can behave perfectly reasonably in the event that 
> a targetted resource has gone missing why was it felt necessary to 
> require that the targetted server a) know about all such bindings and b) 
> inform the targetting servers?

Well, for BIND we assumed people want referential integrity.

Maybe you should look at redirect reference resources? 
(<http://greenbytes.de/tech/webdav/rfc4437.html>)

> And if I implement BIND such that it simply treats the target as empty 
> or non-existant how would anybody know different? By which I mean 
> wouldn't it be better to define the response if a targetted resource 
> disappears or becomes unavailable? The conditions as laid out in draft 
> 20 seem to make this feature unusable for many purposes

I'm not entirely sure what you mean... Could you provide an example?

BR, Julian

Announcement: WebDAV server for Linksys NSLU2

How to handle PROPFIND request with empty <prop> element?

Hi,

 according to RFC4918 one should treat empty PROPFIND requests like an 
<allprop> request, but how should one handle a PROPFIND request which is 
not empty but have an empty <prop> element like:

<?xml version="1.0" encoding="utf-8"?>
   <propfind xmlns="DAV:">
   <prop></prop>
</propfind>

Should this also be treated as an <allprop> request or should we reply 
with say "412 Precondition Failed" or some other error reply?

Sincerely yours, Henrik Holst

Re: How to handle PROPFIND request with empty <prop> element?

Henrik Holst wrote:
> Hi,
> 
> according to RFC4918 one should treat empty PROPFIND requests like an 
> <allprop> request, but how should one handle a PROPFIND request which is 
> not empty but have an empty <prop> element like:
> 
> <?xml version="1.0" encoding="utf-8"?>
>   <propfind xmlns="DAV:">
>   <prop></prop>
> </propfind>
> 
> Should this also be treated as an <allprop> request or should we reply 
> with say "412 Precondition Failed" or some other error reply?

It's invalid, as <prop> should contain a child element specifying the 
property.

Thus, it seems that status 422 makes sense.

Note that 412 has a very specific semantic that doesn't apply here.

And yes, it's unfortunate that there's no really simple way to just get 
the children of a collection; when I needed this, I usually asked for 
DAV:resourcetype, as this is known to exist on every resource, and 
should be cheap to compute.

BR, Julian

Re: How to handle PROPFIND request with empty <prop> element?

On Friday 28 March 2008 15:03:32 Julian Reschke wrote:
> It's invalid, as <prop> should contain a child element specifying the
> property.

Did you find any text supporting that? Here's the DTD excerpt:

   <!ELEMENT prop ANY >

The XML spec isn't very clear on whether ANY may match an empty tag or not. I 
couldn't find out for sure, but I would expect that it may.

Re: How to handle PROPFIND request with empty <prop> element?

Simon Perreault wrote:
> On Friday 28 March 2008 15:03:32 Julian Reschke wrote:
>> It's invalid, as <prop> should contain a child element specifying the
>> property.
> 
> Did you find any text supporting that? Here's the DTD excerpt:
> 
>    <!ELEMENT prop ANY >
> 
> The XML spec isn't very clear on whether ANY may match an empty tag or not. I 
> couldn't find out for sure, but I would expect that it may.

No, the DTD can't express the constraint.

But consider:

"Request particular property values, by naming the properties desired 
within the 'prop' element (the ordering of properties in here MAY be 
ignored by the server)," -- 
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.9.1>

and

"Contains properties related to a resource." -- 
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.14.18>

I'm pretty sure that there's code out there that will fail if <prop> is 
empty.

BR, Julian

Re: How to handle PROPFIND request with empty <prop> element?

On Sunday 30 March 2008 05:24:58 Julian Reschke wrote:
> I'm pretty sure that there's code out there that will fail if <prop> is
> empty.

I was just wondering if there was a use case for a PROPFIND on no properties 
at all (i.e. not having an empty PROPFIND behave as if <allprop/> had been 
specified). I guess not...