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

[Matthew Kerwin <[e-mail]>]

On 13 April 2016 at 20:59, Graham Klyne <[e-mail]> 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/