anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt

[Julian Reschke <[e-mail]>]

Hi,

this is the first of several LC comments on 
draft-nottingham-http-link-header-07. Except for the purely editorial 
ones I'll be sending them in separate emails so that it's easier to 
track them.

This is about the anchor parameter.

The changes 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E>) 
say:

    o  Allowed applications to ignore links with anchor parameters if
       they're concerned.

The actual text changed from 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-5>)

    By default, the context of a link conveyed in the Link header field
    is the IRI of the requested resource.  When present, the anchor
    parameter overrides this with another URI, such as a fragment of this
    resource, or a third resource (i.e., when the anchor value is an
    absolute URI).  If the anchor parameter's value is a relative URI, it
    MUST be resolved as per [RFC3986], Section 5.  Note that any base URI
    from the body's content is not applied.


to 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.2>)

    When present and explicitly specified by use by an application, the
    anchor parameter overrides this with another URI, such as a fragment
    of this resource, or a third resource (i.e., when the anchor value is
    an absolute URI).  If the anchor parameter's value is a relative URI,
    parsers MUST resolve it as per [RFC3986], Section 5.  Note that any
    base URI from the body's content is not applied.

So it appears that this change does not "allow applications to ignore", 
but "requires applications to specify how to process", so it's an "opt 
in", not an "opt out".

That being said: what is an "application" in this context? What needs to 
be done to specify this? An example would be useful; for instance, it 
would be interesting what 
<http://tools.ietf.org/html/draft-brown-versioning-link-relations-06#appendix-A.1> 
would need to say to specify the required processing of anchor.

In general I think that making this somehow optional will be an interop 
disaster. Link header processing should be uniform and not depend on 
some out-of-band information.

If the reason this was changed was because of missing support in those 
UAs that currently handle the "Link" header: let's file bugs.

Best regards, Julian