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

From: Erik Wilde <[email-masked]>
Date: Fri, 06 Sep 2013 18:58:29 -0700

changes from -00 to -01 
(http://tools.ietf.org/html/draft-wilde-accept-post-01#section-9.1):

    o  Changed ABNF for header field from RFC 2616 to HTTPbis convention 
(only specify the header field value grammar).
    o  Added implementations (all from the LDP community for now).
    o  Added open issue for aligning accept-post as defined by the "HTTP 
Link Hints" draft.

-------- Original Message --------
Subject: New Version Notification for draft-wilde-accept-post-01.txt
Date: Fri, 06 Sep 2013 18:41:29 -0700
From: [email-masked]

A new version of I-D, draft-wilde-accept-post-01.txt
has been successfully submitted by John Arwe and posted to the
IETF repository.

Filename:	 draft-wilde-accept-post
Revision:	 01
Title:		 The Accept-Post HTTP Header
Creation date:	 2013-09-06
Group:		 Individual Submission
Number of pages: 10
URL: 
http://www.ietf.org/internet-drafts/draft-wilde-accept-post-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wilde-accept-post
Htmlized:        http://tools.ietf.org/html/draft-wilde-accept-post-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-wilde-accept-post-01

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 [1].
    Online access to all versions and files is available on github [2].

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 11:42:30 -0700

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?

On 6 September 2013 18:58, Erik Wilde <[email-masked]> wrote:
>    o  Added open issue for aligning accept-post as defined by the "HTTP Link
> Hints" draft.
>
>
> URL: http://www.ietf.org/internet-drafts/draft-wilde-accept-post-01.txt
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: James M Snell <[email-masked]>
Date: Mon, 9 Sep 2013 11:50:19 -0700

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 :-)

---

From: Erik Wilde <[email-masked]>
Date: Mon, 09 Sep 2013 12:10:47 -0700

hello.

>> for any future method that contains a body or any request that might

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:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 13:34:58 -0700

I was really just giving you a nudge.  The draft would be better, in
my opinion, if you answered this question in the draft itself.

> - there is precedent (Accept-Patch)

I never regard precedent as a good reason.  So: bad reason.

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

Same reason as the bad reason.

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

Good enough reason, in the absence of other reasons.  And I think that
James provided the other reason: there just isn't that much of a need
for this for other methods.

> we already have implementations using it

Not that convincing an argument honestly.