File URIs, home and relative paths

Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

File URIs, home and relative paths

Jason Dusek

Dear List,

The use of HTTP and other recognized URL schemes for resource identification often overlaps with the use of files. For example, in the specification of Python dependencies.

It is natural to desire to use URLs for all dependencies, even file dependencies; but there are two areas where there are difficulties in principle as well as in practice:

  • In the specification of vendored dependencies

  • In the specification of internally hosted dependencies

The former require a notion of relative paths; the latter, of home directories.

RFC 1736 admonishes us (4.4) that “Locators can be readily distinguished from naming and descriptive identifiers that may occupy the same name space.”. The use of file: instead of file:// for local file URIs would seem to compromise this requirement, since file:... is a valid file path, whereas anything with // in it is not a file path (double slashes being meaningless in paths).

RFC 1736 says (4.2) that “Locators have global scope.” and goes on to say: “The probability of successful access using an Internet locator depends in no way, modulo resource availability, on the geographical or Internet location of the client.” In a similar vain, RFC 3986 says (1.1) that “URIs have a global scope and are interpreted consistently regardless of context, though the result of that interpretation may be in relation to the end-user’s context.”.

It is the first principle that motivates encoding home and dot in file URLs with a ://: that there should be a distinctive way, analogous with other URLs, to specify file resources. The second principle is what guides us in considering (a) whether such URLs are allowable and (b) how they should be understood.

The interpretation of file://server/code/main must be: /code/main on the server server. But in practice one is apt to want: ~/code/main on the server server, due both to shared hosting realities and privilege separation. Every user has a home (on Windows, Linux, Mac, Android, iOS…), so ~ can always be interpreted, although it is clear that “…the result of that interpretation may be in relation to the end-user’s context.”. The interpretation of ~ in the local URL file:///~ is similar to any interpretation for remote servers. The use of local file URLs with ~ allows us to identify and recover configuration (for example). This seems like an easy addition to any follow on of RFC 1738: to adopt ~ to mean home would not impose alien concepts on implementations or conflict with existing URI concepts.

With regards to . and ..: the generic URI syntax describes how . and .. are to be interpreted and offers an algorithm. RFC 3986 goes on to say (5.2) that “Applications may implement relative reference resolution by using some other algorithm, provided that the results match what would be given by this one.” This algorithm results in an interpretation that can not be bent to the purpose of specifying local file references. The URL file:///./a/b must be treated identically to file:///a/b and that is just /a/b/. I am not sure what to do about this one. Even URI templates would take what is formerly succinct and natural — . — and transform it to something both strange to the eye and apt to confuse the shell, Mustache templates, &c.

The principle that “Locators have global scope.” would seem to suggest we should think no more about . and ..; however, vendored dependencies would in practice have a meaningful interpretation globally since they are shipped in the archive. Local directory resolution would seem to be compatible with the spirit of URIs in the same way as localhost (or indeed DNS names in general).

That neither of these use cases — very common in practice — is provided for by the file:// scheme has been a source of amusement and frustration throughout my many years of writing tools for automated deployment and system management. It is my sincere hope that the file URI scheme evolves a mechanism to handle these cases while retaining syntactic uniformity. To implement tools that ignore or extend the specification is, while not unheard of, not really right. It is best to find and stick to a standard if it is at all serviceable.

Kind Regards,

Jason Dusek

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Julian Reschke
On 2016-06-08 01:39, Jason Dusek wrote:
> Dear List,
>
> The use of HTTP and other recognized URL schemes for resource
> identification often overlaps with the use of files. For example, in the
> specification of Python dependencies.
> ...

Time to review
<https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-10>, I guess :-)

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Matthew Kerwin


On 08/06/2016 2:50 PM, "Julian Reschke" <[hidden email]> wrote:
>
> On 2016-06-08 01:39, Jason Dusek wrote:
>>
>> Dear List,
>>
>> The use of HTTP and other recognized URL schemes for resource
>> identification often overlaps with the use of files. For example, in the
>> specification of Python dependencies.
>> ...
>
>
> Time to review <https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-10>, I guess :-)
>
> Best regards, Julian
>

​​
​I'm definitely taking Jason's comments on board, but I can't see anyone implementing this.  In the case of the draft, my goal is updating the scheme to fit with RFC 3986 and documenting the funny things people already do, not inventing new things.

​Here are my thoughts on the proposal:

