Re: windows example not so weird [was: Re: Fwd: I-D ACTION:draft-hoffman-rfc1738bis-00.txt]

I agree with Al's comment.

Some more comments :

1. What's the syntax for translating UNC paths ?
\\hostname\share\file.pdf -->
file://hostname/share/file.pdf

2. What about Macintosh drives ? They don't have ":" as a drive letter
separator.
So should it look like file:///MacHD1/folder/file.pdf ?

3. Directories:
<quote cite=
"ftp://ftp.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-00.txt">

Some systems allow URLs to point to directories. In this case, there
is usually (but not always) a terminating "/" character, such as
in:

   file://usr/local/bin/

</quote>

I think this comment's place is not only for the file scheme.
It also should mention that not putting the terminating "/" in case of a
folder may influence on the result of relative URL resolving.

The example should be file:///usr/local/bin/ (3 slashes), unless you mean
the usr is the hostname.

4. OS with a single root drive
There is a difference between OS that has a single root drive and OS that
doesn't have it.

For example file:///usr/local/bin/ has a well defined meaning in Unix OS but
it is not defined in Windows or Mac, since there is no root drive in these
OS.
Maybe we can suggest that the System disk / drive will be regarded as the
root drive for Windows or Mac.

Israel




----- Original Message -----
From: "Al Gilman" <asgilman@iamdigex.net>
To: "Paul Hoffman / VPNC (by way of Martin Duerst <duerst@w3.org>)"
<paul.hoffman@vpnc.org>; <uri@w3.org>
Sent: Tuesday, September 02, 2003 11:29 PM
Subject: windows example not so weird [was: Re: Fwd: I-D
ACTION:draft-hoffman-rfc1738bis-00.txt]


>
>
> <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 Wednesday, 3 September 2003 05:32:06 UTC