# Re: Status of RFC 1738 -- 'ftp' URI scheme

46 messages
123
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 On Thu, 04 Feb 2010 15:53:50 -0000, Alfred HÎnes <[hidden email]> wrote: > Folks, > work already is in progress for an updated specification of > the 'ftp' URI scheme, as one step in the process to let the > obsoleted RFC 1738 actually become gravestone dead. > Upon indication of support for the idea by an AD, I took over > the pen from Paul Hoffman in December -- he was the last one > to start a similar effort several years ago, but did not have > the time to pursue it. Perhaps this is a good time to point out (which I omitted to do earlier)   that the news and nntp schemes have now een published as RFC 5538, so when   this ftp scheme is finished perhaps we can finally put RFC 1738 to bed. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131                           Web: http://www.cs.man.ac.uk/~chlEmail: [hidden email]      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
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 Charles Lindsey scripsit: > Perhaps this is a good time to point out (which I omitted to do earlier)   > that the news and nntp schemes have now een published as RFC 5538, so > when this ftp scheme is finished perhaps we can finally put RFC 1738 to > bed. Has the file scheme become a separate RFC at last? -- A: "Spiro conjectures Ex-Lax."                  John Cowan Q: "What does Pat Nixon frost her cakes with?"  [hidden email]   --"Jeopardy" for generative semanticists      http://www.ccil.org/~cowan
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 On Wed, Dec 29, 2010 at 8:18 AM, John Cowan wrote: Charles Lindsey scripsit: > Perhaps this is a good time to point out (which I omitted to do earlier) > that the news and nntp schemes have now een published as RFC 5538, so > when this ftp scheme is finished perhaps we can finally put RFC 1738 to > bed. Has the file scheme become a separate RFC at last? -- Unfortunately no - IANA URI Schemes registry says RFC 1738 and this I-Dexpired 5 years ago .Warts and all, an RFC for file URI is sorely needed IMHO. Cheers,- Ira
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 In reply to this post by John Cowan-3 On Wed, 29 Dec 2010 13:18:53 -0000, John Cowan <[hidden email]>   wrote: > Charles Lindsey scripsit: > >> Perhaps this is a good time to point out (which I omitted to do earlier) >> that the news and nntp schemes have now een published as RFC 5538, so >> when this ftp scheme is finished perhaps we can finally put RFC 1738 to >> bed. > > Has the file scheme become a separate RFC at last? No, I suppose that needs to be fixed before this matter can finally be   closed. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131                           Web: http://www.cs.man.ac.uk/~chlEmail: [hidden email]      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
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 In reply to this post by Ira McDonald 29.12.2010 19:10, Ira McDonald wrote: On Wed, Dec 29, 2010 at 8:18 AM, John Cowan wrote: Charles Lindsey scripsit: > Perhaps this is a good time to point out (which I omitted to do earlier) > that the news and nntp schemes have now een published as RFC 5538, so > when this ftp scheme is finished perhaps we can finally put RFC 1738 to > bed. Has the file scheme become a separate RFC at last? -- Unfortunately no - IANA URI Schemes registry says RFC 1738 and this I-D expired 5 years ago . Warts and all, an RFC for file URI is sorely needed IMHO. Cheers, - Ira Moreover, I've found the 'afs' URI scheme in RFC 1738 (and in Provisional registry), that (1) needs to be defined or (2) moved to Historic registry. What RFC says is:  The following scheme have been proposed at various times, but this document does not define their syntax or use at this time. It is suggested that IANA reserve their scheme names for future definition: afs Andrew File System global file names. mid Message identifiers for electronic mail. cid Content identifiers for MIME body parts. nfs Network File System (NFS) file names. tn3270 Interactive 3270 emulation sessions. mailserver Access to data available from mail servers. z39.50 Access to ANSI Z39.50 services.  Currently, all of them (except afs, mailserver and tn3270) have been specified or moved to Historic. There is a draft moving 'mailserver' to Historic too (https://datatracker.ietf.org/doc/draft-melnikov-mailserver-uri-to-historic/) and draft specifying tn3270 scheme (https://datatracker.ietf.org/doc/draft-yevstifeyev-tn3270-uri/). And only afs remains indefinite. So I think now it's time to discuss if it should be moved to Historic either. Maybe (2) seems more acceptable for me. Has anyone seen the Andrew File System wide-spread among the Internet? As I know, it was an experimental effort of Carnegie Mellon University and I really do not neither know any public-available resources hat can be accessed by such a scheme nor clients for it. You may find some discussions on this topic on uri-review mailing list in November, as I remeber (while discussion about draft-melnikov-mailserver-uri-to-historic). I would also like to know what is with 'modem' scheme. It is in permanent registry, but has a note of being Historic. What that smth wrong with defining docs and IANA did not have clear definitions of its actions as for this scheme or smth other? As for 'file' scheme, I just wonder why this document (I mean Paul's draft) has not become the RFC like e. g. his docs as for telnet and prospero schemes. Nevertheless, IMO we need to align it with the most current URI defining practices and make it RFC too. Finally, as for 'ftp' one, I am strongly concerned there must be clear definition of this wide-spread scheme - it is really needed. So, taking everything into account, only if we resolve *all* these problems, we can say that RFC 1738 is really obsolete, IMO. Happy New Year to everybody, Mykyta Yevstifeyev
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 Mykyta Yevstifeyev wrote: > As for 'file' scheme, I just wonder why this document (I mean Paul's > draft) has not become the RFC New RFCs tend to be treated as the latest & greatest guidance (or proposals for such) from the IETF, so there was a question of whether it made sense to create a new RFC that reproduces a relatively uselss section of an otherwise obsolete RFC, just for the purpose of retiring the larger document. If the section were fit to publish as-is, it would be OK, but it really needs a lot of work before it will be of much use to a present-day implementer who wants to know how to produce or utilize 'file:' URIs. When I was working on such a project, I was stymied by all kinds of issues, some of which I posted about: http://lists.w3.org/Archives/Public/uri/2004Jul/0013 (Discussion picked up again in May and August 2005; check the archives.) Even if you take the "just document what works, don't fix what's broken" approach, having an RFC that's just a survey of soon-to-be-outdated implementations doesn't seem like the greatest plan. Paul Hoffman washed his hands of the whole thing after being overwhelmed by the comments and disagreement over how prescriptive a new RFC should be. Larry Masinter offered to take it over, then he and I and Graham Klyne discussed using a wiki to manage the initial stages of a new draft. The idea was to let interested parties make edits directly until a reasonable degree of consensus/stability was reached, and then an editor (Larry probably) would take it over and submit a clean version as an Internet-Draft or RFC. The wiki is still up on my server, but no progress was made; Larry and I are the only ones who ever did anything with it, and we both lost interest pretty quickly. 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. Mike
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 On Mon, 03 Jan 2011 04:32:11 -0000, Mike Brown <[hidden email]> 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/~chlEmail: [hidden email]      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
Open this post in threaded view
|

## RE: Status of RFC 1738 -- 'ftp' URI scheme

 In reply to this post by Mykyta Yevstifeyev > From: [hidden email] [mailto:[hidden email]] On Behalf Of Mykyta Yevstifeyev > Sent: Friday, 31 December, 2010 00:17 > To: Ira McDonald > Cc: John Cowan; Charles Lindsey; URI > Currently, all of them (except afs, mailserver and tn3270) have > been specified or moved to Historic. ... So I think now it's time > to discuss if it should be moved to Historic either. > > Maybe (2) seems more acceptable for me. Has anyone seen the Andrew > File System wide-spread among the Internet? As I know, it was an > experimental effort of Carnegie Mellon University and I really do > not neither know any public-available resources hat can be > accessed by such a scheme nor clients for it. AFS is not just an experimental system, and not used just at CMU. It was used at a number of universities and businesses in production, and sold as a product by Transarc (now part of IBM). When I worked at IBM in the late '80s and early '90s we used it, for example. MIT's Project Athena ran a good-sized AFS cell. As far as I know it's still in use; MIT is still hosting pages about it.[1] OpenAFS [2] is available for several platforms, and is active. There were 35 messages on its announce list last year. Some casual searching suggests there are at least a few public AFS resources. I don't know whether there are any clients that support afs-scheme URLs. [1] See for example http://ist.mit.edu/services/web/afs/about. [2] http://openafs.org/-- Michael Wojcik Principal Software Systems Developer, Micro Focus This message has been scanned for viruses by MailController - www.MailController.altohiway.com
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 In reply to this post by Charles Lindsey Charles Lindsey scripsit: > 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. So far so good.  The messy part is what the authority means when it is neither empty nor "localhost", and clients differ widely in this respect. -- And it was said that ever after, if any                 John Cowan man looked in that Stone, unless he had a               [hidden email] great strength of will to turn it to other              http://ccil.org/~cowanpurpose, he saw only two aged hands withering in flame.   --"The Pyre of Denethor"
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 In reply to this post by Michael Wojcik Michael, See my comment below. 03.01.2011 16:02, Michael Wojcik wrote: >> From: [hidden email] [mailto:[hidden email]] On Behalf Of > Mykyta Yevstifeyev >> Sent: Friday, 31 December, 2010 00:17 >> To: Ira McDonald >> Cc: John Cowan; Charles Lindsey; URI >> Currently, all of them (except afs, mailserver and tn3270) have >> been specified or moved to Historic. ... So I think now it's time >> to discuss if it should be moved to Historic either. >> >> Maybe (2) seems more acceptable for me. Has anyone seen the Andrew >> File System wide-spread among the Internet? As I know, it was an >> experimental effort of Carnegie Mellon University and I really do >> not neither know any public-available resources hat can be >> accessed by such a scheme nor clients for it. > AFS is not just an experimental system, and not used just at CMU. It was > used at a number of universities and businesses in production, and sold > as a product by Transarc (now part of IBM). When I worked at IBM in the > late '80s and early '90s we used it, for example. > > MIT's Project Athena ran a good-sized AFS cell. As far as I know it's > still in use; MIT is still hosting pages about it.[1] > > OpenAFS [2] is available for several platforms, and is active. There > were 35 messages on its announce list last year. > > Some casual searching suggests there are at least a few public AFS > resources. > > I don't know whether there are any clients that support afs-scheme URLs. That is the most important. If there is no interest of implementators, do we need such scheme. Moreover, if the scheme is Historic, that does not mean that it is *restricted* to be used. Historic status means that smth. is *not intended* to be used rather that forbidden. So there is more sense to move this scheme to historic rather than specify it. Mykyta. > > [1] See for example http://ist.mit.edu/services/web/afs/about. > [2] http://openafs.org/> >
Open this post in threaded view
|

## RE: Status of RFC 1738 -- 'ftp' URI scheme

 > From: Mykyta Yevstifeyev [mailto:[hidden email]] > Sent: Tuesday, 04 January, 2011 01:09 > > 03.01.2011 16:02, Michael Wojcik wrote: > > > > I don't know whether there are any clients that support afs- > > scheme URLs. > > That is the most important. If there is no interest of implementators, > do we need such scheme. Moreover, if the scheme is Historic, that does > not mean that it is *restricted* to be used. Historic status means that > smth. is *not intended* to be used rather that forbidden. So there is > more sense to move this scheme to historic rather than specify it. Agreed. Unless someone can identify a client that uses afs-scheme URLs, relegating it to Historic status appears to be appropriate. -- Michael Wojcik Principal Software Systems Developer, Micro Focus This message has been scanned for viruses by MailController - www.MailController.altohiway.com
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 In reply to this post by John Cowan-3 On Mon, 03 Jan 2011 14:38:05 -0000, John Cowan <[hidden email]>   wrote: > Charles Lindsey scripsit: > >> 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. > > So far so good.  The messy part is what the authority means when it is > neither empty nor "localhost", and clients differ widely in this respect. > If the authority identifies a host (e.g. e domain name with a A record, or   some local name known from /etc/hosts) then the question is whether the   open command in that host understands "blah-blah-blah". I think any   standard should forbid anything other than such domain/host names.   Anything else would be rgearded as a 'local convention' outwith the   standard - and good luck to you if it happens to work in your environment. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131                           Web: http://www.cs.man.ac.uk/~chlEmail: [hidden email]      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
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 Charles Lindsey scripsit: > If the authority identifies a host (e.g. e domain name with a A record, > or some local name known from /etc/hosts) Well, Internet Explorer interprets file://foo/bar/baz as the UNC name \\foo\bar\baz, which strikes me as extremely sensible, and I wish every browser on Windows did it.   (Chrome does, Firefox doesn't.)  Technically "foo" is not a hostname but the published name of an externally exposed portion of a file tree. > then the question is whether the open command in that host understands > "blah-blah-blah". No doubt, but how does one find out?  Lynx uses anonymous FTP if the hostname is not empty or "localhost"; is that conformant, given that anonymous FTP typically has its own root? -- John Cowan  [hidden email]  http://ccil.org/~cowanThe penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street.
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 On Thu, 06 Jan 2011 16:36:23 -0000, John Cowan <[hidden email]>   wrote: > Charles Lindsey scripsit: > >> If the authority identifies a host (e.g. e domain name with a A record, >> or some local name known from /etc/hosts) > > Well, Internet Explorer interprets file://foo/bar/baz as the UNC name > \\foo\bar\baz, which strikes me as extremely sensible, and I wish every > browser on Windows did it.   (Chrome does, Firefox doesn't.)  Technically > "foo" is not a hostname but the published name of an externally exposed > portion of a file tree. That looks like a typical microsoft non-standard invention. It is   certainly not in the spirit of the main URI standard, and it was not the   intention of RFC 1738. And how do you indicate that 'foo' really IS a host   name, as intended by 1738? It seems like an aberration we should not give   any official support to. > >> then the question is whether the open command in that host understands >> "blah-blah-blah". > > No doubt, but how does one find out?  Lynx uses anonymous FTP if the > hostname is not empty or "localhost"; is that conformant, given that > anonymous FTP typically has its own root? Well the file scheme is not supposed to be an alternative to the ftp   scheme. Given that 1738 was written with local networks in mind rather   than the global internet, then I think file:/host/filename... should   normally be seen as an invitation to mount that file from that host using   NFS. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131                           Web: http://www.cs.man.ac.uk/~chlEmail: [hidden email]      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
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 Charles Lindsey scripsit: >> Well, Internet Explorer interprets file://foo/bar/baz as the UNC name >> \\foo\bar\baz, which strikes me as extremely sensible, and I wish every >> browser on Windows did it.   (Chrome does, Firefox doesn't.)  Technically >> "foo" is not a hostname but the published name of an externally exposed >> portion of a file tree. > > That looks like a typical microsoft non-standard invention. It is   > certainly not in the spirit of the main URI standard, and it was not the   > intention of RFC 1738. And how do you indicate that 'foo' really IS a > host name, as intended by 1738? It seems like an aberration we should not > give any official support to. It seems to me to fit perfectly with the notion of a "reg-name" in RFC 3986 Section 3.2.2.  Relevant snippets: "In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host. We use the name 'host' for the ABNF rule because that is its most common purpose, not its only purpose." "A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead." Since the whole "file" scheme is OS-specific anyway, I see no problem with saying that the specific registry for the "file" scheme on Windows hosts is WINS first and then DNS, since WINS client support is universally available on Windows and NFS (or AFS or whatever) is quite rare. In addition, the normal pattern for distributed file systems other than SMB is to mount remote hosts in the local file system, not to reference arbitrary hosts by their DNS names.  (There is already a separate scheme for CIFS, the successor to SMB, where arbitrary references are more common.) -- John Cowan    http://ccil.org/~cowan  [hidden email] The Penguin shall hunt and devour all that is crufty, gnarly and bogacious; all code which wriggles like spaghetti, or is infested with blighting creatures, or is bound by grave and perilous Licences shall it capture.  And in capturing shall it replicate, and in replicating shall it document, and in documentation shall it bring freedom, serenity and most cool froodiness to the earth and all who code therein.  --Gospel of Tux
Open this post in threaded view
|

## RE: Status of RFC 1738 -- 'ftp' URI scheme

 In reply to this post by Charles Lindsey > From: [hidden email] [mailto:[hidden email]] On Behalf Of > Charles Lindsey > Sent: Friday, 07 January, 2011 08:48 > > On Thu, 06 Jan 2011 16:36:23 -0000, John Cowan <[hidden email]> > wrote: > > > Charles Lindsey scripsit: > > > >> If the authority identifies a host (e.g. e domain name with a A > >> record, or some local name known from /etc/hosts) > > > > Well, Internet Explorer interprets file://foo/bar/baz as the UNC name > > \\foo\bar\baz, which strikes me as extremely sensible It strikes me as a lousy idea, so there's another data point. > That looks like a typical microsoft non-standard invention. It is > certainly not in the spirit of the main URI standard, and it was not > the intention of RFC 1738. And a security risk, since it trivially lets malicious sites probe SMB connections using a combination of and other auto-loaded resources and scripting. > Well the file scheme is not supposed to be an alternative to the ftp > scheme. Given that 1738 was written with local networks in mind rather > than the global internet, then I think file:/host/filename... should > normally be seen as an invitation to mount that file from that host > using NFS. I don't think the file scheme should try to do anything at all, beyond attempting to open the named resource using the normal OS mechanism for opening a file. If the OS decides to retrieve a network resource based on that request, fine; but it shouldn't be an explicit feature of the file scheme. If people want URIs that refer to SMB-hosted resources, let them write a new I-D for the "smb" scheme and push it through the RFC process. There are existing implementations.[1] On another point, I'd substitute "normal OS mechanism for opening a file" for Charles' reference to "POSIX" upthread. There are non-POSIX OSes in use, and non-POSIX filesystems even on OSes that also support POSIX. On IBM's OS/400 aka iSeries aka System i aka whatever they're calling it today, for example, people ought to be able to use file-scheme URIs both for resources in the POSIX-compatible Hierarchical File System, and for the non-hierarchical Integrated File System. (There's still a reasonable, though constrained, interpretation for the abs_path portion of a file-scheme URI under IFS.) [1] See . Apparently there was an I-D for the smb scheme at one point. -- Michael Wojcik Principal Software Systems Developer, Micro Focus This message has been scanned for viruses by MailController - www.MailController.altohiway.com
Open this post in threaded view
|

## Re: Status of RFC 1738 -- 'ftp' URI scheme

 Michael Wojcik scripsit: > I don't think the file scheme should try to do anything at all, beyond > attempting to open the named resource using the normal OS mechanism for > opening a file. But that's precisely my point: UNC names *are* obtained by opening the named resource using the normal OS mechanism, given the obvious mapping of / to \ (which is not actually required by the Windows kernel). -- John Cowan              http://www.ccil.org/~cowan      [hidden email] "After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?" "No, I wouldn't", the beggar replied.  "Why is that?" the Master asked. "A Dinar doesn't go very far these days, Master.        --Kehlog Albran Besides, the Temple of Toplat is across the street."      The Profit
Open this post in threaded view
|

## RE: Status of RFC 1738 -- 'ftp' URI scheme

 > From: John Cowan [mailto:[hidden email]] On Behalf Of John Cowan > Sent: Friday, 07 January, 2011 10:16 > > Michael Wojcik scripsit: > > > I don't think the file scheme should try to do anything at all, > beyond > > attempting to open the named resource using the normal OS mechanism > > for opening a file. > > But that's precisely my point: UNC names *are* obtained by opening the > named resource using the normal OS mechanism, given the obvious mapping > of / to \ (which is not actually required by the Windows kernel). Hmm. Yes. Good point. That's what I get for posting while distracted. However, it's only true if the authority portion of the file-scheme URI is passed to the file-opening mechanism, and it's not clear that is either the original intent or the desirable behavior of the file scheme. Certainly *I* would prefer that file-scheme handlers on Windows do something like the following: - Convert the authority and path to canonical form if necessary - Verify that the authority portion is empty or a reference to the local host - Pass the path portion to the standard OS file-opening mechanism (CreateFile), requesting read access to the data I explicitly don't want them to treat a file-scheme URI as a UNC name. But obviously some users (possibly the majority) *would* want a file-scheme URI treated as a UNC name. And while I might argue that the principle of least surprise, the principle of least privilege, and a bias toward security all argue against that, those are arguments that historically have not had a lot of traction among casual users or implementors of the software they use. I suppose what I'm saying, then, is that I don't believe it's clear that the UNC-mapping behavior is necessarily desirable, and more discussion on the topic might be called for, if we're trying to standardize the file scheme. -- Michael Wojcik Principal Software Systems Developer, Micro Focus This message has been scanned for viruses by MailController - www.MailController.altohiway.com