From groupdav@opengroupware.org  Sun Dec 21 08:28:09 2008
From: groupdav@opengroupware.org (Butrus Damaskus)
Date: Sun, 21 Dec 2008 09:28:09 +0100
Subject: [GroupDAV] Brief Header
In-Reply-To: <0095FACE-F670-4602-A802-8D1D62837CB8@opengroupware.org>
References: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org>
 <48A28F5D.1090601@outdoor-training.de>
 <0095FACE-F670-4602-A802-8D1D62837CB8@opengroupware.org>
Message-ID: <a2831f3f0812210028q3b13ac52j31c17912f49c54cd@mail.gmail.com>

------=_Part_2332_30904127.1229848090003
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Aug 13, 2008 at 8:41 AM, Helge Hess <helge.hess@opengroupware.org>wrote:

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

Wouldn't it be better to standartize something less "microsoftish" (I mean
a "t" value doesn't say anything) for any WebDAV based protocol?

Petr Tomasek

------=_Part_2332_30904127.1229848090003
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Aug 13, 2008 at 8:41 AM, Helge Hess <span dir="ltr">&lt;<a href="mailto:helge.hess@opengroupware.org">helge.hess@opengroupware.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 13.08.2008, at 09:38, Ralf Becker wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Does this &quot;Brief&quot; header only apply to PROPSTAT, or also to REPORT requests?<br>
</blockquote>
<br>
<br></div>
This could apply to everything which returns an {DAV:}response element. If Brief: t, just omit &lt;propstat&gt; elements with &lt;status&gt; 404.<br>
<br>
Greets,<br><font color="#888888">
 &nbsp;Helge</font><div></div></blockquote><div><br>Wouldn&#39;t it be better to standartize something less &quot;microsoftish&quot; (I mean&nbsp; a &quot;t&quot; value doesn&#39;t say anything) for any WebDAV based protocol?<br><br>
Petr Tomasek <br></div></div><br>

------=_Part_2332_30904127.1229848090003--

From groupdav@opengroupware.org  Sun Dec 21 08:36:50 2008
From: groupdav@opengroupware.org (Butrus Damaskus)
Date: Sun, 21 Dec 2008 09:36:50 +0100
Subject: [GroupDAV] Versioning GroupDav?
Message-ID: <a2831f3f0812210036h7ebce8c8raf86d0e0a72489e8@mail.gmail.com>

------=_Part_2351_22577793.1229848610739
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello!

I wonder if the GroupDAV shoudn't specify an optional (simple) versioning of
the resources. Consider e.g. You have an addressbook that records the
changes of a address when someone moves...

For an inteplementation it would be sufficient to:
 a) export each version under separate URL (a recommended practice would be
in an standalone folder/directory/collection)
 b) implement the DAV:version-tree REPORT.

Couldn't this be added to GroupDAV v.3 ? ;)

------=_Part_2351_22577793.1229848610739
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello!<br><br>I wonder if the GroupDAV shoudn&#39;t specify an optional (simple) versioning of the resources. Consider e.g. You have an addressbook that records the changes of a address when someone moves...<br><br>For an inteplementation it would be sufficient to:<br>
&nbsp;a) export each version under separate URL (a recommended practice would be in an standalone folder/directory/collection)<br>&nbsp;b) implement the DAV:version-tree REPORT.<br><br>Couldn&#39;t this be added to GroupDAV v.3 ? ;)<br>

------=_Part_2351_22577793.1229848610739--

From groupdav@opengroupware.org  Sun Dec 21 10:47:11 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Sun, 21 Dec 2008 11:47:11 +0100
Subject: [GroupDAV] Versioning GroupDav?
In-Reply-To: <a2831f3f0812210036h7ebce8c8raf86d0e0a72489e8@mail.gmail.com>
References: <a2831f3f0812210036h7ebce8c8raf86d0e0a72489e8@mail.gmail.com>
Message-ID: <08BA3FE5-8D40-4BEB-9EE4-6591AE53F3C5@opengroupware.org>

On 21.12.2008, at 09:36, Butrus Damaskus wrote:
> I wonder if the GroupDAV shoudn't specify an optional (simple)  
> versioning of the resources. Consider e.g. You have an addressbook  
> that records the changes of a address when someone moves...

IMHO the straightforward solution for this specific situation is to  
give that address another TYPE.

   ADR;TYPE=HOME:...
   ADR;TYPE=OLD-HOME:...

Maybe even introduce some versioning in the payload.

> For an inteplementation it would be sufficient to:
>  a) export each version under separate URL (a recommended practice  
> would be in an standalone folder/directory/collection)
>  b) implement the DAV:version-tree REPORT.

"Just" do this if you want versioning:

   http://www.ietf.org/rfc/rfc3253.txt

(in fact an HTTP based Subversion server is a perfectly valid  
GroupDAVv2 backend, providing automatic versioning)

I'm not sure why you need to add that GroupDAV itself.

> Couldn't this be added to GroupDAV v.3 ? ;)


GroupDAV is supposed to be as minimalistic as possible. HTTP  
versioning is clearly out of discussion.

If you want to work on versioning in the calendaring/contact context,  
I suggest to raise the topic in the CalDAV and CardDAV forums. Those  
are more complex efforts which might have room for versioning.

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

