W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 29 Jan 2010 13:45:41 +0100
Message-ID: <4B62D875.102@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
> ...
> 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? 
> ...

First of all, I'd prefer to distinguish between (A) "must be processed" 
and (B) "may be processed, otherwise link must be rejected altogether".

I see two purposes for the anchor parameter:

1) Making a statement about a subset of the context resource, by 
specifying a fragment identifier

2) Making a statement about a different resource than the context 
resource, such as

2a) because the context is anonymous (such as the response body for a 
204, see 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-07.html#rfc.section.A.1>), 
or

2b) because a reverse link is exposed (anchor as workaround for missing 
rev parameter)

I'm still not sure why we would ever make special cases here, except for 
the known bugs in current implementations of the Link header where 
anchor is ignored (so mainly Mozilla/Opera for stylesheet links). 
Optimally, we just work with the vendors to get the bugs fixed.

If that's not possible, allowing an opt-out per relation type might 
work, as long as behavior (B) would still be allowed. Is there any 
relation != "stylesheet" for which this would be relevant?

Best regards, Julian
Received on Friday, 29 January 2010 12:46:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:16 GMT