1. '.' already means something in URIs; you can't redefine it, even for just one scheme, without rewriting RFC 3986 (possibly requiring a time machine.)  Since '.' is an unreserved character we can't even use "%2E" to smuggle it through the remove_dot_segments algorithm.

2. Presumably the proposed '~' and '.' are only special when they're the first path segment*.  How would that interact with relative resolution?  To me, as someone familiar with tilde expansion in bash, I'd expect "~/foo/bar" to be an obvious relative reference, but if it were resolved against a base URL with subdirectories in the path, the tilde would find itself above the root, and thus lose all its special meaning.  We'd have to use "/~/foo/bar" as the relative reference, which is unintuitive and kind of counter to the proposal.

 * otherwise what would "/foo/~/bar" mean?

3. This would break: `mkdir -p /\~/foo ; touch /\~/foo/bar`  ("file:///~/foo/bar" would always resolve to my home directory; "file:///%7E/foo/bar" would too, since '~' is unreserved)

Off-list I suggested Jason use RFC 6570 URI templates, and define variables like {+PWD} or {+HOME} in the context of his application (even though "moustache templates" aren't aesthetically pleasing).  I still think that's probably the best way forward.

Cheers,
Matty

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Jason Dusek
On Wed, 8 Jun 2016 at 04:42 Matthew Kerwin <[hidden email]> wrote:

On 08/06/2016 2:50 PM, "Julian Reschke" <[hidden email]> wrote:
>
> On 2016-06-08 01:39, Jason Dusek wrote:
>>
>> Dear List,
>>
>> The use of HTTP and other recognized URL schemes for resource
>> identification often overlaps with the use of files. For example, in the
>> specification of Python dependencies.
>> ...
>
>
> Time to review <https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-10>, I guess :-)
>
> Best regards, Julian
>

​​
​I'm definitely taking Jason's comments on board, but I can't see anyone implementing this.  In the case of the draft, my goal is updating the scheme to fit with RFC 3986 and documenting the funny things people already do, not inventing new things.

​Here are my thoughts on the proposal:

1. '.' already means something in URIs; you can't redefine it, even for just one scheme, without rewriting RFC 3986 (possibly requiring a time machine.)  Since '.' is an unreserved character we can't even use "%2E" to smuggle it through the remove_dot_segments algorithm.

This is a fair point. I don’t think direct use of . is viable; it has to be by way of some indirection. 

2. Presumably the proposed '~' and '.' are only special when they're the first path segment*.  How would that interact with relative resolution?  To me, as someone familiar with tilde expansion in bash, I'd expect "~/foo/bar" to be an obvious relative reference, but if it were resolved against a base URL with subdirectories in the path, the tilde would find itself above the root, and thus lose all its special meaning.  We'd have to use "/~/foo/bar" as the relative reference, which is unintuitive and kind of counter to the proposal.

 * otherwise what would "/foo/~/bar" mean?

3. This would break: `mkdir -p /\~/foo ; touch /\~/foo/bar`  ("file:///~/foo/bar" would always resolve to my home directory; "file:///%7E/foo/bar" would too, since '~' is unreserved)

Fair points.

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.

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?

Kind Regards,
  Jason Dusek
 