From groupdav@opengroupware.org  Sun Dec 21 10:52:44 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Sun, 21 Dec 2008 11:52:44 +0100
Subject: [GroupDAV] Brief Header
In-Reply-To: <a2831f3f0812210028q3b13ac52j31c17912f49c54cd@mail.gmail.com>
References: <A8910F3C-DA05-41A4-9637-46E8EB41449A@opengroupware.org> <48A28F5D.1090601@outdoor-training.de> <0095FACE-F670-4602-A802-8D1D62837CB8@opengroupware.org> <a2831f3f0812210028q3b13ac52j31c17912f49c54cd@mail.gmail.com>
Message-ID: <0D27EFBB-FB40-4723-AD9C-90DB34F6DF5F@opengroupware.org>

On 21.12.2008, at 09:28, Butrus Damaskus 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.
>
> Wouldn't it be better to standartize something less  
> "microsoftish" (I mean  a "t" value doesn't say anything) for any  
> WebDAV based protocol?


Actually I don't mind (and somewhat agree). But standards should be  
discussed in the WebDAV mailing list (and lead to an RFC). I'm happy  
to switch if something gets standardized.
Could be something more powerful like 'exclude-propstat: 403,403' etc.

Anyways, I think 'Brief' is not the worst choice at this point of  
time. Its implemented by a few people and it does solve the problem at  
hand.

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

From groupdav@opengroupware.org  Sun Dec 21 11:51:47 2008
From: groupdav@opengroupware.org (Butrus Damaskus)
Date: Sun, 21 Dec 2008 12:51:47 +0100
Subject: [GroupDAV] Versioning GroupDav?
In-Reply-To: <08BA3FE5-8D40-4BEB-9EE4-6591AE53F3C5@opengroupware.org>
References: <a2831f3f0812210036h7ebce8c8raf86d0e0a72489e8@mail.gmail.com>
 <08BA3FE5-8D40-4BEB-9EE4-6591AE53F3C5@opengroupware.org>
Message-ID: <a2831f3f0812210351r1b1c0b2ayd3d178a29f40bcae@mail.gmail.com>

------=_Part_2717_30723509.1229860307046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Dec 21, 2008 at 11:47 AM, Helge Hess
<helge.hess@opengroupware.org>wrote:


 For an inteplementation it would be sufficient to:
>  a) export each version under separate URL (a recommended practice would be
> in an standalone folder/directory/collection)
>  b) implement the DAV:version-tree REPORT.
>

"Just" do this if you want versioning:
>
>  http://www.ietf.org/rfc/rfc3253.txt



Yes, i WAS refering to RFC3252! (The DAV:version-tree is described in
section 3.7.1)


> Couldn't this be added to GroupDAV v.3 ? ;)
>
 GroupDAV is supposed to be as minimalistic as possible. HTTP versioning is
> clearly out of discussion.


That's EXACTLY why I'm asking here! RFC3252 is huge and it operates with
number of concepts that are not needed for a SIMPLE versioning of
contacts/calendar events/todos... (like the concept of branches,
checkout/checkin, etc.)

What I was suggesting, was to add a "minimalistic" note to the Groupdav spec
about _which_methods_ (i.e. DAV:version-tree REPORT) one should use IF he
wants versioning and under which constrains (e.g. no branches, the versions
should be in separate folder, etc.).

Actually, It's clear to me, that nowadays no-one uses versioning with remote
addressbooks / calendars, but it is a concept which can be very usefull
exactly with this kind of collective collaboration...


> If you want to work on versioning in the calendaring/contact context, I
> suggest to raise the topic in the CalDAV and CardDAV forums. Those are more
> complex efforts which might have room for versioning.


No, the CalDAV/CardDAV approach is far too complex :) I was looking for
minimalistic versioning ;)

------=_Part_2717_30723509.1229860307046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Dec 21, 2008 at 11:47 AM, Helge Hess <span dir="ltr">&lt;<a href="mailto:helge.hess@opengroupware.org">helge.hess@opengroupware.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><br><div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For an inteplementation it would be sufficient to:<br>
&nbsp;a) export each version under separate URL (a recommended practice would be in an standalone folder/directory/collection)<br>
&nbsp;b) implement the DAV:version-tree REPORT.<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&quot;Just&quot; do this if you want versioning:<br>
<br>
 &nbsp;<a href="http://www.ietf.org/rfc/rfc3253.txt" target="_blank">http://www.ietf.org/rfc/rfc3253.txt</a></blockquote><div><br><br>Yes, i WAS refering to RFC3252! (The DAV:version-tree is described in section 3.7.1)<br><br>
</div><div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; Couldn&#39;t this be added to GroupDAV v.3 ? ;)<br>
</blockquote>

</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
GroupDAV is supposed to be as minimalistic as possible. HTTP versioning is clearly out of discussion.</blockquote><div><br>That&#39;s EXACTLY why I&#39;m asking here! RFC3252 is huge and it operates with number of concepts that are not needed for a SIMPLE versioning of contacts/calendar events/todos... (like the concept of branches, checkout/checkin, etc.)<br>
<br>What I was suggesting, was to add a &quot;minimalistic&quot; note to the Groupdav spec about _which_methods_ (i.e. DAV:version-tree REPORT) one should use IF he wants versioning and under which constrains (e.g. no branches, the versions should be in separate folder, etc.).<br>
<br>Actually, It&#39;s clear to me, that nowadays no-one uses versioning with remote addressbooks / calendars, but it is a concept which can be very usefull exactly with this kind of collective collaboration...<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
If you want to work on versioning in the calendaring/contact context, I suggest to raise the topic in the CalDAV and CardDAV forums. Those are more complex efforts which might have room for versioning.</blockquote><div>&nbsp;<br>
No, the CalDAV/CardDAV approach is far too complex :) I was looking for minimalistic versioning ;)<br><br></div></div><br>

