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

Matthew Kerwin <matthew@kerwin.net.au> Fri, 15 April 2016 06:32 UTC

Return-Path: <phluid61@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7012DFB8; Thu, 14 Apr 2016 23:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9MtJWb8a_sS; Thu, 14 Apr 2016 23:32:53 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1529D12DFAB; Thu, 14 Apr 2016 23:32:53 -0700 (PDT)
Received: by mail-ig0-x229.google.com with SMTP id kb1so5629897igb.0; Thu, 14 Apr 2016 23:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.50.27.39 with SMTP id q7mr2928975igg.34.1460701972302; Thu, 14 Apr 2016 23:32:52 -0700 (PDT)
Sender: phluid61@gmail.com
Received: by 10.107.166.78 with HTTP; Thu, 14 Apr 2016 23:32:52 -0700 (PDT)
In-Reply-To: <570E267A.2070801@ninebynine.org>
References: <570D4C99.1030405@dcrocker.net> <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com> <570E267A.2070801@ninebynine.org>
Date: Fri, 15 Apr 2016 16:32:52 +1000
X-Google-Sender-Auth: 1xUeRAFSrRel2eduVUIEIkpa_qI
Message-ID: <CACweHNDry0HaLUqTCRh7tpR6VwgmJnaaa9mLoKqRHV6j8j2AdQ@mail.gmail.com>
From: Matthew Kerwin <matthew@kerwin.net.au>
To: Graham Klyne <gk@ninebynine.org>
Content-Type: multipart/alternative; boundary=047d7b10ce152e94110530802ec6
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/oO3pqH9bIh_z87cygEEyCenGSLY>
Cc: draft-ietf-appsawg-file-scheme@ietf.org, Dave Crocker <dcrocker@bbiw.net>, Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2016 06:32:55 -0000

On 13 April 2016 at 20:59, Graham Klyne <gk@ninebynine.org> 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
https://example.com/foo and https://example.com/foo/ 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
  http://matthew.kerwin.net.au/