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

Graham Klyne <gk@ninebynine.org> Thu, 14 April 2016 10:17 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 EC15712E3A2 for <apps-discuss@ietfa.amsl.com>; Thu, 14 Apr 2016 03:17:48 -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 BcHHlBsM8zQD for <apps-discuss@ietfa.amsl.com>; Thu, 14 Apr 2016 03:17:43 -0700 (PDT)
Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.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 E9BCB12E395 for <apps-discuss@ietf.org>; Thu, 14 Apr 2016 03:17:41 -0700 (PDT)
Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1aqeKy-0000L2-s6; Thu, 14 Apr 2016 11:17:24 +0100
Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <gk@ninebynine.org>) id 1aqeKy-0002Ip-Hs; Thu, 14 Apr 2016 11:17:24 +0100
Message-ID: <570F6E32.5060808@ninebynine.org>
Date: Thu, 14 Apr 2016 11:17:22 +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: Mark Nottingham <mnot@mnot.net>, Dave Crocker <dcrocker@bbiw.net>
References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> <CACweHNCT+yTE7JoFQwrmaz4+WcAni4Xe=NV+KzhMu5w0g6tuRA@mail.gmail.com> <570F0057.3030409@dcrocker.net> <CACweHND_WLDocx0ozhGisCGw7dUeP4bzU3Fx1sxA=tzaZk+iZQ@mail.gmail.com> <570F0928.4020307@dcrocker.net> <694AED88-B641-4FDD-B033-9C038879A062@mnot.net>
In-Reply-To: <694AED88-B641-4FDD-B033-9C038879A062@mnot.net>
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/sy_e_oK3h6EuOfIpogNK55su05k>
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Experimental (was - Re: 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: 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 
locally.

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.

#g
--


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 <dhc2@dcrocker.net> 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
>>   bbiw.net
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>