Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme

Graham Klyne <> Wed, 13 April 2016 10:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0E5A12D5C8; Wed, 13 Apr 2016 03:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u9nbh9yAIiDo; Wed, 13 Apr 2016 03:19:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4885612D7A7; Wed, 13 Apr 2016 03:19:45 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1aqHtc-0004x9-iB; Wed, 13 Apr 2016 11:19:40 +0100
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aqHtc-0002h8-EV; Wed, 13 Apr 2016 11:19:40 +0100
Message-ID: <>
Date: Wed, 13 Apr 2016 11:19:38 +0100
From: Graham Klyne <>
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 <>, Dave Crocker <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <>
Cc:, Apps Discuss <>
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Apr 2016 10:19:48 -0000


(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 "" 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. "") 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:

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.


(*) 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 (