Re: file://host/location URLs

[Stephen J. Turnbull]

Daniel Colascione writes:

 > Yes, my proposal violates the RFC. I maintain that nobody deliberately
 > constructs file URLs

Shouldn't you put a period here? ;-)  Seriously, I expect that people
who deliberately write file URIs probably know what an RFC is, and may
even have read the relevant ones.  It's not like an http URI where
any Facebook user has at least seen them.

On the contrary, I had an experimental implementation of an URL
handler that used TRAMP to deal with file URLs, and tested it with
deliberately constructed file URLs.  So "nobody" is wrong.  I've seen
such URLs in the wild, used properly though not in a programmatic
context (in a trust group with access to several hosts, indicating use
with SSH or scp, written on paper napkins and the like).

 > pointing to remote hosts,

I disagree.  To me, it's the obvious RFC-standardized way to write an
ssh/scp/sftp URL[1] for fetching a file from a specific host, where
the user of the URL is expected to be able to access the same file
system on that host as the writer, but without constraining the user
to a possibly inconvenient transport protocol.

If you're saying that users sometimes write file://usr/bin/emacs when
they mean either file:///usr/bin/emacs, file:/usr/bin/emacs, or maybe
file:usr/bin/emacs, too bad for those users.  Even on Windows, with a
leading doubled slash the following element indicates the host
providing a service (ie, a namespace authority in URI-speak).

As for the bug in Emacs (and other programs), what else is new?  Emacs
is buggy.  Fix the bug.

 > and that the behavior that best matches user intent is to always
 > interpret file URIs as local, RFC be damned.

And what are you proposing?  Should file://bogus/foo be interpreted as
file:///bogus/foo or as file:bogus/foo?  Or perhaps as file:///foo?

If you want to know what users think, make file://bogus/foo...  error
at parse time if bogus doesn't resolve to the local host.  They'll
tell you.  But it's a bad idea to guess, and a worse idea to take a
precise syntax and make it fuzzy.  Next users will request that such
fuzziness should be allowed for http and other URLs.  After all, it's
obvious what they meant when they wrote http:/www.gnu.org/, right?

By the way, none of the above means that you shouldn't write a
defuzzer program to guess what possibly broken URIs were intended to
be.  Users who can't or won't learn how to write conforming URIs can
install it themselves, and I see nothing wrong with that.

But Emacs itself should follow the RFC here.  The RFC is not broken.


Footnotes: 
[1]  Yes, I'm aware of the *long*-expired IETF draft, though not why
it expired without being approved for RFC status.  Possibly because of
the overlap with the existing file URI?