Subject: Re: I-D Action:draft-reschke-webdav-post-00.txt

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Oct 2008 16:45:11 +0200

Ok,

I have a new version ready that (hopefully) addresses all points that 
have been raised so far. See

	<http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html>

BR, Julian (planning to submit it tomorrow as -01)

Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On September 23, 2008 5:46:12 PM +0200 Julian Reschke 
> <[email-masked]> wrote:
> 
>>> "When a server supports WebDAV ACL [RFC3744], the DAV:bind privilege is
>>> required to be granted on the collection resource in which the new
>>> member resource is being created. If this privilege is denied or not
>>> present, the POST request MUST fail."
>>
>> Yes, although I'd move that into a "Relation to WebDAV ACL" section.
>>
>>> Another question: there is no restriction on what p:add-member URI can
>>> be? e.g. if I have the collection "/a/b/" can the p:add-member be
>>> another resource entirely, e.g. "/a/use-c-to-create-in-b/"? If this is
>>
>> I thought that was already clear; maybe I should have chosen a different
>> URI :-)
> 
> A couple of different examples would help make it clear.
> 
>>> possible it should be called out, as the behavior might be somewhat
>>> unexpected for clients. It might even be the case that the p:add-member
>>> URI is on a different server (e.g. new member items in a collection need
>>> "approval" from some other service). The interaction with WebDAV ACL in
>>
>> It seems that that kind of redirection would need a different mechanism.
>> Let's not make things more complicated than they need to be.
> 
> OK, then let's explicitly state that the add-member URI must not be on a 
> different server.
> 
>>> this case would need to be clear - i.e. what privileges are required on
>>> the p:add-member URI?
>>
>> I think it would be sufficient to state the ACL requirements in terms of
>> DAV:bind on the "real" collection. The add-member URI in general could me
>> a non-WebDAV resource, so talking about WebDAV ACLs really doesn't make
>> sense here.
> 
> OK, makes sense.
>

---

From: Petr Tomasek <[email-masked]>
Date: Tue, 7 Oct 2008 16:30:43 +0200

On Mon, Sep 22, 2008 at 05:42:54PM +0200, Julian Reschke wrote:
> 
> FYI -- this is an early draft of what I proposed in July 
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008JulSep/0011.html>).
> 
> Feedback appreciated,
> 
> Julian

Hi,

I dislike the fact, that a simple task like creating a new resource
should constitute complicated metadata creating/parsing.

I think a simple method (I would choose another one, not the POST
one, but e.g. "CREATE") would be more suitable to the HTTP model.

Please, note, not everything on the earth "is WebDAV" and it seems
to mee that forcing using XML everywhere, even if it is not necessary
is simply an error (it leads to too complicated protocols and too
much overhead for implementing them...)

Petr Tomasek

-- 
Petr Tomasek <http://www.etf.cuni.cz/~tomasek>
Jabber: [email-masked]
SIP: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Oct 2008 16:40:34 +0200

> one, but e.g. "CREATE") would be more suitable to the HTTP model.

I proposed that one ("ADDMEMBER", see 
<http://tools.ietf.org/html/draft-reschke-http-addmember-00>) over three 
years ago, and the feedback from the HTTP community I got was: "not 
needed, just use POST").

The new proposal addresses that feedback -- it makes POST usable for 
WebDAV collections.

> much overhead for implementing them...)

This is a proposal specifically for WebDAV. Thus I think it's totally 
acceptable that the information lives in WebDAV properties.

(That being said, I strongly disagree with the assumption that using XML 
itself is a problem; see for instance AtomPub which uses exactly the 
same approach)

BR, Julian

---

From: Petr Tomasek <[email-masked]>
Date: Sat, 18 Oct 2008 09:58:04 +0200

> years ago, and the feedback from the HTTP community I got was: "not 

Yes I know, but the "HTTP community" is simply wrong. There are fundamental
differences of how POST and the supposed ADDMEMBER would work:
 - most important, POST generetas response body, while ADDMEMBER would never.
I.e. POST is a mixture of PUT and GET, while ADDMEMBER would be a special case
of PUT.
 - with POST the data structure is not defined and is completely up to
the application.

> This is a proposal specifically for WebDAV. Thus I think it's totally 

Yes, and that's wrong, because this sort of action is genereal enough
to be used outside of the scope of WebDAV....

> itself is a problem; see for instance AtomPub which uses exactly the 

It may be problem e.g. for embedded devices with very low resources
(have ever tried to implement something for 8bit MCU like Atmel AVR's?
But there are working implementations of TCP/HTTP stack for such small
devices; adding XML would perhaps double the code for such an implementation!)

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Oct 2008 10:12:11 +0200

> I.e. POST is a mixture of PUT and GET, while ADDMEMBER would be a special case

How is that a problem?

>  - with POST the data structure is not defined and is completely up to

Please elaborate. Which data structure?

> to be used outside of the scope of WebDAV....

And the answer to this that I got was: use POST. I have given up 
fighting that battle. How about trying yourself?

> devices; adding XML would perhaps double the code for such an implementation!)

Out of the mobile devices which are sold *today*, which does have an 
HTTP stack that allows non-RFC2616 methods but does not have an XML parser?

BR, Julian