anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
Julian Reschke <julian.reschke@gmx.de> Thu, 21 January 2010 12:54 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A904C3A6AAA for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Thu, 21 Jan 2010 04:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.184
X-Spam-Level:
X-Spam-Status: No, score=-9.184 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 iQx4u06+PMre for <ietfarch-httpbisa-archive-bis2Juki@core3.amsl.com>; Thu, 21 Jan 2010 04:54:39 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id D35F23A6A65 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 21 Jan 2010 04:54:39 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1NXwY9-0007TK-Qf for ietf-http-wg-dist@listhub.w3.org; Thu, 21 Jan 2010 12:54:13 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1NXwY3-0007SL-HX for ietf-http-wg@listhub.w3.org; Thu, 21 Jan 2010 12:54:07 +0000
Received: from mail.gmx.net ([213.165.64.20]) by lisa.w3.org with smtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1NXwY2-0006df-4U for ietf-http-wg@w3.org; Thu, 21 Jan 2010 12:54:07 +0000
Received: (qmail invoked by alias); 21 Jan 2010 12:53:33 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp062) with SMTP; 21 Jan 2010 13:53:33 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+NoSMQUBCNgTP50r69y9wfrIFqv0y5asWpBsghmG ZgLQ1TihBiI1+h
Message-ID: <4B584E46.7000405@gmx.de>
Date: Thu, 21 Jan 2010 13:53:26 +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: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
References: <20100119053002.5CD613A683B@core3.amsl.com> <E4FF7733-D744-4AC3-AB99-66A12868E4CE@mnot.net> <4B56E27D.800@gmx.de>
In-Reply-To: <4B56E27D.800@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57999999999999996
Received-SPF: pass
X-SPF-Guess: pass
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-2.599, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1NXwY2-0006df-4U 429345f908d32972afb2b495974340c5
X-Original-To: ietf-http-wg@w3.org
Subject: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
Archived-At: <http://www.w3.org/mid/4B584E46.7000405@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/8233
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1NXwY9-0007TK-Qf@frink.w3.org>
Resent-Date: Thu, 21 Jan 2010 12:54:13 +0000
Hi, this is the first of several LC comments on draft-nottingham-http-link-header-07. Except for the purely editorial ones I'll be sending them in separate emails so that it's easier to track them. This is about the anchor parameter. The changes (<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E>) say: o Allowed applications to ignore links with anchor parameters if they're concerned. The actual text changed from (<http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-5>) By default, the context of a link conveyed in the Link header field is the IRI of the requested resource. When present, the anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI). If the anchor parameter's value is a relative URI, it MUST be resolved as per [RFC3986], Section 5. Note that any base URI from the body's content is not applied. to (<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.2>) When present and explicitly specified by use by an application, the anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI). If the anchor parameter's value is a relative URI, parsers MUST resolve it as per [RFC3986], Section 5. Note that any base URI from the body's content is not applied. 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". 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. 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. Best regards, Julian
- Fwd: New Version Notification - draft-nottingham-… Mark Nottingham
- Re: New Version Notification - draft-nottingham-h… Mike Burrows
- Re: Fwd: New Version Notification - draft-notting… Julian Reschke
- Re: New Version Notification - draft-nottingham-h… Subbu Allamaraju
- 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… Mike Burrows
- Re: parameter quoting - LC comment on draft-notti… Julian Reschke
- 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… Roy T. Fielding
- 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… 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