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

From: Erik Wilde <[email-masked]>
Date: Mon, 29 Jul 2013 10:02:12 +0200

hello.

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.

thanks and cheers,

dret.

----------------------------------------------------------------------

On 2013-07-29 9:18 , [email-masked] wrote:
> A new version of I-D, draft-wilde-accept-post-00.txt
> has been successfully submitted by John Arwe and posted to the
> IETF repository.
>
> Filename:	 draft-wilde-accept-post
> Revision:	 00
> Title:		 The Accept-Post HTTP Header
> Creation date:	 2013-07-29
> Group:		 Individual Submission
> Number of pages: 7
> URL:             http://www.ietf.org/internet-drafts/draft-wilde-accept-post-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-wilde-accept-post
> Htmlized:        http://tools.ietf.org/html/draft-wilde-accept-post-00
>
>
> Abstract:
>     This specification defines a new HTTP response header field Accept-
>     Post, which indicates server support for specific media types for
>     entity bodies in HTTP POST requests.
>
> Note to Readers
>
>     This draft should be discussed on the apps-discuss mailing list [9].
>     Online access to all versions and files is available on github [10].

---

From: Mark Baker <[email-masked]>
Date: Tue, 30 Jul 2013 12:49:33 -0400

On Mon, Jul 29, 2013 at 4:02 AM, Erik Wilde <[email-masked]> wrote:
> hello.
>
> 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?

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.

Mark.

---

From: Erik Wilde <[email-masked]>
Date: Wed, 31 Jul 2013 10:35:42 +0200

hello mark.

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

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

cheers,

dret.

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

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |