W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

From: Joe Gregorio <joe.gregorio@gmail.com>
Date: Thu, 17 Feb 2005 15:27:27 +0000
Message-ID: <3f1451f50502170727c6f24b9@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>

On Thu, 17 Feb 2005 14:54:38 +0100, Julian Reschke
<julian.reschke@gmx.de> wrote:
> Roy T. Fielding wrote:
> > It doesn't because it never needed it.
> OK, let's step back and look at the situation that caused me to make
> this proposal.
> Two separate communities (CalDAV/GroupDav and Atompub) encountered the
> same issue: what's the best way to create a new resource on an HTTP
> server when I can't use PUT as the URI space may be entirely
> server-controlled?
> 1) CalDav's approach is: use PUT to an arbitrary member URI of the
> container; then let the server automagically move it somewhere else, and
> report that in the Location response header
> (<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html#rfc.section.A.2>).
> 2) Atom's approach is to use service URIs to which the client can POST,
> and to discover these service URIs by parting entity (feed) bodies.

To be clear, Atom uses POST + media-type ==> 201 + location exactly
as Roy outlined. 

As you point out, there is an issue with the discovery of the URI to POST
to, but I'll get back to that below.

> Somehow I have the (perhaps naive) wish that identical requirements
> should lead to common protocol constructs.
> 1) Seems to break PUT semantics;
> 2) Is specific to Atom and not applicable to other protocols.

None of what Atom does is specific to Atom, unless you count
the media-type of "application/atom+xml".

The real source of the problem/disconnect here seems to be
not over the semantics of PUT or POST, but goes back a level
further into the differences betweeen Atom and WebDAV and how 
they use URIs, which in turn may foster different solutions
to the problem of resource creation. 

To make this clear, let's define two terms:

URI Construction:
   An algorithm for pasting together some information into 
   URI path and query parameters to form a URI.

   Two examples:
   1. WebDAV's use of PUT. To create a new resource append 
       to the path your are currently using and PUT a representation 
       to that URI.
   2. Del.icio.us API (http://del.icio.us/doc/api) Ignoring for now
the non-idenpotent
       uses of GET, the API is just a recipe for how to construct URIs.

Hypertext Navigation:
   Following opaque URIs in a hypertext document.

     The <a/> element in HTML.

Now we can categorize:

   Atom:        All URIs are opaque and it uses Hypertext Navigation
to find URIs.
   WebDAV:  In many instances uses URI Construction.
   HTML:       Uses a blend of both. For example <a/> elements are pure 
                   Hypertext Navigation, while HTML Forms that 
                   use GET use a combination, creating a URI from data in 
                   the Hypertext to construct a URI.

As a side note, what does seem to be missing is a generic mechanism
for URI construction using data culled from hypertext that can be used
for web services. That is, while HTML can construct Form GET requests
using query parameters there is no analogue for constructing path and
query components of a URI from XML documents.


Joe Gregorio        http://bitworking.org
Received on Thursday, 17 February 2005 15:30:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC