W3C home > Mailing lists > Public > public-ldp@w3.org > July 2013

Re: [apps-discuss] Fw: New Version Notification for draft-wilde-accept-post-00.txt

From: Erik Wilde <dret@berkeley.edu>
Date: Wed, 31 Jul 2013 10:35:42 +0200
Message-ID: <51F8CC5E.1010605@berkeley.edu>
To: Mark Baker <distobj@acm.org>
CC: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>, Steve Speicher <sspeiche@us.ibm.com>, LDP <public-ldp@w3.org>, John Arwe <johnarwe@us.ibm.com>
hello mark.

On 2013-07-30 18:49 , Mark Baker wrote:
> On Mon, Jul 29, 2013 at 4:02 AM, Erik Wilde <dret@berkeley.edu> wrote:
>> a new draft "The Accept-Post HTTP Header" has been published. it has been
>> developed within the W3C LDP working group
>> (http://www.w3.org/2012/ldp/wiki/Main_Page), but we thought it would promote
>> reuse of that header field if it were specified and registered separately.
>> any feedback is very welcome. in order to align with the timing of the W3C
>> LDP specifications, our goal is to move this draft forward as fast as we
>> can.
> Hey Erik. Is there any particular reason why this is POST-specific and
> not applicable to all methods that meaningfully accept a
> representation, like PUT or PATCH?

the intention for this header is to expose the supported representations 
for POST requests. in many HTTP-based designs, the set of accepted 
representations differs between the methods. for example the existing 
Accept-Patch header exposes accepted representations for PATCH, but 
clearly those only make sense for PATCH requests.

that being said, nothing stops you from proposing a header that exposes 
all accepted representations of a resource, independent of the request 
method. my guess is you'd end up qualifying them somehow by which 
methods support that particular representation, in which case you'd end 
up pretty much at the same point.

> Also, historically, as I'm sure you know, this information is
> typically provided by prior hypermedia transactions, e.g. an HTML
> form. The reasons for this over providing them from the resource
> itself directly (which I assume is the use case, it isn't clear) are
> primarily efficiency; that a separate round trip isn't required to
> gather that information. So I would expect that a mechanism such as
> yours would be used with legacy formats that don't support the ability
> to make such a declaration, but that doesn't appear to be the case for
> LDP. What are your thoughts? Thanks.

in the end, it's a design question how and where to expose this 
information. if your design prefers to put it inside the representation, 
you're free to not use Accept-Post. the LDP WG decided to prefer using 
an HTTP header.

while LDP is not doing it this way, i could also see link hints [1] 
being used for this as well, with the link hint providing the 
information in the way you prefer it (embedded in the representation 
linking to the resource accepting POST requests), and the resource 
itself providing it using Accept-Post, in case you're getting to that 
resource through let's say a bookmark, so that the link hint information 
isn't available to you.



[1] http://tools.ietf.org/html/draft-nottingham-link-hint-00

erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
Received on Wednesday, 31 July 2013 08:36:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:35 UTC