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

Julian Reschke <julian.reschke@gmx.de> Fri, 29 January 2010 12:45 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D511F3A6A6F for <apps-discuss@core3.amsl.com>; Fri, 29 Jan 2010 04:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.832
X-Spam-Level:
X-Spam-Status: No, score=-4.832 tagged_above=-999 required=5 tests=[AWL=-2.233, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sycTs5XVUc7X for <apps-discuss@core3.amsl.com>; Fri, 29 Jan 2010 04:45:30 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 678443A6A51 for <discuss@apps.ietf.org>; Fri, 29 Jan 2010 04:45:30 -0800 (PST)
Received: (qmail invoked by alias); 29 Jan 2010 12:45:50 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp063) with SMTP; 29 Jan 2010 13:45:50 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19peAVo9cBpQO3DgvjNuLkya2Yv3YpEKDWkdFSGmB 1bS+tuq0ULOLIV
Message-ID: <4B62D875.102@gmx.de>
Date: Fri, 29 Jan 2010 13:45:41 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de> <4B584E46.7000405@gmx.de> <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net> <4B596450.7020001@gmx.de> <F1BF65AA-AE8F-435D-9097-AD629488E134@mnot.net>
In-Reply-To: <F1BF65AA-AE8F-435D-9097-AD629488E134@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.65000000000000002
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 12:45:31 -0000

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