Re: Comments on LDP-Paging

> <#MISSING?>
> Server indication that is has given up on paging and client should 
> start "fresh".
> There was some discussion of allowing for a server to indicate that 
> the in-sequence page resource is "no longer" valid and the client 
> should re-initiate paging.  I believe Sandro had proposed using 410-
> Gone (of course all the right paging response headers would be 
> present, rel=first, etc).  Is there another way a client can detect 
this?

In the current live drafts, the only mentions of abandon or 410 are in the 
non-normative notes on 5.1.4 and 6.2.9, which talk about the server 
abandoning a page sequence.  Only 5.1.4 specifically mentions 410; both 
mention 4xx, which I think is the general case.  How a client reacts to 
that is IMO up to the client.

Of course even IF the server uses a 410 for this case, the client can't 
know that it's seeing 410 specifically because the page sequence was 
abandoned; it could be for other reasons, like the paged-resource itself 
being deleted by a competing request.

> 
> <#MISSING?>
> OPTIONS & HEAD
> I only see the "HTTP GET" section, HEAD is pretty straightforward 
> and not sure we need to call it out (though we do in LDP).  I think 
> these response headers would be valuable on OPTIONS as well, no? 
>  Did we ever discuss this or has it been considered?

I think we had HEAD in LDP because we specifically required it for LDPRs. 
Since everything in Paging is already in LDPR, and we don't add anything 
new, we're silent.
I don't recall any discussion about OPTIONS.  I see that we currently 
define pages as LDPRs, so support is required.

The response headers is an interesting thought; I've never been completely 
comfortable requiring OPTIONS in LDP, and I don't see (yet?) how the 
response headers would help me with paging vs just doing the GET 
paged-resource-uri and potentially getting a 2nn or 303 back.

> I'd propose we add a clause that says something of the sort:
> [[LDP Paging servers SHOULD indicate that they have abandoned a 
> sequence by responding with at 410-Gone to any of the in-sequence 
> pages with appropriate paging link response headers, rel='first']]

I'm a little confuzzled on the placement of this (410, then options/head, 
then a proposal on 410).
I'm agnostic at this point as to the value of SHOULD-410, since it doesn't 
give clients any new guarantees. 

The response headers is an interesting thought; I take it you're thinking 
that the 4xx would have the "new first page" etc links.  Technically, the 
clauses as now worded in 6.2.10-16 apply to 4xx requests as well (they 
don't qualify [successful] GET requests), so 'next' (unless also last) + 
type='page' is required, which seems like a perverse result to some 
degree.

[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.

I'm not convinced we need any of that in 1.0 vs .next, but if we decide we 
need it, seems like an option that works.
[end]


[1] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jul/0059.html

Best Regards, John

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