[要約] RFC 2224は、NFS URL Schemeの仕様を定義しており、NFSリソースにアクセスするための統一されたURL形式を提供します。このRFCの目的は、NFSリソースへのアクセスを簡素化し、異なるシステム間での互換性を確保することです。
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.
Copyright（C）The Internet Society（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「Uniform Resource Locators（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]の2つのバージョンに存在します。どちらも、関連する外部データ表現（XDR）[RFC1832]とバインディングプロトコル[RFC1833]でONC RPC [RFC1831]に基づいて構築されています。
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
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で説明されているCommon Internet Scheme Syntaxに基づいています。一般的な形式は次のとおりです。
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-path>もオプションです。
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-path>は、/ <directory> / <directory> / <directory> /.../ <name>の形式の階層ディレクトリパスです。 <url-path>は、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 PROG_MISMATCHエラーを返した場合、クライアントは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クライアントは、MOUNTプロトコルを使用するのではなく、パブリックファイルハンドルを初期ファイルハンドルとして使用します。 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.
バージョン2のファイルハンドルは、RFC 1094で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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
バージョン3のファイルハンドルは、RFC 1813で最大64オクテットを占める可変長の不透明な値として定義されています。ファイルハンドルの長さは、後に続く有効なオクテットの数を表す4オクテット値に含まれる整数値によって示されます。バージョン3の公開ファイルハンドルの長さはゼロです。
+-+-+-+-+
| 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 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".
通常、NFS LOOKUP要求（バージョン2または3）は、ディレクトリメンバーの名前と共にディレクトリファイルハンドルを受け取り、ディレクトリメンバーのファイルハンドルを返します。クライアントが一連のコンポーネントを含むパス名を評価する必要がある場合、最初のコンポーネントのディレクトリファイルハンドルから始めて、一度に1つのコンポーネントに対して一連のLOOKUP要求を発行する必要があります。たとえば、パス「a / b / c」を評価すると、パス名「a」、「b」、および「c」の各コンポーネントに対して個別のLOOKUPリクエストが生成されます。
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.
パブリックファイルハンドルを使用するLOOKUPリクエストは、複数のコンポーネントを含むパス名を提供できます。サーバーは、パス名全体を評価し、最終コンポーネントのファイルハンドルを返すことが期待されています。
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
Relative to the public filehandle these three LOOKUP requests can be replaced by a single multi-component lookup:
パブリックファイルハンドルに比べて、これらの3つのLOOKUPリクエストは、単一のマルチコンポーネントルックアップで置き換えることができます。
LOOKUP FH=0x0 "a/b/c" --->
<--- FH=0x3
Multi-component lookup is supported only for LOOKUP requests relative to the public filehandle.
マルチコンポーネントルックアップは、パブリックファイルハンドルに関連するLOOKUPリクエストに対してのみサポートされます。
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-path>は、マルチコンポーネントルックアップとして評価する必要があります。これは、パスコンポーネントがスラッシュで区切られ、パスを構成する文字が印刷可能なUS-ASCII文字セットである必要があることを意味します。 「予約されていない」セット（下記の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>を導入する最初の「/」をマルチコンポーネントルックアップのサーバーに渡してはならないことに注意してください。たとえば、公開ファイルハンドルがサーバーのディレクトリ「/ a / b / c」に関連付けられている場合、URLは次のようになります。
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:
サーバーのディレクトリ「/ a / b / c」に対するパス「d / e / f」のマルチコンポーネントルックアップで評価されますが、URLは次のとおりです。
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
then the following examples show how a new URL can be formed from the symbolic link text:
次の例は、シンボリックリンクテキストから新しいURLを作成する方法を示しています。
c = nfs://server/a/c
c/d = nfs://server/a/c/d
../c = nfs://server/c
/c/d = nfs://server/c/d
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エラーを返す場合、クライアントはMOUNTプロトコルを使用して<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.
MOUNTプロトコルのバージョン1は、RFC 1094の付録AとRFC 1813の付録Iのバージョン3で説明されています。MOUNTプロトコルのバージョン2は、バージョン1と同じです。サーバ。
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で記述されているスラッシュで区切られたパスではなく、サーバーのネイティブパスであると想定されます。したがって、MOUNTプロトコルは<url-path>をマップすることが合理的に期待できます。スラッシュで区切られたASCIIネイティブパスをサポートするサーバーでのみファイルハンドルに。一般に、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で異なるため、クライアントは適切なバージョンのMOUNTプロトコルを選択する必要があります。 MOUNTバージョン1および2はNFSバージョン2ファイルハンドルのみを返しますが、MOUNTバージョン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サービスとは異なり、MOUNTサービスは既知のポートに登録されていません。クライアントは、要求されたパスに対応するファイルハンドルを取得するためにMOUNTPROC_MNT要求を送信する前に、PORTMAPサービスを使用してサーバーのMOUNTポートを見つける必要があります。
Client Server
------ ------
-------------- MOUNT port ? --------------> Portmapper
<-------------- Port=984 ------------------
------- 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_MNTリクエストに対する応答が成功した場合、WebNFSクライアントはMOUNTPROC_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、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1808] Fielding, R., "Relative Uniform Resource Locators," RFC 1808, June 1995.
[RFC1808]フィールディング、R。、「Relative Uniform Resource Locators」、RFC 1808、1995年6月。
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2," RFC 1831, August 1995.
[RFC1831] Srinivasan、R。、「RPC：Remote Procedure Call Protocol Specification Version 2」、RFC 1831、1995年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。、「Network Filesystem Specification」、RFC 1094、1989年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クライアント仕様」、RFC 2054、1996年10月。
[RFC2055] Callaghan, B., "WebNFS Server Specification," RFC 2055, October 1996.
[RFC2055] Callaghan、B。、「WebNFS Server Specification」、RFC 2055、1996年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] 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。 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インターネットワーキングのプロトコル：XNFS、X / Open Company、Ltd.、Apex Plaza、Forbury Road、Reading Berkshire、RG1 1AX、イギリス、1991。これは、NFSと、Lock Managerや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, 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 / 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、イギリス、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 ]
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 | ":" | "@" | "&" | "=" | "+"
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
unreserved = alpha | digit | mark
mark = "$" | "-" | "_" | "." | "!" | "~" |
"*" | "'" | "(" | ")" | ","
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 = 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"
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 Callaghan Sun Microsystems, Inc. Mailstop Mpk17-201, 901 San Antonio Road, Palo Alto, California 94303
Brent Callaghan Sun Microsystems、Inc. Mailstop Mpk17-201、901 San Antonio Road、Palo Alto、California 94303
Phone: 1-415-786-5067 EMail: brent.callaghan@eng.sun.com Fax: 1-415-786-5896
電話：1-415-786-5067メール：brent.callaghan@eng.sun.comファックス：1-415-786-5896
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（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."
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性の権利または黙示の保証を侵害するものではありません。」