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

* John Arwe <johnarwe@us.ibm.com> [2014-07-08 13:05-0400]
> 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; 

The draft [2NN] follows the RFC 7238 [7238] precedent of having a
Deployment section with no 2119 language:
[[
   Per [12], this document registers the Prefer header ([RFC7240])
   value "contents-of-related".  A client MAY include a "Prefer:
   contents-of-related" header with a request to indicate that the
   client can accept 2NN responses.
]]

2NN's deployment unto the masses is roughly analogous to that of 308's
deployment, though arguably, an unexpected 2xx is more likely to
mislead those who care than will an unexpected 308.

I *think* the category of "those who care" is limited to SemWeb "/"ers
who have deployed client-side 303 machinery who need to count on the
server implementer reading the above text and opting against sending
a 2NN to naive clients. Here's my reasoning:

  2NN is defined in terms of a response which pre-fetches Location:.

  Location: is commonly deployed for 201, 301, 302, 303.

  Reload issues have pushed 201 out of favor for generic systems.
  (Specialized systems like Jigedit use 201 with requirements for
  the client to send etags to protect against reload problems.)

  Conventional browsers follow 3xx automatically (see
  <http://www.w3.org/2014/02/2xx/301tests/>
  <http://www.w3.org/2014/02/2xx/302tests/>
  <http://www.w3.org/2014/02/2xx/303tests/>) which is essentially
  mimicked by 209 (see <http://www.w3.org/2014/02/2xx/tests/>).

  Any non-browser clients expecting 303s are probably part of some API
  where the servers are unlikely to choose to screw over their
  unsuspecting clients for a 2NN RFC.

>From that I gather that SemWebbers are the ones who care, and they can
read the deployment section and decide how conservative their service
should be.

I suspect that the 308 motivation to avoid 2112 text was to encourage
future APIs to adopt if they control the client base well enough. I
guess we'd like the same, (as well as existing APIs, e.g. github's
pagination API [GPAG]).

 [2NN] <http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00>
[7238] <http://tools.ietf.org/html/rfc7238#section-4>
[GPAG] <https://developer.github.com/guides/traversing-with-pagination/>

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

nope, intended to be a true hint as above in 3a


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

Since the draft publication process translates that .xml to .txt and
.html representations, I think I'd like to avoid having another slave
copy which will inevitably get out of sync.


> 2: I thought that the sense from Jeni'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.

address ad nauseum above


> 3: "303 See Related" should be "303 See Other"

fixed


> 4: "The 2NN status code response asserts that Location field identifies" 
> >> "The 2NN status code response asserts that the Location response header 
> identifies"

fixed there and one other place.
(who is Roy T. Response Headering?)


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

That's intentional; POSTing, PUTting, etc. to the related resource
would relegate the use of 209 to some peculiar protocols. We're trying
to short cut a 303 followed by a GET
  -> POST /container
  <- 303 Location /container/resource1
  -> GET /container/resource1
  <- 200 ...

This works for GET /Alice as well.


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

I spelled it out in two lists (I'll see your list and raise you one):
[[
By returning a 2NN status code, the server asserts that:

    The expected response has a status code of 200.
    The expected response has no Location header.

The 2NN response is the same as the expected response with the following changes:

    The status code is 2NN (instead of 200).
    A 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).

  POST /foo <guts> -> Location: http://a.example/foo/bar#baz
  GET /foo/bar -> Content-type: text/fragolicious <other guts>

I have no idea what happens to #baz, but I think that's up to the
architect who decided to return it. I hope the current semantics of
2NN faithfully reproduce the above in one transaction. I'd also expect
that relative URIs in the body would resolve against the related
resource as they had the body come in a GET.
[[
For purposes other than caching, the response is interpreted as if the
response code were 200 and the effective request URI were the related
resource.
]]

Does that make sense to you?


> 8: "client performs on operation"  typo; on >> an

fixed


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

Has my #5 response persuaded you?


> 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

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Wednesday, 9 July 2014 14:54:00 UTC