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

Mark Nottingham <> Thu, 14 April 2016 00:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D06A12E407 for <>; Wed, 13 Apr 2016 17:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XYAqTUK_6fIp for <>; Wed, 13 Apr 2016 17:02:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD77A12E3AF for <>; Wed, 13 Apr 2016 17:02:31 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A01C722E25B; Wed, 13 Apr 2016 20:02:27 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <>
In-Reply-To: <20160413200825.15190.qmail@ary.lan>
Date: Thu, 14 Apr 2016 10:02:24 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20160413200825.15190.qmail@ary.lan>
To: General discussion of application-layer protocols <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: Dave Crocker <>
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 00:02:34 -0000

The draft states:

This document defines a syntax that is compatible with most extant implementations, while attempting to push towards a stricter subset of "ideal" constructs.  In many cases it simultaneously acknowledges and deprecates some less common or outdated constructs.

I'm concerned about how well this draft aligns with current and future behaviour of common clients (especially, but not exclusively, Web browsers), especially since it's making decisions about deprecation and subsetting.

Have we had any input or statements of support from those communities?

Is there a test suite or other data to validate the decisions made?

Absent those things, I question whether it should be published at all. Experimental doesn't seem like the correct path, because the experiment would effectively be to "see if this sticks." It's one thing to define a new protocol extension with the hope that it will get traction in time; it's another to do hope-based definition of existing protocol constructs.


> On 14 Apr 2016, at 6:08 AM, John Levine <> wrote:
>> So the idea behind Experimental -- and I see this as especially strong 
>> /because/ there already is very wide use of the file: construct -- is to 
>> publish the draft and see whether the community adopts use of it, to 
>> cover that existing practise.
> I coulda sworn that's what Proposed Standard means.
> R's,
> John
> PS: More concretely, what's the timeline for the experiment and how
> will we tell what the results are?
> _______________________________________________
> apps-discuss mailing list

Mark Nottingham