RE: Status of draft-hoffman-rfc1738bis-01.txt

I hope Paul's monitoring this ;-)  This message is a bit of a round-up.

With reference to:
   http://www.ietf.org/internet-drafts/draft-hoffman-rfc1738bis-01.txt

Also previous messages starting with:
   http://lists.w3.org/Archives/Public/uri/2004Feb/0003.html

Lacking someone who's coming forward as a clear authority on these matters, 
here are my preferences:

...

>In particular, I have followed the advice concerning URIs for Windows
>drive+path specifications.

I have seen some software than changes (say) C: to C| within a URI.  That 
seems pointless to me and I prefer to leave the ':' as-is.

...

>I have a small problem with the text.  The example:
>     file://usr/local/bin/
>is confusing.  'usr' should be an authority component, but to users of
>Unix/Linux systems it looks like part of the path.

I think this should read:
     file:///usr/local/bin/

...

Israel Viente wrote:
>About
> >For Windows shares, there is an additional "/" prepended to the name.
> >Thus, the file "example.doc" on the shared directory "department" would
> >have the URL:
>
> >   file:////department/example.doc
>
>Is it a shared directory on the local host?

I think so.

>How would it be in case of shared directory on a remote host?
>file://remote-host//department/example.doc
>???

That's what I would expect.

...

And looking to Israel's comments in:
http://lists.w3.org/Archives/Public/uri/2003Sep/0004.html

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

I agree.  That's pretty much what I've just done in my code.  I don't think 
this is something the file: URI spec should try to tackle normatively.

...

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

I'm not a Mac person, but that looks plausible to me.  I assume the drive 
latter is the first level of a hierarchical storage partitioning *within* a 
given machine?

Again, I don't think this is something the file: URI spec should try to 
tackle normatively, but a non-normative example might help.

...

>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.

But *this document* is about specific schemes, including file:.

>It also should mention that not putting the terminating "/" in case of a
>folder may influence on the result of relative URL resolving.

Ah, yes, I think that would be a handy reminder.

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

Yes.

...

>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.

I don't think I agree with this.  Another way to look at it is that 
Unix-like systems have a more uniform hierarchy than (say) DOS and VMS 
which have a drive designator as the top level of the hierarchy.

Whether a given path is actually meaningful in the context of a given 
authority is always going to be for the authority to determine.  The given 
example above would not be meaningful even on a Unix system that did not 
have a /usr path from the root (and I'm pretty sure it is *possible*, if 
unconventional, to construct such systems).

This spec is primarily about the file: URI specification rather than file 
system architectures, so I think care is needed to not get sidetracked into 
too much detail of this kind.  At most, I think it should be at the level 
of non-normative examples in the text.

...

And to another point I raised:

>Test case:
>   file:///dir/subdir/file
>
>Is it legitimate to rewrite this as:
>   file:/dir/subdir/file
>
>?
>
>More generally, is it legitimate to remove the '//' that introduce an 
>empty authority string?

I think the answer in general should be "no", in consideration of:
   http://www.w3.org/2001/tag/webarch/#lc-uri-chars

Even though for the file: system, they may be defined to reference the same 
file.

(Similarly for removing trailing '#', etc.)

...

That's all I can find for now.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 3 February 2004 12:30:32 UTC