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

Matthew Kerwin <> Fri, 15 April 2016 06:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DA7012DFB8; Thu, 14 Apr 2016 23:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Status: No, score=-1.449 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, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V9MtJWb8a_sS; Thu, 14 Apr 2016 23:32:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1529D12DFAB; Thu, 14 Apr 2016 23:32:53 -0700 (PDT)
Received: by with SMTP id kb1so5629897igb.0; Thu, 14 Apr 2016 23:32:53 -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=qna0XoOS73oABzfY7/F/ZplcbBBWXNfz3q24T0YEsu0=; b=UoG7sPhlfU96subdLZ6qQbmZnGWUhUmps3wHgiHt42rEuUcGoEv9h26P/gC9fYkAXw y+l0krdLNLbkfxedBzuXND7wVFDjooHsw5BPjaBx4tobOAItDczvo4aGJv9gy8yaSfvi i+nHZYG5mZGn97wGJi9DeYi6rwR+z9ZLLuXhssWw9Ty9ryac5mJmGUpZYJxSpuBXAttX vOSXEj1s3CdVCs4yN1gurwyxPGNNI9cdWqo+ULvKZGi7cS7PunBNGkRhuq8EJNc+3vDf tl2Y76yDgE2rdylLYqGUHQzZn0EiOLzb1NV2/u4BM6xnrl/kdV2zKL6RyTPXs+NLL5vc UZhQ==
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=qna0XoOS73oABzfY7/F/ZplcbBBWXNfz3q24T0YEsu0=; b=FpseiaNsY7tRWdO2Y9nbtcSj/8Ac/gyAsNHMNL+EX/e61UGd8m2WF/V8Rs1f4GMBNP pLva79Po89QE/cNUVd6osGy7t/arr5RlA0MrI4qTw60SQJAKiFy9Yf0aML6We6u4Dth8 uIECecwOdrasIptF9KOvyUTLEUH5A36pF88LjNkucyXaKB1MIaZd6nwHJKA5AHIovpVD znphi4bT/q81kFGw7dn/tL+REny4aBuzQ1s+5NtI0XZZsNWTvpwJW0mP7vCDRVcPZ8QY zcjHx4DdgRcKc3OWmyJTypysZprv59dRB9Rtofl8viraD1vfZNC8Z1LDt0jpCf45Sna4 2wBw==
X-Gm-Message-State: AOPr4FURi9k+dATnvbtLDwuWhvlf9rSBLAliIf2M4jIF15OdtNt5Yx8u4TdJy8QYkeWBR6cldqpcriwvzIMaiw==
MIME-Version: 1.0
X-Received: by with SMTP id q7mr2928975igg.34.1460701972302; Thu, 14 Apr 2016 23:32:52 -0700 (PDT)
Received: by with HTTP; Thu, 14 Apr 2016 23:32:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 15 Apr 2016 16:32:52 +1000
X-Google-Sender-Auth: 1xUeRAFSrRel2eduVUIEIkpa_qI
Message-ID: <>
From: Matthew Kerwin <>
To: Graham Klyne <>
Content-Type: multipart/alternative; boundary=047d7b10ce152e94110530802ec6
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: Fri, 15 Apr 2016 06:32:55 -0000

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

> On 13/04/2016 09:28, Matthew Kerwin wrote:
>>         2.  Append the transformed segment and a delimiting slash
>>>> >>            character "/" to the URI.
>>>> >>
>>>> >>    6.  If the path includes a file name:
>>>> >>
>>>> >>        1.  Transform the file name to a path segment as above.
>>>> >>
>>>> >>        2.  Append the transformed segment to the URI.
>>>> >>
>>> >
>>> >A slash is required at the end of a directory, even if there is no file
>>> >name?
>>> >
>>> >
>> If you're using it as a directory then yes. If you're using it as the
>> ultimate object (the "file") then no. We defined "file" as an "object" in
>> the file system earlier, which (going with the UNIX interpretation that
>> everything is a file) can include directories. As far as I know most
>> non-UNIXy systems around today can deal with this interpretation too.
>> Should I spell it out, or leave it up to interpretation?
> I'd also say "yes".
> This is an area where URI resolution works differently to file path
> resolution (on some systems), so it's not just an academic point.
> If you don't include the trailing "/" on a directory used as a base URI,
> then the final directory segment gets dropped when performing URI
> resolution.
> Developers working in this space will know this anyway, but I think it's
> important.
​That's a good point. In my working copy I've added this as a footnote to
the algorithm:

Some file systems allow directory objects to be treated as files
in some cases.  This can be reflected in a file URI by using the
name of the ultimate directory as the file name (such that the URI does
not have a trailing slash "/").  Be aware that merging a relative URI
reference to such a base URI as per Section 5.2 of [RFC3986] could
remove the directory name from the resulting target URI.

Editorially a footnote might not be the best way to do it, but it gets the
words in there. Does that cover it?

Also, "file:///home/user" and "file:///home/user/" are different URIs per
> RFC3986.  It's usially a good idea to avoid gratuitous URI aliasing, which
> suggests it would be good practice to always include the trailing "/".
It's true that they are different URIs; in the same way and are different URIs. In
that case it's the webserver itself that redirects a request for the former
to the latter. I don't know if we really need to say anything more about it
here, especially since we've pointed out an actual functional difference.

  Matthew Kerwin