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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FE0312E4CC; Wed, 13 Apr 2016 03:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yzdxVChmcu-I; Wed, 13 Apr 2016 03:41:35 -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 BA30212E4C6; Wed, 13 Apr 2016 03:41:34 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1aqIEm-0007hH-cd; Wed, 13 Apr 2016 11:41:33 +0100
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aqIEm-00050z-FJ; Wed, 13 Apr 2016 11:41:32 +0100
Message-ID: <>
Date: Wed, 13 Apr 2016 11:41:31 +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:41:36 -0000

On 13/04/2016 09:28, Matthew Kerwin wrote:
> For a specification involving such a potentially and presumably important
>> >capability, I think significant community support should be required...
>> >unless the spec is to be offered as Experimental, which is the most I'm
>> >inclined to recommend at this point...
>> >
>> >
> To be honest, if that's what you think is most suitable and if we can't
> improve it, I don't have a problem with Experimental. We're fighting
> against decades of stagnation and ennui; if an Experimental spec can kick
> some life into it and stir up the muck that's a good start. If something
> resolves out of it, then there's nothing wrong with redoing it "properly"
> in future, with more engagement and recent experience to call on.
> But to reiterate, it's already implemented pretty widely so I don't think
> it can count as an "experimental scheme" -- rather, this would be an
> experiment in restandardising a diverged and stagnant scheme.


file:// URIs are *very* widely used - I don't think it makes sense to call them 
"experimental".  I think it should be standards-track, but if the community 
can't agree then I'd suggest "informational" with permanent registration.

(I don't anticipate any spec needing to normatively reference file: URI 
specifically, as opposed to URIs generically, so I don't see "informational" 
causing any problems.)