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

In case you missed the implication...[1] says RESOLVED: LDP servers MUST 
NOT initiate paging unless the client has indicated it understands paging 
(such as via the Prefer page-size header)

Maybe there was a different sense on the call not being reflected in the 
minutes, but I take this to mean that if the client expresses no paging 
preference (which is the only mechanism we have to know if the client 
"understands" LDP Paging per se) when requesting a resource that the 
server would prefer to page, that client is going to get The Whole Thing 
(200) usually or a redirect (303) if the server plays hardball.  Both are 
fully within HTTP, neither is an error, and _neither is the desired result 
you just articulated_ (unless you go down the "200 means whatever the 
server wants it to" rathole, in which case we don't need paging or 2NN 
ostensibly).

Your desired result is explicitly in violation of the Must Not resolution 
as I read it.  I wasn't on the call, so if that's not the intent catch me 
up please with whatever information I don't have.  I agree it's a perverse 
result, that's what motivated this particular question.

For that matter, I could probably read 303 as being in violation of the 
resolution, which if we get any deep review might cause us problems too 
from anyone who's HTTP-literate.  The client has no way to know if the 303 
was "only" to initiate paging; although the server can know that and this 
is a server constraint, LDP is entitled to levy the requirement.  Although 
(thinking as a compliance tester) you can't know from the outside _why_ 
the 303 was issued so the prohibition's value is less obvious. 


My *suspicion* is that people we/are convoluting paging and 2NN, which are 
separate and separable concerns.  I was doing that in my head until I 
started doing more drafting of text.  If the intent of the resolution was 
really to prevent a current client from seeing 2NN and thinking it has the 
whole thing (a very reasonable "no silent failures"-esque concern), then 
we have a requirement not about _paging preferences_ but about "contents 
of related" preferences ... and a consequent question as to whether that 
is better addressed in the IETF defining document or Paging (I'm less 
worried about that latter choice, personally).  We know we could do paging 
without 2NN, the original used 303, and other existing paging schemes use 
303 [2] (no accident, of course); 2NN is a (strictly speaking) optional 
latency-removal optimization on top of paging.


[1] http://www.w3.org/2013/meeting/ldp/2014-06-30#resolution_2
[2] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Resource_Paging

Best Regards, John

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




From:   ashok malhotra <ashok.malhotra@oracle.com>
To:     public-ldp-wg@w3.org
Date:   07/08/2014 01:40 PM
Subject:        Re: LDP paging + IETF 2NN draft comments - some questions 
I came  across while  working on editorial issues



On 7/8/2014 1:05 PM, John Arwe wrote:
1: Do we want any corresponding requirement that LDP paging clients Must 
add the page size preference to their requests?  I am going to move the 
section defining the preference up into the Paging Clients section, just 
in case that influences anyone's answer.
What behavior do we want if the page size is not specified by the client?
Should that be an error?  Seems harsh.
Servers should be able to figure out the device the client is running on 
and
set a reasonable page size.

Ashok