W3C home > Mailing lists > Public > uri@w3.org > May 2005

Re: Converting filenames to file: URIs

From: Graham Klyne <gk@ninebynine.org>
Date: Sat, 14 May 2005 09:14:12 +0100
Message-Id: <>
To: John Cowan <jcowan@reutershealth.com>
Cc: uri@w3.org

A somewhat rambling email follows... but towards the end I note that ftp: 
scheme spec proposal draft clearly separates file: and ftp:.

At 01:01 14/05/05 -0400, John Cowan wrote:
>For that matter, on Plan 9 what you see under / depends on what your process
>has attached there.  It's not a requirement that "file://localhost/foo" means
>the same thing for everyone even on a single box.

Hmmm... OK.

I *still* think that replacing file: with ftp: is not appropriate in the 
general case.  Maybe I need to come at this with a use-case argument?

The occasions when I have wanted to use file:// URIs fall into two categories:
(a) to use a browser to examine web pages on a local file system
(b) to develop software than can access local and remote resources in a 
uniform way.
(which, now I write them down, I see (a) maybe as a particular case of (b).)

Where the correspondence seems to be particularly important is in 
interpretation of the "current working directory" (or local host equivalent 
concept) as a URI.  Also -- a bit trickier -- in cases where software 
attempts to interpret a given string as either a local filename *or* a URI, 
depending on the syntax used.  (Maybe this latter one isn't a good idea -- 
better to have distinct specification "modes" for filenames and URIs? -- 
but I found I needed to do something like this when implementing external 
entity handling in an XML parser.)

The common strand here seems to be that the file:// URI needs to have a 
globally consistent correspondence with a local user's view of the host 
file system.  That is, the file:/// URI would be interpreted according to 
the implicit context of a local user, and for these purposes would never 
contain an explicit authority element.

Hmmm... I suppose you might argue similarly for ftp:/// URIs (without 
authority element), in which case I can see grounds for conceding the 
"plausibility" you claimed, but I'd need to see that underpinned by 
sufficiently rigorous language in both the file: and ftp: URI specifications.

Looking at http://www.ietf.org/internet-drafts/draft-hoffman-ftp-uri-04.txt:
    Note that the file: and ftp: URIs are not the same, even when the
    target of the ftp: URI is the local host.
which seems to settle the issue
(er, why didn't I look there to begin with ;-).

I can't see anything in the ftp: draft to suggest how ftp:/// should be 
interpreted.  The only hint I see that it is a legal ftp: URI is in the 
broad-brush statement:
    An FTP URL follows the standard syntax described in
    draft-fielding-uri-rfc2396bis [2396bis].
which implicitly, by omission of any contrary qualification, permits ftp:///.


Graham Klyne
For email:
Received on Saturday, 14 May 2005 08:20:07 UTC

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