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

> Can we keep separate the 2NN issues from the issues that exist whether 
or not 2NN happens?

chuckle; grated minds (sic) think alike; see my "suspicion" paragraph  in 
reply to Ashok

> In particular, 2NN includes this rule from the IETF that servers MUST 
NOT send a 2NN unless they know the client can accept it.

FWIW: I don't see that in Eric P's draft.  Still, separate and separable.

> while non-LDP servers can send 303 to a truncated representation 
whenever they feel like it, LDP servers can only do it if they got a 
Prefer page-size header.
m'kay.  I agree this is within our province to require.  Testability need 
not be limiting.

> I would expect Linked Data clients to follow 303s without paying 
attention, because the 303 might be there to help with httpRange-14.
Which, of course, is more than HTTP warrants (in 2616 or 7231, re-read 
both - waves to Andre).  "See Other" as a mnemonic is pretty 
self-descriptive, although both RFCs are explicit about the relationship 
between the original effective request URI and the 303-Location URI. Being 
careful about burning *all* our bridges though, peace.

>> 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 
> Yes ...
ok, that's at least coherent w/ the resolution.  Based on Ashok's initial 
conflicting reply I'm going to wait a bit before drafting anything on 
this.  See where WG consensus seems to be going.

>> error cases ...303
> That behavior violates the 30 June resolution
ok, that's at least coherent w/ the resolution.  You leave me hanging 
though on what you consider a correct response to be.  I assume from this 
it's 4xx of some flavor, since it's the request that's flawed not a 
temporary server (5xx) problem.  I.e. it falls into what Ashok though was 
a bit harsh at first blush.  The problem of how the client knows that it's 
a problem of it not being a paging client talking to a hardball-playing 
server falls into the 4xx body/general "no standard solution" HTTP bucket, 
is the implication.


Best Regards, John

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