Subject: [Fwd: draft-reschke-http-addmember-00]

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Feb 2005 13:00:56 +0100

(fyi)

-------- Original Message --------
 > ...

Hi,

recently different communities (caldav/groupdav, atompup (protocol
part)) have been discussing how to use HTTP to author new resources when
the URL namespace is completely server-controlled, thus PUT just doesn't
fit well.

A simple approach would be to define a new HTTP method which is *almost*
like PUT, except that the server chooses the URL to create (and returns
it in the Location header).

I've submitted a first draft as "draft-reschke-http-addmember-00". Note
that it also contains an appendix covering possible alternative approaches.

Feedback appreciated,

Julian

HTML version:
<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html>
Latest edits will be at:
<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-latest.html

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 15 Feb 2005 14:02:40 -0800

> that it also contains an appendix covering possible alternative 

Julian, POST to a collection resource is already defined as
adding a member resource.  That was its very first definition
(hence, named after NNTP's post) and remains applicable today.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 16 Feb 2005 09:46:30 -0800

Julian,

Thanks for writing this draft -- I've been thinking along similar lines
recently.

> (hence, named after NNTP's post) and remains applicable today.

RFC 2616 states:
"The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI."

>From a client perspective this makes POST unreliable, and leads to the
desire to define a new method.

Besides, despite what RFC 2616 actually says, POST is really the protocol
tunneling and form submission method.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Feb 2005 18:50:56 +0100

> tunneling and form submission method.

Thanks Roy and Jim for the feedback.

When I sent the announcement, I forgot to redirect feedback to a single 
place, which should be <[email-masked]> (which I include in this 
reply).

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 16 Feb 2005 21:54:16 -0800

> desire to define a new method.

The action will either succeed or fail.  If it succeeds, the client
will receive the exact same response from POST that it would have
received from a new method.  If it fails, the client will receive
the same potential set of failure responses as it might have from
a new method.

The only way you could claim that a new method would be more reliable
is if the client knows the exact implementation of the resource
being requested, which is something that a client does not know
with HTTP, and even if it did, it is far more likely that it will
know how the server and all intermediaries will respond to the
existing POST method than it could know about their response to
a new method that has zero deployment.

....Roy

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 17 Feb 2005 07:32:44 -0500

I believe the problem arises when you are trying to apply the
addmember function to a resource that already handles POST as meaning
"do the operation specifies in the body of the POST".
To use POST to perform an addmember to that resource, you would
need to have some special encoding of the addmember function in
the body of the POST.  But this special encoding only works on
resources that support that particular encoding for POST calls.
So that would mean that for a client to use POST to perform addmember,
it would need to know whether or not a resource already interprets
POST in a certain way, and then would need to know the encoding in
the body that would be understood by that resource as meaning "addmember".

I may be missing something obvious here (and if so, I'm counting on
Roy pointing it out :-), but if not, it seems that POST cannot be
defined to perform any particular operation, since it already is
being used by some resources to mean "perform the operation specified
in the body".

Cheers,
Geoff

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 17 Feb 2005 13:58:58 +0100

I think What Would Make The World A Better Place is a mechanism that 
generic clients can discover POST service points where they can persist 
new entities. There is nothing wrong with POST, it is just that a 
client cannot discover if and where a server supports that feature.

Atom solves this problem by embedding the POST service uri into the 
feed document. That is fine, but
a) has low reusablity for other protocols/applications
b) has no usability from the view of a generic client

  I think this is what Julian tries to address with ADDMEMBER, since 
this method will  be visible in an OPTIONS response. Alternatively, an 
OPTIONS reponse could carry an extra Header with the URI of such a POST 
service.

On second thought, this could also be nicely wrapped up inside a site 
description and the pointer to the site could be a header in an OPTIONS 
response. Then a small, extensible site description document (XML) 
could do the job nicely.

//Stefan

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 17 Feb 2005 08:04:34 -0500

Stefan: How does your proposal below address the problem of performing
an addmember function against a resource that already interprets POST
as meaning "execute the function specified in some special format in
the body of this POST call".  You don't want to have to introduce a new
resource just to perform an addmember function against that resource.

Cheers,
Geoff

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 17 Feb 2005 14:25:05 +0100

Geoff,

i do not see a problem with introducing a new URI should the server 
wish to support POST for other purposes. Example:

http://example.com/collection/

supports POST for other purposes, then one solution is that

OPTIONS /collection/ HTTP/1.1
Host: example.com

HTTP/1.1 200 Ok
Allow: GET, HEAD, OPTIONS, POST
WhatEverTheHeaderName: http://example.com/collection/?function=AddMember

Of course, in the case of embedding the Post service URI in a site 
description, there would be one URI for all resources belonging to that 
site and the client is not able to control in which collection the 
resource will appear. But I do not see that as an issue...

I see beauty in describing such functions inside a site description 
resource. It is cacheable again, it can habe ETags, it can be target of 
conditional retrieval and it can even be authorable via WebDAV should 
some crazy people want to do that.