------=_Part_2717_30723509.1229860307046--

From groupdav@opengroupware.org  Sun Dec 21 12:19:47 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Sun, 21 Dec 2008 13:19:47 +0100
Subject: [GroupDAV] Versioning GroupDav?
In-Reply-To: <a2831f3f0812210351r1b1c0b2ayd3d178a29f40bcae@mail.gmail.com>
References: <a2831f3f0812210036h7ebce8c8raf86d0e0a72489e8@mail.gmail.com> <08BA3FE5-8D40-4BEB-9EE4-6591AE53F3C5@opengroupware.org> <a2831f3f0812210351r1b1c0b2ayd3d178a29f40bcae@mail.gmail.com>
Message-ID: <90FDAEFB-914D-4F47-A0EC-75D9E581BBBC@opengroupware.org>

On 21.12.2008, at 12:51, Butrus Damaskus wrote:
> Yes, i WAS refering to RFC3252! (The DAV:version-tree is described  
> in section 3.7.1)

Yes, I know :-)

> > GroupDAV is supposed to be as minimalistic as possible. HTTP  
> versioning > is clearly out of discussion.
> That's EXACTLY why I'm asking here! RFC3252 is huge and it operates  
> with number of concepts that are not needed for a SIMPLE versioning  
> of contacts/calendar events/todos... (like the concept of branches,  
> checkout/checkin, etc.)
>
> What I was suggesting, was to add a "minimalistic" note to the  
> Groupdav spec about _which_methods_ (i.e. DAV:version-tree REPORT)  
> one should use IF he wants versioning and under which constrains  
> (e.g. no branches, the versions should be in separate folder, etc.).
>
> Actually, It's clear to me, that nowadays no-one uses versioning  
> with remote addressbooks / calendars, but it is a concept which can  
> be very usefull exactly with this kind of collective collaboration...

I think agree with all of your points, except that it should be added  
to GroupDAV. Its a transport layer effort which should be  
complementary to GroupDAV (and other *DAV efforts). Seems like you  
want to do to RFC3252 what GroupDAV is to CalDAV/CardDAV. Which might  
be a good idea (don't know enough about RFC 3252).

A client could then check whether a resource or collection supports  
the "MiniVersDAV" ;-) and expose it to the user. Though I honestly  
doubt that any of the mainstream clients will ever support this ...  
GroupDAV would contain a feature with no real world relevance, which  
obviously bites with the 'minimalistic' aspect.

Anyways. I'm open to hear what others think about it. Maybe you could  
propose the exact text which would be added to GroupDAV (outlining all  
the details which would be required to achieve simple versioning).

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

From groupdav@opengroupware.org  Sun Dec 21 14:48:15 2008
From: groupdav@opengroupware.org (Adam Tauno Williams)
Date: Sun, 21 Dec 2008 09:48:15 -0500
Subject: [GroupDAV] Versioning GroupDav?
In-Reply-To: <90FDAEFB-914D-4F47-A0EC-75D9E581BBBC@opengroupware.org>
References: <a2831f3f0812210036h7ebce8c8raf86d0e0a72489e8@mail.gmail.com>
 <08BA3FE5-8D40-4BEB-9EE4-6591AE53F3C5@opengroupware.org>
 <a2831f3f0812210351r1b1c0b2ayd3d178a29f40bcae@mail.gmail.com>
 <90FDAEFB-914D-4F47-A0EC-75D9E581BBBC@opengroupware.org>
Message-ID: <1229870895.7763.24.camel@linux-nnci.site>

> > > GroupDAV is supposed to be as minimalistic as possible. HTTP  
> > versioning > is clearly out of discussion.
> > That's EXACTLY why I'm asking here! RFC3252 is huge and it operates  
> > with number of concepts that are not needed for a SIMPLE versioning  
> > of contacts/calendar events/todos... (like the concept of branches,  
> > checkout/checkin, etc.)
> > What I was suggesting, was to add a "minimalistic" note to the  
> > Groupdav spec about _which_methods_ (i.e. DAV:version-tree REPORT)  
> > one should use IF he wants versioning and under which constrains  
> > (e.g. no branches, the versions should be in separate folder, etc.).
> > Actually, It's clear to me, that nowadays no-one uses versioning  
> > with remote addressbooks / calendars, but it is a concept which can  
> > be very usefull exactly with this kind of collective collaboration...

The only real world use of versioning I've seen lately (excepting code
management solutions) is for PITR (point-in-time-restore) which isn't a
client-facing feature.  No end-user client, or even binding, I'm aware
of supports versioning.

> A client could then check whether a resource or collection supports  
> the "MiniVersDAV" ;-) and expose it to the user. Though I honestly  
> doubt that any of the mainstream clients will ever support this ...  
> GroupDAV would contain a feature with no real world relevance, which  
> obviously bites with the 'minimalistic' aspect.
> Anyways. I'm open to hear what others think about it. Maybe you could  
> propose the exact text which would be added to GroupDAV (outlining all  
> the details which would be required to achieve simple versioning).