Off-list I suggested Jason use RFC 6570 URI templates, and define variables like {+PWD} or {+HOME} in the context of his application (even though "moustache templates" aren't aesthetically pleasing).  I still think that's probably the best way forward.

Cheers,
Matty

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Matthew Kerwin

Hi,

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

On 10/06/2016 2:38 PM, "Jason Dusek" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Jason Dusek
On Fri, 10 Jun 2016 at 18:08 Matthew Kerwin <[hidden email]> wrote:

Hi,

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

On 10/06/2016 2:38 PM, "Jason Dusek" <[hidden email]> 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.

Well, this clarifies some things. Magic mounts are, I think, within an implementer's rights; and here, percent encoding does provide a way to escape the special interpretation.

It is strange to me that the draft neither provides for home and the present directory semantics, nor clearly speaks to the issue (in a section titled "Special Paths in UNIX and File URLs" or something similar). Perhaps it would inspire future work in this area.

> Kind Regards,
>   Jason Dusek
>

Cheers,
Matty

Kind Regards,
  Jason Dusek 
Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Matthew Kerwin


On 12/06/2016 5:57 AM, "Jason Dusek" <[hidden email]> wrote:
>
> It is strange to me that the draft neither provides for home and the present directory semantics, nor clearly speaks to the issue (in a section titled "Special Paths in UNIX and File URLs" or something similar). Perhaps it would inspire future work in this area.
>
> Kind Regards,
>   Jason Dusek 

In URI space current directory references are achieved using relative references. "./foo/bar" is a valid relative reference, which can be resolved against a base URI that represents $PWD.

User home directory and tilde expansion both, AFAIK, come from the shell, not the file system. I could add a warning that a relative reference that starts with "~/" (or "~username/") won't resolve against a base URI the same way bash would resolve an equivalent path; but since no other URI scheme special handles '~' is anyone going to find this valuable?

Cheers

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Jason Dusek

On Sat, 11 Jun 2016 at 16:23 Matthew Kerwin matthew@... wrote:


On 12/06/2016 5:57 AM, "Jason Dusek" <[hidden email]> wrote:
>
> It is strange to me that the draft neither provides for home and the present directory semantics, nor clearly speaks to the issue (in a section titled "Special Paths in UNIX and File URLs" or something similar). Perhaps it would inspire future work in this area.
>
> Kind Regards,
>   Jason Dusek 

In URI space current directory references are achieved using relative references. "./foo/bar" is a valid relative reference, which can be resolved against a base URI that represents $PWD.

This works out strangely in practice because you can’t write file://<something> to get it.

User home directory and tilde expansion both, AFAIK, come from the shell, not the file system. I could add a warning that a relative reference that starts with "~/" (or "~username/") won't resolve against a base URI the same way bash would resolve an equivalent path; but since no other URI scheme special handles '~' is anyone going to find this valuable?

Well, I have not been collecting statistics over the years — but many a time have I seen confusion and consternation with file URLs. It seems valuable to mention a feature that might be mistakenly expected but is not provided for.

It is worth pointing out that there are variety of “pseudo URL schemes” that have grown up around Git which implicitly rely on resolution relative to . or ~ on a remote server.

Perhaps people will put some thought into an approach as a result.

Cheers

Very Best,

Jason Dusek

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Matthew Kerwin


On 12/06/2016 10:40 AM, "Jason Dusek" <[hidden email]> wrote:
>
> On Sat, 11 Jun 2016 at 16:23 Matthew Kerwin [hidden email] wrote:
>>
>>
>> On 12/06/2016 5:57 AM, "Jason Dusek" <[hidden email]> wrote:
>> >
>> > It is strange to me that the draft neither provides for home and the present directory semantics, nor clearly speaks to the issue (in a section titled "Special Paths in UNIX and File URLs" or something similar). Perhaps it would inspire future work in this area.
>> >
>> > Kind Regards,
>> >   Jason Dusek 
>>
>> In URI space current directory references are achieved using relative references. "./foo/bar" is a valid relative reference, which can be resolved against a base URI that represents $PWD.
>
> This works out strangely in practice because you can’t write file://<something> to get it.
>

Like I said at the very start, I think you're trying to use URLs for something URLs aren't meant for. Relative resolution is strictly hierarchical, always, in all hierarchical URI schemes.

URI templates can be used to achieve your non-hierarchical resolution, using variable substitution.

>>
>> User home directory and tilde expansion both, AFAIK, come from the shell, not the file system. I could add a warning that a relative reference that starts with "~/" (or "~username/") won't resolve against a base URI the same way bash would resolve an equivalent path; but since no other URI scheme special handles '~' is anyone going to find this valuable?
>
> Well, I have not been collecting statistics over the years — but many a time have I seen confusion and consternation with file URLs. It seems valuable to mention a feature that might be mistakenly expected but is not provided for.
>

I've never seen or heard of anyone confused by this issue. Do you think a short warning to that effect would resolve your concern? Or, do you have any text to propose?

>
> It is worth pointing out that there are variety of “pseudo URL schemes” that have grown up around Git which implicitly rely on resolution relative to . or ~ on a remote server.
>
> Perhaps people will put some thought into an approach as a result.
>

Sure, but you're talking about pseudo URL schemes, not misunderstandings of the file: scheme. This is a whole new scope. Why don't you write a new informational draft that addresses it?

Cheers,
Matty

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Jason Dusek

On Sat, 11 Jun 2016 at 18:26 Matthew Kerwin matthew@... wrote:

On 12/06/2016 10:40 AM, "Jason Dusek" <[hidden email]> wrote:
>
> On Sat, 11 Jun 2016 at 16:23 Matthew Kerwin [hidden email] wrote:
>>
>>
>> On 12/06/2016 5:57 AM, "Jason Dusek" <[hidden email]> wrote:
>> >
>> > It is strange to me that the draft neither provides for home and the present directory semantics, nor clearly speaks to the issue (in a section titled "Special Paths in UNIX and File URLs" or something similar). Perhaps it would inspire future work in this area.
>> >
>> > Kind Regards,
>> >   Jason Dusek 
>>
>> In URI space current directory references are achieved using relative references. "./foo/bar" is a valid relative reference, which can be resolved against a base URI that represents $PWD.
>
> This works out strangely in practice because you can’t write file://<something> to get it.
>

Like I said at the very start, I think you're trying to use URLs for something URLs aren't meant for.

That is by no means clear. Their charter is pretty broad. I would hope that ...://... could name everything under the sun.

Relative resolution is strictly hierarchical, always, in all hierarchical URI schemes.

URI templates can be used to achieve your non-hierarchical resolution, using variable substitution.

Could ~ be made part of the RFC? It is an ubiquitous concept. Only at the beginning of a path, sure. What are the objections to that?

>> User home directory and tilde expansion both, AFAIK, come from the shell, not the file system. I could add a warning that a relative reference that starts with "~/" (or "~username/") won't resolve against a base URI the same way bash would resolve an equivalent path; but since no other URI scheme special handles '~' is anyone going to find this valuable?
>
> Well, I have not been collecting statistics over the years — but many a time have I seen confusion and consternation with file URLs. It seems valuable to mention a feature that might be mistakenly expected but is not provided for.

I've never seen or heard of anyone confused by this issue. Do you think a short warning to that effect would resolve your concern? Or, do you have any text to propose?

> It is worth pointing out that there are variety of “pseudo URL schemes” that have grown up around Git which implicitly rely on resolution relative to . or ~ on a remote server.
>
> Perhaps people will put some thought into an approach as a result.

Sure, but you're talking about pseudo URL schemes, not misunderstandings of the file: scheme. This is a whole new scope. Why don't you write a new informational draft that addresses it?

I am happy to write such a draft; but I bring them up here just to point out they face the same issue with respect to home and dot and an accurate treatment of them puts them in disharmony with file://.

Cheers,
Matty

Kind Regards,

Jason Dusek

Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Matthew Kerwin


On 12 June 2016 at 12:47, Jason Dusek <[hidden email]> wrote:

On Sat, 11 Jun 2016 at 18:26 Matthew Kerwin matthew@... wrote:

On 12/06/2016 10:40 AM, "Jason Dusek" <[hidden email]> wrote:
>
> On Sat, 11 Jun 2016 at 16:23 Matthew Kerwin [hidden email] wrote:
>>
>>
>> On 12/06/2016 5:57 AM, "Jason Dusek" <[hidden email]> wrote:
>> >
>> > It is strange to me that the draft neither provides for home and the present directory semantics, nor clearly speaks to the issue (in a section titled "Special Paths in UNIX and File URLs" or something similar). Perhaps it would inspire future work in this area.
>> >
>> > Kind Regards,
>> >   Jason Dusek 
>>
>> In URI space current directory references are achieved using relative references. "./foo/bar" is a valid relative reference, which can be resolved against a base URI that represents $PWD.
>
> This works out strangely in practice because you can’t write file://<something> to get it.
>

Like I said at the very start, I think you're trying to use URLs for something URLs aren't meant for.

That is by no means clear. Their charter is pretty broad. I would hope that ...://... could name everything under the sun.

​It can. Absolutely.  E.g.: "file://115.64.214.208/home/matty/Projects/foo/bar" That doesn't mean it has to be able to name everything *simultaneously*.

Relative resolution is strictly hierarchical, always, in all hierarchical URI schemes.

URI templates can be used to achieve your non-hierarchical resolution, using variable substitution.

Could ~ be made part of the RFC? It is an ubiquitous concept. Only at the beginning of a path, sure. What are the objections to that?

​It could, but the objection is: nobody does it.

The goal isn't to tell people what to do, it's to explain to other people what is already being done. If we were to mandate that "
/~/*
" in a path has to be treated a special way, there'd be pushback from every current vendor. Also: just by writing an RFC, we can't force existing software to update itself; so it wouldn't interoperate with existing deployments.
 

>> User home directory and tilde expansion both, AFAIK, come from the shell, not the file system. I could add a warning that a relative reference that starts with "~/" (or "~username/") won't resolve against a base URI the same way bash would resolve an equivalent path; but since no other URI scheme special handles '~' is anyone going to find this valuable?
>
> Well, I have not been collecting statistics over the years — but many a time have I seen confusion and consternation with file URLs. It seems valuable to mention a feature that might be mistakenly expected but is not provided for.

I've never seen or heard of anyone confused by this issue. Do you think a short warning to that effect would resolve your concern? Or, do you have any text to propose?

> It is worth pointing out that there are variety of “pseudo URL schemes” that have grown up around Git which implicitly rely on resolution relative to . or ~ on a remote server.
>
> Perhaps people will put some thought into an approach as a result.

Sure, but you're talking about pseudo URL schemes, not misunderstandings of the file: scheme. This is a whole new scope. Why don't you write a new informational draft that addresses it?

I am happy to write such a draft; but I bring them up here just to point out they face the same issue with respect to home and dot and an accurate treatment of them puts them in disharmony with file://.

​Of course there'll be disharmony. They've been created because the existing schemes can't do what people want. That's why new things get created. It's not a problem.

Cheers
--
  Matthew Kerwin
  http://matthew.kerwin.net.au/
Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Graham Klyne-2
In reply to this post by Jason Dusek
On 12/06/2016 03:47, Jason Dusek wrote:
>>
>> Like I said at the very start, I think you're trying to use URLs for
>> something URLs aren't meant for.
>>
> That is by no means clear. Their charter is pretty broad. I would hope that
> ...://... could name everything under the sun.
>

Indeed that is the goal of URIs.  It's not *what* they identify that's in
question here, but *how*.

URIs do not, of themselves, allow for relative naming.  That aspect is covered
separately in RFC3986 by "URI references", which are strings that are used in
contexts that allow them to be resolved to full URIs.  Relative references are
necessarily processed without reference to any particular URI scheme, and as
such must be used according to the rules of RFC3986 or interoperability problems
may arise.


> Relative resolution is strictly hierarchical, always, in all hierarchical
>> URI schemes.
>>
>> URI templates can be used to achieve your non-hierarchical resolution,
>> using variable substitution.
>>
> Could ~ be made part of the RFC? It is an ubiquitous concept. Only at the
> beginning of a path, sure. What are the objections to that?
>

Offhand, I see no particular reason why a file system implementation may not
choose to implement `file:///~/my.file` or `file///~fred/freds.file` in the way
you suggest, but I don't see any value in trying to standardize that behaviour.

Behaviour of file: URIs is necessarily dependent on the file system they are
used with, and in my experience there is no general value in passing full file:
URIs between systems.  (This as opposed to relative URI references which can be
resolved against a local file: base URI on the target system.)

Trying to deal with this kind of edge case is something that has delayed
production of a new specification for file: URI scheme specification for many
years, and as such leaving us without a formal specification for common and
uncontroversial uses of file: URIs.  Matthews current proposal is the closest we
have come to resolving this.  So while I'm not implacably opposed to trying to
raise and discuss these issues (notwithstanding my views above), I do oppose
trying to deal with them in the current draft (draft-kerwin-file-scheme) - I
really would like to see that proceed to reinstate file: as a standardized URI
scheme, without getting bogged down in features that have not previously been
specified.

>>> It is worth pointing out that there are variety of “pseudo URL schemes”
>>> that have grown up around Git which implicitly rely on resolution relative
>>> to . or ~ on a remote server.
>>>
>>> Perhaps people will put some thought into an approach as a result.

>> Sure, but you're talking about pseudo URL schemes, not misunderstandings
>> of the file: scheme. This is a whole new scope. Why don't you write a new
>> informational draft that addresses it?
>>
> I am happy to write such a draft; but I bring them up here just to point
> out they face the same issue with respect to home and dot and an accurate
> treatment of them puts them in disharmony with file://.
>

I'm not clear what you refer to here, but if they are in disharmony with file://
URIs it may be because they are in disharmony with URIs (per RFC3986).

#g
--


Reply | Threaded
Open this post in threaded view
|

Re: File URIs, home and relative paths

Graham Klyne-2
In reply to this post by Matthew Kerwin
On 12/06/2016 04:28, Matthew Kerwin wrote:
> Of course there'll be disharmony. They've been created because the
> existing schemes can't do what people want. That's why new things get
> created. It's not a problem.

Or that, of course! (ref. my previous response just posted.

#g
--