IETF Logo Mail Archive

Re: [art] Question regarding RFC 8089

"Roy T. Fielding" <fielding@gbiv.com> Thu, 17 January 2019 18:19 UTC

Return-Path: <fielding@gbiv.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECABF130EC3 for <art@ietfa.amsl.com>; Thu, 17 Jan 2019 10:19:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gbiv.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrXXhEmlDt-z for <art@ietfa.amsl.com>; Thu, 17 Jan 2019 10:19:06 -0800 (PST)
Received: from goldenrod.birch.relay.mailchannels.net (goldenrod.birch.relay.mailchannels.net [23.83.209.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831F2130EA0 for <art@ietf.org>; Thu, 17 Jan 2019 10:19:06 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 95390282314; Thu, 17 Jan 2019 18:19:05 +0000 (UTC)
Received: from pdx1-sub0-mail-a3.g.dreamhost.com (unknown [100.96.30.62]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 24EF7283C34; Thu, 17 Jan 2019 18:19:05 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|fielding@gbiv.com
Received: from pdx1-sub0-mail-a3.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Thu, 17 Jan 2019 18:19:05 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|fielding@gbiv.com
X-MailChannels-Auth-Id: dreamhost
X-Supply-Thread: 7fdcad190367265c_1547749145392_264069921
X-MC-Loop-Signature: 1547749145392:184620368
X-MC-Ingress-Time: 1547749145392
Received: from pdx1-sub0-mail-a3.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTP id CA2C58040A; Thu, 17 Jan 2019 10:19:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=oQjvqpqmvL8PjjF5/6OrHgRnzBY=; b=FfF38affJbR0TLgxra3DUwhcRaxD JC7IGElsRmexFnNkoQCZqchhFQD/VEINmerwpD0ikFrENPcTAD9zV33cYIa2Er2m E6WH8k6JWN4zbl7hSLpzsrzYYWbSjM82RLjlMwXHYuAN4yrKAqzO2WO92j5GCM9v /I05pT+gwPXRazM=
Received: from [192.168.1.13] (ip68-228-64-138.oc.oc.cox.net [68.228.64.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by pdx1-sub0-mail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 5C24980409; Thu, 17 Jan 2019 10:18:59 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
X-DH-BACKEND: pdx1-sub0-mail-a3
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <87y37k2e1y.fsf@hobgoblin.ariadne.com>
Date: Thu, 17 Jan 2019 10:19:02 -0800
Cc: John C Klensin <john-ietf@jck.com>, Julian Reschke <julian.reschke@gmx.de>, art@ietf.org, Mark Nottingham <mnot@mnot.net>, matthew@kerwin.net.au, sbergman@redhat.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F7BA309-7C94-47D7-9379-0CAD31C7A60D@gbiv.com>
References: <87y37k2e1y.fsf@hobgoblin.ariadne.com>
To: "Dale R. Worley" <worley@ariadne.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtledrgeekgddutdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepfdftohihucfvrdcuhfhivghlughinhhgfdcuoehfihgvlhguihhnghesghgsihhvrdgtohhmqeenucfkphepieekrddvvdekrdeigedrudefkeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplgduledvrdduieekrddurddufegnpdhinhgvthepieekrddvvdekrdeigedrudefkedprhgvthhurhhnqdhprghthhepfdftohihucfvrdcuhfhivghlughinhhgfdcuoehfihgvlhguihhnghesghgsihhvrdgtohhmqedpmhgrihhlfhhrohhmpehfihgvlhguihhnghesghgsihhvrdgtohhmpdhnrhgtphhtthhopehssggvrhhgmhgrnhesrhgvughhrghtrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/K_PIVUo-tYehFTiiQUNdxpIo_K0>
Subject: Re: [art] Question regarding RFC 8089
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2019 18:19:09 -0000

> On Jan 16, 2019, at 6:50 PM, Dale R. Worley <worley@ariadne.com> wrote:
> 
> John C Klensin <john-ietf@jck.com> writes:
>> However, Mark, it seems to me to be entirely appropriate, and
>> consistent with 3986, for a scheme definition to state whether
>> or not a fragment identifier is permitted.
> 
> I argue that the *scheme* does not define whether a fragment identifier
> is permitted, but rather the media type of the referenced resource
> defines it.
> 
> This does mean that if the scheme defines its URIs in such a way that
> the referenced resource can never have a media type, or can never have a
> media type that defines fragment identifiers, then the scheme
> effectively forbids the use of fragment identifiers.  (sip: is an
> example of such a scheme; its referenced resource can only be used
> dynamically, and cannot be instantiated as a "media object".)

That is a reasonable argument, but it isn't quite true. A resource that is not
dereferenced doesn't have an associated media type at that point in time, but
this doesn't prevent it from having one at some other point in time, or when
referenced within some other context, no matter what the scheme says.
For example, HTTP can be used to dereference sip identifiers and the media
type of the response does support fragment ids.

We say that the fragment is unconstrained by the scheme because that's
how indirect identifiers work.  I can identify my son without using his name,
and I can identify my daughter even though I don't have one.

The right thing to do is to simply admit that indirect identifiers exist, provide
them with a syntax that won't be confused with the direct identifier, and let
systems decide whether to use them or not based on their usefulness for
that system (not based on committee opinions).

....Roy

v2.23.0 | Report a Bug | By Email