Issue-80: Post media types usable for Create; background for proposal

The listserv is simply more amenable than the issue page for laying out 
the information I considered in the proposal in [issue80].

Reasonably near matches from existing work can be found in [patch]'s 
definition of an HTTP header and [atom]'s accept content element.  In both 
cases, the value space is a list of media type ranges with optional media 
type parameters, so the proposal is to use that much without alteration.

[patch] defines an Allow-Patch header; [issue80]'s is more specific 
(Allow-Post-Create instead of Allow-Post) because POST's semantics are 
more open than PATCH's, and LDP is attempting to use POST only for Create 
semantics... implicitly allowing implementations or other specifications 
to use other forms of POST request for other semantics.  The presence of 
Allow-Patch on a response informs the client of PATCH media types 
acceptable to the server; absence of the header carries no fixed semantic 
that I can find.

The presence of [atom]'s app:accept element on a collection informs 
clients of the acceptable media types that can be POSTed to the collection 
in order to create new entries.  Its absence should be interpreted as 
equivalent to its presence with a default of the atom-entry media type. 
Its presence exactly once with an empty value should be interpreted as a 
*lack* of "post to create" support ... i.e. the list of media types 
supported with a create semantic is empty.  Each element contains one 
media type specification, and the element may be repeated.


I proposed a HTTP header because this is part of the interaction model; 
this information does not seem like it's part of the container's state to 
me, although the WG could choose to define it that way.  I also note that, 
had Atom defined such a header as I drafted below, LDP could have simply 
re-used it - always a nice test.  Certainly the "use POST for Create" 
pattern is commonly enough used outside of either that the larger Web 
community might find it useful, as long as we're careful about the 
definition.  I think we could define it almost exactly as in [patch], so 
I've pasted that definition in here and made what I think are the minimum 
required changes.

  The Accept-Post-Create Header


   This specification introduces a new response header Accept-Post-Create 
used
   to specify the post document formats accepted by the server for 
creating new resources.
   Accept-Post-Create SHOULD appear in the OPTIONS response for any 
resource
   that supports the use of the POST method for creating new resources. 
The presence of the
   Accept-Post-Create header in response to any method is an implicit
   indication that POST is allowed on the resource identified by the
   Request-URI.  The presence of a specific document format in
   this header indicates that that specific format is allowed on the
   resource identified by the Request-URI.

   Accept-Post-Create = "Accept-Post-Create" ":" 1#media-type

   The Accept-Post-Create header specifies a comma-separated listing of 
media-
   types (with optional parameters) as defined by [RFC2616], Section
   3.7.

   Example:

We might choose to weaken the SHOULD on OPTIONS since POST is already 
deployed, OTOH a MAY seems pretty wishy-washy so I left it a SHOULD above.

Since the semantics of POST are more open than PATCH, we might also choose 
to have the editors add clarifications to what is above: 

1: that the presence of a media type (e.g. text/turtle) on this header is 
a positive-assertion hint to clients about the server's capabilities, not 
an iron-clad guarantee that *all* such requests will be processed in that 
way.  I'm thinking of the case where a server deeply processes the request 
body to decide what the request semantics should be; just as some servers 
today treat POST with form-encoded requests as queries, yet the same 
servers treat other identical (at that level of description - actual 
payload varies) requests as updates or creates.

2: that the presence of the header with a value of the empty string should 
be interpreted by clients to mean that the server does not support 
POST-Create (negative-assertion hint ), regardless of media type. 
(stealing a page from Atom's book here - again, POST's more open semantics 
make this seem like a good idea to me).

3: that the *absence* of the header should be interpreted by clients to 
mean that the server provides no hints to clients about its capabilities 
in this respect.


Note that all of this is and should be kept LDP-agnostic, even with the 
suggested clarifications, to allow re-use by other specs.

An LDP client could use Accept-Post-Create (in concert with the "LDP 
server here!" knowledge, whose need is asserted in a different issue) to 
understand whether or not the result of a create request should be an 
LDPR, before making the attempt.  Vs the same client talking to any random 
existing server (no knowledge - try it, see what happens), something that 
it knows via previous interactions to be an atom:collection (see [atom] 
then for its capabilities), or other animals in the zoo.



[issue80] https://www.w3.org/2012/ldp/track/issues/80
[patch] http://tools.ietf.org/html/rfc5789#section-3.1
[atom] http://tools.ietf.org/html/rfc5023#section-8.3.4


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario