LDP Paging Comments

To whom it may concern:

I'm working on a REST API specification for a project that is interested in
LDP compliance, so please forgive the late timing of this comment in the
editorial process.

I believe I understand the intended value of the LDP-Paging spec, but I
think (as an implementor of clients and servers) that LDP might be better
served by the simpler, but more restrictive, approach of elaborating the
HTTP 1.1 Range Request specification to include member and perhaps triple
as Range units.

The current LDP Paging spec reifies a paged request in a way that is
valuable from a certain perspective of replayability, but unusual in that
it seems to allow the client less control than is typically expected of
paged resources. Consider the following version of Example 3:

GET /customer-relations HTTP/1.1
Host: example.org
Accept: text/turtle
Range: triples=1-500
Prefer: return=representation

The server might reply with:
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
      <http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/customer-relations>; rel='canonical';
etag="customer-relations-v1"
Allow: GET,OPTIONS,HEAD
....

if the entire representation could be fulfilled, or:
HTTP/1.1 206 Partial Content
Content-Type: text/turtle
Content-Range: triples 1-500/600

for a paged response. Alternately, instead of triple limits the client may
just request pages of members:
GET /customer-relations HTTP/1.1
Host: example.org
Accept: text/turtle
Range: members=1-10
Prefer: return=representation

with partial responses:
HTTP/1.1 206 Partial Content
Content-Type: text/turtle
Content-Range: members 1-10/12

This approach would be, I think, a much more natural approach to pages of
members- it leverages the HTTP 1.1 features already required of LDP and
makes paging logic more transparent to the client. At first blush it seems
less linkable, but the opacity of a page link in the current spec and the
reliance on additional request headers regardless make its links less
useful than they appear at first blush. It also gives servers and clients
well-defined ways to advertise their ability to process the paged requests
(and types of pages) within the confines of existing REST specifications.

Regards,
  Benjamin Armintor