I agree that it is interesting but I'd be against it since I don't think
anyone would use it,  The only way I can see something like version
useful would be in a PITR fashion and no protocol extension is required
for that;  just http://{server}/{root}/AsOf20081221/, etc...  since in
that manner it could be used without client extensions.  But then, no
public server I'm aware of supports that either. :)


From groupdav@opengroupware.org  Sun Dec 28 19:16:41 2008
From: groupdav@opengroupware.org (Butrus Damaskus)
Date: Sun, 28 Dec 2008 20:16:41 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
Message-ID: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>

------=_Part_67686_6929765.1230491801685
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello!

http://www.groupdav.org/draft-hess-groupdav-01.txt in section 5.4. (Creating
items) in the example a status code "201 Created" is returned together with
the "Location:" header (that points to the newly created item according to
the naming scheme on the server).

However the RFC 2616 in the section 9.6 ("PUT") states: "...the server MUST
NOT attempt to apply the request to some other resource. If the server
desires that the request be applied to a different URI, it MUST send a 301
(Moved Permanently) response; the user agent MAY then make its own decision
regarding whether or not to redirect the request."

So, shouldn't the GrouDAV draft/spec be changed accordingly?
Thanks!

Petr Tomasek

------=_Part_67686_6929765.1230491801685
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello!<br><br><a href="http://www.groupdav.org/draft-hess-groupdav-01.txt">http://www.groupdav.org/draft-hess-groupdav-01.txt</a> in section 5.4. (Creating items) in the example a status code &quot;201 Created&quot; is returned together with the &quot;Location:&quot; header (that points to the newly created item according to the naming scheme on the server).<br>
<br>However the RFC 2616 in the section 9.6 (&quot;PUT&quot;) states: &quot;...the
   server MUST NOT attempt to apply the request to some other resource.
   If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY
   then make its own decision regarding whether or not to redirect the
   request.&quot;<br><br>So, shouldn&#39;t the GrouDAV draft/spec be changed accordingly?<br>Thanks!<br><br>Petr Tomasek<br>

------=_Part_67686_6929765.1230491801685--

From groupdav@opengroupware.org  Sun Dec 28 19:41:51 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Sun, 28 Dec 2008 20:41:51 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
In-Reply-To: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>
References: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>
Message-ID: <B73C9F0B-958B-4B77-987D-C42EE6B073EF@opengroupware.org>

On 28.12.2008, at 20:16, Butrus Damaskus wrote:
> http://www.groupdav.org/draft-hess-groupdav-01.txt in section 5.4.  
> (Creating items) in the example a status code "201 Created" is  
> returned together with the "Location:" header (that points to the  
> newly created item according to the naming scheme on the server).
>
> However the RFC 2616 in the section 9.6 ("PUT") states: "...the  
> server MUST NOT attempt to apply the request to some other resource.

Well, the server does not apply the request to another resource, its  
the exact same resource. It just moves the created resource to a new  
location and (already) tells the client in the PUT response. (to the  
client thats no different to another user moving the resource after  
the PUT)

Whether thats allowed or not leads to big discussion threads. You can  
search Google for "PUT location header". IMHO its a gray area in the  
spec.

> If the server desires that the request be applied to a different  
> URI, it MUST send a 301 (Moved Permanently) response; the user agent  
> MAY then make its own decision regarding whether or not to redirect  
> the request."

Well, first I'm not convinced that PUT+location is forbidden per se  
(nor that it makes sense to forbid it). See above plus the discussions  
on the net.

Second, 301 has the disadvantage that the server must allocate an id  
before it receives the content. Many (RDBMS) servers can't do that  
easily. I do agree that GroupDAV clients should _also_ support  
301+location. We should add a hint on that to the spec.
(also, the 301 implies that the client needs to transfer the content  
twice, unless the server implements 100-continue - VERY few do so)

We might also add a "SHOULD NOT" to PUT+location for servers (but keep  
a MUST for clients).

> So, shouldn't the GroupDAV draft/spec be changed accordingly?


I would say no, mostly for pragmatic reasons. While PUT+location is  
not perfectly specified in HTTP, there are no known side effects in  
the context of GroupDAV. And it makes an initial GroupDAV  
implementation much easier for many many server vendors - that feature  
is very important to get a good adoption rate.

Again in short: supporting PUT+location does not hurt in any way.  
Clients should just implement it and everyone is happy ;-)

Greets,
   Helge

PS: just to be clear, its recommended that the server uses and stores  
the name choosen by the client, PUT+location is just a documented  
workaround if they can't easily.
-- 
Helge Hess
http://helgehess.eu/

From groupdav@opengroupware.org  Sun Dec 28 20:47:49 2008
From: groupdav@opengroupware.org (Julian Reschke)
Date: Sun, 28 Dec 2008 21:47:49 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
In-Reply-To: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>
References: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>
Message-ID: <4957E5F5.6080604@gmx.de>

Butrus Damaskus wrote:
> Hello!
> 
> http://www.groupdav.org/draft-hess-groupdav-01.txt in section 5.4. 
> (Creating items) in the example a status code "201 Created" is returned 
> together with the "Location:" header (that points to the newly created 
> item according to the naming scheme on the server).
> 
> However the RFC 2616 in the section 9.6 ("PUT") states: "...the server 
> MUST NOT attempt to apply the request to some other resource. If the 
> server desires that the request be applied to a different URI, it MUST 
> send a 301 (Moved Permanently) response; the user agent MAY then make 
> its own decision regarding whether or not to redirect the request."
> ...

