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

hello.

On 2013-09-09 11:50 , James M Snell wrote:
> An Accept-Put (or Accept-{whatever}) would be useful if and only if
> there are practical known use cases where we know they'd be used. The
> two we currently have (Accept-Patch and Accept-Post) have very clear,
> specific real world use cases that solve immediate non-theoretical
> needs. If someone eventually finds need for Accept-Put, they can
> easily draft up a quick I-D that defines it :-)
> On Mon, Sep 9, 2013 at 11:42 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
>> Apologies if I missed an earlier discussion, but why is this
>> restricted specifically to POST requests?  Is there value in also
>> having Accept-Put (useful if the resource can be retrieved in multiple
>> forms, but only uploaded in a subset of those, such that it is
>> difficult to learn what types are acceptable), as well as Accept-Blah,
>> for any future method that contains a body or any request that might
>> return 415?

james' response is right along the lines what i would say. you might be 
able to come up with a model for an Accept-AnyMethod field, but it would 
necessarily be more complicated.

and not that this proves anything, but link hints as they are defined in 
the current draft support method-specific hints such as accept-post: 
http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.4

when we (the W3C LDP WG) came up with Accept-Post, we followed the model 
of Accept-Patch, which already exists as a registered header field: 
http://tools.ietf.org/html/rfc5789#section-4.1

personally, i don't think there's a functional difference between what 
you can do with method-specific fields, or with one field that openly 
covers all methods. the reasons for doing it per method include:

- there is precedent (Accept-Patch)

- link hints currently follow the same method-specific model.

- the "content model" is simpler than for a more general header field.

the preference of the LDP WG of course is to follow the path we're 
proposing, also because we already have implementations using it: 
http://tools.ietf.org/html/draft-wilde-accept-post-01#section-6

thanks and cheers,

dret.

-- 
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 Monday, 9 September 2013 19:11:13 UTC