- From: Al Gilman <asgilman@iamdigex.net>
- Date: Tue, 02 Sep 2003 17:29:56 -0400
- To: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>(by way of Martin Duerst <duerst@w3.org>), uri@w3.org
<quote cite=
" ftp://ftp.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-00.txt">
Because different operating systems specify the location of files in
directories differently, the file URL scheme is very system-dependent.
For example, on systems running some versions of Microsoft Windows, a
drive specification is used instead of a host, and the drive is preceded
by an extra "/" character. Thus, for a file called "windows.ini" in the
"windows" directory on the "c:" drive, the URL would be:
file:///c:/windows/example.ini
</quote>
This paragraph paints this behavior in too peculiar a light. The "c:" in
this URI is *not* syntactically a replacement for the <host>. It is the
top of the file-path. The host in this URI is the sameOldSameOld default
host of 'localhost.'
It is a characteristic of this OS that the file path always starts with a
drive letter. But in the URI syntax this is just an OS-peculiar convention
on top-level directory names, not requiring any special support in the scheme.
Once we have established the 'localhost' convention and the empty-string
alias for this pseudohost, the DOS usage above is fully conforming already;
needs no additional special casing.
<quote
cite=ibid>
As a special case, <host> can be the string "localhost" or the empty
string; this is interpreted as `the machine from which the URL is
being interpreted'.
</quote>
The transform from
.. in DOS syntax
c:\windows\example.ini
to
.. in URI syntax
file:///c:/windows/example.ini
is much closer and more direct than the above quote would make it sound.
The paragraph could go away and the example move to a collection of examples.
[all IIRC...]
Al
Received on Tuesday, 2 September 2003 17:35:02 UTC