Indeed.

See: 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0096.html>.

BR, Julian

From groupdav@opengroupware.org  Tue Dec 30 12:47:46 2008
From: groupdav@opengroupware.org (Butrus Damaskus)
Date: Tue, 30 Dec 2008 13:47:46 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
In-Reply-To: <B73C9F0B-958B-4B77-987D-C42EE6B073EF@opengroupware.org>
References: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>
 <B73C9F0B-958B-4B77-987D-C42EE6B073EF@opengroupware.org>
Message-ID: <a2831f3f0812300447m16c74f9dr1d3a002fe34e74c4@mail.gmail.com>

------=_Part_81319_10813347.1230641266791
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Dec 28, 2008 at 8:41 PM, Helge Hess <helge.hess@opengroupware.org>wrote:

> On 28.12.2008, at 20:16, Butrus Damaskus wrote:
>
>> http://www.groupdav.org/draft-hess-groupdav-01.txt in section 5.4.
>> (Creating items) in the example a status code "201 Created" is returned
>> together with the "Location:" header (that points to the newly created item
>> according to the naming scheme on the server).
>>
>> However the RFC 2616 in the section 9.6 ("PUT") states: "...the server
>> MUST NOT attempt to apply the request to some other resource.
>>
>
> Well, the server does not apply the request to another resource, its the
> exact same resource. It just moves the created resource to a new location
> and (already) tells the client in the PUT response. (to the client thats no
> different to another user moving the resource after the PUT)
>
> Whether thats allowed or not leads to big discussion threads. You can
> search Google for "PUT location header". IMHO its a gray area in the spec.
>

Ok


>  If the server desires that the request be applied to a different URI, it
>> MUST send a 301 (Moved Permanently) response; the user agent MAY then make
>> its own decision regarding whether or not to redirect the request."
>>
>
> Well, first I'm not convinced that PUT+location is forbidden per se (nor
> that it makes sense to forbid it). See above plus the discussions on the
> net.
>
> Second, 301 has the disadvantage that the server must allocate an id before
> it receives the content.


Oh, I didn't realize, that it would mean two requests...

> We might also add a "SHOULD NOT" to PUT+location for servers (but keep a
MUST for clients).

That would mean that letting the server to decide what the URI would be is
perfectly legitimate.


>
>  So, shouldn't the GroupDAV draft/spec be changed accordingly?
>>
>
>
> I would say no, mostly for pragmatic reasons. While PUT+location is not
> perfectly specified in HTTP, there are no known side effects in the context
> of GroupDAV. And it makes an initial GroupDAV implementation much easier for
> many many server vendors - that feature is very important to get a good
> adoption rate.


I agree. But, PLEASE, could You make an explicit note about using
PUT+Location in the spec?


>
> Again in short: supporting PUT+location does not hurt in any way. Clients
> should just implement it and everyone is happy ;-)
>
> Greets,
>  Helge
>
> PS: just to be clear, its recommended that the server uses and stores the
> name choosen by the client,


Why? This seems a little bit stupid to me... For most RDBMS this would on
contrary be the prefered way!

------=_Part_81319_10813347.1230641266791
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Dec 28, 2008 at 8:41 PM, Helge Hess <span dir="ltr">&lt;<a href="mailto:helge.hess@opengroupware.org">helge.hess@opengroupware.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 28.12.2008, at 20:16, Butrus Damaskus wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<a href="http://www.groupdav.org/draft-hess-groupdav-01.txt" target="_blank">http://www.groupdav.org/draft-hess-groupdav-01.txt</a> in section 5.4. (Creating items) in the example a status code &quot;201 Created&quot; is returned together with the &quot;Location:&quot; header (that points to the newly created item according to the naming scheme on the server).<br>

<br>
However the RFC 2616 in the section 9.6 (&quot;PUT&quot;) states: &quot;...the server MUST NOT attempt to apply the request to some other resource.<br>
</blockquote>
<br></div>
Well, the server does not apply the request to another resource, its the exact same resource. It just moves the created resource to a new location and (already) tells the client in the PUT response. (to the client thats no different to another user moving the resource after the PUT)<br>

<br>
Whether thats allowed or not leads to big discussion threads. You can search Google for &quot;PUT location header&quot;. IMHO its a gray area in the spec.<br></blockquote><div><br>Ok<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.&quot;<br>

</blockquote>
<br></div>
Well, first I&#39;m not convinced that PUT+location is forbidden per se (nor that it makes sense to forbid it). See above plus the discussions on the net.<br>
<br>
Second, 301 has the disadvantage that the server must allocate an id before it receives the content.</blockquote><div><br>Oh, I didn&#39;t realize, that it would mean two requests...<br><br></div>&gt; 
We might also add a &quot;SHOULD NOT&quot; to PUT+location for servers (but keep a MUST for clients).<br><br>That would mean that letting the server to decide what the URI would be is perfectly legitimate. <br>
<div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, shouldn&#39;t the GroupDAV draft/spec be changed accordingly?<br>
</blockquote>
<br>
<br>
I would say no, mostly for pragmatic reasons. While PUT+location is not perfectly specified in HTTP, there are no known side effects in the context of GroupDAV. And it makes an initial GroupDAV implementation much easier for many many server vendors - that feature is very important to get a good adoption rate.</blockquote>
<div><br>I agree. But, PLEASE, could You make an explicit note about using PUT+Location in the spec?<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Again in short: supporting PUT+location does not hurt in any way. Clients should just implement it and everyone is happy ;-)<br>
<br>
Greets,<br>
 &nbsp;Helge<br>
