W3C home > Mailing lists > Public > www-tag@w3.org > June 2014

Re: 2NN draft responses

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Mon, 16 Jun 2014 16:32:40 +0900
Message-ID: <539E9D98.4090708@it.aoyama.ac.jp>
To: Eric Prud'hommeaux <eric@w3.org>, public-ldp-wg@w3.org, www-tag@w3.org
CC: Jeni Tennison <jeni@jenitennison.com>, John Arwe <johnarwe@us.ibm.com>
Hello Eric,

On 2014/06/16 07:19, Eric Prud'hommeaux wrote:
> I think the 2NN draft is ready for final review:
> <http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml>

This is labeled as an Internet Draft (and should be an Internet Draft, 
because the IETF is in charge of HTTP status codes). But Internet Drafts 
are published at http://www.ietf.org/ (see 
https://datatracker.ietf.org/submit/ for submission). "Final review" 
before publishing the first draft sounds confusing. Can you explain?

Regards,   Martin.

> 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.
Received on Monday, 16 June 2014 07:33:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:02 UTC