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

Matthew Kerwin <> Thu, 14 April 2016 02:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EEDD12D924 for <>; Wed, 13 Apr 2016 19:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6AMYobQybUET for <>; Wed, 13 Apr 2016 19:55:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C809912DA2C for <>; Wed, 13 Apr 2016 19:55:07 -0700 (PDT)
Received: by with SMTP id g185so91334357ioa.2 for <>; Wed, 13 Apr 2016 19:55:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=3XkVwCiVWZkv1chM3dqfoFtMdcavqKz23Fm3W7k0Lks=; b=IbZbosrudfSSrd4VTHziwGHwHOPwlpcrCBm93/SMSthhTI8RHy3czqS13ZEdVVf0H7 X+a7rNo+IwDjeNUK1jueSI1khQMhLZxtf4M48nMtZp4Cm098QUxkoVQEgRzjIwzNPSvg UzkwZyTqzsEIKzx5v8WRafANun+StBAWLyKUFVvdV8oX+vOHeMsItEfS+akbWQAlCHOs nnyNcnjGqPwnlHg3mQX8oCXWFZq5/8ONjcjLe3gqWxif6EOt8EyOyy5eVyWmkjcfIco+ biDHa6DiHFV6QnfwZ33n9EptEs6arlu4BkDkOBngPjzfMSD+BNvdbOonsjzbxDzqnt3A MpPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3XkVwCiVWZkv1chM3dqfoFtMdcavqKz23Fm3W7k0Lks=; b=XGlLd4JSnXCkSsW8H3ZF4sFZTp2L2V47al8vGOi3DXF7eHk84lrs6/cVQwDM/HBWje TmFaFznPb6V8giZLTobyxa2UQgp/dafFrcxYU++hyOQ07clXORRRWOiQ8wMPMeen3cTi dB9WsrbHNE3rF23SUEQXwsrXhVS82+/PYZUniJGKFXnZsnLqVSPYkQlHLc0TXOYeciWn adZlEvr6Sl+mjuJVNYB6t2gPTvga47emiEgDuxDI7/Sz2XZDV9X3tiQV+WpqHVnZ/3SN 1RmtvwD0HOfB6RmAUYaCWUWbe0fDBvByYv3Z8Q5wLWdHl7WgflX9YEUiIHODmBJG7K4m suKA==
X-Gm-Message-State: AOPr4FXpl+5uanzgITwxP/hWPQBNBnCODHlNKkoeUOKCyqkgKNQyBloNzwbJaeDIm5SDh8pY9PS+jn8qBUZsYw==
MIME-Version: 1.0
X-Received: by with SMTP id 31mr13311213iop.3.1460602507206; Wed, 13 Apr 2016 19:55:07 -0700 (PDT)
Received: by with HTTP; Wed, 13 Apr 2016 19:55:07 -0700 (PDT)
In-Reply-To: <>
References: <20160413200825.15190.qmail@ary.lan> <> <> <>
Date: Thu, 14 Apr 2016 12:55:07 +1000
X-Google-Sender-Auth: VYGKzBRo-CDXd08KT9YpWK4Bjyk
Message-ID: <>
From: Matthew Kerwin <>
To: Dave Crocker <>
Content-Type: multipart/alternative; boundary=001a113ee86899a94f0530690526
Archived-At: <>
Cc: Mark Nottingham <>, 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:55:10 -0000

On 14 April 2016 at 12:28, Dave Crocker <> wrote:

> 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
> wording:
Fair enough. I think I did mean 'extant', but I'm not super invested in the

> ​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.
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.

>     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
> debugging...)
Mostly I just looked at the various browsers and APIs and worked out what
they had in common. It's hard to define an interoperability test for file
URIs, since they really only "interoperate" by being parsed/dereferenced
from shared hypertext documents -- i.e. basically a 'test suite.'

  Matthew Kerwin