LDP "paging"

I took a fresh look at the LDP paging spec [1] this morning, and I have 
three main thoughts (and a lot of editorial thoughts which can wait):

1.  We're not ready to decide on publication today.

2.  On the issue of terminology [2], I'm now thinking that just changing 
"single-page resource" will leave something of a mishmash.   It would be 
much cleaner to have another set of terms which doesn't overlap with Web 
Pages.   For example "segment", so we'd have "segmented resource" and 
"segment resources" (or just "segments", less formally).   Or, more 
fancifully, "chapter", so we'd have "chaptered resource" and "chapter 
resources" (or just "chapters", less formally).

If we adopt one of those, we might consider changing the name of the 
spec to match (LDP Segments, LDP Chapters), although I can still see how 
the whole process could be called "paging", even if you're "paging 
through segments" or "paging through chapters".

3.  On the key issue of initiation and interoperability (and thus 
conformance), I believe this is our current story, reframed in a way 
that makes sense to me:

    There are five kinds of LDP clients with respect to paging:

    Type 1, the Non-Paging LDP Client.  Ignores first/last/next/prev
    headers, ignores 303.  If the server decides a resource is too big
    and tries a 303, this client will break.  LDP Spec says clients
    SHOULD NOT be like this, but allows them to be like this and still
    be conforming LDP Clients.

    Type 2, the Silent-Paging LDP Client.  Ignores first/last headers,
    but follows a 303 redirect and then follows rel=next headers, so it
    works properly if a server initiate paging using a 303.   If servers
    assume every client is like this, they can do something like
    automatic paging for containers with over 1000 members.   But they
    will be breaking any Type 1 (Non-Paging) clients.

    Type 3, the Paging-Acceptable LDP Client.  Follows 303/rel=next like
    Type 2, implements 2nn as well, and most importantly sends a Prefer:
    page-size header, letting the server know it's safe to initiate
    paging with 2nn or 303.   (Per IETF, 2nn MUST NOT be used unless
    there is reason to believe the client understands it, and Prefer:
    page-size is the only way we're defining to give the server that
    information).   This type of client can stream-process resources and
    intends to fetch all pages, so it sees no actual benefit from
    paging.   As such, it might provide a very large page size, but I
    suggest we define page-size=unlim for this case.

    Type 4, the Paging-Preferred LDP Client.  Like Paging-Acceptable,
    but it can't stream process, or wants just a little bit of the data,
    or wants long pauses in streaming, or has some other reason to have
    a preference for paging of large resources.  So it sends an explicit
    page-size.

    Type 5, the Tries-Paging-First LDP Client.   Like Paging-Preferred,
    but first tries doing a HEAD, looking for rel=first or rel=last. 
    This allows paging from servers that don't do 303 or 2nn.   Also
    allows paging in reverse order.  Falls back to doing a GET if those
    headers are not present.  I suggest it MUST include the Prefer:
    page-size header on it's HEAD request, in case the server only pages
    upon request.

That all seems fairly reasonable.   If complicated.   But I can't see 
how to simplify it without breaking things.     Personally, I think 
everyone should aim for Types 3 and 4, but I see why people might need 
1, 2, and 5.

There's a corresponding analysis one could do on the servers, but it's a 
little simpler and I'm out of time.

         -- Sandro


[1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html
[2] https://www.w3.org/2012/ldp/wiki/Names_in_Paging