- From: Graham Klyne <GK@ninebynine.org>
- Date: Tue, 03 Feb 2004 17:24:43 +0000
- To: "Israel Viente" <israel_viente@il.vio.com>, <uri@w3.org>
- Cc: Paul Hoffman <paul.hoffman@vpnc.org>
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