[23]xx status codes, prefer, and create

In the course of drafting this content [1] I found a few things that are 
reflected in the live editor's draft.  To give those in fortuitous time 
zones more time to digest/understand them, I'm outlining them here and we 
can also discuss on today's call.

wrt [23]xx, I discovered that the TAG thread has not yet come to anything 
that looks like consensus, so it was a bit more challenging than expected 
to draft something.  Fortunately I was able to find a suitable translator. 
 I also appear to have found an approach *completely within current specs* 
that gives us what we want (303 behavior without the extra round trip). 
More below on my communications with the Incan monkey god [1].

wrt Prefer, I took inspiration from Ted [2] with a syntactic variation 
different than what we voted on.  This seemed low risk, since syntax was 
not a point of contention during meetings/email.
- Instead of return=minimal, I used return=representation as the starting 
point.  This turns out to be important to the [23]xx solution.
- Instead of unqualified tokens, I used LDP-defined URIs as Ted wished.

wrt create, I considered (but did not, as yet) creating a new section 
(let's say, between LDPC General and LDPC Get) to cover the consistent 
"requirements" or invariants that we're trying to get to be true, 
*regardless of which LDP-defined means are used for create*.  In addition 
to reducing duplication in the spec and/or clarifying what we're after, it 
positions us better for extensibility.  I.e. if some creative genius finds 
a shiny new way to create resources that goes viral (maybe using WebDAV, 
who knows), tell people what we'd expect to be true about that approach 
regardless of the concrete syntax used... things like changes to 
membership/containment triples, etc.  This could be done (non-) or 
normatively, but the latter is what I was thinking would be more useful.

wrt the Incan monkey god...

1:  The back-and-forth in the TAG centers around a few issues. 

(a) The effect on existing clients if a 2xx code is used; the same "they 
asked for x, you're giving them a representation of x' " discussion we 
had. 

(b) If a 3xx code is used, how to interpret response headers that describe 
"the resource" (vs others that describe the message itself)... are they 
"about" the request-URI or the (in the 303 case) Location URI?


2: Prefer return= [3] was written to cover existing cases very much like 
[23]xx

The "return=representation" preference is intended to provide a means
   of optimizing communication between the client and server by
   eliminating the need for a subsequent GET request to retrieve the
   current representation of the resource following a modification.

   After successfully processing a modification request such as a POST
   or PUT, a server can choose to return either an entity describing the
   status of the operation or a representation of the modified resource
   itself.  While the selection of which type of entity to return, if
   any at all, is solely at the discretion of the server, the
   "return=representation" preference -- along with the "return=minimal"
   preference defined below -- allow the server to take the client's
   preferences into consideration while constructing the response.

(a) Straddling end of page 8/top of 9: 

When honoring the "return=representation" preference, the returned
   representation might not be a representation of the effective request
   URI when the request is affecting another resource.  In such cases,
   the Content-Location header can be used to identify the URI of the
   returned representation.

(b) Content-Location seems like the wrong choice to me (although I can see 
why it was attractive), and someone on the TAG thread had a similar 
reaction when HT proposed using C-L in a similar fashion.  But in our more 
constrained situation (303 as the starting point), Location is already 
defined and used in practice with exactly the semantics we're after so 
there is no need to define-new for that case.

(c) If we put those two together, we have a decent and deployable 
solution.  We use 303; if the client doesn't do anything special, they get 
the second round trip, using base HTTP (2616 and/or bis).  If they add 
Prefer return=representation, then the client has specifically authorized 
new behavior, and (if honored) it can know that the response 
representation is a representation of the resource whose URI is given by 
the Location header.  The Preference-Applied response header would be 
Required in this case, because 303 already allows a response entity body 
(description in next "bullet").

(d) Which gets me back to "why =representation instead of =minimal is 
important"... because a 'minimal' response to a 303 is no entity body (if 
you ignore the Should in 303) or an entity body that 2616 and bis describe 
this way: the entity of the   response SHOULD contain a short hypertext 
note with a hyperlink to   the new URI(s).  So a minimal response is not a 
representation; the excerpt above on modifications provides other similar 
examples.  We know we want a representation back, saying that seems like 
the better choice even though we've all been thinking of its LDP usage in 
terms of how to reduce the size of the representation.

The closest things I see to open switches here:

1: We're talking about doing this with GETs, which of course are not 
modifications.  Based on earlier discussions with Snell, I would not read 
that as limiting.  The TAG thread might well continue (and ultimately 
might result in a new status code in order to get rid of the requirement 
for clients to proactively send Prefer), but for LDP where I think we have 
flexibility this seems more than 80-20.

2: We don't address the interpretation of response headers.  I don't see 
that [3] does so either (however, if we read the return= text a bit 
narrowly and infer that "successful requests" => 2xx status code, then no 
ambiguity exists for what [3] covers so it becomes our problem when we 
extend its usage).  At least for Link headers, since we're using those, 
it's not an issue; Link allows explicit specification of a context URI via 
anchor= for use when the context IRI differs from the request-URI.



[1] http://dilbert.com/strips/comic/1992-08-03/
[2] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0136.html
[3] http://tools.ietf.org/html/draft-snell-http-prefer-18#section-4.2

Best Regards, John

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