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

Dave Crocker <dhc2@dcrocker.net> Wed, 13 April 2016 14:18 UTC

Return-Path: <dhc2@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D019212D6D9; Wed, 13 Apr 2016 07:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8_PVvVJZHg6X; Wed, 13 Apr 2016 07:18:49 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30C412D126; Wed, 13 Apr 2016 07:18:49 -0700 (PDT)
Received: from [] (76-218-8-128.lightspeed.sntcca.sbcglobal.net []) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3DEIljr015572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 07:18:48 -0700
References: <570D4C99.1030405@dcrocker.net> <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com> <570E2373.20209@ninebynine.org>
To: Matthew Kerwin <matthew@kerwin.net.au>
From: Dave Crocker <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <570E553E.7090305@dcrocker.net>
Date: Wed, 13 Apr 2016 07:18:38 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <570E2373.20209@ninebynine.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com []); Wed, 13 Apr 2016 07:18:49 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/-YWj_01AhssItMriC1UnifcDInQ>
Cc: Apps Discuss <apps-discuss@ietf.org>, draft-ietf-appsawg-file-scheme@ietf.org
Subject: [apps-discuss] Implementation (was - Re: Review of draft-ietf-appsawg-file-scheme)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
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 14:18:51 -0000

On 4/13/2016 3:46 AM, Graham Klyne wrote:
> On 13/04/2016 09:28, Matthew Kerwin wrote:
>>> >
>>>> >>    o  the use of slashes to denote boundaries between directory
>>>> levels
>>>> >>       of a hierarchical file system; and
>>>> >>
>>>> >>    o  the requirement that client software convert the file URI
>>>> into a
>>>> >>       file name in the local file name conventions.
>>>> >>
>>> >
>>> >*** Hmmm. A requirement like that moves this from being a URI
>>> >specification to being a file protocol specification...
>>> >
>>> >
>> Thank you for saying that, you've triggered a bit of a light-bulb moment
>> for me about why I've had so much trouble getting this draft straight
>> in my
>> head -- maybe it is actually a protocol spec. That said, I'd rather
>> cut it
>> back to be a URI scheme spec. If we need to define the protocol in
>> future,
>> then that's a future issue.
> Yes, I think staying clear of "protocol" is probably best.

One of the challenges in writing Internet technical specifications, is 
to make sure that the focus is on bits over the wire, rather than code 
on a machine.  The former is system-independent.  The latter always 
suffers the risk of being implementation-dependent.

Even the primary use of file: for "local" environments needs this 
distinction, in terms of talking only about abstractions.

The writing style requirements for making this work well have a variety 
of characteristics and common practices.  I think there's no guide for 
this, though.  So it's more clinical art than mechanical science.

One, trivial suggestion that occurs to me is to not use the word 
implementation -- unless specification reviewing implementation history 
or the like -- and instead use the word 'use'.  It's a gimmick, but it 
might help.



   Dave Crocker
   Brandenburg InternetWorking