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

Dave Crocker <> Thu, 14 April 2016 02:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D4B912E5F8 for <>; Wed, 13 Apr 2016 19:28:43 -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 uckO8H2tsG5e for <>; Wed, 13 Apr 2016 19:28:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8201012E121 for <>; Wed, 13 Apr 2016 19:28:41 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u3E2SdRg007003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 19:28:40 -0700
References: <20160413200825.15190.qmail@ary.lan> <> <>
To: Matthew Kerwin <>, Mark Nottingham <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Wed, 13 Apr 2016 19:28:39 -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: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 13 Apr 2016 19:28:40 -0700 (PDT)
Archived-At: <>
Cc: Dave Crocker <>, 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 02:28:43 -0000

On 4/13/2016 7:11 PM, Matthew Kerwin wrote:
> On 14 April 2016 at 10:02, Mark Nottingham <
> <>>wrote:
> Actually since Dave's review the working copy now says:
> """
> ​This document specifies a syntax that is compatible with most extant
> implementations. It also documents other less common or outdated constructs.
> """

just to lighten things up with a bit of superficial nit-picking about 

> ​That is, the idealism and deprecation are both removed. Essentially

>     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?
> A little, mostly tangential or out of band.
> Is it typical for lots of entities to do a similar thing in different
> ways, and block standardisation by not engaging? It sounds snarky, but
> I'm genuinely asking, since I'm still quite new to this whole open
> standardisation thing and don't know the politics of it.

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.

>     Is there a test suite or other data to validate the decisions made?
> Nope. How would that look? Would a list of URIs and the expected
> outcomes of parsing/dereferencing them (alongside metrics of known
> implementations that pass/fail) be enough?

There has long been a part of the world that seeks to test network 
software with comformance suites, and the like.  The historical 
alternative in the IETF world is interoperability test between real 
implementations, rather than having independent implementations bang 
against an artificial, third-party 'test suite'.

(On the other hand, test suites can be very efficient for aiding basic 



   Dave Crocker
   Brandenburg InternetWorking