Re: [art] Question regarding RFC 8089

John C Klensin <john-ietf@jck.com> Tue, 18 December 2018 08:17 UTC

Return-Path: <john-ietf@jck.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 94CC7128CF2 for <art@ietfa.amsl.com>; Tue, 18 Dec 2018 00:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 OmmtHeo7YlDr for <art@ietfa.amsl.com>; Tue, 18 Dec 2018 00:17:17 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CE0127598 for <art@ietf.org>; Tue, 18 Dec 2018 00:17:17 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1gZAYy-000MZ7-3F; Tue, 18 Dec 2018 03:17:12 -0500
Date: Tue, 18 Dec 2018 03:17:04 -0500
From: John C Klensin <john-ietf@jck.com>
To: Mark Nottingham <mnot@mnot.net>, "Julian F. Reschke" <julian.reschke@gmx.de>
cc: "General Area Review Team (gen-art@ietf.org)" <art@ietf.org>, Matthew Kerwin <matthew@kerwin.net.au>, Stephan Bergmann <sbergman@redhat.com>
Message-ID: <1FC45B47B703AED3FAE346F4@PSB>
In-Reply-To: <114E58B9-0CB4-4B98-B6C8-D2B84879EE6B@mnot.net>
References: <f49638dc-4a0e-e03d-7e91-b968a1217679@redhat.com> <CACweHNBps_O0JqAUFj5FD3V+LzbTWUKNKuFzKk82WR+33b8seA@mail.gmail.com> <45967886-f3f4-12b8-75b7-2b9199e59bfa@gmx.de> <114E58B9-0CB4-4B98-B6C8-D2B84879EE6B@mnot.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/5KYHHqJYNv9g4eN2KKmiX1ss1C8>
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: Tue, 18 Dec 2018 08:17:20 -0000

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.  That is very
different from specifying the details of the syntax or semantics
of that identifier if it is allowed and it is not clear to me
from reading 3986 whether the default, if the scheme definition
doesn't say anything, is "yes" or "no".

     john


--On Tuesday, December 18, 2018 09:09 +1100 Mark Nottingham
<mnot@mnot.net> wrote:

> To add a bit -
> 
> URI scheme definitions are supposed *not* to define fragment
> identifiers, since their interpretation is dependent upon the
> media type, not the scheme.
> 
> This has caused confusion in the past; see
> <https://github.com/httpwg/http-core/issues/103>. 
> 
> Cheers,
> 
> 
>> On 18 Dec 2018, at 9:04 am, Julian Reschke
>> <julian.reschke@gmx.de> wrote:
>> 
>> On 2018-12-17 22:57, Matthew Kerwin wrote:
>>> On Tue, 18 Dec 2018 at 03:15, Stephan Bergmann
>>> <sbergman@redhat.com> wrote:
>>>> 
>>>> Is it intentionally so that file URIs do not support
>>>> neither a query nor a fragment part?  At least, that is how
>>>> I read RFC 8089 section 2 in combination with RFC 3986
>>>> section 3.
>>>> 
>>> I would say: a bit yes, a bit no. There was definitely no
>>> support for query or fragment in RFC 1630 nor 1738, and we
>>> never explicitly *added* support in 8089.
>>> The two goals of RFC 8089 were: to publish an RFC for file
>>> URIs with unambiguous status, and to align the
>>> syntax/definition with RFC 3986. According to the letter of
>>> the law (i.e. RFC 3986): "The query component contains
>>> non-hierarchical data that, along with data in the path
>>> component, serves to identify a resource..."  So as far as
>>> aligning with that definition, it wouldn't have made sense
>>> to add a query component.  Files are identified by purely
>>> hierarchical data. As to the fragment, it's a bit murky, but
>>> the way I read RFC 3986, section 3.5, "The fragment's format
>>> and resolution is ... dependent on the media type of a
>>> potentially retrieved representation..." Since the resource
>>> representation retrieved by dereferencing a file URI doesn't
>>> have a media type (heuristics notwithstanding) it doesn't
>>> make sense to include a fragment component in the URI
>>> scheme, since it would always be undefined.
>>> All that said, file URI syntax is now a subset of the
>>> generic syntax, so you're technically able to parse a file
>>> URI with query and/or fragment components.  If that's useful
>>> for you -- e.g. if you are confident that your media type
>>> heuristics are good enough to make fragment components
>>> workable -- then nothing stops you.  Clearly the browsers
>>> support it; although I don't know what it would mean for
>>> something like cURL or urllib to have to deal with a query
>>> component, so I don't know how it could be added to the
>>> scheme definition.  You could always just go with
>>> https://url.spec.whatwg.org/ instead... A little bit of
>>> whataboutism occurs to me: what about data URIs?  They *do*
>>> have media type information, but don't define fragments in
>>> the URI scheme.
>>> ...
>> 
>> URI schemes do not *need* to define fragment handling. It's
>> inherent once the media type has been determined.
>> 
>> Best regards, Julian
>> 
>> _______________________________________________
>> art mailing list
>> art@ietf.org
>> https://www.ietf.org/mailman/listinfo/art
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art