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

On 07/08/2014 01:05 PM, John Arwe wrote:
> apropos the June 30 MUST NOT resolution:
>

John, I like to think I'm smart enough to follow this, but... maybe not 
without some more sleep or something.

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

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

HTTP has no such rule about 303, which is why we needed that 30 june 
resolution ("LDP servers MUST NOT initiate paging unless the client has 
indicated it understands paging (such as via the Prefer page-size 
header").   That means that 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.

For the rest of my reply I'm going to ignore the 2NN issues, talking 
only about non-2NN issues.

In general I would expect Linked Data clients to follow 303s without 
paying attention, because the 303 might be there to help with 
httpRange-14.    So clients need special code to look at the Link 
headers and figure out (I guess by looking for that link to the paged 
resource) that they got an in-sequence page instead of what they were 
expecting -- and if they were asked to get all the data, they MUST 
follow all the rel=next links.   I don't think we can mandate every LDP 
client will do that, so instead we say servers MUST NOT send that kind 
of paging-initiating 303 unless they got a Prefer Page-Size header.


> 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.
>

Yes.   Be definition and LDP Paging Client (1) behaves properly if the 
server initiates paging, and (2) identifies itself as an LDP paging 
client by sending the prefer page-size.

> 2: The minutes had no mention of error cases.  I won't be surprised if 
> some devs say that certain containers are paged, period (no non-paged 
> access).  If that URL gets a GET request sans a page-size preference, 
> I would tell them to redirect same as we would do in the absence of 2NN.

That behavior violates the 30 June resolution.    I can see why they 
would want that, but if they do that, they force every client to 
understand paging.    If we want interop, we need either the client or 
the server to be required to be flexible.   The group seemed to 
prioritize simplicity in the client.  Plus, we'd need to go back to LC 
on LDP.   I'm fairly ambivalent on client vs server simplicity myself, 
but I'd prefer not to backtrack (since that would put LDP-WG into EXPTIME).


>  I wonder out loud of something to that effect needs to be in the 
> spec, to head off the 2NN abusers.  Any objections?  If the IETF draft 
> is updated to cover this (more below), then we would not need to do 
> anything.
>
> 3: If we are basing Paging on Eric P's IETF draft [1], I don't see why 
> this resolution was needed in this form (although this may be related 
> to IETF.2 below).  The TAG's comments, and the IETF draft, define an 
> opt-in model for clients to use, by which servers decide between 303 
> and 2NN responses.
>
> 3a: If [1] intends its new Prefer opt-in to be a "true hint" (i.e. 
> server can ignore it if the server so desires), as currently written, 
> then our Must Not should be written in terms of that Prefer header IMO;
>
> 3b: if [1] _does_ intend the same result as our Must Not, then ours is 
> normatively superfluous once [1] is clarified and the June 30 
> resolution should be reversed, although we could certainly draw 
> non-normative attention to it in the client and/or "other specs' 
> important info" sections.
>

I think this is all about 2nn, so I'm going to put it off for now.

>
>
> other questions
>
> 1: We currently have the following clause under LDPC.General, which 
> seems unnecessary to me.  Other opinions?  I don't think we're trying 
> to define Yet Another Kind of Container here, we're just adding a way 
> to communicate whatever ordering the server is using *on any existing 
> container* that happens to be a paged resource.  The term Linked Data 
> Platform Paging Container only occurs in that section; if we're trying 
> to formally define a YAKC then we need something up in Conformance too.
>
> > Each Linked Data Platform Paging Container MUST also be a conforming 
> Linked Data Platform Container.
>

Yeah, seems superfluous to me, too.

Stopping here.

       - Sandro


> 2: I'm adjusting the text to align with Eric P's IETF draft, e.g. the 
> change of status code mnemonic.
>
>
>
> IETF draft questions/comments for Eric P
>
> 1: [1] does not render well in FF ESR either (IIRC Judi said it was 
> borked in Chrome) ... it seems to think it has >> width than my window 
> or 20" screen to render within, and no horiz scroll bar.  If I 
> maximize the window on a 24" screen I can see the whole thing, just 
> barely.  Interestingly, after I moved it to the larger screen and 
> restored the window to its former size, your content was re-flowed to 
> fit.  So at least in the FF case there is a timing window in play.
>
> 2: I thought that the sense from Judi's draft TAG comments was that 
> 2NN Must Not be used by servers without the opt-in of the Prefer: 
> contents-of-related request header.  I do not see that requirement in 
> the IETF draft however.  Re-reading item 8 in her comments [2], I 
> don't see the "must not" sense that I remember however ... more a 
> "just like other conneg hints" sense.  So maybe this was something I 
> got from the telling not reflected in the bits.  In item 8 2NN and 303 
> are the only options.  Section 4 says clients MAY include the header; 
> nothing about what servers are permitted to do in its absence.
>
> 3: "303 See Related" should be "303 See Other"
>
> 4: "The 2NN status code response asserts that Location field 
> identifies" >> "The 2NN status code response asserts that the Location 
> response header identifies"
>
> 5: "The "expected response" is the response that the client would have 
> received had it performed a GET on"  GET >> the same method  ... in 
> the previous sentence you apply it to all methods, giving examples of 
> GET or POST, then here you are overly specific by saying GET.
>
> 6: "By returning a 2NN status code, ..." turned a bit opaque.  One 
> problem is 2 'and's in the same sentence.  See if you like this 
> version any better:
> By returning a 2NN status code, the server asserts that its 2NN 
> response is the same as the expected response with the following changes:
> 1.  the expected response has a status code of 200 instead of 2NN
> 2. the expected response has no Location header
> The 2NN response's Location header identifies the related resource.
>
> 7: A murky point in the original that #6 brought into my forebrain is 
> the handling of various Location value classes, since you also talk 
> about "effective request URI" in the other-than-caching section.  [3] 
> allows any URI reference as a Location value (a bit of a surprise to 
> me), talks about fragment handling (double yikes), as well as relative 
> reference resolution (wait for it... using the -actual- effective 
> request URI, which I'm not sure if we want in the 2NN case).  The 
> fragment language is specific to 3xx, but since that is what 2NN is 
> meant to replace in part, due diligence is required.  I suspect on the 
> relative resolution piece we can let 7231 govern the syntax, and put 
> the burden on server implementers to get their code right (or avoid 
> the issue by using absolute URIs).
>
> 8: "client performs on operation"  typo; on >> an
>
> 9: similar issue as #5, different context: "client performs on 
> operation on a resource, the server responds with a 303, and the 
> client performs a GET (or HEAD) "  latter should be "performs the same 
> operation"
>
> 10: GET-centricity also leaked heavily into 3.1.  I completely agree 
> it's the normal case, but as was recently pointed out to me others 
> like Post are _eligible_ for caching normally as well.
>
>
> [1] http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml
> [2] 
> https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md
> [3] http://tools.ietf.org/html/rfc7231#section-7.1.2
>
> Best Regards, John
>
> Voice US 845-435-9470 BluePages 
> <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe> 
>
> Cloud and Smarter Infrastructure OSLC Lead
>