//Stefan

Am 17.02.2005 um 14:04 schrieb Geoffrey M Clemm:

>  > >  >
>  > >  > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote:
>  > >  > > RFC 2616 states:
>  > >  > > "The actual function performed by the POST method is 
> determined
>  > > by the
>  > >  > > server and is usually dependent on the Request-URI."
>  > >  > >
>  > >  > > From a client perspective this makes POST unreliable, and 
> leads
>  > > to the
>  > >  > > desire to define a new method.
>  > >  >
>  > >  > The action will either succeed or fail.  If it succeeds, the 
> client
>  > >  > will receive the exact same response from POST that it would 
> have
>  > >  > received from a new method.  If it fails, the client will 
> receive
>  > >  > the same potential set of failure responses as it might have 
> from
>  > >  > a new method.
>  > >  >
>  > >  > The only way you could claim that a new method would be more
>  > > reliable
>  > >  > is if the client knows the exact implementation of the resource
>  > >  > being requested, which is something that a client does not know
>  > >  > with HTTP, and even if it did, it is far more likely that it 
> will
>  > >  > know how the server and all intermediaries will respond to the
>  > >  > existing POST method than it could know about their response to
>  > >  > a new method that has zero deployment.
>  > >  >
>  > >  > ....Roy
>  > >  >
>  > >  >
>  >
>  >
>  >

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 17 Feb 2005 09:03:45 -0500

The benefit of using a new method name to define a new method is that you
can re-use all of the existing machinery (both syntactic and semantic) 
that
keys off of the method name. 

Although SOAP has gone down the "embed the method name in the body of the 
POST"
approach, WebDAV has taken the "use the method name as the method name" 
approach.

If you use some other technique (such as embedding the method name in the 
request-URI), you need to re-invent new machinery to do all the same 
things
that the existing machinery does with method names.

Cheers,
Geoff

Stefan Eissing <[email-masked]> wrote on 02/17/2005 08:25:05 
AM:

> >  > this method will  be visible in an OPTIONS response. Alternatively, 

> > an
> >  > >  > > "The actual function performed by the POST method is 
> > determined
> >  > > by the
> >  > >  > > From a client perspective this makes POST unreliable, and 
> > leads
> >  > > to the

---

From: Yves Lafon <[email-masked]>
Date: Thu, 17 Feb 2005 15:55:48 +0100 (MET)

On Thu, 17 Feb 2005, Geoffrey M Clemm wrote:

> Although SOAP has gone down the "embed the method name in the body of 
> the POST" approach, WebDAV has taken the "use the method name as the 
> method name" approach.

That is not true. In SOAP, you may stuff everything in the SOAP envelope, 
or use the request URI of the underlying protocol in use to identify what 
will be done with this SOAP envelope.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 17 Feb 2005 17:04:24 +0100

Geoff,

it is certainly true that WebDAV has introduced new methods for almost 
everything. I sometimes feel however that reusing existing methods in 
some cases would have its benefits. A GETtable PROPFIND multistatus is 
one of them (with last-modified and etags maybe, yummy!).

In order to stamp out any meta discussion and can openers: the 
discussion about ADDMEMBER and POST seems to hint the POST was intended 
to do what ADDMEMBER addresses. The only thing that is missing is the 
auto discovery feature. That's why I injected my proposal here.

As with any architecture, you can build around small set of primitives 
or make lots of specifics. Finding the optimal balance is the fun 
thing. You cannot say: as we went that way in the past, it will only 
get better when we continue in that direction. Its not a linear 
topology or else software could easily optimize it for us...

//Stefan

Am 17.02.2005 um 15:03 schrieb Geoffrey M Clemm:

