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

Petr Tomasek wrote:
>> 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").
> 
> 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.

How is that a problem?

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

Please elaborate. Which data structure?

>> The new proposal addresses that feedback -- it makes POST usable for 
>> WebDAV collections.
>>
>>> 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...)
>> 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....

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

>> 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)
> 
> 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!)

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