Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
Graham Klyne <gk@ninebynine.org> Wed, 13 April 2016 10:19 UTC
Return-Path: <gk@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5A12D5C8; Wed, 13 Apr 2016 03:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 u9nbh9yAIiDo; Wed, 13 Apr 2016 03:19:45 -0700 (PDT)
Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4885612D7A7; Wed, 13 Apr 2016 03:19:45 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1aqHtc-0004x9-iB; Wed, 13 Apr 2016 11:19:40 +0100
Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1aqHtc-0002h8-EV; Wed, 13 Apr 2016 11:19:40 +0100
Message-ID: <570E1D3A.5050608@ninebynine.org>
Date: Wed, 13 Apr 2016 11:19:38 +0100
From: Graham Klyne <gk@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Matthew Kerwin <matthew@kerwin.net.au>, Dave Crocker <dcrocker@bbiw.net>
References: <570D4C99.1030405@dcrocker.net> <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com>
In-Reply-To: <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/Iv20qlhRSBdcMSK7ULXJkMJCozI>
Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Apr 2016 10:19:48 -0000
Dave, (writing as a s/w dev who uses URIs a lot...) I think the role of file: URIs is slightly unusual as a protocol element. It appears in contexts where a network address may be used, but (in my experience) is mainly used to trigger local access. So in an application that uses a URI like "http://example.org/somedata" to address some data on the web, it can also be really useful to be able to use "file:///somelocaldata" to tell the application to read a local file. What I never use is a file URI to actually access data from another system (*). So I don't think that interop of cross-system data access is the primary concern here. BUT, there is one case where common interpretation and interop is really important, and that is relative URI reference resolution. Something I commonly do is use relative references (e.g. "someplace/somedata") in my data, which may be hosted on a web server (e.g. "http://www.example.org/") or in a local file system ("file:///home/user/exampledata/"). What is important to me is that the relative reference resolves consistently in these situations. E.g., for the examples given, to yield absolute addresses respectively of: http://www.example.org/someplace/somedata and file:///home/user/exampledata/someplace/somedata In the past, the problem has been that the local system quirks cause deviant behaviour (e.g. what happens if the base URI used is based on a Windows path, e.g. "C:/someuser/") - it is "edge cases" like this that have caused me difficulties in the past running software on different systems. I believe that Matthew's draft, as currently structured, does usefully navigate this space between desired and widely implemented core functionality and likely-to-be-encountered quirks. I would hope that by publishing this as a standard document, we will see programming language URI-handling library functions converge to provide the defined core behaviour. #g -- (*) other than a mounted network file system. On 13/04/2016 09:28, Matthew Kerwin wrote: >> > >> >A file: construct should be of significant utility to the Internet >> >community. So it warrants careful community review and extensive >> >indication of active support. That is, there ought to be a basis for >> >assessing the likelihood of implementation and use. As of now, this is not >> >possible. >> > >> > > Technically it's already implemented in a bunch of places, not always > entirely interoperably. Most of the non-interoperable parts are in the edge > cases, but the "common core" is pretty universal. Since there's no > (non-obsolete) spec that defines it, what I want to achieve with this draft > -- if nothing else -- is to put that "common core" in a (non-obsolete) spec. > > If that just meant de-obsoleting RFC 1738 that would almost be enough > (although an update might be in order.) However the discussion that started > with that question has lead us to where we are now, with this draft. > > For what it's worth, at least one potential implementation is likely: the > Ruby standard library OpenURI module, which was the original reason I > started pursuing this in the first place ( > https://bugs.ruby-lang.org/issues/8544) > > >
- [apps-discuss] Review of draft-ietf-appsawg-file-… Dave Crocker
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Murray S. Kucherawy
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Graham Klyne
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Graham Klyne
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Graham Klyne
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Graham Klyne
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Graham Klyne
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Graham Klyne
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Graham Klyne
- [apps-discuss] Experimental (was - Re: Review of … Dave Crocker
- [apps-discuss] Implementation (was - Re: Review o… Dave Crocker
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Dave Crocker
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… t.petch
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… t.petch
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… t.petch
- Re: [apps-discuss] Experimental (was - Re: Review… John Levine
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Experimental (was - Re: Review… Dave Crocker
- Re: [apps-discuss] Experimental (was - Re: Review… Mark Nottingham
- Re: [apps-discuss] Experimental (was - Re: Review… Matthew Kerwin
- Re: [apps-discuss] Experimental (was - Re: Review… Dave Crocker
- Re: [apps-discuss] Experimental (was - Re: Review… Matthew Kerwin
- Re: [apps-discuss] Experimental (was - Re: Review… Dave Crocker
- Re: [apps-discuss] Experimental (was - Re: Review… Mark Nottingham
- Re: [apps-discuss] Experimental (was - Re: Review… Graham Klyne
- Re: [apps-discuss] Experimental (was - Re: Review… Graham Klyne
- Re: [apps-discuss] Experimental (was - Re: Review… Dave Crocker
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Julian Reschke
- [apps-discuss] New information relating to draft-… Graham Klyne
- Re: [apps-discuss] New information relating to dr… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Martin J. Dürst
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Murray S. Kucherawy
- Re: [apps-discuss] New information relating to dr… Graham Klyne
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Julian Reschke
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… John C Klensin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Martin J. Dürst
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… John C Klensin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Ned Freed
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… John C Klensin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Dave Crocker
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Sean Leonard
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Matthew Kerwin
- Re: [apps-discuss] Review of draft-ietf-appsawg-f… Sean Leonard