<br>
PS: just to be clear, its recommended that the server uses and stores the name choosen by the client,</blockquote><div><br>Why? This seems a little bit stupid to me... For most RDBMS this would on contrary be the prefered way!<br>
&nbsp;</div><br></div><br>

------=_Part_81319_10813347.1230641266791--

From groupdav@opengroupware.org  Tue Dec 30 12:52:29 2008
From: groupdav@opengroupware.org (Butrus Damaskus)
Date: Tue, 30 Dec 2008 13:52:29 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
In-Reply-To: <4957E5F5.6080604@gmx.de>
References: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>
 <4957E5F5.6080604@gmx.de>
Message-ID: <a2831f3f0812300452v49debf49q679aec04e9d32056@mail.gmail.com>

------=_Part_81335_20762935.1230641549070
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Dec 28, 2008 at 9:47 PM, Julian Reschke <julian.reschke@gmx.de>wrote:

> Butrus Damaskus wrote:
>
>> Hello!
>>
>> http://www.groupdav.org/draft-hess-groupdav-01.txt in section 5.4.
>> (Creating items) in the example a status code "201 Created" is returned
>> together with the "Location:" header (that points to the newly created item
>> according to the naming scheme on the server).
>>
>> However the RFC 2616 in the section 9.6 ("PUT") states: "...the server
>> MUST NOT attempt to apply the request to some other resource. If the server
>> desires that the request be applied to a different URI, it MUST send a 301
>> (Moved Permanently) response; the user agent MAY then make its own decision
>> regarding whether or not to redirect the request."
>> ...
>>
>
> Indeed.
>
> See: <
> http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0096.html>.
>
> BR, Julian


Hi, Julian,

