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

apropos the June 30 MUST NOT resolution:

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.

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



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. 

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
Cloud and Smarter Infrastructure OSLC Lead