Re: File URIs, home and relative paths

Hi,

I'll reply to the part I can talk to.

On 10/06/2016 2:38 PM, "Jason Dusek" <jason.dusek@gmail.com> wrote:
>
> In the draft RFC, some allowance is made for UNC paths, which result in
runs of slashes like this file://///... UNC provides a notion of a share
and perhaps we could treat home, dot and dot dot as shares?
Using file://..././/.., file://.../~//..., &c.
>

I don't see how to make this work. The concept of a 'share' is unique to
MS-DTYP. All we have in a file URI is a path.

And, again, one has to take care with names like '.' and '..' since those
are destroyed by any RFC 3986-compliant general purpose URL library.

> Another possibility is to make use of a reserved character, the @, as a
mysterium bonum. We imagine a virtual directory at file:///@ wherein:
>
> file:///@/. is a link to the present directory as defined by the end
user’s context,
> file:///@/.. is the directory above this directory,
> file:///@/~ is the end user’s home directory.
>
> To access a file or directory @ at the system root, one can
use file:///%40. Is this something that a conforming implementation could
provide under the present draft?
>

That's syntactically legal. I also think there's nothing in the current
draft that forbids it, because I realise on a fresh reading that the part
of the draft that used to explain how the 'path' of a URI relates to the
local file system has vanished. I'm going to have to re-add it. It will
describe what everyone currently does and expects: the URI path represents
an absolute file path.

Since '@' is explicitly allowed in the `pchar` rule used in path segments,
I think "/@/..." would not be special-handled by most implementations; so
you're going to have interoperability issues trying to do this.

> Kind Regards,
>   Jason Dusek
>

Cheers,
Matty