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

On Dec 9, 2008, at 4:18 AM, Mark Nottingham wrote:

> That's an extraordinarily subtle distinction (and I still haven't  
> thought
> through its impact if we act upon it).

Well, < 
header-03> says

    Each link-value MUST have at least one "rel" or "rev" parameter  
    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.

which is wrong.  The distinction isn't subtle if you think about what
Link defines and how agents are supposed to act on that information.

We should remove the mistaken usage of "outbound" and "inbound" and
the definition of rev should be in section 4 (and deprecated because
experience has shown that reversing semantics is less understandable
by people than choosing inverse relation names).

> Is your preference still to keep rev out of the spec?

No, my preference is to leave it in but deprecate its use.

Also, I note the following:

    If the relation-type is a relative URI, its base URI MUST be
    considered to be "", and  
    corresponding value MUST be present in the link relation registry.

A MUST here requires that implementations look-up the registry to
confirm the entry.  Nobody wants that.  There is no need for these
requirements -- the base is a statement of fact, and the semantics
are necessarily concluded from that fact.  It should just say:

    The URI-reference(s) within relation-type are parsed relative to
    the base URI of <>.
    A relation-type value that is not an absolute URI [RFC3986] is
    therefore presumed to be a relative reference to the corresponding
    relation within the IANA relation registry [cite].  If no such
    registered relation exists or the reference is malformed, then
    the relation is undefined.  Implementations SHOULD ignore relation
    names that they do not understand or have no need to process.


Received on Tuesday, 9 December 2008 21:37:44 UTC