- From: Charles Lindsey <chl@clerew.man.ac.uk>
- Date: Mon, 03 Jan 2011 11:10:46 -0000
- To: URI <uri@w3.org>
On Mon, 03 Jan 2011 04:32:11 -0000, Mike Brown <mike@skew.org> wrote:
> http://offset.skew.org/wiki/URI/File_scheme/Plan_of_action
> http://offset.skew.org/wiki/URI/File_scheme
>
> 'file' URIs being tied to OSes as they are (not so much a question of
> interopability on the Internet), I'm not convinced there are enough
> people
> interested in the problem or who are having trouble with implementations
> to
> really justify a project to update the 'file:' URI spec.
>
> I think it makes more sense to just leave the issue unresolved (pardon
> the
> pun). That means either leaving RFC 1738 alive, or just retiring the
> 'file:'
> URI spec altogether. That wouldn't preclude picking it up again in the
> future.
Having taken a quick look at those links, I think people were trying to
make it more complicated than needs be. Essentially, a file URI is
supposed to be meaningful within some limited namepsace. Therefore, any
convention which works within that namespace should work within the URI.
If you are not familiar with the namespace in question, then don't use
file URIs.
Put more simply, if you write file://host/blah-blah-blah, then if you
write a POSIX open call open("blah-blah-blah", ...) then it ought to work,
and you define the format of blah-blah-blah so that it is so. All you ahve
to worry about then is where percent-coding is needed, and perhaps whether
some relative URI is possible.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Received on Monday, 3 January 2011 11:11:39 UTC