Re: LDP paging + IETF 2NN draft comments - some questions I came across while working on editorial issues

Vielen Dank, sehr geehrter doesa Prud'hommeaux [...and I raise you 2 
languages, fully expecting a Franco-raise and wondering if you have 
another in your pocket to call with]

> > 5: "The "expected response" is the response that the client would have 

> > received had it performed a GET on"  GET >> the same method  ... in 
the 
> > previous sentence you apply it to all methods, giving examples of GET 
or 
> > POST, then here you are overly specific by saying GET.
> 
> That's intentional; POSTing, PUTting, etc. to the related resource
> would relegate the use of 209 to some peculiar protocols. We're trying
> to short cut a 303 followed by a GET
>   -> POST /container
>   <- 303 Location /container/resource1
>   -> GET /container/resource1
>   <- 200 ...

I was thinking of [1] paragraph 2, POST followed by GET.
If I read 2NN's words at the point cited as 5: literally (as it seems I am 
wont to do), "The "expected response" is the response that the client 
would have received had it performed a GET on the related resource. " 
sounds different than making 2 requests.  I read your words to say that 
[somehow left to the imagination] the client magically came to possess the 
POST's 303's Location URI, and [without ever doing a POST at all] it 
requested a GET against that Location URI.  Re-reading it, I see you're 
silent on that [curse you, limbic system!].  Since I think we actually 
agree on intent, I suggest this clarification - reword as

The "expected response" is the response that the client would have 
received had it performed the original request, received a 303 See Other 
response with a Location header giving the URI of the related resource, 
and then requested a GET on the related resource's URI.

> This works for GET /Alice as well.

"ouch" says the baby seal.

> > 9: similar issue as #5, different context: "client performs on 
operation 
> Has my #5 response persuaded you?

I think your words in 9 should basically be reproduced at the site of 5, 
as my independently-draft strawman probably makes clear.
Those words are more accurate wrt our intent.

> > 10: GET-centricity also leaked heavily into 3.1.  I completely agree 
it's 
> [no answer]

Adding the POST example from [1] would be another way to clarify the 
intent; if new-5 == old-9 words, then of little incremental value to add 
it IMO, else higher value.


> I spelled it out in two lists (I'll see your list and raise you one):

"ooo mackerel, you shouldn't have!" says the baby seal.


>   POST /foo <guts> -> Location: http://a.example/foo/bar#baz
>   GET /foo/bar -> Content-type: text/fragolicious <other guts>
> 
> I have no idea what happens to #baz, but I think that's up to the

[[
Never mind; after drafting a more thorough reply (below, skippable if you 
believe my 'never mind'), I realized that this is not a new problem. Since 
generic 303 has this case already, by re-using 303's rules this is solved 
for 2NN in the same way and to the same degree that 303 solves it.  Since 
303 gives the client no guarantees that the original fragment works as 
expected on the "other" Location-identified resource, in general "ymmv" if 
you fall into this case.  c'est la vie.
]]

Fortunately, [2] does cover that case.  As usual fragment processing is 
governed by the media type specification [3] (so it isn't our problem - 
we're not defining any new media types).  I was not concerned with this 
case, however.  I was murky about how [2] "If the Location value provided 
in a 3xx (Redirection) response does not have a fragment component, ..." 
functions; that section inverts the order of the examples, which was more 
confusing/less obvious yesterday than I find it now.  So [2] determines 
this for us as well, we just have to be sure that it's the desired result 
in 2NN: 

Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the original
   fragment identifier.

If it's not the desired result, then 2NN should warn servers about this 
and get IETF feedback on how to handle it.  It's certainly not obvious to 
me that a fragment ID on the paged-resource would automagically be valid 
on the first (or any particular, in general) in-sequence page resource. 
More likely it's going to be valid on exactly one of the pages, and (since 
the server never sees it) the server has no obvious way to adjust for 
that.  Remember that the client is required by HTTP to remove the fragment 
ID from the request's target URI [4].

[cue: fish-slapping dance]





[1] http://tools.ietf.org/html/rfc7231#section-6.4.4
[2] http://tools.ietf.org/html/rfc7231#section-7.1.2
[3] http://tools.ietf.org/html/rfc3986#section-3.5
[4] http://tools.ietf.org/html/rfc7230#section-5.1

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead