[要約] RFC 8178は、NFSv4の拡張とマイナーバージョンのためのルールを定めたものであり、NFSv4プロトコルの進化と互換性を確保することを目的としています。
Internet Engineering Task Force (IETF) D. Noveck
Request for Comments: 8178 NetApp
Updates: 5661, 7862 July 2017
Category: Standards Track
ISSN: 2070-1721
Rules for NFSv4 Extensions and Minor Versions
NFSv4拡張とマイナーバージョンのルール
Abstract
概要
This document describes the rules relating to the extension of the NFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions.
このドキュメントでは、NFSv4ファミリーのプロトコルの拡張に関するルールについて説明します。マイナーバージョンの作成、既存のマイナーバージョンへのオプション機能の追加、および提案された標準として既に公開されている機能の欠陥の修正について説明します。このドキュメントに記載されているマイナーバージョンの構築とマイナーバージョン実装の相互作用に関するルールは、RFC 5661およびマイナーバージョンを定義する他のRFCのマイナーバージョン管理ルールに優先します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8178.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8178で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Use of Keywords Defined in RFCs 2119 and 8174 . . . . . . 4
2.2. Use of Feature Statuses . . . . . . . . . . . . . . . . . 4
2.3. NFSv4 Versions . . . . . . . . . . . . . . . . . . . . . 5
3. Consolidation of Extension Rules . . . . . . . . . . . . . . 6
4. XDR Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. XDR Extension . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Rules for XDR Extension within NFSv4 . . . . . . . . . . 8
4.3. Handling of Protocol Elements by Responders . . . . . . . 9
4.4. Inter-version Interoperability . . . . . . . . . . . . . 11
4.4.1. Requirements for Knowledge of Protocol Elements . . . 11
4.4.2. Establishing Interoperability . . . . . . . . . . . . 12
4.4.3. Determining Knowledge of Protocol Elements . . . . . 14
4.5. XDR Overlay . . . . . . . . . . . . . . . . . . . . . . . 15
5. Other NFSv4 Protocol Changes . . . . . . . . . . . . . . . . 15
5.1. Field Interpretation and Use . . . . . . . . . . . . . . 15
5.2. Behavioral Changes . . . . . . . . . . . . . . . . . . . 16
6. Extending Existing Minor Versions . . . . . . . . . . . . . . 17
7. Minor Versions . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Creation of New Minor Versions . . . . . . . . . . . . . 18
8. Minor Version Interaction Rules . . . . . . . . . . . . . . . 18
8.1. Minor Version Identifier Transfer Issues . . . . . . . . 19
8.2. Minor Version Compatibility . . . . . . . . . . . . . . . 19
9. Correction of Existing Minor Versions and Features . . . . . 20
9.1. XDR Changes to Implement Protocol Corrections . . . . . . 21
9.2. XDR Corrections to OPTIONAL Features . . . . . . . . . . 21
9.3. XDR Corrections to REQUIRED Features . . . . . . . . . . 22
9.4. Addressing XDR Corrections in Later Minor Versions . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
To address the requirement for an NFS protocol that can evolve as the need arises, the Network File System (NFS) version 4 (NFSv4) protocol provides a framework to allow for future changes via the creation of new protocol versions, including minor versions and certain forms of modification of existing minor versions. The extension rules contained in this document allow extensions and other changes to be implemented in a way that maintains compatibility with existing clients and servers.
ネットワークファイルシステム（NFS）バージョン4（NFSv4）プロトコルは、必要に応じて進化するNFSプロトコルの要件に対処するために、マイナーバージョンや特定の既存のマイナーバージョンの変更の形式。このドキュメントに含まれる拡張ルールにより、既存のクライアントやサーバーとの互換性を維持する方法で拡張やその他の変更を実装できます。
Previously, all protocol changes had been part of new minor versions. The COMPOUND procedure (see Section 14.2 of [RFC7530]) specifies the minor version being used by the client in making requests. The CB_COMPOUND procedure (see Section 15.2 of [RFC7530]) specifies the minor version being used by the server on callback requests.
以前は、すべてのプロトコル変更は新しいマイナーバージョンの一部でした。 COMPOUNDプロシージャ（[RFC7530]のセクション14.2を参照）は、クライアントが要求を行うときに使用するマイナーバージョンを指定します。 CB_COMPOUNDプロシージャ（[RFC7530]のセクション15.2を参照）は、サーバーがコールバックリクエストで使用するマイナーバージョンを指定します。
Creation of a new minor version is no longer the only way in which protocol changes may be made. Optional features may be added as extensions and protocol corrections can be proposed, specified, and implemented within the context of a single minor version. Creation of new minor versions remains available when needed.
新しいマイナーバージョンの作成は、プロトコルの変更を行う唯一の方法ではなくなりました。オプション機能は、拡張機能として追加でき、プロトコルの修正を提案、指定、および単一のマイナーバージョンのコンテキスト内で実装できます。必要に応じて、新しいマイナーバージョンを作成できます。
The goal of allowing extensions within the context of a minor version is to provide more implementation flexibility while preserving interoperability on protocol upgrade. As described in Section 4.4, a client and server may each choose a subset of available extensions. Each party can successfully use a subset of protocol elements that are known to and supported by both the client and server. Support for this common subset is not affected by the fact that extensions outside this common subset may be supported by the server or potentially used by the client.
マイナーバージョンのコンテキスト内で拡張機能を許可する目的は、プロトコルのアップグレード時の相互運用性を維持しながら、実装の柔軟性を高めることです。セクション4.4で説明したように、クライアントとサーバーはそれぞれ、使用可能な拡張機能のサブセットを選択できます。各当事者は、クライアントとサーバーの両方が認識してサポートしているプロトコル要素のサブセットを正常に使用できます。この共通サブセットのサポートは、この共通サブセットの外部の拡張機能がサーバーでサポートされていたり、クライアントで使用されている可能性があるという事実の影響を受けません。
A basic familiarity with NFSv4 terminology is assumed in this document and the reader is pointed to [RFC7530].
このドキュメントでは、NFSv4の用語に関する基本的な知識があることを前提としており、読者は[RFC7530]を参照しています。
In this document, the term "version" is not limited to minor versions. When minor versions are meant, the term "minor version" is used explicitly. For more discussion of this and related terms, see Section 2.3.
このドキュメントでは、「バージョン」という用語はマイナーバージョンに限定されません。マイナーバージョンを意味する場合、「マイナーバージョン」という用語が明示的に使用されます。この用語と関連する用語の詳細については、セクション2.3を参照してください。
A "feature package" is a set of features that are defined together, either as part of a minor version or as part of the same protocol extension.
「機能パッケージ」は、マイナーバージョンの一部として、または同じプロトコル拡張機能の一部として、一緒に定義される機能のセットです。
The keywords defined by [RFC2119] [RFC8174] have special meanings that this document intends to adhere to. However, due to the nature of this document and some special circumstances, there are some complexities to take note of:
[RFC2119] [RFC8174]で定義されているキーワードには、このドキュメントが準拠する予定の特別な意味があります。ただし、このドキュメントの性質といくつかの特別な状況により、次の点に注意する必要があります。
o Where this document does not directly specify implementation requirements, use of these capitalized terms is often not appropriate since the guidance given in this document does not directly affect interoperability.
o このドキュメントで実装要件を直接指定していない場合、このドキュメントで提供されているガイダンスは相互運用性に直接影響しないため、これらの大文字の用語の使用は適切ではないことがよくあります。
o In this document, what authors of RFCs defining features and minor versions need to do is stated without these specialized terms. Although it is necessary to follow this guidance to provide successful NFSv4 protocol extension, that sort of necessity is not of the sort defined as applicable to the use of the keywords defined in [RFC2119] [RFC8174].
o このドキュメントでは、機能とマイナーバージョンを定義するRFCの作成者が行う必要があることを、これらの専門用語なしで説明しています。 NFSv4プロトコルの拡張を成功させるには、このガイダンスに従う必要がありますが、そのような必要性は、[RFC2119] [RFC8174]で定義されているキーワードの使用に適用できると定義されている種類のものではありません。
The fact that these capitalized terms are not used should not be interpreted as indicating that this guidance does not need to be followed or is somehow not important.
これらの大文字で表記された用語が使用されていないという事実は、このガイダンスに従う必要がない、または何とか重要ではないことを示すものとして解釈されるべきではありません。
o In speaking of the possible statuses of features and feature elements, the terms "OPTIONAL" and "REQUIRED" are used. For further discussion, see Section 2.2.
o 機能および機能要素の可能なステータスについて言えば、「オプション」および「必須」という用語が使用されます。詳細については、セクション2.2を参照してください。
o When one of these upper-case keywords defined in [RFC2119] [RFC8174] is used in this document, it is in the context of a rule directed to an implementer of NFSv4 minor versions, the status of a feature or protocol element, or in a quotation, sometimes indirect, from another document.
o [RFC2119] [RFC8174]で定義されているこれらの大文字のキーワードの1つがこのドキュメントで使用されている場合、NFSv4マイナーバージョンの実装者に向けられたルール、機能またはプロトコル要素のステータス、または別の文書からの引用、時には間接的。
There has been some confusion during the history of NFSv4 about the correct use of these terms, and instances in which the keywords defined in [RFC2119] [RFC8174] were used in ways that appear to be at variance with the definitions in that document.
NFSv4の歴史の中で、これらの用語の正しい使用と、[RFC2119] [RFC8174]で定義されたキーワードが、そのドキュメントの定義と異なるように見える方法で使用された例について、いくつかの混乱がありました。
o In [RFC3530], the lower-case terms "optional", "recommended", and "required" were used as feature statuses, Later, in [RFC5661] and [RFC7530], the corresponding upper-case keywords were used. It is not clear why this change was made.
o [RFC3530]では、小文字の「optional」、「recommended」、および「required」が機能のステータスとして使用されました。後で、[RFC5661]および[RFC7530]では、対応する大文字のキーワードが使用されました。この変更が行われた理由は明らかではありません。
o In the case of "RECOMMENDED", its use as a feature status is inconsistent with [RFC2119] [RFC8174] and it will not be used for this purpose in this document.
o 「推奨」の場合、機能ステータスとしての使用は[RFC2119] [RFC8174]と一貫性がなく、このドキュメントではこの目的で使用されません。
o The word "RECOMMENDED" to denote the status of attributes in [RFC7530] and [RFC5661] raises similar issues. This has been recognized in [RFC7530] with regard to NFSV4.0, although the situation with regard to NFSv4.1 remains unresolved.
o [RFC7530]と[RFC5661]で属性のステータスを示す「推奨」という単語は、同様の問題を引き起こします。これはNFSV4.0に関して[RFC7530]で認識されていますが、NFSv4.1に関する状況は未解決のままです。
In this document, the keywords "OPTIONAL" and "REQUIRED" and the phrase "mandatory to not implement" are used to denote the status of features within a given minor version. In using these terms, RFCs that specify the status of features inform:
このドキュメントでは、特定のマイナーバージョン内の機能のステータスを示すために、キーワード「OPTIONAL」と「REQUIRED」、および「実装不可」という語句が使用されています。これらの用語を使用すると、機能のステータスを指定するRFCは次のことを通知します。
o client implementations whether they need to deal with the absence of support for these features.
o これらの機能のサポートの欠如に対処する必要があるかどうかのクライアント実装。
o server implementations whether they need to provide support for these features.
o これらの機能のサポートを提供する必要があるかどうかのサーバー実装。
The term "version" denotes any valid protocol variant constructed according to the rules in this document. It includes minor versions, but there are situations that allow multiple variant versions to be associated with and coexist within a single minor version:
「バージョン」という用語は、このドキュメントのルールに従って構築された有効なプロトコルの変形を示します。これにはマイナーバージョンが含まれていますが、複数のバリアントバージョンを単一のマイナーバージョンに関連付けて共存させることができる状況があります。
o When there are feature specification documents published as Proposed Standards extending a given minor version, then the protocol defined by the minor version specification document, when combined with any subset (not necessarily a proper subset) of the feature specification documents, is a valid NFSv4 version variant that is part of the minor version in question.
o 特定のマイナーバージョンを拡張する提案された標準として公開されている機能仕様ドキュメントがある場合、機能仕様ドキュメントのサブセット（必ずしも適切なサブセットではない）と組み合わせると、マイナーバージョン仕様ドキュメントによって定義されたプロトコルは有効なNFSv4バージョンになります。問題のマイナーバージョンの一部であるバリアント。
o When there are protocol corrections published that update a given minor version, each set of published updates, up to the date of publication of the update, is a valid NFSv4 version variant that is part of the minor version in question.
o 特定のマイナーバージョンを更新するプロトコル修正が公開されている場合、公開された更新の各セットは、更新の公開日まで、問題のマイナーバージョンの一部である有効なNFSv4バージョンのバリアントです。
Because of the above, there can be multiple version variants that are part of a given minor version. Two of these are worthy of special terms:
上記のため、特定のマイナーバージョンの一部である複数のバージョンバリアントが存在する可能性があります。これらのうち2つは、特別な用語に値します。
o The term "base minor version" denotes the version variant that corresponds to the minor version as originally defined, including all protocol elements specified in the minor version definition document but not incorporating any extensions or protocol corrections published after that original definition.
o 「ベースマイナーバージョン」という用語は、最初に定義されたマイナーバージョンに対応するバージョンバリアントを示します。マイナーバージョン定義ドキュメントで指定されているすべてのプロトコル要素が含まれますが、元の定義の後に公開された拡張機能やプロトコル修正は組み込まれていません。
o At any given time, the term "current minor version" denotes the minor version variant including all extensions of and corrections to the minor version made by Standards Track documents published up to that time.
o 常に、「現在のマイナーバージョン」という用語は、その時点までに発行されたスタンダードトラックドキュメントによって作成されたマイナーバージョンのすべての拡張および修正を含むマイナーバージョンのバリアントを意味します。
Each client and server that implements a specific minor version will implement some particular variant of that minor version. Each variant is a subset of the current minor version and a superset of the base minor version. When the term "minor version" is used without either of these qualifiers, it should refer to something that is true of all variants within that minor version. For example, in the case of a minor version that has not had a protocol correction, one may refer to the set of REQUIRED features for that minor version since it is the same for all variants within the minor version. See Section 9 for a discussion of correcting an existing minor version.
特定のマイナーバージョンを実装する各クライアントおよびサーバーは、そのマイナーバージョンの特定のバリアントを実装します。各バリアントは、現在のマイナーバージョンのサブセットであり、ベースマイナーバージョンのスーパーセットです。これらの修飾子のいずれも使用せずに「マイナーバージョン」という用語を使用する場合、そのマイナーバージョン内のすべてのバリアントに当てはまるものを指す必要があります。たとえば、プロトコルが修正されていないマイナーバージョンの場合、マイナーバージョン内のすべてのバリアントで同じであるため、そのマイナーバージョンの一連の必須機能を参照できます。既存のマイナーバージョンの修正については、セクション9を参照してください。
In the past, the only existing extension rules were the minor versioning rules that were being maintained and specified in the Standards Track RFCs, which defined the individual minor versions. In the past, these minor versioning rules were modified on an ad hoc basis for each new minor version.
以前は、既存の拡張ルールは、個別のマイナーバージョンを定義する標準化トラックRFCで維持および指定されていたマイナーバージョン管理ルールのみでした。以前は、これらのマイナーバージョン管理ルールは、新しいマイナーバージョンごとにその場で変更されていました。
More recently, minor versioning rules were specified in [RFC5661] while modifications to those rules were allowed in subsequent minor versions.
最近では、マイナーバージョニングルールが[RFC5661]で指定されていましたが、それらのルールへの変更は後続のマイナーバージョンで許可されていました。
This document defines a set of extension rules, including rules for minor version construction. These rules apply to all future changes to the NFSv4 protocol. The rules are subject to change but any such change should be part of a Standards Track RFC obsoleting or updating this document.
このドキュメントでは、マイナーバージョンの構築に関するルールを含む、一連の拡張ルールを定義しています。これらのルールは、NFSv4プロトコルに対する将来のすべての変更に適用されます。規則は変更される可能性がありますが、そのような変更は、このドキュメントを廃止または更新する標準規格RFCの一部である必要があります。
Rather than a single list of extension rules, as was done in the minor versioning rules in [RFC5661], this document defines multiple sets of rules that deal with the various forms of protocol change provided for in the NFSv4 extension framework.
[RFC5661]のマイナーバージョニングルールで行われたように、拡張ルールの単一のリストではなく、このドキュメントでは、NFSv4拡張フレームワークで提供されるプロトコル変更のさまざまな形式を処理する複数のルールセットを定義します。
o The kinds of changes in External Data Representation (XDR) definitions that may be made to extend NFSv4 are addressed in the rules in Section 4.2.
o NFSv4を拡張するために行われる可能性のある外部データ表現（XDR）定義の種類の変更は、セクション4.2のルールで対処されています。
o Minor version construction, including rules applicable to changes that cannot be made in extensions to existing minor versions are addressed in Section 7.1.
o 既存のマイナーバージョンの拡張で行うことができない変更に適用されるルールを含むマイナーバージョンの構築については、セクション7.1で説明します。
o Minor version interaction rules are discussed in Sections 8.1 and 8.2.
o マイナーバージョンの相互作用ルールについては、セクション8.1および8.2で説明します。
This document supersedes minor versioning rules appearing in the minor version specification RFCs, including those in [RFC5661] and also the modification to those rules mentioned in [RFC7862]. As a result, potential conflicts among documents should be addressed as follows:
このドキュメントは、[RFC5661]にあるものを含むマイナーバージョン仕様RFCに表示されるマイナーバージョン管理ルールと、[RFC7862]で言及されているそれらのルールの変更に優先します。その結果、ドキュメント間の潜在的な競合は次のように対処する必要があります。
o The specification of the actual protocols for minor versions previously published as Proposed Standards take precedence over minor versioning rules in either this document or in the minor version specification RFCs. In other words, if the transition from version A to version B violates a minor versioning rule, the version B protocol stays as it is.
o 提案された標準として以前に公開されたマイナーバージョンの実際のプロトコルの仕様は、このドキュメントまたはマイナーバージョン仕様のRFCのマイナーバージョン管理ルールよりも優先されます。つまり、バージョンAからバージョンBへの移行がマイナーバージョン管理ルールに違反している場合、バージョンBプロトコルはそのままです。
o Since minor versioning rules #11 and #13 from [RFC5661] deal with the interactions between multiple minor versions, the situation is more complicated. See Section 8 for a discussion of these issues, including how potential conflicts between rules are to be resolved.
o [RFC5661]のマイナーバージョン管理ルール＃11および＃13は複数のマイナーバージョン間の相互作用を扱うため、状況はより複雑になります。ルール間の潜在的な競合をどのように解決するかを含め、これらの問題の説明については、セクション8を参照してください。
o Otherwise, any conflict between the extension rules in this document and those in minor version specification RFCs are to be resolved based on the treatment in this document. In particular, corrections may be made as specified in Section 9 for all previously specified minor versions, and the extensibility of previously specified minor versions is to be handled in accord with Section 6.
o それ以外の場合、このドキュメントの拡張ルールとマイナーバージョン仕様RFCの拡張ルールとの競合は、このドキュメントの扱いに基づいて解決されます。特に、以前に指定されたすべてのマイナーバージョンについて、セクション9で指定されたとおりに修正することができます。以前に指定されたマイナーバージョンの拡張性は、セクション6に従って処理されます。
Future minor version specification documents should avoid specifying rules relating to minor versioning and reference this document in connection with rules for NFSv4 extension.
将来のマイナーバージョンの仕様ドキュメントでは、マイナーバージョン管理に関するルールの指定を避け、NFSv4拡張のルールに関連してこのドキュメントを参照する必要があります。
As an extensible XDR-based protocol, NFSv4 has to ensure inter-version compatibility in situations in which the client and server use different XDR descriptions. For example, the client and server may implement different variants of the same minor version, in that they each might add different sets of extensions to the base minor version.
拡張可能なXDRベースのプロトコルとして、NFSv4はクライアントとサーバーが異なるXDR記述を使用する状況でバージョン間の互換性を保証する必要があります。たとえば、クライアントとサーバーは、同じマイナーバージョンの異なるバリアントを実装する場合があり、それぞれ異なる基本のマイナーバージョンに拡張機能のセットを追加する場合があります。
The XDR extension paradigm, discussed in Section 4.1, assures that these descriptions are compatible, with clients and servers able to determine and use those portions of the protocol that they both share according to the method described in Section 4.4.2.
セクション4.1で説明されているXDR拡張パラダイムは、これらの記述が互換性があることを保証します。クライアントとサーバーは、セクション4.4.2で説明されている方法に従って両方が共有するプロトコルの部分を決定して使用できます。
When an NFSv4 version change requires a modification to the protocol XDR, this is effected within a framework based on the idea of XDR extension. This is in contrast to transitions between major NFS versions (including that between NFSv3 and NFSv4.0) in which the XDR for one version was replaced by a different XDR for a newer version.
NFSv4バージョンの変更にプロトコルXDRの変更が必要な場合、これはXDR拡張のアイデアに基づくフレームワーク内で行われます。これは、あるバージョンのXDRが新しいバージョンの別のXDRに置き換えられたメジャーNFSバージョン間の移行（NFSv3とNFSv4.0間の移行を含む）とは対照的です。
The XDR extension approach allows an XDR description to be extended in a way that retains the structure of all previously valid messages. If a base XDR description is extended to create a second XDR description, the following will be true for the second description to be a valid extension of the first:
XDR拡張アプローチでは、以前に有効だったすべてのメッセージの構造を保持する方法でXDR記述を拡張できます。ベースXDR記述が拡張されて2番目のXDR記述が作成される場合、2番目の記述が最初の記述の有効な拡張になるには、以下が当てはまります。
o The set of valid messages described by the extended definition is a superset of that described by the first.
o 拡張定義で記述された有効なメッセージのセットは、最初のメッセージで記述されたメッセージのスーパーセットです。
o Each message within the set of valid messages described by the base definition is recognized as having exactly the same structure/interpretation using the extended definition.
o 基本定義によって記述された有効なメッセージのセット内の各メッセージは、拡張定義を使用してまったく同じ構造/解釈を持つものとして認識されます。
o Each message within the set of messages described as valid by the extended definition but not the base definition must be recognized, using the base definition, as part of an unknown extension.
o 基本定義ではなく拡張定義によって有効であると記述されたメッセージのセット内の各メッセージは、基本定義を使用して、不明な拡張の一部として認識される必要があります。
The use of XDR extension can facilitate compatibility between different versions of the NFSv4 protocol. When XDR extension is used to implement OPTIONAL features, the greatest degree of inter-version compatibility is obtained. In this case, as long as the rules in Section 6 are followed, no change in minor version number is needed and the extension may be effected in the context of a single minor version.
XDR拡張を使用すると、NFSv4プロトコルの異なるバージョン間の互換性を促進できます。 XDR拡張機能を使用してオプション機能を実装すると、バージョン間の互換性が最大になります。この場合、セクション6のルールが守られている限り、マイナーバージョン番号を変更する必要はなく、単一のマイナーバージョンのコンテキストで拡張が影響を受ける可能性があります。
In the context of NFSv4, given the central role of COMPOUND and CB_COMPOUND, addition of new RPC procedures is not allowed and the enumeration of operations and callback operations have a special role.
NFSv4のコンテキストでは、COMPOUNDおよびCB_COMPOUNDの中心的な役割を考えると、新しいRPCプロシージャの追加は許可されておらず、操作の列挙とコールバック操作には特別な役割があります。
The following XDR extensions, by their nature, affect both messages sent by requesters (i.e., requests and callbacks), and responders (i.e., replies and callback replies).
次のXDR拡張機能は、その性質上、リクエスター（つまり、リクエストとコールバック）から送信されるメッセージとレスポンダ（つまり、返信とコールバック返信）の両方に影響します。
o Addition of previously unspecified operation codes, within the framework established by COMPOUND and CB_COMPOUND. These extend the appropriate enumeration and the corresponding switches devoted to requests and responses for the associated direction of operation.
o COMPOUNDおよびCB_COMPOUNDによって確立されたフレームワーク内で、以前は指定されていなかったオペレーションコードの追加。これらは、適切な列挙と、関連する操作の方向の要求と応答専用のスイッチを拡張します。
o Addition of previously unspecified attributes. These add additional numeric constants that define each attribute's bit position within the attribute bitmap, together with XDR typedefs that specify the attributes' format within the nominally opaque arrays specifying sets of attributes.
o 以前は指定されていなかった属性の追加。これらは、属性ビットマップ内の各属性のビット位置を定義する数値定数と、属性のセットを指定する名目上不透明な配列内の属性の形式を指定するXDR typedefを追加します。
Other sorts of changes will generally affect one of requests, replies, callback, or callback replies. Although all are valid XDR extensions, the messages that are affected may determine whether the extension requires a new minor version (see Section 7) or can be made as an extension within an existing minor version (see Section 6).
その他の種類の変更は、通常、要求、応答、コールバック、またはコールバック応答のいずれかに影響します。すべて有効なXDR拡張機能ですが、影響を受けるメッセージによって、拡張機能に新しいマイナーバージョンが必要か（セクション7を参照）、既存のマイナーバージョン内の拡張機能として作成できるか（セクション6を参照）が決まる場合があります。
o Addition of new, previously unused, values to existing enums.
o 以前は使用されていなかった新しい値を既存の列挙型に追加します。
o Addition of previously unassigned bit values to a flag word.
o 以前に割り当てられていないビット値をフラグワードに追加します。
o Addition of new cases to existing switches, provided that the existing switch did not contain a default case.
o 既存のスイッチにデフォルトのケースが含まれていなかった場合の、既存のスイッチへの新しいケースの追加。
None of the following is allowed to happen:
次のいずれも発生することは許可されていません。
o Any change to the structure of existing requests or replies other than those listed above.
o 上記以外の既存の要求または応答の構造に対する変更。
o Addition of previously unspecified RPC procedures for either the NFSv4 program or the callback program.
o NFSv4プログラムまたはコールバックプログラムのいずれかに対する、以前は指定されていなかったRPCプロシージャの追加。
o Deletion of existing RPC procedures, operation codes, enum values, flag bit values, and switch cases. Note that changes may be made to define use of any of these as causing an error, as long as the XDR is unaffected. Similarly, none of these items may be reused for a new purpose.
o 既存のRPCプロシージャ、オペレーションコード、列挙値、フラグビット値、スイッチケースの削除。 XDRに影響がない限り、これらの使用をエラーの原因として定義するように変更を加えることができます。同様に、これらのアイテムを新しい目的で再利用することもできません。
Implementations handle protocol elements received in requests and callbacks in one of three ways. Which of the following ways are valid depends on the status of the protocol element in the variant being implemented:
実装では、リクエストとコールバックで受信したプロトコル要素を3つの方法のいずれかで処理します。次のどの方法が有効であるかは、実装されるバリアントのプロトコル要素のステータスによって異なります。
o The protocol element is not a part of definition of the variant in question and so is "unknown". The responder, when it does not report an RPC XDR decode error, reports an error indicative of the element not being defined in the XDR such as NFS4ERR_OP_ILLEGAL, NFS4ERR_BADXDR, or NFS4ERR_INVAL. See Section 4.4.3 for details.
o プロトコル要素は、問題のバリアントの定義の一部ではないため、「不明」です。レスポンダは、RPC XDRデコードエラーを報告しない場合、NFS4ERR_OP_ILLEGAL、NFS4ERR_BADXDR、NFS4ERR_INVALなどのXDRで定義されていない要素を示すエラーを報告します。詳細については、セクション4.4.3を参照してください。
o The protocol element is a known part of the variant but is not supported by the particular implementation. The responder reports an error indicative of the element being recognized as one which is not supported such as NFS4ERR_NOTSUPP, NFS4ERR_UNION_NOTSUPP, or NFS4ERR_ATTRNOTSUPP.
o プロトコル要素はバリアントの既知の部分ですが、特定の実装ではサポートされていません。レスポンダは、NFS4ERR_NOTSUPP、NFS4ERR_UNION_NOTSUPP、NFS4ERR_ATTRNOTSUPPなど、サポートされていないものとして認識されている要素を示すエラーを報告します。
o The protocol element is a known part of the variant that is supported by the particular implementation. The responder reports success or an error other than the special ones discussed above.
o プロトコル要素は、特定の実装によってサポートされるバリアントの既知の部分です。レスポンダは、上記の特別なもの以外の成功またはエラーを報告します。
Which of these are validly returned by the responder depends on the status of the protocol element in the minor version specified in the COMPOUND or CB_COMPOUND. The possibilities that can exist when dealing with minor versions that have not been subject to corrections are listed below. See Sections 9.1 and 9.3 for a discussion of the effects of protocol correction.
これらのうちどれがレスポンダによって有効に返されるかは、COMPOUNDまたはCB_COMPOUNDで指定されたマイナーバージョンのプロトコル要素のステータスによって異なります。修正の対象となっていないマイナーバージョンを処理するときに存在する可能性がある可能性を以下に示します。プロトコル修正の影響については、セクション9.1および9.3を参照してください。
o The protocol element is not known in the minor version. In this case, all implementations of the minor version MUST indicate that the protocol element is not known.
o プロトコル要素は、マイナーバージョンでは不明です。この場合、マイナーバージョンのすべての実装は、プロトコル要素が不明であることを示す必要があります。
o The protocol element is part of a feature specified as mandatory to not implement in the minor version. In this case as well, all implementations of the minor version MUST indicate that the protocol element is not known.
o プロトコル要素は、マイナーバージョンに実装しないように必須として指定された機能の一部です。この場合も、マイナーバージョンのすべての実装は、プロトコル要素が不明であることを示す必要があります。
o The protocol element is defined as part of the current variant of the minor version but is not part of the corresponding base variant. In this case, the requester can encounter situations in which the protocol element is either not known to the responder, is known to but not supported by the responder, or is both known to and supported by the responder.
o プロトコル要素は、マイナーバージョンの現在のバリアントの一部として定義されていますが、対応するベースバリアントの一部ではありません。この場合、リクエスターは、プロトコル要素がレスポンダーに知られていない、レスポンダーに認識されているがサポートされていない、またはレスポンダーに認識されてサポートされている状況に遭遇する可能性があります。
o The protocol element is defined as an OPTIONAL part of the base minor version. In this case, the requester can expect the protocol element to be known but must deal with cases in which it is supported or is not supported.
o プロトコル要素は、ベースマイナーバージョンのオプションの部分として定義されます。この場合、リクエスタはプロトコル要素が既知であることを期待できますが、それがサポートされている場合またはサポートされていない場合に対処する必要があります。
o The protocol element is defined as a REQUIRED part of the base minor version. In this case, the requester can expect the protocol element to be both known and supported by the responder.
o プロトコル要素は、ベースマイナーバージョンの必須部分として定義されます。この場合、リクエスタはプロトコル要素が既知であり、レスポンダによってサポートされていることを期待できます。
The listing of possibilities above does not mean that a requester always needs to be prepared for all such possibilities. Often, depending on the scope of the feature of which the protocol element is a part, handling of a previous request using the same or related protocol elements will allow the requester to be sure that certain of these possibilities cannot occur.
上記の可能性のリストは、リクエスタが常にそのようなすべての可能性に備える必要があることを意味するものではありません。多くの場合、プロトコル要素がその一部である機能の範囲に応じて、同じまたは関連するプロトコル要素を使用して以前の要求を処理することで、要求者はこれらの可能性の一部が発生しないことを確認できます。
Requesters, typically clients, may test for knowledge of, or support for, protocol elements as part of connection establishment. This may allow the requester to be aware of a responder's lack of knowledge of or support for problematic requests before they are actually used to affect user requests.
リクエスター（通常はクライアント）は、接続の確立の一環として、プロトコル要素の知識またはサポートをテストできます。これにより、リクエスターは、ユーザーリクエストに影響を与えるために実際に使用される前に、問題のあるリクエストについてのレスポンダーの知識不足またはサポートを認識できます。
Because of NFSv4's use of XDR extension, any communicating client and server versions have XDR definitions such that each is a valid extension of a third version. Once that version is determined, it may be used by both client and server to communicate. Each party can successfully use a subset of protocol elements that are both known to and supported by both parties.
NFSv4はXDR拡張を使用しているため、通信するクライアントとサーバーのバージョンにはXDR定義があり、それぞれが3番目のバージョンの有効な拡張です。そのバージョンが決定されると、クライアントとサーバーの両方が通信に使用できます。各当事者は、両方の当事者が認識してサポートしているプロトコル要素のサブセットを正常に使用できます。
With regard to requirements for knowledge of protocol elements, the following rules apply. These rules are the result of the use of the XDR extension paradigm combined with the way in which extensions are incorporated in existing minor versions (for details, see Section 6).
プロトコル要素の知識の要件に関しては、次のルールが適用されます。これらの規則は、XDR拡張パラダイムを使用して、拡張機能を既存のマイナーバージョンに組み込む方法と組み合わせた結果です（詳細については、セクション6を参照）。
o Any protocol element defined as part of the base variant of a particular minor version is required to be known by that minor version. This occurs whether the specification happens in the body of the minor definition document or is in a feature definition document that is made part of the minor version by being normatively referenced by the minor version definition document.
o 特定のマイナーバージョンのベースバリアントの一部として定義されているプロトコル要素は、そのマイナーバージョンで認識されている必要があります。これは、仕様がマイナー定義ドキュメントの本文で発生する場合でも、マイナーバージョン定義ドキュメントによって規範的に参照されることによってマイナーバージョンの一部となる機能定義ドキュメント内で発生する場合でも発生します。
o Any protocol element required to be known in a given minor version is required to be known in subsequent minor versions, unless and until a minor version has made that protocol element as mandatory to not implement.
o 特定のマイナーバージョンで既知であることが必要なプロトコル要素は、マイナーバージョンがそのプロトコル要素を実装しないように必須として指定しない限り、その後のマイナーバージョンで既知である必要があります。
o When a protocol element is defined as part of an extension to an extensible minor version, it is not required to be known in that minor version but is required to be known by the next minor version. In the earlier minor version, it might not be defined in the XDR definition document, while in the later version it needs to be defined in the XDR definition document. In either case, if it is defined, it might or might not be supported.
o プロトコル要素が拡張可能なマイナーバージョンの拡張の一部として定義されている場合、そのマイナーバージョンで認識される必要はありませんが、次のマイナーバージョンで認識される必要があります。以前のマイナーバージョンでは、XDR定義ドキュメントで定義されていない可能性がありますが、それ以降のバージョンでは、XDR定義ドキュメントで定義する必要があります。どちらの場合も、定義されていると、サポートされる場合とサポートされない場合があります。
o When knowledge of protocol elements is optional in a given minor version, the responder's knowledge of such optional elements must obey the rule that if one such element is known, then all the protocol elements defined in the same minor version definition document must be known as well.
o 特定のマイナーバージョンでプロトコル要素の知識がオプションである場合、そのようなオプション要素の応答者の知識は、そのような要素が1つ知られている場合、同じマイナーバージョン定義ドキュメントで定義されているすべてのプロトコル要素も知られている必要があるという規則に従う必要があります。 。
For many minor versions, all existing protocol elements are required to be known by both the client and the server, and so requesters do not have to test for the presence or absence of knowledge regarding protocol elements. This is the case if there has been no extension for the minor version in question. Extensions can be added to extensible minor versions as described in Section 6 and can be used to correct protocol flaws as described in Section 9.
多くのマイナーバージョンでは、既存のすべてのプロトコル要素がクライアントとサーバーの両方で認識されている必要があるため、リクエスターはプロトコル要素に関する知識の有無をテストする必要がありません。これは、問題のマイナーバージョンの拡張機能がない場合に当てはまります。セクション6で説明するように、拡張機能を拡張可能なマイナーバージョンに追加し、セクション9で説明するようにプロトコルの欠陥を修正するために使用できます。
Requesters can ascertain the knowledge of the responder in two ways:
リクエスタは、次の2つの方法でレスポンダの知識を確認できます。
o By issuing a request using the protocol element and looking at the response. Note that, even if the protocol element used is not supported by the responder, the requester can still determine if the element is known by the responder.
o プロトコル要素を使用して要求を発行し、応答を確認する。使用されるプロトコル要素がレスポンダによってサポートされていない場合でも、リクエスタは要素がレスポンダによって認識されているかどうかを判断できることに注意してください。
o By receiving a request from the responder, acting in the role of requester. For example, a client may issue a request enabling the server to infer that it is aware of a corresponding callback.
o レスポンダからリクエストを受け取り、リクエスタとして振る舞います。たとえば、クライアントは、サーバーが対応するコールバックを認識していることを推測できるようにする要求を発行する場合があります。
In making this determination, the requester can rely on two basic facts:
この決定を行う際、リクエスタは2つの基本的な事実に依存できます。
o If the responder is aware of a single protocol element within a feature package, it must be aware of all protocol elements within that feature package.
o レスポンダが機能パッケージ内の単一のプロトコル要素を認識している場合、レスポンダはその機能パッケージ内のすべてのプロトコル要素を認識している必要があります。
o If a protocol element is one defined by the minor version specified by a request (and not in an extension), or in a previous minor version, the responder must be aware of it.
o プロトコル要素が、リクエストで指定されたマイナーバージョンで定義されている（拡張機能ではない）、または以前のマイナーバージョンである場合、レスポンダはそれを認識する必要があります。
When a client and a server interact, they need to able to take advantage of the compatibility provided by NFSv4's use of XDR extension.
クライアントとサーバーが相互作用する場合、NFSv4のXDR拡張の使用によって提供される互換性を利用できる必要があります。
In this context, the client and server would arrive at a common variant, which the client uses to send requests that the server would then accept. The server would use that variant to send callbacks that the client would then accept. This state of affairs could arise in a number of ways:
このコンテキストでは、クライアントとサーバーは共通のバリアントに到達し、クライアントはこれを使用して、サーバーが受け入れる要求を送信します。サーバーはそのバリアントを使用して、クライアントが受け入れるコールバックを送信します。この状況は、いくつかの方法で発生する可能性があります。
o Client and server have been built using XDR variants that belong to the same minor version.
o クライアントとサーバーは、同じマイナーバージョンに属するXDRバリアントを使用して構築されています。
o The client's minor version is lower than that of the server. In this case the server, in accord with Section 8.2, accepts the client's minor version, and acts as if it has no knowledge of extensions made in subsequent minor versions. It has knowledge of protocol elements within the current (i.e., effectively final) variant of the lower minor version.
o クライアントのマイナーバージョンはサーバーのマイナーバージョンよりも低くなっています。この場合、サーバーはセクション8.2に従い、クライアントのマイナーバージョンを受け入れ、後続のマイナーバージョンで作成された拡張機能を認識していないかのように動作します。下位のマイナーバージョンの現在の（つまり、事実上最終的な）バリアント内のプロトコル要素の知識があります。
o The client's minor version is higher than that of the server. In this case the client, in accord with Section 8.2, uses a lower minor version that the server will accept. In this case, the server has no knowledge of extensions made in subsequent minor versions.
o クライアントのマイナーバージョンがサーバーのマイナーバージョンより高いです。この場合、クライアントはセクション8.2に従い、サーバーが受け入れる下位のマイナーバージョンを使用します。この場合、サーバーは後続のマイナーバージョンで作成された拡張機能を認識しません。
There are a number of cases to consider based on the characteristics of the minor version chosen.
選択したマイナーバージョンの特性に基づいて検討する必要のあるケースがいくつかあります。
o When the minor version consists of only a single variant (no extension or XDR corrections), the client and the server are using the same XDR description and have knowledge of the same protocol elements.
o マイナーバージョンが単一のバリアントのみで構成されている場合（拡張機能やXDR修正なし）、クライアントとサーバーは同じXDR記述を使用しており、同じプロトコル要素の知識を持っています。
o When the minor version consists of multiple variants (i.e., there are one or more XDR extensions or XDR corrections), the client and the server are using compatible XDR descriptions. The client is aware of some set of extensions while the server may be aware of a different set. The client can use the approach described in Section 4.4.3 to determine which of the extensions it knows about are also known by the server. Once this is done, the client and server will both be using a common variant. The variants that the client and the server were built with will both either be identical to this variant or a valid extension of it. Similarly, the variants that the client and the server actually use will be a subset of this variant, in that certain OPTIONAL features will not be used.
o マイナーバージョンが複数のバリアントで構成されている場合（つまり、1つ以上のXDR拡張またはXDR修正がある場合）、クライアントとサーバーは互換性のあるXDR記述を使用しています。クライアントはいくつかの拡張セットを認識していますが、サーバーは別のセットを認識している場合があります。クライアントは、セクション4.4.3で説明されているアプローチを使用して、サーバーが認識している拡張機能を判別できます。これが完了すると、クライアントとサーバーの両方で共通のバリアントが使用されます。クライアントとサーバーが構築されたバリアントは、どちらもこのバリアントと同じか、またはその有効な拡張です。同様に、クライアントとサーバーが実際に使用するバリアントは、このバリアントのサブセットとなり、特定のオプション機能は使用されません。
In either case, the client must determine which of the OPTIONAL protocol elements within the common version are supported by the server, just as it does for OPTIONAL features introduced as part of a minor version.
どちらの場合でも、クライアントは、マイナーバージョンの一部として導入されたOPTIONAL機能の場合と同様に、共通バージョン内のどのOPTIONALプロトコル要素がサーバーによってサポートされるかを決定する必要があります。
It is best if client implementations make the determination as to the support provided by the server before acting on user requests. This includes the determination of the common protocol variant and the level of support for OPTIONAL protocol elements.
クライアントの実装が、ユーザーの要求に応じる前に、サーバーが提供するサポートに関して決定を下すことが最善です。これには、一般的なプロトコルバリアントの決定と、OPTIONALプロトコルエレメントのサポートレベルが含まれます。
A requester may test the responder's knowledge of particular protocol elements as defined below, based on the type of protocol element. Note that in the case of attribute or flag bits, use of a request that refers to 2 or more bits of undetermined status ("known" versus "unknown") may return results that are not particularly helpful. In such cases, when the response is NFS4ERR_INVAL, the requester can only conclude that at least one of the bits is unknown.
リクエスタは、プロトコル要素のタイプに基づいて、以下に定義されている特定のプロトコル要素に関するレスポンダの知識をテストできます。属性ビットまたはフラグビットの場合、未確定ステータス（「既知」と「不明」）の2ビット以上を参照するリクエストを使用すると、特に役に立たない結果が返される場合があることに注意してください。このような場合、応答がNFS4ERR_INVALのとき、リクエスターは少なくとも1つのビットが不明であると結論付けることができます。
o When a GETATTR request is made specifying an attribute bit to be tested and that attribute is not a set-only attribute, if the GETATTR returns with the error NFS4ERR_INVAL, then it can be concluded that the responder has no knowledge of the attribute in question. Other responses, including NFS4ERR_ATTRNOTSUPP, indicate that the responder is aware of the attribute in question.
o テスト対象の属性ビットを指定してGETATTR要求が行われ、その属性がセットオンリー属性ではない場合、GETATTRがエラーNFS4ERR_INVALで戻る場合、レスポンダは問題の属性を認識していないと結論付けることができます。 NFS4ERR_ATTRNOTSUPPを含む他の応答は、レスポンダが問題の属性を認識していることを示しています。
o When a SETATTR request is made specifying the attribute bit to be tested and that attribute is not a get-only attribute, if the SETATTR returns with the error NFS4ERR_INVAL, then it can be concluded that the responder has no knowledge of the attribute in question. Other responses, including NFS4ERR_ATTRNOTSUPP, indicate that the responder is aware of the attribute in question.
o テストする属性ビットを指定してSETATTR要求が行われ、その属性が取得専用属性でない場合、SETATTRがエラーNFS4ERR_INVALを返した場合、レスポンダは問題の属性を認識していないと結論付けることができます。 NFS4ERR_ATTRNOTSUPPを含む他の応答は、レスポンダが問題の属性を認識していることを示しています。
o When a request is made including an operation with a new flag bit, if the operation returns with the error NFS4ERR_INVAL, then it can generally be concluded that the responder has no knowledge of the flag bit in question, as long as the requester is careful to avoid other error situations in which the operation in question is defined as returning NFS4ERR_INVAL. Other responses indicate that the responder is aware of the flag bit in question.
o 新しいフラグビットを使用した操作を含む要求が行われたときに、操作がエラーNFS4ERR_INVALで返された場合、通常、リクエスターが注意を払っている限り、レスポンダーは問題のフラグビットを認識していないと結論付けることができます。問題の操作がNFS4ERR_INVALを返すと定義されている他のエラー状況を回避します。他の応答は、応答側が問題のフラグビットを認識していることを示します。
o When a request is made including the operation to be tested, if the responder returns an RPC XDR decode error, or a response indicating that the operation in question resulted in NFS4ERR_OP_ILLEGAL or NFS4ERR_BADXDR, then it can be concluded that the responder has no knowledge of the operation in question. Other responses, including NFS4ERR_NOTSUPP, indicate that the responder is aware of the operation in question.
o テストする操作を含む要求が行われたときに、レスポンダがRPC XDRデコードエラーを返した場合、または問題の操作がNFS4ERR_OP_ILLEGALまたはNFS4ERR_BADXDRになったことを示す応答が返された場合、レスポンダは応答を認識していないと結論付けることができます。問題の操作。 NFS4ERR_NOTSUPPを含む他の応答は、応答側が問題の操作を認識していることを示しています。
o When a request is made including the switch arm to be tested, if the responder returns an RPC XDR decode error, or a response indicating that the operation in question resulted in NFS4ERR_BADXDR, then it can be concluded that the responder has no knowledge of the operation in question. Other responses, including NFS4ERR_UNION_NOTSUPP, indicate that the responder is aware of the protocol element in question.
o テスト対象のスイッチアームを含む要求が行われたときに、レスポンダがRPC XDRデコードエラー、または問題の操作がNFS4ERR_BADXDRになったことを示す応答が返された場合、レスポンダは操作を認識していないと結論付けることができます。問題です。 NFS4ERR_UNION_NOTSUPPを含む他の応答は、応答側が問題のプロトコル要素を認識していることを示しています。
A determination of the knowledge or lack of knowledge of a particular protocol element is expected to remain valid as long as the clientid associated with the request remains valid.
特定のプロトコル要素の知識または知識の欠如の判定は、リクエストに関連付けられたクライアントIDが有効である限り、有効であると期待されます。
The above assumes, as should be the case, that the server will accept the minor version used by the client. For more detail regarding this issue, see Section 8.2.
上記は、当然のことながら、サーバーがクライアントによって使用されるマイナーバージョンを受け入れることを前提としています。この問題の詳細については、セクション8.2を参照してください。
XDR additions may also be made by defining XDR structures that overlay nominally opaque fields that are defined to allow such incremental extensions.
XDRの追加は、そのような増分拡張を許可するように定義された名目上不透明なフィールドをオーバーレイするXDR構造を定義することによっても行うことができます。
For example, each parallel NFS (pNFS) mapping type provides its own XDR definition for various pNFS-related fields defined in [RFC5661] as opaque arrays.
たとえば、各並列NFS（pNFS）マッピングタイプは、[RFC5661]で不透明な配列として定義されたさまざまなpNFS関連フィールドに独自のXDR定義を提供します。
Because such additions provide new interpretations of existing fields, they may be made outside of the extension framework as long as they obey the rules previously established when the nominally opaque protocol elements were added to the protocol.
そのような追加は既存のフィールドの新しい解釈を提供するので、名目上不透明なプロトコル要素がプロトコルに追加されたときに以前に確立されたルールに従う限り、それらは拡張フレームワークの外で作成できます。
There are a number of types of protocol changes that are outside the XDR extension framework discussed in Section 4. These changes are also managed within the NFSv4 versioning framework and may be of a number of types, which are discussed in the sections below.
セクション4で説明したXDR拡張フレームワークの範囲外のプロトコル変更にはいくつかのタイプがあります。これらの変更はNFSv4バージョン管理フレームワーク内でも管理され、以下のセクションで説明するいくつかのタイプである可能性があります。
Despite the previous emphasis on XDR changes, additions and changes to the NFSv4 protocols have not been limited to those that involve changes (in the form of extensions) to the protocol XDR. Examples of other sorts of changes have been taken from NFSv4.1.
これまでXDRの変更に重点を置いていましたが、NFSv4プロトコルへの追加と変更は、プロトコルXDRへの（拡張の形式での）変更を伴うものに限定されていません。他の種類の変更の例はNFSv4.1から取られました。
All such changes that have been made in the past have been made as part of new minor version. Future change of these sorts may not be done in an extension but can only be made in a new minor version.
過去に行われたそのような変更はすべて、新しいマイナーバージョンの一部として行われました。これらの種類の将来の変更は拡張機能では行われない可能性がありますが、新しいマイナーバージョンでのみ行うことができます。
The XDR description of a protocol does not constitute a complete description of the protocol. Therefore, versioning needs to consider the role of changes in the use of fields, even when there is no change to the underlying XDR.
プロトコルのXDR記述は、プロトコルの完全な記述ではありません。したがって、バージョン管理では、基になるXDRに変更がない場合でも、フィールドの使用における変更の役割を考慮する必要があります。
Although any XDR element is potentially subject to a change in its interpretation and use, the likelihood of such change will vary with the XDR-specified type of the element, as discussed below:
XDR要素はその解釈と使用が変更される可能性がありますが、そのような変更が発生する可能性は、以下で説明するように、XDRで指定された要素のタイプによって異なります。
o When XDR elements are defined as strings, rules regarding the appropriate string values are specified in protocol specification text with changes in such rules documented in minor version definition documents. Some types of strings within NFS4 are used in server names (in location-related attributes), user and group names, and in the names of file objects within directories. Rules regarding what strings are acceptable appear in [RFC7530] and [RFC5661] with the role of the XDR limited to hints regarding UTF-8 and capitalization issues via XDR typedefs.
o XDR要素が文字列として定義されている場合、適切な文字列値に関するルールはプロトコル仕様テキストで指定され、そのようなルールの変更はマイナーバージョン定義ドキュメントに記載されています。 NFS4内の一部のタイプのストリングは、サーバー名（ロケーション関連の属性）、ユーザー名およびグループ名、およびディレクトリー内のファイルオブジェクトの名前で使用されます。 [RFC7530]と[RFC5661]には、許容できる文字列に関するルールが記載されており、XDRの役割は、XDR typedefを介したUTF-8および大文字化の問題に関するヒントに限定されています。
o Fields that are XDR-defined as opaque elements and that are truly opaque, do not raise versioning issues, except as regards inter-version use, which is effectively foreclosed by the rules in Section 8.1.
o 不透明な要素としてXDRで定義され、本当に不透明なフィールドは、バージョン間の問題を引き起こしません。ただし、バージョン8.1の規則によって事実上排除されているバージョン間の使用に関する場合を除きます。
Note that sometimes a field will seem to be opaque but not actually be fully opaque when considered carefully. For example, the "other" field of stateids is defined as an opaque array, while the specification text specially defines appropriate treatment when the "other" field within it is either all zeros or all ones. Given this context, creation or deletion of reserved values for "special" stateids will be a protocol change that versioning rules need to deal with.
慎重に検討すると、フィールドは不透明に見えても実際には完全に不透明ではない場合があることに注意してください。たとえば、stateidsの「other」フィールドは不透明な配列として定義されますが、仕様テキストでは、「other」フィールドがすべてゼロまたはすべて1の場合の適切な処理が特別に定義されています。このコンテキストの場合、「特別な」stateidの予約値の作成または削除は、バージョン管理ルールが処理する必要のあるプロトコルの変更になります。
o Some nominally opaque elements have external XDR definitions that overlay the nominally opaque arrays. Such cases are discussed in Section 4.5.
o 一部の名目上不透明な要素には、名目上不透明な配列をオーバーレイする外部XDR定義があります。このようなケースについては、セクション4.5で説明します。
Changes in the behavior of NFSv4 operations are possible, even if there is no change in the underlying XDR or change to field interpretation and use.
基礎となるXDRに変更がない場合、またはフィールドの解釈と使用に変更がない場合でも、NFSv4操作の動作を変更することができます。
One class of behavioral change involves changes in the set of errors to be returned when various failure conditions occur. When the set of valid requests remain the same, and the behavior for each of them remains the same, such changes can be implemented with only limited disruption to existing clients.
動作の変更の1つのクラスには、さまざまな障害状態が発生したときに返される一連のエラーの変更が含まれます。有効なリクエストのセットが同じで、それぞれの動作が同じである場合、このような変更は、既存のクライアントへの中断を最小限に抑えて実装できます。
Many more substantial behavioral changes have occurred in connection with the addition of the session concept in NFSv4.1. Even though there was no change to the XDR for existing operations, many existing operations and COMPOUNDs consisting only of them became invalid.
NFSv4.1でのセッションの概念の追加に関連して、さらに多くの大幅な動作の変更が発生しました。既存の操作のXDRに変更はありませんでしたが、多くの既存の操作とそれらだけで構成されるCOMPOUNDは無効になりました。
Also, changes were made regarding the required server behavior as to the interaction of the MODE and Access Control List (ACL) attributes.
また、MODEとアクセス制御リスト（ACL）属性の相互作用に関して、必要なサーバーの動作に関して変更が加えられました。
Extensions to the most recently published NFSv4 minor version may be made by publishing the extension as a Proposed Standard, unless the minor version in question has been defined as non-extensible. A document need not use the "Updates" header specifying the RFC that defines the minor version, which remains a valid description of the base variant of the minor version in question.
問題のマイナーバージョンが非拡張可能として定義されていない限り、最近公開されたNFSv4マイナーバージョンへの拡張は、提案された標準としてエクステンションを公開することで作成できます。ドキュメントは、マイナーバージョンを定義するRFCを指定する "Updates"ヘッダーを使用する必要はありません。これは、問題のマイナーバージョンのベースバリアントの有効な説明のままです。
In addition to following the rules for XDR extensions in Section 4.2, such extensions must also obey the rules listed below in order to allow interoperability to be established, as described in Section 4.4:
セクション4.2のXDR拡張のルールに従うことに加えて、そのような拡張は、セクション4.4で説明されているように相互運用性を確立できるようにするために、以下にリストされているルールにも従う必要があります。
o Additions to the set of callback requests and extensions to the XDR for existing callback operations can only be made if the server can determine, based on the client's actions, that the client is aware of the changes. This determination, for any particular client (as defined by its clientid), is made before sending those new or extended callbacks.
o サーバーがクライアントのアクションに基づいてクライアントが変更を認識していると判断できる場合にのみ、一連のコールバック要求への追加と既存のコールバック操作のXDRへの拡張を行うことができます。特定のクライアント（clientidによって定義されている）のこの決定は、それらの新しいコールバックまたは拡張コールバックを送信する前に行われます。
o XDR extensions that affect the structures of responses to existing operations can only be made if the server can determine, based on the client's actions, that it is aware of the existence of XDR changes, before sending responses containing those extensions. This determination can be based on the request being responded to, but that is not required. Use of any protocol element defined in the extension can be the basis of the determination, provided that the requirements for determining client awareness are clearly stated.
o 既存の操作への応答の構造に影響を与えるXDR拡張機能は、サーバーがそれらの拡張機能を含む応答を送信する前に、クライアントのアクションに基づいて、XDR変更の存在を認識していると判断できる場合にのみ作成できます。この決定は、応答される要求に基づいて行うことができますが、これは必須ではありません。拡張機能で定義されているプロトコル要素の使用は、クライアントの認識を決定するための要件が明確に述べられている限り、決定の基礎となります。
Corrections to protocol errors (see Section 9) may be accomplished by publishing an extension, including a compatible XDR change that follows the rules above. Such documents will update the defining documents for the minor version to be corrected.
プロトコルエラー（セクション9を参照）の修正は、上記のルールに従う互換性のあるXDR変更を含む拡張機能を公開することで達成できます。そのようなドキュメントは、修正されるマイナーバージョンの定義ドキュメントを更新します。
In some cases, extensions will contain elements such as new operations or previously invalid switch cases. Although it is possible to determine whether these OPTIONAL elements are supported using the rules described above, those defining an extension that contains such elements have the choice of defining a new attribute that indicates whether the feature is present and supported. Since it is easy to determine whether a new attribute is supported using the supported_attrs attribute, this can make it simple and convenient for clients to determine whether support is present, particularly when a feature involves support for multiple such elements.
拡張機能には、新しい操作や以前は無効だったスイッチケースなどの要素が含まれる場合があります。これらのOPTIONAL要素が上記のルールを使用してサポートされているかどうかを判断することは可能ですが、そのような要素を含む拡張機能を定義するものには、機能が存在しサポートされているかどうかを示す新しい属性を定義する選択肢があります。 supported_attrs属性を使用して新しい属性がサポートされているかどうかを判断するのは簡単なので、これにより、特に機能にそのような要素のサポートが含まれる場合に、クライアントがサポートが存在するかどうかを簡単に判断できます。
It is important to note that this section, in describing situations that would require new minor versions to be created, does not thereby imply that situations will exist in the future. Judgments regarding desirability of future changes will be made by the working group or its successors and any guidance that can be offered at this point is necessarily quite limited.
このセクションは、新しいマイナーバージョンを作成する必要がある状況を説明する際に、状況が将来存在することを意味するものではないことに注意することが重要です。将来の変更の望ましさに関する判断は、ワーキンググループまたはその後継者によって行われ、この時点で提供できるガイダンスは必然的にかなり制限されます。
Creation of a new minor version is an option that the working group retains. The listing of situations below that would prompt such actions is not meant to be exhaustive.
新しいマイナーバージョンの作成は、ワーキンググループが保持するオプションです。そのようなアクションを促す以下の状況のリストは、すべてを網羅しているわけではありません。
The following sorts of features are not allowed as extensions and would require creation of a new minor version:
次の種類の機能は拡張機能として許可されておらず、新しいマイナーバージョンの作成が必要になります。
o Features that incorporate any of the non-XDR-based changes discussed in Sections 5.1 and 5.2.
o セクション5.1および5.2で説明されている非XDRベースの変更を組み込んだ機能。
o Features whose XDR changes do not follow the rules in Section 6.
o XDRの変更がセクション6のルールに従っていない機能。
o Addition of REQUIRED new features.
o 必要な新機能の追加。
o Changes to the status of existing features including converting features to be mandatory to not implement.
o 実装しないために必須となる機能の変換を含む、既存の機能のステータスの変更。
This section addresses issues related to rules #11 and #13 in the minor versioning rules in [RFC5661]. With regard to the supersession of minor versioning rules, the treatment here overrides that in [RFC5661] when either of the potentially interacting minor versions has not yet been published as a Proposed Standard.
このセクションでは、[RFC5661]のマイナーバージョン管理ルールのルール＃11および＃13に関連する問題を扱います。マイナーバージョニングルールの置換に関して、相互作用する可能性のあるマイナーバージョンのいずれかが提案された標準としてまだ公開されていない場合、ここでの扱いは[RFC5661]でのそれを上書きします。
Note that these rules are the only ones directed to minor version implementers, rather than to those specifying new minor versions.
これらのルールは、新しいマイナーバージョンを指定するルールではなく、マイナーバージョンの実装者に向けられた唯一のルールであることに注意してください。
Each relationship between a client instance and a server instance, as represented by a clientid, is to be devoted to a single minor version. If a server detects that a COMPOUND with an inappropriate minor version is being used, it MUST reject the request. In doing so, it may return either NFS4ERR_BAD_CLIENTID or NFS4RR_MINOR_VERS_MISMATCH.
clientidで表されるクライアントインスタンスとサーバーインスタンス間の各関係は、単一のマイナーバージョンに割り当てられます。サーバーが不適切なマイナーバージョンのCOMPOUNDが使用されていることを検出した場合、サーバーは要求を拒否する必要があります。その際、NFS4ERR_BAD_CLIENTIDまたはNFS4RR_MINOR_VERS_MISMATCHが返される場合があります。
As a result of the above, the client has the assurance that the set of REQUIRED and OPTIONAL features will not change within the context of a single clientid. Server implementations MUST ensure that the set of supported features and protocol elements does not change within such a context.
上記の結果として、クライアントは、REQUIREDおよびOPTIONAL機能のセットが単一のclientidのコンテキスト内で変更されないことを保証します。サーバー実装は、サポートされる機能とプロトコル要素のセットがそのようなコンテキスト内で変更されないことを保証しなければなりません（MUST）。
The goal of the NFSv4 extension model is to enable compatibility including compatibility between clients and servers implementing different minor versions.
NFSv4拡張モデルの目標は、異なるマイナーバージョンを実装するクライアントとサーバー間の互換性を含む互換性を有効にすることです。
Within a set of minor versions that define the same set of features as REQUIRED and mandatory to not implement, it is relatively easy for clients and servers to provide the needed compatibility by adhering to the following practices:
REQUIREDと同じ機能のセットを定義し、実装しないことを必須とするマイナーバージョンのセット内では、クライアントとサーバーが次のプラクティスに従うことにより、必要な互換性を比較的簡単に提供できます。
o Servers supporting a given minor version should support earlier minor versions within that set and return appropriate errors for use of protocol elements that were not a valid part of that earlier minor version. For details, see below.
o 特定のマイナーバージョンをサポートするサーバーは、そのセット内の以前のマイナーバージョンをサポートし、その以前のマイナーバージョンの有効な部分ではなかったプロトコル要素の使用に対して適切なエラーを返す必要があります。詳細は以下をご覧ください。
o Clients should deal with an NFS4ERR_MINOR_VERS_MISMATCH error by searching for a lower minor version number that the server will accept.
o クライアントは、サーバーが受け入れるより小さなマイナーバージョン番号を検索して、NFS4ERR_MINOR_VERS_MISMATCHエラーに対処する必要があります。
Servers supporting a given minor version MUST, in returning errors for operations that were a valid part of the minor version, return the errors allowed for the current operation in the minor version actually being used.
特定のマイナーバージョンをサポートするサーバーは、マイナーバージョンの有効な部分であった操作のエラーを返す際に、実際に使用されているマイナーバージョンの現在の操作で許可されているエラーを返す必要があります。
With regard to protocol elements not known in a given minor version, the appropriate error codes are given below. Essentially, the server, although it has a more extensive XDR reflective of a newer minor version, must act as a server with a more limited XDR would.
特定のマイナーバージョンで知られていないプロトコル要素に関して、適切なエラーコードを以下に示します。基本的に、サーバーは、新しいマイナーバージョンを反映したより広範なXDRを備えていますが、より限定的なXDRを持つサーバーとして機能する必要があります。
o When an operation is used that is not known in the specified minor version, NFS4ERR_OP_ILLEGAL (as opposed to NFS4ERR_NOTSUPP) should be returned.
o 指定されたマイナーバージョンで認識されていない操作を使用すると、NFS4ERR_OP_ILLEGAL（NFS4ERR_NOTSUPPではなく）が返されます。
o When an attribute is used that is not known in the specified minor version, NFS4ERR_INVAL (as opposed to NFS4ERR_ATTRNOTSUPP) should be returned.
o 指定されたマイナーバージョンで認識されていない属性が使用されている場合は、NFS4ERR_ATTRNOTSUPPではなく、NFS4ERR_INVALが返されます。
o When a switch case is used that is not known in the specified minor version, NFS4ERR_BADXDR (as opposed to NFS4ERR_UNION_NOTSUPP) should be returned. Even though the message may be XDR-decodable by the server's current XDR, it is not so according to the minor version being used.
o 指定されたマイナーバージョンでは不明なスイッチケースが使用されている場合、NFS4ERR_BADXDR（NFS4ERR_UNION_NOTSUPPではなく）が返されます。メッセージはサーバーの現在のXDRによってXDRデコード可能である可能性がありますが、使用されているマイナーバージョンによってはそうではありません。
o When a flag bit is used that is not known in the specified minor version, NFS4ERR_INVAL (as opposed to NFS4ERR_NOTSUPP or any other error defined as indicating non-support of a flag bit) should be returned.
o 指定されたマイナーバージョンで認識されていないフラグビットが使用された場合、NFS4ERR_INVAL（NFS4ERR_NOTSUPPまたはフラグビットがサポートされていないことを示すと定義されたその他のエラーとは対照的に）が返されます。
The possibility always exists that there will be a need to correct an existing feature in some way after the acceptance of that feature, or a minor version containing it, as a Proposed Standard. While the working group can reduce the probability of such situations arising by waiting for running code before considering a feature as done, it cannot reduce the probability to zero. As features are used more extensively and interact with other features, previously unseen flaws may be discovered and will need to be corrected.
提案された標準として、その機能またはそれを含むマイナーバージョンを受け入れた後、何らかの方法で既存の機能を修正する必要がある可能性は常に存在します。ワーキンググループは、機能が完了したと見なす前にコードの実行を待機することで、このような状況が発生する確率を減らすことができますが、確率をゼロにすることはできません。機能がより広範囲に使用され、他の機能と相互作用するようになると、以前には見られなかった欠陥が発見される可能性があり、修正する必要があります。
Such corrections are best done in a document obsoleting or updating the RFC defining the relevant feature or minor version. In making such corrections, the working group will have to carefully consider how to assure interoperability with older clients and servers.
このような修正は、関連する機能またはマイナーバージョンを定義するRFCを廃止または更新するドキュメントで行うのが最適です。このような修正を行う場合、ワーキンググループは、古いクライアントやサーバーとの相互運用性を保証する方法を慎重に検討する必要があります。
Often, corrections can be done without changing the protocol XDR. In many cases, a change in client and server behavior can be implemented without taking special provision with regard to interoperability with earlier implementations. In those cases, and in cases in which a revision merely clarifies an earlier protocol definition document, a new document can be published that simply updates the earlier protocol definition document.
多くの場合、プロトコルXDRを変更せずに修正を行うことができます。多くの場合、クライアントとサーバーの動作の変更は、以前の実装との相互運用性に関して特別な対策を講じなくても実装できます。それらの場合、および改訂が以前のプロトコル定義文書を明らかにするだけの場合、以前のプロトコル定義文書を単に更新する新しい文書を発行することができます。
In other cases, it is best if client or server behavior needs to change in a way that raises interoperability concerns. In such cases, incompatible changes in server or client behavior should not be mandated in order to avoid XDR changes.
他の場合では、相互運用性の懸念を引き起こすような方法でクライアントまたはサーバーの動作を変更する必要がある場合に最適です。このような場合、XDRの変更を回避するために、サーバーまたはクライアントの動作に互換性のない変更を強制しないでください。
When XDR changes are necessary as part of correcting a flaw, these should be done in a manner similar to that used when implementing new minor versions or features within them. In particular:
欠陥の修正の一環としてXDRの変更が必要な場合は、それらに新しいマイナーバージョンまたは機能を実装するときに使用される方法と同様の方法で行う必要があります。特に：
o Existing XDR structures may not be modified or deleted.
o 既存のXDR構造は変更または削除できません。
o XDR extensions may be used to correct existing protocol facilities in a manner similar to those used to add additional optional features. Such corrections may be done in a minor version for which optional features may no longer be added, if the working group decides that it is an appropriate way to compatibly effect a correction.
o XDR拡張機能は、追加のオプション機能を追加するために使用されるものと同様の方法で、既存のプロトコル機能を修正するために使用できます。このような修正は、ワーキンググループが修正を互換的に実行する適切な方法であると判断した場合、オプション機能を追加できないマイナーバージョンで行うことができます。
o When a correction is made to an OPTIONAL feature, the result is similar to a situation in which there are two independent OPTIONAL features. A server may choose to implement either or both. See Section 9.2 for a detailed discussion of interoperability issues.
o OPTIONAL機能が修正されると、結果は2つの独立したOPTIONAL機能がある状況に似ています。サーバーは、いずれかまたは両方を実装することを選択できます。相互運用性の問題の詳細については、セクション9.2を参照してください。
o When a correction is made to a REQUIRED feature, the situation becomes one in which the old version of the feature remains REQUIRED while the corrected version, while OPTIONAL, is intended to be adopted to provide correct operation. Although use of the corrected version is ultimately better and may be recommended, it should not be described as "RECOMMENDED" since the choice of versions to support will depend on the needs of clients, which may be slow to adopt the updated version. The nature of such corrections is such that it may result in situations in which different variants of the same minor version may not both support the corrected version. See Section 9.3 for details.
o REQUIRED機能に修正を加えると、修正されたバージョンはOPTIONALであるが、正しい操作を提供するために採用されることが意図されている一方で、機能の古いバージョンがREQUIREDのままである状況になります。修正されたバージョンを使用する方が最終的には適切であり、推奨される場合がありますが、サポートするバージョンの選択はクライアントのニーズに依存するため、「推奨」とは記述しないでください。このような修正の性質上、同じマイナーバージョンの異なるバリアントが両方とも修正バージョンをサポートしていない場合があります。詳細については、9.3項を参照してください。
o In all of the cases above, it is appropriate that the old version of the feature be considered obsolescent, with the expectation that the working group might, in a later minor version, change the status of the uncorrected version. See Section 9.4 for more detail.
o 上記のすべてのケースで、古いバージョンの機能は廃止されていると見なすことが適切であり、ワーキンググループが後のマイナーバージョンで未修正バージョンのステータスを変更する可能性があります。詳細については、セクション9.4を参照してください。
By defining the corrected and uncorrected version as independent OPTIONAL features, the protocol with the XDR modification can accommodate clients and servers that support either the corrected or the uncorrected version of the protocol, and also clients and servers aware of and capable of supporting both alternatives.
修正バージョンと未修正バージョンを独立したオプションの機能として定義することにより、XDR変更を伴うプロトコルは、プロトコルの修正バージョンまたは未修正バージョンのいずれかをサポートするクライアントとサーバー、および両方の選択肢を認識してサポートできるクライアントとサーバーに対応できます。
Based on the type of client:
クライアントのタイプに基づいて：
o A client that uses only the earlier version of the feature (i.e., an older unfixed client) can determine whether the server it is connecting to supports the older version of feature. It is capable of interoperating with older servers that support only the unfixed protocol as well as ones that support both versions.
o 以前のバージョンの機能のみを使用するクライアント（つまり、古い未修正のクライアント）は、接続先のサーバーが古いバージョンの機能をサポートしているかどうかを判別できます。固定されていないプロトコルのみをサポートする古いサーバーや、両方のバージョンをサポートするサーバーと相互運用できます。
o A client that supports only the corrected version of the feature (i.e., a new or updated client) can determine whether the server it is connecting to supports the newer version of the feature. It is capable of interoperating with newer servers that support only the updated feature as well as ones that support both versions.
o 機能の修正されたバージョンのみをサポートするクライアント（つまり、新しいクライアントまたは更新されたクライアント）は、接続先のサーバーが機能の新しいバージョンをサポートしているかどうかを判別できます。更新された機能だけをサポートする新しいサーバーと、両方のバージョンをサポートするサーバーとの相互運用が可能です。
o A client that supports both the older and newer version of the feature can determine which version of the particular feature is supported by the server it is working with.
o 機能の古いバージョンと新しいバージョンの両方をサポートするクライアントは、操作しているサーバーがサポートしている特定の機能のバージョンを判別できます。
Based on the type of server:
サーバーのタイプに基づく：
o A server that supports only the earlier version of the feature (i.e., an older unfixed server) can only successfully interoperate with clients implementing the older version. However, clients that do not implement the older version of the feature can easily determine that the feature cannot be used on that server.
o 以前のバージョンの機能のみをサポートするサーバー（つまり、古い未修正サーバー）は、古いバージョンを実装しているクライアントとのみ正常に相互運用できます。ただし、古いバージョンの機能を実装していないクライアントは、その機能がそのサーバーで使用できないことを簡単に判断できます。
o A server that supports only the newer version of the feature (i.e., a new or updated server) can only successfully interoperate with newer clients. However, older clients can easily determine that the feature cannot be used on that server. In the case of OPTIONAL features, clients can be expected to deal with non-support of that particular feature.
o 新しいバージョンの機能のみをサポートするサーバー（つまり、新しいサーバーまたは更新されたサーバー）は、新しいクライアントと正常に相互運用することしかできません。ただし、古いクライアントは、そのサーバーで機能を使用できないことを簡単に判断できます。 OPTIONAL機能の場合、クライアントはその特定の機能の非サポートに対処することが期待できます。
o A server that supports both the older and newer versions of the feature can interoperate with all client variants.
o 機能の古いバージョンと新しいバージョンの両方をサポートするサーバーは、すべてのクライアントバリアントと相互運用できます。
By using extensions in this manner, the protocol creates a clear path that preserves the functioning of existing clients and servers and allows client and server implementers to adopt the new version of the feature at a reasonable pace.
この方法で拡張機能を使用することにより、プロトコルは、既存のクライアントとサーバーの機能を維持する明確なパスを作成し、クライアントとサーバーの実装者が適切なペースで新しいバージョンの機能を採用できるようにします。
Interoperability issues in this case are similar to those for the OPTIONAL case described above (in Section 9.2). However, because the use of the uncorrected version is REQUIRED, servers have to support this until there is a minor version change. Nevertheless, there is the opportunity for clients and servers to implement the corrected version, while maintaining necessary interoperability with earlier implementations.
この場合の相互運用性の問題は、上記で説明したOPTIONALの場合（9.2項）と同様です。ただし、未修正バージョンを使用する必要があるため、マイナーバージョンが変更されるまで、サーバーはこれをサポートする必要があります。それにもかかわらず、以前の実装との必要な相互運用性を維持しながら、クライアントとサーバーが修正されたバージョンを実装する機会があります。
The following types of servers can exist:
次のタイプのサーバーが存在する可能性があります。
o Servers only aware of and supporting the uncorrected version, such as servers developed before the issue requiring correction was known.
o 修正が必要な問題が判明する前に開発されたサーバーなど、修正されていないバージョンのみを認識してサポートするサーバー。
o Servers aware of both versions while only supporting the uncorrected version.
o サーバーは両方のバージョンを認識し、修正されていないバージョンのみをサポートします。
o Servers aware of and supporting both versions.
o 両方のバージョンを認識してサポートするサーバー。
With the exception of clients that do not use the feature in question, the following sorts of clients may exist:
問題の機能を使用しないクライアントを除いて、次の種類のクライアントが存在する可能性があります。
o Clients only aware of and prepared to use the uncorrected version, such as those developed before the issue requiring correction was known.
o クライアントは、修正が必要な問題が判明する前に開発されたバージョンなど、修正されていないバージョンのみを認識して使用する準備をしました。
Clients developed before the correction was defined would be of this type. They would be capable of interoperating with all of the types of servers listed above, but could not use the corrected version.
修正が定義される前に開発されたクライアントはこのタイプになります。これらは、上記のすべてのタイプのサーバーと相互運用できますが、修正されたバージョンを使用できませんでした。
o Clients aware of both versions while only prepared to use the uncorrected version.
o クライアントは両方のバージョンを認識しているが、修正されていないバージョンを使用する準備だけをしている。
Some clients developed or modified after the correction was defined would be of this type, until they were modified to support the corrected version. They would also be capable of interoperating with all of the types of servers listed above, but could not use the corrected version.
修正が定義された後に開発または変更された一部のクライアントは、修正されたバージョンをサポートするように変更されるまで、このタイプになります。また、上記のすべてのタイプのサーバーと相互運用できますが、修正されたバージョンを使用できませんでした。
o Clients aware of and prepared to use either version.
o クライアントは、どちらかのバージョンを認識し、使用する準備をしました。
Such clients would be capable of interoperating with all of the types of servers listed above, and could use the corrected version with servers that supported it.
このようなクライアントは、上記のすべてのタイプのサーバーと相互運用でき、サポートされているサーバーで修正バージョンを使用できます。
o Clients aware of both versions while only prepared to use the newer, corrected version.
o クライアントは両方のバージョンを認識しているが、新しい、修正されたバージョンを使用する準備だけをしている。
Such clients would only be capable of interoperating with servers that supported the corrected version. With other types of servers, they could determine the absence of appropriate support at an early stage and treat the minor version in question as unsupported by the server. Such clients are only likely to be deployed when the majority of servers support the corrected version.
このようなクライアントは、修正されたバージョンをサポートするサーバーとのみ相互運用できます。他のタイプのサーバーでは、適切なサポートがないことを早い段階で判断し、問題のマイナーバージョンをサーバーでサポートされていないものとして扱うことができます。このようなクライアントは、サーバーの大部分が修正されたバージョンをサポートしている場合にのみ展開される可能性があります。
As described in Sections 9.2 and 9.3, a corrected XDR can be incorporated in an existing minor version and be used, while an existing uncorrected version is still supported. Nevertheless, the uncorrected version will remain part of the protocol until its status is changed in a later minor version.
セクション9.2および9.3で説明されているように、既存の未修正バージョンは引き続きサポートされますが、修正済みのXDRを既存のマイナーバージョンに組み込んで使用できます。それでも、修正されていないバージョンは、後のマイナーバージョンでステータスが変更されるまで、プロトコルの一部として残ります。
One possible change that could be made in a later minor version is to define the uncorrected version as mandatory to not implement. Because of the difficulty of determining that no clients depend on support for the uncorrected version, it is unlikely that this step would be appropriate for a considerable time.
後のマイナーバージョンで行われる可能性のある1つの変更は、未修正バージョンを実装しないように必須として定義することです。修正されていないバージョンのサポートに依存しているクライアントがないと判断するのが難しいため、この手順がかなりの期間適切であるとは考えられません。
In the case of a correction to a REQUIRED feature, there are a number of less disruptive changes that could be made earlier:
REQUIRED機能を修正する場合、以前に行う可能性のある、中断の少ない変更がいくつかあります。
o Changing the uncorrected version from REQUIRED to OPTIONAL while REQUIRING that servers support at least one of the two versions.
o サーバーが2つのバージョンのうち少なくとも1つをサポートすることを要求している間に、未修正バージョンをREQUIREDからOPTIONALに変更する。
This would allow new server implementations to avoid support for the uncorrected version.
これにより、新しいサーバーの実装で未修正バージョンのサポートを回避できます。
o Changing the corrected version from OPTIONAL to REQUIRED, making both versions REQUIRED.
o 修正されたバージョンをOPTIONALからREQUIREDに変更し、両方のバージョンをREQUIREDにします。
This would allow new clients to depend on support for the corrected version being present.
これにより、新しいクライアントは、存在する修正バージョンのサポートに依存できます。
o Changing the uncorrected version from REQUIRED to OPTIONAL while changing the corrected version from OPTIONAL to REQUIRED.
o 修正されたバージョンをOPTIONALからREQUIREDに変更しながら、修正されていないバージョンをREQUIREDからOPTIONALに変更します。
This would complete the shift to the corrected version once clients are prepared to use the corrected version.
これにより、クライアントが修正バージョンを使用する準備が整うと、修正バージョンへの移行が完了します。
In making such changes, interoperability issues would need to be carefully considered.
このような変更を行う場合、相互運用性の問題を慎重に検討する必要があります。
Since no substantive protocol changes are proposed here, no security considerations apply.
ここではプロトコルの実質的な変更は提案されていないため、セキュリティに関する考慮事項は適用されません。
The current document does not require any IANA actions.
現在のドキュメントでは、IANAアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>.
[RFC5661] Shepler、S.、Ed。、Eisler、M.、Ed。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、RFC 5661、DOI 10.17487 / RFC5661、 2010年1月、<http://www.rfc-editor.org/info/rfc5661>。
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]ヘインズ、T。、エド。およびD. Noveck編、「Network File System（NFS）Version 4 Protocol」、RFC 7530、DOI 10.17487 / RFC7530、2015年3月、<http://www.rfc-editor.org/info/rfc7530>。
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <http://www.rfc-editor.org/info/rfc7862>.
[RFC7862]ヘインズ、T。、「ネットワークファイルシステム（NFS）バージョン4マイナーバージョン2プロトコル」、RFC 7862、DOI 10.17487 / RFC7862、2016年11月、<http://www.rfc-editor.org/info/rfc7862 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, DOI 10.17487/RFC3530, April 2003, <http://www.rfc-editor.org/info/rfc3530>.
[RFC3530] Shepler、S.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、M。、およびD. Noveck、「Network File System（NFS）version 4 Protocol」、 RFC 3530、DOI 10.17487 / RFC3530、2003年4月、<http://www.rfc-editor.org/info/rfc3530>。
Acknowledgements
謝辞
The author wishes to thank Tom Haynes of Primary Data for his role in getting the effort to revise NFSV4 version management started and for his work in coauthoring the first draft version of this document.
著者は、NFSV4のバージョン管理を改訂するための取り組みを開始した彼の役割と、このドキュメントの最初のドラフトバージョンの共同執筆に尽力してくれたPrimary DataのTom Haynesに感謝します。
The author also wishes to thank Chuck Lever and Mike Kupfer of Oracle, and Bruce Fields of Red Hat for their helpful reviews of this and other versioning-related documents.
また、オラクルのチャックレバーとマイククプファー、およびレッドハットのブルースフィールズに、このドキュメントやその他のバージョン管理関連のドキュメントに関する有益なレビューを提供してくれたことにも感謝します。
Author's Address
著者のアドレス
David Noveck NetApp 1601 Trapelo Road Waltham, MA 02451 United States of America
David Noveck NetApp 1601 Trapelo Road Waltham、MA 02451アメリカ合衆国
Phone: +1 781 572 8038
Email: davenoveck@gmail.com