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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

Alfred Hönes
Reply | Threaded
Open this post in threaded view
|

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

Charles Lindsey
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/~chl
Email: [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

Reply | Threaded
Open this post in threaded view
|

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

John Cowan-3
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

Reply | Threaded
Open this post in threaded view
|

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

Ira McDonald


On Wed, Dec 29, 2010 at 8:18 AM, 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?

--

Unfortunately no - IANA URI Schemes registry says RFC 1738 and this I-D
expired 5 years ago <draft-hoffman-file-uri-03.txt>.

Warts and all, an RFC for file URI is sorely needed IMHO.

Cheers,
- Ira

Reply | Threaded
Open this post in threaded view
|

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

Charles Lindsey
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/~chl
Email: [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

Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
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 <[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?

--

Unfortunately no - IANA URI Schemes registry says RFC 1738 and this I-D
expired 5 years ago <draft-hoffman-file-uri-03.txt>.

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
Reply | Threaded
Open this post in threaded view
|

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

Mike Brown-3
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

Reply | Threaded
Open this post in threaded view
|

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

Charles Lindsey
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/~chl
Email: [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

Reply | Threaded
Open this post in threaded view
|

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

Michael Wojcik
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

Reply | Threaded
Open this post in threaded view
|

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

John Cowan-3
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/~cowan
purpose, he saw only two aged hands withering
in flame.   --"The Pyre of Denethor"

Reply | Threaded
Open this post in threaded view
|

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

Mykyta Yevstifeyev
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/
>
>


Reply | Threaded
Open this post in threaded view
|

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

Michael Wojcik
> 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

Reply | Threaded
Open this post in threaded view
|

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

Charles Lindsey
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/~chl
Email: [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

Reply | Threaded
Open this post in threaded view
|

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

John Cowan-3
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/~cowan
The 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.

Reply | Threaded
Open this post in threaded view
|

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

Charles Lindsey
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/~chl
Email: [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

Reply | Threaded
Open this post in threaded view
|

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

John Cowan-3
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

Reply | Threaded
Open this post in threaded view
|

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

Michael Wojcik
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 <img> 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 <http://ubiqx.org/cifs/Appendix-D.html>. 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

Reply | Threaded
Open this post in threaded view
|

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

John Cowan-3
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

Reply | Threaded
Open this post in threaded view
|

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

Michael Wojcik
> 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

Reply | Threaded
Open this post in threaded view
|

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

John Cowan-3
Michael Wojcik scripsit:

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

Please do argue, because I don't see how they apply.

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

I think that's what we are doing.

--
John Cowan    [hidden email]    http://ccil.org/~cowan
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....

123