Re: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme)

Graham Klyne <> Thu, 14 April 2016 10:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC15712E3A2 for <>; Thu, 14 Apr 2016 03:17:48 -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 BcHHlBsM8zQD for <>; Thu, 14 Apr 2016 03:17:43 -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 E9BCB12E395 for <>; Thu, 14 Apr 2016 03:17:41 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1aqeKy-0000L2-s6; Thu, 14 Apr 2016 11:17:24 +0100
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aqeKy-0002Ip-Hs; Thu, 14 Apr 2016 11:17:24 +0100
Message-ID: <>
Date: Thu, 14 Apr 2016 11:17:22 +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: Mark Nottingham <>, Dave Crocker <>
References: <20160413200825.15190.qmail@ary.lan> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: <>
Cc: General discussion of application-layer protocols <>
Subject: Re: [apps-discuss] Experimental (was - Re: 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: Thu, 14 Apr 2016 10:17:49 -0000

I'm not sure if this will help, or just add more noise, but...

TL;DR:  I don't think the "over the wire" issue should be elevated to the level 
of dogma.  Systems are more complicated than that.


For me, as a developer, the value of a file:// URI is not what gets sent "over 
the wire", but what does *not* get sent over the wire.

I mainly work on applications for "small data" (but very heterogeneous). I 
create data that can be served on the web, or locally from a file system.  The 
data itself is location agnostic (i.e. portable), and internally uses relative 
URI references.  The existence of file: URIs is important to this mechanism 
because they can be used locally as a base URI to access data that is stored 

So why do I feel the file: is an important specification that impacts 
interoperability in a network protocol suite?

1. it can be used uniformly as part of a structure that does operate 
predominantly over the network.

2. It can be used to provide a local context for interpreting data that *has* 
been sent "over the wire".

This is why I have said that (for me at least), the most important part of the 
file: URI spec is that it behaves consistently with respect to URI resolution.


On 14/04/2016 06:35, Mark Nottingham wrote:
> What do you consider "the wire" for the purposes of the file:// URL scheme?
>> On 14 Apr 2016, at 1:06 PM, Dave Crocker <> wrote:
>> On 4/13/2016 7:55 PM, Matthew Kerwin wrote:
>>>     This is why focusing on bits over the wire is better than talking
>>>     about software implementation details.  If the 'different ways' mean
>>>     different bits over the wire, then they are using different formats
>>>     or different protocols.  And they won't interoperate.
>>>     If they generate/parse the same bits and same semantics over the
>>>     wire, this we don't care how the built the software to do it,
>>>     because they /do/ interoperate.
>>> The 'different ways' are actually different bits over the wire. Mostly
>>> those are the bits that weren't part of the original spec, but were
>>> widely deemed useful/necessary. I've tried to sidestep too much
>>> controversy by continuing not to specify them, but I did write down some
>>> of the ways some folk have decided to represent them.
>> OK.  My advice:
>>      If there is a common core of bits over the wire that they all do do, but then some /additional/ bits over the wire that are different, then write the spec for the common parts and note (but do not document) that there are various independent extensions.
>>      Treat any effort to document the variations as completely separate from the common core.
>> d/
>> --
>>   Dave Crocker
>>   Brandenburg InternetWorking
>> _______________________________________________
>> apps-discuss mailing list
> --
> Mark Nottingham
> _______________________________________________
> apps-discuss mailing list