2NN draft responses

I think the 2NN draft is ready for final review:
<http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml>

Many thanks for Jeni's/TAG's spec review at
<https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md>.
I've changed the text a lot in response, and drafted these responses.

Following are responses to the TAG comments
<https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md>.
These use the terms "related resource" and "expected response" as defined
in Section 2 of the updated 2NN draft.

1. doesn't work in Chrome:

  Chrome has issues with stylesheets links with relative URLs. I've
  made it absolute, and I believe that early in the IETF process, the
  document will get HTML-ified, text-ified and maybe even tex-ified.

2. s/209/2NN/

  done

3. s/Location/Content-Location/g

  declined, both Location and Content-Location may appear in the same
  2NN response (example in the 2NN draft). The Location identifies the
  target of the redirection and the Content-Location identifies a
  direct URL for any conneg that (would have) happend on a GET of the
  Location header value.

4. add packaging use case

  done

5. clarify interpretation of headers, e.g. Link applies to orig URL.

  All except Location apply to related resource. If we make e.g. Link
  apply to the original URL, we'll have no way to communicate the
  link headers associated with the related resource. There's an example
  with an expected response with a Link header.

6. recommend Link header à la
  Link: <http://example.com/meta>; rel=describedby

  As stated in 5, Link, like all headers, applies to related resource.
  We could have used a REV= link from the related resource back to the
  original URL, but it has been deprecated. Punting for now means not
  trying to define a prescrive behavior which tells people that they
  should use link relationships which may have not yet been invented.
  Of course, people are free to add what Link headers they want.

7. for security, don't extend caching semantics to related resource

  waffling here

  I stipulated that it can be done only with out-of-band trust, which
  is analogous to Content-Location. It could be argued that the C-L
  text only *implies* caching with the text "the origin server claims
  that the URI is an identifier for a different resource corresponding
  to the enclosed representation". I come right out and say "If the
  client has out of band reason to trust the server's claim that the
  same operation performed on the value of the Location header would
  have elicited the same response, they may additionally cache a 200
  response for the requested operation on value of the Location
  header." That seems analogous to the implications of the C-L text,
  albeit a bit more direct.

8. define Accept-Related: describedby, provenance

  I think your goal was that "Accept-Related: first" (or Samdro's
  proposed "Prefer: follow-link rel=first") would leverage the Link
  rel registry to codify what relationship one wants to follow from
  the initial resource.  This exceeds the current expressivity where
  one recieves an e.g. 303 with a single resource in the Location.
  The parameterized Accept-Related would be a shortcut for an exchange
  where the server returned a 303 with maybe no Location but instead
  multiple Link headers and the client did a GET on one of them.

  I think this is fascinating and useful, but I don't think we want to
  predicate 2NN on a rather complex expressivity. It should be easier
  to explain with the single "Prefer: contents-of-related" which says
  "please send me a 209 for the (only) resource you would have
  redirected me to." Once in place, other RFCs can leverage 2NN for a
  growing network of coded link relationships, maybe involving even
  requests like "follow-link rel=first,rel=next" to get the 2nd page.

9. say how 2NN works for other methods

  Currently worded in terms of "the same method executed on the
  related resource" so I think we're covered without having to dream
  up a lot of use cases. The 2NN spec references the HTTPbis spec for
  a use case for POST. PUT, DELETE, ACCEPT and CONNECT become
  progressively harder to think about. There's no restriction in
  HTTPbis about where you might see a 303 but I didn't want to
  specifically prohibit 2NN for use cases I can't predict.

10. Update HTTPbis ref

  done


Potential issues:

  - As mentioned above, 2NN is  defined in terms of any response which
    would yield a  Location header. Maybe we should  say "only 201 and
    3xx" or maybe "only 303".

  - The caching makes explicit some (trusted) caching implications
    that are only implicit in the HTTP spec.

  - A few folks have wanted the client to ask for following specific
    links but I think that's a different spec, written in terms of
    Link headers on 3xx responses.

-- 
-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 Sunday, 15 June 2014 22:19:13 UTC