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

[Mark Nottingham <[e-mail]>]

On 21/01/2010, at 11:53 PM, Julian Reschke wrote:

> 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".

Yes, sorry; forgot to (re-)update the changelog on that one.

> 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.

Yes, it would. "Application" is intentionally a bit fuzzy, because while some link relations are defined by their application, others have been purposefully separated; e.g., "alternate" is used for a variety of purposes.

> 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.

It wasn't, and the link header parsing is the same; it's just the interpretation that changes, depending on whether the application expects the anchor parameter to be used. This was done because in many (or even most) instances, it's very surprising to have a link from A to B to be able to assert things about C, and have their semantics automatically applied. 

Cheers,


--
Mark Nottingham     http://www.mnot.net/