Yes I know about
http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html, but
I still it's an error to use POST for this purpose. The POST is too general
method (in contrast to PUT there is NO guarantee, that the request body - or
it's equivalent - will be accesible through the GET command). Actually the
POST means "send some data to the server and see what it returns". I think
after all, PUT+Location is much more sane solution. Pity, that the HTTP
don't want to see this...

Petr Tomasek

------=_Part_81335_20762935.1230641549070
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sun, Dec 28, 2008 at 9:47 PM, Julian Reschke <span dir="ltr">&lt;<a href="mailto:julian.reschke@gmx.de">julian.reschke@gmx.de</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Butrus Damaskus wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
Hello!<br>
<br>
<a href="http://www.groupdav.org/draft-hess-groupdav-01.txt" target="_blank">http://www.groupdav.org/draft-hess-groupdav-01.txt</a> in section 5.4. (Creating items) in the example a status code &quot;201 Created&quot; is returned together with the &quot;Location:&quot; header (that points to the newly created item according to the naming scheme on the server).<br>

<br>
However the RFC 2616 in the section 9.6 (&quot;PUT&quot;) states: &quot;...the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.&quot;<br>
</div>
...<br>
</blockquote>
<br>
Indeed.<br>
<br>
See: &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0096.html" target="_blank">http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0096.html</a>&gt;.<br>
<br>
BR, Julian</blockquote><div><br>Hi, Julian,<br><br>Yes I know about <a href="http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html">http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html</a>, but I still it&#39;s an error to use POST for this purpose. The POST is too general method (in contrast to PUT there is NO guarantee, that the request body - or it&#39;s equivalent - will be accesible through the GET command). Actually the POST means &quot;send some data to the server and see what it returns&quot;. I think after all, PUT+Location is much more sane solution. Pity, that the HTTP don&#39;t want to see this...<br>
<br>Petr Tomasek<br><br></div></div><br><br><br>

------=_Part_81335_20762935.1230641549070--

From groupdav@opengroupware.org  Tue Dec 30 13:15:32 2008
From: groupdav@opengroupware.org (Butrus Damaskus)
Date: Tue, 30 Dec 2008 14:15:32 +0100
Subject: [GroupDAV] Which status codes to use?
Message-ID: <a2831f3f0812300515r34163179k1887c2ddc7587ca0@mail.gmail.com>

------=_Part_81461_25285063.1230642932740
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

SGkhCgpJIHRyaWVkIHRvIGltcGxlbWVudCB0aGUgUFVUICJwYXJ0IiBvZiB0aGUgR3JvdXBEQVYg
dXNpbmcgUEhQIG9uIG9uZSB3ZWIKcGFnZSAod2hpY2ggYWxyZWFkeSBwcm92aWRlcyByZWFkLW9u
bHkgc3VwcG9ydCBmb3IgR3JvdXBEQVYgZm9yIGl0J3MKY2FsZW5kYXIgYW5kIGFkcmVzc2Jvb2sp
LiBIb3dldmVyIEkgZm91bmQsIHRoYXQgdGhlcmUgaXMgbm8gaW5kaWNhdGlvbiBpbgp0aGUgc3Bl
YyBmb3Igd2hpY2ggSFRUUCBlcnJvci9zdGF0dXMgY29kZXMgdG8gdXNlIGZvciBwYXJ0aWN1bGFy
IGVycm9yCnNpdHVhdGlvbnMuIEkgdXNlOgoKYSkgSFRUUCBoZWFkZXI6CiDigKIgNDE1IFVuc3Vw
cG9ydGVkIE1lZGlhIFR5cGU6IGZvciB3cm9uZyBDb250ZW50LXR5cGUKIOKAoiA0MTEgTGVuZ3Ro
IFJlcXVpcmVkLCA0MTMgUmVxdWVzdCBFbnRpdHkgVG9vIExhcmdlOgoKYikgdkNhbGVuZGFyL3ZD
YXJkIHN5bnRheDoKIOKAoiA0MDAgQmFkIFJlcXVlc3QKCmMpICB3cm9uZyB2Q2FsZW5kYXIgIGNv
bXBvbmVudCwgIG1vcmUgdGhhbiBvbmUgdkNhbGVuZGFyIGNvbXBvbmVudCwgbWlzc2luZwp2Q2Fs
ZW5kYXIgZmllbGRzLCB3cm9uZyB2Q2FsZW5kYXIgZmllbGRzOgog4oCiIDQyMiBVbnByb2Nlc3Nh
YmxlIEVudGl0eQoKCklzIHRoaXMgcmlnaHQ/IFNob3VsZCB0aGlzIGJlIG1vcmUgZXhwbGljaXRs
eSBzcGVjaWZpZWQ/ClRoYW5rcyEKClBldHIgVG9tYXNlawo=
------=_Part_81461_25285063.1230642932740
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

SGkhPGJyPjxicj5JIHRyaWVkIHRvIGltcGxlbWVudCB0aGUgUFVUICZxdW90O3BhcnQmcXVvdDsg
b2YgdGhlIEdyb3VwREFWIHVzaW5nIFBIUCBvbiBvbmUgd2ViIHBhZ2UgKHdoaWNoIGFscmVhZHkg
cHJvdmlkZXMgcmVhZC1vbmx5IHN1cHBvcnQgZm9yIEdyb3VwREFWIGZvciBpdCYjMzk7cyBjYWxl
bmRhciBhbmQgYWRyZXNzYm9vaykuIEhvd2V2ZXIgSSBmb3VuZCwgdGhhdCB0aGVyZSBpcyBubyBp
bmRpY2F0aW9uIGluIHRoZSBzcGVjIGZvciB3aGljaCBIVFRQIGVycm9yL3N0YXR1cyBjb2RlcyB0
byB1c2UgZm9yIHBhcnRpY3VsYXIgZXJyb3Igc2l0dWF0aW9ucy4gSSB1c2U6PGJyPgo8YnI+YSkg
SFRUUCBoZWFkZXI6PGJyPiZuYnNwO+KAoiA0MTUgVW5zdXBwb3J0ZWQgTWVkaWEgVHlwZTogZm9y
IHdyb25nIENvbnRlbnQtdHlwZTxicj4mbmJzcDvigKIgNDExIExlbmd0aCBSZXF1aXJlZCwgNDEz
IFJlcXVlc3QgRW50aXR5IFRvbyBMYXJnZTo8YnI+PGJyPmIpIHZDYWxlbmRhci92Q2FyZCBzeW50
YXg6PGJyPiZuYnNwO+KAoiA0MDAgQmFkIFJlcXVlc3Q8YnI+PGJyPmMpJm5ic3A7IHdyb25nIHZD
YWxlbmRhciZuYnNwOyBjb21wb25lbnQsJm5ic3A7IG1vcmUgdGhhbiBvbmUgdkNhbGVuZGFyIGNv
bXBvbmVudCwgbWlzc2luZyB2Q2FsZW5kYXIgZmllbGRzLCB3cm9uZyB2Q2FsZW5kYXIgZmllbGRz
OiA8YnI+CiZuYnNwO+KAoiA0MjIgVW5wcm9jZXNzYWJsZSBFbnRpdHk8YnI+PGJyPjxicj5JcyB0
aGlzIHJpZ2h0PyBTaG91bGQgdGhpcyBiZSBtb3JlIGV4cGxpY2l0bHkgc3BlY2lmaWVkPzxicj5U
aGFua3MhPGJyPjxicj5QZXRyIFRvbWFzZWs8YnI+PGJyPjxicj4K
------=_Part_81461_25285063.1230642932740--

From groupdav@opengroupware.org  Tue Dec 30 13:19:24 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Tue, 30 Dec 2008 14:19:24 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
In-Reply-To: <a2831f3f0812300447m16c74f9dr1d3a002fe34e74c4@mail.gmail.com>
References: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com> <B73C9F0B-958B-4B77-987D-C42EE6B073EF@opengroupware.org> <a2831f3f0812300447m16c74f9dr1d3a002fe34e74c4@mail.gmail.com>
Message-ID: <6F00D0CF-9B99-478D-84C5-83AB413EC72D@opengroupware.org>

On 30.12.2008, at 13:47, Butrus Damaskus wrote:
> > We might also add a "SHOULD NOT" to PUT+location for servers (but  
> keep a MUST for clients).
> That would mean that letting the server to decide what the URI would  
> be is perfectly legitimate.

Yes. But it would not be recommended, see below.

> PS: just to be clear, its recommended that the server uses and  
> stores the name choosen by the client,
>
> Why? This seems a little bit stupid to me... For most RDBMS this  
> would on contrary be the prefered way!

Yes, but its the approach which gives the highest possible interop,  
hence recommended. And yes, this usually means that the server needs  
to maintain an additional table for mapping a "WebDAV" name to the  
RDBMS primary key (potentially per-collection if it exposes the same  
item in multiple, virtual collections).

Remember: only GroupDAV clients will usually support PUT+location "per  
spec". To support CalDAV/CardDAV clients, you will need to do it  
anyways. (again my basic idea: make it easy to implement GroupDAV in  
the beginning, but provide a good upgrade path to 'full' CalDAV/CardDAV)

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

From groupdav@opengroupware.org  Tue Dec 30 13:22:58 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Tue, 30 Dec 2008 14:22:58 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
In-Reply-To: <a2831f3f0812300452v49debf49q679aec04e9d32056@mail.gmail.com>
References: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com> <4957E5F5.6080604@gmx.de> <a2831f3f0812300452v49debf49q679aec04e9d32056@mail.gmail.com>
Message-ID: <8F05BCD6-65AD-4069-A740-6F9435917673@opengroupware.org>

On 30.12.2008, at 13:52, Butrus Damaskus wrote:
> Yes I know about http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html 
> , but I still it's an error to use POST for this purpose. The POST  
> is too general method (in contrast to PUT there is NO guarantee,  
> that the request body - or it's equivalent - will be accesible  
> through the GET command). Actually the POST means "send some data to  
> the server and see what it returns". I think after all, PUT+Location  
> is much more sane solution.

Please lets not reraise this discussion in this list.

> Pity, that the HTTP don't want to see this...


I'm not entirely sure about that. What we would need is an official  
RFC which documents either PUT+location, or possibly a new response  
header.
But again: not a topic for _this_ list. I'll stick to PUT+Loc in  
GroupDAV (and possibly the 301 variant) until I see somthing better.  
The POST is out of question for _GroupDAV_.

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

From groupdav@opengroupware.org  Tue Dec 30 13:31:29 2008
From: groupdav@opengroupware.org (Helge Hess)
Date: Tue, 30 Dec 2008 14:31:29 +0100
Subject: [GroupDAV] Which status codes to use?
In-Reply-To: <a2831f3f0812300515r34163179k1887c2ddc7587ca0@mail.gmail.com>
References: <a2831f3f0812300515r34163179k1887c2ddc7587ca0@mail.gmail.com>
Message-ID: <2409AE43-EB1B-4016-87D8-6DE4B0BC3DFB@opengroupware.org>

On 30.12.2008, at 14:15, Butrus Damaskus wrote:
> I tried to implement the PUT "part" of the GroupDAV using PHP on one =20=

> web page (which already provides read-only support for GroupDAV for =20=

> it's calendar and adressbook). However I found, that there is no =20
> indication in the spec for which HTTP error/status codes to use for =20=

> particular error situations.

I think its no different to HTTP, just use the error codes as =20
explained there?

> I use:
>
> a) HTTP header:
>  =95 415 Unsupported Media Type: for wrong Content-type
>  =95 411 Length Required, 413 Request Entity Too Large:

Looks good.

> b) vCalendar/vCard syntax:
>  =95 400 Bad Request

