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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCA9E12DDCD for <>; Wed, 13 Apr 2016 19:11:09 -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 UbvrOPzjdFZi for <>; Wed, 13 Apr 2016 19:11:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5390412DDC7 for <>; Wed, 13 Apr 2016 19:11:06 -0700 (PDT)
Received: by with SMTP id g185so90596627ioa.2 for <>; Wed, 13 Apr 2016 19:11:06 -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=X/Nw383dVpTGHP4n7gF6Vqh7f4R9MJBjcnvOIX1q4K8=; b=IKicnF44Dq/tK2jKAFTyhSVxARqhDufq5mrkJzvNsKDialLvqpdrnDoPZOqjA/lQW7 Aaimtepb05HJ+A0wGnVRAUMFMn5FiuuMSx/U7iLRXngZR7uDNot8IgCOJYtxFWIYC2i0 W+K/dIXA3qaFo/igEVFV2HER83fyvzTwOIDRES/YgDiF4gon8bzOPv7AmElmlbB59P8p 7rRdFkW1dN4M/8Gm7yFqF6lxUEpCjeA317a3auokMo/Ryo0ZIJQDA2iO/e1PjOSK4/+D ub1245LiEvxmB0sSjcJrdHZX0LEw3umeD+bOHwtKSflHvGplyZbEwGllbWtUXBflfVIW rhoA==
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=X/Nw383dVpTGHP4n7gF6Vqh7f4R9MJBjcnvOIX1q4K8=; b=TshR8mmniyI5NtR6AMJjU5r0u8Bg0qyNGxOOQ/GFwa+TBspVW303YWQlgHisOqZZRL DTdt452dV49SUbseneScKzqjvlFsheelZXemBlUJ8Tz7dyGSH/HY+xgAHqz5m63CcIf4 70+6rryQAw4vQTGzVX8qo9iC3j/+sfRtCEHXZfQNNDEUxbx9BTBvWzR+3Yf86LpUtANg hNfVywkzgv75GOzEStrzvxUPMP4QSMWKulKtCd3Zic+KXmcY5aSNxL47myNi/8X5iC8t RlANymJb0MznQupPPqn/UrA4zTB5JkT3TY2x1V9lgmLU/Py9BpIVgOcM8hMZFRkCryZJ ZaJw==
X-Gm-Message-State: AOPr4FVYHoFfx4UpR5TEJwQSeajy8B9gncuPwp0FsrRO8ImRvoVG/IjKYXX6AWzO+XQnD219/OKzyzLWlaZ/ng==
MIME-Version: 1.0
X-Received: by with SMTP id 31mr13186423iop.3.1460599865715; Wed, 13 Apr 2016 19:11:05 -0700 (PDT)
Received: by with HTTP; Wed, 13 Apr 2016 19:11:05 -0700 (PDT)
In-Reply-To: <>
References: <20160413200825.15190.qmail@ary.lan> <>
Date: Thu, 14 Apr 2016 12:11:05 +1000
X-Google-Sender-Auth: uDXspI-gHix1UFjG1zBf-pb-WlY
Message-ID: <>
From: Matthew Kerwin <>
To: Mark Nottingham <>
Content-Type: multipart/alternative; boundary=001a113ee86827b163053068688b
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:11:10 -0000

On 14 April 2016 at 10:02, Mark Nottingham <> wrote:

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

​That is, the idealism and deprecation are both removed. Essentially it's
an update of the syntax from RFC 1738 to fit better with 3986, and some
information regarding unspecified edge cases and implementation-specific

As I mentioned in my reply to Dave's review, I want to work out how to
clarify the intention and structure of the document; I think this helps
inform that.

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.

If it's my fault for not appropriately seeking that engagement, I'll
happily go seeking it (even if it's too late for this draft.)

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?

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.
Since everyone "does" file URIs, but they all do it differently, and the
spec that defines it is ancient, underspecified, and officially obsolete,
would you suggest instead I write an informational RFC describing the
situation and what everyone is doing right now? Because I really don't want
to walk away and leave the situation the way it currently is.

  Matthew Kerwin