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

[Mark Nottingham <[e-mail]>]

On 22/01/2010, at 7:39 PM, Julian Reschke wrote:

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

Probably just a sentence or two to tease this out at the top. I've been trying to come up with prose for this for a while, but it's difficult to do it without messing it up. Will try again.

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


If that's the case, you're saying that whether the anchor is allowed is really a property of the relation type, not the application, aren't you? 


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