Subject: [apps-discuss] Accept-Post HTTP header field

From: Erik Wilde <[email-masked]>
Date: Tue, 06 May 2014 17:14:14 -0700

hello.

http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data 
Platform") is a current W3C document in last call WD status, and it 
introduces/uses the Accept-Post header field proposed in a current draft:

http://tools.ietf.org/html/draft-wilde-accept-post

we have publicized this proposed header field on this list, and the 
latest draft also includes a list of known implementations of this 
header field:

http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6

after making the specification available for a while, and listing known 
implementations, we are wondering about next steps. what it would take 
to get this draft moving towards an experimental RFC (apart from some 
references that will need to be updated).

thanks a lot and kind regards,

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 J. Dürst" <[email-masked]>
Date: Wed, 07 May 2014 09:45:35 +0900

Hello Erik,

> http://tools.ietf.org/html/draft-wilde-accept-post-02#section-6

What's the intent behind "Feature at Risk" box? I can see two reasons 
for this: a) trying to be really good citizens, and not going ahead with 
something that's not properly registered; and b) not being confident 
that this is a good idea.

If it's the former, than see below.

> references that will need to be updated).

Why experimental? Why not standards track?

An alternative would be to do a provisional registration, because this 
doesn't need an RFC. That would give you some slack for moving ahead 
with the Linked Data Platform spec without being at the mercy of a 
potentially low level of interest in the IETF.

With respect to the draft itself, I don't see a registration template.

Regards,   Martin.

---

From: Erik Wilde <[email-masked]>
Date: Tue, 06 May 2014 19:11:56 -0700

hello martin.

thanks a lot for the feedback!

> If it's the former, than see below.

it's a), because of the timing issues involved with working on these two 
documents in W3C- and IETF-land.

> Why experimental? Why not standards track?

it could be either way, i don't think we have a strong opinion about 
that. it seems to me that there are different opinions when to use what, 
but if standards track is a better fit, that's fine with us.

> potentially low level of interest in the IETF.

thanks for pointing that out. i guess if we are not making progress with 
the draft, then that would be a way to go for us. for now, maybe there 
is enough interest to move forward with the current approach.

> With respect to the draft itself, I don't see a registration template.

that would be a template according to RFC 3864? good point, i will add 
that to 
https://github.com/dret/I-D/blob/master/accept-post/draft-wilde-accept-post-03.xml

thanks and cheers,

dret.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 May 2014 12:38:17 +1000

Without looking at the draft (recently)...

> Why experimental? Why not standards track?

+1.

“experimental” is for process experiments, e.g., when we can’t come to consensus; not “I’m not sure if people will be using this.”

Go ahead and go standards-track. 

--
Mark Nottingham   http://www.mnot.net/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 May 2014 15:08:31 -0400

> “experimental” is for process experiments, e.g., when we can’t
> come to consensus; not “I’m not sure if people will be using this.”
>

I'll quibble with that:
Experimental is for protocol experiments as well.  "We're not sure
that we got some of this right, and we want to document it and have
people try it and see before we say it's a proposed standard."

That said, I don't disagree with the last thing Mark said: If you
think the protocol needs experimentation, make it Experimental.  If
you're reasonably confident that the protocol is right, but you're
just not sure how much deployment it'll get, make it Proposed
Standard.

Barry, Applications AD

---

From: Erik Wilde <[email-masked]>
Date: Wed, 07 May 2014 16:35:06 -0700

hello barry.

thanks for the feedback.

> people try it and see before we say it's a proposed standard."

the proposal is rather simple and similar to what has been done with the 
existing Accept-Patch header field. because of this, i think we're 
fairly confident that it does not contain major issues. we also do have 
existing implementations using it already.

> just not sure how much deployment it'll get, make it Proposed

ok, i guess in this case we'll stick to the standard route. i have added 
a proper registration template as suggested by martin, and i am 
wondering if there are any other issues i should look at before 
publishing an updated version of the draft.

thanks and cheers,

dret.

ps: 
https://github.com/dret/I-D/blob/master/accept-post/draft-wilde-accept-post-03.txt 
is where the currently unpublished -03 lives

---

From: Graham Klyne <[email-masked]>
Date: Thu, 08 May 2014 08:14:18 +0100

Eric,

