Feedback for draft-nottingham-http-link-header-03

I like this draft a lot, especially how the new focus is on the link relationship instead of the Link header.

> 1.  Introduction
>
>    This document defines typed link relations, independent of the
>    context they occur in.  It does so by clarifying the status of the

I think 'context' needs to be clarified to mean 'content type' or 'transport'. Without the next sentence, this seems to imply that instances of the Link header are not context-sensitive, which they are (resource, representation, etc.).

> 4.  Link Relation Types
>
>    Relation types are not to be confused with media types [RFC4288];
>    they do not identify the format of the representation that results
>    when the link is dereferenced.  Rather, they only describe how the
>    current context is related to another resource.

I think it should also clarify the fact that 'type' is non-authoritative but informative (suggestion, hint). In addition, it should state that 'type' should not be used to imply relationship as is often the case with single-use content-types (favicon is one example). It seems many people find the distinction between 'rel' and 'type' confusing and the spec should make it clear how the parameters relate to each other.

>
> 5.  The Link Header Field
>
>        Link           = "Link" ":" #link-value

The '#' operator is not defined in the referenced ABNF provided (it is defined in the original spec).

>    Each link-value conveys one target URI inside angle brackets ("<>").
>    If it is relative, it MUST be resolved as per [RFC3986].  Note that
>    because it is conveyed in a header, base URIs from content are not
>    applied to it.

Just confirming that URI-Reference can be an empty string, i.e.: Link: <>; rel="something". It is needed for using links with URI-templates [1] where the link value is constructed using a template that does not fit in the URI-Reference space (using a link header extension).

>    The context of links conveyed in the Link header field is the
>    representation that the header is part of.

This makes sense since the header is provided in the context of the representation. However, is there a way to indicate that a link is persistent across representations and is not representation-specific? Do 404 and 303 considered representations?

>    Each link-value MUST have at least one "rel" or "rev" parameter whose
>    value indicates the relation type.  If the "rel" parameter is used,
>    it indicates that the link's direction for that relation type is
>    outbound; if the "rev" parameter is used, the given relation type's
>    direction is inbound.

Is 'rev' considered as authoritative as 'rel' (as in, 'type' is non-authoritative, just a hint)? Forward looking links using 'rel' are clearly authoritative as they indicate the view-point of the resource, which has the authority to declare its own perceive links to other resources. However, 'rev' can go both ways. It seems to be semantically equivalent to an identical 'rel' coming from the linked resource. For example:

Resource A: Link: <http://example.com/b>; rel="friend"
Resource B: Link: <http://example.com/a>; rev="friend"

If the two are semantically identical, 'rev' must be non-authoritative as it serves as a hint as to what another resource view the relationship as: "A declares B to be <<its friend>>, B hints that A <<declares B its friend>>". However, if 'rev' is meant to be authoritative, the two links above cannot be semantically the same, as they read: "A declares B to be <<its friend>>, B declares that A <<consider it a friend>>". The question is, is 'rev' simply an implied 'rel' from the other direction (and so, non-authoritative), or 'rev' is a reverse "opinion" of 'rel' which is completely relative to the resource regardless of any actual 'rel' from the other direction (and so, authoritative).

EHL

[1] http://lists.w3.org/Archives/Public/www-talk/2008NovDec/0006.html

Received on Tuesday, 2 December 2008 07:33:52 UTC