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

Mark Nottingham wrote:
> 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.

OK, what needs to be done to specify this?

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

Both *parsing* and *processing* should be uniform.

I'm ok with allowing recipients to *reject* (*) link headers that 
include the anchor parameter. On the other hand *ignoring* it needs to 
be a bug.

Best regards, Julian

(*) treat it as invalid

Received on Friday, 22 January 2010 08:40:31 UTC