If the W3C spec is published on REC track, that would be sufficient to allow 
permanent registration in the header field registry (W3C being a "recognized 
standards organization" for this purpose).  Until it gets to REC track 
publication, I'd suggest going for an interim provisional registration.

Assuming this is a REC track specification, my suggestion would be, rather than 
going the RFC publication route, to include the registration template in an IANA 
consideration section in the W3C spec, and cite that in a request to IANA when 
the document is W3C-approved for CR/PR/REC publication. Also, notify the IANA 
header field discussion list (and maybe IETF apps-discuss) when the document 
goes to last call at the W3C.

#g
--

On 07/05/2014 01:14, Erik Wilde wrote:
> hello.
>
> http://www.w3.org/TR/ldp/#header-accept-post (the "Linked Data Platform") is a
> current W3C document in last call WD status, and it introduces/uses the
> Accept-Post header field proposed in a current draft:
>
> we have publicized this proposed header field on this list, and the latest draft
> also includes a list of known implementations of this header field:
>
> implementations, we are wondering about next steps. what it would take to get
> this draft moving towards an experimental RFC (apart from some references that
> will need to be updated).
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 May 2014 14:06:42 +0200

> thanks a lot and kind regards,

Editorial question:

    The app:accept element is similar to the HTTP Accept request header
    field [RFC2616].  Media type parameters are allowed within Accept-
    Post, but Accept-Post has no notion of preference - "accept-params"
    or "q" arguments, as specified in Section 14.1 of [RFC2616], are not
    significant.

What is "app:accept"?

Furthermore: the fact that we'd have both Accept-Patch and Accept-Post 
kind of implies that maybe something more generic is needed.

Wouldn't it make more sense to allow "Accept" as a response header field?

Best regards, Julian

---

From: mike amundsen <[email-masked]>
Date: Fri, 9 May 2014 08:34:58 -0400

+1 on an "Acceptable" header to match "Allow" for OPTIONS and HTTP 406.

been doing something similar for quite a while (old blog post here:[1]).

[1] http://www.amundsen.com/blog/archives/716

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

On Fri, May 9, 2014 at 8:06 AM, Julian Reschke <[email-masked]>wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 May 2014 14:39:35 +0200

On 2014-05-09 14:34, mike amundsen wrote:
> ...

Can't we just extend "Accept" to be a response header field?

Best regards, Julian

---

From: mike amundsen <[email-masked]>
Date: Fri, 9 May 2014 08:46:02 -0400

Think of an OPTIONS response when the client wants to know:
1) what media types are accepted for requests
AND
2) what media types are returned for responses

i think you need a new header.

mamund
+1.859.757.1449
skype: mca.amundsen

---

From: James M Snell <[email-masked]>
Date: Fri, 9 May 2014 05:46:25 -0700

-1.. In most cases where I've used this kind of mechanism, it is important
to distinguish what you'd accept via post separately than what you'd accept
via patch or put. There is also no requirement for q-value ordering.
Reusing Accept would mean requiring special case handling that's just not
worth the effort when the separate headers approach gets us easily where we
want to go.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 May 2014 14:54:27 +0200

> i think you need a new header.

I don't see why we need 2). Can you elaborate?

Best regards, Julian

---

From: mike amundsen <[email-masked]>
Date: Fri, 9 May 2014 09:19:06 -0400

**** REQUEST ****
OPTIONS /users HTTP/1.1

**** RESPONSE ****
200 OK HTTP/1.1
Allow: GET, HEAD, POST
Accept: text/html, application/atom+xml, application/collection+json
Accepts: application/www-form-url-encoded
Content-Type: text/plain

Methods Allowed: GET, HEAD, POST
Response Types Available: text/html, applicaiton/atom+xml,
application/collection+json
Request Types Accepted: application/www-form-url-encoded

mamund
+1.859.757.1449
skype: mca.amundsen

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 May 2014 15:31:34 +0200

On 2014-05-09 15:19, mike amundsen wrote:
> ....

What's the actual use case for querying the set of available response types?

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Fri, 09 May 2014 16:04:28 -0700

hello.

On 2014-05-09, 5:46, James M Snell wrote:
> -1.. In most cases where I've used this kind of mechanism, it is
> important to distinguish what you'd accept via post separately than what
> you'd accept via patch or put. There is also no requirement for q-value
> ordering. Reusing Accept would mean requiring special case handling
> that's just not worth the effort when the separate headers approach gets
> us easily where we want to go.

+1 on the -1 ;-)

reusing Accept wouldn't work. when publishing earlier versions of the 
draft, i did get feedback about a more general Accept-* header (instead 
of having separate Accept-Patch and Accept-Post and maybe others).

this is certainly possible, but the syntax would get more complicated 
because, as james points out, typically various methods accept different 
sets of media types. plus we already have Accept-Patch out there.

Accept-Post is the result of a real need (W3C's LDP work), and it does 
solve the problem that LDP has. other solutions certainly would have 
been possible as well. mostly, we tried to align our solution with what 
exists (Accept-Patch), and without solving broader problems then the 
ones that we were facing.

just out of curiosity, since we're talking about the possibility of 
generalizing the Accept-* approach: does anybody have any interest in 
having Accept-Put or a general-purpose Accept-* so that PUT would be 
covered as well?

thanks and cheers,

dret.