Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
Mark Nottingham <mnot@mnot.net> Sun, 28 February 2010 11:22 UTC
Return-Path: <mnot@mnot.net>
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 7116B3A8708 for <apps-discuss@core3.amsl.com>; Sun, 28 Feb 2010 03:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
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 1KjzbjA956GN for <apps-discuss@core3.amsl.com>; Sun, 28 Feb 2010 03:22:14 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 520363A7507 for <discuss@apps.ietf.org>; Sun, 28 Feb 2010 03:22:14 -0800 (PST)
Received: from chancetrain-lm.mnot.net (unknown [118.209.189.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E5F22509DA; Sun, 28 Feb 2010 06:22:06 -0500 (EST)
Subject: Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <4B879921.9060900@gmx.de>
Date: Sun, 28 Feb 2010 22:22:02 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D7C8ED7-F5B0-4B2A-89B8-26BB4D469ADE@mnot.net>
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> <4B62D875.102@gmx.de> <7B248F44-44D9-4054-84A2-E9C4C5C251E1@mnot.net> <4B6C1144.4090502@gmx.de> <5C1BFD92-7E8D-4ABF-A986-03ADC50A18CD@mnot.net> <4B7E5A62.6080304@gmx.de> <CF905E97-0BDC-47A5-8F7E-01B0136CE384@mnot.net> <4B879921.9060900@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1077)
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: Sun, 28 Feb 2010 11:22:15 -0000
I think we're saying the same thing here, but your text seems to rely upon the reader to understand that it's underspecified purposefully (the "syntax they don't grok"), whereas I'd like to surface that in the document. I know it's a bit messy, but there *is* a concept of something that says "when you're using links for X, this is valid, this isn't." I.e., consumers don't just pick a number from /dev/random to determine whether or not they pay attention to links with anchor parameters; it's written down somewhere, based on what they're doing with the link. I hesitate to make this into a big deal, especially since we're so close (I think) to having this out the door, but letting clients make an arbitrary decision is horrible for interoperability. If I'm using a link header to tell a web browser where a stylesheet is, I should be able to expect that different implementations will behave the same way with regard to it. On 26/02/2010, at 8:49 PM, Julian Reschke wrote: > On 26.02.2010 05:44, Mark Nottingham wrote: >> What's<ref> here? I still don't see where the decision is made... at worst, this makes it seem like consumers can make an arbitrary decision as to whether to process a link with an anchor. > > <ref> would point to text that states how to resolve against the context IRI when present. > > And yes, I think consumers can make an almost arbitrary decision about it -- either they ignore the syntax they don't grok, or they process it as specified (where there's really only a single way to process them). > >> This is where I am now: >> >> Links with the anchor parameter MUST be ignored by consuming implementations, unless their use is explicitly specified. > > That doesn't work for me, as it makes it sound that somebody needs to do additional work to "specify" it. Who? And what? The only thing that needs to be said is that the anchor param modifies the context, and recipients are allowed to ignore it if the resolved context IRI differs from the original one. > > So how about (adding more context): > > "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. > > Note that the presence of the anchor parameter affects the context IRI. Thus, consumers either MUST ignore all links that include the anchor parameter, or process it according to its definition above. In the latter case, the resulting context IRI can identify an entirely different resource, in which case consumers can choose to ignore the link." > > (We might have to tune the paragraph for the case where the context resource is anonymous, though) > > > ... > > Best regards, Julian -- Mark Nottingham http://www.mnot.net/
- 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