W3C home > Mailing lists > Public > uri@w3.org > January 2010

Re: Status of RFC 1738

From: Paul Prescod <paul@prescod.net>
Date: Fri, 8 Jan 2010 07:22:58 -0800
Message-ID: <1cb725391001080722s5b817685n8558a1926e7a3ab8@mail.gmail.com>
To: Graham Klyne <GK-lists@ninebynine.org>
Cc: Mike Brown <mike@skew.org>, uri@w3.org
On Fri, Jan 8, 2010 at 3:50 AM, Graham Klyne <GK-lists@ninebynine.org> wrote:
> Mike Brown wrote:
>>
>> I'm not convinced 'file' really needs an RFC at all. The lack of specific,
>> prescriptive guidelines aren't really impeding implementers, and 'file' URI
>> interoperability in browsers isn't something I hear much clamoring for.
>
> That's not my sense.  A lot of web applications, other than browsers, use
> file: URIs as a way of accessing local resources alongside global ones.  In
> my past experience as a developer, a little more consistency in the various
> ways in which file: URIs are constructed and interpreted would be really
> helpful (e.g. handling drive names on Windows systems; exactly what
> constitutes an "authority", etc.).

I agree with both key parts. file:// is used by a lot more than just
browsers. Browsers are actually the least interesting consumers of
those URIs.

If it were more reliable it could become a more general replacement
for "raw file paths" which would in turn mean that URIs are allowed in
many places that only file paths are. (e.g. configuration files) One
could imagine a universe in which it is just as easy in standard APIs
to open a URL as to open a file, and to use a file:// URL as to use a
file path. But the current mess (on Windows in particular) does not
allow that.

If one were to take on this problem, you'd probably make a standard
for how to interpret file:/// URLs on Windows and how to interpret
them on posix-like systems, and that would cover the vast majority of
users in the world.

> The trouble is, it's a Hard Problem made complex by the heavy hand of
> history.

I agree. It is true that there is no single constituency who would
care enough to push for vendors to update their handling to be
consistent.

 Paul Prescod
Received on Friday, 8 January 2010 15:23:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:13 UTC