To: firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org In-Reply-To: <Roam.1.1.841992280.3526.brent@caribe> (message from Brent Subject: Re: Proposed NFS URL scheme From: Larry Masinter <email@example.com> Message-Id: <96Sep7.005822pdt."2759"@golden.parc.xerox.com> Date: Sat, 7 Sep 1996 00:58:22 PDT Brent, I didn't read the spec carefully, except for the parts about the NFS scheme, but here are some questions on webnfs.client.nr: > 6.2.1 URL Link > If the link text has the prefix: "nfs://" the client > should interpret the text as an NFS URL. > The client should parse the URL as described in section 7. > Then contact the server named in the URL, and LOOKUP the > <path> in the URL. > Clients that support URL types other than "nfs" should > also be alert for other URL schemes. For instance, if > the symbolic link text contains an "http" URL, then > a Web browser should obtain the data referenced by the URL > with the HTTP protocol. I think that you've confused the HTTP protocol with 'web browser'. Why should a 'web browser' be used for retrieving HTTP URLs but a 'non web browser' be used for retrieving other kinds of data. What kind of software should be used for retrieving 'ftp' URLs? Or 'mailto' URLs? I think the ambiguity between URL links and relative links will bite you, and that it is really poor protocol design. There are lots of proposed URL schemes floating around, and the inconsistency between clients that support some but not others -- and thus assume that they are relative links -- will bite you. Your design for nfs: URLs is inconsistent with RFC 1738, both for ftp: and file: URLs. At least in RFC 1738 as written, we tried to assert that the slash-delimiter as indication of hierarchy was independent of the local file system conventions, e.g., windows systems would continue to use file://host/dir1/dir2/name and a FTP connection to a windows system would use ftp://host/dir1/dir2/name even though the Windows convention might be \\host\dir1\dir2\name. While RFC 1738 gives leeway for new schemes to use whatever conventions they want, it also says: > New schemes should try to follow the same syntactic conventions of > existing schemes, where appropriate. It is likewise recommended > that, where a protocol allows for retrieval by URL, that the client > software have provision for being configured to use specific gateway > locators for indirect access through new naming schemes. I think it would be appropriate in this case, and don't understand the rationale for making the other choice. Since WebNFS is a new protocol, why not give it uniform semantics? I suppose this is an issue only for WebNFS servers for windows machines.