Re: Comments on LDP-Paging - 410-gone thinking out loud threadlet

> > [going waaaaay out on a new branch from that point...thinking out 
loud]
> > If the client supports 2NN, the server could I think legally 
> return 2NN+new-first-page in this case.
> > Else If the client supports LDP paging, '303 to the new first 
> page' could be made to work, with changes below
> > Else 4xx seems required, and the headers won't help it anyway, 
> although it is true that the only way a non-paging-aware client 
> could get to this case is if it was given "a URI" that happened to 
> be a page URI.
> >
> > changes for "303 to restart traversal", might well also apply to 2nn 
case:
> > - paging client needs a way to tell that what it got is *the 
> first* page in particular (it requested the n>=1st page), which 
> currently is a known only via the client's point in the interaction 
> not via response content; trivial to solve with a Link: <303-
> location-uri>; rel='first' header.
> > - that might serve to distinguish sufficiently between "sequence 
> abandoned" (this new 303-on-a-page case) and other error cases 
> apropos your original comment above ... I think the only new 
> *normative* text would be for the link on 303.
> >
> "the link" is the link header sample you show above?  

yes: Link: <303-location-uri>; rel='first' 

> To play it 
> out, the "303 to restart traversal" client would have to be smart 
> enough to compare Link: <303-location-uri>; rel='first' and Location
> header uri, if they match, then "this is not the page you were 
> looking for, give up on paging, and start here".  

Upon receipt of a 303 or 2NN, any *LDP Paging client* knows "this is not 
the page you were looking for" via 5.1.6.  Full stop.

How it reacts to that is up to the client implementation.
Assuming it wishes to restart traversal, it's very much like the pattern 
in chapter 4:

1: It is free to GET paged-resource-URI and start traversal from the 
beginning, with no further optimization.

2: If it wishes to optimize by avoiding that GET, then it can see if the 
303 Location-header-URI is the first page.

   I suggested Link: <303-location-uri>; rel='first' as one way that we 
could define for doing so.

3: If it is 2NN-capable, then the server could allow the client to avoid 
both the GET from #1 and the GET of first-page-URI by responding with 2NN 
and the contents of the first page. 

   This has the same "is the Location URI the 'first' page?" problem as 
#2, and presumably the same solution.

> A client not aware
> of this, just following links and consuming RDF, could keep going on
> for a while with a bunch of redundant stuff (not sure this something
> we can completely avoid but just pointing it out). 

A client not aware that 303 means they're getting the URI of a resource 
different from what they requested is not an LDP Paging client (violates 
5.1.6).

A client not aware that 2NN means they're getting the URI of a resource 
different from what they requested is an LDP Paging client but violates 
the 2NN spec, assuming the server behaves and only initiates 
paging-using-2nn when the client has asserted it's 2nn-capable.  Either 
way one of the parties is violating one of the specs. 

It is certainly true that not all existing HTTP clients comply with 5.1.6 
and ~zero are 2nn-aware, so the fact that they're not LDP Paging clients 
while true is not the whole story by any means.  Specifying something 
conditional that makes a possibly large existing client base less likely 
to work incorrectly could be a good trade-off.


> ....  I kind of like 
> 410-Gone approach instead, if client had previous copies of first/
> last/next, it could check those and check the paged resource. 

410-Gone has the obvious advantage that no client can possibly get 
something unexpected, since they're all getting nothing.  Hence they can't 
wander off doing foolish things, regardless of their LDP Paging or 2NN 
awareness/ignorance/malfeasance.

The chapter-4-ish optimization possibilities I laid out above are still 
possible, simply less likely to be implemented.
Since they're still possible, and I'm honestly not sure how much effort 
it's worth to optimize restarting paging (for either party), people might 
well prefer to add the SHOULD at this point.
Having convinced myself they are still possible, I'm content to either 
have the should or not, and leave any of the optimizations above out of 
the spec regardless; if it becomes something important, it's still here 
and it can be put in .whatever.




Best Regards, John

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