As per Relevance of the word relative, we have this rfc below:
Network Working Group B.
Request for Comments: 2224 Sun Microsystems, Inc
Category: Informational October 1997
NFS URL
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
A new URL scheme, 'nfs' is defined. It is used to refer to files
directories on NFS servers using the general URL syntax defined
RFC 1738, "Uniform Resource Locators (URL)".
This scheme uses the public filehandle and multi-component
[RFC2054, RFC2055] to access server data with a minimum of
overhead
The NFS protocol provides access to shared filesystems
networks. It is designed to be machine, operating system,
architecture, and transport protocol independent. The
currently exists in two versions: version 2 [RFC1094] and version 3
[RFC1813], both built on ONC RPC [RFC1831] at its associated
Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].
Table of
1. URL Syntax . . . . . . . . . . . . . . . . . . . . . . . 2
2. URL Evaluation . . . . . . . . . . . . . . . . . . . . . 2
3. Server Connection . . . . . . . . . . . . . . . . . . . 2
4. NFS Version . . . . . . . . . . . . . . . . . . . . . . 2
5. Public Filehandle . . . . . . . . . . . . . . . . . . . 3
5.1 NFS Version 2 Public Filehandle . . . . . . . . . . . 3
5.2 NFS Version 3 Public Filehandle . . . . . . . . . . . 3
6. Multi-component Lookup . . . . . . . . . . . . . . . . . 3
6.1 Absolute vs Relative Pathname . . . . . . . . . . . . 4
6.2 Symbolic Links . . . . . . . . . . . . . . . . . . . . 5
7. Mount Protocol . . . . . . . . . . . . . . . . . . . . . 6
8. Bibliography . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . 8
Callaghan Informational [Page 1]
RFC 2224 NFS URL Scheme October 1997
10. BNF for NFS URL Scheme . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
12. Author's Address . . . . . . . . . . . . . . . . . . . . 10
13. Full Copyright Statement . . . . . . . . . . . . . . . . 11
1. URL
An NFS URL is based on the Common Internet Scheme Syntax described
section 3.1 of RFC 1738. It has the general form
nfs://:
The ":" part is optional. If omitted then port 2049
assumed. The is also optional
The is a hierarchical directory path of the
/<directory>/<directory>/<directory>/.../. The
consist only of characters within the US-ASCII character set.
a <directory> or component the character "/" is reserved
must be encoded as described in Section 2.2 of RFC 1738. If
path> is omitted or consists solely of "/", it must default to
path ".".
2. URL
A client must evaluate an NFS URL by a method known as
[RFC2054, RFC2055]. This method provides easy passage
firewalls and proxy servers, as well as using a minimum number
messages. The WebNFS method is defined for NFS versions 2 and 3.
assumes that the server registers on TCP or UDP port 2049
supports the public filehandle and multi-component lookup
as described in the following sections
3. Server
The client must first attempt to create a TCP connection to
using the specified. If : is omitted, then port 2049
will be used. If the server refuses the TCP connection, then
client will use UDP
4. NFS
The client must first attempt to use NFS version 3. If the
returns an RPC PROG_MISMATCH error then the client must assume
NFS version 3 is not supported, and retry the operation with an
version 2 public filehandle
Callaghan Informational [Page 2]
RFC 2224 NFS URL Scheme October 1997
5. Public
NFS filehandles are normally created by the server and used
identify uniquely a particular file or directory on the server.
client does not normally create filehandles or have any knowledge
the contents of a filehandle
The public filehandle is an an exception. It is an NFS
with a reserved value and special semantics that allow an
filehandle to be obtained. A WebNFS client uses the
filehandle as an initial filehandle rather than using the
protocol. Since NFS version 2 and version 3 have
filehandle formats, the public filehandle is defined differently
each
The public filehandle is a zero filehandle. For NFS version 2
is a filehandle with 32 zero octets. A version 3 public
has zero length
5.1 NFS Version 2 Public
A version 2 filehandle is defined in RFC 1094 as an opaque
occupying 32 octets. A version 2 public filehandle has a zero
each octet, i.e. all zeros
1 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 NFS Version 3 Public
A version 3 filehandle is defined in RFC 1813 as a variable
opaque value occupying up to 64 octets. The length of the
is indicated by an integer value contained in a 4 octet value
describes the number of valid octets that follow. A version 3
filehandle has a length of zero
+-+-+-+-+
| 0 |
+-+-+-+-+
6. Multi-component
Normally the NFS LOOKUP request (version 2 or 3) takes a
filehandle along with the name of a directory member, and returns
filehandle of the directory member. If a client needs to evaluate
pathname that contains a sequence of components, then beginning
Callaghan Informational [Page 3]
RFC 2224 NFS URL Scheme October 1997
the directory filehandle of the first component it must issue
series of LOOKUP requests one component at a time. For instance
evaluation of the path "a/b/c" will generate separate
requests for each component of the pathname "a", "b", and "c".
A LOOKUP request that uses the public filehandle can provide
pathname containing multiple components. The server is expected
evaluate the entire pathname and return a filehandle for the
component
For example, rather than evaluate the path "a/b/c" as
LOOKUP FH=0x0 "a" --->
<--- FH=0x
LOOKUP FH=0x1 "b" --->
<--- FH=0x
LOOKUP FH=0x2 "c" --->
<--- FH=0x
Relative to the public filehandle these three
requests can be replaced by a single multi-
lookup
LOOKUP FH=0x0 "a/b/c" --->
<--- FH=0x
Multi-component lookup is supported only for LOOKUP requests
to the public filehandle
The of the NFS URL must be evaluated as a multi-
lookup. This implies that the path components are delimited
slashes and the characters that make up the path must be in
printable US-ASCII character set. Characters not in the "unreserved
set (see BNF description below) may be included in
components but must be escaped
If the is empty or consists solely of "/", the client
send a multi-component lookup for the pathname ".".
6.1 Absolute vs. Relative
A multi-component pathname that begins with a slash character
considered "absolute" and will be evaluated relative to the server'
root. A pathname that does not begin with a slash is "relative"
will be evaluated relative to the directory with which the
filehandle is associated
Callaghan Informational [Page 4]
RFC 2224 NFS URL Scheme October 1997
Note that the initial "/" that introduces the of an
URL must not be passed to the server for multi-component lookup
the pathname is to be evaluated relative to the public
directory. For example, if the public filehandle is associated
the server's directory "/a/b/c" then the URL
nfs://server/d/e/
will be evaluated with a multi-component lookup of the
"d/e/f" relative to the server's directory "/a/b/c"
the URL
nfs://server//a/b/c/d/e/
will locate the same file with an absolute multi-component lookup
the path "/a/b/c/d/e/f" relative to the server's filesystem root
Notice that a double slash is required at the beginning of the path
Not all WebNFS servers can support arbitrary use of absolute paths
Clearly, the server must not return a filehandle if the
identifies a file or directory that is not exported by the server
In addition, some servers will not return a filehandle if the
names a file or directory in an exported filesystem different
the one that is associated with the public filehandle
6.2 Symbolic
The NFS protocol supports symbolic links, which are the
equivalent of a relative URL. If a WebNFS client retrieves
filehandle for a symbolic link (as indicated by the file
attribute) then it should send a READLINK request to the server
retrieve the path comprising the symbolic link
This path should then be combined with the URL which referenced
symbolic link according to the rules described in RFC 1808. If
relative URL in the symbolic link text is to be resolved
then it must contain only ASCII characters and conform to the
described in RFC 1808. Note that this allows a symbolic link
contain an entire URL and it may specify a scheme that is
necessarily an NFS URL
A symbolic link path that begins with a slash will be evaluated as
absolute path relative to the directory associated with the
filehandle which may not be the same as the server's system
directory. If symbolic links with absolute paths are to be
correctly on both client and server then the public filehandle
be associated with the system root directory
Callaghan Informational [Page 5]
RFC 2224 NFS URL Scheme October 1997
For example, if the symbolic link is named by the
nfs://server/a/
then the following examples show how a new URL can
formed from the symbolic link text
c = nfs://server/a/
c/d = nfs://server/a/c/
../c = nfs://server/
/c/d = nfs://server/c/
nfs://server2/a/b = nfs://server2/a/
7. Mount
The NFS URL may have limited use for naming files on servers that
not support the public filehandle and multi-component lookup
If the server returns an NFS3ERR_STALE, NFS3ERR_INVAL,
NFS3ERR_BADHANDLE error in response to the client's use of a
filehandle, then the client should attempt to resolve the
to a filehandle using the MOUNT protocol
Version 1 of the MOUNT protocol is described in Appendix A of
1094 and version 3 in Appendix I of RFC 1813. Version 2 of the
protocol is identical to version 1 except for the addition of
procedure MOUNTPROC_PATHCONF which returns POSIX pathconf
from the server
Note that the pathname sent to the server in the MOUNTPROC_
request is assumed to be a server native path, rather than a slash
separated path described by RFC 1738. Hence, the MOUNT protocol
reasonably be expected to map a to a filehandle only
servers that support slash-separated ASCII native paths. In general
servers that do not support WebNFS access or slash-separated
native paths should not advertise NFS URLs
At this point the client must already have some indication as
which version of the NFS protocol is supported on the server.
the filehandle format differs between NFS versions 2 and 3,
client must select the appropriate version of the MOUNT protocol
MOUNT versions 1 and 2 return only NFS version 2 filehandles,
MOUNT version 3 returns NFS version 3 filehandles
Callaghan Informational [Page 6]
RFC 2224 NFS URL Scheme October 1997
Unlike the NFS service, the MOUNT service is not registered on
well-known port. The client must use the PORTMAP service to
the server's MOUNT port before it can transmit a MOUNTPROC_
request to retrieve the filehandle corresponding to the
path
Client
------ ------
-------------- MOUNT port ? -------------->
<-------------- Port=984 ------------------
------- Filehandle for /export/foo ? ----> Mountd @ port 984
<--------- Filehandle=0xf82455ce0.. ------
NFS servers commonly use a client's successful MOUNTPROC_MNT
request as an indication that the client has "mounted" the
and may maintain this information in a file that lists
filesystems that clients currently have mounted. This information
removed from the file when the client transmits an MOUNTPROC_
request. Upon receiving a successful reply to a MOUNTPROC_
request, a WebNFS client should send a MOUNTPROC_UMNT request
prevent an accumulation of "mounted" records on the server
8.0
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill
"Uniform Resource Locators (URL)," RFC 1738,
December 1994.
[RFC1808] Fielding, R., "Relative Uniform Resource Locators,"
RFC 1808, June 1995.
[RFC1831] Srinivasan, R., "RPC: Remote Procedure
Protocol Specification Version 2," RFC 1831,
August 1995.
[RFC1832] Srinivasan, R., "XDR: External Data
Standard," RFC 1832, August 1995.
[RFC1833] Srinivasan, R., "Binding Protocols for ONC
Version 2," RFC 1833, August 1995.
[RFC1094] Sun Microsystems, Inc., "Network
Specification," RFC 1094, March 1989.
Callaghan Informational [Page 7]
RFC 2224 NFS URL Scheme October 1997
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach
"NFS Version 3 Protocol Specification," RFC 1813,
June 1995.
[RFC2054] Callaghan, B., "WebNFS Client Specification,"
RFC 2054, October 1996.
[RFC2055] Callaghan, B., "WebNFS Server Specification,"
RFC 2055, October 1996.
[Sandberg] Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh
B. Lyon, "Design and Implementation of the
Network Filesystem," USENIX
Proceedings, USENIX Association, Berkeley, CA
Summer 1985. The basic paper describing
SunOS implementation of the NFS version 2
protocol, and discusses the goals,
specification and trade-offs
[X/OpenNFS] X/Open Company, Ltd., X/Open CAE Specification
Protocols for X/Open Internetworking: XNFS
X/Open Company, Ltd., Apex Plaza, Forbury Road
Reading Berkshire, RG1 1AX, United Kingdom
1991. This is an indispensable reference
the NFS and accompanying protocols,
the Lock Manager and the Portmapper
[X/OpenPCNFS] X/Open Company, Ltd., X/Open CAE Specification
Protocols for X/Open Internetworking: (PC)NFS
Developer's Specification, X/Open Company, Ltd.,
Apex Plaza, Forbury Road, Reading Berkshire, RG
1AX, United Kingdom, 1991. This is
indispensable reference for NFS protocol
accompanying protocols, including the Lock
and the Portmapper
9. Security
Since the WebNFS server features are based on NFS protocol versions 2
and 3, the RPC based security considerations described in RFC 1094,
RFC 1831, and RFC 1832 apply here also
Server implementors should be careful when implementing multi
component lookup that the client cannot obtain unauthorized access
files or directories. For example: a path that includes
occurrences of "../" may locate a filesystem outside of the
filesystem associated with the public filehandle
Callaghan Informational [Page 8]
RFC 2224 NFS URL Scheme October 1997
Clients and servers may separately negotiate secure
schemes for authentication, data integrity, and privacy
10. BNF for NFS URL
The syntax of the NFS URL is a subset of the Generic URL
described in RFC 1738. An NFS URL does not include user or
components, nor does it recognize "?" query or "#"
components
nfsURL = "nfs" ":"
relativeURL = net_path | abs_path | rel_
net_path = "//" hostport [ abs_path ]
abs_path = "/" rel_
rel_path = [ path_segments ]
hostport = host [ ":" port ]
host = hostname |
hostname = *( domainlabel "." )
domainlabel = alphanum | alphanum *( alphanum | "-" )
toplabel = alpha | alpha *( alphanum | "-" )
hostnumber = 1*digit "." 1*digit "." 1*digit "." 1*
port = *
url-path = [ "/" ] path_
path_segments = segment *( "/" segment )
segment = *
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
unreserved = alpha | digit |
mark = "$" | "-" | "_" | "." | "!" | "~" |
"*" | "'" | "(" | ")" | ","
escaped = "%" hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f
alphanum = alpha |
alpha = lowalpha |
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
Callaghan Informational [Page 9]
RFC 2224 NFS URL Scheme October 1997
11.
This specification was extensively reviewed by the NFS group
SunSoft and brainstormed by Michael Eisler
12. Author's
Address comments related to this RFC to
brent@eng.sun.
Brent
Sun Microsystems, Inc
Mailstop Mpk17-201,
901 San Antonio Road
Palo Alto, California 94303
Phone: 1-415-786-5067
EMail: brent.callaghan@eng.sun.
Fax: 1-415-786-5896
Callaghan Informational [Page 10]
RFC 2224 NFS URL Scheme October 1997
13. Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implmentation may be prepared, copied,
andand distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Callaghan Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
