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
- Fwd: New Version Notification - draft-nottingham-… Mark Nottingham
- Re: Fwd: New Version Notification - draft-notting… Julian Reschke
- Re: New Version Notification - draft-nottingham-h… Jan Algermissen
- anchor parameter - LC comment on draft-nottingham… Julian Reschke
- rev parameter - LC comment on draft-nottingham-ht… Julian Reschke
- parameter quoting - LC comment on draft-nottingha… Julian Reschke
- editorial LC comments on draft-nottingham-http-li… Julian Reschke
- exposing sensitive information in URIs - LC comme… Julian Reschke
- Re: parameter quoting - LC comment on draft-notti… Julian Reschke
- Re: New Version Notification - draft-nottingham-h… Mike Burrows
- Re: New Version Notification - draft-nottingham-h… Subbu Allamaraju
- Re: parameter quoting - LC comment on draft-notti… Mike Burrows
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: parameter quoting - LC comment on draft-notti… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: editorial LC comments on draft-nottingham-htt… Mark Nottingham
- Re: New Version Notification - draft-nottingham-h… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: parameter quoting - LC comment on draft-notti… Julian Reschke
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: New Version Notification - draft-nottingham-h… Subbu Allamaraju
- Re: New Version Notification - draft-nottingham-h… Jan Algermissen
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: New Version Notification - draft-nottingham-h… Mark Nottingham
- Re: exposing sensitive information in URIs - LC c… Mark Nottingham
- Re: New Version Notification - draft-nottingham-h… Subbu Allamaraju
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: editorial LC comments on draft-nottingham-htt… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Anne van Kesteren
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: rev parameter - LC comment on draft-nottingha… Roy T. Fielding
- Re: rev parameter - LC comment on draft-nottingha… Mark Nottingham
- Re: rev parameter - LC comment on draft-nottingha… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke
- Re: anchor parameter - LC comment on draft-nottin… Mark Nottingham
- Re: anchor parameter - LC comment on draft-nottin… Julian Reschke