Network Working Group B. Callaghan
Request for Comments: 2224 Sun Microsystems, Inc.
Category: Informational October 1997
Network Working Group B. Callaghan
Request for Comments: 2224 Sun Microsystems, Inc.
Category: Informational October 1997
NFS URL Scheme
NFS URL方案
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
Abstract
摘要
A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, "Uniform Resource Locators (URL)".
定义了一个新的URL方案“nfs”。它用于使用RFC 1738“统一资源定位器（URL）”中定义的通用URL语法引用NFS服务器上的文件和目录。
This scheme uses the public filehandle and multi-component lookup [RFC2054, RFC2055] to access server data with a minimum of protocol overhead.
此方案使用公共文件句柄和多组件查找[RFC2054，RFC2055]以最小的协议开销访问服务器数据。
The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3 [RFC1813], both built on ONC RPC [RFC1831] at its associated eXternal Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833].
NFS协议提供对跨网络共享文件系统的访问。它被设计为独立于机器、操作系统、网络体系结构和传输协议。该协议目前有两个版本：版本2[RFC1094]和版本3[RFC1813]，都是在ONC RPC[RFC1831]的相关外部数据表示（XDR）[RFC1832]和绑定协议[RFC1833]上构建的。
Table of Contents
目录
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
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
10. BNF for NFS URL Scheme . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
12. Author's Address . . . . . . . . . . . . . . . . . . . . 10
13. Full Copyright Statement . . . . . . . . . . . . . . . . 11
10. BNF for NFS URL Scheme . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10
12. Author's Address . . . . . . . . . . . . . . . . . . . . 10
13. Full Copyright Statement . . . . . . . . . . . . . . . . 11
An NFS URL is based on the Common Internet Scheme Syntax described in section 3.1 of RFC 1738. It has the general form:
NFS URL基于RFC 1738第3.1节中描述的通用Internet方案语法。其一般形式如下：
nfs://<host>:<port><url-path>
nfs://<host>:<port><url-path>
The ":<port>" part is optional. If omitted then port 2049 is assumed. The <url-path> is also optional.
“：<port>”部分是可选的。如果省略，则假定端口2049。<url路径>也是可选的。
The <url-path> is a hierarchical directory path of the form /<directory>/<directory>/<directory>/.../<name>. The <url-path> must consist only of characters within the US-ASCII character set. Within a <directory> or <name> component the character "/" is reserved and must be encoded as described in Section 2.2 of RFC 1738. If <url-path> is omitted or consists solely of "/", it must default to the path ".".
<url路径>是一个分层目录路径，其形式为/<directory>/<directory>/…/<name>。<url路径>必须仅由US-ASCII字符集中的字符组成。在<directory>或<name>组件中，字符“/”是保留的，必须按照RFC 1738第2.2节所述进行编码。如果省略了<url path>或仅由“/”组成，则它必须默认为路径“”。
A client must evaluate an NFS URL by a method known as WebNFS [RFC2054, RFC2055]. This method provides easy passage through firewalls and proxy servers, as well as using a minimum number of messages. The WebNFS method is defined for NFS versions 2 and 3. It assumes that the server registers on TCP or UDP port 2049 and supports the public filehandle and multi-component lookup semantics as described in the following sections.
客户端必须使用称为WebNFS的方法[RFC2054，RFC2055]来计算NFS URL。此方法提供了通过防火墙和代理服务器的简单通道，并使用了最少数量的消息。WebNFS方法是为NFS版本2和3定义的。它假定服务器在TCP或UDP端口2049上注册，并支持公共文件句柄和多组件查找语义，如以下部分所述。
The client must first attempt to create a TCP connection to <host> using the <port> specified. If :<port> is omitted, then port 2049 will be used. If the server refuses the TCP connection, then the client will use UDP.
客户端必须首先尝试使用指定的<port>创建到<host>的TCP连接。如果省略：<port>，则将使用端口2049。如果服务器拒绝TCP连接，则客户端将使用UDP。
The client must first attempt to use NFS version 3. If the server returns an RPC PROG_MISMATCH error then the client must assume that NFS version 3 is not supported, and retry the operation with an NFS version 2 public filehandle.
客户端必须首先尝试使用NFS版本3。如果服务器返回RPC程序不匹配错误，则客户端必须假定不支持NFS版本3，并使用NFS版本2公共文件句柄重试该操作。
NFS filehandles are normally created by the server and used to identify uniquely a particular file or directory on the server. The client does not normally create filehandles or have any knowledge of the contents of a filehandle.
NFS文件句柄通常由服务器创建，用于唯一标识服务器上的特定文件或目录。客户端通常不创建文件句柄，也不知道文件句柄的内容。
The public filehandle is an an exception. It is an NFS filehandle with a reserved value and special semantics that allow an initial filehandle to be obtained. A WebNFS client uses the public filehandle as an initial filehandle rather than using the MOUNT protocol. Since NFS version 2 and version 3 have different filehandle formats, the public filehandle is defined differently for each.
公共文件句柄是一个例外。它是一个具有保留值和特殊语义的NFS文件句柄，允许获取初始文件句柄。WebNFS客户端使用公共文件句柄作为初始文件句柄，而不是使用装载协议。由于NFS版本2和版本3具有不同的文件句柄格式，因此公共文件句柄的定义各不相同。
The public filehandle is a zero filehandle. For NFS version 2 this is a filehandle with 32 zero octets. A version 3 public filehandle has zero length.
公共文件句柄是零文件句柄。对于NFS版本2，这是一个具有32个零八位字节的文件句柄。版本3公共文件句柄的长度为零。
A version 2 filehandle is defined in RFC 1094 as an opaque value occupying 32 octets. A version 2 public filehandle has a zero in each octet, i.e. all zeros.
RFC 1094将版本2文件句柄定义为占用32个八位字节的不透明值。版本2的公共文件句柄在每个八位字节中都有一个零，即全零。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A version 3 filehandle is defined in RFC 1813 as a variable length opaque value occupying up to 64 octets. The length of the filehandle is indicated by an integer value contained in a 4 octet value which describes the number of valid octets that follow. A version 3 public filehandle has a length of zero.
RFC 1813将版本3文件句柄定义为可变长度不透明值，最多占用64个八位字节。文件句柄的长度由包含在4个八位字节值中的整数值表示，该值描述了后面的有效八位字节数。版本3公共文件句柄的长度为零。
+-+-+-+-+
| 0 |
+-+-+-+-+
+-+-+-+-+
| 0 |
+-+-+-+-+
Normally the NFS LOOKUP request (version 2 or 3) takes a directory filehandle along with the name of a directory member, and returns the filehandle of the directory member. If a client needs to evaluate a pathname that contains a sequence of components, then beginning with
通常，NFS查找请求（版本2或3）会获取目录文件句柄和目录成员的名称，并返回目录成员的文件句柄。如果客户端需要计算包含一系列组件的路径名，则从
the directory filehandle of the first component it must issue a series of LOOKUP requests one component at a time. For instance, evaluation of the path "a/b/c" will generate separate LOOKUP requests for each component of the pathname "a", "b", and "c".
第一个组件的目录文件句柄它必须一次向一个组件发出一系列查找请求。例如，对路径“a/b/c”的求值将为路径名“a”、“b”和“c”的每个组件生成单独的查找请求。
A LOOKUP request that uses the public filehandle can provide a pathname containing multiple components. The server is expected to evaluate the entire pathname and return a filehandle for the final component.
使用公共文件句柄的查找请求可以提供包含多个组件的路径名。服务器需要计算整个路径名，并返回最终组件的文件句柄。
For example, rather than evaluate the path "a/b/c" as:
例如，不是将路径“a/b/c”评估为：
LOOKUP FH=0x0 "a" --->
<--- FH=0x1
LOOKUP FH=0x1 "b" --->
<--- FH=0x2
LOOKUP FH=0x2 "c" --->
<--- FH=0x3
LOOKUP FH=0x0 "a" --->
<--- FH=0x1
LOOKUP FH=0x1 "b" --->
<--- FH=0x2
LOOKUP FH=0x2 "c" --->
<--- FH=0x3
Relative to the public filehandle these three LOOKUP requests can be replaced by a single multi-component lookup:
相对于公共文件句柄，这三个查找请求可以替换为单个多组件查找：
LOOKUP FH=0x0 "a/b/c" --->
<--- FH=0x3
LOOKUP FH=0x0 "a/b/c" --->
<--- FH=0x3
Multi-component lookup is supported only for LOOKUP requests relative to the public filehandle.
多组件查找仅支持相对于公共文件句柄的查找请求。
The <url-path> of the NFS URL must be evaluated as a multi-component lookup. This implies that the path components are delimited by slashes and the characters that make up the path must be in the printable US-ASCII character set. Characters not in the "unreserved" set (see BNF description below) may be included in pathname components but must be escaped.
NFS url的<url路径>必须作为多组件查找进行评估。这意味着路径组件由斜杠分隔，组成路径的字符必须在可打印的US-ASCII字符集中。不在“unreserved”集中的字符（参见下面的BNF描述）可能包含在路径名组件中，但必须转义。
If the <url-path> is empty or consists solely of "/", the client must send a multi-component lookup for the pathname ".".
如果<url path>为空或仅由“/”组成，则客户端必须发送路径名“”的多组件查找。
A multi-component pathname that begins with a slash character is considered "absolute" and will be evaluated relative to the server's root. A pathname that does not begin with a slash is "relative" and will be evaluated relative to the directory with which the public filehandle is associated.
以斜杠字符开头的多组件路径名被视为“绝对”，并将相对于服务器的根进行计算。不以斜杠开头的路径名是“相对的”，将相对于与公共文件句柄关联的目录进行计算。
Note that the initial "/" that introduces the <url-path> of an NFS URL must not be passed to the server for multi-component lookup since the pathname is to be evaluated relative to the public filehandle directory. For example, if the public filehandle is associated with the server's directory "/a/b/c" then the URL:
请注意，引入NFS url的<url path>的初始“/”不能传递给服务器进行多组件查找，因为路径名是相对于公共filehandle目录计算的。例如，如果公共文件句柄与服务器的目录“/a/b/c”关联，则URL：
nfs://server/d/e/f
nfs://server/d/e/f
will be evaluated with a multi-component lookup of the path "d/e/f" relative to the server's directory "/a/b/c" while the URL:
将使用多组件查找路径“d/e/f”相对于服务器目录“/a/b/c”进行评估，而URL：
nfs://server//a/b/c/d/e/f
nfs://server//a/b/c/d/e/f
will locate the same file with an absolute multi-component lookup of 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.
将使用相对于服务器文件系统根目录的路径“/a/b/c/d/e/f”的绝对多组件查找来定位同一文件。请注意，路径的开头需要一个双斜杠。
Not all WebNFS servers can support arbitrary use of absolute paths. Clearly, the server must not return a filehandle if the path identifies a file or directory that is not exported by the server. In addition, some servers will not return a filehandle if the path names a file or directory in an exported filesystem different from the one that is associated with the public filehandle.
并非所有WebNFS服务器都支持任意使用绝对路径。显然，如果路径标识服务器未导出的文件或目录，则服务器不得返回文件句柄。此外，如果路径将导出文件系统中的文件或目录命名为与公共文件句柄关联的文件或目录不同的文件或目录，则某些服务器将不会返回文件句柄。
The NFS protocol supports symbolic links, which are the filesystem equivalent of a relative URL. If a WebNFS client retrieves a filehandle for a symbolic link (as indicated by the file type attribute) then it should send a READLINK request to the server to retrieve the path comprising the symbolic link.
NFS协议支持符号链接，符号链接是与相对URL等效的文件系统。如果WebNFS客户端检索符号链接的文件句柄（如文件类型属性所示），则应向服务器发送READLINK请求以检索包含符号链接的路径。
This path should then be combined with the URL which referenced the symbolic link according to the rules described in RFC 1808. If the relative URL in the symbolic link text is to be resolved successfully then it must contain only ASCII characters and conform to the syntax described in RFC 1808. Note that this allows a symbolic link to contain an entire URL and it may specify a scheme that is not necessarily an NFS URL.
然后，根据RFC 1808中描述的规则，该路径应与引用符号链接的URL组合。如果要成功解析符号链接文本中的相对URL，则它必须仅包含ASCII字符，并符合RFC 1808中描述的语法。请注意，这允许符号链接包含整个URL，并且它可以指定不一定是NFS URL的方案。
A symbolic link path that begins with a slash will be evaluated as an absolute path relative to the directory associated with the public filehandle which may not be the same as the server's system root directory. If symbolic links with absolute paths are to be evaluated correctly on both client and server then the public filehandle must be associated with the system root directory.
以斜杠开头的符号链接路径将被计算为相对于与公共文件句柄关联的目录的绝对路径，该目录可能与服务器的系统根目录不同。如果要在客户端和服务器上正确计算具有绝对路径的符号链接，则公共文件句柄必须与系统根目录相关联。
For example, if the symbolic link is named by the URL
例如，如果符号链接由URL命名
nfs://server/a/b
nfs://server/a/b
then the following examples show how a new URL can be formed from the symbolic link text:
然后，以下示例显示如何从符号链接文本形成新URL：
c = nfs://server/a/c
c = nfs://server/a/c
c/d = nfs://server/a/c/d
c/d = nfs://server/a/c/d
../c = nfs://server/c
../c = nfs://server/c
/c/d = nfs://server/c/d
/c/d = nfs://server/c/d
nfs://server2/a/b = nfs://server2/a/b
nfs://server2/a/b = nfs://server2/a/b
The NFS URL may have limited use for naming files on servers that do not support the public filehandle and multi-component lookup.
NFS URL在不支持公共文件句柄和多组件查找的服务器上命名文件的用途可能有限。
If the server returns an NFS3ERR_STALE, NFS3ERR_INVAL, or NFS3ERR_BADHANDLE error in response to the client's use of a public filehandle, then the client should attempt to resolve the <url-path> to a filehandle using the MOUNT protocol.
如果服务器返回NFS3ERR_STALE、NFS3ERR_INVAL或NFS3ERR_BADHANDLE错误以响应客户端使用公共文件句柄，则客户端应尝试使用装载协议将<url path>解析为文件句柄。
Version 1 of the MOUNT protocol is described in Appendix A of RFC 1094 and version 3 in Appendix I of RFC 1813. Version 2 of the MOUNT protocol is identical to version 1 except for the addition of a procedure MOUNTPROC_PATHCONF which returns POSIX pathconf information from the server.
RFC 1094附录A中描述了装载协议的第1版，RFC 1813附录I中描述了第3版。装载协议的版本2与版本1相同，只是添加了一个过程MOUNTPROC_PATHCONF，该过程从服务器返回POSIX PATHCONF信息。
Note that the pathname sent to the server in the MOUNTPROC_MNT request is assumed to be a server native path, rather than a slash-separated path described by RFC 1738. Hence, the MOUNT protocol can reasonably be expected to map a <url-path> to a filehandle only on servers that support slash-separated ASCII native paths. In general, servers that do not support WebNFS access or slash-separated ASCII native paths should not advertise NFS URLs.
请注意，在MOUNTPROC_MNT请求中发送到服务器的路径名被假定为服务器本机路径，而不是RFC 1738描述的斜杠分隔路径。因此，装载协议可以合理地预期仅在支持斜杠分隔ASCII本机路径的服务器上将<url path>映射到文件句柄。通常，不支持WebNFS访问或斜杠分隔的ASCII本机路径的服务器不应播发NFS URL。
At this point the client must already have some indication as to which version of the NFS protocol is supported on the server. Since the filehandle format differs between NFS versions 2 and 3, the client must select the appropriate version of the MOUNT protocol. MOUNT versions 1 and 2 return only NFS version 2 filehandles, whereas MOUNT version 3 returns NFS version 3 filehandles.
此时，客户机必须已经知道服务器上支持哪个版本的NFS协议。由于NFS版本2和3的filehandle格式不同，因此客户端必须选择适当的装载协议版本。装载版本1和2仅返回NFS版本2文件句柄，而装载版本3返回NFS版本3文件句柄。
Unlike the NFS service, the MOUNT service is not registered on a well-known port. The client must use the PORTMAP service to locate the server's MOUNT port before it can transmit a MOUNTPROC_MNT request to retrieve the filehandle corresponding to the requested path.
与NFS服务不同，装载服务未在已知端口上注册。客户端必须使用PORTMAP服务定位服务器的装载端口，然后才能发送MOUNTPROC_MNT请求以检索与请求路径对应的文件句柄。
Client Server
------ ------
Client Server
------ ------
-------------- MOUNT port ? --------------> Portmapper
<-------------- Port=984 ------------------
-------------- MOUNT port ? --------------> Portmapper
<-------------- Port=984 ------------------
------- Filehandle for /export/foo ? ----> Mountd @ port 984
<--------- Filehandle=0xf82455ce0.. ------
------- Filehandle for /export/foo ? ----> Mountd @ port 984
<--------- Filehandle=0xf82455ce0.. ------
NFS servers commonly use a client's successful MOUNTPROC_MNT request request as an indication that the client has "mounted" the filesystem and may maintain this information in a file that lists the filesystems that clients currently have mounted. This information is removed from the file when the client transmits an MOUNTPROC_UMNT request. Upon receiving a successful reply to a MOUNTPROC_MNT request, a WebNFS client should send a MOUNTPROC_UMNT request to prevent an accumulation of "mounted" records on the server.
NFS服务器通常使用客户机成功的MOUNTPROC_MNT请求作为客户机已“装载”文件系统的指示，并且可以在列出客户机当前已装载的文件系统的文件中维护此信息。当客户端发送MOUNTPROC\UMNT请求时，此信息将从文件中删除。在收到对MOUNTPROC\u MNT请求的成功回复后，WebNFS客户端应发送MOUNTPROC\u UMNT请求，以防止服务器上累积“已装载”的记录。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)," RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators," RFC 1808, June 1995.
[RFC1808]菲尔丁，R.，“相对统一资源定位器”，RFC18081995年6月。
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2," RFC 1831, August 1995.
[RFC1831]Srinivasan，R.，“RPC：远程过程调用协议规范版本2”，RFC18311995年8月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard," RFC 1832, August 1995.
[RFC1832]Srinivasan，R.，“XDR：外部数据表示标准”，RFC 1832，1995年8月。
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2," RFC 1833, August 1995.
[RFC1833]Srinivasan，R.，“ONC RPC版本2的绑定协议”，RFC 1833，1995年8月。
[RFC1094] Sun Microsystems, Inc., "Network Filesystem Specification," RFC 1094, March 1989.
[RFC1094]Sun Microsystems，Inc.，“网络文件系统规范”，RFC10941989年3月。
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification," RFC 1813, June 1995.
[RFC1813]Callaghan，B.，Pawlowski，B.和P.Staubach，“NFS版本3协议规范”，RFC 1813，1995年6月。
[RFC2054] Callaghan, B., "WebNFS Client Specification," RFC 2054, October 1996.
[RFC2054]Callaghan，B.，“WebNFS客户端规范”，RFC2054，1996年10月。
[RFC2055] Callaghan, B., "WebNFS Server Specification," RFC 2055, October 1996.
[RFC2055]Callaghan，B.，“WebNFS服务器规范”，RFC20551996年10月。
[Sandberg] Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon, "Design and Implementation of the Sun Network Filesystem," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Summer 1985. The basic paper describing the SunOS implementation of the NFS version 2 protocol, and discusses the goals, protocol specification and trade-offs.
[Sandberg]R.，D.Goldberg，S.Kleiman，D.Walsh，B.Lyon，“Sun网络文件系统的设计和实现”，USENIX会议记录，USENIX协会，加利福尼亚州伯克利，1985年夏季。本文描述了NFS版本2协议的SunOS实现，并讨论了目标、协议规范和权衡。
[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 for the NFS and accompanying protocols, including the Lock Manager and the Portmapper.
[X/OpenNFS]X/Open Company，Ltd.，X/Open CAE规范：X/Open互联网协议：X/NFS，X/Open Company，Ltd.，雷丁伯克希尔福伯里路顶点广场，英国RG1 1AX，1991年。这是NFS及其附带协议（包括锁管理器和端口映射器）不可或缺的参考。
[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, RG1 1AX, United Kingdom, 1991. This is an indispensable reference for NFS protocol and accompanying protocols, including the Lock Manager and the Portmapper.
[X/OpenPCNFS]X/OpenCompany，Ltd.，X/OpenCAE规范：X/OpenInternetworking协议：（PC）NFS，开发者规范，X/OpenCompany，Ltd.，福伯里路顶点广场，雷丁伯克希尔，RG1 1AX，英国，1991年。这是NFS协议及其附带协议（包括锁管理器和端口映射器）不可或缺的参考。
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.
由于WebNFS服务器功能基于NFS协议版本2和3，因此RFC 1094、RFC 1831和RFC 1832中描述的基于RPC的安全注意事项也适用于此处。
Server implementors should be careful when implementing multi-component lookup that the client cannot obtain unauthorized access to files or directories. For example: a path that includes multiple occurrences of "../" may locate a filesystem outside of the exported filesystem associated with the public filehandle.
服务器实现人员在实现多组件查找时应小心，以免客户端无法获得对文件或目录的未经授权的访问。例如：包含多次出现“./”的路径可能位于与公共文件句柄关联的导出文件系统之外的文件系统。
Clients and servers may separately negotiate secure connection schemes for authentication, data integrity, and privacy.
客户端和服务器可以分别协商安全连接方案，以实现身份验证、数据完整性和隐私。
The syntax of the NFS URL is a subset of the Generic URL syntax
described in RFC 1738. An NFS URL does not include user or password
components, nor does it recognize "?" query or "#" fragment
components.
nfsURL = "nfs" ":" relativeURL
relativeURL = net_path | abs_path | rel_path
net_path = "//" hostport [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path_segments ]
The syntax of the NFS URL is a subset of the Generic URL syntax
described in RFC 1738. An NFS URL does not include user or password
components, nor does it recognize "?" query or "#" fragment
components.
nfsURL = "nfs" ":" relativeURL
relativeURL = net_path | abs_path | rel_path
net_path = "//" hostport [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path_segments ]
hostport = host [ ":" port ]
host = hostname | hostnumber
hostname = *( domainlabel "." ) toplabel
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
hostnumber = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit
hostport = host [ ":" port ]
host = hostname | hostnumber
hostname = *( domainlabel "." ) toplabel
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
hostnumber = 1*digit "." 1*digit "." 1*digit "." 1*digit
port = *digit
url-path = [ "/" ] path_segments
path_segments = segment *( "/" segment )
segment = *pchar
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
url-path = [ "/" ] path_segments
path_segments = segment *( "/" segment )
segment = *pchar
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
unreserved = alpha | digit | mark
mark = "$" | "-" | "_" | "." | "!" | "~" |
"*" | "'" | "(" | ")" | ","
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
unreserved = alpha | digit | mark
mark = "$" | "-" | "_" | "." | "!" | "~" |
"*" | "'" | "(" | ")" | ","
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
alphanum = alpha | digit alpha = lowalpha | upalpha
alphanum=alpha |数字alpha=low alpha | upalpha
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"
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"
This specification was extensively reviewed by the NFS group at SunSoft and brainstormed by Michael Eisler.
该规范由SunSoft的NFS小组进行了广泛审查，并由Michael Eisler进行了头脑风暴。
Address comments related to this RFC to:
将与本RFC相关的意见发送至：
brent@eng.sun.com
brent@eng.sun.com
Brent Callaghan Sun Microsystems, Inc. Mailstop Mpk17-201, 901 San Antonio Road, Palo Alto, California 94303
Brent Callaghan Sun Microsystems，Inc.邮箱Mpk17-201，加利福尼亚州帕洛阿尔托市圣安东尼奥路901号，邮编94303
Phone: 1-415-786-5067 EMail: brent.callaghan@eng.sun.com Fax: 1-415-786-5896
电话：1-415-786-5067电子邮件：布伦特。callaghan@eng.sun.com传真：1-415-786-5896
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。”