> the POST"
> approach, WebDAV has taken the "use the method name as the method 
> name" approach.
>
> Stefan Eissing <[email-masked]> wrote on 02/17/2005 
> 08:25:05 AM:
>
>  > Geoff,
>  >
>  > WhatEverTheHeaderName: 
> http://example.com/collection/?function=AddMember
>  >
>  > >  > I think What Would Make The World A Better Place is a 
> mechanism that
>  > >  > generic clients can discover POST service points where they can
>  > > persist
>  > >  > new entities. There is nothing wrong with POST, it is just 
> that a
>  > >  > client cannot discover if and where a server supports that 
> feature.
>  > >  >
>  > >  > Atom solves this problem by embedding the POST service uri 
> into the
>  > >  > feed document. That is fine, but
>  > >  > a) has low reusablity for other protocols/applications
>  > >  > b) has no usability from the view of a generic client
>  > >  >
>  > >  >   I think this is what Julian tries to address with ADDMEMBER, 
> since
>  > >  > this method will  be visible in an OPTIONS response. 
> Alternatively,
>  > > an
>  > >  > OPTIONS reponse could carry an extra Header with the URI of 
> such a
>  > > POST
>  > >  > service.
>  > >  >
>  > >  > On second thought, this could also be nicely wrapped up inside 
> a
>  > > site
>  > >  > description and the pointer to the site could be a header in an
>  > > OPTIONS
>  > >  > response. Then a small, extensible site description document 
> (XML)
>  > >  > could do the job nicely.
>  > >  >
>  > >  > //Stefan
>  > >  >
>  > >  > Am 17.02.2005 um 13:32 schrieb Geoffrey M Clemm:
>  > >  >
>  > >  > >
>  > >  > > I believe the problem arises when you are trying to apply the
>  > >  > > addmember function to a resource that already handles POST as
>  > > meaning
>  > >  > > "do the operation specifies in the body of the POST".
>  > >  > > To use POST to perform an addmember to that resource, you 
> would
>  > >  > > need to have some special encoding of the addmember function 
> in
>  > >  > > the body of the POST.  But this special encoding only works 
> on
>  > >  > > resources that support that particular encoding for POST 
> calls.
>  > >  > > So that would mean that for a client to use POST to perform
>  > > addmember,
>  > >  > > it would need to know whether or not a resource already 
> interprets
>  > >  > > POST in a certain way, and then would need to know the 
> encoding in
>  > >  > > the body that would be understood by that resource as meaning
>  > >  > > "addmember".
>  > >  > >
>  > >  > > I may be missing something obvious here (and if so, I'm 
> counting
>  > > on
>  > >  > > Roy pointing it out :-), but if not, it seems that POST 
> cannot be
>  > >  > > defined to perform any particular operation, since it 
> already is
>  > >  > > being used by some resources to mean "perform the operation
>  > > specified
>  > >  > > in the body".
>  > >  > >
>  > >  > > Cheers,
>  > >  > > Geoff
>  > >  > >
>  > >  > > Roy wrote on 02/17/2005 12:54:16 AM:
>  > >  > >  >
>  > >  > >  > On Feb 16, 2005, at 9:46 AM, Jim Whitehead wrote:
>  > >  > >  > > RFC 2616 states:
>  > >  > >  > > "The actual function performed by the POST method is
>  > > determined
>  > >  > > by the
>  > >  > >  > > server and is usually dependent on the Request-URI."
>  > >  > >  > >
>  > >  > >  > > From a client perspective this makes POST unreliable, 
> and
>  > > leads
>  > >  > > to the
>  > >  > >  > > desire to define a new method.
>  > >  > >  >
>  > >  > >  > The action will either succeed or fail.  If it succeeds, 
> the
>  > > client
>  > >  > >  > will receive the exact same response from POST that it 
> would
>  > > have
>  > >  > >  > received from a new method.  If it fails, the client will
>  > > receive
>  > >  > >  > the same potential set of failure responses as it might 
> have
>  > > from
>  > >  > >  > a new method.
>  > >  > >  >
>  > >  > >  > The only way you could claim that a new method would be 
> more
>  > >  > > reliable
>  > >  > >  > is if the client knows the exact implementation of the 
> resource
>  > >  > >  > being requested, which is something that a client does 
> not know
>  > >  > >  > with HTTP, and even if it did, it is far more likely that 
> it
>  > > will
>  > >  > >  > know how the server and all intermediaries will respond 
> to the
>  > >  > >  > existing POST method than it could know about their 
> response to
>  > >  > >  > a new method that has zero deployment.
>  > >  > >  >
>  > >  > >  > ....Roy
>  > >  > >  >
>  > >  > >  >
>  > >  >
>  > >  >
>  > >  >
>  >
>  >

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 17 Feb 2005 09:41:55 -0800

On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote:

> generic clients can discover POST service points where they can 
> persist new entities. There is nothing wrong with POST, it is just 
> that a client cannot discover if and where a server supports that 
> feature.
>

Not only that, the Atom approach makes it very difficult for a client 
to synchronize a set of items such as a blog in such a way that the 
blog can be authored offline and synched with both local changes and 
server changes.  It might be possible for a specialized Atom client but 
certainly not for an out-of-the-box WebDAV client.

That's what concerns me for the feature of adding a new resource and 
letting the server choose a location -- it would be nice for a tool 
like Sitecopy to still be able to work.  I'm using that more and more 
to get content to  and from sites like ietf.webav.org.

> OPTIONS reponse could carry an extra Header with the URI of such a 
> POST service.

I think ADDMEMBER would be worthwhile if it did have more of an 
extensibility model and provide the ability to support specialized 
applications. For example, some calendar servers need to reject 
non-iCalendar formatted submissions.  ADDMEMBER reminds me a lot of 
MKRESOURCE if it leans in that direction.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 17 Feb 2005 18:49:58 +0100

> MKRESOURCE if it leans in that direction.

Well, we just killed MKRESOURCE for good reasons :-)

Anyway; nothing is preventing a server to restrict the applicable 
content types for ADDMEMBER...

Best regards, Julian