Re: Proposed NFS URL scheme

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.

Received on Saturday, 7 September 1996 03:58:50 UTC