Re: Client preferences

Greg, the working group discussed this comment on today's call.

The intent of the draft is that the "client supports LDP paging" signal is 
conveyed not merely by the presence of Prefer: return=representation, 
which might be used for other things, but in particular by the presence of 
a page-size parameter (which is newly defined by LDP Paging) on that 
preference.

I just made updates to the editor's draft at [1], changeset [2] to clarify 
that.


With respect to the other part of your question, if the header is absent 
(or has just Prefer: return=representation, no page-size parameter) then 
there the server has a choice to make.  Apropos your other comment [3], 
the draft you reviewed (6.2.17 Must Not) requires the server to either 
serve the entire resource (unpaged) or reject the request.  Most servers 
would probably choose a 4xx status code for the rejection case, if the 
resource in question would never be served as paged, although in theory 
5xx could be used if the server dynamically based its decision on things 
like server load.

If this addresses your questions to your satisfaction, or not, please 
respond to that effect on the list.  In the "or not" case, if you have any 
specific changes that would satisfy you by all means supply them as input. 
 The working group will be reviewing in parallel as well, so it is 
possible that this will still evolve; in the case of substantive change, 
we'll have to ask you to take another look, but that seems unlikely.



On the same working group call, the working group endorsed Sandro's 
initial response to change 6.2.17 to a SHOULD NOT, for the reasons he 
articulated.  I'll respond to that thread separately once the associated 
changes are live in the editor's draft.



[1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html
[2] https://dvcs.w3.org/hg/ldpwg/rev/492ad8a031b9
[3] 
http://lists.w3.org/Archives/Public/public-ldp-comments/2014Jul/0001.html

Best Regards, John

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

Received on Monday, 28 July 2014 18:42:04 UTC