Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
Julian Reschke <julian.reschke@gmx.de> Fri, 22 January 2010 08:40 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 957793A68BD for <apps-discuss@core3.amsl.com>; Fri, 22 Jan 2010 00:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.715
X-Spam-Level:
X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-1.116, 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 GsifD+jVmA7c for <apps-discuss@core3.amsl.com>; Fri, 22 Jan 2010 00:40:02 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 44D5F3A68C4 for <discuss@apps.ietf.org>; Fri, 22 Jan 2010 00:40:01 -0800 (PST)
Received: (qmail invoked by alias); 22 Jan 2010 08:39:54 -0000
Received: from p508FD092.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.208.146] by mail.gmx.net (mp003) with SMTP; 22 Jan 2010 09:39:54 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/cYvsTgTPckoGVEok9U1wmU+v++m5qYLO7760+Tz 960JHN0nueQePi
Message-ID: <4B596450.7020001@gmx.de>
Date: Fri, 22 Jan 2010 09:39:44 +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>
In-Reply-To: <2C94E45E-3373-4694-BFA3-FA7B595EAF65@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57999999999999996
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, 22 Jan 2010 08:40:03 -0000
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? >> 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
- 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