Proposed NFS URL scheme

Brent Callaghan (
Thu, 5 Sep 1996 23:44:41 -0800 (PDT)

Date: Thu, 5 Sep 1996 23:44:41 -0800 (PDT)
From: Brent Callaghan <>
Subject: Proposed NFS URL scheme
Message-Id: <Roam.1.1.841992280.3526.brent@caribe>

I have submitted drafts of two Informational RFC's to the RFC editor.
They describe a binding protocol for NFS called WebNFS.

Of particular interest to this mailing list is the description
of a URL for NFS (nfs://server/path) in the WebNFS client RFC.

The IESG have requested that I forward notice of this proposed
scheme to this alias so that it may receive appropriate review
and comment.

The drafts are available via the following URL's:

Each is encoded in nroff RFC format per rfc1543 and have sizes:
  886 lines - 18 pages
  436 lines - 9 pages

As well, I have attached some questions from Harald Alvestrand along
with my responses.

I look forward to your comments.  Please mail me directly
since I am not on this alias.


----- Begin Included Message -----

>From: Brent Callaghan <brent@caribe>
Reply-To: Brent Callaghan <brent@caribe>
Subject: Re: About the nfs: URL....

Hello Harald,

Thanks for your questions.  It's clear that you have read
the draft thoroughly :-)  My responses are below:

> - Compatibility between native and fallback modes of operation,
>   in particular between the public-filehandle and MOUNT
>   methods for resolving an URL; what guarantee do we have
>   that they will produce the same result?

It's not required that they product the same result.

For instance, a WebNFS server supports a pathname relative
to the public filehandle, whereas a non-WebNFS server has
no concept of public filehandles.  Basically, it's up
to the server administrator to publish URL that contains
a path that works for that particular server.

There is a special case for Unix servers: if the LOOKUP
path is relative to the public filehandle and has an initial
slash "/", then it will be relative to the root and independent
of the directory with which the public filehandle is associated.
In this case we do guarantee that the URL:  nfs://server//path
will work identically whether the public-filehandle or the
MOUNT protocol are used to evaluate the path.

> - Scheme robustness with directory separator. The scheme
>   says that / cannot be assumed to be the separator character,
>   yet specifies a fallback to a multistep lookup process where
>   it seems to me that the client is required to guess at separators.

No, the fallback is to use the MOUNT protocol to evaluate 
the path in its entirety.  The client is not required to
perform individual lookups for pathname components.

There is some text in the final paragraph of the client RFC
in Section 9. "Mount Protocol" that suggests the use of
a pathname prefix cache, but as well as an assumption of
pathname syntax it also points out the danger of inadvertent
mountpoint crossing.

Note: Sections 6.1 and 6.2 do refer to features of Unix pathnames.
In Sect 6.1 "Absolute vs. Relative Pathnames" is an explanation
of the features of these pathnames to Unix servers, but it is
not required that the client parse the name - this is only
of interest to suppliers of URLs from Unix servers.
In Sect 6.2 "Symbolic Links" the client is required to
understand the Unix pathname syntax to replace the final
component of the URL with the symbolic link text as if the
link text were a relative URL per RFC 1808, however
this knowledge is required only for servers that support
symbolic links (only Unix servers as far as we know).

> - Relative URL compatibility. Is there an acceptable method to
>   resolve, for instance, a relative URL called "foo.html"
>   within a HTML document that was fetched from an nfs: URL?
>   What about "../foo.html" or "/etc/passwd"?

Relative URL's can be resolved successfully only against
servers that publish and support hierarchical, slash-
separated pathnames as described in Sect 2.2 of RFC 1808.
So relative URL's can be resolved against Unix servers,
but are not guaranteed to work against servers that do not
support a hierarchical, slash-separated, base URL.

> - Internationalization. Is there a single uniform way to
>   represent NFS filenames that have non-ASCII characters
>   in them, including Shift-JIS and UTF-8 based servers?

NFS filenames are XDR strings as described in RFC 1831.
In this RFC they are described as ASCII strings though
in practice they are encoded as null-terminated octet
strings, so there's no practical reason why clients and
servers cannot pass filenames in any 8-bit encoding like
ISO-8859-1 or UTF-8 as long both client and server agree
out-of-band on the encoding, since the protocol itself
does not carry encoding information.

> - Security. URLs have a nasty habit of escaping reasonable scopes.
>   Is the intent of the document that a client which has no
>   authorization for the server host use the "uid=65535" method,
>   and should this be documented?

Yes, it's the server's responsibility to ensure that a
URL references only exported filesystems and that access
is controlled by whatever method the server chooses.

In the "Security Considerations" section both RFCs defer to the
schemes described in the NFS RFC's 1094 and 1813 and indirectly to
the RPC RFC 1831.

> I would appreciate it if you would think about pulling the
> nfs: URL scheme out in a separate document for review and
> possible standardization, where these things can be addressed
> without impacting on the rest of the document; the ""
> mailing list would probably be a good list to notify about this doc.

Yes, the description of the NFS URL should standardized and I am
interested in beginning this process.  However, without reference
to the nfs: URL scheme, the WebNFS client Informational RFC would lack
a rationale.  There is a close association between the URL
scheme and it's expression as a binding scheme utilizing the public

I would like to make an alternative suggestion: that we make it
clear that the NFS URL scheme is provisional, that further work
will create a standard and IANA registration with the assistance
and review of those on "".  If you consider that
the provisional URL description is unclear, then of course I'll
provide additional clarifying text with the assistance and review
of those on the URI mailing list. Hopefully this additional review
and will abide by the spirit of the current rules relating to URL


----- End Included Message -----