[要約] RFC 5024は、ODETTE File Transfer Protocol（OFTP）2.0の仕様を定義しています。OFTPは、業界間でのファイル転送を安全かつ効率的に行うためのプロトコルであり、このRFCはその目的と仕様を提供しています。
Network Working Group I. Friend
Request for Comments: 5024 ODETTE
Obsoletes: 2204 November 2007
Category: Informational
ODETTE File Transfer Protocol 2
Odetteファイル転送プロトコル2
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Abstract
概要
This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.
このメモは、トレーディングパートナー間のビジネスデータの交換を促進する確立されたファイル転送プロトコルであるOdetteファイル転送プロトコルをバージョン2に更新します。
The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.
このプロトコルは、トランスポートレイヤーセキュリティを使用してインターネットを介した安全で認証された通信をサポートし、暗号化メッセージの構文を使用してファイル暗号化、署名、および圧縮を提供し、受信したファイルの承認のための署名済みの領収書を提供します。
The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks.
このプロトコルは、付加価値ネットワークを介した直接的なピアツーピア通信と間接通信の両方をサポートし、TCP/IP、X.25、およびISDNベースのネットワークで使用できます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Background .................................................4
1.2. Summary of Features ........................................5
1.3. General Principles .........................................5
1.4. Structure ..................................................6
1.5. Virtual Files ..............................................6
1.6. Service Description ........................................9
1.7. Security ...................................................9
2. Network Service ................................................11
2.1. Introduction ..............................................11
2.2. Service Primitives ........................................11
2.3. Secure ODETTE-FTP Session .................................12
2.4. Port Assignment ...........................................12
3. File Transfer Service ..........................................13
3.1. Model .....................................................13
3.2. Session Setup .............................................14
3.3. File Transfer .............................................16
3.4. Session Take Down .........................................20
3.5. Service State Automata ....................................23
4. Protocol Specification .........................................28
4.1. Overview ..................................................28
4.2. Start Session Phase .......................................28
4.3. Start File Phase ..........................................30
4.4. Data Transfer Phase .......................................34
4.5. End File Phase ............................................35
4.6. End Session Phase .........................................36
4.7. Problem Handling ..........................................36
5. Commands and Formats ...........................................37
5.1. Conventions ...............................................37
5.2. Commands ..................................................37
5.3. Command Formats ...........................................37
5.4. Identification Code .......................................68
6. File Services ..................................................69
6.1. Overview ..................................................69
6.2. File Signing ..............................................69
6.3. File Encryption ...........................................70
6.4. File Compression ..........................................70
6.5. V Format Files - Record Lengths ...........................70
7. ODETTE-FTP Data Exchange Buffer ................................71
7.1. Overview ..................................................71
7.2. Data Exchange Buffer Format ...............................71
7.3. Buffer Filling Rules ......................................72
8. Stream Transmission Buffer .....................................73
8.1. Introduction ..............................................73
8.2. Stream Transmission Header Format .........................73
9. Protocol State Machine .........................................74
9.1. ODETTE-FTP State Machine ..................................74
9.2. Error Handling ............................................75
9.3. States ....................................................76
9.4. Input Events ..............................................79
9.5. Output Events .............................................79
9.6. Local Variables ...........................................80
9.7. Local Constants ...........................................81
9.8. Session Connection State Table ............................82
9.9. Error and Abort State Table ...............................85
9.10. Speaker State Table 1 ....................................86
9.11. Speaker State Table 2 ....................................91
9.12. Listener State Table .....................................93
9.13. Example ..................................................96
10. Miscellaneous .................................................97
10.1. Algorithm Choice .........................................97
10.2. Cryptographic Algorithms .................................97
10.3. Protocol Extensions ......................................97
10.4. Certificate Services .....................................98
11. Security Considerations .......................................98
Appendix A. Virtual File Mapping Example .........................100
Appendix B. ISO 646 Character Subset .............................103
Appendix C. X.25 Specific Information ............................104
C.1. X.25 Addressing Restrictions .............................104
C.2. Special Logic ............................................105
C.3. PAD Parameter Profile ....................................116
Appendix D. OFTP X.25 Over ISDN Recommendation ...................118
D.1. ODETTE ISDN Recommendation ...............................119
D.2. Introduction to ISDN .....................................120
D.3. Equipment Types ..........................................123
D.4. Implementation ...........................................124
Acknowledgements .................................................132
Normative References .............................................132
Informative References ...........................................133
ODETTE Address ...................................................134
The ODETTE File Transfer Protocol (ODETTE-FTP) was defined in 1986 by working group four of the Organisation for Data Exchange by Tele Transmission in Europe (ODETTE) to address the electronic data interchange (EDI) requirements of the European automotive industry.
Odetteファイル転送プロトコル（Odette-FTP）は、1986年に、ヨーロッパの自動車産業の電子データインターチェンジ（EDI）要件に対処するために、ヨーロッパのTELE Transmission（Odette）のデータ交換機関のワーキンググループ4によって定義されました。
ODETTE-FTP allows business applications to exchange files on a peer-to-peer basis in a standardised, purely automatic manner and provides a defined acknowledgement process on successful receipt of a file.
Odette-FTPを使用すると、ビジネスアプリケーションは標準化された純粋に自動的にピアツーピアベースでファイルを交換することができ、ファイルの受領を成功させるために定義された承認プロセスを提供します。
ODETTE-FTP is not to be confused as a variant of, or similar to, the Internet FTP [FTP], which provides an interactive means for individuals to share files and which does not have any sort of acknowledgement process. By virtue of its interactive nature, lack of file acknowledgements, and client/server design, FTP does not easily lend itself to mission-critical environments for the exchange of business data.
Odette-FTPは、インターネットFTP [FTP]のバリアント、または類似したものとして混同されるべきではありません。これは、個人がファイルを共有するインタラクティブな手段を提供し、承認プロセスの種類がありません。インタラクティブな性質、ファイル承認の欠如、クライアント/サーバーの設計により、FTPはビジネスデータを交換するためのミッションクリティカルな環境に簡単に貸し出されません。
Over the last ten years, ODETTE-FTP has been widely deployed on systems of all sizes from personal computers to large mainframes while the Internet has emerged as the dominant international network, providing high-speed communication at low cost. To match the demand for EDI over the Internet, ODETTE has decided to extend the scope of its file transfer protocol to incorporate security functions and advanced compression techniques to ensure that it remains at the forefront of information exchange technology.
過去10年間で、Odette-FTPはパーソナルコンピューターから大規模なメインフレームまで、あらゆるサイズのシステムに広く展開されていましたが、インターネットは支配的な国際ネットワークとして浮上し、低コストで高速通信を提供しました。インターネット上のEDIの需要に合わせて、Odetteはファイル転送プロトコルの範囲を拡張して、セキュリティ関数と高度な圧縮技術を組み込んで、情報交換技術の最前線に留まることを確認することを決定しました。
The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.
このプロトコルは、トランスポートレイヤーセキュリティを使用してインターネットを介した安全で認証された通信をサポートし、暗号化メッセージの構文を使用してファイル暗号化、署名、および圧縮を提供し、受信したファイルの承認のための署名済みの領収書を提供します。
The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25 and ISDN based networks.
このプロトコルは、付加価値ネットワークを介して直接ピアツーピア通信と間接通信の両方をサポートし、TCP/IP、X.25、およびISDNベースのネットワークで使用できます。
ODETTE-FTP has been defined by the ODETTE Security Working Group which consists of a number of ODETTE member organisations. All members have significant operational experience working with and developing OFTP and EDI solutions.
Odette-FTPは、多くのOdetteメンバー組織で構成されるOdette Security Working Groupによって定義されています。すべてのメンバーは、OFTPおよびEDIソリューションを使用して開発し、開発しています。
This memo is a development of version 1.4 of ODETTE-FTP [OFTP] with these changes/additions:
このメモは、これらの変更/追加を伴うOdette-FTP [OFTP]のバージョン1.4の開発です。
Session level encryption File level encryption Secure authentication File compression Signed End to End Response (EERP) Signed Negative End Response (NERP) Maximum permitted file size increased to 9 PB (petabytes) Virtual file description added Extended error codes
セッションレベル暗号化ファイルレベル暗号化セキュア認証ファイル圧縮符号付きエンドエンドエンド応答（EERP）署名されたネガティブエンド応答（NERP）最大許容ファイルサイズが9 PB（PETABYTES）仮想ファイルの説明拡張エラーコードの追加
Version 1.4 of ODETTE-FTP included these changes and additions to version 1.3:
Odette-FTPのバージョン1.4には、これらの変更とバージョン1.3への追加が含まれていました。
Negative End Response (NERP) Extended Date and Time stamp New reason code 14 (File direction refused)
ネガティブエンド応答（NERP）延長日付とタイムスタンプ新しい理由コード14（ファイルの指示が拒否されました）
The aim of ODETTE-FTP is to facilitate the transmission of a file between one or more locations in a way that is independent of the data communication network, system hardware, and software environment.
Odette-FTPの目的は、データ通信ネットワーク、システムハードウェア、およびソフトウェア環境とは独立した方法で、1つ以上の場所間のファイルの送信を容易にすることです。
In designing and specifying the protocol, the following factors were considered.
プロトコルの設計と指定では、次の要因が考慮されました。
1. The possible differences of size and sophistication of file storage and small and large systems.
1. ファイルストレージと小規模および大規模システムのサイズと洗練の可能な違い。
2. The necessity to work with existing systems (reduce changes to existing products and allow easy implementation).
2. 既存のシステムを操作する必要性（既存の製品の変更を減らし、簡単に実装できるようにします）。
3. Systems of different ages.
3. さまざまな年齢のシステム。
4. Systems of different manufactures.
4. さまざまなメーカーのシステム。
5. The potential for growth in sophistication (limit impact and avoid changes at other locations).
5. 洗練された成長の可能性（影響を制限し、他の場所での変更を回避します）。
ODETTE-FTP is modelled on the OSI reference model. It is designed to use the Network Service provided by level 3 of the model and provide a File Service to the users. Thus, the protocol spans levels 4 to 7 of the model.
Odette-FTPは、OSI参照モデルでモデル化されています。モデルのレベル3が提供するネットワークサービスを使用し、ユーザーにファイルサービスを提供するように設計されています。したがって、プロトコルはモデルのレベル4〜7に及びます。
The description of ODETTE-FTP contained in this memo is closely related to the original 'X.25' specification of the protocol and in the spirit of the OSI model describes:
このメモに含まれるOdette-FTPの説明は、プロトコルの元の「X.25」仕様とOSIモデルの精神に密接に関連しています。
1. A File Service provided to a User Monitor.
1. ユーザーモニターに提供されるファイルサービス。
2. A protocol for the exchange of information between peer ODETTE-FTP entities.
2. ピアオデットFTPエンティティ間の情報交換のためのプロトコル。
Information is always exchanged between ODETTE-FTP entities in a standard representation called a Virtual File. This allows data transfer without regard for the nature of the communicating systems.
情報は、仮想ファイルと呼ばれる標準表現のOdette-FTPエンティティ間で常に交換されます。これにより、通信システムの性質を考慮せずにデータ転送が可能になります。
The mapping of a file between a local and virtual representation will vary from system to system and is not defined here.
ローカル表現と仮想表現の間のファイルのマッピングは、システムごとに異なり、ここでは定義されていません。
o---------o
Site | Local |
A | File A |
o---------o
|
o----------------------- Mapping A ------------------------o
| | |
| o---------o |
| | Virtual | |
| | File | |
| o---------o |
| o------------------------------------------------o |
| | | |
| | ODETTE-FTP | |
| | | |
| o------------------------------------------------o |
| o---------o o---------o |
| | Virtual | | Virtual | |
| | File | | File | |
| o---------o o----+----o |
| | | |
o------ Mapping B ------------------------ Mapping C ------o
| |
o---------o o----+----o
| Local | Site Site | Local |
| File B | B C | File C |
o---------o o---------o
A Virtual File is described by a set of attributes identifying and defining the data to be transferred. The main attributes are detailed in Sections 1.5.1 to 1.5.4.
仮想ファイルは、転送されるデータを識別および定義する一連の属性によって説明されます。主な属性については、セクション1.5.1〜1.5.4で詳しく説明しています。
Sequential
一連
Logical records are presented one after another. ODETTE-FTP must be aware of the record boundaries.
論理レコードは次々に提示されます。Odette-FTPは、記録的な境界を認識している必要があります。
Dataset Name
データセット名
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
データセット名は、二国間契約によって割り当てられている仮想ファイルの名前。
Time stamp (HHMMSScccc)
タイムスタンプ（HHMMSSCCCC）
A file qualifier indicating the time the Virtual File was made available for transmission. The counter (cccc=0001-9999) gives higher resolution.
仮想ファイルが送信用に利用可能になった時間を示すファイル予選。カウンター（CCCC = 0001-9999）はより高い解像度を与えます。
Date stamp (CCYYMMDD)
日付スタンプ（ccyymmdd）
A file qualifier indicating the date the Virtual File was made available for transmission.
仮想ファイルが送信用に利用可能になった日付を示すファイル修飾子。
The Dataset Name, Date, and Time attributes are assigned by the Virtual File's originator and are used to uniquely identify a file. They are all mandatory and must not be changed by intermediate locations.
データセット名、日付、および時刻属性は、仮想ファイルのオリジネーターによって割り当てられ、ファイルを一意に識別するために使用されます。それらはすべて必須であり、中間の場所で変更してはなりません。
The User Monitor may use the Virtual File Date and Time attributes in local processes involving date comparisons and calculations. Any such use falls outside the scope of this protocol.
ユーザーモニターは、日付の比較と計算を含むローカルプロセスで、仮想ファイルの日付および時刻属性を使用できます。このような使用は、このプロトコルの範囲外にあります。
Four record formats are defined:
4つのレコード形式が定義されています。
Fixed (F)
固定（f）
Each record in the file has the same length.
ファイル内の各レコードには同じ長さがあります。
Variable (V)
変数（v）
The records in the file can have different lengths.
ファイル内のレコードには、長さが異なります。
Unstructured (U)
非構造（u）
The file contains a stream of data. No structure is defined.
ファイルにはデータのストリームが含まれています。構造は定義されていません。
Text File (T)
テキストファイル（t）
A Text File is defined as a sequence of ASCII characters, containing no control characters except CR-LF that delimit lines. A line will not have more than 2048 characters.
テキストファイルは、線を区切るCR-LF以外の制御文字を含むASCII文字のシーケンスとして定義されます。ラインには2048人以上の文字がありません。
ODETTE-FTP can negotiate the restart of an interrupted Virtual File transmission. Fixed and Variable format files are restarted on record boundaries. For Unstructured and Text files, the restart position is expressed as a file offset in 1K (1024 octet) blocks.
Odette-FTPは、中断された仮想ファイル送信の再起動をネゴシエートできます。固定および可変形式のファイルは、レコード境界で再起動されます。非構造ファイルとテキストファイルの場合、再起動位置は1K（1024オクテット）ブロックのファイルオフセットとして表されます。
The restart position is always calculated relative to the start of the Virtual File.
再起動位置は、仮想ファイルの開始に対して常に計算されます。
ODETTE-FTP provides a file transfer service to a User Monitor and in turn uses the Internet transport layer stream service to communicate between peers.
Odette-FTPは、ユーザーモニターへのファイル転送サービスを提供し、インターネットトランスポートレイヤーストリームサービスを使用してピア間で通信します。
These services are specified in this memo using service primitives grouped into four classes as follows:
これらのサービスは、次のように4つのクラスにグループ化されたサービスプリミティブを使用して、このメモで指定されています。
Request (RQ) An entity asks the service to do some work. Indication (IND) A service informs an entity of an event. Response (RS) An entity responds to an event. Confirm (CF) A service informs an entity of the response.
リクエスト（RQ）エンティティは、サービスに何らかの作業を行うように依頼します。表示（Ind）サービスは、イベントのエンティティに通知します。応答（RS）エンティティはイベントに対応します。確認（CF）サービスは、エンティティに応答を通知します。
Services may be confirmed, using the request, indication, response, and confirm primitives, or unconfirmed using just the request and indication primitives.
リクエスト、表示、応答、およびプリミティブの確認を使用して、またはリクエストと表示プリミティブのみを使用して固定されていないサービスが確認される場合があります。
ODETTE-FTP provides a number of security services to protect a Virtual File transmission across a hostile network.
Odette-FTPは、敵対的なネットワーク全体で仮想ファイル送信を保護するための多くのセキュリティサービスを提供します。
These security services are as follows:
これらのセキュリティサービスは次のとおりです。
Confidentiality Integrity Non-repudiation of receipt Non-repudiation of origin Secure authentication
機密性の整合性領収書の非控除原産地の非和解セキュア認証
Security services in this specification are implemented as follows:
この仕様のセキュリティサービスは、次のように実装されています。
Session level encryption File level encryption Signed files Signed receipts Session level authentication ODETTE-FTP Authentication
セッションレベル暗号化ファイルレベル暗号化署名されたファイル署名された領収書セッションレベル認証odette-ftp認証
Session level encryption provides data confidentiality by encryption of all the protocol commands and data exchanged between two parties, preventing a third party from extracting any useful information from the transmission.
セッションレベルの暗号化は、すべてのプロトコルコマンドと2つの関係者間で交換されるデータの暗号化によりデータの機密性を提供し、サードパーティが送信から有用な情報を抽出することを妨げます。
This session level encryption is achieved by layering ODETTE-FTP over Transport Layer Security [TLS], distinguishing between secure and unsecure TCP/IP traffic using different port numbers.
このセッションレベルの暗号化は、輸送層のセキュリティ[TLS]を介してOdette-FTPを重ね、さまざまなポート番号を使用して安全なTCP/IPトラフィックを区別することによって達成されます。
File encryption provides complementary data confidentiality by encryption of the files in their entirety. Generally, this encryption occurs prior to transmission, but it is also possible to encrypt and send files while in session. File encryption has the additional benefit of allowing a file to remain encrypted outside of the communications session in which it was sent. The file can be received and forwarded by multiple intermediaries, yet only the final destination will be able to decrypt the file. File encryption does not encrypt the actual protocol commands, so trading partner EDI codes and Virtual File names are still viewable.
ファイル暗号化は、ファイル全体を暗号化することにより、補完的なデータの機密性を提供します。一般に、この暗号化は送信前に発生しますが、セッション中にファイルを暗号化して送信することもできます。ファイル暗号化には、送信された通信セッションの外側でファイルが暗号化されたままにすることを許可するという追加の利点があります。ファイルは複数の仲介者によって受信および転送できますが、最終目的地のみがファイルを復号化できます。ファイル暗号化は実際のプロトコルコマンドを暗号化しないため、トレーディングパートナーのEDIコードと仮想ファイル名は引き続き表示されます。
Secure authentication is implemented through the session level authentication features available in [TLS] and proves the identity of the parties wishing to communicate.
安全な認証は、[TLS]で利用可能なセッションレベル認証機能を通じて実装され、通信を希望する当事者のIDを証明します。
ODETTE-FTP Authentication also provides an authentication mechanism, but one that is integral to ODETTE-FTP and is available on all network infrastructures over which ODETTE-FTP is operated (this is in contrast to [TLS] which is generally only available over TCP/IP-based networks). Both parties are required to possess certificates when ODETTE-FTP Authentication is used.
Odette-FTP認証も認証メカニズムを提供しますが、Odette-FTPに不可欠であり、Odette-FTPが動作するすべてのネットワークインフラストラクチャで利用可能です（これは、一般にTCP/でのみ利用可能な[TLS]とは対照的です。IPベースのネットワーク）。両方の当事者は、Odette-FTP認証が使用されている場合、証明書を所有する必要があります。
The security features in ODETTE-FTP 2 are centred around the use of [X.509] certificates. To take advantage of the complete range of security services offered in both directions, each party is required to possess an [X.509] certificate. If the confidentiality of data between two parties is the only concern, then [TLS] alone can be used, which allows the party accepting an incoming connection (the Responder) to be the only partner required to possess a certificate.
Odette-FTP 2のセキュリティ機能は、[X.509]証明書の使用を中心としています。両方向で提供されるセキュリティサービスの完全な範囲を活用するには、各当事者が[x.509]証明書を所有する必要があります。2つの当事者間のデータの機密性が唯一の懸念である場合、[TLS]のみを使用できます。これにより、当事者が入ってくる接続（レスポンダー）を受け入れる当事者が証明書を所有するために必要な唯一のパートナーであることができます。
For businesses, this means that session level encryption between a hub and its trading partners can be achieved without requiring all the trading partners to obtain a certificate, assuming that trading partners always connect to the hub.
企業の場合、これは、すべての取引パートナーが常に証明書を取得することを要求することなく、ハブとその取引パートナー間のセッションレベルの暗号化を達成できることを意味します。
With the exception of [TLS], all the security services work with X.25 and ISDN as transport media. Although nothing technically precludes [TLS] from working with X.25 or ISDN, implementations are rare.
[TLS]を除き、すべてのセキュリティサービスはX.25およびISDNを輸送メディアとして機能させます。技術的にはX.25またはISDNでの作業を妨げるものはありませんが、実装はまれです。
ODETTE-FTP peer entities communicate with each other via the OSI Network Service or the Transmission Control Protocol Transport Service [RFC793]. This is described by service primitives representing request, indication, response, and confirmation actions.
Odette-FTPピアエンティティは、OSIネットワークサービスまたは送信制御プロトコルトランスポートサービス[RFC793]を介して相互に通信します。これは、リクエスト、表示、応答、および確認アクションを表すサービスプリミティブによって説明されています。
For the Internet environment, the service primitives mentioned below for the Network Service have to be mapped to the respective Transport Service primitives. This section describes the Network Service primitives used by ODETTE-FTP and their relationship to the TCP interface. In practice, the local transport service application programming interface will be used to access the TCP service.
インターネット環境の場合、ネットワークサービスのために以下に記載されているサービスプリミティブをそれぞれの輸送サービスプリミティブにマッピングする必要があります。このセクションでは、Odette-FTPが使用するネットワークサービスプリミティブとTCPインターフェイスとの関係について説明します。実際には、ローカルトランスポートサービスアプリケーションプログラミングインターフェイスを使用して、TCPサービスにアクセスします。
All network primitives can be directly mapped to the respective Transport primitives when using TCP.
すべてのネットワークプリミティブは、TCPを使用する場合、それぞれの輸送プリミティブに直接マッピングできます。
N_CON_RQ ------> N_CON_IND
N_CON_CF <------ N_CON_RS
This describes the setup of a connection. The requesting ODETTE-FTP peer uses the N_CON_RQ primitive to request an active OPEN of a connection to a peer ODETTE-FTP, the Responder, which has previously requested a passive OPEN. The Responder is notified of the incoming connection via N_CON_IND and accepts it with N_CON_RS. The requester is notified of the completion of its OPEN request upon receipt of N_CON_CF.
これは、接続のセットアップを説明します。要求するOdette-FTPピアは、N_CON_RQ Primitiveを使用して、以前にパッシブオープンを要求していたピアオデットFTPへの接続のアクティブなオープンを要求します。レスポンダーには、N_CON_INDを介した着信接続が通知され、N_CON_RSでそれを受け入れます。要求者は、N_CON_CFを受け取ったときにオープンリクエストの完了を通知されます。
Parameters
パラメーター
Request Indication Response Confirmation
---------------------------------------------------------------------
Dest addr ------> same same same
N_DATA_RQ ------> N_DATA_IND
Data exchange is an unconfirmed service. The requester passes data for transmission to the Network Service via the N_DATA_RQ primitive. The Responder is notified of the availability of data via N_DATA_IND.
データ交換は未確認のサービスです。要求者は、N_DATA_RQ Primitiveを介してネットワークサービスに送信するためのデータを渡します。レスポンダーには、N_DATA_INDを介したデータの可用性が通知されます。
In practice, the notification and receipt of data may be combined, such as by the return from a blocking read from the network socket.
実際には、ネットワークソケットから読み取られたブロッキングからの返品など、データの通知と受領を組み合わせることができます。
Parameters
パラメーター
Request Indication
---------------------------------------------------------------------
Data ------------------> same
N_DISC_RQ ------> N_DISC_IND
An ODETTE-FTP requests the termination of a connection with the N_DISC_RQ service primitive. Its peer is notified of the CLOSE by a N_DISC_IND event. It is recognised that each peer must issue a N_DISC_RQ primitive to complete the TCP symmetric close procedure.
ODETTE-FTPは、N_DISC_RQサービスプリミティブとの接続の終了を要求します。そのピアは、N_DISC_INDイベントによって終了することを通知されます。各ピアは、N_DISC_RQプリミティブを発行して、TCP対称閉鎖手順を完了する必要があることが認識されています。
------> N_RST_IND
An ODETTE-FTP entity is notified of a network error by a N_RST_IND event. It should be noted that N_RST_IND would also be generated by a peer RESETTING the connection, but this is ignored here as N_RST_RQ is never sent to the Network Service by ODETTE-FTP.
Odette-FTPエンティティには、N_RST_INDイベントによるネットワークエラーが通知されます。N_RST_INDは、接続をリセットするピアによっても生成されることに注意する必要がありますが、N_RST_RQがOdette-FTPによってネットワークサービスに送信されることはないため、ここでは無視されます。
[TLS] provides a mechanism for securing an ODETTE-FTP session over the Internet or a TCP network. ODETTE-FTP is layered over [TLS], distinguishing between secure and unsecure traffic by using different server ports.
[TLS]は、インターネットまたはTCPネットワーク上でオデットFTPセッションを保護するためのメカニズムを提供します。Odette-FTPは[TLS]上に階層化されており、さまざまなサーバーポートを使用して安全なトラフィックと無事なトラフィックを区別します。
The implementation is very simple. Layer ODETTE-FTP over [TLS] in the same way as layering ODETTE-FTP over TCP/IP. [TLS] provides both session encryption and authentication, both of which may be used by the connecting parties. A party acts as a [TLS] server when receiving calls and acts as a [TLS] client when making calls. When the [TLS] handshake has completed, the responding ODETTE-FTP may start the ODETTE-FTP session by sending the Ready Message.
実装は非常に簡単です。TCP/IPを介してOdette-FTPを階層化するのと同じ方法で、[TLS]上にOdette-FTPを層化します。[TLS]は、セッションの暗号化と認証の両方を提供しますが、どちらも接続当事者が使用できます。当事者は、通話を受信するときに[TLS]サーバーとして機能し、電話をかけるときは[TLS]クライアントとして機能します。[TLS]の握手が完了すると、対応するOdette-FTPは、Readyメッセージを送信してOdette-FTPセッションを開始する可能性があります。
An ODETTE-FTP requester will select a suitable local port.
ODETTE-FTPリクエスト担当者は、適切なローカルポートを選択します。
The responding ODETTE-FTP will listen for connections on Registered Port 3305; the service name is 'odette-ftp'.
応答するOdette-FTPは、登録されたポート3305の接続をリッスンします。サービス名は「odette-ftp」です。
The responding ODETTE-FTP will listen for secure TLS connections on Registered Port 6619; the service name is 'odette-ftps'.
応答するOdette-FTPは、登録されたポート6619で安全なTLS接続をリッスンします。サービス名は「odette-ftps」です。
The File Transfer Service describes the services offered by an ODETTE-FTP entity to its User Monitor (generally an application).
ファイル転送サービスは、Odette-FTPエンティティがユーザーモニター（一般的にアプリケーション）に提供するサービスを説明しています。
NOTE: The implementation of the service primitives is an application issue.
注：サービスプリミティブの実装はアプリケーションの問題です。
o-------------------o o-------------------o
| | | |
| USER MONITOR | | USER MONITOR |
| | | |
o-------------------o o-------------------o
| A | A
| | | |
F_XXX_RQ/RS | | F_XXX_IND/CF F_XXX_RQ/RS | | F_XXX_IND/CF
V | V |
o-------------------o o-------------------o
| |- - - - - - >| |
| ODETTE-FTP Entity | E-Buffer | ODETTE-FTP Entity |
| |< - - - - - -| |
o-------------------o o-------------------o
| A | A
N_XXX_RQ/RS | | N_XXX_IND/CF N_XXX_RQ/RS | | N_XXX_IND/CF
| | | |
V | V |
o---------------------------------------------------------o
| |
| N E T W O R K |
| |
o---------------------------------------------------------o
Key: E-Buffer - Exchange Buffer F_ - File Transfer Service Primitive N_ - Network Service Primitive
キー：eバッファー - 交換バッファーf_-ファイル転送サービスプリミティブN_-ネットワークサービスプリミティブ
These diagrams represent the interactions between two communicating ODETTE-FTP entities and their respective User Agents.
これらの図は、2つの通信Odette-FTPエンティティとそれぞれのユーザーエージェントとの相互作用を表しています。
The vertical lines represent the ODETTE-FTP entities. The User Agents are not shown.
垂直線は、Odette-FTPエンティティを表します。ユーザーエージェントは表示されません。
| |
F_CONNECT_RQ ---->|------------|----> F_CONNECT_IND
| |
F_CONNECT_CF <----|------------|<---- F_CONNECT_RS
| |
Parameters
パラメーター
Request Indication Response Confirm
---------------------------------------------------------------------
called-address -> same --- ----
calling-address-> same --- ----
ID1 ------------> same ID2 ------------> same
PSW1------------> same PSW2 -----------> same
mode1 ----------> mode2 ----------> mode3 ----------> same
restart1 -------> same -----------> restart2 -------> same
authentication1-> same -----------> authentication2-> same
---------------------------------------------------------------------
Mode
モード
Specifies the file transfer capabilities of the entity sending or receiving a F_CONNECT primitive for the duration of the session.
セッション中にF_Connect Primitiveを送信または受信するエンティティのファイル転送機能を指定します。
Value: Sender-only The entity can only send files. Receiver-only The entity can only receive files. Both The entity can both send and receive files.
値：送信者のみエンティティはファイルのみを送信できます。レシーバーのみエンティティはファイルのみを受信できます。両方のエンティティは、ファイルを送信および受信できます。
Negotiation: Sender-only Not negotiable. Receiver-only Not negotiable. Both Can be negotiated down to Sender-only or Receiver-only by the User Monitor or the ODETTE-FTP entity.
交渉：送信者のみは交渉できません。レシーバーのみは交渉できません。どちらも、ユーザーモニターまたはOdette-FTPエンティティによって送信者のみまたはレシーバーのみにネゴシエートすることができます。
Request Indication Response Confirm
---------------------------------------------------------------------
Sender-only ----> Receiver-only --> Receiver-only --> Sender-only
Receiver-only --> Sender-only ----> Sender-only ----> Receiver-only
Both -----+-----> Both ----+------> Both -----------> Both
| or +------> Receiver-only --> Sender-only
| or +------> Sender-only ----> Receiver-only
|
or +-----> Receiver-only --> Receiver-only --> Sender-only
or +-----> Sender-only ----> Sender-only ----> Receiver-only
---------------------------------------------------------------------
Restart
再起動
Specifies the file transfer restart capabilities of the User Monitor.
ユーザーモニターのファイル転送再起動機能を指定します。
Value: Y The entity can restart file transfers. N The entity cannot restart file transfers.
値：Yエンティティはファイル転送を再開できます。nエンティティはファイル転送を再開できません。
Negotiation:
交渉：
Request Indication Response Confirm
---------------------------------------------------------------------
restart = Y ----> restart = Y --+-> restart = Y ----> restart = Y
or +-> restart = N ----> restart = N
restart = N ----> restart = N ----> restart = N ----> restart = N
---------------------------------------------------------------------
Authentication
認証
Specifies the authentication requirement of the User Monitor.
ユーザーモニターの認証要件を指定します。
Value:
Y Authentication required.
N Authentication not required.
Negotiation: Not negotiable.
交渉：交渉できません。
Request Indication Response Confirm
---------------------------------------------------------------------
auth = Y ----> auth = Y ----> auth = Y ----> auth = Y
auth = N ----> auth = N ----> auth = N ----> auth = N
---------------------------------------------------------------------
| |
F_START_FILE_RQ ---->|------------|----> F_START_FILE_IND
| |
F_START_FILE_CF(+|-) <----|------------|<---- F_START_FILE_RS(+|-)
| |
Parameters
パラメーター
Request Ind. RS(+) CF(+) RS(-) CF(-)
------------------------------------------------------------------
filename-------> same ---- ---- ---- ----
date-time------> same ---- ---- ---- ----
destination----> same ---- ---- ---- ----
originator-----> same ---- ---- ---- ----
rec-format-----> same ---- ---- ---- ----
rec-size ------> same ---- ---- ---- ----
file-size------> same ---- ---- ---- ----
org-file-size--> same ---- ---- ---- ----
signed-eerp----> same ---- ---- ---- ----
cipher---------> same ---- ---- ---- ----
sec-services---> same ---- ---- ---- ----
compression----> same ---- ---- ---- ----
envelope-format> same ---- ---- ---- ----
description----> same ---- ---- ---- ----
restart-pos1---> same-> restart-pos2-> same ---- ----
---- ---- ---- ---- cause ------> same
---- ---- ---- ---- retry-later-> same
------------------------------------------------------------------
Notes:
ノート：
1. Retry-later has values "Y" or "N". 2. Cause is the reason for refusing the transfer (1,..,13,99). 3. Restart-pos1 not equal 0 is only valid if restart has been agreed during initial negotiation. 4. Restart-pos2 is less than or equal to restart-pos1.
1. retry-laterには、値「y」または「n」があります。2.原因は、転送を拒否する理由です（1、..、13,99）。3.再起動-Pos1等しい0は、最初の交渉中に再起動が合意された場合にのみ有効です。4.再起動-Pos2は、再起動-Pos1以下です。
| |
F_DATA_RQ ---->|------------|----> F_DATA_IND
| |
F_DATA_CF <----|(---CDT----)|
| |
Note: Unlike other commands, where the F_XXX_CF signal is a result of a corresponding F_XXX_RS command, in this case, the local entity layer issues this signal when it is ready for the next data request. This decision is based on the current credit count and the reception of CDT (Set Credit) from the receiver.
注：F_XXX_CF信号が対応するF_XXX_RSコマンドの結果である他のコマンドとは異なり、この場合、ローカルエンティティレイヤーは、次のデータ要求の準備ができたときにこの信号を発行します。この決定は、現在のクレジット数と受信者からのCDT（セットクレジット）の受信に基づいています。
| |
F_CLOSE_FILE_RQ --->|------------|----> F_CLOSE_FILE_IND
| |
F_CLOSE_FILE_CF(+|-) <---|------------|<---- F_CLOSE_FILE_RS(+|-)
| |
Parameters
パラメーター
Request Ind RS(+) CF(+) RS(-) CF(-)
---------------------------------------------------------------------
rec-count ---> same ---- ---- ---- ----
unit-count --> same ---- ---- ---- ----
---- ---- Speaker=Y ---> Speaker=N ---- ----
---- ---- Speaker=N ---> Speaker=Y ---- ----
---- ---- ---- ---- cause ---> same
---------------------------------------------------------------------
In a positive Close File response (F_CLOSE_FILE_RS(+)) the current Listener may either:
肯定的なクローズファイル応答（f_close_file_rs（））では、現在のリスナーは次のとおりです。
1. Set Speaker to "Yes" and become the Speaker or 2. Set Speaker to "No" and remain the Listener.
1. スピーカーを「はい」に設定し、スピーカーになります。スピーカーを「いいえ」に設定し、リスナーのままです。
The File Transfer service will ensure that the setting of the speaker parameter is consistent with the capabilities of the peer user.
ファイル転送サービスは、スピーカーパラメーターの設定がピアユーザーの機能と一致するようにします。
The turn is never exchanged in the case of a negative response or confirmation.
否定的な応答または確認の場合、ターンは決して交換されません。
Only the Speaker is allowed to issue F_XXX_FILE_RQ primitives.
スピーカーのみがF_XXX_FILE_RQ Primitivesを発行できます。
The Initiator becomes the first Speaker at the end of the Session Setup (F_CONNECT_CF received by Initiator and F_CONNECT_RS sent by Responder).
イニシエーターは、セッションのセットアップの終了時に最初のスピーカーになります（f_connect_cfは、Responderが送信したInitiatorおよびF_Connect_RSが受信します）。
Rules:
ルール：
1. At each unsuccessful End of File, the turn is not exchanged.
1. ファイルの端が失敗するたびに、ターンは交換されません。
2. At each successful End of File, the turn is exchanged if requested by the Listener:
2. ファイルの成功するたびに、リスナーから要求された場合、ターンは交換されます。
- The current Listener receives F_CLOSE_FILE_IND (Speaker = choice).
- 現在のリスナーは、f_close_file_ind（speaker = choice）を受信します。
- If the Listener answers F_CLOSE_FILE_RS(Speaker = YES), it becomes the Speaker, the Speaker receives F_CLOSE_FILE_CF (Speaker = NO) and becomes the Listener.
- リスナーがf_close_file_rs（スピーカー= yes）に答えた場合、それはスピーカーになり、スピーカーはf_close_file_cf（スピーカー= no）を受信し、リスナーになります。
- If the Listener answers F_CLOSE_FILE_RS(Speaker = NO), it remains as the Listener, and the Speaker receives F_CLOSE_FILE_CF (Speaker = YES) and remains as the Speaker.
- リスナーがf_close_file_rs（スピーカー= no）に答えた場合、それはリスナーとして残り、スピーカーはf_close_file_cf（スピーカー= yes）を受信し、スピーカーとして残ります。
3. The Speaker can issue a Change Direction request (F_CD_RQ) to become the Listener. The Listener receives a Change Direction indication (F_CD_IND) and becomes the Speaker.
3. スピーカーは、リスナーになるために変更方向リクエスト（F_CD_RQ）を発行できます。リスナーは、変更方向表示（f_cd_ind）を受け取り、スピーカーになります。
4. In order to prevent loops of F_CD_RQ/IND, the Speaker may not send an F_CD_RQ after receiving an unsolicited F_CD_IND. If the Listener receives a solicited F_CD_IND as a result of sending EFPA(Speaker=Yes), it is acceptable to immediately relinquish the right to speak by sending an F_CD_RQ.
4. f_cd_rq/indのループを防ぐために、スピーカーは未承諾のf_cd_indを受け取った後、f_cd_rqを送信することはできません。リスナーがEFPA（スピーカー= yes）を送信した結果として勧誘されたf_cd_indを受け取った場合、f_cd_rqを送信することにより、すぐに発言権を放棄することは許容されます。
This service is initiated by the current Speaker (if there is no file transfer in progress) to send an End to End Response from the final destination to the originator of a file.
このサービスは、現在のスピーカー（進行中のファイル転送がない場合）によって開始され、最終目的地からファイルのオリジネーターにエンドツーエンドの応答を送信します。
| |
F_EERP_RQ ---->|------------|----> F_EERP_IND
| |
F_RTR_CF <----|------------|<---- F_RTR_RS
| |
Parameters
パラメーター
Request Indication
------------------------------------
filename -----------> same
date ---------------> same
time ---------------> same
destination --------> same
originator ---------> same
hash ---------------> same
signature ----------> same
------------------------------------
Relationship with Turn:
ターンとの関係：
- Only the Speaker may send an End to End Response request.
- スピーカーのみがエンドツーエンド応答リクエストを送信できます。
- Invoking the EERP service does not change the turn.
- EERPサービスを呼び出すことは、ターンを変更しません。
- If an F_CD_IND has been received just before F_EERP_RQ is issued, this results in leaving the special condition created by the reception of F_CD_IND; i.e., while it was possible to issue F_RELEASE_RQ and not possible to issue F_CD_RQ just after the reception of F_CD_IND, after having issued F_EERP_RQ the normal Speaker status is entered again (F_CD_RQ valid, but F_RELEASE_RQ not valid).
- F_EERP_RQが発行される直前にF_CD_INDを受信した場合、F_CD_INDの受信によって作成された特別な状態を離れることになります。つまり、F_RELEASE_RQを発行することは可能でしたが、F_CD_INDの受信直後にF_CD_RQを発行することはできませんでしたが、F_EERP_RQを発行した後、通常のスピーカーステータスが再び入力されます（F_CD_RQ有効ですが、F_RELEASE_RQは無効です）。
Notes:
ノート：
1. The F_EERP_RQ (and also F_NERP_RQ) is confirmed with an F_RTR_CF signal. The F_RTR_CF signal is common to both F_EERP_RQ and F_NERP_RQ. There should be no ambiguity, since there can only be one such request pending at any one time.
1. F_EERP_RQ（およびF_NERP_RQ）は、F_RTR_CF信号で確認されています。f_rtr_cf信号は、f_eerp_rqとf_nerp_rqの両方に共通しています。一度に保留中のそのような要求が1つしかないため、あいまいさはないはずです。
2. The signature is optional and is requested when sending the F_START_FILE_RQ.
2. 署名はオプションであり、f_start_file_rqを送信するときに要求されます。
3. If it is not possible to sign the EERP, then an unsigned EERP should still be sent.
3. EERPに署名することができない場合は、署名されていないEERPを送信する必要があります。
4. It is an application implementation issue to validate the contents of the EERP and its signature and to decide what action to take on receipt of an EERP that fails validation or is not signed when a signed EERP was requested.
4. これは、EERPの内容とその署名の内容を検証し、検証に失敗した、または署名されたEERPが要求されたときに署名されていないEERPの受領でどのアクションを取るかを決定するためのアプリケーションの実装の問題です。
This service is initiated by the current speaker (if there is no file transfer in progress) to send a Negative End Response when a file could not be transmitted to the next destination. It is sent only if the problem is of a non-temporary kind.
このサービスは、ファイルを次の宛先に送信できなかった場合に負の終了応答を送信するために、現在のスピーカー（進行中のファイル転送がない場合）によって開始されます。問題が非同種の場合にのみ送信されます。
This service may also be initiated by the final destination instead of sending an End to End Response when a file could not be processed, after having successfully received the file.
このサービスは、ファイルを正常に受信した後、ファイルを処理できなかったときにエンドツーエンド応答を送信する代わりに、最終目的地によって開始される場合があります。
| |
F_NERP_RQ ---->|------------|----> F_NERP_IND
| |
F_RTR_CF <----|------------|----- F_RTR_RS
| |
Parameters
パラメーター
Request Indication
---------------------------------------------------
filename ----------------------> same
date --------------------------> same
time --------------------------> same
destination -------------------> same
originator --------------------> same
creator of negative response --> same
reason ------------------------> same
reason text -------------------> same
hash --------------------------> same
signature ---------------------> same
---------------------------------------------------
Relationship with Turn:
ターンとの関係：
The same as for the End-To-End response (see Section 3.3.5).
エンドツーエンドの応答と同じ（セクション3.3.5を参照）。
| |
F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND
| |
Parameters
パラメーター
Request Indication
---------------------------------------------------------------------
reason = normal -------> ----
---------------------------------------------------------------------
The Release service can only be initiated by the Speaker.
リリースサービスは、スピーカーによってのみ開始できます。
The Speaker can only issue a Release request (F_RELEASE_RQ) just after receiving an unsolicited Change Direction indication (F_CD_IND). This ensures that the other partner doesn't want to send any more files in this session.
スピーカーは、未承諾の変更方向表示（f_cd_ind）を受信した直後にリリースリクエスト（f_release_rq）を発行できます。これにより、他のパートナーがこのセッションでこれ以上ファイルを送信したくないことが保証されます。
Peer ODETTE-FTP entities action a normal session release by specifying Reason = Normal in an End Session (ESID) command.
Peer Odette-FTPエンティティアクションEnd Session（ESID）コマンドでReason = Normalを指定することにより、通常のセッションリリース。
| |
F_RELEASE_RQ ---->|------------|----> F_ABORT_IND
| |
Parameters
パラメーター
Request Indication
---------------------------------------------------------------------
reason = error value --> same (or equivalent)
AO (Abort Origin) = (L)ocal or (D)istant
---------------------------------------------------------------------
Abnormal session release can be initiated by either the Speaker or the Listener and also by the user or provider.
異常なセッションのリリースは、スピーカーまたはリスナーのいずれか、およびユーザーまたはプロバイダーによって開始できます。
Abnormal session release can occur at any time within the session.
異常なセッションのリリースは、セッション内のいつでも発生する可能性があります。
Peer ODETTE-FTP entities action an abnormal session release by specifying Reason = Error-value in an End Session (ESID) command.
Peer Odette-FTPエンティティアクションは、理由を指定することにより異常なセッションリリースを行います= ERROR-VALUE（ESID）コマンド。
The abnormal session release deals with the following types of error:
異常なセッションリリースは、次のタイプのエラーを扱います。
1. The service provider will initiate an abnormal release in the following cases:
1. サービスプロバイダーは、次の場合に異常なリリースを開始します。
1. Protocol error. 2. Failure of the Start Session (SSID) negotiation. 3. Command not recognised. 4. Data Exchange Buffer size error. 5. Resources not available. 6. Other unspecified abort code (with Reason = unspecified).
1. プロトコルエラー。2.開始セッション（SSID）交渉の失敗。3.コマンドは認識されていません。4.データ交換バッファサイズエラー。5.リソースは利用できません。6.その他の不特定の中止コード（理由=不特定）。
2. The User Monitor will initiate an abnormal release in the following cases:
2. ユーザーモニターは、次の場合に異常なリリースを開始します。
1. Local site emergency close down. 2. Resources not available. 3. Other unspecified abort code (with Reason = unspecified).
1. ローカルサイトの緊急閉鎖。2.利用できないリソース。3.その他の不特定の中止コード（理由=不特定）。
Other error types may be handled by an abort of the connection.
他のエラータイプは、接続の中止によって処理される場合があります。
| |
F_ABORT_RQ ---->|------------|----> F_ABORT_IND
| |
User-Initiated Abort
| |
F_ABORT_IND <----|------------|----> F_ABORT_IND
| |
Provider-Initiated Abort
Parameters
パラメーター
Request Indication
---------------------------------------------------------------------
-- R (Reason): specified or unspecified
-- AO (Abort Origin): (L)ocal or (D)istant
---------------------------------------------------------------------
The Abort service may be invoked by either entity at any time.
中止サービスは、いずれかのエンティティによっていつでも呼び出される場合があります。
The service provider may initiate an abort in case of error detection.
サービスプロバイダーは、エラー検出の場合に中止を開始する場合があります。
User | OFTP | Network | OFTP | User
---------------|------|----------------------|------|---------------
| | | |
1. Normal Release
1. 通常のリリース
F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND
*--------------|-> ==|======================|=> --|-------------->
(R=normal) | | | |
2. User-Initiated Abnormal Release
2. ユーザー開始の異常リリース
F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND
*--------------|-> ==|======================|=> -|-------------->
(R=error value)| | | | (R=error,AO=D)
3. Provider-Initiated Abnormal Release
3. プロバイダー開始異常リリース
F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND
<--------------|-* *=|======================|=> --|-------------->
| | | |
4. User-Initiated Connection Abort
4. ユーザー開始接続中止
F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND
*--------------|-> --|--------->..----------|-> --|-------------->
| | N_DISC_IND | | (R=unsp.,AO=D)
5. Provider-Initiated Connection Abort
5. プロバイダー開始接続中止
F_ABORT_IND | | N_DISC_RQ | | F_ABORT_IND
<--------------|-* *-|--------->..----------|-> --|-------------->
(R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D)
Key: * Origin of command flow
F_ ---> File Transfer Service primitive
N_ ---> Network Service primitive
===> ODETTE-FTP (OFTP) protocol message
These state automata define the service as viewed by the User Monitor. Events causing a state transition are shown in lower case and the resulting action in upper case where appropriate.
これらの状態オートマトンは、ユーザーモニターによって表示されるようにサービスを定義します。状態遷移を引き起こすイベントは、必要に応じて上品な場合に結果として生じるアクションを下回って表示されます。
o------------o
decision | | f_connect_ind
+-----------------| IDLE |-----------------+
| F_CONNECT_RQ | (0) | F_CONNECT_RS |
| o------------o |
V |
o-----------------o |
| | |
| I_WF_FCONNECTCF | |
| | |
o--------+--------o |
| |
| F_CONNECT_CF |
V V
o-----------------o o-----------------o
| | | |
| IDLE SPEAKER | | IDLE LISTENER |
| (1) | | (2) |
| See Speaker | | See Listener |
| State Diagram | | State Diagram |
| | | |
o-----------------o o-----------------o
o-----------------o o-----------------o
| IDLE LISTENER | | IDLE |
| CD_RQ just sent | | see (0) |
| see (3), Listen | | Idle |
| State Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision decision
F_CD_RQ F_RELEASE_RQ
| |
o================o decision o----------o decision o---------------o
| |---------->| WAIT FOR |<----------| |
| | F_EERP_RQ | | F_EERP_RQ | |
| IDLE | | EERP/ | | IDLE |
| SPEAKER | decision | NERP | decision | SPEAKER |
| (1) |---------->| CONFIRM. |<----------| (4) |
| | F_NERP_RQ | | F_NERP_RQ | |
| | | | | |
| | | | | CD_IND |
| | f_rtr_cf | | | just received |
| |<----------| | | |
| | o----------o | |
| | | |
| | | |
o================o o---------------o
A A | |
| | | decision and P2 decision and P2 |
| | +-----------------+ +---------------------+
| | F_START_FILE_RQ | | F_START_FILE_RQ
| | V V
| | o---------------o
| | f_file_start_cf(-) | |
| +----------------------| OPENING |
| | |
| o---------------o
| |
f_file_close_cf(-) or f_start_file_cf(+)
f_file_close_cf(+) and not P1 |
| V
o---------------o o---------------o record to send o---------o
| | | |------------------>| |
| CLOSING | | DATA TRANSFER | F_DATA_RQ | NEXT |
| | | | | RECORD |
| | | | f_data_cf | |
| | | |<------------------| |
o---------------o o---------------o o---------o
| A |
| | end of file |
| +-------------------+
| F_CLOSE_FILE_RQ
| o-----------------o
| f_file_close_cf(+) and P1 | IDLE LISTENER |
+--------------------------------------------->| see (2), Listen |
| State Diagram |
Predicates: o-----------------o
P1: Positive confirmation and Speaker = YES
P2: Mode = Both or (Mode = Sender-only)
o-----------------o o-----------------o
| IDLE SPEAKER | | IDLE |
| CD_IND just | | |
| received see(4) | | see (0) |
| Speaker State | | Idle |
| Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision f_eerp_ind decision
F_CD_IND +--------------+ F_RELEASE_IND
| | F_RTR_RS | |
o=================o | o-----------------o
| |<-----------+ | |
| | | |
| | f_nerp_ind | |
| |------------+ | |
| | F_RTR_RS | | |
| | | | |
| |<-----------+ | |
| IDLE LISTENER | f_eerp_ind | IDLE LISTENER |
| (2) |<-----------------------------| (3) |
| | F_RTR_RS | CD_RQ |
| | | just sent |
| | f_nerp_ind | |
| |<-----------------------------| |
| | F_RTR_RS | |
| | | |
| | f_start_file_ind | |
| | and not P1 | |
| |---------------------+ | |
o=================o F_START_FILE_RS(-) | o-----------------o
A A | A A | | |
| | | | +-----------------------+ | |
| | | | | |
| | | | f_start_file_ind and not P1 | |
| | | +--------------------------------------+ |
| | | F_START_FILE_RS(-) |
| | | |
| | | f_start_file_ind f_start_file_ind |
| | | and P1 and P1 |
| | +----------------------------+ +------------------+
| | F_START_FILE_RS(+) | | F_START_FILE_RS(+)
| | V V
| | o---------------o
| |f_close_file_ind and not P3 | |
| +----------------------------| |
| F_CLOSE_FILE_RS(+,N) | |
| | DATA |
| | TRANSFER |
| f_close_file_ind and not P2 | |-------------+
+------------------------------| | |
F_CLOSE_FILE_RS(-) | |<------------+
o---------------o F_DATA_IND
o---------------o |
| IDLESPEAKER | f_close_file_ind and P3 |
| see (1), Spkr |<--------------------------+
| State Diagram | F_CLOSE_FILE_RS(+,Y)
o---------------o
Predicates:
P1: Decision to send F_START_FILE_RS(+)
P2: Decision to send F_CLOSE_FILE_RS(+)
P3: Decision to become Speaker
ODETTE-FTP is divided into five operating phases.
Odette-FTPは、5つの動作フェーズに分割されます。
Start Session Start File Data Transfer End File End Session
開始セッションスタートファイルデータ転送エンドファイルエンドセッション
After the End File phase, an ODETTE-FTP entity may enter a new Start File phase or terminate the session via the End Session phase.
終了ファイルフェーズの後、Odette-FTPエンティティは新しい開始ファイルフェーズを入力するか、終了セッションフェーズを介してセッションを終了することができます。
ODETTE-FTP peers communicate by sending and receiving messages in Exchange Buffers via the Network Service. Each Exchange Buffer contains one of the following commands.
Odette-FTPピアは、ネットワークサービスを介してバッファーでメッセージを送信および受信して通信します。各交換バッファには、次のコマンドのいずれかが含まれています。
SSRM Start Session Ready Message SSID Start Session SECD Security Change Direction AUCH Authentication Challenge AURP Authentication Response SFID Start File SFPA Start File Positive Answer SFNA Start File Negative Answer DATA Data CDT Set Credit EFID End File EFPA End File Positive Answer EFNA End File Negative Answer ESID End Session CD Change Direction EERP End to End Response NERP Negative End Response RTR Ready To Receive
SSRM START SESSION READYメッセージSSIDセッションSECDセキュリティの変更方向AUCH認証チャレンジAURP認証応答終了セッションCD CD変更方向EERPへの終了応答NERPネガティブエンド応答RTRを受信する準備ができています
The remainder of this section describes the protocol flows. Section five details the command formats.
このセクションの残りの部分では、プロトコルフローについて説明します。セクション5では、コマンド形式の詳細があります。
The Start Session phase is entered immediately after the network connection has been established.
ネットワーク接続が確立された直後に、開始セッションフェーズが入力されます。
The ODETTE-FTP entity that took the initiative to establish the network connection becomes the Initiator. Its peer becomes the Responder.
ネットワーク接続を確立するためにイニシアチブをとったOdette-FTPエンティティがイニシエーターになります。そのピアはレスポンダーになります。
The first message must be sent by the Responder.
最初のメッセージはレスポンダーから送信する必要があります。
1. Initiator <-------------SSRM -- Responder Ready Message -- SSID ------------> Identification <------------ SSID -- Identification
1. イニシエーター<------------- SSRM-レスポンダー対応メッセージ-SSID ----------->識別<------------SSID-識別
Having exchanged SSIDs, the Initiator may optionally begin an authentication phase, in which each party proves its identity to the other.
SSIDを交換した後、イニシエーターはオプションで認証フェーズを開始する場合があり、各当事者が他の関係者にそのアイデンティティを証明します。
The first authentication message must be sent by the Initiator.
最初の認証メッセージは、イニシエーターが送信する必要があります。
1. Initiator -- SECD ------------> Responder Change Direction <------------ AUCH -- Challenge -- AURP ------------> Response <------------ SECD -- Change Direction -- AUCH ------------> Challenge <------------ AURP -- Response
1. イニシエーター-SECD ----------->レスポンダーの変更方向<------------ auch-チャレンジ - aurp --------------------------------------------------- - > response <------------ secd-change方向 - auch -----------> choupled <---------------------------------------------aurp-応答
The Initiator sends a Security Change Direction (SECD) to which the Responder replies with an Authentication Challenge (AUCH).
イニシエーターは、認証チャレンジ（auch）で応答者が応答するセキュリティ変更方向（secd）を送信します。
The Responder looks up the public certificate that is linked to the purported identity of the Initiator (located in the SSID). If the Responder is unable to locate a suitable certificate then authentication fails. The Responder uses the public key contained in the certificate to encrypt a random challenge, unique for each session, for the Initiator. This encrypted challenge is sent as a [CMS] envelope to the Initiator as part of the AUCH.
レスポンダーは、イニシエーター（SSIDに位置する）の識別とされたアイデンティティにリンクされている公開証明書を調べます。応答者が適切な証明書を見つけることができない場合、認証は失敗します。レスポンダーは、証明書に含まれる公開キーを使用して、イニシエーターに対して、各セッションに一意のランダムな課題を暗号化します。この暗号化されたチャレンジは、auchの一部としてイニシエーターに[cms]封筒として送信されます。
The Initiator decrypts the challenge using their private key and sends the decrypted challenge back to the Responder in the Authentication Response (AURP).
イニシエーターは、秘密鍵を使用してチャレンジを解読し、復号化されたチャレンジを認証応答（AURP）のレスポンダーに送り返します。
The Responder checks that the data received in the AURP matches the random challenge that was sent to the Initiator.
Responderは、AURPで受信したデータがイニシエーターに送信されたランダムチャレンジと一致することをチェックします。
If the data matches, then the Initiator has authenticated successfully and the Responder replies with a Security Change Direction (SECD) beginning the complementary process of verifying the Responder to the Initiator. If the data does not match, then the Initiator fails authentication.
データが一致する場合、イニシエーターは正常に認証され、レスポンダーはセキュリティ変更方向（SECD）で応答し、レスポンダーをイニシエーターに検証する補完プロセスを開始します。データが一致しない場合、イニシエーターは認証に失敗します。
The Initiator from the Start Session phase is designated the Speaker while the Responder becomes the Listener. The roles are reversed by the Speaker sending a Change Direction command to the Listener.
開始セッションフェーズのイニシエーターはスピーカーに指定され、レスポンダーがリスナーになります。役割は、スピーカーがリスナーにChange Drieceコマンドを送信することによって逆転します。
1. Speaker -- SFID ------------> Listener Start File <------------ SFPA -- Answer YES
1. スピーカー-SFID ----------->リスナーの開始ファイル<------------ SFPA-回答はい
2. Speaker -- SFID ------------> Listener Start File <------------ SFNA -- Answer NO Go To 1
2. スピーカー-SFID ----------->リスナーの開始ファイル<------------ sfna-回答いいえ
Note: The User Monitor should take steps to prevent a loop situation occurring.
注：ユーザーモニターは、ループの状況が発生するのを防ぐための措置を講じる必要があります。
2. Speaker -- CD --------------> Listener Change Direction Listener <------------ EERP -- Speaker End to End Response -- RTR -------------> Ready to Receive <------------ NERP -- Negative End Response -- RTR -------------> Ready to Receive <------------ SFID -- Start File
2. スピーカー-CD ------------->リスナーの変更方向リスナー<------------ EERP-スピーカーエンドエンド応答 - RTR -------------->受信の準備<------------ NERP-ネガティブエンド応答 - RTR -----------><------------ sfid-ファイルを起動する準備ができています
The Start File command includes a count allowing the restart of an interrupted transmission to be negotiated. If restart facilities are not available, the restart count must be set to zero. The sender will start with the lowest record count + 1.
開始ファイルコマンドには、中断された送信の再起動を交渉できるカウントが含まれています。再起動施設が利用できない場合は、再起動カウントをゼロに設定する必要があります。送信者は、最も低いレコードカウント1から開始します。
The destination in a Start File command can be specified as follows.
開始ファイルコマンドの宛先は、次のように指定できます。
1. An explicitly defined destination.
1. 明示的に定義された宛先。
2. A group destination that allows an intermediate location to broadcast the Virtual File to multiple destinations.
2. 中間位置が仮想ファイルを複数の宛先にブロードキャストできるようにするグループ宛先。
The Listener will send a negative answer to the Speaker when the destination is not known.
リスナーは、目的地が知られていないときにスピーカーに否定的な答えを送信します。
The prioritisation of files for transmission is left to the local implementation. To allow some flexibility, a change direction mechanism is available in the End File phase.
送信用ファイルの優先順位付けは、ローカル実装に任されています。ある程度の柔軟性を可能にするために、エンドファイルフェーズで変更方向メカニズムを使用できます。
The End to End Response (EERP) command notifies the originator of a Virtual File that the Virtual File has been successfully delivered to its final destination. This allows the originator to perform house keeping tasks such as deleting copies of the delivered data.
End to End Response（EERP）コマンドは、仮想ファイルのオリジネーターに、仮想ファイルが最終目的地に正常に配信されたことを通知します。これにより、オリジネーターは、配信されたデータのコピーを削除するなどのハウスキーピングタスクを実行できます。
If the originator of the Virtual File requested a signed EERP in the SFID, the EERP must be signed. Signing allows the originator of the file to prove that the EERP was generated by the final destination. If the final destination is unable to sign the EERP, it may send back an unsigned EERP. It is an implementation issue to allow the acceptance of an unsigned EERP if a signed EERP is requested.
仮想ファイルのオリジネーターがSFIDで署名されたEERPを要求した場合、EERPに署名する必要があります。署名により、ファイルのオリジネーターは、EERPが最終目的地によって生成されたことを証明することができます。最終目的地がEERPに署名できない場合、署名されていないEERPを送り返す可能性があります。署名されたEERPが要求された場合、署名されていないEERPの受け入れを許可することは、実装の問題です。
A Response Command must be sent from the location performing the final processing or distribution of the data to the originator. The Response is mandatory and may be sent in the same or in any subsequent session.
応答コマンドは、データの最終処理または配布をオリジネーターに実行する場所から送信する必要があります。応答は必須であり、同じまたは後続のセッションで送信される場合があります。
When an intermediate location broadcasts or distributes a Virtual File, it must receive a Response command from all the locations to which it forwarded the data before sending its own Response. This ensures that the Response received by the Virtual File's originator accounts for all the destination locations. An intermediate location therefore needs to track the status of files it processes over time.
中間ロケーションが仮想ファイルをブロードキャストまたは配布する場合、独自の応答を送信する前にデータを転送するすべての場所から応答コマンドを受信する必要があります。これにより、仮想ファイルのオリジネーターが受け取った応答がすべての宛先の場所を説明することが保証されます。したがって、中間位置は、時間の経過とともに処理するファイルのステータスを追跡する必要があります。
The requesting of a signed EERP is incompatible with the use of broadcast facilities because an EERP can be signed by only one destination. If this scenario occurs, the intermediate broadcast location may continue and ignore the request for a signed EERP or send back a NERP.
署名されたEERPの要求は、EERPが1つの目的地で署名される可能性があるため、放送施設の使用と互換性がありません。このシナリオが発生した場合、中間ブロードキャストの場所は継続し、署名されたEERPのリクエストを無視するか、オタクを送り返すことができます。
Example: Point to Point
例：ポイントツーポイント
Location A sends file Ba to location B, which will send an EERP to location A after it successfully receives the file.
ロケーションAは、ファイルBAをロケーションBに送信します。これにより、ファイルが正常に受信された後、EERPが位置Aに送信されます。
o----------o o-----------o
| Loc. A |----------- S1 ---------->| Loc. B |
| | | |
| [Ba] |<---------- R2 -----------| [Ba] |
+----------o o-----------o
Key: S - File Transfer R - Response EERP [Ba] - File for B from A
キー：s-ファイル転送r-応答EERP [ba] - bからのファイル
Example: Data distribution
例：データ分布
Location A sends a Virtual File containing data for distribution to locations B and C via clearing centres E1 and E2. Clearing centre E1 must wait for a response from E2 (for file Ba) and location C before it sends its response, R8, to location A. Clearing centre E2 can only send response R7 to E1 when location B acknowledges file Ba with response R6.
位置Aは、クリアセンターE1およびE2を介して場所BとCへの配布のデータを含む仮想ファイルを送信します。クリアリングセンターE1は、応答を位置Aに送信する前に、E2（ファイルBAの場合）および位置Cからの応答を待つ必要があります。
o---------o o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S2 ->| Loc. E2 |-- S5 ->| Loc. B |
| | | | | | | |
| [Ba,Ca] |<- R8 --| [Ba,Ca] |<- R7 --| [Ba] |<- R6 --| [Ba] |
o---------o o---------o o---------o o---------o
A |
| | o---------o
| +----- S3 ->| Loc. C |
| | |
+--------- R4 --| [Ca] |
o---------o
Example: Data collection
例：データ収集
Locations A and B send files Ca and Cb to clearing centre E1, which forwards both files to location C in a single Virtual File. When it receives response R4 from C, clearing centre E1 sends response R5 to location A and R6 to location B.
場所AとBは、ファイルCAとCBをクリアリングセンターE1に送信します。センターE1は、両方のファイルを単一の仮想ファイルの位置Cに転送します。Cから応答R4を受信した場合、クリアリングセンターE1は応答R5を位置Aに、R6に位置Bに送信します。
o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S3 ->| Loc. C |
| | | | | |
| [Ca] |<- R5 --| [Ca,Cb] |<- R4 --| [Ca,Cb] |
o---------o o---------o o---------o
A |
o---------o | |
| Loc. B |-- S2 -----+ |
| | |
| [Cb] |<- R6 ---------+
o---------o
In addition to the EERP, which allows control over successful transmission of a file, a Negative End Response signals that a file could not be delivered to the final destination or that the final destination could not process the received file.
ファイルの成功した送信を制御できるEERPに加えて、ネガティブエンド応答は、ファイルを最終目的地に配信できないこと、または最終宛先が受信ファイルを処理できないことを示します。
It may be created by an intermediate node that could not transmit the file any further because the next node refuses to accept the file. The cause of the refusal has to be non-temporary, otherwise the intermediate node has to try the transmission again.
次のノードがファイルを受け入れることを拒否しているため、ファイルをこれ以上送信できなかった中間ノードによって作成される場合があります。拒否の原因は非同時でなければなりません。そうしないと、中間ノードは再度送信を試してみる必要があります。
It may also be created by the final node that is unable to process the file because of non-recoverable syntax or semantic errors in the file, or because of the failure of any other processing performed on the file.
また、ファイル内の非回復不可能な構文やセマンティックエラー、またはファイルで実行された他の処理の障害により、ファイルを処理できない最終ノードによって作成される場合があります。
The NERP will be sent back to the originator of the file.
NERPはファイルのオリジネーターに送り返されます。
The parameters are equal to the ones of the EERP, but with additional information about the creator of the NERP and the abort reason. Where the NERP is created due to a failure to transmit, the abort reason is taken from the refusal reason that was sent by the node refusing the file. Because of the NERP, it is possible for the intermediate node to stop trying to send the non-deliverable file and to delete the file.
パラメーターはEERPのパラメーターと等しくなりますが、NERPの作成者と中絶理由に関する追加情報があります。送信に失敗したためにオタクが作成された場合、中止された理由は、ファイルを拒否したノードによって送信された拒否理由から取得されます。NERPのため、中間ノードが配信不可能なファイルを送信してファイルを削除しようとするのを停止する可能性があります。
The NERP allows the originator of the file to react to the unsuccessful transmission or processing, depending on the reason code and the creator of the NERP.
NERPにより、ファイルの発信元は、NERPの理由と作成者に応じて、失敗した送信または処理に反応することができます。
If the originator of the Virtual File requested a signed EERP in the SFID, the NERP must be signed. Signing allows the originator of the file to prove by whom the NERP was generated. If the location generating the NERP is unable to sign the NERP, it may send back an unsigned NERP. It is an implementation issue to allow the acceptance of an unsigned EERP if a signed NERP is requested.
仮想ファイルのオリジネーターがSFIDで署名されたEERPを要求した場合、NERPに署名する必要があります。署名により、ファイルのオリジネーターがオタクがどのように生成されたかを証明することができます。NERPを生成する場所がNERPに署名できない場合、署名されていないNERPを送り返す可能性があります。署名されたNERPが要求された場合、署名されていないEERPの受け入れを許可することは、実装の問題です。
In order to avoid congestion between two adjacent nodes caused by a continuous flow of EERPs and NERPs, a Ready To Receive (RTR) command is provided. The RTR acts as an EERP/NERP acknowledgement for flow control but has no end-to-end significance.
EERPとオタクの連続的な流れによって引き起こされる2つの隣接するノード間の輻輳を回避するために、受信対象の（RTR）コマンドが提供されます。RTRは、フロー制御のEERP/NERPの確認として機能しますが、エンドツーエンドの重要性はありません。
Speaker -- EERP ------------> Listener End to End Response
<------------- RTR -- Ready to Receive
-- EERP ------------> End to End Response
<------------- RTR -- Ready to Receive
-- NERP ------------> Negative End Response
<------------- RTR -- Ready to Receive
-- SFID ------------> Start File
or
-- CD --------------> Exchange the turn
After sending an EERP or NERP, the Speaker must wait for an RTR before sending any other commands. The only acceptable commands to follow are:
EERPまたはNERPを送信した後、スピーカーは他のコマンドを送信する前にRTRを待つ必要があります。従うべき唯一の許容コマンドは次のとおりです。
EERP NERP SFID or CD (if there are no more EERPs or NERPs to be sent)
EERP NERP SFIDまたはCD（これ以上EERPSまたはNERPSが送信されない場合）
Virtual File data flows from the Speaker to the Listener during the Data Transfer phase, which is entered after the Start File phase.
仮想ファイルデータは、STARTファイルフェーズの後に入力されるデータ転送フェーズ中に、スピーカーからリスナーに流れます。
To avoid congestion at the protocol level, a flow control mechanism is provided via the Set Credit (CDT) command.
プロトコルレベルでの輻輳を回避するために、Set Credit（CDT）コマンドを介してフロー制御メカニズムが提供されます。
A Credit limit is negotiated in the Start Session phase; this represents the number of Data Exchange Buffers that the Speaker may send before it is obliged to wait for a Credit command from the Listener.
開始セッションフェーズでクレジット制限は交渉されます。これは、リスナーからのクレジットコマンドを待つ義務がある前に、スピーカーが送信する可能性のあるデータ交換バッファーの数を表します。
The available credit is initially set to the negotiated value by the Start File positive answer, which acts as an implicit Credit command. The Speaker decreases the available credit count by one for each data buffer sent to the Listener.
利用可能なクレジットは、最初に開始ファイルの肯定的な回答によってネゴシエートされた価値に設定されます。これは、暗黙のクレジットコマンドとして機能します。スピーカーは、リスナーに送信された各データバッファーに対して利用可能なクレジット数を1つ減らします。
When the available credit is exhausted, the Speaker must wait for a Credit command from the Listener; otherwise, a protocol error will occur and the session will be aborted.
利用可能なクレジットが使い果たされた場合、スピーカーはリスナーからのクレジットコマンドを待つ必要があります。それ以外の場合、プロトコルエラーが発生し、セッションが中止されます。
The Listener should endeavour to send the Credit command without delay to prevent the Speaker blocking.
リスナーは、スピーカーのブロックを防ぐために遅滞なくクレジットコマンドを送信するよう努力する必要があります。
1. Speaker -- SFID ------------> Listener Start File <------------ SFPA -- Answer YES
1. スピーカー-SFID ----------->リスナーの開始ファイル<------------ SFPA-回答はい
2. If the credit value is set to 2
2. クレジット価値が2に設定されている場合
Speaker -- Data ------------> Listener Start File
-- Data ------------>
<------------- CDT -- Set Credit
-- Data ------------>
-- EFID ------------> End File
The Speaker notifies the Listener that it has finished sending a Virtual File by sending an End File (EFID) command. The Listener replies with a positive or negative End File command and has the option to request a Change Direction command from the Speaker.
スピーカーは、Endファイル（EFID）コマンドを送信して仮想ファイルの送信が終了したことをリスナーに通知します。リスナーは、正または負のエンドファイルコマンドで返信し、スピーカーからChange Directionコマンドを要求するオプションがあります。
1. Speaker -- EFID ------------> Listener End File <------------ EFPA -- Answer YES
1. スピーカー-EFID ----------->リスナーエンドファイル<------------ EFPA-回答はい
2. Speaker -- EFID ------------> Listener End File <------------ EFPA -- Answer YES + CD -- CD --------------> Change Direction Listener <------------ EERP -- Speaker End to End Response -------------- RTR -> Ready to Receive Listener <------------ NERP -- Speaker Negative End Response -------------- RTR -> Ready to Receive Go to Start File Phase
2. スピーカー-EFID ------------>リスナーエンドファイル<------------ EFPA-回答はいCD-CD ------------->方向リスナーの変更<------------ EERP-スピーカーエンドエンド応答------------- RTR->リスナーを受け取る<------------ NERP-スピーカーネガティブエンド応答-------------- RTR->開始ファイルフェーズを受信する準備ができています
3. Speaker -- EFID ------------> Listener End File <------------ EFNA -- Answer NO
3. スピーカー - efid ----------->リスナーエンドファイル<------------ efna-回答番号
The Speaker terminates the session by sending an End Session (ESID) command. The Speaker may only do this if the Listener has just relinquished its role as speaker.
スピーカーは、終了セッション（ESID）コマンドを送信することによりセッションを終了します。スピーカーは、リスナーがスピーカーとしての役割を放棄したばかりの場合にのみこれを行うことができます。
1. Speaker -- EFID ------------> Listener End File <------------ EFPA -- Answer YES -- CD --------------> Change Direction Listener <------------ ESID -- Speaker End Session
1. スピーカー-EFID ------------>リスナーエンドファイル<------------ EFPA-回答はい - CD ------------->方向の変更リスナー<------------ ESID-スピーカーエンドセッション
Error detection and handling should be done as close as possible to the problem. This aids problem determination and correction. Each layer of the reference model is responsible for its own error handling.
エラーの検出と取り扱いは、問題にできるだけ近いことを行う必要があります。これにより、問題の決定と修正が支援されます。参照モデルの各レイヤーは、独自のエラー処理の原因です。
ODETTE-FTP can detect protocol errors by virtue of its state machine and uses activity timers to detect session hang conditions. These mechanisms are separate from the End to End controls.
Odette-FTPは、その状態マシンによりプロトコルエラーを検出し、アクティビティタイマーを使用してセッションハング条件を検出します。これらのメカニズムは、端から端のコントロールから分離されています。
If a protocol error occurs, the session will be terminated and application activity aborted. Both locations enter the IDLE state.
プロトコルエラーが発生した場合、セッションは終了し、アプリケーションアクティビティが中止されます。両方の場所がアイドル状態に入ります。
To protect against application and network hang conditions, ODETTE-FTP uses activity timers for all situations where a response is required. The timers and actions to be taken if they expire are described in Section 9, "Protocol State Machine".
アプリケーションおよびネットワークハング条件から保護するために、Odette-FTPは、応答が必要なすべての状況にアクティビティタイマーを使用します。有効期限が切れる場合に行われるタイマーとアクションは、セクション9「プロトコル状態マシン」に記載されています。
The use of clearing centres introduces the possibility of errors occurring as a result of data processing activities within the centre. Such errors are not directly related to ODETTE-FTP or the communication network and are therefore outside the scope of this specification.
クリアリングセンターの使用は、センター内のデータ処理アクティビティの結果として発生するエラーの可能性を導入します。このようなエラーは、Odette-FTPまたは通信ネットワークに直接関係していないため、この仕様の範囲外です。
ODETTE-FTP entities communicate via Exchange Buffers. The Command Exchange Buffers are described below. Virtual File data is carried in Data Exchange Buffers, which are described in Section 7.
Odette-FTPエンティティは、交換バッファーを介して通信します。コマンド交換バッファーを以下に説明します。仮想ファイルデータは、セクション7で説明されているデータ交換バッファーで伝達されます。
The basic unit of information is an octet, containing 8 bits.
情報の基本単位は、8ビットを含むオクテットです。
The ISO 646 IRV 7-bit coded character set [ISO-646], according to Appendix B, is used to encode constants and strings within Command Exchange Buffers except where [UTF-8] is explicitly indicated against a field.
付録Bによると、ISO 646 IRV 7ビットコード文字セット[ISO-646]は、[UTF-8]がフィールドに対して明示的に示されている場合を除き、コマンド交換バッファー内の定数と文字列をエンコードするために使用されます。
A Command Exchange Buffer contains a single command starting at the beginning of the buffer. Commands and data are never mixed within an Exchange Buffer. Commands cannot be compressed. Variable-length parameters may be omitted entirely if not required and the associated length indicator field set to zero.
コマンド交換バッファには、バッファの先頭から始まる単一のコマンドが含まれています。コマンドとデータは、交換バッファー内で混合されることはありません。コマンドを圧縮できません。変数長のパラメーターは、必要でない場合は完全に省略され、関連する長さインジケータフィールドがゼロに設定されます。
Components:
コンポーネント：
1. Command identifier:
1. コマンド識別子：
The first octet of an Exchange Buffer is the Command Identifier and defines the format of the buffer.
交換バッファの最初のオクテットはコマンド識別子であり、バッファの形式を定義します。
2. Parameter(s):
2. パラメーター）：
Command parameters are stored in fields within a Command Exchange Buffer. Where variable-length fields are used, they are preceded with a header field indicating the length. All values are required except where explicitly indicated.
コマンドパラメーターは、コマンド交換バッファー内のフィールドに保存されます。可変長さのフィールドが使用される場合、長さを示すヘッダーフィールドが前に行われます。明示的に示されている場合を除き、すべての値が必要です。
The ODETTE-FTP commands are described below using the following definitions.
Odette-FTPコマンドは、以下の定義を使用して以下に説明します。
Position (Pos)
位置（POS）
Field offset within the Command Exchange Buffer, relative to a zero origin.
コマンド交換バッファー内のフィールドオフセット、ゼロ起源と比較して。
Field
分野
The name of the field.
フィールドの名前。
Description
説明
A description of the field.
フィールドの説明。
Format
フォーマット
F - A field containing fixed values. All allowable values for the field are enumerated in the command definition.
F-固定値を含むフィールド。フィールドのすべての許容値は、コマンド定義で列挙されています。
V - A field with variable values within a defined range. For example, the SFIDLRECL field may contain any integer value between 00000 and 99999.
V-定義範囲内の変動値を持つフィールド。たとえば、SFIDLRECLフィールドには、00000〜99999の整数値が含まれている場合があります。
X(n) - An alphanumeric field of length n octets.
x（n） - 長さnオクテットの英数字フィールド。
A String contains alphanumeric characters from the following set:
文字列には、次のセットからの英数字の文字が含まれています。
The numerals: 0 to 9 The upper case letters: A to Z The following special set: / - . & ( ) space.
数字：0〜9大文字の文字：aからz次の特別なセット： / - 。＆ （ ） 空。
Space is not allowed as an embedded character.
スペースは埋め込まれた文字として許可されていません。
9(n) - A numeric field of length n octets.
9（n） - 長さnオクテットの数値フィールド。
U(n) - A binary field of length n octets.
u（n） - 長さnオクテットのバイナリフィールド。
Numbers encoded as binary are always unsigned and in network byte order.
バイナリとしてエンコードされた数値は、常に署名されておらず、ネットワークバイトの順序です。
T(n) - An field of length n octets, encoded using [UTF-8].
T（N） - [UTF -8]を使用してエンコードされた長さnオクテットのフィールド。
String and alphanumeric fields are always left justified and right padded with spaces where needed.
弦と英数字のフィールドは常に正当化され、必要に応じてスペースで右にパッドで塗られます。
Numeric fields are always right justified and left padded with zeros where needed.
数値フィールドは常に正当化され、必要に応じてゼロでパッドで埋められたままです。
Reserved fields should be padded with spaces.
予約済みのフィールドには、スペースが付いている必要があります。
o-------------------------------------------------------------------o
| SSRM Start Session Ready Message |
| |
| Start Session Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSRMCMD | SSRM Command, 'I' | F X(1) |
| 1 | SSRMMSG | Ready Message, 'ODETTE FTP READY ' | F X(17) |
| 18 | SSRMCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
SSRMCMD Command Code Character
SSRMCMDコマンドコード文字
Value: 'I' SSRM Command identifier.
値： 'I' SSRMコマンド識別子。
SSRMMSG Ready Message String(17)
ssrmmsg対応メッセージ文字列（17）
Value: 'ODETTE FTP READY '
値：「Odette FTP Ready」
SSRMCR Carriage Return Character
SSRMCRキャリッジリターン文字
Value: Character with hex value '0D' or '8D'.
値：hex値 '0D'または '8D'を持つキャラクター。
o-------------------------------------------------------------------o
| SSID Start Session |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SSIDCMD | SSID Command 'X' | F X(1) |
| 1 | SSIDLEV | Protocol Release Level | F 9(1) |
| 2 | SSIDCODE | Initiator's Identification Code | V X(25) |
| 27 | SSIDPSWD | Initiator's Password | V X(8) |
| 35 | SSIDSDEB | Data Exchange Buffer Size | V 9(5) |
| 40 | SSIDSR | Send / Receive Capabilities (S/R/B) | F X(1) |
| 41 | SSIDCMPR | Buffer Compression Indicator (Y/N) | F X(1) |
| 42 | SSIDREST | Restart Indicator (Y/N) | F X(1) |
| 43 | SSIDSPEC | Special Logic Indicator (Y/N) | F X(1) |
| 44 | SSIDCRED | Credit | V 9(3) |
| 47 | SSIDAUTH | Secure Authentication (Y/N) | F X(1) |
| 48 | SSIDRSV1 | Reserved | F X(4) |
| 52 | SSIDUSER | User Data | V X(8) |
| 60 | SSIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
SSIDCMD Command Code Character
SSIDCMDコマンドコード文字
Value: 'X' SSID Command identifier.
値： 'X' SSIDコマンド識別子。
SSIDLEV Protocol Release Level Numeric(1)
SSIDLEVプロトコルリリースレベル数値（1）
Used to specify the level of the ODETTE-FTP protocol
Odette-FTPプロトコルのレベルを指定するために使用されます
Value: '1' for Revision 1.2 '2' for Revision 1.3 '4' for Revision 1.4 '5' for Revision 2.0
値：リビジョン1.2 '2'改訂式1.3 '4'リビジョン1.4 '5'のリビジョン2.0の場合は '1'
Future release levels will have higher numbers. The protocol release level is negotiable, with the lowest level being selected.
将来のリリースレベルの数は高くなります。プロトコルリリースレベルは交渉可能で、最低レベルが選択されています。
Note: ODETTE File Transfer Protocol 1.3 (RFC 2204) specifies '1' for the release level, despite adhering to revision 1.3.
注：Odetteファイル転送プロトコル1.3（RFC 2204）は、リリービング1.3を順守しているにもかかわらず、リリースレベルに「1」を指定します。
SSIDCODE Initiator's Identification Code String(25)
ssidcodeイニシエーターの識別コード文字列（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
Uniquely identifies the Initiator (sender) participating in the ODETTE-FTP session.
Odette-FTPセッションに参加しているイニシエーター（送信者）を独自に識別します。
It is an application implementation issue to link the expected [X.509] certificate to the SSIDCODE provided.
予想される[X.509]証明書を提供されたSSIDCodeにリンクするためのアプリケーション実装の問題です。
SSIDPSWD Initiator's Password String(8)
SSIDPSWDイニシエーターのパスワード文字列（8）
Key to authenticate the sender. Assigned by bilateral agreement.
送信者を認証する鍵。二国間協定によって割り当てられます。
SSIDSDEB Data Exchange Buffer Size Numeric(5)
SSIDSDEBデータ交換バッファーサイズ数値（5）
Minimum: 128 Maximum: 99999
最小：128最大：99999
The length, in octets, of the largest Data Exchange Buffer that can be accepted by the location. The length includes the command octet but does not include the Stream Transmission Header.
オクテットの長さは、場所で受け入れることができる最大のデータ交換バッファーの長さ。長さにはコマンドオクテットが含まれていますが、ストリームトランスミッションヘッダーは含まれません。
After negotiation, the smallest size will be selected.
交渉後、最小サイズが選択されます。
SSIDSR Send / Receive Capabilities Character
SSIDSRは機能を送信 /受信文字を送信 /受信します
Value: 'S' Location can only send files. 'R' Location can only receive files. 'B' Location can both send and receive files.
値： 's'場所はファイルのみを送信できます。「R」場所はファイルのみを受信できます。「B」の場所は、ファイルを送信および受信できます。
Sending and receiving will be serialised during the session, so parallel transmissions will not take place in the same session.
セッション中に送信と受信はシリアル化されるため、同じセッションでは並列送信は行われません。
An error occurs if adjacent locations both specify the send or receive capability.
隣接する場所が送信または受信機能を指定する場合、エラーが発生します。
SSIDCMPR Buffer Compression Indicator Character
SSIDCMPRバッファー圧縮インジケータ文字
Value: 'Y' The location can handle OFTP data buffer compression 'N' The location cannot handle OFTP buffer compression
値：「Y」場所はOFTPデータバッファ圧縮を処理できます 'n' OFTPバッファー圧縮を処理できません
Compression is only used if supported by both locations.
圧縮は、両方の場所でサポートされている場合にのみ使用されます。
The compression mechanism referred to here applies to each individual OFTP data buffer. This is different from the file compression mechanism in OFTP, which involves the compression of whole files.
ここで言及されている圧縮メカニズムは、個々のOFTPデータバッファーに適用されます。これは、OFTPのファイル圧縮メカニズムとは異なり、ファイル全体の圧縮を伴います。
SSIDREST Restart Indicator Character
ssidrest再起動インジケーター文字
Value: 'Y' The location can handle the restart of a partially transmitted file. 'N' The location cannot restart a file.
値：「Y」場所は、部分的に送信されたファイルの再起動を処理できます。'n'場所はファイルを再起動できません。
SSIDSPEC Special Logic Indicator Character
SSIDSPEC特別論理インジケーター文字
Value: 'Y' Location can handle Special Logic 'N' Location cannot handle Special Logic
値：「Y」場所は特別な論理を処理できます 'n'場所は特別なロジックを処理できません
Special Logic is only used if supported by both locations.
特別なロジックは、両方の場所でサポートされている場合にのみ使用されます。
The Special Logic extensions are only useful to access an X.25 network via an asynchronous entry and are not supported for TCP/IP connections.
特別なロジック拡張機能は、非同期エントリを介してX.25ネットワークにアクセスするのにのみ役立ち、TCP/IP接続にはサポートされていません。
SSIDCRED Credit Numeric(3)
SSIDCREDクレジット数値（3）
Maximum: 999
最大：999
The number of consecutive Data Exchange Buffers sent by the Speaker before it must wait for a Credit (CDT) command from the Listener.
スピーカーがリスナーからクレジット（CDT）コマンドを待つ必要がある前に、スピーカーから送信される連続したデータ交換バッファーの数。
The credit value is only applied to Data flow in the Data Transfer phase.
クレジット値は、データ転送フェーズのデータフローにのみ適用されます。
The Speaker's available credit is initialised to SSIDCRED when it receives a Start File Positive Answer (SFPA) command from the Listener. It is zeroed by the End File (EFID) command.
スピーカーの利用可能なクレジットは、リスナーからSTARTファイルの肯定的な回答（SFPA）コマンドを受信したときにSSIDCREDに初期化されます。Endファイル（EFID）コマンドによってゼロになります。
After negotiation, the smallest size must be selected in the answer of the Responder, otherwise a protocol error will abort the session.
交渉後、最小サイズをレスポンダーの回答で選択する必要があります。そうしないと、プロトコルエラーがセッションを中止します。
Negotiation of the "credit-window-size" parameter.
「クレジットウィンドウサイズ」パラメーターの交渉。
Window Size m -- SSID ------------>
<------------ SSID -- Window Size n
(n less than or
equal to m)
Note: negotiated value will be "n".
SSIDAUTH Secure Authentication Character
Ssidauthセキュア認証文字
Value: 'Y' The location requires secure authentication. 'N' The location does not require secure authentication.
値：「Y」場所には安全な認証が必要です。'n'場所には安全な認証は必要ありません。
Secure authentication is only used if agreed by both locations.
安全な認証は、両方の場所で合意された場合にのみ使用されます。
If the answer of the Responder does not match with the authentication requirements of the Initiator, then the Initiator must abort the session.
応答者の回答がイニシエーターの認証要件と一致しない場合、イニシエーターはセッションを中止する必要があります。
No negotiation of authentication is allowed.
認証の交渉は許可されていません。
authentication p -- SSID ------------>
<------------ SSID -- authentication q
p == q -> continue. p != q -> abort.
p == q->続行。p！= q->中断。
SSIDRSV1 Reserved String(4)
ssidrsv1予約文字列（4）
This field is reserved for future use.
このフィールドは、将来の使用のために予約されています。
SSIDUSER User Data String(8)
ssiduserユーザーデータ文字列（8）
May be used by ODETTE-FTP in any way. If unused, it should be initialised to spaces. It is expected that a bilateral agreement exists as to the meaning of the data.
Odette-FTPでは何らかの方法で使用できます。使用されていない場合は、スペースに初期化する必要があります。データの意味に関して二国間契約が存在することが予想されます。
SSIDCR Carriage Return Character
SSIDCRキャリッジリターン文字
Value: Character with hex value '0D' or '8D'.
値：hex値 '0D'または '8D'を持つキャラクター。
o-------------------------------------------------------------------o
| SFID Start File |
| |
| Start File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFIDCMD | SFID Command, 'H' | F X(1) |
| 1 | SFIDDSN | Virtual File Dataset Name | V X(26) |
| 27 | SFIDRSV1 | Reserved | F X(3) |
| 30 | SFIDDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 38 | SFIDTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 48 | SFIDUSER | User Data | V X(8) |
| 56 | SFIDDEST | Destination | V X(25) |
| 81 | SFIDORIG | Originator | V X(25) |
| 106 | SFIDFMT | File Format (F/V/U/T) | F X(1) |
| 107 | SFIDLRECL | Maximum Record Size | V 9(5) |
| 112 | SFIDFSIZ | File Size, 1K blocks | V 9(13) |
| 125 | SFIDOSIZ | Original File Size, 1K blocks | V 9(13) |
| 138 | SFIDREST | Restart Position | V 9(17) |
| 155 | SFIDSEC | Security Level | F 9(2) |
| 157 | SFIDCIPH | Cipher suite selection | F 9(2) |
| 159 | SFIDCOMP | File compression algorithm | F 9(1) |
| 160 | SFIDENV | File enveloping format | F 9(1) |
| 161 | SFIDSIGN | Signed EERP request | F X(1) |
| 162 | SFIDDESCL | Virtual File Description length | V 9(3) |
| 165 | SFIDDESC | Virtual File Description | V T(n) |
o-------------------------------------------------------------------o
SFIDCMD Command Code Character
SFIDCMDコマンドコード文字
Value: 'H' SFID Command identifier.
値： 'H' SFIDコマンド識別子。
SFIDDSN Virtual File Dataset Name String(26)
sfiddsn仮想ファイルデータセット名文字列（26）
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
データセット名は、二国間契約によって割り当てられている仮想ファイルの名前。
No general structure is defined for this attribute.
この属性の一般的な構造は定義されていません。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
SFIDRSV1 Reserved String(3)
sfidrsv1予約文字列（3）
This field is reserved for future use.
このフィールドは、将来の使用のために予約されています。
SFIDDATE Virtual File Date stamp Numeric(8)
sfiddate仮想ファイル日付スタンプ数値（8）
Format: 'CCYYMMDD' 8 decimal digits representing the century, year, month, and day.
形式： 'ccyymmdd'世紀、年、月、日を表す8桁。
Date stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
仮想ファイルのオリジネーターによって割り当てられた日付スタンプは、ファイルがいつ送信できるようになったかを示しています。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
SFIDTIME Virtual File Time stamp Numeric(10)
sfidtime仮想ファイルタイムスタンプ数値（10）
Format: 'HHMMSScccc' 10 decimal digits representing hours, minutes, seconds, and a counter (0001-9999), which gives higher resolution.
形式： 'HHMMSSCCCC'時間、数分、秒、およびカウンター（0001-9999）を表す10桁の10桁。
Time stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
仮想ファイルのオリジネーターによって割り当てられたタイムスタンプは、ファイルがいつ送信できるようになったかを示しています。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
SFIDUSER User Data String(8)
sfiduserユーザーデータ文字列（8）
May be used by ODETTE-FTP in any way. If unused, it should be initialised to spaces. It is expected that a bilateral agreement exists as to the meaning of the data.
Odette-FTPでは何らかの方法で使用できます。使用されていない場合は、スペースに初期化する必要があります。データの意味に関して二国間契約が存在することが予想されます。
SFIDDEST Destination String(25)
sfiddest宛先文字列（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
The Final Recipient of the Virtual File.
仮想ファイルの最終受信者。
This is the location that will look into the Virtual File content and perform mapping functions. It is also the location that creates the End to End Response (EERP) command for the received file.
これは、仮想ファイルコンテンツを調べ、マッピング関数を実行する場所です。また、受信したファイルのEnd to End Response（EERP）コマンドを作成する場所でもあります。
SFIDORIG Originator String(25)
Sfidorig Originator String（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
Originator of the Virtual File.
仮想ファイルのオリジネーター。
It is the location that created (mapped) the data for transmission.
これは、送信用のデータを作成（マッピング）した場所です。
SFIDFMT File Format Character
sfidfmtファイル形式文字
Value: 'F' Fixed format binary file 'V' Variable format binary file 'U' Unstructured binary file 'T' Text
値： 'f'固定形式バイナリファイル 'v'変数形式バイナリファイル 'u'非構造化バイナリファイル 't'テキスト
Virtual File format. Used to calculate the restart position (Section 1.5.4).
仮想ファイル形式。再起動位置を計算するために使用されます（セクション1.5.4）。
Once a file has been signed, compressed, and/or encrypted, in file format terms it becomes unstructured, format U. The record boundaries are no longer discernable until the file is decrypted, decompressed, and/or verified. SFID File Format Field in this scenario indicates the format of the original file, and the transmitted file must be treated as U format.
ファイルが署名、圧縮、および/または暗号化されたら、ファイル形式の用語では、構造化されていない形式です。このシナリオのSFIDファイル形式フィールドは、元のファイルの形式を示し、送信されたファイルはU形式として扱う必要があります。
SFIDLRECL Maximum Record Size Numeric(5)
sfidlrecl最大レコードサイズ数値（5）
Maximum: 99999
最大：99999
Length in octets of the longest logical record that may be transferred to a location. Only user data is included.
場所に転送される可能性のある最長の論理レコードのオクテットの長さ。ユーザーデータのみが含まれています。
If SFIDFMT is 'T' or 'U', then this attribute must be set to '00000'.
SFIDFMTが「T」または「U」の場合、この属性は「00000」に設定する必要があります。
If SFIDFMT is 'V' and the file is compressed, encrypted, or signed, then the maximum value of SFIDRECL is '65536'.
SFIDFMTが「V」であり、ファイルが圧縮、暗号化、または署名されている場合、SFIDRECLの最大値は「65536」です。
SFIDFSIZ Transmitted File Size Numeric(13)
sfidfsiz送信ファイルサイズ数値（13）
Maximum: 9999999999999
最大：999999999999
Space in 1K (1024 octet) blocks required at the Originator location to store the actual Virtual File that is to be transmitted.
送信される実際の仮想ファイルを保存するために、オリジナルの場所で必要な1K（1024オクテット）ブロックのスペース。
For example, if a file is compressed before sending, then this is the space required to store the compressed file.
たとえば、送信前にファイルが圧縮されている場合、これは圧縮ファイルを保存するために必要なスペースです。
This parameter is intended to provide only a good estimate of the Virtual File size.
このパラメーターは、仮想ファイルサイズの適切な推定のみを提供することを目的としています。
Using 13 digits allows for a maximum file size of approximately 9.3 PB (petabytes) to be transmitted.
13桁を使用すると、最大ファイルサイズが約9.3 pb（ペタバイト）を送信できます。
SFIDOSIZ Original File Size Numeric(13)
sfidosizオリジナルファイルサイズ数値（13）
Maximum: 9999999999999
最大：999999999999
Space in 1K (1024 octet) blocks required at the Originator location to store the original before it was signed, compressed, and/or encrypted.
オリジナルの場所で必要な1K（1024オクテット）ブロックのスペースは、署名、圧縮、および/または暗号化される前にオリジナルを保存するために必要です。
If no security or compression services have been used, SFIDOSIZ should contain the same value as SFIDFSIZ.
セキュリティまたは圧縮サービスが使用されていない場合、SFIDOSIZにはSFIDFSIZと同じ値を含める必要があります。
If the original file size is not known, the value zero should be used.
元のファイルサイズが不明な場合は、値ゼロを使用する必要があります。
This parameter is intended to provide only a good estimate of the original file size.
このパラメーターは、元のファイルサイズの適切な推定のみを提供することを目的としています。
The sequence of events in file exchange are:
ファイル交換の一連のイベントは次のとおりです。
(a) raw data file ready to be sent SFIDOSIZ = Original File Size
(a) 生データファイルを送信する準備ができているsfidosiz =元のファイルサイズ
(b) signing/compression/encryption
(b) 署名/圧縮/暗号化
(c) transmission SFIDFSIZ = Transmitted File Size
(c) 送信SFIDFSIZ =送信ファイルサイズ
(d) decryption/decompression/verification
(d) 復号化/減圧/検証
(e) received raw data file for in-house applications SFIDOSIZ = Original File Size
(e) 社内アプリケーション用の生データファイルを受信sfidosiz =元のファイルサイズ
The Transmitted File Size at (c) indicates to the receiver how much storage space is needed to receive the file.
（c）の送信されたファイルサイズは、ファイルを受信するために必要なストレージスペースの量を受信者に示します。
The Original File Size at (e) indicates to the in-house application how much storage space is needed to process the file.
（e）の元のファイルサイズは、ファイルを処理するために必要なストレージスペースの量を社内アプリケーションに示します。
SFIDREST Restart Position Numeric(17)
sfidrest再起動位置数値（17）
Maximum: 99999999999999999
最大：9999999999999999
Virtual File restart position.
仮想ファイルの再起動位置。
The count represents the: - Record Number if SSIDFMT is 'F' or 'V'. - File offset in 1K (1024 octet) blocks if SFIDFMT is 'U' or 'T'.
カウントは、次のものを表します。 -SSID FMTの記録数は「F」または「V」です。-SFID FMTの1K（1024 Octet）ブロックのファイルオフセットは「U」または「T」です。
The count will express the transmitted user data (i.e., before ODETTE-FTP buffer compression, header not included).
カウントは、送信されたユーザーデータを表現します（つまり、Odette-FTPバッファー圧縮の前、ヘッダーは含まれていません）。
After negotiation between adjacent locations, retransmission will start at the lowest value.
隣接する場所間の交渉の後、再送信は最低値から開始されます。
Once a file has been signed, compressed, and/or encrypted, in file format terms, it has become unstructured, like format U. The file should be treated as format U for the purposes of restart, regardless of the actual value in SFIDFMT.
ファイルがファイル形式の用語で署名、圧縮、および/または暗号化されたら、Format Uのように構造化されていません。ファイルは、SFIDFMTの実際の値に関係なく、再起動の目的でフォーマットuとして扱う必要があります。
SFIDSEC Security Level Numeric(2)
SFIDSECセキュリティレベル数値（2）
Value: '00' No security services '01' Encrypted '02' Signed '03' Encrypted and signed
値： '00'セキュリティサービスなし '01'暗号化された02 '署名' 03 '暗号化されて署名
Indicates whether the file has been signed and/or encrypted before transmission. (See Section 6.2.)
ファイルが送信前に署名および/または暗号化されたかどうかを示します。（セクション6.2を参照してください。）
SFIDCIPH Cipher suite selection Numeric(2)
sfidciph暗号スイート選択数値（2）
Value: '00' No security services '01' See Section 10.2
値： '00'セキュリティサービスなし '01'セクション10.2を参照してください
Indicates the cipher suite used to sign and/or encrypt the file and also to indicate the cipher suite that should be used when a signed EERP or NERP is requested.
ファイルに署名および/または暗号化するために使用されるCipherスイート、および署名されたEERPまたはNERPが要求されたときに使用する必要がある暗号スイートを示すために使用されることを示します。
SFIDCOMP File compression algorithm Numeric(1)
SFIDCOMPファイル圧縮アルゴリズム数値（1）
Value: '0' No compression '1' Compressed with [ZLIB] algorithm
値： '0'圧縮なし '1' [zlib]アルゴリズムで圧縮
Indicates the algorithm used to compress the file. (See Section 6.4.)
ファイルを圧縮するために使用されるアルゴリズムを示します。（セクション6.4を参照してください。）
SFIDENV File enveloping format Numeric(1)
sfidenvファイル封筒フォーマット数値（1）
Value: '0' No envelope '1' File is enveloped using [CMS]
値： '0' envelope '1'ファイルは[cms]を使用して包み込まれます
Indicates the enveloping format used in the file.
ファイルで使用されている封筒形式を示します。
If the file is encrypted/signed/compressed or is an enveloped file for the exchange and revocation of certificates, this field must be set accordingly.
ファイルが暗号化/署名/圧縮されているか、証明書の交換と取り消しのための包括的なファイルである場合、このフィールドはそれに応じて設定する必要があります。
SFIDSIGN Signed EERP request Character
SFIDSIGN署名されたEERP要求文字
Value: 'Y' The EERP returned in acknowledgement of the file must be signed 'N' The EERP must not be signed
値：「Y」ファイルの承認で返されたEERPに署名する必要があります。
Requests whether the EERP returned for the file must be signed.
ファイルのEERPが返されたかどうかを要求する必要があります。
SFIDDESCL Virtual File Description length Numeric(3)
sfiddescl仮想ファイルの説明長さ数字（3）
Length in octets of the field SFIDDESC.
フィールドsfiddescのオクテットの長さ。
A value of 0 indicates that no description is present.
0の値は、説明が存在しないことを示します。
SFIDDESC Virtual File Description [UTF-8](n)
SFIDDESC仮想ファイル説明[UTF-8]（n）
May be used by ODETTE-FTP in any way. If not used, SFIDDESCL should be set to zero.
Odette-FTPでは何らかの方法で使用できます。使用していない場合は、SFIDDESCLをゼロに設定する必要があります。
No general structure is defined for this attribute, but it is expected that a bilateral agreement exists as to the meaning of the data.
この属性に対して一般的な構造は定義されていませんが、データの意味に関して二国間合意が存在すると予想されます。
It is encoded using [UTF-8] to support a range of national languages.
[UTF-8]を使用してエンコードされ、さまざまな国語をサポートしています。
Maximum length of the encoded value is 999 octets.
エンコードされた値の最大長は999オクテットです。
o-------------------------------------------------------------------o
| SFPA Start File Positive Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFPACMD | SFPA Command, '2' | F X(1) |
| 1 | SFPAACNT | Answer Count | V 9(17) |
o-------------------------------------------------------------------o
SFPACMD Command Code Character
SFPACMDコマンドコード文字
Value: '2' SFPA Command identifier.
値： '2' SFPAコマンド識別子。
SFPAACNT Answer Count Numeric(17)
sfpaacnt回答数値（17）
The Listener must enter a count lower than or equal to the restart count specified by the Speaker in the Start File (SFID) command. The count expresses the received user data. If restart facilities are not available, a count of zero must be specified.
リスナーは、STAREファイル（SFID）コマンドのスピーカーによって指定された再起動カウント以下のカウント以下を入力する必要があります。カウントは、受信したユーザーデータを表現します。再起動施設が利用できない場合は、ゼロのカウントを指定する必要があります。
o-------------------------------------------------------------------o
| SFNA Start File Negative Answer |
| |
| Start File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SFNACMD | SFNA Command, '3' | F X(1) |
| 1 | SFNAREAS | Answer Reason | F 9(2) |
| 3 | SFNARRTR | Retry Indicator, (Y/N) | F X(1) |
| 4 | SFNAREASL | Answer Reason Text Length | V 9(3) |
| 7 | SFNAREAST | Answer Reason Text | V T(n) |
o-------------------------------------------------------------------o
SFNACMD Command Code Character
SFNACMDコマンドコード文字
Value: '3' SFNA Command identifier.
値： '3' SFNAコマンド識別子。
SFNAREAS Answer Reason Numeric(2)
sfnareas回答理由数値（2）
Value: '01' Invalid filename. '02' Invalid destination. '03' Invalid origin. '04' Storage record format not supported. '05' Maximum record length not supported. '06' File size is too big. '10' Invalid record count. '11' Invalid byte count. '12' Access method failure. '13' Duplicate file. '14' File direction refused. '15' Cipher suite not supported. '16' Encrypted file not allowed. '17' Unencrypted file not allowed. '18' Compression not allowed. '19' Signed file not allowed. '20' Unsigned file not allowed. '99' Unspecified reason.
値： '01'無効なファイル名。'02'無効な宛先。'03'無効な起源。'04'ストレージレコード形式はサポートされていません。'05'最大レコード長はサポートされていません。「06」ファイルサイズが大きすぎます。「10」無効なレコードカウント。'11'無効なバイトカウント。「12」アクセスメソッドの障害。'13'複製ファイル。「14」ファイルの指示は拒否されました。'15'暗号スイートはサポートされていません。'16'暗号化されたファイルは許可されていません。'17'暗号化されていないファイルは許可されていません。'18'圧縮は許可されていません。「19」署名されたファイルは許可されていません。'20'署名されていないファイルは許可されていません。'99'不特定の理由。
Reason why transmission cannot proceed.
トランスミッションが進むことができない理由。
SFNARRTR Retry Indicator Character
SFNARRTR RETRYインジケーター文字
Value: 'N' Transmission should not be retried. 'Y' The transmission may be retried later.
値： 'n'トランスミッションを再試行しないでください。「Y」トランスミッションは後で再試行される場合があります。
This parameter is used to advise the Speaker if it should retry at a later time due to a temporary condition at the Listener site, such as a lack of storage space. It should be used in conjunction with the Answer Reason code (SFNAREAS).
このパラメーターは、ストレージスペースの不足などのリスナーサイトでの一時的な状態のために、後で再試行する必要がある場合、スピーカーにアドバイスするために使用されます。Answer Reason Code（SFNAREAS）と組み合わせて使用する必要があります。
An invalid file name error code may be the consequence of a problem in the mapping of the Virtual File on to a real file. Such problems cannot always be resolved immediately. It is therefore recommended that when an SFNA with Retry = Y is received the User Monitor attempts to retransmit the relevant file in a subsequent session.
無効なファイル名エラーコードは、仮想ファイルを実際のファイルにマッピングする際の問題の結果である可能性があります。このような問題を常にすぐに解決することはできません。したがって、retry = yのSFNAを受信すると、ユーザーモニターが後続のセッションで関連ファイルを再送信しようとすることをお勧めします。
SFNAREASL Answer Reason Text Length Numeric(3)
sfnareasl回答理由テキスト長さ数値（3）
Length in octets of the field SFNAREAST.
フィールドのオクテットの長さsfnareast。
0 indicates that no SFNAREAST field follows.
0は、sfnareastフィールドが続くことがないことを示します。
SFNAREAST Answer Reason Text [UTF-8](n)
sfnareast回答理由テキスト[utf-8]（n）
Reason why transmission cannot proceed in plain text.
伝送が平易なテキストで進行できない理由。
It is encoded using [UTF-8].
[UTF-8]を使用してエンコードされています。
Maximum length of the encoded reason is 999 octets.
エンコードされた理由の最大長は999オクテットです。
No general structure is defined for this attribute.
この属性の一般的な構造は定義されていません。
o-------------------------------------------------------------------o
| DATA Data Exchange Buffer |
| |
| Data Transfer Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | DATACMD | DATA Command, 'D' | F X(1) |
| 1 | DATABUF | Data Exchange Buffer payload | V U(n) |
o-------------------------------------------------------------------o
DATACMD Command Code Character
datacmdコマンドコード文字
Value: 'D' DATA Command identifier.
値：「d」データコマンド識別子。
DATABUF Data Exchange Buffer payload Binary(n)
DataBuf Data Exchange Bufferペイロードバイナリ（n）
Variable-length buffer containing the data payload. The Data Exchange Buffer is described in Section 7.
データペイロードを含む可変長バッファー。データ交換バッファーについては、セクション7で説明します。
o-------------------------------------------------------------------o
| CDT Set Credit |
| |
| Data Transfer Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | CDTCMD | CDT Command, 'C' | F X(1) |
| 1 | CDTRSV1 | Reserved | F X(2) |
o-------------------------------------------------------------------o
CDTCMD Command Code Character
CDTCMDコマンドコード文字
Value: 'C' CDT Command identifier.
値： 'C' CDTコマンド識別子。
CDTRSV1 Reserved String(2)
cdtrsv1予約文字列（2）
This field is reserved for future use.
このフィールドは、将来の使用のために予約されています。
o-------------------------------------------------------------------o
| EFID End File |
| |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFIDCMD | EFID Command, 'T' | F X(1) |
| 1 | EFIDRCNT | Record Count | V 9(17) |
| 18 | EFIDUCNT | Unit Count | V 9(17) |
o-------------------------------------------------------------------o
EFIDCMD Command Code Character
EFIDCMDコマンドコード文字
Value: 'T' EFID Command identifier.
値： 't' efidコマンド識別子。
EFIDRCNT Record Count Numeric(17)
efidrcntレコードカウント数値（17）
Maximum: 99999999999999999
最大：9999999999999999
For SSIDFMT 'F' or 'V', the exact record count. For SSIDFMT 'U' or 'T', zeros.
ssidfmt 'f'または 'v'の場合、正確なレコードがカウントされます。ssidfmt 'u'または 't'の場合、ゼロ。
The count will express the real size of the file (before buffer compression, header not included). The total count is always used, even during restart processing.
カウントは、ファイルの実際のサイズを表現します（バッファ圧縮の前、ヘッダーは含まれていません）。再起動処理中であっても、合計カウントは常に使用されます。
EFIDUCNT Unit Count Numeric(17)
efiducnt unitカウント数値（17）
Maximum: 99999999999999999
最大：9999999999999999
Exact number of units (octets) transmitted.
送信されたユニットの正確な数（オクテット）。
The count will express the real size of the file. The total count is always used, even during restart processing.
カウントはファイルの実際のサイズを表現します。再起動処理中であっても、合計カウントは常に使用されます。
o-------------------------------------------------------------------o
| EFPA End File Positive Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFPACMD | EFPA Command, '4' | F X(1) |
| 1 | EFPACD | Change Direction Indicator, (Y/N) | F X(1) |
o-------------------------------------------------------------------o
EFPACMD Command Code Character
EFPACMDコマンドコード文字
Value: '4' EFPA Command identifier.
値： '4' EFPAコマンド識別子。
EFPACD Change Direction Indicator Character
EFPACD変更方向インジケータ文字
Value: 'N' Change direction not requested. 'Y' Change direction requested.
値： 'および「要求されていない方向を変更します。'A'変更方向が要求されました。
This parameter allows the Listener to request a Change Direction (CD) command from the Speaker.
このパラメーターにより、リスナーはスピーカーに変更方向（CD）コマンドを要求できます。
o-------------------------------------------------------------------o
| EFNA End File Negative Answer |
| |
| End File Phase Speaker <---- Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EFNACMD | EFNA Command, '5' | F X(1) |
| 1 | EFNAREAS | Answer Reason | F 9(2) |
| 3 | EFNAREASL | Answer Reason Text Length | V 9(3) |
| 6 | EFNAREAST | Answer Reason Text | V T(n) |
o-------------------------------------------------------------------o
EFNACMD Command Code Character
EFNACMDコマンドコード文字
Value: '5' EFNA Command identifier.
値： '5' EFNAコマンド識別子。
EFNAREAS Answer Reason Numeric(2)
efnareas回答理由数値（2）
Value: '01' Invalid filename. '02' Invalid destination. '03' Invalid origin. '04' Storage record format not supported. '05' Maximum record length not supported. '06' File size is too big. '10' Invalid record count. '11' Invalid byte count. '12' Access method failure. '13' Duplicate file. '14' File direction refused. '15' Cipher suite not supported. '16' Encrypted file not allowed. '17' Unencrypted file not allowed. '18' Compression not allowed. '19' Signed file not allowed. '20' Unsigned file not allowed. '21' Invalid file signature. '22' File decryption failure. '23' File decompression failure. '99' Unspecified reason.
値： '01'無効なファイル名。'02'無効な宛先。'03'無効な起源。'04'ストレージレコード形式はサポートされていません。'05'最大レコード長はサポートされていません。「06」ファイルサイズが大きすぎます。「10」無効なレコードカウント。'11'無効なバイトカウント。「12」アクセスメソッドの障害。'13'複製ファイル。「14」ファイルの指示は拒否されました。'15'暗号スイートはサポートされていません。'16'暗号化されたファイルは許可されていません。'17'暗号化されていないファイルは許可されていません。'18'圧縮は許可されていません。「19」署名されたファイルは許可されていません。'20'署名されていないファイルは許可されていません。'21'無効なファイル署名。'22'ファイル復号化障害。'23'ファイル減圧障害。'99'不特定の理由。
Reason why transmission failed.
送信が失敗した理由。
EFNAREASL Answer Reason Text Length Numeric(3)
efnareasl回答理由テキスト長さ数値（3）
Length in octets of the field EFNAREAST.
フィールドのオクテットの長さEfnareast。
0 indicates that no EFNAREAST field follows.
0は、efnareastフィールドが続いていないことを示します。
EFNAREAST Answer Reason Text [UTF-8](n)
Efnareast Answer Reason Text [utf-8]（n）
Reason why transmission failed in plain text.
トランスミッションがプレーンテキストで失敗した理由。
It is encoded using [UTF-8].
[UTF-8]を使用してエンコードされています。
Maximum length of the encoded reason is 999 octets.
エンコードされた理由の最大長は999オクテットです。
No general structure is defined for this attribute.
この属性の一般的な構造は定義されていません。
o-------------------------------------------------------------------o
| ESID End Session |
| |
| End Session Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | ESIDCMD | ESID Command, 'F' | F X(1) |
| 1 | ESIDREAS | Reason Code | F 9(2) |
| 3 | ESIDREASL | Reason Text Length | V 9(3) |
| 6 | ESIDREAST | Reason Text | V T(n) |
| | ESIDCR | Carriage Return | F X(1) |
o-------------------------------------------------------------------o
ESIDCMD Command Code Character
ESIDCMDコマンドコード文字
Value: 'F' ESID Command identifier.
値： 'f' esidコマンド識別子。
ESIDREAS Reason Code Numeric(2)
esidReas理由コード数値（2）
Value: '00' Normal session termination
値： '00'通常のセッション終了
'01' Command not recognised
'01'コマンドは認識されていません
An Exchange Buffer contains an invalid command code (1st octet of the buffer).
Exchange Bufferには、無効なコマンドコード（バッファの最初のオクテット）が含まれています。
'02' Protocol violation
'02'プロトコル違反
An Exchange Buffer contains an invalid command for the current state of the receiver.
Exchangeバッファには、受信機の現在の状態の無効なコマンドが含まれています。
'03' User code not known
'03'ユーザーコードは不明です
A Start Session (SSID) command contains an unknown or invalid Identification Code.
開始セッション（SSID）コマンドには、不明または無効な識別コードが含まれています。
'04' Invalid password
'04'無効なパスワード
A Start Session (SSID) command contained an invalid password.
開始セッション（SSID）コマンドには、無効なパスワードが含まれていました。
'05' Local site emergency close down
'05'ローカルサイトの緊急時
The local site has entered an emergency close down mode. Communications are being forcibly terminated.
ローカルサイトは緊急のクローズダウンモードに入りました。通信は強制的に終了しています。
'06' Command contained invalid data
'06'コマンドには無効なデータが含まれていました
A field within a Command Exchange Buffer contains invalid data.
コマンド交換バッファ内のフィールドには、無効なデータが含まれています。
'07' Exchange Buffer size error
'07'バッファサイズエラーを交換します
The length of the Exchange Buffer as determined by the Stream Transmission Header differs from the length implied by the Command Code.
ストリームトランスミッションヘッダーによって決定される交換バッファーの長さは、コマンドコードによって暗示される長さとは異なります。
'08' Resources not available
'08'リソースは利用できません
The request for connection has been denied due to a resource shortage. The connection attempt should be retried later.
リソースの不足により、接続の要求は拒否されました。接続の試行は後で再試行する必要があります。
'09' Time out
'09'タイムアウト
'10' Mode or capabilities incompatible
「10」モードまたは機能は互換性がありません
'11' Invalid challenge response
「11」無効なチャレンジ応答
'12' Secure authentication requirements incompatible
「12」安全な認証要件は互換性がありません
'99' Unspecified Abort code
'99'不特定の中止コード
An error was detected for which no specific code is defined.
特定のコードが定義されていないエラーが検出されました。
ESIDREASL Reason Text Length Numeric(3)
esidreasl理由テキスト長さ数値（3）
Length in octets of the field ESIDREAST.
フィールドのオクテットの長さは、esidreast。
0 indicates that no ESIDREAST field is present.
0は、eSidreastフィールドが存在しないことを示します。
ESIDREAST Reason Text [UTF-8](n)
ESIDREAST REASON TEXT [UTF-8]（n）
Reason why session ended in plain text.
セッションがプレーンテキストで終了した理由。
It is encoded using [UTF-8].
[UTF-8]を使用してエンコードされています。
Maximum length of the encoded reason is 999 octets.
エンコードされた理由の最大長は999オクテットです。
No general structure is defined for this attribute.
この属性の一般的な構造は定義されていません。
ESIDCR Carriage Return Character
ESIDCRキャリッジリターン文字
Value: Character with hex value '0D' or '8D'.
値：hex値 '0D'または '8D'を持つキャラクター。
o-------------------------------------------------------------------o
| CD Change Direction |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
| End Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | CDCMD | CD Command, 'R' | F X(1) |
o-------------------------------------------------------------------o
CDCMD Command Code Character
CDCMDコマンドコード文字
Value: 'R' CD Command identifier.
値： 'R' CDコマンド識別子。
o-------------------------------------------------------------------o
| EERP End to End Response |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | EERPCMD | EERP Command, 'E' | F X(1) |
| 1 | EERPDSN | Virtual File Dataset Name | V X(26) |
| 27 | EERPRSV1 | Reserved | F X(3) |
| 30 | EERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 38 | EERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 48 | EERPUSER | User Data | V X(8) |
| 56 | EERPDEST | Destination | V X(25) |
| 81 | EERPORIG | Originator | V X(25) |
| 106 | EERPHSHL | Virtual File hash length | V U(2) |
| 108 | EERPHSH | Virtual File hash | V U(n) |
| | EERPSIGL | EERP signature length | V U(2) |
| | EERPSIG | EERP signature | V U(n) |
o-------------------------------------------------------------------o
EERPCMD Command Code Character
Value: 'E' EERP Command identifier.
値： 'e' eerpコマンド識別子。
EERPDSN Virtual File Dataset Name String(26)
eerpdsn仮想ファイルデータセット名文字列（26）
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
データセット名は、二国間契約によって割り当てられている仮想ファイルの名前。
No general structure is defined for this attribute.
この属性の一般的な構造は定義されていません。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
EERPRSV1 Reserved String(3)
eerprsv1予約文字列（3）
This field is reserved for future use.
このフィールドは、将来の使用のために予約されています。
EERPDATE Virtual File Date stamp Numeric(8)
eerpdate仮想ファイル日付スタンプ数値（8）
Format: 'CCYYMMDD' 8 decimal digits representing the century, year, month, and day, respectively.
形式： 'ccyymmdd'それぞれ、それぞれ世紀、月、日を表す8桁。
Date stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
仮想ファイルのオリジネーターによって割り当てられた日付スタンプは、ファイルがいつ送信できるようになったかを示しています。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
EERPTIME Virtual File Time stamp Numeric(10)
EERPTIME仮想ファイルタイムスタンプ数値（10）
Format: 'HHMMSScccc' 10 decimal digits representing hours, minutes, seconds, and a counter (0001-9999), which gives higher resolution.
形式： 'HHMMSSCCCC'時間、数分、秒、およびカウンター（0001-9999）を表す10桁の10桁。
Time stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
仮想ファイルのオリジネーターによって割り当てられたタイムスタンプは、ファイルがいつ送信できるようになったかを示しています。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
EERPUSER User Data String(8)
Eerpuserユーザーデータ文字列（8）
May be used by ODETTE-FTP in any way. If unused, it should be initialised to spaces. It is expected that a bilateral agreement exists as to the meaning of the data.
Odette-FTPでは何らかの方法で使用できます。使用されていない場合は、スペースに初期化する必要があります。データの意味に関して二国間契約が存在することが予想されます。
EERPDEST Destination String(25)
eerpdest宛先文字列（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
Originator of the Virtual File.
仮想ファイルのオリジネーター。
This is the location that created the data for transmission.
これは、送信用のデータを作成した場所です。
EERPORIG Originator String(25)
Eerporig Originator String（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
Final Recipient of the Virtual File.
仮想ファイルの最終受信者。
This is the location that will look into the Virtual File content and process it accordingly. It is also the location that creates the EERP for the received file.
これは、仮想ファイルのコンテンツを調べてそれに応じて処理する場所です。また、受信したファイルのEERPを作成する場所でもあります。
EERPHSHL Virtual File hash length Binary(2)
eerphshl仮想ファイルハッシュ長さバイナリ（2）
Length in octets of the field EERPHSH.
フィールドEerphshのオクテットの長さ。
A binary value of 0 indicates that no hash is present. This is always the case if the EERP is not signed.
0のバイナリ値は、ハッシュが存在しないことを示します。EERPが署名されていない場合、これは常に当てはまります。
EERPHSH Virtual File hash Binary(n)
eerphsh仮想ファイルハッシュバイナリ（n）
Hash of the transmitted Virtual File, i.e., not the hash of the original file.
送信された仮想ファイルのハッシュ、つまり元のファイルのハッシュではありません。
The algorithm used is determined by the bilaterally agreed cipher suite specified in the SFIDCIPH.
使用されるアルゴリズムは、SFIDCIPHで指定された二国間で合意された暗号スイートによって決定されます。
It is an application implementation issue to validate the EERPHSH to ensure that the EERP is acknowledging the exact same file as was originally transmitted.
EERPHSを検証して、EERPが元々送信されたのとまったく同じファイルを確認していることを確認するためのアプリケーションの実装の問題です。
EERPSIGL EERP signature length Binary(2)
Eerpsigl EERP署名長バイナリ（2）
0 indicates that this EERP has not been signed.
0は、このEERPが署名されていないことを示します。
Any other value indicates the length of EERPSIG in octets and indicates that this EERP has been signed.
他の値は、オクテットのeerpsigの長さを示し、このEERPが署名されたことを示します。
EERPSIG EERP signature Binary(n)
eerpsig eerp signature binary（n）
Contains the [CMS] enveloped signature of the EERP.
EERPの[CMS]包括的な署名が含まれています。
Signature = Sign{EERPDSN EERPDATE EERPTIME EERPDEST EERPORIG EERPHSH}
署名= sign {eerpdsn eerpdate eerptime eerpdest eerporig eerphsh}}}
Each field is taken in its entirety, including any padding. The envelope must contain the original data, not just the signature.
各フィールドには、パディングを含め、その全体が撮影されています。封筒には、署名だけでなく、元のデータが含まれている必要があります。
The [CMS] content type used is SignedData.
使用される[CMS]コンテンツタイプはSignedDataです。
The encapsulated content type used is id-data.
使用されるカプセル化されたコンテンツタイプはID-DATAです。
It is an application issue to validate the signature with the contents of the EERP.
EERPの内容を使用して署名を検証することはアプリケーションの問題です。
o-------------------------------------------------------------------o
| NERP Negative End Response |
| |
| Start File Phase Speaker ----> Listener |
| End File Phase Speaker ----> Listener |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | NERPCMD | NERP Command, 'N' | F X(1) |
| 1 | NERPDSN | Virtual File Dataset Name | V X(26) |
| 27 | NERPRSV1 | Reserved | F X(6) |
| 33 | NERPDATE | Virtual File Date stamp, (CCYYMMDD) | V 9(8) |
| 41 | NERPTIME | Virtual File Time stamp, (HHMMSScccc) | V 9(10) |
| 51 | NERPDEST | Destination | V X(25) |
| 76 | NERPORIG | Originator | V X(25) |
| 101 | NERPCREA | Creator of NERP | V X(25) |
| 126 | NERPREAS | Reason code | F 9(2) |
| 128 | NERPREASL | Reason text length | V 9(3) |
| 131 | NERPREAST | Reason text | V T(n) |
| | NERPHSHL | Virtual File hash length | V U(2) |
| | NERPHSH | Virtual File hash | V U(n) |
| | NERPSIGL | NERP signature length | V U(2) |
| | NERPSIG | NERP signature | V U(n) |
o-------------------------------------------------------------------o
NERPCMD Command Code Character
Value: 'N' NERP Command identifier.
値： 'n' nerpコマンド識別子。
NERPDSN Virtual File Dataset Name String(26)
nerpdsn仮想ファイルデータセット名文字列（26）
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
データセット名は、二国間契約によって割り当てられている仮想ファイルの名前。
No general structure is defined for this attribute.
この属性の一般的な構造は定義されていません。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
NERPRSV1 Reserved String(6)
nerprsv1予約文字列（6）
This field is reserved for future use.
このフィールドは、将来の使用のために予約されています。
NERPDATE Virtual File Date stamp Numeric(8)
nerpdate仮想ファイル日付スタンプ数値（8）
Format: 'CCYYMMDD' 8 decimal digits representing the century, year, month, and day, respectively.
形式： 'ccyymmdd'それぞれ、それぞれ世紀、月、日を表す8桁。
Date stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
仮想ファイルのオリジネーターによって割り当てられた日付スタンプは、ファイルがいつ送信できるようになったかを示しています。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
NERPTIME Virtual File Time stamp Numeric(10)
nerptime仮想ファイルタイムスタンプ数値（10）
Format: 'HHMMSScccc' 10 decimal digits representing hours, minutes, seconds, and a counter (0001-9999), which gives higher resolution.
形式： 'HHMMSSCCCC'時間、数分、秒、およびカウンター（0001-9999）を表す10桁の10桁。
Time stamp assigned by the Virtual File's Originator indicating when the file was made available for transmission.
仮想ファイルのオリジネーターによって割り当てられたタイムスタンプは、ファイルがいつ送信できるようになったかを示しています。
See Virtual Files - Identification (Section 1.5.2)
仮想ファイルを参照 - 識別（セクション1.5.2）
NERPDEST Destination String(25)
nerpdest宛先文字列（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
Originator of the Virtual File.
仮想ファイルのオリジネーター。
This is the location that created the data for transmission.
これは、送信用のデータを作成した場所です。
NERPORIG Originator String(25)
nerporig Originator String（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
The Final Recipient of the Virtual File.
仮想ファイルの最終受信者。
This is the location that will look into the Virtual File content and perform mapping functions.
これは、仮想ファイルコンテンツを調べ、マッピング関数を実行する場所です。
NERPCREA Creator of the NERP String(25)
NERP弦のネルプクレア作成者（25）
Format: See Identification Code (Section 5.4)
形式：識別コード（セクション5.4）を参照してください
It is the location that created the NERP.
オタクを作成したのは場所です。
NERPREAS Reason code Numeric(2)
nerpreas理由コード数値（2）
This attribute will specify why transmission cannot proceed or why processing of the file failed.
この属性は、送信が続行できない理由、またはファイルの処理が失敗した理由を指定します。
"SFNA(RETRY=N)" below should be interpreted as "EFNA or SFNA(RETRY=N)" where appropriate.
「sfna（retry = n）」は、必要に応じて「efnaまたはsfna（retry = n）」と解釈する必要があります。
Value '03' ESID received with reason code '03' (user code not known) '04' ESID received with reason code '04' (invalid password) '09' ESID received with reason code '99' (unspecified reason) '11' SFNA(RETRY=N) received with reason code '01' (invalid file name) '12' SFNA(RETRY=N) received with reason code '02' (invalid destination) '13' SFNA(RETRY=N) received with reason code '03' (invalid origin) '14' SFNA(RETRY=N) received with reason code '04' (invalid storage record format) '15' SFNA(RETRY=N) received with reason code '05' (maximum record length not supported) '16' SFNA(RETRY=N) received with reason code '06' (file size too big) '20' SFNA(RETRY=N) received with reason code '10' (invalid record count) '21' SFNA(RETRY=N) received with reason code '11' (invalid byte count) '22' SFNA(RETRY=N) received with reason code '12' (access method failure)
Value '03' esid reason code '03'（ユーザーコードは不明） '04' esid esed with reason code '04'（無効なパスワード） '09' esid esed with reason code '99'（不特定の理由）'11'sfna（retry = n）reason code' 01 '（無効なファイル名）' 12 'sfna（retry = n）sfna（retry = n）reason code' 02 '（無効な宛先）' 13 'sfna（retry = n）理由コード '03'（無効な起源） '14' sfna（retry = n）reason code '04'（無効なストレージレコード形式） '15' sfna（retry = n）reason code '05'（最大レコードで受信）サポートされていない長さ） '16' sfna（retry = n）理由コードで受信した '06'（ファイルサイズが大きすぎる）sfna（retry = n）reason code '11'（無効なバイトカウント） '22' sfna（retry = n）reason code '12'（アクセスメソッド障害）
'23' SFNA(RETRY=N) received with reason code '13' (duplicate file) '24' SFNA(RETRY=N) received with reason code '14' (file direction refused) '25' SFNA(RETRY=N) received with reason code '15' (cipher suite not supported) '26' SFNA(RETRY=N) received with reason code '16' (encrypted file not allowed) '27' SFNA(RETRY=N) received with reason code '17' (unencrypted file not allowed) '28' SFNA(RETRY=N) received with reason code '18' (compression not allowed) '29' SFNA(RETRY=N) received with reason code '19' (signed file not allowed) '30' SFNA(RETRY=N) received with reason code '20' (unsigned file not allowed) '31' File signature not valid. '32' File decompression failed. '33' File decryption failed. '34' File processing failed. '35' Not delivered to recipient. '36' Not acknowledged by recipient. '50' Transmission stopped by the operator. '90' File size incompatible with recipient's protocol version. '99' Unspecified reason.
'23' SFNA（RETRY = N）Reason Code '13'（重複ファイル） '24' SFNA（Retry = n）Reason Code '14'（ファイル指示拒否） '25' SFNA（Retry = n）Reason Code '15'（Cipher Suiteがサポートされていない）で受信した '26' SFNA（RETRY = N）Reason Code '16'（暗号化されたファイルが許可されていない） '27' SFNA（RETRY = N）Reason Code '17で受信'（暗号化されていないファイルが許可されていない）' 28 'SFNA（RETRY = N）理由コード' 18 '（圧縮は許可されていない）' 29 'SFNA（retry = n）reason code' 19 'で受信した（signedファイルが許可されていない）'30' sfna（retry = n）reason code '20'（unsignedファイルが許可されていない）で受信した '31'ファイル署名は無効です。'32'ファイル減圧は失敗しました。'33'ファイルの復号化は失敗しました。'34'ファイル処理に失敗しました。'35'受信者に配達されません。「36」は受信者によって認められていません。'50'トランスミッションはオペレーターによって停止しました。'90'ファイルサイズは、受信者のプロトコルバージョンと互換性がありません。'99'不特定の理由。
NERPREASL Reason Text Length Numeric(3)
NERPREASL理由テキストの長さ数値（3）
Length in octets of the field NERPREAST.
フィールドのオクテットの長さnerpreast。
0 indicates that no NERPREAST field follows.
0は、nerpreastフィールドが続くことがないことを示します。
NERPREAST Reason Text [UTF-8](n)
nerpreast理由テキスト[utf-8]（n）
Reason why transmission cannot proceed in plain text.
伝送が平易なテキストで進行できない理由。
It is encoded using [UTF-8].
[UTF-8]を使用してエンコードされています。
Maximum length of the encoded reason is 999 octets.
エンコードされた理由の最大長は999オクテットです。
No general structure is defined for this attribute.
この属性の一般的な構造は定義されていません。
NERPHSHL Virtual File hash length Binary(2)
nerphshl仮想ファイルハッシュ長さバイナリ（2）
Length in octets of the field NERPHSH.
フィールドナルフシュのオクテットの長さ。
A binary value of 0 indicates that no hash is present. This is always the case if the NERP is not signed.
0のバイナリ値は、ハッシュが存在しないことを示します。これは、オタクに署名されていない場合は常に当てはまります。
NERPHSH Virtual File hash Binary(n)
nerphsh仮想ファイルハッシュバイナリ（n）
Hash of the Virtual File being transmitted.
送信される仮想ファイルのハッシュ。
The algorithm used is determined by the bilaterally agreed cipher suite specified in the SFIDCIPH.
使用されるアルゴリズムは、SFIDCIPHで指定された二国間で合意された暗号スイートによって決定されます。
NERPSIGL NERP Signature length Binary(2)
nerpsigl nerp signature length binary（2）
0 indicates that this NERP has not been signed.
0は、このオタクが署名されていないことを示します。
Any other value indicates the length of NERPSIG in octets and indicates that this NERP has been signed.
他の値は、オクテットのnerpsigの長さを示し、このオタクが署名されていることを示します。
NERPSIG NERP Signature Binary(n)
nerpsig nerp signature binary（n）
Contains the [CMS] enveloped signature of the NERP.
[CMS]包囲された署名が含まれています。
Signature = Sign{NERPDSN NERPDATE NERPTIME NERPDEST NERPORIG NERPCREA NERPHSH}
署名= sign {nerpdsn nerpdate nerptime nerpdest nerporig nerpcrea nerphsh}}}
Each field is taken in its entirety, including any padding. The envelope must contain the original data, not just the signature.
各フィールドには、パディングを含め、その全体が撮影されています。封筒には、署名だけでなく、元のデータが含まれている必要があります。
The [CMS] content type used is SignedData.
使用される[CMS]コンテンツタイプはSignedDataです。
The encapsulated content type used is id-data.
使用されるカプセル化されたコンテンツタイプはID-DATAです。
It is an application issue to validate the signature with the contents of the NERP.
署名をNERPの内容を検証するためのアプリケーションの問題です。
o-------------------------------------------------------------------o
| RTR Ready To Receive |
| |
| Start File Phase Initiator <---- Responder |
| End File Phase Initiator <---- Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | RTRCMD | RTR Command, 'P' | F X(1) |
o-------------------------------------------------------------------o
RTRCMD Command Code Character
RTRCMDコマンドコード文字
Value: 'P' RTR Command identifier.
値： 'P' RTRコマンド識別子。
o-------------------------------------------------------------------o
| SECD Security Change Direction |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SECDCMD | SECD Command, 'J' | F X(1) |
o-------------------------------------------------------------------o
SECDCMD Command Code Character
SECDCMDコマンドコード文字
Value: 'J' SECD Command identifier.
値： 'J' secdコマンド識別子。
o-------------------------------------------------------------------o
| AUCH Authentication Challenge |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | AUCHCMD | AUCH Command, 'A' | F X(1) |
| 1 | AUCHCHLL | Challenge Length | V U(2) |
| 3 | AUCHCHAL | Challenge | V U(n) |
o-------------------------------------------------------------------o
AUCHCMD Command Code Character
Value: 'A' AUCH Command identifier.
値： 'a' auchコマンド識別子。
AUCHCHLL Challenge length Binary(2)
auchchllチャレンジ長バイナリ（2）
Indicates the length of AUCHCHAL in octets.
オクテット中のauchchalの長さを示します。
The length is expressed as an unsigned binary number using network byte order.
長さは、ネットワークバイト順序を使用して、署名されていないバイナリ番号として表されます。
AUCHCHAL Challenge Binary(n)
auchchalチャレンジバイナリ（n）
A [CMS] encrypted 20-byte random number uniquely generated each time an AUCH is sent.
[cms]は、auchが送信されるたびに一意に生成される20バイトの乱数を1バイトの乱数で暗号化しました。
NOTE:
ノート：
Any encryption algorithm that is available through a defined cipher suite (Section 10.2) may be used. See Section 10.1 regarding the choice of a cipher suite.
定義された暗号スイート（セクション10.2）を介して利用可能な暗号化アルゴリズムを使用できます。暗号スイートの選択については、セクション10.1を参照してください。
o-------------------------------------------------------------------o
| AURP Authentication Response |
| |
| Start Session Phase Initiator <---> Responder |
|-------------------------------------------------------------------|
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | AURPCMD | AURP Command, 'S' | F X(1) |
| 1 | AURPRSP | Response | V U(20) |
o-------------------------------------------------------------------o
AURPCMD Command Code Character
aurpcmdコマンドコード文字
Value: 'S' AURP Command identifier.
値： 'S' AURPコマンド識別子。
AURPRSP Response Binary(20)
aurprsp応答バイナリ（20）
Contains the decrypted challenge (AUCHCHAL).
復号化されたチャレンジ（Auchchal）が含まれています。
IMPORTANT:
重要：
It is an application implementation issue to validate a received AURP to ensure that the response matches the challenge. This validation is extremely important to ensure that a party is correctly authenticated.
受信したオーープを検証して、応答がチャレンジと一致するようにすることは、アプリケーションの実装の問題です。この検証は、当事者が正しく認証されていることを確認するために非常に重要です。
The Initiator (sender) and Responder (receiver) participating in an ODETTE-FTP session are uniquely identified by an Identification Code based on [ISO-6523], Structure for the Identification of Organisations (SIO). The locations are considered to be adjacent for the duration of the transmission.
Odette-FTPセッションに参加するイニシエーター（送信者）とレスポンダー（受信者）は、[ISO-6523]に基づく識別コード、組織の識別のための構造（SIO）によって一意に識別されます。場所は、送信期間中、隣接すると見なされます。
The SIO has the following format.
SIOには次の形式があります。
o-------------------------------------------------------------------o
| Pos | Field | Description | Format |
|-----+-----------+---------------------------------------+---------|
| 0 | SIOOID | ODETTE Identifier | F X(1) |
| 1 | SIOICD | International Code Designator | V 9(4) |
| 5 | SIOORG | Organisation Code | V X(14) |
| 19 | SIOCSA | Computer Subaddress | V X(6) |
o-------------------------------------------------------------------o
SIOOID ODETTE Identifier Character
siooiod odette識別子文字
Value: 'O' Indicates ODETTE assigned Organisation Identifier. Other values may be used for non-ODETTE codes.
値： 'o'は、Odetteが割り当てられた組織識別子を示します。他の値は、オデット以外のコードに使用される場合があります。
SIOICD International Code Designator String(4)
Sioicd International Code Deconitator String（4）
A code forming part of the Organisation Identifier.
組織識別子の一部を形成するコード。
SIOORG Organisation Code String(14)
Sioorg組織コード文字列（14）
A code forming part of the Organisation Identifier. This field may contain the letters A to Z, the digits 0 to 9, and space and hyphen characters.
組織識別子の一部を形成するコード。このフィールドには、文字AからZ、数字0〜9、およびスペースとハイフンの文字が含まれている場合があります。
SIOCSA Computer Subaddress String(6)
siocsaコンピューターサブアドレス文字列（6）
A locally assigned address that uniquely identifies a system within an organisation (defined by an Organisation Identifier).
組織内のシステムを一意に識別するローカルに割り当てられたアドレス（組織識別子によって定義されています）。
ODETTE-FTP provides services for compressing, encrypting, and signing files. These services should generally be performed off line, outside of the ODETTE-FTP communications session for performance reasons, although this is not a strict requirement.
Odette-FTPは、ファイルを圧縮、暗号化、署名するためのサービスを提供します。これらのサービスは通常、パフォーマンス上の理由でOdette-FTP通信セッションの外で、オフラインで実行する必要がありますが、これは厳しい要件ではありません。
ODETTE-FTP requires that the following steps must be performed in this exact sequence, although any of steps 2, 3, or 4 may be omitted. Step 1 is required only if any of steps 2, 3, or 4 are performed:
Odette-FTPでは、この正確なシーケンスで次の手順を実行する必要がありますが、手順2、3、または4のいずれかは省略できます。ステップ1は、ステップ2、3、または4のいずれかが実行される場合にのみ必要です。
1. Insert record length indicators (V format files only; see Section 6.5) 2. Sign 3. Compress 4. Encrypt
1. レコード長インジケーターを挿入します（Vフォーマットファイルのみ;セクション6.5を参照）2。署名3.圧縮4.暗号化
The cipher suite for the encryption and signing algorithms is assigned by bilateral agreement.
暗号化および署名アルゴリズムの暗号スイートは、二国間契約によって割り当てられます。
Secured and/or compressed files must be enveloped. The envelope contains additional information about the service used that is necessary for a receiving party to fully process the file.
セキュリティ済みファイルおよび/または圧縮ファイルを包み込む必要があります。エンベロープには、受信者がファイルを完全に処理するために必要な使用されるサービスに関する追加情報が含まれています。
The [CMS] content types used are:
使用される[CMS]コンテンツタイプは次のとおりです。
EnvelopedData - Indicates encrypted data CompressedData - Indicates compressed data SignedData - Indicates signed content Data - Indicates unstructured data
EnvelopedData-暗号化されたデータCompresdDataを示します - 圧縮データSignedDataを示します - 署名されたコンテンツデータを示します - 非構造化データを示します
For signed or encrypted data, the encapsulated content type (eContentType field) is id-data.
署名または暗号化されたデータの場合、カプセル化されたコンテンツタイプ（econtentTypeフィールド）はID-DATAです。
Files that are to be signed are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
署名されるファイルは、ファイルエンベロープ形式（SFIDENV）に従って包まれています。一般的に、これは[CMS]パッケージとして行われます。
A file may be signed more than once to ease the changeover between old and new certificates.
古い証明書と新しい証明書の間の切り替えを容易にするために、ファイルに複数回署名される場合があります。
It is recommended that the envelope does not contain the public certificate of the signer. Where files are sent to the same recipient continuously, it would serve no benefit to repeatedly send the same certificate. Both the original file data and signature are stored within the [CMS] package.
封筒には署名者の公開証明書が含まれていないことが推奨されます。ファイルが同じ受信者に継続的に送信される場合、同じ証明書を繰り返し送信することは利益をもたらさないでしょう。元のファイルデータと署名の両方が[CMS]パッケージ内に保存されます。
Files that are to be encrypted are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
暗号化されるファイルは、ファイルエンベロープ形式（SFIDENV）に従って包まれています。一般的に、これは[CMS]パッケージとして行われます。
It is recommended that encryption should be performed before the ODETTE-FTP session starts because a large file takes a long time to encrypt and could cause session time outs, even on high-performance machines.
大規模なファイルが暗号化に長い時間がかかり、高性能マシンでもセッションタイムアウトを引き起こす可能性があるため、Odette-FTPセッションが開始する前に暗号化を実行することをお勧めします。
Likewise, decryption of the file should occur outside of the session. However, an application may choose to allow in-session encryption and decryption for very small files.
同様に、ファイルの復号化はセッションの外部で発生するはずです。ただし、アプリケーションは、非常に小さなファイルのセッション内暗号化と復号化を許可することを選択する場合があります。
Files that are to be compressed are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package using the [CMS-Compression] data type, which uses the [ZLIB] compression algorithm by default.
圧縮されるファイルは、ファイルエンベロープ形式（SFIDENV）に従って包み込まれます。一般に、これは[CMS-Compression]データ型を使用した[CMS]パッケージとして、デフォルトで[ZLIB]圧縮アルゴリズムを使用します。
Unlike the buffer compression method, this method operates on a whole file. Because of the increased levels of compression, file level compression essentially deprecates the older buffer compression inside ODETTE-FTP. The buffer compression is kept for backwards compatibility.
バッファ圧縮法とは異なり、この方法はファイル全体で動作します。圧縮のレベルが上昇しているため、ファイルレベルの圧縮により、Odette-FTP内の古いバッファー圧縮が本質的に廃止されます。バッファー圧縮は、逆方向の互換性のために保持されます。
A file that has been signed, compressed, and/or encrypted will have lost its record structure, so ODETTE-FTP will not be able to insert the End of Record Flag in subrecord headers in Data Exchange Buffers. To preserve the record structure, V format files must have record headers inserted into them prior to signing, compression, or encryption. These 2-byte binary numbers, in network byte order, indicate the length of each record, allowing the receiving system, where appropriate, to recreate the files complete with the original variable-length records. Note that the header bytes hold the number of data bytes in the record and don't include themselves.
署名、圧縮、および/または暗号化されたファイルはレコード構造を失ったため、Odette-FTPはデータ交換バッファーのサブレコードヘッダーにレコードフラグの端を挿入できません。レコード構造を保持するには、v形式ファイルに署名、圧縮、または暗号化の前にレコードヘッダーが挿入されている必要があります。これらの2バイトのバイナリ番号は、ネットワークバイトの順序で、各レコードの長さを示し、必要に応じて受信システムが元の可変長レコードで完全なファイルを再現できるようにします。ヘッダーバイトには、レコード内のデータバイト数を保持し、自分自身を含めないことに注意してください。
This is only applicable to V format files, which themselves are typically only of concern for mainframes.
これはV形式ファイルにのみ適用されます。これは、通常、メインフレームに懸念しているだけです。
Virtual Files are transmitted by mapping the Virtual File records into Data Exchange Buffers, the maximum length of which was negotiated between the ODETTE-FTP entities via the Start Session (SSID) commands exchanged during the Start Session phase of the protocol.
仮想ファイルは、仮想ファイルレコードをデータ交換バッファーにマッピングすることによって送信されます。その最大長は、プロトコルの開始セッションフェーズで交換された開始セッション（SSID）コマンドを介してOdette-FTPエンティティ間で交渉されました。
Virtual File records may be of arbitrary length. A simple compression scheme is defined for strings of repeated characters.
仮想ファイルレコードは任意の長さの場合があります。繰り返される文字の文字列に対して、単純な圧縮スキームが定義されています。
An example of the use of the Data Exchange Buffer can be found in Appendix A.
データ交換バッファーの使用の例は、付録Aにあります。
For transmission of Virtual File records, data is divided into subrecords, each of which is preceded by a 1-octet Subrecord Header.
仮想ファイルレコードを送信するために、データはサブレコードに分割され、それぞれの前には1オクテットのサブレコードヘッダーがあります。
The Data Exchange Buffer is made up of the initial Command Character followed by pairs of Subrecord Headers and subrecords, as follows.
データ交換バッファーは、次のように、初期コマンド文字で構成されています。
o--------------------------------------------------------
| C | H | | H | | H | | /
| M | D | SUBRECORD | D | SUBRECORD | D | SUBRECORD | /_
| D | R | | R | | R | | /
o-------------------------------------------------------
CMD
CMD
The Data Exchange Buffer Command Character, 'D'.
データ交換バッファコマンド文字「D」。
HDR
HDR
A 1-octet Subrecord Header defined as follows:
次のように定義されている1-OCTETサブレコードヘッダー：
0 1 2 3 4 5 6 7
o-------------------------------o
| E | C | |
| o | F | C O U N T |
| R | | |
o-------------------------------o
Bits
ビット
0 End of Record Flag
0レコードフラグの終わり
Set to indicate that the next subrecord is the last subrecord of the current record.
次のサブレコードが現在のレコードの最後のサブレコードであることを示すように設定されています。
Unstructured files are transmitted as a single record; in this case, the flag acts as an end-of-file marker.
非構造化されたファイルは、単一のレコードとして送信されます。この場合、フラグはファイル終了マーカーとして機能します。
1 Compression Flag
1圧縮フラグ
Set to indicate that the next subrecord is compressed.
次のサブレコードが圧縮されていることを示すように設定されています。
2-7 Subrecord Count
2-7サブレコードカウント
The number of octets in the Virtual File represented by the next subrecord expressed as a binary value.
次のサブレコードで表される仮想ファイルのオクテットの数は、バイナリ値として表されます。
For uncompressed data, this is simply the length of the subrecord.
非圧縮データの場合、これは単にサブレコードの長さです。
For compressed data, this is the number of times that the single octet in the following subrecord must be inserted in the Virtual File.
圧縮データの場合、これは、次のサブレコードの単一のオクテットを仮想ファイルに挿入する必要がある回数です。
As 6 bits are available, the next subrecord may represent between 0 and 63 octets of the Virtual File.
6ビットが利用可能であるため、次のサブレコードは仮想ファイルの0〜63オクテットを表す場合があります。
A Data Exchange Buffer may be any length up to the value negotiated in the Start Session exchange.
データ交換バッファーは、開始セッションエクスチェンジで交渉された値までの任意の長さである場合があります。
Virtual File records may be concatenated within one Data Exchange Buffer or split across a number of buffers.
仮想ファイルレコードは、1つのデータ交換バッファー内で連結したり、多数のバッファーに分割されたりする場合があります。
A subrecord is never split between two Exchange Buffers. If the remaining space in the current Exchange Buffer is insufficient to contain the next 'complete' subrecord, one of the following strategies should be used:
サブレコードが2つの交換バッファー間で分割されることはありません。現在の交換バッファーの残りのスペースが次の「完全な」サブレコードを抑えるには不十分な場合、次の戦略の1つを使用する必要があります。
1. Truncate the Exchange Buffer, and put the complete subrecord (preceded by its header octet) in a new Exchange Buffer.
1. 交換バッファーを切り捨て、完全なサブレコード（ヘッダーオクテットの前）を新しい交換バッファーに入れます。
2. Split the subrecord into two, filling the remainder of the Exchange Buffer with the first new subrecord and starting a new Exchange Buffer with the second.
2. サブレコードを2つに分割し、エクスチェンジバッファーの残りを最初の新しいサブレコードで埋め、2番目の新しいサブレコードで新しい交換バッファーを起動します。
A record of length zero may appear anywhere in the Exchange Buffer.
長さゼロのレコードは、交換バッファー内のどこにでも表示される場合があります。
A subrecord of length zero may appear anywhere in the record and/or the Exchange Buffer.
長さゼロのサブレコードは、レコードおよび/または交換バッファーのどこにでも表示される場合があります。
To utilise the TCP stream, a Stream Transmission Buffer (STB) is created by adding a Stream Transmission Header (STH) to the start of all Command and Data Exchange Buffers before they are passed to the TCP transport service. This allows the receiving ODETTE-FTP to recover the original Exchange Buffers.
TCPストリームを利用するために、TCPトランスポートサービスに渡される前に、すべてのコマンドおよびデータ交換バッファーの開始にストリームトランスミッションヘッダー（STH）を追加することにより、ストリームトランスミッションバッファ（STB）が作成されます。これにより、受信オデットFTPが元の交換バッファーを回復することができます。
Note: The Stream Transmission Buffer is not used when using ODETTE-FTP over an X.25 network.
注：X.25ネットワークでOdette-FTPを使用する場合、ストリームトランスミッションバッファーは使用されません。
This is because ODETTE-FTP can rely on the fact that the Network Service will preserve the sequence and boundaries of data units transmitted through the network and that the Network Service will pass the length of the data unit to the receiving ODETTE-FTP. TCP offers a stream-based connection that does not provide these functions.
これは、Odette-FTPがネットワークサービスがネットワークを介して送信されるデータユニットのシーケンスと境界を保持し、ネットワークサービスがデータユニットの長さを受信Odette-FTPに渡すという事実に依存できるためです。TCPは、これらの機能を提供しないストリームベースの接続を提供します。
The Stream Transmission Buffer is composed of an STH and an OEB.
ストリームトランスミッションバッファーは、STHとOEBで構成されています。
o-----+-----------------+-----+--------------------+-----+------
| STH | OEB | STH | OEB | STH | OEB/
o-----+-----------------+-----+--------------------+-----+----
STH - Stream Transmission Header OEB - ODETTE-FTP Exchange Buffer
STH-ストリームトランスミッションヘッダーOEB -Odette -FTP Exchangeバッファー
The Stream Transmission Header is shown below. The fields are transmitted from left to right.
ストリームトランスミッションヘッダーを以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version
Value: 0001 (binary)
値：0001（バイナリ）
Stream Transmission Header version number.
ストリームトランスミッションヘッダーバージョン番号。
Flags
フラグ
Value: 0000 (binary)
値：0000（バイナリ）
Reserved for future use.
将来の使用のために予約されています。
Length
長さ
Range: 5 - 100003 (decimal)
範囲：5-100003（小数）
The length of the Stream Transmission Buffer (STH+OEB).
ストリームトランスミッションバッファー（STH OEB）の長さ。
The smallest STB is 5 octets consisting of a 4-octet header followed by a 1-octet Exchange Buffer such as a Change Direction (CD) command.
最小のSTBは、4オクセットのヘッダーで構成される5オクテットと、その後に変更方向（CD）コマンドなどの1オクテットの交換バッファーが続きます。
The maximum Exchange Buffer length that can be negotiated is 99999 octets (Section 5.3.2) giving an STB length of 100003.
交渉できる最大交換バッファーの長さは、99999オクテット（セクション5.3.2）で、STBの長さは100003です。
The length is expressed as a binary number in network byte order.
長さは、ネットワークバイトの順序でバイナリ番号として表されます。
It is expected that implementations of this protocol will follow the Internet robustness principle of being conservative in what is sent and liberal in what is accepted.
このプロトコルの実装は、送信されたもので保守的であるというインターネットの堅牢性の原則に従い、受け入れられているものに従うことが期待されています。
The operation of an ODETTE-FTP entity is formally defined by the State Machine presented below. There are five State and Transition tables, and for each table additional information is given in the associated Predicate and Action lists.
Odette-FTPエンティティの動作は、以下に示す状態マシンによって正式に定義されています。5つの状態テーブルと遷移表があり、各テーブルについて、関連する述語リストとアクションリストに追加情報が記載されています。
The response of an ODETTE-FTP entity to the receipt of an event is defined by a Transition table entry indexed by the Event/State intersection within the appropriate state table.
イベントの受領に対するOdette-FTPエンティティの応答は、適切な状態テーブル内のイベント/状態交差点によってインデックスが付けられた遷移テーブルエントリによって定義されます。
Each Transition table entry defines the actions taken, events generated, and new state entered. Predicates may be used within a table entry to select the correct response on the basis of local information held by the entity.
各遷移テーブルエントリは、実行されたアクション、生成されたイベント、および新しい状態を定義します。予定状は、テーブルエントリ内で使用され、エンティティが保有するローカル情報に基づいて正しい応答を選択できます。
A Transition table contains the following fields:
遷移テーブルには、次のフィールドが含まれています。
Index (I) State transition index.
インデックス（i）状態遷移インデックス。
Predicate A list of predicates used to select between different possible transitions. The predicates are defined in the Predicate and Action lists.
異なる可能な遷移を選択するために使用される述語のリストを述べています。述語は、述語リストとアクションリストで定義されています。
Actions A list of actions taken by the entity. The actions are defined in the Predicate and Action lists.
アクションエンティティが取得したアクションのリスト。アクションは、述語リストとアクションリストで定義されています。
Events Output events generated by the entity.
イベントエンティティが生成するイベントイベント。
Next State The new state of the entity.
次は、エンティティの新しい状態を述べています。
The receipt of an event in a given state may be invalid for three reasons.
特定の状態でのイベントの受領は、3つの理由で無効になる場合があります。
1. The case is impossible by design of the state automata, denoted 'X' in the state tables. For example, a timer that has not been set cannot run out.
1. このケースは、状態テーブルで「x」と表される状態オートマトンの設計によって不可能です。たとえば、設定されていないタイマーは使い果たすことはできません。
2. The event is the result of an error in the Network Service implementation, also denoted 'X' in the state tables. The Network Service implementation is considered to be correct.
2. このイベントは、ネットワークサービスの実装のエラーの結果であり、状態表の「x」も示されています。ネットワークサービスの実装は正しいと見なされます。
3. For all other cases, the event is considered to be a User Error, denoted "U" in the state tables.
3. 他のすべてのケースについて、このイベントは、状態テーブルで「u」と示されているユーザーエラーと見なされます。
The state tables define the conditions under which a User event is valid, thus preventing the generation of a protocol error by the ODETTE-FTP entity as a result of a User Monitor error. The reaction of the entity to such errors is undefined and regarded as a local implementation issue.
状態テーブルは、ユーザーイベントが有効な条件を定義するため、ユーザーモニターエラーの結果としてOdette-FTPエンティティによるプロトコルエラーの生成を防ぎます。そのようなエラーに対するエンティティの反応は未定義であり、ローカルの実装の問題と見なされます。
The state tables also allow protocol errors due to the receipt of invalid Exchange Buffers, to be detected. In such cases, the reaction of the entity to the error is defined.
状態テーブルは、無効な交換バッファーの受領によるプロトコルエラーも検出できます。そのような場合、エンティティに対するエラーに対する反応が定義されます。
The Command Mode is strictly a half-duplex flip-flop mode.
コマンドモードは、厳密に半分二重フリップフロップモードです。
A_NC_ONLY Responder, Network Connection opened
A_NC_ONLY RESPONDER、ネットワーク接続が開きました
The Responder has sent its Ready Message (SSRM) and is waiting for Start Session (SSID) from the Initiator.
ResponderはReadyメッセージ（SSRM）を送信し、イニシエーターから開始セッション（SSID）を待っています。
A_WF_CONRS Responder Waiting for F_CONNECT_RS
a_wf_conrs f_connect_rsを待っているレスポンダー
The Responder has received the Initiator's Start Session (SSID) and is waiting for a response (F_CONNECT_RS) from its User Monitor.
レスポンダーはイニシエーターの開始セッション（SSID）を受け取り、ユーザーモニターから応答（f_connect_rs）を待っています。
CDSTWFCD CD_RQ stored in WF_CD state
wf_cd状態に保存されているcdstwfcd cd_rq
Since the User Monitor doesn't see the WF_CD state, it may send a Change Direction request (F_CD_RQ) before the ODETTE-FTP receives a Change Direction (CD) command.
ユーザーモニターにはWF_CD状態が表示されないため、Odette-FTPがChange Direction（CD）コマンドを受信する前に、変更方向リクエスト（F_CD_RQ）を送信する場合があります。
CLIP Close Input Pending
保留中のクリップクローズ入力
The Listener has received an End File (EFID) command and is waiting for the Close File response (F_CLOSE_FILE_RS) from its User Monitor.
リスナーはEnd File（EFID）コマンドを受信しており、ユーザーモニターから閉じるファイル応答（f_close_file_rs）を待っています。
CLOP Close Out Pending
保留中のクロップクローズアウト
The Speaker has sent an End File (EFID) command and is waiting for an End File Answer (EFPA or EFNA).
スピーカーはエンドファイル（EFID）コマンドを送信し、エンドファイルの回答（EFPAまたはEFNA）を待っています。
ERSTWFCD End to End Response stored in WF_CD state
wf_cd状態に保存されているerstwfcd end to end応答
Since the User Monitor doesn't see the WF_CD state, it may send F_EERP_RQ, before ODETTE-FTP receives a Change Direction (CD) command.
ユーザーモニターにはWF_CD状態が表示されないため、Odette-FTPがChange Direction（CD）コマンドを受信する前に、F_EERP_RQを送信する場合があります。
IDLE Connection IDLE
アイドル接続アイドル
IDLELI Idle Listener
Idleliアイドルリスナー
IDLELICD Idle Listener, F_CD_RQ Received
idlelicdアイドルリスナー、f_cd_rqが受信されました
The ODETTE-FTP entity has become the Listener after receiving a Change Direction request (F_CD_RQ) from the User Monitor. The receipt of an End Session (ESID) is valid in this state.
Odette-FTPエンティティは、ユーザーモニターから変更方向リクエスト（F_CD_RQ）を受信した後、リスナーになりました。エンドセッション（ESID）の受領は、この状態で有効です。
IDLESP Idle Speaker
アイドルスプアイドルスピーカー
IDLESPCD Idle Speaker, F_CD_IND Sent
idlespcdアイドルスピーカー、f_cd_ind送信
The ODETTE-FTP entity has sent a Change Direction indication (F_CD_IND) to the User Monitor. A Change Direction request (F_CD_RQ) is invalid in this state.
Odette-FTPエンティティは、ユーザーモニターに変更方向表示（f_cd_ind）を送信しました。この状態では、変更方向要求（F_CD_RQ）が無効です。
I_WF_NC Initiator Waiting for Network Connection
I_WF_NCイニシエーターがネットワーク接続を待っています
The Initiator has requested a new network connection and is waiting for a Connection confirmation (N_CON_CF) from the Network Service.
イニシエーターは新しいネットワーク接続を要求し、ネットワークサービスから接続確認（N_CON_CF）を待っています。
I_WF_RM Initiator Waiting for Ready Message
I_WF_RMイニシエーターが準備が整ったメッセージを待っています
Before sending Start Session (SSID), the Initiator must wait for a Ready Message (SSRM) from the Responder.
開始セッション（SSID）を送信する前に、イニシエーターはレスポンダーから準備完了メッセージ（SSRM）を待つ必要があります。
I_WF_SSID Initiator Waiting for SSID
I_WF_SSIDイニシエーターがSSIDを待っています
The Initiator has sent a Start Session (SSID) command and is waiting for Start Session from the Responder.
イニシエーターはStart Session（SSID）コマンドを送信し、Responderからの開始セッションを待っています。
NRSTWFCD Negative End Response stored in WF_CD state
wf_cd状態に保存されているnrstwfcd負の末端応答
Since the User Monitor doesn't see the WF_CD state, it may send F_NERP_RQ, before ODETTE-FTP receives a Change Direction (CD) command.
ユーザーモニターにはWF_CD状態が表示されないため、Odette-FTPがChange Direction（CD）コマンドを受信する前に、F_NERP_RQを送信する場合があります。
OPI Open Input (Data Transfer Phase)
OPIオープン入力（データ転送フェーズ）
The Listener is waiting for the Speaker to send a Data Exchange Buffer.
リスナーは、スピーカーがデータ交換バッファーを送信するのを待っています。
OPIP Open Input Pending
保留中のオピップオープン入力
The Listener has received a Start File (SFID) command and is waiting for the Start File response (F_START_FILE_RS) from its User Monitor.
リスナーはSTARTファイル（SFID）コマンドを受信しており、ユーザーモニターからSTARTファイル応答（F_START_FILE_RS）を待っています。
OPO Open Out (Data Transfer Phase)
OPOオープンアウト（データ転送フェーズ）
The Speaker has received a Start File Positive Answer (SFPA) and is waiting for a Data (F_DATA_RQ) or Close File (F_CLOSE_FILE) request from its User Monitor.
スピーカーはSTARTファイルの肯定的な回答（SFPA）を受け取り、ユーザーモニターからデータ（F_DATA_RQ）または閉じるファイル（F_CLOSE_FILE）要求を待っています。
OPOP Open Out Pending
opopが保留中に開いています
The Speaker has sent a Start File (SFID) command and is waiting for a Start File Answer (SFPA or SFNA).
スピーカーはStartファイル（SFID）コマンドを送信し、Startファイルの回答（SFPAまたはSFNA）を待っています。
OPOWFC Open Out Wait for Credit
opowfcクレジットを待ちます
The Speaker is waiting for a Set Credit (CDT) command before sending further Data Exchange buffers.
スピーカーは、さらにデータ交換バッファーを送信する前に、セットクレジット（CDT）コマンドを待っています。
RTRP Ready to Receive (RTR) Pending
RTRPは、保留中の（RTR）受信（RTR）
The Listener has received an EERP or a NERP and is waiting for the Ready to Receive response (F_RTR_RS) from its User Monitor.
リスナーはEERPまたはNERPを受け取り、ユーザーモニターから対応の準備ができている（F_RTR_RS）を待っています。
SFSTWFCD Start File Request stored in WF_CD state.
sfstwfcd wf_cd状態に保存されているStart file request。
Since the User Monitor doesn't see the WF_CD state, it may send a Start File request (F_START_FILE_RQ) before the ODETTE-FTP receives a Change Direction (CD) command.
ユーザーモニターにはWF_CD状態が表示されないため、Odette-FTPがChange Direction（CD）コマンドを受信する前に、開始ファイル要求（f_start_file_rq）を送信する場合があります。
WF_CD Wait for Change Direction
WF_CD変更方向を待ちます
The Listener wishes to become the Speaker and is waiting for a Change Direction (CD) command after sending an End File Positive Answer (EFPA) requesting change direction.
リスナーはスピーカーになりたいと考えており、変更方向を要求するエンドファイルの肯定的な回答（EFPA）を送信した後、変更方向（CD）コマンドを待っています。
WF_RTR Wait for Ready To Receive
wf_rtr受信準備ができるのを待ちます
The Speaker has sent an End to End Response (EERP) or a Negative End Response (NERP) command and must wait for Ready To Receive (RTR) from the Listener.
スピーカーは、エンドツーエンド応答（EERP）またはネガティブエンド応答（NERP）コマンドを送信しており、リスナーから受信（RTR）を受信（RTR）を待つ必要があります。
WF_NDISC Wait for N_DISC_IND
wf_ndisc n_disc_indを待ちます
ODETTE-FTP has sent an End Session (ESID) command and is waiting for a Disconnection indication (N_DISC_IND) from the Network Service.
Odette-FTPはエンドセッション（ESID）コマンドを送信し、ネットワークサービスから切断表示（N_DISC_IND）を待っています。
WF_SECD Wait for Security Change Direction
WF_SECDセキュリティ変更方向を待ちます
The Speaker is expecting a Security Change Direction (SECD) from the Listener.
スピーカーは、リスナーからセキュリティ変更方向（SECD）を期待しています。
WF_AUCH Wait for Authentication Challenge
wf_auch認証チャレンジを待ちます
The Speaker has sent a Security Change Direction (SECD) command and must wait for Authentication Challenge (AUCH) from the Listener.
スピーカーはセキュリティ変更方向（SECD）コマンドを送信し、リスナーから認証チャレンジ（auch）を待つ必要があります。
WF_AURP Wait for Authentication Response
wf_aurp認証応答を待ちます
The Speaker has sent an Authentication Challenge (AUCH) command and must wait for Authentication Response (AURP) from the Listener.
スピーカーは認証チャレンジ（auch）コマンドを送信し、リスナーから認証応答（aurp）を待つ必要があります。
User Monitor Input Events (Section 3)
ユーザーモニター入力イベント（セクション3）
F_DATA_RQ F_CONNECT_RQ F_START_FILE_RQ F_CLOSE_FILE_RQ
F_EERP_RQ F_CONNECT_RS F_START_FILE_RS(+) F_CLOSE_FILE_RS(+)
F_NERP_RQ F_ABORT_RQ F_START_FILE_RS(-) F_CLOSE_FILE_RS(-)
F_CD_RQ F_RELEASE_RQ F_RTR_RS
Network Input Events (Section 2.2)
ネットワーク入力イベント（セクション2.2）
N_CON_IND N_CON_CF N_DATA_IND N_DISC_IND N_RST_IND
n_con_ind n_con_cf n_data_ind n_disc_ind n_rst_ind
Peer ODETTE-FTP Input Events (Section 4)
ピアオデット-ftp入力イベント（セクション4）
SSID SFID SFPA SFNA EFID EFPA EFNA DATA ESID EERP RTR CD CDT SSRM NERP SECD AUCH AURP
SSID SFID SFPA SFNA EFID EFPA EFNAデータESID EERP RTR CD CD CD SSRM NERP SECD AUCH AURP
Internal Input Events
内部入力イベント
TIME-OUT - Internal ODETTE-FTP timer expires.
タイムアウト - 内部Odette-FTPタイマーは期限切れになります。
Input event parameters are denoted I.Event-name.Parameter-name within the state table action and predicate lists. Their value can be examined but not changed by the ODETTE-FTP entity.
入力イベントパラメーターは、ステートテーブルアクションと述語リスト内のi.Event-name.parameter-nameと表示されます。それらの価値は調べることができますが、Odette-FTPエンティティによって変更されません。
User Monitor Output Events (Section 3)
ユーザーモニター出力イベント（セクション3）
F_DATA_IND F_CONNECT_IND F_START_FILE_IND F_CLOSE_FILE_IND
F_EERP_IND F_CONNECT_CF F_START_FILE_CF(+) F_CLOSE_FILE_CF(+)
F_CD_IND F_ABORT_IND F_START_FILE_CF(-) F_CLOSE_FILE_CF(-)
F_NERP_IND F_RELEASE_IND F_DATA_CF F_RTR_CF
Network Output Events (Section 2.2)
ネットワーク出力イベント（セクション2.2）
N_CON_RQ N_CON_RS N_DATA_RQ N_DISC_RQ
N_CON_RQ N_CON_RS N_DATA_RQ N_DISC_RQ
Peer ODETTE-FTP Output Events (Section 4)
ピアオデット-ftp出力イベント（セクション4）
SSID SFID SFPA SFNA EFID EFPA EFNA DATA ESID EERP RTR CD CDT SSRM NERP SECD AUCH AURP
SSID SFID SFPA SFNA EFID EFPA EFNAデータESID EERP RTR CD CD CD SSRM NERP SECD AUCH AURP
Output event parameters are denoted O.Event-name.Parameter-name within the state table action and predicate lists. Their values can be examined and changed by the ODETTE-FTP entity.
出力イベントパラメーターは、ステートテーブルアクションと述語リスト内でo.event-name.parameter-nameと表示されます。それらの値は、Odette-FTPエンティティによって調べて変更できます。
The following variables are maintained by the ODETTE-FTP entity to assist the operation of the protocol. They are denoted V.Variable-name within the state table action and predicate lists. Their value can be examined and changed by the ODETTE-FTP entity. The initial value of each variable is undefined.
次の変数は、プロトコルの動作を支援するために、Odette-FTPエンティティによって維持されます。それらは、ステートテーブルアクションと述語リスト内でV.Variable-Nameと表示されます。それらの価値は、Odette-FTPエンティティによって調べて変更できます。各変数の初期値は定義されていません。
Variable Type Comments
---------------------------------------------------------------------
Buf-size Integer Negotiated Data Exchange Buffer size.
Called-addr Address Used to build O.F_CONNECT_IND.Called-addr
Calling-addr Address To build O.F_CONNECT_IND.Calling-addr
Compression Yes/No Compression in use as agreed.
Credit_L Integer Listener's credit counter.
Credit_S Integer Speaker's credit counter.
Id String Used to build O.SSID.Id
Mode Sender-only, Receiver-only, Both.
Pswd String Password, used to build O.SSID.Pswd
Req-buf Primitive Input event (F_XXX_RQ) stored in WF_CD
state.
Restart Yes/No Restart in used as agreed.
Restart-pos Integer Used only during file opening.
Window Integer The credit value negotiated for the
session.
Caller Yes/No This entity initiated the ODETTE-FTP
session.
Authentication Yes/No Secure authentication in use as agreed
Challenge Binary Random challenge
---------------------------------------------------------------------
The following constants define the capabilities of a given ODETTE-FTP entity. They are denoted C.Constant-name within the state table action and predicate lists. Their value can be examined but not changed by the ODETTE-FTP entity.
次の定数は、特定のOdette-FTPエンティティの機能を定義します。それらは、ステートテーブルアクションと述語リスト内でc.constant-nameと表示されます。それらの価値は調べることができますが、Odette-FTPエンティティによって変更されません。
Constant Value Comments
---------------------------------------------------------------------
Cap-compression Yes/No Compression supported?
Cap-init Initiator Must be Initiator.
Responder Must be Responder.
Both Can be Initiator or Responder.
Cap-mode Sender-only Must be sender.
Receiver-only Must be receiver.
Both Can be sender or receiver.
Max-buf-size 127 < Int < 100000 Maximum Data Exchange Buffer
size supported.
Max-window 0 < Int < 1000 Local maximum credit value.
Cap-restart Yes/No Restart supported?
Cap-logic 0, 1, 2 0 = does not support special
logic
1 = supports special logic
2 = needs special logic
---------------------------------------------------------------------
o----------------------------------------------------------o
| | Other States |
| |--------------------------------------------------o |
| | WF_SECD | |
| |----------------------------------------------o | |
| | WF_AURP | | |
| |------------------------------------------o | | |
| | WF_AUCH | | | |
| |--------------------------------------o | | | |
| S | A_WF_CONRS | | | | |
| |----------------------------------o | | | | |
| T | A_NC_ONLY | | | | | |
| |------------------------------o | | | | | |
| A | I_WF_SSID | | | | | | |
| |--------------------------o | | | | | | |
| T | I_WF_RM | | | | | | | |
| |----------------------o | | | | | | | |
| E | I_WF_NC | | | | | | | | |
| |------------------o | | | | | | | | |
| | IDLE | | | | | | | | | |
|==================o---+---+---+---+---+---+---+---+---+---|
| | F_CONNECT_RQ | A | X | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| E | N_CON_CF | X | C | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| V | SSRM | X | X | H | X | X | X | L | L | L | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| E | SSID | X | X | X | D | E | F | L | L | L | F |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| N | N_CON_IND | B | X | X | X | X | X | X | X | X | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| T | F_CONNECT_RS | X | U | U | U | U | G | X | X | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | ESID | X | X | X | F | X | X | F | F | F | X |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | AUCH | X | X | U | U | X | X | I | L | L | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | AURP | X | X | U | U | X | X | L | K | L | U |
| |--------------+---+---+---+---+---+---+---+---+---+---|
| | SECD | X | X | U | U | X | X | L | L | J | U |
o----------------------------------------------------------o
I | Predicate Actions Output Events Next State
===o=============================================================
A | P1: F_ABORT_IND IDLE
| !P1: 1,2 N_CON_RQ I_WF_NC
---+-------------------------------------------------------------
B | P3: N_DISC_RQ IDLE
| !P3: 2 N_CON_RS
| SSRM A_NC_ONLY
---+-------------------------------------------------------------
C | 4,2 I_WF_RM
---+-------------------------------------------------------------
D | P2 & P8 & P11: 4,2,5 SECD WF_AUCH
| P2 & P8 & !P11: 4,2,5 F_CONNECT_CF IDLESP
| P2 & !P8: 4,2 ESID(R=12)
| F_ABORT_IND(R,AO=L) WF_NDISC
| else: 4,2 ESID(R=10)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
E | P4: 4 N_DISC_RQ IDLE
| !P4: 4,2 F_CONNECT_IND A_WF_CONRS
---+-------------------------------------------------------------
F | 4 F_ABORT_IND
| N_DISC_RQ IDLE
---+-------------------------------------------------------------
G | P2 & P9 & P10: 4,2,5 SSID WF_SECD
| P2 & !P9 & P10: 4,2,5 SSID IDLELI
| !P10: 4,2 ESID(R=12)
| F_ABORT_IND(R,AO=L) WF_NDISC
| else: 4,2 ESID(R=10)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
H | 4,2,3 SSID I_WF_SSID
---+-------------------------------------------------------------
I | P5: 4,2 AURP WF_SECD
| !P5: 4,2 AURP IDLELI
---+-------------------------------------------------------------
J | 4,2 AUCH WF_AURP
---+-------------------------------------------------------------
K | P6: 4,2 F_CONNECT_CF IDLESP
| P7: 4,2 SECD WF_AUCH
| else: 4,2 ESID(R=11)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
L | 4,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-------------------------------------------------------------
Predicate P1: (No resources available) OR (C.Cap-init = Responder) OR (C.Cap-mode = Sender-only AND I.F_CONNECT_RQ.Mode = Receiver-only) OR (C.Cap-mode = Receiver-only AND I.F_CONNECT_RQ.Mode = Sender-only)
述語P1 ：（リソースは利用できません）または（c.cap-init = responder）または（c.cap-mode = senderのみおよびi.f_connect_rq.mode = receiverのみ）または（c.cap-mode = receiver--唯一およびi.f_connect_rq.mode = senderのみ）
Predicate P2: SSID negotiation is successful (for these, Buf-size, Restart, Compression, Mode, Special logic, and Window, compare the inbound SSID with the local constants to set the local variables. Any incompatibilities result in failure of the negotiation.)
述語P2：SSID交渉は成功します（これら、BUFサイズ、再起動、圧縮、モード、特別なロジック、およびウィンドウの場合、インバウンドSSIDをローカル定数と比較してローカル変数を設定します。））
Predicate P3: C.Cap-init = Initiator
述語P3：c.cap-init = initiatator
Predicate P4: Mode in SSID incompatible with C.Cap-mode
述語P4：c.cap-modeと互換性のないSSIDのモード
Predicate P5: V.Caller = Yes
述語P5：V.Caller =はい
Predicate P6: (V.Caller = Yes) AND (AURP.Signature verifies with V.Challenge)
述語P6：（v.caller = yes）and（aurp.signatureはv.challengeで検証します）
Predicate P7: (V.Caller = No) AND (AURP.Signature verifies with V.Challenge)
述語P7：（v.caller = no）および（aurp.signatureはv.challengeで検証します）
Predicate P8: V.Authentication = I.SSID.Authentication
述語P8：v.authentication = i.ssid.authentication
Predicate P9: I.F_CONNECT_RS.Authentication = Yes
述語P9：i.f_connect_rs.authentication = yes
Predicate P10: O.F_CONNECT_IND.Authentication = I.F_CONNECT_RS.Authentication
述語P10：o.f_connect_ind.authentication = i.f_connect_rs.authentication
Predicate P11: V.Authentication = Yes
述語P11：V.Authentication =はい
Action 1: Set V.Mode from (C.Cap-mode, I.F_CONNECT_RQ.Mode) Set V.Pswd, V.Id, V.Restart, and V.Authentication from I.F_CONNECT_RQ Set V.Buf-size = C.Max-buf-size Set V.Compression = C.Cap-compression Set V.Caller = Yes Build O.N_CON_RQ
アクション1：（c.cap-mode、i.f_connect_rq.mode）からv.modeを設定するv.pswd、v.id、v.restart、およびv.authentication from i.f_connect_rq set v.buf-size = c.max-buf-size set v.compression = C.cap-compression set v.caller = yes build o.n_con_rq
Action 2: Start inactivity timer
アクション2：非アクティブタイマーを開始します
Action 3: Set parameters in O.SSID = from local variables
Action 4: Stop timer
Action 5: Set V.Mode, V.Restart, V.Compression, V.Buf-size, V.Window, V.Authentication = from SSID
アクション5：v.mode、v.restart、v.compression、v.buf-size、v.window、v.authentication = from Ssidを設定します
Action 6: Set V.Challenge = A random number unique to the session
アクション6：v.challenge =セッションに固有の乱数を設定します
o--------------------------------------o
| | Other States |
| S |------------------------------o |
| T | WF_NDISC | |
| A |--------------------------o | |
| T | I_WF_NC | | |
| E |----------------------o | | |
| | IDLE | | | |
|======================o---+---+---+---|
| | TIME-OUT | X | X | A | B |
| |------------------+---+---+---+---|
| E | F_ABORT_RQ | X | A | X | C |
| V |------------------+---+---+---+---|
| E | N_RST_IND | X | X | A | D |
| N |------------------+---+---+---+---|
| T | N_DISC_IND | X | E | F | G |
| |------------------+---+---+---+---|
| | Invalid Buffer | X | X | H | I |
o--------------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | N_DISC_RQ IDLE
---+-----------------------------------------------------------------
B | F_ABORT_IND
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
C | 1 N_DISC_RQ IDLE
---+-----------------------------------------------------------------
D | 1 N_DISC_RQ
| F_ABORT_IND IDLE
---+-----------------------------------------------------------------
E | F_ABORT_IND IDLE
---+-----------------------------------------------------------------
F | 1 IDLE
---+-----------------------------------------------------------------
G | 1 F_ABORT_IND IDLE
---+-----------------------------------------------------------------
H | WF_NDISC
---+-----------------------------------------------------------------
I | 1,2 ESID(R=01)
| F_ABORT_IND(R,AO=L) WF_NDISC
---------------------------------------------------------------------
Action 1: Stop inactivity timer
アクション1：非アクティブタイマーを停止します
Action 2: Start inactivity timer
アクション2：非アクティブタイマーを開始します
The following abbreviations are used in the Speaker state table.
次の略語は、スピーカーステートテーブルで使用されています。
F_REL_RQ(Ok) - F_RELEASE_RQ Reason = Normal
F_REL_RQ(Err) - F_RELEASE_RQ Reason = Error
o--------------------------------------------------------------------o
| | Other States |
| |--------------------------------------------------------------o |
| | WF_NDISC | |
| |----------------------------------------------------------o | |
| | OPOWFC | | |
| |------------------------------------------------------o | | |
| | OPO | | | |
|S|--------------------------------------------------o | | | |
| | OPOP | | | | |
|T|----------------------------------------------o | | | | |
| | CDSTWFCD | | | | | |
|A|------------------------------------------o | | | | | |
| | SFSTWFCD | | | | | | |
|T|--------------------------------------o | | | | | | |
| | NRSTWFCD | | | | | | | |
|E|----------------------------------o | | | | | | | |
| | ERSTWFCD | | | | | | | | |
| |------------------------------o | | | | | | | | |
| | WF_CD | | | | | | | | | |
| |--------------------------o | | | | | | | | | |
| | WF_RTR | | | | | | | | | | |
| |----------------------o | | | | | | | | | | |
| | IDLESPCD | | | | | | | | | | | |
| |------------------o | | | | | | | | | | | |
| | IDLESP | | | | | | | | | | | | |
|=+==============o---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_EERP_RQ | A | A | W | F | W | W | U | U | U | U | U | U | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_NERP_RQ | Y | Y | W | Z | W | W | U | U | U | U | U | U | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_START_ | B | B | W | G | W | W | U | U | U | U | U | X | U |
| | FILE_RQ | | | | | | | | | | | | | |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | SFPA | C | C | C | C | C | C | C | C | K | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|E| SFNA | C | C | C | C | C | C | C | C | L | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|V| CD | C | C | C | H | R | Z1| I | J | C | C | C | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|E| F_DATA_RQ | U | U | U | U | U | U | U | U | U | M | U | S | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|N| CDT | C | C | C | C | C | C | C | C | C | P | O | S | C |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
|T| F_CD_RQ | D | U | W | T | W | W | U | U | U | U | U | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_REL_RQ(Ok) | U | E | U | U | U | U | U | U | U | U | U | X | U |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | F_REL_RQ(Err)| Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | Q | S | Q |
| |--------------+---+---+---+---+---+---+---+---+---+---+---+---+---|
| | RTR | C | C | N | C | C | C | C | C | C | C | C | S | C |
o--------------------------------------------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | P5: 1,2,3,18 EERP WF_RTR
| !P5: 1,2,3 EERP WF_RTR
---+-----------------------------------------------------------------
B | P1: UE
| !P1: 1,2,5 SFID OPOP
---+-----------------------------------------------------------------
C | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
D | 1,2 CD IDLELICD
---+-----------------------------------------------------------------
E | 1,2 ESID(R=00) WF_NDISC
---+-----------------------------------------------------------------
F | 4 ERSTWFCD
---+-----------------------------------------------------------------
G | P1: UE
| !P1: 6 SFSTWFCD
---+-----------------------------------------------------------------
H | 1,2 IDLESP
---+-----------------------------------------------------------------
I | 1,2,10 SFID OPOP
---+-----------------------------------------------------------------
J | 1,2 CD IDLELICD
---+-----------------------------------------------------------------
K | P2: 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
| !P2: 1,2,7,12 F_START_FILE_CF(+) OPO
---+-----------------------------------------------------------------
L | 1,2,8 F_START_FILE_CF(-) IDLESP
---+-----------------------------------------------------------------
M | P3: 1,2,11,13 DATA OPOWFC
| !P3: 1,2,11,13 DATA
| F_DATA_CF OPO
---+-----------------------------------------------------------------
N | F_RTR_CF IDLESP
---+-----------------------------------------------------------------
O | 12 F_DATA_CF OPO
---+-----------------------------------------------------------------
P | Protocol 1,2 ESID(R=02)
| Error F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
Q | 1,2 ESID(R) WF_NDISC
---+-----------------------------------------------------------------
Continued -->
I | Predicate Actions Output Events Next State
===o=================================================================
R | 1,2,9 EERP WF_RTR
---+-----------------------------------------------------------------
S | WF_NDISC
---+-----------------------------------------------------------------
T | CDSTWFCD
---+-----------------------------------------------------------------
U | User Error UE
---+-----------------------------------------------------------------
W | User Error - Note 1 UE
---+-----------------------------------------------------------------
X | Error
---+-----------------------------------------------------------------
Y | P4 & P5: 1,2,15,18 NERP WF_RTR
| !P4 & !P5: 1,2,15,14 NERP WF_RTR
| P4 & !P5: 1,2,15 NERP WF_RTR
| !P4 & P5: 1,2,15,14,18 NERP WF_RTR
---+-----------------------------------------------------------------
Z | 16 NRSTWFCD
---------------------------------------------------------------------
Z1| P4: 1,2,17 NERP WF_RTR
| !P4: 1,2,17,14 NERP WF_RTR
---------------------------------------------------------------------
Predicate P1: (I.F_START_FILE_RQ.Restart-pos > 0 AND V.Restart = No)
OR (V.Mode = Receiver-only)
Note: Restart requested and not supported for this session.
注：再起動は要求され、このセッションのサポートされていません。
Predicate P2: I.SFPA.Restart-pos > V.Restart-pos
述語P2：i.sfpa.restart-pos> v.restart-pos
Note: Protocol error due to the restart position in the SFPA acknowledgement being greater than the position requested in the SFID request.
注：SFPA認定の再起動位置によるプロトコルエラーは、SFIDリクエストで要求された位置よりも大きいためです。
Predicate P3: V.Credit_S - 1 = 0
Note: Speaker's Credit is exhausted.
注：スピーカーのクレジットは使い果たされています。
Predicate P4: No special logic is in use
述語P4：特別なロジックは使用されていません
Predicate P5: Signed EERP/NERP requested
述語P5：署名されたEERP/NERPが要求されました
Action 1: Stop inactivity timer Action 2: Start inactivity timer
アクション1：非アクティブタイマーアクションを停止する2：不活動タイマーを開始
Action 3: Build an EERP from F_EERP_RQ
アクション3：F_EERP_RQからEERPを構築します
Action 4: Store F_EERP_RQ in V.Req-buf
アクション4：V.Req-BufにF_EERP_RQを保存します
Action 5: Build SFID from F_START_FILE_RQ V.Restart-pos = I.F_START_FILE_RQ.Restart-pos
アクション5：f_start_file_rq v.restart-pos = i.f_start_file_rq.restart-posからsfidを作成する
Action 6: Store F_START_FILE_RQ in V.Req-buf
アクション6：v.req-bufにf_start_file_rqを保存します
Action 7: Build F_START_FILE_CF(+) from I.SFPA
Action 8: Build F_START_FILE_CF(-) from I.SFNA
アクション8：i.sfnaからf_start_file_cf（ - ）をビルド
Action 9: Build EERP from F_EERP_RQ stored in V.Req-buf
アクション9：V.Req-Bufに保存されているF_EERP_RQからEERPを構築する
Action 10: Build SFID from F_START_FILE_RQ stored in V.Req-buf Set V.Restart-pos
アクション10：v.req-buf set v.restart-posに保存されているf_start_file_rqからsfidを構築する
Action 11: Build Exchange Buffer
アクション11：交換バッファを構築します
Action 12: V.Credit_S = V.Window
アクション12：v.credit_s = v.window
Action 13: V.Credit_S = V.Credit_S - 1
Action 14: Activate CRC-calculus function. Wrap Exchange buffer in special logic
アクション14：CRC-Calculus関数を有効にします。特別なロジックで交換バッファーをラップします
Action 15: Build a NERP from F_NERP_RQ
アクション15：f_nerp_rqからオタクを構築します
Action 16: Store F_NERP_RQ in V.Req-buf
アクション16：v.req-bufにf_nerp_rqを保存します
Action 17: Build NERP from F_NERP_RQ stored in V.Req-buf
アクション17：v.req-bufに保存されているf_nerp_rqからnerpを構築する
Action 18: Sign the contents of NERP/EERP
アクション18：NERP/EERPの内容に署名する
Note 1: Whether to accept this "Request/Event" while in this state is a matter of local implementation. The ODETTE state tables are based on the assumption that this event cannot occur in this state and is considered to be a user error (UE).
注1：この状態でこの「リクエスト/イベント」を受け入れるかどうかは、現地の実装の問題です。オデット状態テーブルは、このイベントがこの状態では発生できず、ユーザーエラー（UE）と見なされているという仮定に基づいています。
o---------------------------------o
| S | CLOP |
| T |-------------------------o |
| A | OPOWFC | |
| T |---------------------o | |
| E | OPO | | |
|=====================o---+---+---|
| E | F_CLOSE_FILE_RQ | A | E | U |
| V |-----------------+---+---+---|
| E | EFPA | B | B | C |
| N |-----------------+---+---+---|
| T | EFNA | B | B | D |
o---------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | 1,2,5,7 EFID CLOP
---+-----------------------------------------------------------------
B | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
C | P1: 1,2,3 F_CLOSE_FILE_CF(+,SP=No)
| CD IDLELI
| !P1: 1,2,4 F_CLOSE_FILE_CF(+,SP=Yes) IDLESP
---+-----------------------------------------------------------------
D | 1,2,6 F_CLOSE_FILE_CF(-) IDLESP
---+-----------------------------------------------------------------
E | See Note 1
---+-----------------------------------------------------------------
U | User Error UE
---------------------------------------------------------------------
Predicate P1: (I.EFPA.CD-Request = Yes)
述語P1：（i.efpa.cd-request = yes）
Predicate P2: No special logic is in use
述語P2：特別なロジックは使用されていません
Action 1: Stop inactivity timer
アクション1：非アクティブタイマーを停止します
Action 2: Start inactivity timer
Action 3: O.F_CLOSE_FILE_CF(+).Speaker = No
Action 4: O.F_CLOSE_FILE_CF(+).Speaker = Yes
Action 5: Build EFID from F_CLOSE_FILE_RQ
アクション5：f_close_file_rqからEFIDを作成します
Action 6: Build F_CLOSE_FILE_CF(-) from EFNA
アクション6：efnaからf_close_file_cf（ - ）をビルド
Action 7: Set V.Credit_S = 0
アクション7：v.credit_s = 0を設定します
Action 8: Wrap Exchange buffer in special logic
アクション8：特別なロジックでのラップ交換バッファー
Note 1: In order to respect the "half duplex" property of ODETTE-FTP, it is forbidden to send EFID while in the OPOWFC state. EFID can be sent only in the OPO state.
注1：Odette-FTPの「半分のデュプレックス」プロパティを尊重するために、OpoWFC州にいる間にEFIDを送信することは禁止されています。EFIDは、OPO状態でのみ送信できます。
The ODETTE-FTP implementation must avoid sending EFID (or receiving F_CLOSE_FILE_RQ) while in the OPOWFC state.
ODETTE-FTPの実装は、OPOWFC状態でEFIDの送信（またはF_CLOSE_FILE_RQを受信する）を避ける必要があります。
o---------------------------------------------o
| | RTRP |
| |-------------------------------------o |
| | CLIP | |
| |---------------------------------o | |
| | OPI | | |
| S |-----------------------------o | | |
| T | OPIP | | | |
| A |-------------------------o | | | |
| T | IDLELICD | | | | |
| E |---------------------o | | | | |
| | IDLELI | | | | | |
|=====================o---+---+---+---+---+---+
| | SFID | A | A | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| E | DATA | B | B | B | I | B | B |
| V |-----------------+---+---+---+---+---+---+
| E | EFID | B | B | B | J | B | B |
| N |-----------------+---+---+---+---+---+---+
| T | F_START_FILE_RS | U | U | H | U | U | U |
| |-----------------+---+---+---+---+---+---+
| | F_CLOSE_FILE_RS | U | U | U | U | K | U |
| |-----------------+---+---+---+---+---+---+
| | CD | C | B | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | ESID R=Normal | D | F | D | D | D | D |
| |-----------------+---+---+---+---+---+---+
| | ESID R=Error | D | D | D | D | D | D |
| |-----------------+---+---+---+---+---+---+
| | EERP | E | E | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | NERP | L | L | B | B | B | B |
| |-----------------+---+---+---+---+---+---+
| | F_RTR_RS | U | U | U | U | U | M |
o---------------------------------------------o
I | Predicate Actions Output Events Next State
===o=================================================================
A | P1: 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
| !P1: 1,2,3 F_START_FILE_IND OPIP
---+-----------------------------------------------------------------
B | 1,2 ESID(R=02)
| F_ABORT_IND(R,AO=L) WF_NDISC
---+-----------------------------------------------------------------
C | 1,2 F_CD_IND IDLESPCD
---+-----------------------------------------------------------------
D | 1 F_ABORT_IND(Received
| ESID Reason,AO=D)
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
E | 1,2,4 F_EERP_IND RTRP
---+-----------------------------------------------------------------
F | 1 F_RELEASE_IND
| N_DISC_RQ IDLE
---+-----------------------------------------------------------------
H | P4: User Error UE
| P2 & !P4 & !P5: 1,2,8 SFPA OPI
| !P2 & !P4 & !P5: 1,2 SFNA IDLELI
| P2 & !P4 & P5: 1,2,5,8 SFPA OPI
| !P2 & !P4 & P5: 1,2,5 SFNA IDLELI
---+-----------------------------------------------------------------
I | P6: 1,2 ESID(R=02)
| F_ABORT_IND(R,A0=L) WF_NDISC
| !P5 & !P6 & !P7: 1,2,7 F_DATA_IND (See Note 1) OPI
| !P5 & !P6 & P7: 1,2,8 F_DATA_IND
| CDT (See Note 1) OPI
| P5 & !P6 & P8: 1,2 ESID(R=07)
| F_ABORT_IND(R,A0=L) WF_NDISC
| P5 & !P6 & !P7 : 1,2,6,7 F_DATA_IND (See Note 1) OPI
| & !P8
| P5 & !P6 & P7 : 1,2,5,6,8 F_DATA_IND OPI
| & !P8 CDT (See Note 1)
---+-----------------------------------------------------------------
J | 1,2 F_CLOSE_FILE_IND CLIP
---+-----------------------------------------------------------------
K | P2 & P3 & !P5: 1,2 EFPA(CD-Req) WF_CD
| P2 & !P3 & !P5: 1,2 EFPA(no CD) IDLELI
| !P2 & !P5: 1,2 EFNA IDLELI
| P2 & !P3 & P5: 1,2,5 EFPA(no CD) IDLELI
| !P2 & P5: 1,2,5 EFNA IDLELI
| P2 & P3 & P5: 1,2,5 EFPA(CD-Req) WF_CD
---+-----------------------------------------------------------------
L | 1,2,10 F_NERP_IND RTRP
---+-----------------------------------------------------------------
M | 1,2 RTR IDLELI
---+-----------------------------------------------------------------
U | User Error UE
---------------------------------------------------------------------
Predicate P1: (I.SFID.Restart-pos > 0 AND V.Restart = No) OR (V.Mode
= Sender-only)
Note: Invalid Start File command.
注：無効なSTARTファイルコマンド。
Predicate P2: Positive Response
述語P2：肯定的な応答
Predicate P3: I.F_CLOSE_FILE_RS(+).Speaker = Yes
Predicate P4: I.F_START_FILE_RS(+).Restart-pos > V.Restart
Predicate P5: Special logic is used
述語P5：特別なロジックが使用されます
Predicate P6: V.Credit_L - 1 < 0
Note: Protocol Error because the Speaker has exceeded its available transmission credit.
注：スピーカーが利用可能な送信クレジットを超えたため、プロトコルエラー。
Predicate P7: V.Credit_L - 1 = 0
Note: The Speaker's credit must be reset before it can send further Data Exchange Buffers.
注：スピーカーのクレジットは、さらなるデータ交換バッファーを送信する前にリセットする必要があります。
Predicate P8: The calculus of the received CRC indicates an error
述語P8：受信したCRCの計算はエラーを示します
Action 1: Stop inactivity timer
アクション1：非アクティブタイマーを停止します
Action 2: Start inactivity timer
アクション2：非アクティブタイマーを開始します
Action 3: Build F_START_FILE_IND from I.SFID V.Restart-pos = I.SFID.Restart-pos
アクション3：i.sfid v.restart-pos = i.sfid.restart-posからf_start_file_indを構築する
Action 4: Build F_EERP_IND from I.EERP
アクション4：i.eerpからf_eerp_indを作成します
Action 5: Add special logic header to the command to be sent to the Speaker
アクション5：スピーカーに送信されるコマンドに特別なロジックヘッダーを追加する
Action 6: Suppress the special logic header from the data buffer before giving it to the user
アクション6：ユーザーに提供する前に、データバッファーから特別なロジックヘッダーを抑制します
Action 7: V.Credit_L = V.Credit_L - 1
Action 8: V.Credit_L = V.Window
アクション8：v.credit_l = v.window
Action 10: Build F_NERP_IND from I.NERP
アクション10：i.nerpからf_nerp_indを構築します
Note 1: Flow control in case of reception.
注1：受信の場合のフロー制御。
The ODETTE-FTP Listener must periodically send new credit to the Speaker. The timing of this operation will depend on:
Odette-FTPリスナーは、定期的にスピーカーに新しいクレジットを送信する必要があります。この操作のタイミングは次のとおりです。
1. The User Monitor's capacity to receive data. 2. The number of buffers available to ODETTE-FTP. 3. The Speaker's available credit, which must be equal to zero.
1. ユーザーモニターのデータを受信する能力。2. Odette-FTPが利用できるバッファーの数。3.スピーカーの利用可能なクレジットは、ゼロに等しい必要があります。
Consider an ODETTE-FTP entity that has sent a Start File (SFID) command and entered the Open Out Pending (OPOP) state. Its response on receiving a Positive Answer (SFPA) is documented in Speaker State Table 1, which shows that transition 'K' should be applied and is interpreted as follows:
STARTファイル（SFID）コマンドを送信し、Open Out Pended（OPOP）状態を入力したOdette-FTPエンティティを検討してください。肯定的な答え（SFPA）の受信に対するその応答は、スピーカー状態の表1に文書化されています。これは、遷移「k」を適用し、次のように解釈する必要があることを示しています。
if (I.SFPA.Restart-pos > V.Restart-pos) then
begin // invalid restart
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Output: ESID(R=02), // to peer ODETTE-FTP
F_ABORT_IND(R,AO=L); // to User Monitor
New State: WF_NDISC;
end
else begin
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Build F_START_FILE_CF(+) from I.SFPA
V.Credit_S = V.Window // initialise credit
Output: F_START_FILE_CF(+); // to User Monitor
New State: OPO;
end
ODETTE-FTP checks the restart position in the received Start File Positive Answer (SFPA) command. If it is invalid, it aborts the session by sending an End Session (ESID) command to its peer and an Abort indication (F_ABORT_IND) to its User Monitor. If the restart position is valid, a Start File confirmation (F_START_FILE_CF) is built and sent to the User Monitor, the credit window is initialised, and the Open Out (OPO) state is entered.
Odette-FTPは、受信開始ファイルPositive Answer（SFPA）コマンドの再起動位置をチェックします。無効な場合は、ピアにエンドセッション（ESID）コマンドを送信し、ユーザーモニターに中断表示（f_abort_ind）を送信することによりセッションを中止します。再起動位置が有効な場合、開始ファイル確認（f_start_file_cf）がビルドされ、ユーザーモニターに送信され、クレジットウィンドウが初期化され、オープン（OPO）状態が入力されます。
The choice of algorithms to use for security or compression between partners is for bilateral agreement outside of ODETTE-FTP.
パートナー間のセキュリティまたは圧縮に使用するアルゴリズムの選択は、Odette-FTP以外の二国間契約のためです。
The algorithms for symmetric and asymmetric cryptography and hashing are represented by a coded value, the cipher suite:
対称的および非対称暗号化およびハッシュのアルゴリズムは、コード化された値である暗号スイートで表されます。
Cipher Suite Symmetric Asymmetric Hashing
------------ ----------------- ------------ -------
01 3DES_EDE_CBC_3KEY RSA_PKCS1_15 SHA-1
02 AES_256_CBC RSA_PKCS1_15 SHA-1
Support of all cipher suites listed here is mandatory.
ここにリストされているすべての暗号スイートのサポートは必須です。
The certificates used must be [X.509] certificates.
使用される証明書は[X.509]証明書でなければなりません。
TripleDES is using Cipher Block Chaining (CBC) mode for added security and uses the Encryption Decryption Encryption (EDE) process with 3 different 64-bit keys.
Tripledesは、セキュリティを追加するために暗号ブロックチェーン（CBC）モードを使用しており、3つの異なる64ビットキーを備えた暗号化復号化暗号化（EDE）プロセスを使用しています。
RSA padding is as defined in [PKCS#1].
RSAパディングは[PKCS＃1]で定義されています。
AES is using a 256-bit key in CBC mode.
AESは、CBCモードで256ビットキーを使用しています。
An extended list of optional cipher suites may be used (Section 10.3), but there is no guarantee that two communicating ODETTE-FTP entities would both support these optional cipher suites.
オプションの暗号スイートの拡張リストを使用することもできますが（セクション10.3）、2つの通信Odette-FTPエンティティがこれらのオプションの暗号スイートをサポートするという保証はありません。
The algorithms and file enveloping formats available in ODETTE-FTP may be extended outside of this document.
Odette-FTPで利用可能なアルゴリズムとファイルの包括的な形式は、このドキュメントの外側に拡張できます。
An up-to-date list of cipher suite values for use in ODETTE-FTP is maintained by ODETTE International, and published on their website at www.odette.org.
Odette-FTPで使用するための暗号スイート値の最新リストは、Odette Internationalによって維持され、www.odette.orgのWebサイトで公開されています。
Certificates and certificate revocation lists may be exchanged as [CMS] enveloped files. It is therefore valid to exchange a [CMS] file that is neither encrypted, compressed, nor signed. It is an application implementation issue to determine the correct course of action on receipt of such a file.
証明書および証明書の取り消しリストは、[CMS]包括的なファイルとして交換される場合があります。したがって、暗号化、圧縮、署名のない[CMS]ファイルを交換することが有効です。このようなファイルの受領時に正しいアクションコースを決定するためのアプリケーションの実装の問題です。
ODETTE-FTP security requires the use of [X.509] certificates. If no security options are agreed for use, the send and receive passwords are sent in plain text. Whilst this is acceptable over X.25 and ISDN networks, this is a risky practice over insecure public networks such as the Internet.
Odette-FTPセキュリティには、[X.509]証明書の使用が必要です。セキュリティオプションが使用されていない場合、送信および受信パスワードはプレーンテキストで送信されます。これはX.25およびISDNネットワークで許容されますが、これはインターネットなどの安全でないパブリックネットワークよりも危険な慣行です。
All, some, or none of the security options available in ODETTE-FTP may be used. No recommendations for the use of these options are provided in this specification. Whilst use of the highest-strength encryption algorithms may seem admirable, there is often a performance tradeoff to be made, and signing all files and acknowledgements has potential legal implications that should be considered.
Odette-FTPで利用可能なセキュリティオプションはすべて使用できます。この仕様には、これらのオプションを使用するための推奨事項は提供されていません。最も高い強さの暗号化アルゴリズムの使用は賞賛に値するかもしれませんが、多くの場合、パフォーマンスのトレードオフが行われるべきであり、すべてのファイルと謝辞に署名する必要がある潜在的な法的意味合いがあります。
It should be noted that whilst the security measures ensure that an ODETTE-FTP partner is authenticated, it does not necessarily mean that the partner is authorised. Having proven the identity of a partner, it is an application issue to decide whether that partner is allowed to connect or exchange files.
セキュリティ対策は、オデットFTPパートナーが認証されていることを保証しますが、必ずしもパートナーが承認されていることを意味するわけではないことに注意する必要があります。パートナーの身元を証明したことで、そのパートナーがファイルを接続するか交換できるかどうかを判断するのはアプリケーションの問題です。
Extracted from [RFC3850]:
[RFC3850]から抽出：
"When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures have not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it.
「証明書を処理する場合、処理が失敗する可能性のある多くの状況があります。処理はユーザーエージェント、セキュリティゲートウェイ、または他のプログラムによって行われる可能性があるため、そのような障害を処理する方法はありません。障害はリストされていませんが、読者はそれらが重要ではないと仮定するべきではありません。逆のことは真実です。証明書が有効でメッセージに関連付けられていない場合、処理ソフトウェアは即座に顕著な手順を実行する必要があります。それについてのエンドユーザー。
Some of the many situations in which signature and certificate checking might fail include the following:
署名と証明書のチェックが失敗する可能性のある多くの状況のいくつかには、以下が含まれます。
No certificate chain leads to a trusted CA No ability to check the Certificate Revocation List (CRL) for a certificate An invalid CRL was received The CRL being checked is expired The certificate is expired The certificate has been revoked
証明書チェーンが信頼できるCAにつながることはありません証明書の取り消しリスト（CRL）を確認する能力は証明書（CRL）を受け取ったCRLが受け取られたCRLの有効期限が切れます。証明書が失効
There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly, and to decide what to do if the check fails. See RFC 3280 for additional information on certificate path validation."
証明書が無効になる可能性のある他のインスタンスが確かにあり、処理ソフトウェアの責任であり、それらをすべて徹底的にチェックし、チェックが失敗した場合に何をすべきかを決定することです。証明書パス検証の詳細については、RFC 3280を参照してください。」
The push / pull nature of ODETTE-FTP means that a party can make an outbound connection from behind a firewall to another party and exchange files in both directions. There is no need for both partners to open ports on their firewalls to allow incoming connections; only one party needs to allow incoming connections.
Odette-FTPのプッシュ /プルの性質は、パーティーがファイアウォールの後ろから別のパーティーにアウトバウンド接続を行い、両方向にファイルを交換できることを意味します。入ってくる接続を許可するために、両方のパートナーがファイアウォールでポートを開く必要はありません。着信接続を許可する必要がある当事者のみが必要です。
See Section 1.7 for a discussion of the benefits of session security [TLS] versus file security.
セッションセキュリティ[TLS]とファイルセキュリティの利点についての議論については、セクション1.7を参照してください。
This example demonstrates the mapping of a Virtual File into a sequence of ODETTE-FTP Data Exchange Buffers.
この例は、仮想ファイルの一連のOdette-FTPデータ交換バッファーへのマッピングを示しています。
Each line in this extract from 'The Rime of the Ancient Mariner' by Coleridge [RIME] is separated by CR-LFs in a file that is being transmitted as a T format file.
Coleridge [Rime]による「The Rime of the Ancient Mariner」からのこの抽出物の各ラインは、T形式ファイルとして送信されているファイルのCR-LFSによって分離されています。
It is an ancient Mariner, And he stoppeth one of three. "By thy long grey beard and glittering eye, Now wherefore stopp'st thou me?
それは古代のマリナーであり、彼は3つのうちの1つを止めます。「あなたの長い灰色のあごひげときらびやかな目によって、今、あなたは私を止めますか？
"The Bridegroom's doors are opened wide, And I am next of kin; The guests are met, the feast is set: May'st hear the merry din."
「花roomのドアは大きく開かれており、私は近親者です。ゲストが出会って、ごちそうが設定されています。メリーディンが聞こえます。」
He holds him with his skinny hand, "There was a ship," quoth he. "Hold off! unhand me, grey-beard loon!" Eftsoons his hand dropt he.
彼は彼の細い手で彼を抱きしめます。「船がありました」と彼。「頑張って！彼の手が彼を落とす。
He holds him with his glittering eye-- The Wedding-Guest stood still, And listens like a three years; child: The Mariner hath his will.
彼は彼のきらびやかな目で彼を抱きしめます - 結婚式のゲストはじっと立っていて、3年のように耳を傾けます。子供：マリナーは彼の意志を持っています。
The Wedding-Guest sat on a stone: He cannot chuse but hear; And thus spake on that ancient man, The bright-eyed Mariner.
結婚式の王は石の上に座っていました。したがって、その古代の男、明るい目のマリナーを吐き出します。
The ship was cheered, the harbour cleared, Merrily did we drop Below the kirk, below the hill, Below the light-house top.
船は歓声を上げ、港はきれいになり、陽気に丘の下のカークの下、灯台の頂上の下に落ちました。
The Exchange Buffers below were built from the above. The top line of each represents the ASCII code, while the two lines below give the hexadecimal value.
以下の交換バッファーは、上記から構築されました。それぞれの最上位はASCIIコードを表し、以下の2行は16進価値を示します。
Note that:
ご了承ください：
. The "D" at the beginning of each Exchange Buffer is the command code.
。各交換バッファの先頭にある「D」はコマンドコードです。
. The "?" preceding each subrecord is the header octet (see the hexadecimal value).
。「？」各サブレコードの前には、ヘッダーオクテットがあります（16進数を参照）。
Exchange Buffer 1
交換バッファー1
D?It is an ancient Mariner,..And he stoppeth one of three..."By
4347267266266666672467666720046626627767767626662662767662002472
4F9409301E01E395E40D129E52CDA1E4085034F005480FE50F6048255EDA2290
t?hy long grey beard and glittering eye,..Now wherefore stopp'st
7367266662676726667626662666776766626762004672766766676277677277
4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
?thou me?...."The Bridegroom's doors are opened wide,..And I am
2376672663000025662476666766627266677267626766662766620046624266
0F48F50D5FDADA248502294572FFD7304FF2301250F05E5407945CDA1E40901D
?next of kin;..The guests are met, the feast is set:..May'st he
2366772662666300566267677726762667227662666772672767300467277266
0FE5840F60B9EBDA485075534301250D54C04850651340930354ADAD19734085
a?r the merry din."....He holds him with his skinny hand,.."Ther
6372766266777266622000046266667266627676266727666672666620025667
1F204850D5229049EE2DADA8508FC43089D07948089303B9EE9081E4CDA24852
e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon
6327672627667222776762662002466626662276666626622676726667626666
5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE
!?"..Eftsoons his hand dropt he.....He holds him with his glitte
2320046776667266726666267677266200004626666726662767626672666776
1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445
r?ing eye--..The Wedding-Guest stood still,..And listens like a
7366626762200566256666662476772776662776662004662667766726666262
2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010
t?hree years; child:..The Mariner hath his will.....The Wedding-
7367662766773266666300566246766672667626672766620000566256666662
4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
G?uest sat on a stone:..He cannot chuse but hear;..And thus spak
4376772767266262776663004626666672667762677266673004662767727766
7F553403140FE01034FE5ADA85031EEF4038535025408512BDA1E4048530301B
e? on that ancient man,..The bright-eyed Mariner.....The ship wa
6326627667266666672666200566267666726766246766672000056627667276
5F0FE0481401E395E40D1ECDA4850229784D59540D129E52EDADA48503890071
s? cheered, the harbour cleared,..Merrily did we drop..Below the
7326666766227662667667726666766200467766726662762676700466672766
3F03855254C048508122F5203C51254CDAD5229C90494075042F0DA25CF70485
.kirk, below the hill,..Below the light-house top...
2B667622666672766266662004666727662666672667762767200
03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
o-----------------------------------------------------------------o
| | 7| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| | B -+-----+-----+-----+-----+-----+-----+-----+-----|
| | I 6| 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
| | T -+-----+-----+-----+-----+-----+-----+-----+-----|
| | 5| 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
| |----+-----+-----+-----+-----+-----+-----+-----+-----|
| | | | | | | | | | |
| | | | | | | | | | |
|------------| | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| BIT | | | | | | | | | |
| 4 3 2 1 | | | | | | | | | |
|============o====o=====+=====+=====+=====+=====+=====+=====+=====|
| 0 0 0 0 | 0 | | | SP | 0 | | P | | |
|------------|----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 0 1 | 1 | | | | 1 | A | Q | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 1 0 | 2 | | | | 2 | B | R | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 0 1 1 | 3 | | | | 3 | C | S | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 0 0 | 4 | | | | 4 | D | T | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 0 1 | 5 | | | | 5 | E | U | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 1 0 | 6 | | | & | 6 | F | V | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 0 1 1 1 | 7 | | | | 7 | G | W | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 0 0 | 8 | | | ( | 8 | H | X | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 0 1 | 9 | | | ) | 9 | I | Y | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 1 0 | 10 | | | | | J | Z | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 0 1 1 | 11 | | | | | K | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 0 0 | 12 | | | | | L | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 0 1 | 13 | | | - | | M | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 1 0 | 14 | | | . | | N | | | |
|------------+----|-----+-----+-----+-----+-----+-----+-----+-----|
| 1 1 1 1 | 15 | | | / | | O | | | |
o-----------------------------------------------------------------o
The International Organization for Standardization (ISO) Open Systems Interconnection (OSI) model is the basis for ODETTE-FTP.
国際標準化機関（ISO）オープンシステム相互接続（OSI）モデルは、Odette-FTPの基礎です。
ODETTE-FTP covers levels 4 to 7, and originally CCITT X.25 was the only recommended telecommunication protocol for OSI's layers 1, 2, 3.
Odette-FTPはレベル4から7をカバーし、元々CCITT X.25はOSIのレイヤー1、2、3の唯一の推奨電気通信プロトコルでした。
ISO Reference Model:
ISOリファレンスモデル：
+------------------------------+ <==== File Service
| Level-7 FTP application |
|------------------------------|
| Level-6 FTP presentation |
|------------------------------|
| Level-5 FTP session |
|------------------------------|
| Level-4 FTP transport |
|------------------------------| <==== Network Service
| Level-3 X.25 |
|------------------------------|
| Level-2 X.25 |
|------------------------------|
| Level-1 X.25 |
+------------------------------+
When an X.25 call is made over a PSDN, the Network User Address (NUA) of the destination must be specified in order that the PTT may route the call. The call placed is directed to the termination equipment upon the user's premises.
PSDNを介してX.25コールが行われる場合、PTTがコールをルーティングできるように、宛先のネットワークユーザーアドレス（NUA）を指定する必要があります。配置された通話は、ユーザーの敷地内の終了機器に向けられます。
It is possible to provide extra information in the Call Request Packet in addition to the mandatory NUA required by the PTT.
PTTが必要とする必須のNUAに加えて、コールリクエストパケットに追加の情報を提供することができます。
This extra information may be of 2 kinds:
この余分な情報は2種類かもしれません：
(a) A subaddress:
(a) サブアドレス：
It is simply an extension to the address and it is put into the called address field of the Call Request Packet. This information (Address + Subaddress) is taken from the destination address field of the F_CONNECT_RQ; therefore, from the user's point of view, there is no distinction between the main address and subaddress parts.
これは単にアドレスへの拡張機能であり、コールリクエストパケットの呼び出されたアドレスフィールドに配置されます。この情報（アドレスサブアドレス）は、f_connect_rqの宛先アドレスフィールドから取得されます。したがって、ユーザーの観点からは、メインアドレスとサブアドレス部品に区別はありません。
(b) User data:
(b) ユーザーデータ：
There is no standard for user data. Moreover, there is no information in the F_CONNECT_RQ from which the ODETTE-entity may derive user data to be put in the N_CONNECT_RQ; therefore, user data shall not be used.
ユーザーデータの標準はありません。さらに、f_connect_rqには、odette-entityがn_connect_rqに入れられるユーザーデータを導き出すことができる情報はありません。したがって、ユーザーデータは使用されません。
The SSID field SSIDSPEC specifies whether special logic must be applied (Y (yes) or N (no)) to the Data Exchange Buffer before the ODETTE-FTP moves the data into the NSDU (Network Service Data Unit) and passes control to the Network Service.
SSIDフィールドSSIDSPECは、Odette-FTPがデータをNSDU（ネットワークサービスデータユニット）に移動し、コントロールをネットワークに合格する前に、特別なロジックをデータ交換バッファーに適用する必要があるかどうかを指定します。サービス。
This logic is not applied to SSRM and SSID commands.
このロジックは、SSRMおよびSSIDコマンドには適用されません。
The "special-logic" parameter was created in order to allow the use of ODETTE-FTP over asynchronous links. The "special-logic" could be needed to enable terminals to access an X.25 network via an asynchronous entry (through a PAD: Packet Assembly / Disassembly). The "special-logic" is not needed in case of a whole X.25 connection. This "special-logic" realises a CRC function in order to detect errors due to the asynchronous medium.
「特別なロジック」パラメーターは、非同期リンクでOdette-FTPを使用できるように作成されました。端子が非同期エントリを介してX.25ネットワークにアクセスできるようにするには、「特別なロジック」が必要になる場合があります（パッドを介して：パケットアセンブリ /分解）。x.25接続全体の場合、「特別なロジック」は必要ありません。この「特別なロジック」は、非同期媒体によるエラーを検出するためにCRC関数を実現します。
Negotiation of the "special-logic" parameter in the SSID command is as follows:
SSIDコマンドの「特別なロジック」パラメーターの交渉は次のとおりです。
SSID SSID
-----------------------------------------------
special-logic=yes --------------------->
<------------------------------------ special-logic=yes
or
<------------------------------------ special-logic=no
special-logic=no ---------------------->
<------------------------------------ special-logic=no
This logic is activated when the "special-logic" parameter in the SSID specifies Y (yes).
このロジックは、SSIDの「特別なロジック」パラメーターがy（yes）を指定するとアクティブになります。
Special logic processing, when activated, will function within level 4 of the OSI model.
特別なロジック処理は、アクティブ化されると、OSIモデルのレベル4内で機能します。
+------------------------------+ <==== File Service
| Level-7 FTP application |
|------------------------------|
| Level-6 FTP presentation |
|------------------------------|
| Level-5 FTP session |
|------------------------------|
| Level-4 FTP transport |
| SPECIAL LOGIC PROCESSING |
|------------------------------| <==== Network Service
| Level-3 X.25 |
|------------------------------|
| Level-2 X.25 |
|------------------------------|
| Level-1 X.25 |
+------------------------------+
When transmitting an Exchange Buffer and special logic is active, layer 4 will wrap the Exchange Buffer in synchronization and delineation characters, then protect the data integrity by means of a block checksum (BCS). When receiving an Exchange Buffer and special logic is active, layer 4 will remove such things as synchronization and delineation characters, etc., before passing the Exchange Buffer to the higher layers.
交換バッファーと特別なロジックの送信がアクティブな場合、レイヤー4は交換バッファーを同期と描写文字で包み、ブロックチェックサム（BCS）を使用してデータの整合性を保護します。Exchange Bufferと特別なロジックを受信するとアクティブになると、レイヤー4は、交換バッファーをより高いレイヤーに渡す前に、同期や描写文字などなどのものを削除します。
Each envelope has a 1-byte header prefixed to it, and a 2-byte checksum appended to the end. The checksum is derived in a manner specified in the ISO DIS 8073 TRANSPORT LAYER documentation.
各エンベロープには、1バイトのヘッダーが付いており、最後まで2バイトのチェックサムが追加されています。チェックサムは、ISO DIS 8073輸送層のドキュメントで指定された方法で導き出されます。
The layout of the data buffer will be structured as follows:
データバッファのレイアウトは、次のように構成されます。
+------------------------------------------------------------------+
| S | B | | B | C |
| T | S | COMPLETE EXCHANGE BUFFER (CEB) | C | / |
| X | N | | S | R |
+------------------------------------------------------------------+
A A A A
| | | |
| +------------- Block sequence number | |
| | |
+----------------- Synchronization character | |
| |
Block checksum -----------------------+ |
|
Delineation character --------------------+
The envelope is initialised with an STX and the checksum variables are set to 0. The leading STX is not protected by the checksum calculation but is explicitly protected by a character compare at the receiver's end. The Exchange Buffer is processed character by character. As each character is removed from the Exchange Buffer, it is put through the checksum calculation and then, prior to its insertion in the envelope, it is put through the Shift-out transparency logic, which will result in either one or two characters being inserted. When the contents of the Exchange Buffer have been entirely processed, then the checksum variables are brought up to date by inserting two X'00's through the checksum calculator and the two resultant checksum characters forwarded to the Shift-out transparency logic for insertion into the envelope. Finally, a carriage return (CR) is appended to the envelope. The segment is now ready for transmission to line.
エンベロープはSTXで初期化され、チェックサム変数は0に設定されます。主要なSTXはチェックサムの計算によって保護されていませんが、受信機の端での文字比較によって明示的に保護されています。交換バッファーは、文字によって処理されます。各文字がExchangeバッファーから削除されると、チェックサムの計算に配置され、エンベロープに挿入する前に、シフトアウトの透明性ロジックに挿入され、1つまたは2つの文字が挿入されます。。交換バッファーの内容が完全に処理された場合、チェックサム変数は、チェックサム計算機を通して2つのX'00を挿入することにより最新の状態になります。。最後に、キャリッジリターン（CR）が封筒に追加されます。セグメントは、ラインへの送信の準備ができました。
Upon receipt of a valid envelope that has the correct sequence number, the host should increment his sequence number register ready for the next transmission.
正しいシーケンス番号を持つ有効なエンベロープを受け取ると、ホストは次の送信の準備が整ったシーケンス番号レジスタを増やす必要があります。
The receiver will initialise his receiving buffer area upon receipt of an STX character, place the STX at the beginning of the buffer, and reset checksum variables. All subsequent characters are processed using Shift-out logic before they are inserted into the buffer, at which point they will NOT be processed by the checksum calculator, although the character following the Shift-out (after subtracting X'20') will be. The checksum characters themselves will be processed by the checksum calculator by virtue of the design of the checksum algorithm.
受信者は、STX文字を受け取ったときに受信バッファーエリアを初期化し、STXをバッファーの先頭に配置し、チェックサム変数をリセットします。後続のすべての文字は、バッファに挿入される前にシフトアウトロジックを使用して処理されます。この時点で、チェックサム計算機によって処理されませんが、シフトアウト後の文字（x'20 'を減算した後）はそうです。チェックサム文字自体は、チェックサムアルゴリズムの設計により、チェックサム計算機によって処理されます。
The error correction scheme is implemented by the definition of three timers and the use of an ASCII NAK (Negative Acknowledgement) character followed by a C/R. The <NAK><C/R> will flow between the two session partners, but only as a consequence of previous bad data.
エラー修正スキームは、3つのタイマーの定義とASCII NAK（否定的な確認）文字の使用とC/Rの使用によって実装されます。<nak> <c/r>は、2つのセッションパートナー間で流れますが、以前の悪いデータの結果としてのみ流れます。
A user of the error recovery correcting extension must always work with a credit value of 1. This can be forced upon any session partner at SSID negotiation. The effect will be to force a simple half-duplex flip-flop protocol.
エラー回復のユーザーは、常に1のクレジット値で動作する必要があります。これは、SSID交渉のセッションパートナーに強制することができます。効果は、単純な半分二重フリップフロッププロトコルを強制することです。
Upon receipt of a bad block, send <NAK><C/R> to the session partner.
悪いブロックを受け取ったら、<nak> <c/r>をセッションパートナーに送信します。
Upon receipt of a <NAK><C/R>, a session partner should retransmit the last block in its entirety.
<nak> <c/r>を受け取ると、セッションパートナーは最後のブロック全体を再送信する必要があります。
The majority of error conditions will be detected by a bad BCS sequence. However, certain conditions cannot be so detected. For example, a corrupt C/R will mean that the receiver will not know that the end of a block has been reached. No matter how long he waits, no more data will come from the sender. Thus, a timer is the only way to detect this type of corruption. There are three timers needed to detect all possible malignant conditions of this type.
エラー条件の大部分は、悪いBCSシーケンスによって検出されます。ただし、特定の条件をそのように検出することはできません。たとえば、破損したC/Rは、レシーバーがブロックの終了に到達したことを知らないことを意味します。彼がどれだけ長く待っても、これ以上のデータは送信者からのものではありません。したがって、タイマーは、このタイプの腐敗を検出する唯一の方法です。このタイプのすべての悪性条件を検出するために必要な3つのタイマーがあります。
T1 - Exchange Buffer Time Out (Inactivity or Response) T2 - Inter Character Time Out T3 - Data Carrier Detect Loss Time Out
T1-交換バッファタイムアウト（非アクティブまたは応答）T2-インターキャラクタータイムアウトT3-データキャリアは損失時間を検出します
The three timers are in addition to the timer defined in the original protocol.
3つのタイマーは、元のプロトコルで定義されているタイマーに追加されます。
TIMER T1 - RESPONSE TIME OUT (DEFAULT = 45 SECONDS):
タイマーT1-応答タイム（デフォルト= 45秒）：
Used to detect a high-level block Time Out, e.g., the Time Out between an SFID and its associated SFPA or SFNA response.
SFIDと関連するSFPAまたはSFNA応答の間のタイムアウトなど、高レベルのブロックタイムアウトを検出するために使用されます。
Started - It is started after the last character of an exchange buffer has been sent to the line.
開始 - 交換バッファの最後の文字がラインに送信された後に開始されます。
Stopped - It is stopped when an STX has been received.
停止 - STXが受信されたときに停止します。
Expiry - Retransmit the whole block again, until such time as the retry limit has been reached.
有効期限 - 再試行制限に達するまで、ブロック全体を再度再送信します。
TIMER T2 - INTER CHARACTER TIME OUT (DEFAULT = 7 SECONDS):
タイマーT2-文字間タイムアウト（デフォルト= 7秒）：
Used to detect errors in the reception of individual characters.
個々の文字の受信のエラーを検出するために使用されます。
Started - For an asynchronous entity, it is started upon receipt of each character while in synchronisation mode. For an X.25 entity, it is started after a received block that did not terminate an Exchange Buffer.
開始 - 非同期エンティティの場合、同期モードで各文字を受信すると開始されます。X.25エンティティの場合、交換バッファーを終了しなかった受信ブロックの後に開始されます。
Stopped - Upon receipt of the next character.
停止 - 次のキャラクターを受け取ると。
Expiry - Send a <NAK><C/R>, drop out of synchronised mode, and go back and listen to line.
有効期限 - <nak> <c/r>を送信し、同期モードからドロップアウトして、戻ってラインを聴きます。
TIMER T3 - DATA CARRIER TEMPORARY LOSS (DEFAULT = 1 SECOND):
タイマーT3-データキャリアの一時的な損失（デフォルト= 1秒）：
Used by an asynchronous entity only and is used to detect a temporary carrier failure.
非同期エンティティのみが使用し、一時的なキャリアの障害を検出するために使用されます。
Started - When DCD (Data Carrier Detect) is lost.
開始-DCD（データキャリア検出）が失われたとき。
Stopped - When DCD is regained.
停止 - DCDが再び回復したとき。
Expiry - Disconnect the session.
有効期限 - セッションを切断します。
Data corruption when it occurs can be categorised in one of five ways:
データの破損が発生した場合、5つの方法のいずれかで分類できます。
(1) CORRUPT STX (START OF TEXT)
(1) 破損したstx（テキストの開始）
In this situation the STX is not seen and synchronisation is not achieved. The terminating C/R is received out of synchronisation and hence the block is not seen by the receiver. A <NAK><C/R> is transmitted to the sender to indicate this. The sender should then retransmit the last block (each implementation will need to set a retry limit to be used for the number of consecutive times it attempts to retransmit a block -- a default limit of 5 is recommended). All data received outside synchronisation (except <NAK><C/R>) are ignored.
この状況では、STXは見られず、同期は達成されません。終了C/Rは同期から受信されるため、ブロックは受信機によっては表示されません。a <nak> <c/r>は、これを示すために送信者に送信されます。次に、送信者は最後のブロックを再送信する必要があります（各実装は、ブロックを再送信しようとする連続回数のために使用されるために再試行制限を設定する必要があります - 5のデフォルト制限が推奨されます）。外部の同期（<nak> <c/r>を除く）外部のデータは無視されます。
(A) (B)
（a）（b）
Dropped Start of Text (STX)
テキストのドロップされた開始（STX）
+-------------------------+
| | B | | B | C |
-----| | S | CEB | C | / |-----> Not sync
| | N | | S | R |
+-------------------------+
+-------+
| N | C |
<-----| A | / |----- Not sync
| K | R |
+-------+
Exchange Buffer Resent
交換バッファーがresします
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
(2) CORRUPT TERMINATION (C/R)
(2) 破損した終了（c/r）
This situation manifests itself as an extended period of synchronisation with no activity. The T2 timer will detect this condition.
この状況は、アクティビティのない延長された同期の期間として現れます。T2タイマーはこの状態を検出します。
(A) (B)
（a）（b）
Corrupt Carriage Return
破損したキャリッジが戻ります
+-------------------------+
| S | B | | B | |
-----| T | S | CEB | C | |-----> No activity
| X | N | | S | |
+-------------------------+
+-------+
| N | C | T2
<-----| A | / |----- Timed out
| K | R |
+-------+
Exchange Buffer Resent
交換バッファーがresします
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
(3) BAD DATA (4) BAD BCS (BLOCK CHECK SUM)
(3) 悪いデータ（4）悪いBC（ブロックチェック合計）
In this situation, the receiver is unable to tell whether the error is bad data or bad BCS. In either case, the response is to discard the Exchange Buffer and send a <NAK><C/R>.
この状況では、レシーバーはエラーが悪いデータであるか悪いBCであるかを判断できません。どちらの場合でも、回答は交換バッファーを破棄し、a <nak> <c/r>を送信することです。
(A) (B)
（a）（b）
Bad Data/BCS
悪いデータ/BC
+-------------------------+
| S | B | | B | C | Bad data
-----| T | S | "%! | C | / |-----> detected
| X | N | | S | R |
+-------------------------+
+-------+
| N | C |
<-----| A | / |----- Discard Block
| K | R |
+-------+
Exchange Buffer Resent
交換バッファーがresします
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Data OK
| X | N | | S | R |
+-------------------------+
(5) BAD BLOCK SEQUENCE NUMBER (BSN)
(5) 悪いブロックシーケンス番号（BSN）
A circular sequential number (0 up to and including 9) is assigned to transmitted Exchange Buffers. This is to aid detection of duplicate or out-of-sequence Exchange Buffers. Once a duplicate block is detected, the Exchange Buffer in question is discarded. Once an out of sequence block is detected, this should result in a protocol violation.
円形のシーケンシャル数（9までの0）が送信された交換バッファーに割り当てられます。これは、重複またはシーケンスの交換バッファーの検出を支援するためです。複製ブロックが検出されると、問題の交換バッファーが破棄されます。シーケンスから外れたブロックが検出されると、これによりプロトコル違反が発生します。
Example protocol sequence:
例プロトコルシーケンス：
(A) (B)
（a）（b）
Exchange Buffer Being Sent
送信中の交換バッファー
+-------------------------+
| S | | | B | C | Expecting
-----| T | 0 | EERP | C | / |-----> BSN=0
| X | | | S | R | Transmission
+-------------------------+
Exchange Buffer Being Sent
送信中の交換バッファー
+-------------------------+
| S | | | B | C | Response to
<----| T | 0 | RTR | C | / |----- Previous
| X | | | S | R | Block
+-------------------------+
Exchange Buffer Being Sent
送信中の交換バッファー
+-------------------------+ Expecting
| S | | | B | C | BSN=1 (Block
-----| T | 1 | SFID | C | / |- // -> lost in
| X | | | S | R | Transmission)
+-------------------------+ T1 Timed Out
Exchange Buffer Being Sent
送信中の交換バッファー
+-------------------------+
| S | | | B | C | Send last
<----| T | 0 | RTR | C | / |----- Block
| X | | | S | R | again
+-------------------------+
Discard Block and start Timer T1
ブロックを破棄し、タイマーT1を開始します
T1 Timed Out Exchange Buffer Resent
T1タイムアウトエクスチェンジバッファーがresします
+-------------------------+
| S | | | B | C | Expecting
-----| T | 1 | SFID | C | / |-----> BSN=1
| X | | | S | R | Block OK
+-------------------------+
Exchange Buffer Being Sent
送信中の交換バッファー
+-------------------------+
| S | | | B | C | Response
<----| T | 1 | SFPA | C | / |----- BSN=1
| X | | | S | R | Block OK
+-------------------------+
Exchange Buffer Being Sent
送信中の交換バッファー
+-------------------------+
| S | | | B | C |
-----| T | 2 | DATA | C | / |-----> Data OK
| X | | | S | R |
+-------------------------+
Note: A credit value of 1 must be used to guarantee half-duplex flip-flop.
注：半分二重フリップフロップを保証するために、1のクレジット値を使用する必要があります。
The following functions will be executed in sequence:
次の機能は、順番に実行されます。
1. Calculation of the Block Sequence Number (BSN):
1. ブロックシーケンス番号（BSN）の計算：
BSN is set to zero by SSID. First block will be sent with value zero. Value of BSN is increased by one for each data buffer to be transmitted. When BSN value exceeds 9, counter will be reset to zero.
BSNはSSIDによってゼロに設定されています。最初のブロックは値ゼロで送信されます。BSNの値は、送信されるデータバッファーごとに1つ増加します。BSN値が9を超えると、カウンターはゼロにリセットされます。
Format: numeric/1 pos.
フォーマット：numeric/1 pos。
2. Calculation of the Block Checksum (BCS):
2. ブロックチェックサム（BCS）の計算：
Calculation is done as specified in the ISO DIS 8073 TRANSPORT LAYER document.
計算は、ISO DIS 8073輸送層ドキュメントで指定されているとおりに行われます。
Format: binary/2 pos.
フォーマット：Binary/2 Pos。
3. Shift-out transparency (See TRANSMIT/RECEIVE logic.)
3. シフトアウトの透明性（送信/受信ロジックを参照してください。）
To avoid appearance of any control characters in the data stream, all the characters of the extended Exchange Buffer (with exception of the STX and carriage return characters enveloping the buffer) are put through a Shift-out logic, which result in a character being inserted (SO) and adding hex value '20' to the control character.
データストリーム内のコントロール文字の外観を回避するために、拡張交換バッファーのすべての文字（STXおよびキャリッジリターン文字を除き、バッファを包み込むことを除く）がシフトアウトロジックに配置され、文字が挿入されます。（そう）、コントロール文字に16進価値 '20'を追加します。
4. The carriage return is inserted at the end of the data buffer.
4. キャリッジリターンは、データバッファの端に挿入されます。
Note: After adding STX, BSN, BCS, CR, and SO-logic, the data buffer may exceed the Data Exchange Buffer size.
注：STX、BSN、BCS、CR、およびSOロジックを追加した後、データバッファーはデータ交換バッファーのサイズを超える可能性があります。
These follow the ISO DIS 8073 TRANSPORT LAYER standard.
これらは、ISO DIS 8073トランスポートレイヤー標準に従います。
SYMBOLS:
シンボル：
The following symbols are used:
次のシンボルが使用されます。
C0,C1 Variables used in the algorithm L Length of the complete NSDU X Value of the first octet of the checksum parameter Y Value of the second octet of the checksum parameter
C0、C1アルゴリズムで使用されるC1変数チェックサムパラメーターの最初のオクテットの完全なNSDU X値チェックサムパラメーターの2番目のオクテットの値Y値
ARITHMETIC CONVENTIONS:
算術規則：
Addition is performed in one of the two following modes:
追加は、次の2つのモードのいずれかで実行されます。
a) modulo 255 arithmetic b) one's complement arithmetic in which if any of the variables has the value minus zero (i.e., 255) it shall be regarded as though if was plus zero (i.e., 0).
a) Modulo 255算術b）変数のいずれかが値をマイナスゼロ（つまり、255）がゼロ（つまり、0）であると見なされる補完算術補完算術。
ALGORITHM FOR GENERATING CHECKSUM PARAMETERS:
チェックサムパラメーターを生成するためのアルゴリズム：
. Set up the complete NSDU with the value of the checksum parameter field set to zero.
。Checksumパラメーターフィールドの値をゼロに設定して、完全なNSDUを設定します。
. Initialise C0 and C1 to zero.
。C0とC1をゼロに初期化します。
. Process each octet sequentially from i=1 to L by
。各オクテットを順番にi = 1からlに処理します
a) adding the value of the octet to C0, then b) adding the value of C0 to C1.
a) オクテットの値をC0に追加し、b）C0の値をC1に追加します。
. Calculate X and Y such that
。xとyを計算します
X = C0 - C1
Y = C1 - 2*C0
. Place the values X and Y in the checksum bytes 1 and 2, respectively.
。値xとyをそれぞれチェックサムバイト1と2に配置します。
. Initialise parameters C0 and C1 to zero.
。パラメーターC0およびC1からゼロを初期化します。
. Process each octet of NSDU sequentially from i=1 to L by
。nsduの各オクテットをi = 1からlに順番に処理します
a) adding the value of the octet to C0, then b) adding the value of C0 to C1.
a) オクテットの値をC0に追加し、b）C0の値をC1に追加します。
. If, when all the octets have been processed, either or both C0 and C1 does not have the value zero, then the checksum formulas have not been satisfied.
。すべてのオクテットが処理されている場合、C0と両方のC0と両方に値がゼロにない場合、チェックサム式は満たされていません。
Note that the nature of the algorithm is such that it is not necessary to compare explicitly the stored checksum bytes.
アルゴリズムの性質は、保存されたチェックサムバイトを明示的に比較する必要がないようなものであることに注意してください。
(Transparency for all control characters)
（すべてのコントロール文字の透明性）
TRANSMIT LOGIC (values SO: X'0E' or X'8E')
ロジックを送信します（values so：x'0e 'またはx'8e'）
Buffer(1), ... , (n) is a character in the buffer to be sent.
バッファ（1）、...、（n）は、送信されるバッファーの文字です。
FOR i=1 to n /* for all octets of the buffer */
IF ((buffer(i) & X'7F') < X'20')
THEN output (SO) output (buffer(i) + X'20')
その後、出力（so）出力（バッファ（i）x'20 '）
ELSE output (buffer(i))
else output（バッファ（i））
NEXT:
次：
RECEIVE LOGIC (values SO: X'0E' or X'8E')
ロジックを受信します（values so：x'0e 'またはx'8e'）
Buffer(1), ... , (n) is a character in the received buffer.
バッファー（1）、...、（n）は、受信したバッファーの文字です。
drop = false
FOR i=1 to n /* for all octets of the buffer */
IF drop = true
drop = trueの場合
THEN output (buffer(i) - X'20') drop = false
その後、出力（バッファー（i）-x'20 '）drop = false
ELSE IF buffer(i) = (X'0D' or X'8D')
THEN Stop
ELSE IF buffer(i) = SO
THEN drop = true
ELSE output (buffer(i))
NEXT:
次：
Before an (ODETTE-FTP) asynchronous entity --> Modem --> PAD --> (ODETTE-FTP) native X.25 link can be established, the target PAD parameters must be set such that correct communication is established. It is strongly recommended that the PAD parameters are set by the X.25 entity. CCITT recommendations X.3, X.28, and X.29 define the PAD parameters and procedures for exchange of control information and user data between a PAD and a packet mode Data Terminal Equipment (DTE).
（odette-ftp）非同期エンティティ - > modem-> pad->（odette-ftp）ネイティブx.25リンクを確立することができます。正しい通信が確立されるようにターゲットパッドパラメーターを設定する必要があります。PADパラメーターをX.25エンティティによって設定することを強くお勧めします。CCITTの推奨事項X.3、X.28、およびX.29は、パッドとパケットモードのデータ端子機器（DTE）間の制御情報とユーザーデータの交換のためのパッドパラメーターと手順を定義します。
Following is the Parameter list and values used to set the PAD for ODETTE-FTP communication. For further detailed information see the specification for CCITT X.25, X.28, X.29 and X.3.
次のとおり、パラメーターリストと、Odette-FTP通信のパッドを設定するために使用される値です。詳細については、CCITT X.25、X.28、X.29およびX.3の仕様を参照してください。
No. Description Value Meaning
---------------------------------------------------------------
1 Escape from Data Transfer 0 Controlled by host
2 Echo 0 No Echo
3 Data Forwarding Signal 2 Carriage Return
4 Selection of Idle Timer Delay 20 1 second
5 Ancillary Device Control 0 X-ON, X-OFF not used
6 PAD Service Signals 1 All except prompt
7 Procedure on Break 2 Reset
8 Discard Output 0 Do not discard
9 Padding after Carriage Return 0 No padding
10 Line Folding 0 No line folding
11 Terminal Data Rate - Read only
12 Flow Control of the PAD 0 No flow control used
13 Linefeed Insertion after C/R 0 No linefeed
14 Linefeed Padding 0 No linefeed padding
15 Editing 0 No editing
16 Character Delete 127 Delete
17 Line Delete 24 <CTRL>X
18 Line Display 18 <CTRL>R
19 Editing PAD Service Signals 0 No service signal
20 Echo Mask 0 No echo mask
21 Parity Treatment 0 No parity check
22 Page Wait 0 No page wait
Note 1:
注1：
Refer to CCITT (1984) - Parameters 1 - 12 are mandatory and available internationally. - Parameters 13 - 22 may be available on certain networks and may also be available internationally. - A parameter value may be mandatory or optional.
CCITT（1984）を参照 - パラメーター1-12は必須であり、国際的に利用可能です。 - パラメーター13-22は、特定のネットワークで利用できる場合があり、国際的にも利用できる場合があります。 - パラメーター値は必須またはオプションです。
The ODETTE profile refers only to parameter values which must be internationally implemented if the parameter is made available internationally.
Odetteプロファイルは、パラメーターが国際的に利用可能になった場合に国際的に実装する必要があるパラメーター値のみを指します。
The ODETTE-FTP "special-logic" parameter may be impossible on some PADs because they do not support of some of the parameters (13 - 22). (If the PAD is supporting parity check (21) by default, ODETTE-FTP special logic would be impossible.)
オデットFTPの「特別なロジック」パラメーターは、一部のパラメーターをサポートしていないため、一部のパッドでは不可能な場合があります（13-22）。（パッドがパリティチェック（21）をデフォルトでサポートしている場合、Odette-FTP特別ロジックは不可能です。）
It is a user responsibility to ensure special logic consistency when making the PAD subscription.
パッドサブスクリプションを作成するときに特別なロジックの一貫性を確保することは、ユーザーの責任です。
Note 2:
注2：
Some parameters may have to be set differently depending on: - Make and function of the start-stop mode DTE entity. - Start-stop mode DTE entity ODETTE-FTP monitor function. - PAD services implemented. - Packet mode DTE entity ODETTE-FTP monitor function.
一部のパラメーターは、以下に応じて異なる方法で設定する必要がある場合があります。-スタートストップモードDTEエンティティの作成と機能。 - スタートストップモードDTEエンティティOdette-FTPモニター機能。 - パッドサービスが実装されました。 - パケットモードDTEエンティティodette-ftpモニター機能。
This appendix describes the recommendation of ODETTE Group 4 (1) for the use of OFTP (2) over X.25 over ISDN.
この付録では、ISDNを超えるX.25を超えるOFTP（2）を使用するためのOdette Group 4（1）の推奨について説明しています。
(1) ODETTE Group 4 is responsible for the specification of Telecommunications standards and recommendations for use within the Automotive Industry.
(1) Odette Group 4は、自動車業界で使用するための通信基準の仕様と推奨事項を担当しています。
(2) OFTP (ODETTE File Transfer Protocol) is the communications standard specified by ODETTE Group 4 designed for the transfer of both EDI and non-EDI data.
(2) OFTP（Odetteファイル転送プロトコル）は、EDIデータと非EDIデータの両方を転送するために設計されたOdette Group 4によって指定された通信標準です。
This document offers an introductory overview of a technical subject. It is structured to contain the ODETTE recommendation, together with introductory information for the person not familiar with ISDN, and notes on the issues associated with the implementation of the recommendation.
このドキュメントは、技術的なテーマの概要を提供します。ISDNに精通していない人の紹介情報と、推奨事項の実装に関連する問題に関するメモとともに、Odetteの推奨事項を含むように構成されています。
The first section provides the detailed ODETTE recommendation, which is followed by a general discussion. If you are not familiar with the terminology, please read the subsequent sections first.
最初のセクションでは、詳細なオデットの推奨事項を提供し、その後に一般的な議論が続きます。用語に慣れていない場合は、最初に後続のセクションをお読みください。
How far an existing X.25 Line adapter may be replaced by an ISDN line adapter in an installation depends on the opportunities in view of connections (X.25 or ISDN) of the involved partners for file transfer.
既存のX.25ラインアダプターが、インストール内のISDNラインアダプターにどの程度置き換えるかは、ファイル転送の関係パートナーの接続（X.25またはISDN）を考慮した機会に依存します。
Companies that keep many connections to external partners (for example, car manufacturing companies) may use the OFTP file transfer in view of compatibility, which must always be considered anyway only in parallel to the X.25 network.
外部パートナー（たとえば、自動車製造会社）との多くの接続を維持する企業は、互換性を考慮してOFTPファイル転送を使用する場合があります。
It is not the aim of this recommendation to remove the OFTP file transfer generally from the X.25 network to the ISDN network. This will not always be possible for international connections because of technical reasons, and this does not always make sense for connections with a low size of data to be transmitted.
一般にX.25ネットワークからISDNネットワークへのOFTPファイル転送を削除することは、この推奨事項の目的ではありません。これは、技術的な理由により、国際的なつながりで常に可能であるとは限りません。これは、低いサイズのデータを送信するために常に意味があるとは限りません。
Certainly, the use of ISDN, when exchanging a high volume of data (for example, CAD/CAM files), is very much cheaper than the use of an X.25 network. For such cases, this recommendation shall provide a cost-effective possibility for file transfer.
確かに、ISDNの使用は、大量のデータ（たとえば、CAD/CAMファイル）を交換する場合、X.25ネットワークの使用よりもはるかに安価です。そのような場合、この推奨事項は、ファイル転送の費用対効果の高い可能性を提供するものとします。
This appendix is organized as follows. D.1 defines the ODETTE recommendation in these terms, D.2 introduces the ISDN environment to the unfamiliar reader, D.3 describes the various methods of connecting to ISDN, and D.4 covers implementation issues.
この付録は次のように整理されています。D.1これらの用語でオデットの推奨を定義し、D.2はISDN環境をなじみのない読者に導入し、D.3はISDNに接続するさまざまな方法を説明し、D.4は実装の問題をカバーしています。
X.25: Level 2 ISO 7776 Protocol
X.25：レベル2 ISO 7776プロトコル
Level 3 ISO 8208 Protocol
レベル3 ISO 8208プロトコル
Packet Size 128
パケットサイズ128
Level 2 7 Window Size
レベル2 7ウィンドウサイズ
Level 3 7 Window Size
レベル3 7ウィンドウサイズ
First LCN 1
最初のLCN 1
Number of LCNs 1
LCNの数1
Facilities Window Size and Packet Size negotiation shall be supported by everybody. Call User Data should not be required.
施設のウィンドウサイズとパケットサイズのネゴシエーションは、すべての人がサポートするものとします。呼び出しユーザーデータは必須ではありません。
Calling NUA Optionally provided by the call initiator.
コールイニシエーターによってオプションで提供されるNUAの呼び出し。
Called NUA Should be set to a value where the last 'n' digits can be specified by the called party.
呼ばれるNUAは、呼び出されたパーティーで最後の「n」数字を指定できる値に設定する必要があります。
ISDN: Apart from requesting a 64K unrestricted digital call, no ISDN features shall be required.
ISDN：64Kの無制限のデジタルコールを要求することは別として、ISDN機能は必要ありません。
Timeout control: To avoid connections (B channels) within the circuit-switched ISDN network remaining active but unused for a long time, the adapter should include a timeout control.
タイムアウト制御：回路で切り替えられたISDNネットワーク内の接続（Bチャネル）を避けるために、アクティブなままですが、長期間使用されていないため、アダプターにはタイムアウト制御が含まれている必要があります。
An ISDN connection (B channel) should be released if no X.25 packets have been transmitted on this connection for a longer time. For flexibility a variable user definable timer should be incorporated into the adapter.
x.25パケットがこの接続に長時間送信されていない場合、ISDN接続（Bチャネル）をリリースする必要があります。柔軟性のために、可変ユーザーの定義可能なタイマーをアダプターに組み込む必要があります。
In the event of a timeout situation the adapter has to release the ISDN connection and notify the local OFTP by the transmission of a clear packet.
タイムアウトの状況が発生した場合、アダプターはISDN接続をリリースし、クリアパケットの送信によってローカルOFTPに通知する必要があります。
The pages that follow are informational and do not form part of this recommendation.
以下のページは情報提供であり、この推奨の一部を形成しません。
The use of digital encoding techniques over such high-quality, error-free backbone networks has allowed the PTTs to offer high bandwidths to the end user. The service is named ISDN (Integrated Services Digital Network).
このような高品質でエラーのないバックボーンネットワークにわたってデジタルエンコーディング技術を使用することで、PTTはエンドユーザーに高い帯域幅を提供することができました。このサービスの名前はISDN（Integrated Services Digital Network）です。
The increasing need to transfer larger volumes of EDI data, in particular CAD/CAM drawings, has focused attention upon high-speed, low-cost communication. The traditional X.25 over a Packet Switched Data Network (PSDN) has been a good general purpose communications subsystem. Unfortunately, its cost and transfer speed make PSDN expensive for the new requirement.
大量のEDIデータ、特にCAD/CAM図面を転送する必要性が高まっているため、高速で低コストの通信に注目を集めています。パケット切り替えデータネットワーク（PSDN）を介した従来のX.25は、良好な汎用通信サブシステムです。残念ながら、そのコストと転送速度により、新しい要件のためにPSDNが高価になります。
X.25 over the new ISDN provides both the transfer speed and cost benefits to satisfy the new requirements.
X.25新しいISDNを介して、新しい要件を満たすために、転送速度とコストの両方のメリットを提供します。
We include the following terminology because for us to make sense of ISDN and X.25, it is important that we use definitions precisely and avoid the abuses of the past.
ISDNとX.25を理解するためには、定義を正確に使用し、過去の虐待を避けることが重要であるため、次の用語を含めます。
ISDN: Integrated Services Digital Network
ISDN：統合サービスデジタルネットワーク
X.25: X.25 is a communications protocol. It defines the structure of data packets that comprise the protocol and the manner in which they are used.
X.25：X.25は通信プロトコルです。プロトコルを構成するデータパケットの構造と使用方法を定義します。
PSDN: A PSDN (Packet Switched Data Network) is a network over which the X.25 protocol is operated.
PSDN：PSDN（Packet Switched Data Network）は、X.25プロトコルが操作されるネットワークです。
PSPDN: A PSPDN (Packet Switched Public Data Network) is a PSDN operated by the PTTs. PSPDNs are given trade names, such as PSS in the UK, Datex-P in Germany, and Transpac in France.
PSPDN：PSPDN（パケット切り替えパブリックデータネットワーク）は、PTTSが操作するPSDNです。PSPDNには、英国のPSS、ドイツのDateX-P、フランスのTranspacなどの商品が与えられています。
BRI: Basic Rate Interface, also known as Basic Rate Access, defines an ISDN facility with 2 x 64 K B channels.
BRI：基本レートアクセスとも呼ばれる基本レートインターフェイスは、2 x 64 K Bチャネルを備えたISDN施設を定義します。
PRI: Primary Rate Interface, also known as Primary Rate Access, defines an ISDN facility with 30 x 64 K B channels.
PRI：プライマリレートアクセスとも呼ばれるプライマリレートインターフェイスは、30 x 64 K Bチャネルを備えたISDN施設を定義します。
Channels: ISDN is typically brought into a consumer's premises using a twisted pair of wire. Over this wire, data can be transmitted in frequency bands. These frequency bands are allocated as channels.
チャネル：ISDNは通常、ねじれたワイヤーを使用して消費者の施設に持ち込まれます。このワイヤーで、データは周波数帯域で送信できます。これらの周波数帯域はチャネルとして割り当てられます。
B channels: The B channels are the data channels and operate at 64 Kb. The two end users of a connection will communicate over a B channel.
Bチャネル：Bチャネルはデータチャネルであり、64 kbで動作します。接続の2つのエンドユーザーは、Bチャネルを介して通信します。
D channel: Signalling on ISDN is performed over the D channel. Signalling is used to set up and release connections on the B channels. In some countries, the D channel can also be used for limited X.25 access to the PTTs' PSDN.
Dチャネル：ISDNでのシグナリングは、Dチャネルで実行されます。シグナリングは、Bチャネルの接続をセットアップおよび解放するために使用されます。一部の国では、Dチャネルは、PTTSのPSDNへのX.25アクセスが制限されるためにも使用できます。
The D channel operates at the lower speed of 16 Kb as it is normally used only at the beginning and end of a connection.
Dチャネルは、通常、接続の開始と終了時にのみ使用されるため、16 kBの低速度で動作します。
Bandwidth Allocation:
2 Wire B2 - 64 Kb
Twisted Pair B1 - 64 Kb
D Channel - 16 Kb
The standard for the operation of the D channel is called ETSI and is used in most European countries. However, some countries that started the introduction very early used proprietary standards, for example:
Dチャネルの運用の基準はETSIと呼ばれ、ほとんどのヨーロッパ諸国で使用されています。ただし、序文を開始した一部の国では、非常に早期に使用された独自の基準、たとえば：
1TR6 - Used in Germany BTNR - Used in the UK
1TR6-ドイツで使用BTNR-英国で使用
Although there are D channel variations, this will not affect communications over the B channels as the communication over the D channel is between the subscriber and the ISDN service provider.
Dチャネルのバリエーションはありますが、Dチャネル上の通信がサブスクライバーとISDNサービスプロバイダーの間であるため、これはBチャネル上の通信に影響しません。
However, the consumer's equipment must be able to handle the channel D signalling operated by the ISDN service provider and so there may be a problem of equipment availability and certification.
ただし、消費者の機器は、ISDNサービスプロバイダーが操作するチャネルDシグナル伝達を処理できる必要があるため、機器の可用性と認定の問題がある可能性があります。
All the PTTs have committed to migrate to ETSI (also known as EURO-ISDN and Q.931) and many are currently supporting both their national variant and ETSI. It is advisable that in this situation the subscriber select the ETSI variant to avoid unnecessary equipment obsolescence.
すべてのPTTはETSI（Euro-ISDNおよびQ.931とも呼ばれる）に移住することを約束しており、多くは現在、国のバリアントとETSIの両方をサポートしています。この状況では、サブスクライバーがETSIバリアントを選択して、不必要な機器の陳腐化を避けることをお勧めします。
Services: The high-speed service is provided in two forms, Basic and Primary.
サービス：高速サービスは、基本とプライマリの2つの形式で提供されます。
Basic: 2+D, the D 2B channel operates at 16 Kb. The Basic Rate access is normally provided to the subscriber over simple twisted pair cable.
基本：2 D、D 2Bチャネルは16 kbで動作します。基本レートアクセスは、通常、Simple Twistedペアケーブルを介してサブスクライバーに提供されます。
Primary: 30B+D, the D channel operates at 64 Kb. Primary Rate access is normally provided to the subscriber over shielded coaxial cable. Note that the bandwidth for Primary is 2.048 Mbit/s.
プライマリ：30b D、Dチャネルは64 kbで動作します。プライマリレートアクセスは、通常、シールドされた同軸ケーブル上のサブスクライバーに提供されます。プライマリの帯域幅は2.048 Mbit/sであることに注意してください。
Protocols: The B channel is a binary channel and is transparent to the flow of data. Therefore, all of the currently available protocols can operate over a B channel. The most common protocol is X.25.
プロトコル：Bチャネルはバイナリチャネルであり、データの流れに対して透明です。したがって、現在利用可能なすべてのプロトコルは、Bチャネルで動作できます。最も一般的なプロトコルはx.25です。
X.25: The X.25 protocol is a primary protocol for open computer-to-computer communication.
X.25：X.25プロトコルは、オープンコンピューター間通信の主要なプロトコルです。
Passive Bus: It is possible to have an ISDN service enter a building and then have an 8-core cable laid within the building with multiple ISDN junction points, in the same way as one would have multiple telephone points (extensions) for a particular external telephone line.
パッシブバス：ISDNサービスに建物に入ってから、特定の外部外部の複数の電話ポイント（拡張）があるのと同じように、複数のISDNジャンクションポイントのある建物内に8コアケーブルを置くことができます。電話線。
Connection Setup
接続セットアップ
The adapter is responsible for analysing the outgoing X.25 call request and making an ISDN call to a derived ISDN address, establishing a new X.25 level-2 and level-3, and then propagating the X.25 Call Request Packet.
アダプターは、発信X.25コールリクエストを分析し、派生したISDNアドレスにISDNコールを作成し、新しいX.25レベル2とレベル3を確立し、X.25コールリクエストパケットを伝播する責任があります。
Connection Termination
接続終了
The termination phase of the X.25 call is made with a Clear Request and finalised with a Clear Confirmation. The recipient of the Clear Confirm should then close down the ISDN connection.
X.25コールの終了フェーズは、明確なリクエストで行われ、明確な確認で確定します。クリア確認の受信者は、ISDN接続を閉じる必要があります。
The clear down of the ISDN connection should only be made if there are no other Switched Virtual Circuits (SVCs) active on the ISDN connection; note that the usage of multiple simultaneous SVCs is only by virtue of bilateral agreement.
ISDN接続のクリアダウンは、ISDN接続に他の切り替えされた仮想回路（SVC）がアクティブでない場合にのみ行う必要があります。複数の同時SVCの使用は、二国間契約のおかげでのみ行われることに注意してください。
There are a number of ways in which ISDN/X.25 access can be made.
ISDN/X.25アクセスを作成する方法はいくつかあります。
Integrated Adapter
統合されたアダプター
This is normally a PC-based ISDN adapter inside a PC. It is normal in such an environment that the OFTP application has the ability to manipulate the ISDN and X.25 aspects of the session independently and therefore have complete control.
これは通常、PC内のPCベースのISDNアダプターです。OFTPアプリケーションは、セッションのISDNおよびX.25の側面を独立して操作する機能を備えているため、完全に制御できるのは普通です。
Equally important is that the speed of communication between the adapter and the application are at PC BUS speeds. It is therefore more likely that the effective transmission speed will be nearer the 64K limit.
同様に重要なのは、アダプターとアプリケーション間の通信速度がPCバスの速度であることです。したがって、有効な伝送速度が64K制限に近づく可能性が高くなります。
The other benefit of such a direct linkage is that both 64K B channels may be used in parallel and both able to operate at 64Kb.
このような直接的なリンケージのもう1つの利点は、両方の64K Bチャネルが並行して使用され、両方が64kbで動作できることです。
Elementary Terminal Adapter
初期端子アダプター
In this scenario, the computer has an integral X.25 adapter communicating X.21 with a Terminal Adapter that fronts the ISDN network. This allows a host with a X.25 capability to interface to ISDN, normally on a one-to-one basis.
このシナリオでは、コンピューターには、ISDNネットワークの前にある端子アダプターとX.21を通信する積分X.25アダプターがあります。これにより、X.25の機能を備えたホストがISDNにインターフェイスできます。通常、1対1ではいます。
The interface between the Terminal Adapter and the PC will typically only support one 64K B channel. This is obviously an inefficient usage of the ISDN service.
ターミナルアダプターとPCの間のインターフェイスは、通常、1つの64K Bチャネルのみをサポートします。これは明らかにISDNサービスの非効率的な使用です。
Because the linkage between the computer and the Terminal Adapter is only X.25, then some modification/configuration may be needed inside the Terminal Adapter when new users are added.
コンピューターと端子アダプター間のリンケージはx.25のみであるため、新しいユーザーが追加されると、ターミナルアダプター内でいくつかの変更/構成が必要になる場合があります。
X.25 Switch
X.25スイッチ
This solution is normally found inside the larger corporates where an internal X.25 network is operated or where dual X.25 and ISDN is required.
このソリューションは、通常、内部X.25ネットワークが操作されている大企業内や、デュアルX.25およびISDNが必要な大企業内に見られます。
The main benefit of a switch is to support both PSDN and ISDN simultaneously. Also, multiple X.21 lines may be implemented between the X.25 switch and the computer.
スイッチの主な利点は、PSDNとISDNの両方を同時にサポートすることです。また、x.25スイッチとコンピューターの間に複数のx.21行を実装できます。
This solution normally requires more effort to configure and may require obligations to be placed upon how incoming callers specify routing.
このソリューションは通常、設定にもっと努力する必要があり、着信発信者がどのようにルーティングを指定するかについて義務を課す必要がある場合があります。
The adoption of ISDN as an additional subsystem to support OFTP communications has associated implementation problems, which can be categorised as below:
ISDNがTTP通信をサポートするための追加のサブシステムとして採用していることは、以下のように分類できる実装の問題を関連付けています。
X.25/ISDN Addressing Making a Call Receiving a Call Logical Channel Assignment Facilities Negotiation ISDN Call Attributes Homologation Issues Growth Performance
X.25/ISDNアドレス指定コールを受信して呼び出してください
The original OFTP was designed to work over the X.25 networks provided by the PTTs (PSPDNs). The national X.25 networks were interconnected to provide a global X.25 network, and a common addressing scheme was adopted by all. Although there were a few differences in addressing within a national network, the interface to other countries was quite rigid and normalised.
元のOFTPは、PTTS（PSPDNS）が提供するX.25ネットワークで動作するように設計されています。全国X.25ネットワークは相互接続されてグローバルX.25ネットワークを提供し、一般的なアドレス指定スキームがすべての人に採用されました。全国ネットワーク内でのアドレス指定にはいくつかの違いがありましたが、他の国へのインターフェースは非常に厳格で正規化されていました。
PSPDN Numbering
PSPDN番号付け
The addressing scheme adopted in X.25 is a 15-digit number (Network User Address, NUA) where the first three identify the country, the fourth digit identifies the network within the country, and the remainder specify the individual subscriber plus an optional subaddress. In the UK where a full X.25 numbering scheme is adopted, a NUA is, e.g., 234221200170, where 2342 is the DNIC (Data Network Identification Code) and 21200170 is the subscriber number.
X.25で採用されているアドレス指定スキームは、最初の3つが国を識別する15桁の数（ネットワークユーザーアドレス、NUA）であり、4桁目は国内のネットワークを識別し、残りは個々のサブスクライバーとオプションのサブアドレスを指定します。完全なX.25番号付けスキームが採用されている英国では、NUAは234221200170であり、2342はDNIC（データネットワーク識別コード）、21200170はサブスクライバー番号です。
ISDN Numbering
ISDN番号
ISDN is an extension of the normal telephone system; consequently, it adopts (or rather is) the same numbering scheme as the telephone system (PSTN).
ISDNは、通常の電話システムの拡張です。その結果、電話システム（PSTN）と同じ番号付けスキームを採用しています（またはむしろ）。
The Numbering Conflict
番号付けの競合
The PSDN and PSTN numbering schemes are two totally different numbering schemes. There is no relationship between them. It is this conflict that is at the heart of the matter.
PSDNおよびPSTN番号のスキームは、2つのまったく異なる番号付けスキームです。それらの間に関係はありません。問題の中心にあるのはこの対立です。
It is a consequence of PSDN and PSTN being based upon different and unconnected numbering schemes that the key problem arises.
これは、PSDNとPSTNが、重要な問題が発生する異なるおよび接続されていない数字スキームに基づいていることの結果です。
For X.25 to work over ISDN, three main methods of addressing are available:
X.25がISDNを介して作業するには、3つの主要なアドレス指定方法が利用可能です。
Un-mapped: The X.25 called NUA is used as the PSTN number. Thus, an X.25 call to 0733394023 will result in a PSTN call to 0733394023 and the call request that consequently flows will also be to 0733394023.
マップされていない：NUAと呼ばれるX.25は、PSTN番号として使用されます。したがって、0733394023へのx.25コールは、0733394023へのPSTNコールと、その結果、フローも0733394023になるという呼び出し要求が発生します。
Manipulated: The X.25 called NUA is manipulated by the subtraction and/or addition of digits to derive a resultant PSTN number. Thus, 2394023 could be manipulated to derive a PSTN number of 00944733394023, where the prefix 2 is deleted and replaced by 00944733.
操作：NUAと呼ばれるX.25は、結果のPSTN数を導出するために、減算および/または桁の追加によって操作されます。したがって、2394023を操作して、00944733394023のPSTN番号を導出することができます。ここで、プレフィックス2が削除され、00944733に置き換えられます。
Mapped: The X.25 called NUA is used as a look-up into a table of PSTN numbers. Thus, an X.25 call to 234221200170 could be mapped to and result in a PSTN call to 0733394023 and the call request that consequently flows will remain as 234221200170.
マップ：NUAと呼ばれるX.25は、PSTN数の表の検索として使用されます。したがって、234221200170へのx.25コールをマッピングして、0733394023へのPSTNコールと、結果として流れるコールリクエストが234221200170のままになる可能性があります。
Un-mapped Calls
マップされていない呼び出し
Un-mapped calls are where the host-specified X.25 NUA is converted directly to the corresponding ISDN number.
マッピングされていない呼び出しは、ホスト指定のX.25 NUAが対応するISDN番号に直接変換される場所です。
Thus, an X.25 call issued by the host to X.25 NUA 0733394023 will result in an ISDN call to the PSTN number 0733394023. After the call has been established, then HDLC/X.25 protocol setup will be established after which an X.25 call request will be transferred with the NUA 0733394023.
したがって、ホストがX.25 NUA 0733394023に発行したX.25コールは、PSTN番号0733394023へのISDNコールになります。コールが確立された後、HDLC/X.25プロトコルセットアップが確立されます。X.25コールリクエストは、NUA 0733394023で転送されます。
When a PSTN call is made, the number of digits in the called number vary depending upon the location of the called party.
PSTNコールが作成されると、呼び出された数の数字数は、呼び出されたパーティーの場所によって異なります。
When a number is called, it may be local, national, or international.
数字が呼ばれる場合、それはローカル、国内、または国際である可能性があります。
local: 394023 national: 0733 394023 international: 009 44 733 394023
ローカル：394023 National：0733 394023 International：009 44 733 394023
Depending upon where a call originates, the corresponding X.25 NUA in the call request packet will vary dramatically.
コールが発生する場所に応じて、コールリクエストパケットの対応するX.25 NUAは劇的に異なります。
Such variation of X.25 NUA, in particular the changing prefix, can be difficult to be accommodated by X.25 routing logic in many products.
このようなX.25 NUA、特に変化するプレフィックスの変動は、多くの製品のX.25ルーティングロジックによって収容されるのが難しい場合があります。
When an international PSTN call is being made, then it is likely that the PSTN number exceeds 15 digits, which is the maximum length of an X.25 NUA. Therefore, using un-mapped addressing may make some international calls impossible to make.
国際的なPSTNコールが行われている場合、PSTN数は15桁を超える可能性があります。これはX.25 NUAの最大長です。したがって、マッピングされていないアドレス指定を使用すると、いくつかの国際的な呼び出しが不可能になる可能性があります。
Manipulated Calls
操作コール
The X.25 called NUA is manipulated by the subtraction and/or addition of digits to derive a resultant PSTN number.
NUAと呼ばれるX.25は、結果のPSTN数を導出するために、桁の減算および/または添加によって操作されます。
Let us assume that by internal convention we have identified the prefix '2' to indicate an international ISDN call. Thus, an X.25 call request of 244733394023 could be manipulated to derive a PSTN number of 00944733394023, where the prefix '2' is deleted and replaced by '009' (the international prefix).
内部慣習により、国際的なISDNコールを示すようにプレフィックス「2」を特定したと仮定します。したがって、244733394023のx.25コールリクエストを操作して、00944733394023のPSTN番号を導出することができます。ここでは、プレフィックス「2」が削除され、「009」（国際プレフィックス）に置き換えられます。
The X.25 called NUA would typically be left in its un-manipulated state. As individual internal conventions vary, the X.25 called NUA will vary. In the case above, it would be 244733394023, but another installation might have the convention where a prefix of '56' specifies the UK and so the NUA will be 56733394023, where the '56' is deleted and replaced with '00944' to derive the PSTN number.
ヌアと呼ばれるX.25は、通常、操作されていない状態に残されます。個々の内部規則が異なるため、nuaと呼ばれるx.25は変化します。上記の場合は244733394023ですが、別のインストールには、「56」のプレフィックスが英国を指定しているため、NUAは56733394023で、「56」が削除され、「00944」が削除され、「00944」と交換されます。PSTN番号。
Mapped Calls
マップされた呼び出し
The mapped method offers maximum flexibility in that:
マッピングされたメソッドは、その中で最大の柔軟性を提供します。
The PSTN number can exceed 15 digits.
PSTN数は15桁を超える可能性があります。
The X.25 NUA and PSTN number can be totally different.
X.25 NUAおよびPSTN数はまったく異なる場合があります。
The problem with mapped calls is administrative. IBM mainframes can't handle X.25 over ISDN at all, let alone support mapping. For the mainframe solution to work, an external X.25/ISDN router box is required and it is the responsibility of the external box to provide any mapping necessary.
マッピングされた呼び出しの問題は管理者です。IBM MainFramesは、ISDNよりもX.25を処理できず、マッピングをサポートすることはできません。メインフレームソリューションが機能するためには、外部X.25/ISDNルーターボックスが必要であり、必要なマッピングを提供することは外部ボックスの責任です。
This means that any changes or addition of OFTP partners over ISDN will require access to the computer room or special configuration equipment to change the tables inside the external X.25/ISDN router box.
これは、ISDNを介してOFTPパートナーを変更または追加すると、コンピュータールームまたは特別な構成機器にアクセスして、外部X.25/ISDNルーターボックス内のテーブルを変更する必要があることを意味します。
We have seen from the previous section that the called X.25 NUA from an ISDN incoming call may vary considerably. If ISDN/X.25 is confined to a national boundary, then such variation will not be so great as most calls will have matching called X.25 NUA and PSTN numbers.
前のセクションから、ISDN着信からの呼ばれるx.25 nuaが大幅に異なる場合があることがわかりました。ISDN/X.25が国の境界に限定されている場合、そのような変動は、ほとんどの呼び出しがX.25 NUAおよびPSTN数と呼ばれる一致するほど大きくはありません。
X.25 switches and X.25 adapters normally route/accept/reject calls based upon their X.25 called NUA. In particular, routing is made upon the X.25 called NUA subaddress.
X.25スイッチとX.25アダプターは、通常、NUAと呼ばれるX.25に基づいて、呼び出しをルート/受け入れ/拒否します。特に、ルーティングはnua subaddressと呼ばれるx.25にあります。
To derive this subaddress, there are 2 methods:
このサブアドレスを導き出すには、2つの方法があります。
1) the last 'n' digits are analysed.
1) 最後の「n」数字が分析されます。
2) the base X.25 NUA of the line is removed from the called NUA. For example, if the called X.25 NUA is 23422120017010 and the PSDN subscriber NUA is 234221200170, then the subaddress derived from subtraction is 10.
2) ラインのベースx.25 nuaは、呼び出されたnuaから削除されます。たとえば、呼び出されたX.25 NUAが23422120017010、PSDNサブスクライバーNUAが234221200170の場合、減算から派生したサブアドレスは10です。
Obviously, the second method will not work if the incoming NUA varies.
明らかに、着信NUAが変化する場合、2番目の方法は機能しません。
ISDN Features
ISDN機能
ISDN, like X.25, has a core set of features that are then enriched with options. In the original OFTP X.25 specification, it was decided that the Q-bit and D-bit options were not common to all networks or applications; they were therefore positively excluded from the specification.
ISDNは、X.25と同様に、コアセットの機能を備えており、オプションが濃縮されています。元のOFTP X.25仕様では、QビットとDビットのオプションがすべてのネットワークまたはアプリケーションに共通していないことが決定されました。したがって、それらは仕様から積極的に除外されました。
It is proposed that apart from the core ISDN features necessary to establish a call, no other features be used.
コールを確立するために必要なコアISDN機能は別として、他の機能は使用されないことが提案されています。
Subaddressing
サブアドレス
There are two forms of ISDN subaddressing, overdialled and specific.
ISDNサブアドレスの2つの形式があります。
The overdial method allows an ISDN number to be artificially extended. A typical case would be where a private exchange has been installed in a larger company. Assume that the base number is 394023 and the computer is on internal extension 1234, then by specifying an ISDN number of 3940231234, direct access may be made to the internal extension.
オーバーダイアル法により、ISDN番号を人為的に拡張できます。典型的なケースは、大企業にプライベート交換が設置されている場所です。ベース番号が394023であり、コンピューターが内部拡張1234にあると仮定し、3940231234のISDN番号を指定することにより、内部拡張に直接アクセスできるようにすることができます。
The problem with this method is that it extends to called number and may, especially for international access, exceed the ISDN numbering limits between countries.
この方法の問題は、特に国際的なアクセスのために、呼び出された数に拡張され、国間のISDN番号の制限を超える可能性があることです。
The other method of subaddressing is where a discrete subaddress is placed in a specific field in the ISDN call setup.
サブアドレスのもう1つの方法は、ISDNコールセットアップの特定のフィールドに離散サブアドレスが配置される場合です。
The problem with this method, is that it requires the caller to place the subaddress in the ISDN call setup. Not all ISDN implementations will allow this insertion.
この方法の問題は、発信者がISDNコールのセットアップにサブアドレスを配置する必要があることです。すべてのISDN実装により、この挿入が可能になるわけではありません。
In conclusion, subaddressing of any kind should be avoided.
結論として、あらゆる種類のサブアドレスを避ける必要があります。
An X.25 dataline will have associated with it a number of logical channels.
X.25データラインは、多くの論理チャネルに関連付けられています。
The number of channels is a part of the agreement between the PTT and the subscriber. The number of channels subscribed to is important; call failure and similar problems will result if the number of logical channels defined at the two remote ends are different.
チャネルの数は、PTTとサブスクライバーの間の契約の一部です。購読するチャネルの数は重要です。2つのリモートエンドで定義されている論理チャネルの数が異なる場合、コール障害と同様の問題が生じます。
If a DTE makes a call out, then the highest defined logical channel number will be selected. If the remote Data Communications Equipment (DCE) does not have the same number of logical channels defined, then an invalid logical channel is being used from the perspective of the recipient DCE and the call will be rejected.
DTEが呼び出しを行うと、最高の定義された論理チャネル番号が選択されます。リモートデータ通信機器（DCE）に同じ数の論理チャネルが定義されていない場合、受信者DCEの観点から無効な論理チャネルが使用され、コールは拒否されます。
In the PSPDN environment, it is possible to subscribe to negotiation of window size and packet size. Although this negotiation requested by the originator's DTE may be propagated to the remote DTE at the discretion of the originator's DCE, it is a local responsibility between the DTE and DCE pair.
PSPDN環境では、ウィンドウサイズとパケットサイズのネゴシエーションを購読することができます。オリジネーターのDTEによって要求されたこの交渉は、発信者のDCEの裁量でリモートDTEに伝播される可能性がありますが、DTEペアとDCEペアの間の局所責任です。
In the ISDN scenario where it is a DTE-DTE type connection, the window size and packet size may be left at the default value and consequently the values may be omitted from the call request. If no values are specified, then it is vital that both DTEs have configured themselves to the recommended defaults.
DTE-DTEタイプの接続であるISDNシナリオでは、ウィンドウサイズとパケットサイズをデフォルト値に残すことができ、その結果、コールリクエストから値が省略される場合があります。値が指定されていない場合、両方のDTEが推奨デフォルトに自分自身を構成することが重要です。
The symptom of a window size mismatch is a hang situation without any informational error codes.
ウィンドウサイズの不一致の症状は、情報エラーコードのないハング状況です。
The symptoms of a packet size mismatch could work in some scenarios, but would otherwise issue error codes indicating invalid packet sizes.
パケットサイズの不一致の症状は、いくつかのシナリオで機能する可能性がありますが、それ以外の場合は、パケットサイズが無効なことを示すエラーコードを発行します。
Window Size
ウィンドウサイズ
The CCITT X.25 window size has a default value of '2', although subscribers may have other default window sizes, e.g., '7', by virtue of agreement with the PTT.
CCITT X.25ウィンドウサイズのデフォルト値は「2」ですが、サブスクライバーは、PTTとの一致により、他のデフォルトのウィンドウサイズ（ '7'など）を持っている場合があります。
Window size negotiation can be explicitly requested by specifying the requested window size in the Facilities fields in the Call Request packet.
ウィンドウサイズのネゴシエーションは、コールリクエストパケットの機能フィールドに要求されたウィンドウサイズを指定することにより、明示的に要求できます。
Packet Size
パケットサイズ
The CCITT X.25 packet size has a default value of '128' octets, although subscribers may have other default values, e.g., '1024', agreed with the PTT.
CCITT X.25パケットサイズのデフォルト値は「128」オクテットですが、サブスクライバーにはPTTに同意した他のデフォルト値（「1024」など）があります。
The initial setup of an ISDN call is initiated with the transmission of a Q.931 SETUP command. Apart from requesting that a call be established, the SETUP command can optionally carry information about the calling party, the called party, routing information, the type of circuit required (e.g., voice or data), and information about the protocols that are requested to be established.
ISDNコールの最初のセットアップは、Q.931セットアップコマンドの送信で開始されます。コールを確立することを要求することとは別に、セットアップコマンドはオプションで、通話党、呼び出した当事者、ルーティング情報、必要な回路の種類（音声またはデータなど）、および要求されたプロトコルに関する情報をオプションで伝えることができます。確立されます。
Setup Parameters:
セットアップパラメーター：
Bearer capability Information transfer and access attributes
ベアラー機能情報転送およびアクセス属性
Called Party number Destination's network address
パーティー番号宛先のネットワークアドレスと呼ばれます
Called Party subaddress Destination's complete address
パーティーサブアドレスの目的地の完全な住所と呼ばれます
Calling Party number Source's network address
パーティー番号ソースのネットワークアドレスを呼び出します
Low-layer compatibility Layer 1-3 indication
低層互換層1-3表示
High-layer compatibility Layer 4-7 indication
高層互換層4-7表示
Homologation procedures were adopted and vigorously enforced by the PTTs with respect to the quality and conformance of communications equipment connected to the services provided by the PTTs.
ホモログ化手順は、PTTSが提供するサービスに関連する通信機器の品質と適合性に関して、PTTによって採用され、激しく施行されました。
In particular, commercial X.25 products had to be tested and approved before they could be connected to the PTTs' PSPDN. The advantage of this to the subscriber was that there was very little chance of the approved equipment not working.
特に、PTTSのPSPDNに接続する前に、商用X.25製品をテストおよび承認する必要がありました。加入者にとってこれの利点は、承認された機器が機能しない可能性がほとんどなかったことです。
With ISDN, similar approval standards are still enforced. So the subscriber has the same confidence in their ISDN equipment. Wrong, the ISDN equipment itself is approved, but the X.15 protocol that operates on top of ISDN is now outside of the scope of approval services.
ISDNでは、同様の承認基準がまだ実施されています。そのため、サブスクライバーはISDN機器に同じ自信を持っています。間違って、ISDN機器自体が承認されていますが、ISDNの上で動作するX.15プロトコルは現在、承認サービスの範囲外です。
This means that quality of conformance to standards of X.25 over ISDN is subject to the variable quality procedures within the various ISDN equipment manufacturers.
これは、ISDNよりもX.25の標準への適合性の品質が、さまざまなISDN機器メーカー内の可変品質手順の対象となることを意味します。
Although it is likely that commercial reputation will place pressure upon the manufacturers with a programming bug to correct such errors, it still requires the subscribers that do not communicate well to put time and effort into finding the party with the error.
商業的な評判は、そのようなエラーを修正するためにプログラミングバグでメーカーに圧力をかける可能性がありますが、エラーのあるパーティーを見つけるために時間と労力を費やすためにうまくコミュニケーションをとらない加入者が必要です。
So far, tests have shown a number of subtle errors, such as timing problems, that have taken many days to find, prove, and fix.
これまでのところ、テストでは、タイミングの問題など、多くの微妙なエラーが発見、証明、修正に何日もかかりました。
Primary Rate Access
プライマリレートアクセス
If a user decides to plan for growth from the beginning, then the Primary Rate Access has apparent financial benefits. Such apparent savings are usually lost due to the increased cost of user hardware to support such an interface. The BRI for data usage is very common and cards/adapters are low in cost, whereas the PRI cards/adapters are few and far between and consequently highly priced.
ユーザーが最初から成長を計画することを決定した場合、プライマリレートアクセスには明らかな経済的利益があります。このようなインターフェイスをサポートするユーザーハードウェアのコストの増加により、このような明らかな節約は通常失われます。データ使用量のBRIは非常に一般的であり、カード/アダプターのコストは低く、PRIカード/アダプターはほとんどなく、その結果、価格が高くなります。
Basic Rate Access
基本レートアクセス
One way to grow with ISDN is to buy multiple BRI lines, increasing slowly in units of 2 x B channels. The PTTs will be able to provide the same subscriber number for all the lines provided in a similar way to the traditional hunting group associated with PSTN type working.
ISDNで成長する1つの方法は、複数のBRIラインを購入し、2 x Bチャネルの単位でゆっくりと増加することです。PTTSは、PSTNタイプの動作に関連する従来の狩猟グループと同様の方法で提供されるすべてのラインに同じサブスクライバー番号を提供できます。
The obvious benefit of ISDN is speed; unfortunately, the majority of computer systems in use today have a finite amount of computing power available. The attachment of multiple active high-speed communication lines used in file transfer mode could take a significant amount of CPU resource to the detriment of other users on the system.
ISDNの明らかな利点は速度です。残念ながら、現在使用されているコンピューターシステムの大部分には、有限量のコンピューティング能力があります。ファイル転送モードで使用される複数のアクティブな高速通信ラインの添付ファイルは、システム上の他のユーザーの不利益にかなりの量のCPUリソースを必要とする可能性があります。
Connecting an ISDN line with the default 2 B channels to your computer using an X.21 interface is going to give a consistent 64 Kb throughput only if one of the B channels is active at any one time.
X.21インターフェイスを使用して、ISDNラインをデフォルトの2 Bチャンネルとコンピューターに接続すると、Bチャネルの1つがいつでもアクティブである場合にのみ、一貫した64 kbスループットが得られます。
If there are two 64 Kb channels active and contending for a single 64 Kb X.21 interface, then effective throughput will be reduced significantly to just over 50%.
単一の64 kb X.21インターフェイスに対してアクティブで競合する2つの64 kbチャネルがある場合、効果的なスループットは50％を超えて大幅に削減されます。
Mainframe issues:
メインフレームの問題：
Users with a mainframe front-end are also going to find cost an issue. The scanners that scan the communications interfaces are based upon aggregate throughput. A 64 Kb interface takes up a lot of cycles.
メインフレームのフロントエンドを持つユーザーも、コストの問題を発見します。通信インターフェイスをスキャンするスキャナーは、集計スループットに基づいています。64 kbのインターフェイスが多くのサイクルを占めます。
Determining 'DTE' or 'DCE' Characteristics
「DTE」または「DCE」特性を決定します
The following section is an extract from the ISO/IEC 8208 (International Standards Organization, International Electrotechnical Commission) (1990-03-15) standard, which is an ISO extension of the CCITT X.25 standard.
次のセクションは、ISO/IEC 8208（国際標準組織、国際電気技術委員会）（1990-03-15）標準からの抽出物です。これは、CCITT X.25規格のISO拡張です。
The restart procedure can be used to determine whether the DTE acts as a DCE or maintains its role as a DTE with respect to the logical channel selection during Virtual Call establishment and resolution of Virtual Call collision.
再起動手順を使用して、DTEがDCEとして機能するか、仮想コールの確立中の論理チャネル選択と仮想コール衝突の解決に関するDTEとしての役割を維持するかを判断できます。
When prepared to initialise the Packet Layer, the DTE shall initiate the restart procedure (i.e., transmit a RESTART REQUEST packet). The determination is based on the response received from the data exchange equipment (DXE) as outlined below.
パケットレイヤーを初期化する準備ができたら、DTEは再起動手順を開始するものとします（つまり、再起動要求パケットを送信します）。この決定は、以下に概説するように、データ交換機器（DXE）から受け取った応答に基づいています。
a) If the DTE receives a RESTART INDICATION packet with a restarting cause code that is not 'DTE Originated' (i.e., it came from a DCE), then the DTE shall maintain its role as a DTE.
a) DTEが「DTEが発生していない」（つまり、DCEから来た）の再起動原因コードを備えた再起動表示パケットを受信した場合、DTEはDTEとしての役割を維持するものとします。
b) If the DTE receives a RESTART INDICATION packet with a restarting cause code of 'DTE Originated' (i.e., it came from another DTE), then the DTE shall confirm the restart and act as a DCE.
b) DTEが再起動の原因コードの「DTE Originated」（つまり、別のDTEから来た）を使用して再起動表示パケットを受信した場合、DTEは再起動を確認し、DCEとして機能します。
c) If the DTE receives a RESTART INDICATION packet with a restarting cause code of 'DTE Originated' (i.e., it came from another DTE) and it does not have an unconfirmed RESTART REQUEST packet outstanding (i.e., a restart collision), then the DTE shall consider this restart procedure completed but shall take no further action except to transmit another RESTART REQUEST packet after some randomly chosen time delay.
c) DTEが再起動の原因コードの「DTE Originated」（つまり、別のDTEから来た）を備えた再起動の表示パケットを受信し、未確認の再起動リクエストパケットが傑出していない場合（つまり、再起動衝突）、DTEは完了したこの再起動手順を考慮しますが、ランダムに選択された時間遅延の後に別の再起動要求パケットを送信する以外に、それ以上のアクションを取る必要はありません。
d) If the DTE issues a RESTART REQUEST packet that is subsequently confirmed with a RESTART CONFIRMATION packet, then the DTE shall maintain its role as a DTE.
d) DTEが再起動確認パケットで確認された再起動要求パケットを発行する場合、DTEはDTEとしての役割を維持するものとします。
Acknowledgements
謝辞
This document draws extensively on revision 1.4 of the ODETTE File Transfer Specification [OFTP].
このドキュメントは、Odetteファイル転送仕様[OFTP]のリビジョン1.4で広範囲に描かれています。
Many people have contributed to the development of this protocol and their work is hereby acknowledged.
多くの人々がこのプロトコルの開発に貢献しており、彼らの仕事はここに認められています。
Normative References
引用文献
[CMS-Compression] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[CMS-Compression] Gutmann、P。、「暗号化メッセージ構文（CMS）の圧縮データコンテンツタイプ」、RFC 3274、2002年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[ISO-646] International Organisation for Standardisation, ISO Standard 646:1991, "Information technology -- ISO 7-bit coded character set for information interchange", 1991.
[ISO-646]国際標準化機関、ISO標準646：1991、「情報技術 - 情報交換用のISO 7ビットコード化された文字セット」、1991。
[PKCS#1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS＃1] Jonsson、J。and B. Kaliski、 "Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[UTF-8] Yergeau, F., "UTF-8, A Transformation Format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[Zlib] Deutsch、P。およびJ-L。Gailly、「Zlib圧縮データ形式の仕様バージョン3.3」、RFC 1950、1996年5月。
Informative References
参考引用
[ISO-6523] International Organisation for Standardisation, ISO Standard 6523:1984, "Data interchange -- Structures for the identification of organisations", 1984.
[ISO-6523]国際標準化機関、ISO標準6523：1984、「データインターチェンジ - 組織の識別のための構造」、1984。
[OFTP] Organisation for Data Exchange by Tele Transmission in Europe, Odette File Transfer Protocol, Revision 1.4, April 2000.
[OFTP]ヨーロッパのTELE送信によるデータ交換の組織、Odette File Transfer Protocol、Revision 1.4、2000年4月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RIME] Coleridge, Samuel Taylor, "The Rime of the Ancient Mariner", 1817.
[Rime] Coleridge、Samuel Taylor、「The Rime of the Ancient Mariner」、1817。
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X.509] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[RFC3850] Ramsdell、B。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
ODETTE Address
オデットアドレス
The ODETTE File Transfer Protocol is a product of the Technology Committee of Odette International. The Technology Committee can be contacted via the ODETTE Central Office:
Odetteファイル転送プロトコルは、Odette Internationalのテクノロジー委員会の製品です。テクノロジー委員会は、Odette Central Officeから連絡できます。
ODETTE INTERNATIONAL Limited Forbes House Halkin Street London SW1X 7DS United Kingdom
オデットインターナショナルリミテッドフォーブスハウスハルキンストリートロンドンSW1X 7DSイギリス
Phone: +44 (0)171 344 9227
Fax: +44 (0)171 235 7112
EMail: info@odette.org
URL: http://www.odette.org
Author's Address
著者の連絡先
Ieuan Friend Data Interchange Plc Rhys House The Minerva Business Park Lynchwood Peterborough PE2 6FT United Kingdom
Ieuan Friend Data Interchange Plc Rhys House The Minerva Business Park Lynchwood Peterborough PE2 6ft英国
Phone: +44 (0)1733 371 311
EMail: ieuan.friend@dip.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、その中に記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。