I'm not sure what you mean by that. If the vCal/vCard contains a =20
syntax error? In that case I think it would be right.

> c)  wrong vCalendar  component,

Good question. 415 might be OK for that too. A full content-type for =20
an iCalendar file looks like:

   text/calendar; component=3DVEVENT

Hm, we might check what CalDAV specifies here.

>   more than one vCalendar component,

BTW: for CalDAV compat we should allow this if all the items have the =20=

same UID (hence are rrule exceptions).

> missing vCalendar fields, wrong vCalendar fields:

Sounds like b)?

>  =95 422 Unprocessable Entity

Sounds good.

> Is this right?

Looks good.

> Should this be more explicitly specified?

I think the HTTP errors are sufficiently well specified, there are a =20
few edge cases and multiple codes which might match, but I've never =20
found that a problem in practice.

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

From groupdav@opengroupware.org  Tue Dec 30 13:40:48 2008
From: groupdav@opengroupware.org (Julian Reschke)
Date: Tue, 30 Dec 2008 14:40:48 +0100
Subject: [GroupDAV] Does the spec violate RFC2616?
In-Reply-To: <a2831f3f0812300452v49debf49q679aec04e9d32056@mail.gmail.com>
References: <a2831f3f0812281116p2544f884q5a3222cb675c62e@mail.gmail.com>	 <4957E5F5.6080604@gmx.de> <a2831f3f0812300452v49debf49q679aec04e9d32056@mail.gmail.com>
Message-ID: <495A24E0.40404@gmx.de>

Butrus Damaskus wrote:
> Hi, Julian,
> 
> Yes I know about 
> http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-latest.html, 
> but I still it's an error to use POST for this purpose. The POST is too 
> general method (in contrast to PUT there is NO guarantee, that the 
> request body - or it's equivalent - will be accesible through the GET 
> command). Actually the POST means "send some data to the server and see 
> what it returns". I think after all, PUT+Location is much more sane 
> solution. Pity, that the HTTP don't want to see this...
> 
> Petr Tomasek

Yes, POST can do many more things.

Thus, in order to use POST for adding new content (as in PUT), the 
client needs additional information. Both in AtomPub and in my WebDAV 
related proposal this is done by a discovery mechanism which guarantees 
that specific semantics.

BR, Julian