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

Matthew Kerwin <> Wed, 13 April 2016 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E500E12D7FA; Wed, 13 Apr 2016 14:08:57 -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 iBR9N5ZJJdK3; Wed, 13 Apr 2016 14:08:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFD7D12D59F; Wed, 13 Apr 2016 14:08:55 -0700 (PDT)
Received: by with SMTP id g185so84716330ioa.2; Wed, 13 Apr 2016 14:08:55 -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=c9LOnWzRgZcO2CBnEmTGw4R/XmdH+uKczkp0u85cyog=; b=qaQFQ9AX3dNicYSe7tOOS2k0DyR5nV23Hr330Uiw39L5wiBUmRnTbCdsrzmLRequWl oQXQK5/Z8ujADQjj7n+U3wQLpAptoVAp0QSv1h6vyFt9cNP7aagI9kdmpRArwlilADKq rmqKS9C+F8chJltQG0JdNteUv/4L/P1wGhCscesTlp0gNHFB/fp+sjqACbMRb6+GNpdJ 3IUCwyeNfZt4HrpQgfuQMmN6gwUmrXXGV8OQMVZSibnFfRfHpF5//h9+2lZsyDn8YVRR NLXh4trekPMBlT4vOs0j5uDQGKv7gy6SGyqsx4X6Yh/jKXu8ux68YcwLBf+fIG8TzJoW 9DSA==
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=c9LOnWzRgZcO2CBnEmTGw4R/XmdH+uKczkp0u85cyog=; b=JJXcE08VsYQWk8ivVM4DVuTvidQ7xDMt6czYVdS+4yVa4zaKrdCfRmrEWd6SlXzHCh WXasd4hoxROa4Lso62MppZsmAyrFTsHkpEmd63BPKC7n6SFxnohcMfvb+Uxb29VTexdD 2sXZ66Or6P5ec76qT+V64U/Xx3stHdL4fkrhS7r6jqTCSS3PUFP/BJP9DNiOLRQHhf3E SG+chR02fELRgYf1U25+XICS6YtAFH0MQ/9+6OjBDRGaA/6cvYdxRDQA9h2NcEnX2fJA fnvOfXlBTMkburSC+x2KOnL50VYoHlyQkJ0yRjWTvtvxvA7WoQvKURHu61zWad2/KaaA iw6Q==
X-Gm-Message-State: AOPr4FXDvYEcHnpswL3n5u/yny04rAHUqzNLlsRbJzOKPSTkswCj6IRDFnrsc6r693UXp3lkHZoXZxK7jIrCKA==
MIME-Version: 1.0
X-Received: by with SMTP id 31mr12251198iop.3.1460581734926; Wed, 13 Apr 2016 14:08:54 -0700 (PDT)
Received: by with HTTP; Wed, 13 Apr 2016 14:08:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 14 Apr 2016 07:08:54 +1000
X-Google-Sender-Auth: ucKDMA6tXulthdtaNFaGEBPui2k
Message-ID: <>
From: Matthew Kerwin <>
To: Graham Klyne <>
Content-Type: multipart/alternative; boundary=001a113ee86879cfed0530642f69
Archived-At: <>
Cc:, Dave Crocker <>, 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 21:08:58 -0000

On 13 April 2016 at 20:34, Graham Klyne <> wrote:

> As for other URI specs that don't define a protocol...
>     urn:
>     acct:
>     about:
>     cid:
>     mid:
>     ni:
>     (etc)
> (That's from a very brief look at
Urgh, of course you're right, and I knew about those. In my mind I was
still hung up on the difference between a purely naming scheme (like urn)
and a very dereferenceable one (like mid).

As far as precedent, mid: and cid: are both dereferenceable URLs (that is,
they support an operation like HTTP's GET), but they're really old so don't
have the formalisms we expect in a modern spec. (In fact, they seem to
assume that the fact that they can get 'got' at all is basically implied by
the fact that they're URLs. (I'm sorry for writing that sentence.))

acct: and ni: are nice and modern, but don't define any methods per se
(although they do point to webfinger and/or define a mapping to HTTP URIs).

Given the precedent, and Dave's protocol-vs-format comment, I'm wondering
if it's even appropriate to include methods in the file: spec at all (BCP
35 only says the definition SHOULD include operations.)

  Matthew Kerwin