Network Working Group I. Friend
Request for Comments: 5024 ODETTE
Obsoletes: 2204 November 2007
Category: Informational
ODETTE File Transfer Protocol 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はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、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）は、電子データ交換（EDI）欧州の自動車業界の要件に対応するために、ヨーロッパでテレ伝送によるデータ交換のための組織（ODETTE）のグループ4を加工して、1986年に定義されました。
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セキュリティワーキンググループによって定義されています。すべてのメンバーは、重要な運用経験と協力し、OFTPおよびEDIソリューションを開発しています。
This memo is a development of version 1.4 of ODETTE-FTP [OFTP] with these changes/additions:
このメモは、これらの変更/追加して[OFTP] ODETTE-FTPのバージョン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
セッション・レベルの暗号化ファイル・レベルの暗号化セキュア認証ファイル圧縮は最大の仮想ファイル記述は、拡張エラー・コードを追加したファイルサイズが9 PB（ペタバイト）に増加許可否定終了応答（NERP）に署名レスポンス（EERP）をエンドツーエンドを締結します
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.必要性は、既存のシステム（既存製品への変更を削減し、容易に実現することができるように）で動作します。
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が提供するネットワークサービスを使用して、ユーザーにファイルサービスを提供するように設計されています。従って、プロトコルは、モデルの7レベル4に及びます。
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モデルの精神に説明します。
2. A protocol for the exchange of information between peer ODETTE-FTP entities.
2.ピアODETTE-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.4に1.5.1で詳述されています。
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:
四つのレコード形式が定義されています。
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.
セッション・レベルの暗号化は、送信から任意の有用な情報を抽出する第三者を防止する、二者間で交換されるすべてのプロトコルコマンドとデータの暗号化によってデータの機密性を提供します。
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]で利用可能なセッション・レベルの認証機能を介して実装し、通信することを望む当事者の身元を証明しています。
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と一体であり、1つは、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での作業から[TLS]排除しませんが、実装は稀です。
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ピアは以前に受動OPENを要求したピアODETTE-FTP、レスポンダへの接続のアクティブOPENを要求するN_CON_RQプリミティブを使用します。 ResponderはN_CON_IND経由で着信接続を通知し、N_CON_RSでそれを受け入れています。依頼者はN_CON_CFの受信時にそのOPEN要求の完了が通知されます。
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プリミティブを経由してネットワークサービスへの送信のためにデータを渡します。レスポンダは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イベントによってCLOSEが通知されます。各ピアがTCP対称に近い手順を完了するために、プリミティブN_DISC_RQを発行しなければならないことが認識されています。
------> 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ネットワーク上ODETTE-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.
実装は非常に簡単です。 [TLS] TCP / IP上でODETTE-FTPを重ねると同じように上の層ODETTE-FTP。 [TLS]接続関係者によって使用されてもよいどちらも、セッションの暗号化と認証の両方を提供します。呼び出しを行う際に、[TLS]クライアントとして通話や行為を受けたとき、当事者は[TLS]サーバーとして動作します。 [TLS]ハンドシェイクが完了すると、応答ODETTE-FTPは、レディメッセージを送信することにより、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で接続をlistenします。サービス名は「オデット-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接続をリッスンします。サービス名は「オデット・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を送信または受信を指定します。
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実体がファイル転送を再起動することができます。エンティティ内のファイル転送を再起動することはできません。
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.
値：Y認証が必要です。 N認証が必要ありません。
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.再試行後には「Y」または「N」の値を有します。 2.原因転送拒否の理由である（1、...、13,99）。再起動が最初のネゴシエーション時に合意されている場合3. 0を再起動し、POS1等しくないにのみ有効です。 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.設定スピーカーは「はい」と「いいえ」とリスナー維持するスピーカーまたは2セットのスピーカーになるために。
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プリミティブを発行することを許可されています。
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_RSによって受信F_CONNECT_CF）の端部に第1のスピーカとなります。
Rules:
ルール：
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（スピーカー=選択）を受け取ります。
- 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（スピーカー=はい）を送信した結果として募集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_CD_INDが発行されたばかりF_EERP_RQ前に受信された場合、これはF_CD_INDの受信によって作成された特殊な条件を残すことになります。すなわち、通常のスピーカーステータスが再び（F_CD_RQ有効に、しかしF_RELEASE_RQが有効ではありません）入力されたF_EERP_RQを発行した後、ちょうどF_CD_INDの受信後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の両方に共通です。唯一の任意の時点で保留中のそのような要求ができるので、あいまいがあってはなりません。
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.
ODETTE-FTPエンティティのアクションにセッションの終了（ESID）コマンドに理由=ノーマルを指定することによって、通常のセッション解放をピア。
| |
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.
ODETTE-FTPエンティティのアクションにセッションの終了（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.プロトコルエラー。セッション開始（SSID）交渉の2失敗。 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
---------------|------|----------------------|------|---------------
| | | |
F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND
*--------------|-> ==|======================|=> --|-------------->
(R=normal) | | | |
F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND
*--------------|-> ==|======================|=> -|-------------->
(R=error value)| | | | (R=error,AO=D)
F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND
<--------------|-* *=|======================|=> --|-------------->
| | | |
F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND
*--------------|-> --|--------->..----------|-> --|-------------->
| | N_DISC_IND | | (R=unsp.,AO=D)
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
述語：P1：F_START_FILE_RSを送信するために決定（+）P2：F_CLOSE_FILE_RS（+）を送信する決定P3：スピーカーになるために決定
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エンティティは、新たなスタートファイルの段階に入ることまたはEndセッション相を介してセッションを終了します。
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ピアは、ネットワークサービスを経由して取引バッファにメッセージを送受信することで通信を行います。各Exchangeバッファは、次のいずれかのコマンドが含まれています。
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セッション開始の準備メッセージSSIDセッション開始SECDセキュリティの変更の方向AUCH認証チャレンジAURP認証レスポンスSFIDスタートSFPAスタートは肯定的な答えSFNA startが負の回答データデータCDTセットのクレジットEFIDエンドが肯定的な回答EFNAエンドファイルEFPAエンドファイル否定のESIDをファイルファイルファイルファイル受信に応じNERP否定エンドの応答RTR準備を終了するには、セッションCD方向変更EERP終了を終了
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
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
The Initiator sends a Security Change Direction (SECD) to which the Responder replies with an Authentication Challenge (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.
Responderは（SSID内）イニシエータの自称アイデンティティにリンクされているパブリック証明書を検索します。 Responderが、適切な証明書を見つけることができない場合、認証は失敗します。レスポンダはイニシエータのためのセッションごとに独自のランダムチャレンジを、暗号化するために、証明書に含まれる公開鍵を使用しています。この暗号化されたチャレンジは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.
データは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.
Responderがリスナーになりながら、セッション開始段階からイニシエータは、スピーカーを指定されています。役割がリスナーに変化方向コマンドを送信するスピーカーによって反転されています。
1. Speaker -- SFID ------------> Listener Start File
<------------ SFPA -- Answer YES
2. Speaker -- SFID ------------> Listener Start File
<------------ SFNA -- Answer NO
Go To 1
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
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.
スタートFileコマンドが中断伝送の再起動を許可する回数が交渉することが含まれます。再起動の施設が利用できない場合は、再起動回数をゼロに設定する必要があります。送信者は、最低レコード数+ 1で開始します。
The destination in a Start File command can be specified as follows.
次のように起動ファイルコマンドの宛先を指定することができます。
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.
レスポンス（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の要求は、放送設備の使用と互換性がありません。このシナリオが発生した場合、中間放送場所は継続し、署名されたEERPの要求を無視するかNERPを返送してもよいです。
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は、それが正常にファイルを受信した後、位置AにEERPを送信する位置BへのファイルのBaを送信します。
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
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への配信のためのデータを含む仮想ファイルを送信します。それは場所Bが応答R6とファイルのBaを認める場合にのみE1に応答R7を送信することができる場所A.清算中心E2に、その応答、R8を送信する前に、クリアリングセンタE1は、位置C（ファイルのBa用）E2からの応答を待たなければなりません。
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は、単一の仮想ファイル内の位置Cに両方のファイルを転送センターE1を、クリアにファイルCa及びCbのを送信します。それはCからの応答R4を受信すると、クリア中心E1は位置Bに位置A及びR6に応答R5を送信します
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を送信するために失敗に起因して作成された場合は、中止の理由は、ファイルを拒否ノードによって送信された拒否理由から取られています。中間ノードが配信不能ファイルを送信しようと停止し、ファイルを削除するためにため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を返送してもよいです。署名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.
EERPsとNERPsの連続流によって引き起こされる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)
Virtual File data flows from the Speaker to the Listener during the Data Transfer phase, which is entered after the Start File phase.
仮想ファイルデータスタートファイルのフェーズの後に入力されたデータ転送フェーズ中にリスナーにスピーカーから流れます。
To avoid congestion at the protocol level, a flow control mechanism is provided via the Set Credit (CDT) command.
プロトコルレベルでの輻輳を回避するために、流量制御機構は、セットクレジット（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
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.
スピーカーは、それがエンドファイル（EFID）コマンドを送信することによって、仮想ファイルの送信を完了したことをリスナーに通知します。リスナーは、正または負のエンドFileコマンドで応答し、スピーカーからの変化方向コマンドを要求するオプションがあります。
1. Speaker -- EFID ------------> Listener End File
<------------ EFPA -- Answer YES
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
3. Speaker -- EFID ------------> Listener End File
<------------ EFNA -- Answer NO
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
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.
プロトコルエラーが発生した場合、セッションは終了し、アプリケーションの動作が中止されます。どちらの場所はIDLE状態に入ります。
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エンティティは、Exchangeバッファを介して通信します。コマンド取引所バッファは、以下に説明されています。仮想ファイルのデータは、セクション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.
ISO 646 IRV 7ビットコード化文字セット[ISO-646]、付録Bによれば、[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.
コマンド取引所バッファはバッファの先頭から始まる単一のコマンドが含まれています。コマンドおよびデータは、Exchangeバッファ内で混合されることはありません。コマンドは圧縮できません。必要でない場合は可変長パラメータが完全に省略されてもよく、関連する長さインジケータフィールドがゼロに設定します。
Components:
コンポーネント：
The first octet of an Exchange Buffer is the Command Identifier and defines the format of the buffer.
交換バッファの最初のオクテットは、コマンド識別子であり、バッファのフォーマットを定義します。
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大文字：ZにA以下の特別なセット：/ - 。 ＆ （ ） スペース。
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） - 使用して符号化長さNオクテットフィールド、[UTF-8]。
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'.
値：進値と文字「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
値：リビジョン2.0のリビジョン1.4「5」のリビジョン1.3 4「」の「1」のリビジョン1.2「2」
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.
It is an application implementation issue to link the expected [X.509] certificate to the SSIDCODE provided.
提供さSSIDCODEに期待[X.509]証明書をリンクするアプリケーションの実装の問題です。
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
値：特別なロジック「N」場所を扱うことができる「Y」場所は特別なロジックを扱うことができません
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.
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.
それがリスナーからスタートファイルの肯定的な回答（SFPA）コマンドを受信したときにスピーカーの利用可能なクレジットはSSIDCREDに初期化されます。これは、エンド・ファイル（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.
SSIDCR Carriage Return Character
SSIDCRキャリッジリターン文字
Value: Character with hex value '0D' or '8D'.
値：進値と文字「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」10桁、および高解像度を与えるカウンタ（0001〜9999）、。
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.
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.
これは、仮想ファイル内容を調べてマッピング機能を実行する場所です。また、受信したファイルの応答（EERP）コマンドを端から端まで作成する場所です。
SFIDORIG Originator String(25)
SFIDORIG創始文字列（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).
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.
ファイルフォーマットU.、ファイルフォーマットの用語では、それは非構造化となり、署名圧縮、および/または暗号化されたら、ファイルが、復号化された解凍、および/または検証されるまで、レコード境界はもはや識別可能ではありません。このシナリオで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
最大：9999999999999
Space in 1K (1024 octet) blocks required at the Originator
location to store the actual Virtual File that is to be
transmitted.
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
最大：9999999999999
Space in 1K (1024 octet) blocks required at the Originator
location to store the original before it was signed,
compressed, and/or encrypted.
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
最大：99999999999999999
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オクテット）ブロックは、 '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.
ファイルは、署名された圧縮され、および/または暗号化された後、ファイルフォーマットの用語では、フォーマット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.)
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.
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.)
SFIDENV File enveloping format Numeric(1)
SFIDENVファイル包む形式数値（1）
Value: '0' No envelope '1' File is enveloped using [CMS]
値：「0」ノー封筒「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」ERP「で」署名しなければならないファイルの確認応答で返されたERPを署名してはいけません
Requests whether the EERP returned for the file must be
signed.
SFIDDESCL Virtual File Description length Numeric(3)
SFIDDESCL仮想ファイル説明length数値（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.
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.
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」対掌コマンド識別子。
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再試行インジケータキャラクター
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).
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.
無効なファイル名エラーコードは、実際のファイルへの仮想ファイルのマッピングに問題の結果です。このような問題は、常にすぐに解決することはできません。したがって、リトライ= 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' DATAコマンド識別子。
DATABUF Data Exchange Buffer payload Binary(n)
DATABUFデータ交換バッファペイロードバイナリ（N）
Variable-length buffer containing the data payload. The
Data Exchange Buffer is described in Section 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
最大：99999999999999999
For SSIDFMT 'F' or 'V', the exact record count.
For SSIDFMT 'U' or 'T', zeros.
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ユニット（17）の数値をカウント
Maximum: 99999999999999999
最大：99999999999999999
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.
値：「N」変化方向が要求されていません。 「Y」の変更方向が要求されました。
This parameter allows the Listener to request a Change
Direction (CD) command from the Speaker.
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' CHEMICALコマンド識別子。
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回答理由テキスト[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).
'02' Protocol violation
「02」プロトコル違反
An Exchange Buffer contains an invalid command for
the current state of the receiver.
'03' User code not known
「03」ユーザーコードがないことが知ら
A Start Session (SSID) command contains an unknown or
invalid Identification Code.
'04' Invalid password
「04」無効なパスワード
A Start Session (SSID) command contained an invalid
password.
'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のExchangeバッファサイズエラー
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理由テキスト[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'.
値：進値と文字「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
EERPCMDコマンドコード文字
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」10桁、および高解像度を与えるカウンタ（0001〜9999）、。
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.
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創始文字列（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.
最初に送信されたようEERPがまったく同じファイルを認めていることを確認するためにEERPHSHを検証するために、アプリケーションの実装の問題です。
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署名バイナリ（N）
Contains the [CMS] enveloped signature of the EERP.
[CMS]はEERPの署名を包ま含まれています。
Signature = Sign{EERPDSN EERPDATE EERPTIME EERPDEST EERPORIG EERPHSH}
署名=サイン{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データです。
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
NERPCMDコマンドコード文字
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」10桁、および高解像度を与えるカウンタ（0001〜9999）、。
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創始文字列（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ストリングのNERPCREAクリエイター（25）
Format: See Identification Code (Section 5.4)
フォーマット：識別コードを参照してください（5.4節）
It is the location that created the NERP.
それは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)
値「03」ESIDが「04」ESIDは、理由コード「04」（無効なパスワード）を受信（ユーザーコード知られていない）理由コードで「03」を受けた「09」ESIDは、理由コード「99」（詳細不明な理由）'11で受信しました'SFNA（RETRY = N）が理由コードで受信 '01'（無効なファイル名） '12' SFNA（RETRY = N）は、理由コードと受信 '02'（無効な宛先） '13' SFNA（RETRY = N）を、受信しました理由コード '03'（無効原点） '14' SFNA（RETRY = N）は、理由コードと受信 '04'（無効なストレージ・レコード形式） '15' SFNA（RETRY = N）は、理由コード '05' で受信された（最大レコード長さはサポートされません） '16' SFNA（RETRY = N）は、理由コード '06' で受信（ファイルサイズが大きすぎる） '20' SFNA（RETRY = N）は、理由コード '10'（無効なレコード数） '21' で受信SFNA（RETRY = N）は、理由コード '11'（無効バイトカウント） '22' SFNA理由コード '12'（アクセス方法故障）と受信（= Nリトライ）で受信しました
'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.
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.
フィールドNERPHSHのオクテットの長さ。
A binary value of 0 indicates that no hash is present. This is always the case if the NERP is not signed.
0のバイナリ値には、ハッシュが存在しないことを示しています。 NERPが署名されていない場合、これは常にそうです。
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署名長バイナリ（2）
0 indicates that this NERP has not been signed.
0は、このNERPが署名されていないことを示しています。
Any other value indicates the length of NERPSIG in octets and indicates that this NERP has been signed.
他の値は、オクテットでNERPSIGの長さを示し、このNERPが署名されたことを示します。
NERPSIG NERP Signature Binary(n)
NERPSIG NERP署名バイナリ（N）
Contains the [CMS] enveloped signature of the NERP.
[CMS]はNERPの署名を包ま含まれています。
Signature = Sign{NERPDSN NERPDATE NERPTIME NERPDEST NERPORIG NERPCREA NERPHSH}
署名=サイン{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データです。
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
AUCHCMDコマンドコード文字
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.
長さは、ネットワークバイト順を使用して符号なし2進数として表現されます。
AUCHCHAL Challenge Binary(n)
AUCHCHALチャレンジバイナリ（N）
A [CMS] encrypted 20-byte random number uniquely generated
each time an AUCH is sent.
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.
応答がチャレンジと一致することを確認するために、受信したAURPを検証するために、アプリケーションの実装の問題です。この検証は、当事者が正しく認証されることを確実にするために非常に重要です。
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
SIOOID ODETTE識別子キャラクター
Value: 'O' Indicates ODETTE assigned Organisation Identifier. Other values may be used for non-ODETTE codes.
値：「O」をODETTE割り当てられた組織識別子を示します。他の値は、非ODETTEコードのために使用することができます。
SIOICD International Code Designator String(4)
SIOICD国際コード指定文字列（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.
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.レコード長の指標; 2.ログイン3.圧縮4.暗号化（V形式のファイルは6.5節を参照してください）
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のは - 暗号化されたデータCompressedDataを示します - 圧縮データのSignedDataを示します - 署名したコンテンツデータを示している - 非構造化データを示します
For signed or encrypted data, the encapsulated content type (eContentType field) is id-data.
署名または暗号化されたデータのために、カプセル化されたコンテンツタイプ（のeContentTypeフィールド）がIDデータです。
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）に従って包まれます。一般的に、これはデフォルトで[ZLIB]圧縮アルゴリズムを使用しています[CMS-圧縮]データ型を使用して、[CMS]パッケージのようになります。
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オクテットサブレコードヘッダが定義します：
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つのExchangeバッファ間で分割されることはありません。現在のExchangeバッファに残っているスペースは、次の「完全」サブレコードを格納するのに不十分である場合は、次のいずれかを使用する必要があります。
1. Truncate the Exchange Buffer, and put the complete subrecord (preceded by its header octet) in a new Exchange Buffer.
1.交換バッファを切り捨てて、新しいExchange緩衝液（そのヘッダオクテットが先行する）完全なサブレコードを置きます。
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.最初の新しいサブレコードとの交流緩衝液の残りを充填し、第二と新しいExchange出発緩衝液、二つにサブレコードを分割しました。
A record of length zero may appear anywhere in the Exchange Buffer.
長さゼロの記録では、Exchangeバッファのどこに表示されることがあります。
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ストリームを利用するには、ストリーム伝送バッファ（STB）は、それらがTCP転送サービスに渡される前に、すべてのコマンドおよびデータ交換バッファの先頭にストリーム伝送ヘッダー（STH）を追加することによって作成されます。これは、受信ODETTE-FTPは、元のExchangeバッファを回復することができます。
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交流バッファ
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（10進数）
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は、このような変化方向（CD）コマンドのような1オクテット交換バッファに続く4オクテットのヘッダからなる5つのオクテットです。
The maximum Exchange Buffer length that can be negotiated is 99999 octets (Section 5.3.2) giving an STB length of 100003.
ネゴシエートすることができる最大のExchangeバッファ長は、100003のSTBの長さを与える99999個のオクテット（5.3.2項）です。
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.
A_WF_CONRS Responder Waiting for F_CONNECT_RS
F_CONNECT_RSを待っているレスポンダA_WF_CONRS
The Responder has received the Initiator's Start Session
(SSID) and is waiting for a response (F_CONNECT_RS) from
its User Monitor.
CDSTWFCD CD_RQ stored in WF_CD state
CDSTWFCD CD_RQはWF_CD状態に保存されています
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.
CLIP Close Input Pending
保留CLIP閉じる入力
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.
CLOP Close Out Pending
CLOPクローズアウト保留
The Speaker has sent an End File (EFID) command and is
waiting for an End File Answer (EFPA or EFNA).
ERSTWFCD End to End Response stored in WF_CD state
ERSTWFCDエンドWF_CD状態で保存されたレスポンスを終了します
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.
IDLE Connection IDLE
IDLE接続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.
IDLESP Idle Speaker
IDLESPアイドルスピーカー
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.
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.
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.
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.
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.
OPI Open Input (Data Transfer Phase)
OPIオープン入力（データ転送フェーズ）
The Listener is waiting for the Speaker to send a Data
Exchange Buffer.
OPIP Open Input Pending
OPIPミテイ保留
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.
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.
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).
OPOWFC Open Out Wait for Credit
OPOWFCオープン・アウトは、クレジットのを待ちます
The Speaker is waiting for a Set Credit (CDT) command
before sending further Data Exchange buffers.
RTRP Ready to Receive (RTR) Pending
RTRP受信する準備（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.
SFSTWFCD Start File Request stored in WF_CD state.
WF_CD状態で保存されたファイル要求を開始しますSFSTWFCD。
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 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.
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.
WF_NDISC Wait for N_DISC_IND
N_DISC_INDを待ちWF_NDISC
ODETTE-FTP has sent an End Session (ESID) command and is
waiting for a Disconnection indication (N_DISC_IND) from
the Network Service.
WF_SECD Wait for Security Change Direction
セキュリティの変更の方向を待ちWF_SECD
The Speaker is expecting a Security Change Direction
(SECD) from the Listener.
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.
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.
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
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)
ピアODETTE-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 CDT SSRM NERP SECD AUCH AURP
Internal Input Events
内部入力イベント
TIME-OUT - Internal ODETTE-FTP timer expires.
TIME-OUT - 内部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名を付しています。彼らの値を調べたが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
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)
ピアODETTE-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 CDT 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名を付しています。これらの値を調べ、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名を付しています。彼らの値を調べ、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名を付しています。彼らの値を調べたが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：（使用可能リソースがない）OR（C.Cap-INIT =レスポンダ）OR（C.Capモード=送信者専用で、I.F_CONNECT_RQ.Mode =レシーバーのみ）OR（C.Capモード= Receiver-のみとI.F_CONNECT_RQ.Mode =送信者のみ）
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 =イニシエータ
Predicate P4: Mode in SSID incompatible with C.Cap-mode
述語P4：C.Capモードと互換性がないSSIDでモード
Predicate P5: V.Caller = Yes
述語P5：V.Caller =はい
Predicate P6: (V.Caller = Yes) AND (AURP.Signature verifies with V.Challenge)
述語P6：（V.Caller =はい）AND（AURP.SignatureがV.Challengeで検証し）
Predicate P7: (V.Caller = No) AND (AURP.Signature verifies with V.Challenge)
述語P7：（V.Caller =いいえ）AND（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 =はい
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
Action 2: Start inactivity timer
アクション2：非アクティブタイマーを起動します
Action 3: Set parameters in O.SSID = from local variables
アクション3：ローカル変数からO.SSID =で設定されたパラメータ
Action 4: Stop timer
アクション4：停止時間
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サイズ、V.Window、V.Authentication = 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
F_REL_RQ（OK） - F_RELEASE_RQ理由=通常F_REL_RQ（ERR） - F_RELEASE_RQ理由=エラー
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)
述語P1：（I.F_START_FILE_RQ.Restart-POS> 0 AND V.Restart =いいえ）OR（V.Mode =受信のみ）
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.
Predicate P3: V.Credit_S - 1 = 0
述語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
アクション1：非アクティブタイマーを停止します
Action 2: Start inactivity timer
アクション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
アクション7：I.SFPAからF_START_FILE_CF（+）を構築します
Action 8: Build F_START_FILE_CF(-) from I.SFNA
アクション8：F_START_FILE_CFを構築する（ - ）I.SFNAから
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設定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
アクション13：V.Credit_S = V.Credit_S - 1
Action 14: Activate CRC-calculus function. Wrap Exchange buffer in special logic
アクション14：CRC-計算機能をアクティブにします。特別なロジックでラップ為替バッファ
Action 15: Build a NERP from F_NERP_RQ
アクション15：F_NERP_RQからNERPを構築
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：この状態でローカル実装の問題でありながら、この「要求/イベント」を受け入れるかどうか。 ODETTE状態テーブルは、このイベントが、この状態では起こり得ないという仮定に基づいており、ユーザー・エラー（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リクエスト=はい）
Predicate P2: No special logic is in use
述語P2：特別なロジックが使用されていません
Action 1: Stop inactivity timer
アクション1：非アクティブタイマーを停止します
Action 2: Start inactivity timer
アクション2：非アクティブタイマーを起動します
Action 3: O.F_CLOSE_FILE_CF(+).Speaker = No
アクション3：O.F_CLOSE_FILE_CF（+）スピーカー=いいえ。
Action 4: O.F_CLOSE_FILE_CF(+).Speaker = Yes
アクション4：O.F_CLOSE_FILE_CF（+）スピーカー=はい。
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：F_CLOSE_FILE_CF構築する - をEFNAから（）
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.
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)
述語P1：（I.SFID.Restart-POS> 0 AND V.Restart =いいえ）OR（V.Mode =送信者のみ）
Note: Invalid Start File command.
注意：無効なスタートFileコマンドを。
Predicate P2: Positive Response
述語P2：肯定的な反応
Predicate P3: I.F_CLOSE_FILE_RS(+).Speaker = Yes
述語P3：I.F_CLOSE_FILE_RS（+）スピーカー=はい。
Predicate P4: I.F_START_FILE_RS(+).Restart-pos > V.Restart
述語P4：。I.F_START_FILE_RS（+）を再起動し-POS> V.Restart
Predicate P5: Special logic is used
述語P5：特別なロジックが使用されています
Predicate P6: V.Credit_L - 1 < 0
述語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
述語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
アクション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:
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:
スタートファイル（SFID）コマンドを送信し、オープン・アウト保留（OPOP）状態に入っているODETTE-FTPエンティティを考えてみましょう。肯定的な答え（SFPA）を受信すると、その応答は、遷移「K」が適用されるべきであり、以下のように解釈されることを示しており、スピーカー状態テーブル1に記載されています。
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は、受信スタート肯定的な回答をファイル（SFPA）コマンドで再開位置をチェックします。それが無効である場合、それはそのピアとそのユーザーモニタにABORT指示（F_ABORT_IND）にセッションの終了（ESID）コマンドを送信することにより、セッションを中止します。再開位置が有効であれば、スタートファイルの確認（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
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.
トリプルDESは、セキュリティを強化するための暗号ブロック連鎖（CBC）モードを使用し、3つの異なる64ビットキーで暗号解読暗号化（EDE）プロセスを使用しています。
RSA padding is as defined in [PKCS#1].
[PKCS＃1]で定義されるようにRSAのパディングがあります。
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・インターナショナルによって維持、およびwww.odette.orgで彼らのウェブサイト上で公開されています。
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.
セキュリティ対策がODETTE-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）をチェックする能力をリードしていません
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節を参照してください。
Appendix A. Virtual File Mapping Example
付録A.仮想ファイルマッピングの例
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.
コールリッジ[RIME]によって「古代マリナーのライム」からこの抽出物中の各行は、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?
"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."
「花婿のドアが大きく開いている、と私は近親者午前、ゲストが満たされている、ごちそうが設定されている：May'stは陽気の喧騒を聞きます。」
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.
彼はquothが「船がありました」、彼のスキニー手で彼を保持しています。 「ホールドオフ！私をunhand、グレーひげのルーンを！」 Eftsoons彼の手は、彼をdropt。
He holds him with his glittering eye-- The Wedding-Guest stood still, And listens like a three years; child: The Mariner hath his will.
彼は結婚式のゲストはまだ立っeye--彼のきらびやかで彼を保持しており、3年間のようにリッスン;子供：マリナーは、彼の意志をかれら。
The Wedding-Guest sat on a stone: He cannot chuse but hear; And thus spake on that ancient man, The bright-eyed Mariner.
結婚式のゲストには、石の上に座って：彼はchuseが、聞くことはできません。したがって、その古代人、明るい目マリナーに語ら。
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.
取引バッファは、以下の上から造られました。 2行は以下の16進数の値を得ながら、それぞれの一番上の行は、ASCIIコードを表します。
Note that:
ご了承ください：
. The "D" at the beginning of each Exchange Buffer is the command code.
。各Exchangeバッファの先頭に「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
D？それは...、古代マリナーであり、彼は4347267266266666672467666720046626627767767626662662767662002472 4F9409301E01E395E40D129E52CDA1E4085034F005480FE50F6048255EDA2290では、「... 3の1 stoppeth
t?hy long grey beard and glittering eye,..Now wherefore stopp'st 7367266662676726667626662666776766626762004672766766676277677277 4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
トン？HY長い灰色のひげと目をきらびやか..今それゆえstopp'st 7367266662676726667626662666776766626762004672766766676277677277 4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
?thou me?...."The Bridegroom's doors are opened wide,..And I am 2376672663000025662476666766627266677267626766662766620046624266 0F48F50D5FDADA248502294572FFD7304FF2301250F05E5407945CDA1E40901D
？.. .... "花婿のドアが大きく開いていますか？私は汝そして私は2376672663000025662476666766627266677267626766662766620046624266 0F48F50D5FDADA248502294572FFD7304FF2301250F05E5407945CDA1E40901D午前
?next of kin;..The guests are met, the feast is set:..May'st he 2366772662666300566267677726762667227662666772672767300467277266 0FE5840F60B9EBDA485075534301250D54C04850651340930354ADAD19734085
？近親者、ゲストが満たされている..ごちそうが設定されている.. May'st彼2366772662666300566267677726762667227662666772672767300467277266 0FE5840F60B9EBDA485075534301250D54C04850651340930354ADAD19734085
a?r the merry din."....He holds him with his skinny hand,.."Ther 6372766266777266622000046266667266627676266727666672666620025667 1F204850D5229049EE2DADA8508FC43089D07948089303B9EE9081E4CDA24852
？陽気喧騒rを。「....彼はスキニーの手で彼を保持し、..」THER 6372766266777266622000046266667266627676266727666672666620025667 1F204850D5229049EE2DADA8508FC43089D07948089303B9EE9081E4CDA24852
e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon 6327672627667222776762662002466626662276666626622676726667626666 5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE
E？船、「彼quothが...」ホールドオフでした！私をunhand、グレーひげルーン6327672627667222776762662002466626662276666626622676726667626666 5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE
!?"..Eftsoons his hand dropt he.....He holds him with his glitte 2320046776667266726666267677266200004626666726662767626672666776 1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445
！？」.. Eftsoons彼の手のdroptは彼が.....彼はglitteで彼を保持している2320046776667266726666267677266200004626666726662767626672666776 1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445
r?ing eye--..The Wedding-Guest stood still,..And listens like a 7366626762200566256666662476772776662776662004662667766726666262 2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010
R目をINGの - ？..結婚式ゲストは...、まだ立って、7366626762200566256666662476772776662776662004662667766726666262 2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010のようにリッスン
t?hree years; child:..The Mariner hath his will.....The Wedding-7367662766773266666300566246766672667626672766620000566256666662 4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
3年;子供..マリナーは、彼の意志をかれら.....ウェディング-7367662766773266666300566246766672667626672766620000566256666662 4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
G?uest sat on a stone:..He cannot chuse but hear;..And thus spak 4376772767266262776663004626666672667762677266673004662767727766 7F553403140FE01034FE5ADA85031EEF4038535025408512BDA1E4048530301B
？Gはuest石の上に座っていた..彼はchuseことはできませんが、聞いてください。...そしてこうして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
E？その古代の男..上の明るい目マリナー..... 6326627667266666672666200566267666726766246766672000056627667276の5F0FE0481401E395E40D1ECDA4850229784D59540D129E52EDADA48503890071のWA船？陽気に我々は7326666766227662667667726666766200467766726662762676700466672766 3F03855254C048508122F5203C51254CDAD5229C90494075042F0DA25CF70485をdrop..Belowでした..港をクリアし、応援
.kirk, below the hill,..Below the light-house top... 2B667622666672766266662004666727662666672667762767200 03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
.kirk、丘の下に、...ライトハウストップの下に... 2B667622666672766266662004666727662666672667762767200 03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
Appendix B. ISO 646 Character Subset
付録B. ISO 646文字サブセット
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
Appendix C. X.25 Specific Information
付録C. X.25固有の情報
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 7にレベル4を覆い、元々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 |
+------------------------------+
C.1. X.25 Addressing Restrictions
C.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.
X.25コールがPSDN上に形成されている場合、宛先のネットワークユーザアドレス（NUA）はPTTルート呼を得るために指定されなければなりません。配置の呼び出しは、ユーザーの構内に応じ終端装置に向けられています。
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.
ユーザデータのための標準はありません。また、ODETTEエンティティはN_CONNECT_RQに置かれるべきユーザデータを得ることができるからF_CONNECT_RQに情報はありません。そのため、ユーザーデータを使用してはなりません。
C.2. Special Logic
C.2。特別なロジック
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（ネットワークサービスデータユニット）にデータを移動し、ネットワークに制御を渡す前に、特別なロジックは、データ交換バッファに（Y（はい）またはN（いいえ））を適用しなければならないかどうかを指定しますサービス。
C.2.1. When Special Logic Is Not To Be Used
C.2.1。特別なロジックを使用しない場合
This logic is not applied to SSRM and SSID commands.
このロジックは、SSRMとSSIDのコマンドに適用されていません。
C.2.2. The Need for "Enveloping" Exchange Buffers
C.2.2。 「包み込みの」Exchangeバッファの必要性
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（はい）を指定すると、このロジックがアクティブになります。
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 |
+------------------------------+
C.2.3. Responsibilities of Special Logic
C.2.3。特別なロジックの責任
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バッファをラップします。交換バッファを受信し、特別な論理がアクティブである場合、層4はより高い層へのExchangeバッファを渡す前に、等の同期及び描写文字のようなものを削除します。
C.2.4. Extended Exchange Buffer Format
C.2.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で初期化され、チェックサム変数は大手STXは、チェックサム計算によって保護されていないが、明示的に受信者の最後で比較する文字によって保護されて0に設定されています。緩衝液交換は、文字ずつ処理されます。各文字がExchangeバッファから除去されると、それはチェックサム計算に通され、その後、前エンベロープ内への挿入に、それは、1つのまたは2つの文字が挿入されているになりますシフトアウト透明ロジック、通されます。取引バッファの内容が完全に処理された場合は、その後、チェックサム変数は、封筒に挿入するためにシフトアウト透明ロジックに転送チェックサムの計算と得られる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' を差し引いた後の）シフトアウト次の文字がされるが、後続のすべての文字は、シフトアウトロジックを使用して処理されます。チェックサム文字自体はチェックサムアルゴリズムの設計のおかげで、チェックサム計算によって処理されます。
C.2.5. Error recovery
C.2.5。エラー回復
C.2.5.1. Mechanism
C.2.5.1。機構
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つのタイマーの定義とC / R続いてASCII NAK（否定応答）文字を使用することによって実現されます。 <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>を受信すると、セッション・パートナーは、その全体が最後のブロックを再送信すべきです。
C.2.5.2. Timers
C.2.5.2。タイマー
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):
TIMER T1 - 応答時間OUT（DEFAULT = 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 - OUT INTER CHARACTER時間（デフォルト= 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のエンティティのために、それは、Exchangeのバッファを終了していない受信ブロックの後に開始されます。
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):
TIMER T3 - データキャリア一時的な損失（DEFAULT = 1 SECOND）：
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.
有効期限 - セッションを切断します。
C.2.5.3. Types of Error
C.2.5.3。エラーの種類
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は、同期外れ受信され、したがってブロックは、受信機によって見られません。 <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
緩衝液交換のResent
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
(2) CORRUPT TERMINATION (C/R)
（2）CORRUPT TERMINATION（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
緩衝液交換のResent
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
(3) BAD DATA (4) BAD BCS (BLOCK CHECK SUM)
（3）不正なデータ（4）BAD BCS（ブロックチェックSUM）
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>.
このような状況では、受信機は、エラーが不正なデータか悪いBCSであるかどうかを見分けることができません。いずれの場合においても、応答は、Exchangeバッファを破棄し、<NAK> <C / R>を送信することです。
(A) (B)
（A）（B）
Bad Data/BCS
不良データ/ BCS
+-------------------------+
| S | B | | B | C | Bad data
-----| T | S | "%! | C | / |-----> detected
| X | N | | S | R |
+-------------------------+
+-------+
| N | C |
<-----| A | / |----- Discard Block
| K | R |
+-------+
Exchange Buffer Resent
緩衝液交換のResent
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Data OK
| X | N | | S | R |
+-------------------------+
(5) BAD BLOCK SEQUENCE NUMBER (BSN)
（5）BADブロックシーケンス番号（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.
円形の連番（0までと9を含む）が送信された交換バッファに割り当てられています。これは、重複したのか、アウトオブシーケンス交換バッファの検出を助けることです。重複ブロックが検出されると、問題の取引バッファが破棄されます。シーケンスブロックのうちが検出されると、これはプロトコル違反をもたらすはずです。
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
T1がタイムアウト
Exchange Buffer Resent
緩衝液交換のResent
+-------------------------+
| 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のクレジット値は、半二重フリップフロップを保証するために使用する必要があります。
C.2.6. Sequence of Events for Special Logic Processing
C.2.6。特別なロジック処理のためのイベントのシーケンス
The following functions will be executed in sequence:
以下の機能は、順番に実行されます。
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.
フォーマット：/ 1 POS数値。
Calculation is done as specified in the ISO DIS 8073 TRANSPORT LAYER document.
ISO DIS 8073トランスポート層の文書で指定された計算が行われます。
Format: binary/2 pos.
フォーマット：バイナリ/ 2 POS。
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とキャリッジリターン文字を除いて）、データストリームに延び交換バッファのすべての文字を任意の制御文字の出現を避けるために挿入されます（SO）と制御文字に進値「20」を追加します。
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-ロジックを追加した後、データバッファはデータ交換バッファサイズを超えてもよいです。
C.2.7. Checksum Creation Algorithm
C.2.7。チェックサムの作成アルゴリズム
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
チェックサム・パラメータの第2オクテットのチェックサムパラメータY値の最初のオクテットの完全NSDU X値のアルゴリズムLの長さが使用されるC0、C1変数
ARITHMETIC CONVENTIONS:
ARITHMETICの表記：
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））の変数の任意の値がマイナスゼロを有する場合（すなわち、255）は、それがあった場合にかかわらずプラスゼロとみなすた1の補数演算を255算術Bモジュロ（即ち、0）。
ALGORITHM FOR GENERATING CHECKSUM PARAMETERS:
生成CHECKSUMパラメータのアルゴリズム：
. Set up the complete NSDU with the value of the checksum parameter field set to zero.
。完全NSDUはゼロに設定されたチェックサムパラメータフィールドの値に設定します。
. Initialise C0 and C1 to zero.
。ゼロにC0及びC1を初期化します。
. Process each octet sequentially from i=1 to L by
。 Lのi = 1からプロセスの各オクテットを順次によって
a) adding the value of the octet to C0, then
b) adding the value of C0 to 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.
。それぞれ、チェックサム・バイト1及び2の値X及びYを配置します。
C.2.8. Algorithm for checking checksum parameters
C.2.8。チェックサム・パラメータをチェックするためのアルゴリズム
. Initialise parameters C0 and C1 to zero.
。ゼロにパラメータC0及びC1を初期化します。
. Process each octet of NSDU sequentially from i=1 to L by
。 Lのi = 1からプロセスNSDU順次の各オクテットによって
a) adding the value of the octet to C0, then
b) adding the value of C0 to 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とC1が値ゼロを持っていない、場合は、チェックサム式が満たされていなくて。
Note that the nature of the algorithm is such that it is not necessary to compare explicitly the stored checksum bytes.
アルゴリズムの性質は、明示的に保存されているチェックサムのバイトを比較する必要はないようなものであることに注意してください。
C.2.9. Shift-out Processing
C.2.9。シフトアウト処理
(Transparency for all control characters)
（すべての制御文字のための透明性）
TRANSMIT LOGIC (values SO: X'0E' or X'8E')
（SO値：X'0E 'またはX'8E'）LOGICを送信します
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')
IF（（バッファ（I）＆X'7F '）<X'20'）
THEN output (SO) output (buffer(i) + X'20')
THEN出力（SO）出力（バッファ（I）+ X'20' ）
ELSE output (buffer(i))
ELSE出力（バッファ（I））
NEXT:
次：
RECEIVE LOGIC (values SO: X'0E' or X'8E')
（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
ドロップ= Trueの場合
THEN output (buffer(i) - X'20') drop = false
THEN出力（バッファ（I） - X'20' ）ドロップ=偽
ELSE IF buffer(i) = (X'0D' or X'8D') THEN Stop ELSE IF buffer(i) = SO THEN drop = true ELSE output (buffer(i))
緩衝液（I）=（X'0D 'またはX'8Dが'）THEN = = SO THENドロップバッファー（I）IF ELSE真ELSE出力を停止ELSE IF（バッファー（I））
NEXT:
次：
C.3. PAD Parameter Profile
C.3。 PADのパラメータプロファイル
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）非同期エンティティ前 - >モデム - > PAD - >（ODETTE-FTP）ネイティブX.25リンクを確立することができ、目標PADパラメータが正しい通信が確立されるように設定されなければなりません。強く、PADパラメータはX.25エンティティによって設定されていることをお勧めします。 CCITT勧告X.3、X.28、およびX.29 PADとパケットモードデータ端末装置（DTE）との間の制御情報及びユーザデータの交換のためのPADパラメータおよび手順を定義します。
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
15編集0なし編集16文字の削除なしフロー制御はC / R 0なし改行14改行パディング0なし改行パディング後13改行挿入を使用しないPAD 0のわずか12フロー制御を読まない - 11端末データレートを折り畳みなしライン折りたたみ0 10ライン127削除17ライン24 <CTRL> X 18ライン表示18 <CTRL> R 19の編集パッドサービス信号0マスクなしサービス信号20エコーを削除します0：エコーマスク21パリティトリートメント0パリティなしチェック22ページいいえページウェイト0を待っていません
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.
1パラメータ - - 12が国際必須と入手可能であるCCITT（1984）を参照。 - パラメータ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.)
彼らはパラメータ（ - 22 13）の一部をサポートしていないためODETTE-FTP「特別なロジック」パラメータは、いくつかのパッドの上にできない場合があります。 （PADは、デフォルトではパリティチェック（21）をサポートしている場合、ODETTE、FTP特別なロジックは不可能であろう。）
It is a user responsibility to ensure special logic consistency when making the PAD subscription.
PADのサブスクリプションを作成する際に特別なロジックの整合性を確保するためのユーザーの責任です。
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モニタ機能。 - PADのサービスが実装されています。 - パケットモードDTEエンティティODETTE-FTPモニタ機能。
Appendix D. OFTP X.25 over ISDN Recommendation
ISDN勧告を超える付録D. OFTPのX.25
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グループ4（1）の勧告を記述する。
(1) ODETTE Group 4 is responsible for the specification of Telecommunications standards and recommendations for use within the Automotive Industry.
（1）ODETTEグループ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 File Transfer Protocol）は、EDIおよび非EDIデータの両方の転送のために設計さODETTEグループ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.
最初のセクションは、一般的な議論が続いている詳細なODETTE推奨を提供します。あなたは専門用語に精通していない場合、最初の後続のセクションをお読みください。
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.
外部パートナーへの多くの接続を維持している企業（例えば、自動車製造会社）は、常に唯一のX.25ネットワークに並行して、とにかく考慮されなければならない互換性の観点から、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.
ISDN網にX.25ネットワークから一般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は、これらの用語にODETTE推薦を定義、D.2はなじみのない読者にISDN環境を導入し、D.3は、ISDNに接続する種々の方法を記載し、そしてD.4は、実装の問題をカバーします。
D.1. ODETTE ISDN Recommendation
D.1。 ODETTE ISDN勧告
X.25: Level 2 ISO 7776 Protocol
X.25：レベル2 ISO 7776プロトコル
Level 3 ISO 8208
Protocol
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.
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.
以降のページは情報であり、この勧告の一部を構成するものではありません。
D.2. Introduction to ISDN
D.2。 ISDNの紹介
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).
このような高い品質、エラーフリーのバックボーンネットワーク上でデジタル符号化技術の使用はPTTsは、エンドユーザーに高い帯域幅を提供することができました。サービスは、ISDN（総合デジタル通信網）と命名されます。
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図面では、高速、低コストの通信時に注意を集中してきました。パケットを超える伝統的なX.25はデータネットワーク（PSDN）が良い汎用の通信サブシステムとなっているスイッチ。残念ながら、そのコストと転送速度は、新たな要件のPSDNが高価にします。
X.25 over the new ISDN provides both the transfer speed and cost benefits to satisfy the new requirements.
新しいISDN経由X.25は、新しい要件を満たすために、転送速度とコストメリットの両方を提供します。
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 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です。 PSPDNsは、英国の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×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×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.
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
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.
すべてのPTTsはETSIへの移行を約束している（また、EURO-ISDNおよびQ.931として知られている）と、多くは現在、自国のバリアントとETSIの両方をサポートしています。このような状況では、加入者は、不要な設備の陳腐化を避けるために、ETSIのバリアントを選択することをお勧めします。
Services: The high-speed service is provided in two forms, Basic and Primary.
サービス：高速サービスは二つの形式、基本とプライマリで提供されています。
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.
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メガビット/秒であることに注意してください。
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サービスを有することが可能では、1つの特定の外部に対して複数の電話ポイント（拡張機能）を有するであろうと同様に、複数の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接続でアクティブに他の相手先選択接続（SVC）が存在しない場合は、ISDN接続のダウン明らかにのみ行われるべきです。複数の同時のSVCの使用が唯一の二国間協定のおかげであることに注意してください。
D.3. Equipment Types
D.3。機器の種類
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.
そのような直接結合の他の利点は、両方の64K Bチャネルが平行と64kビットで動作することの両方に使用することができるということです。
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.25アダプタ通信X.21を有しています。これは、X.25機能を持つホストは、通常、1対1で、ISDNにインタフェースすることができます。
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.
スイッチの主な利点は、同時にPSTN及びISDNの両方をサポートすることです。また、複数のX.21線がX.25スイッチとコンピュータとの間で実施されてもよいです。
This solution normally requires more effort to configure and may require obligations to be placed upon how incoming callers specify routing.
このソリューションは、通常、設定するには、より多くの労力を必要とし、発信者はルーティングを指定する方法、着信時に配置する義務が必要な場合があります。
D.4. Implementation
D.4。実装
The adoption of ISDN as an additional subsystem to support OFTP communications has associated implementation problems, which can be categorised as below:
OFTP通信をサポートするための追加のサブシステムとしてISDNの採用は、以下のように分類することができ、実装の問題が、関連しています。
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コール論理チャネル割り当て施設交渉ISDNコールはホモロゲ問題の成長パフォーマンス属性の受信電話をかけるアドレッシング
D.4.1. X.25/ISDN Addressing
D.4.1。 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に採用アドレッシングスキームは最初の三つの国を識別する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番号方式は、二つの全く異なる番号方式です。それらの間の関係はありません。これは、問題の核心にあるこの競合です。
D.4.2. Making a Call
D.4.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は、接頭辞2は00944733で削除および置換されて00944733394023のPSTN番号を導出するように操作することができます。
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コールは、次いでHDLC / X.25プロトコル設定が確立され、確立されたコールの後PSTN番号0733394023.のISDNコールになり、その後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国家：0733 394023国際：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の呼び出しが行われているとき、X.25 NUAの最大長さである、PSTN番号が15桁を超える可能性があります。そのため、使用してアンマップさせるために、いくつかの国際通話が不可能にも取り組みます。
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呼び出し要求は、プレフィックス「2」が削除され、「009」（国際プレフィクス）に置き換えられ00944733394023のPSTN番号を導出するように操作することができます。
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.
NUAと呼ばれるX.25は、典型的には、その非操作状態のままにされるだろう。個々の内部規則は異なるため、NUAと呼ばれるX.25が異なります。上記の場合、それは244733394023になりますが、別のインストールが「56」の接頭辞は、英国とを指定する規則がある場合がありますので、NUAは「56」を削除して導き出すために「00944」に置き換えられ56733394023を、になります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のメインフレームは、すべての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ルータボックス内のテーブルを変更するには、コンピュータルームや特別な構成機器へのアクセスを必要とすることを意味します。
D.4.3. Receiving a Call
D.4.3。電話を受けます
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.
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サブアドレス呼ば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が変化した場合明らかに、第二の方法では動作しません。
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のサブアドレスの二つの形式、overdialledと特定があります。
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.
overdial方法は、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.
離散サブアドレスは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.
結論として、どのような種類のサブアドレスは避けるべきです。
D.4.4. Logical Channel Assignment
D.4.4。論理チャネル割り当て
An X.25 dataline will have associated with it a number of logical
channels.
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の観点から使用されており、コールが拒否されます。
D.4.5. Facilities Negotiation
D.4.5。施設の交渉
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.
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」のデフォルト値は「7」、PTTとの合意によって。
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.
加入者は、例えば、「1024」、PTTと合意した他のデフォルト値を有してもよいCCITT X.25パケットサイズは、「128」オクテットのデフォルト値を有しています。
D.4.6. ISDN Call Setup
D.4.6。 ISDNコール設定
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.
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表示
D.4.7. Homologation Issues
D.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によって提供されるサービスに接続された通信機器の品質と適合性に関してPTTsによって実施しました。
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.
特に、商用X.25製品は、彼らがPTTs' PSPDNに接続される前にテストされ、承認されなければなりませんでした。加入者へのこの利点は、動作していない承認された機器の非常に少ないチャンスがあったということでした。
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.
これまでのところ、テストは、見つけることを証明し、修正するために何日取っているようなタイミングの問題など微妙なエラーの数を示しています。
D.4.8. Growth
D.4.8。成長
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と一緒に成長するための一つの方法は、2×Bチャネルの単位で徐々に増加し、複数のBRI回線を購入することです。 PTTsはPSTN型作業に関連した伝統的なハンティンググループと同様に提供されるすべての行に対して同一の加入者番号を提供することができるであろう。
D.4.9. Performance
D.4.9。演奏
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.
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インターフェイスを使用してコンピュータに既定2 BチャネルはBチャネルの一つが一度にアクティブである場合にのみ、一貫性のある64 KBのスループットを与えるために起こっているとISDN回線を接続します。
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%.
2つの64 kbのチャネル活性及び単一の64 kbのX.21インターフェイスの競合がある場合、実効スループットはわずか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.
次のセクションでは、CCITT X.25標準のISOの拡張であるISO / IEC 8208（国際標準化機構、国際電気）（1990年3月15日）、標準、からの抜粋です。
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が（すなわち、それはDCEから来た）、その後、DTEはDTEとしての役割を維持しなければならない「DTEが発信さ」ではありません再起動の原因コードでRESTART通知パケットを受信した場合。
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.
DTEが（すなわち、それは別のDTEから来た）「DTEが起源」の再開原因コードでRESTART通知パケットを受信した場合b）は、その後、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.
DTEは、「DTEが起源」の再開原因コードでRESTART通知パケットを受信した場合C）（すなわち、それは別のDTEから来た）、それは（発行済未確認RESTART要求パケットを持っていない、すなわち、再起動の衝突）、その後、 DTEが完成し、この再起動の手順を考慮しなければならないが、いくつかのランダムに選択された時間遅延の後に別のRESTART要求パケットを送信する以外に何の更なる措置を講じてはなりません。
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.
DTEはその後RESTART確認パケットで確認されたRESTART要求パケットを発行した場合D）、その後、DTEは、DTEとしての役割を維持しなければなりません。
Acknowledgements
謝辞
This document draws extensively on revision 1.4 of the ODETTE File Transfer Specification [OFTP].
この文書では、[OFTP] ODETTEファイル転送仕様の改訂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-圧縮] Gutmann氏、P.、 "暗号メッセージ構文（CMS）のための圧縮されたデータcontent type"、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]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ドイツ、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]ヨーロッパ、オデットファイル転送プロトコル、リビジョン1.4、2000年4月テレ伝送によるデータ交換のための組織。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP]ポステル、J.とJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RIME] Coleridge, Samuel Taylor, "The Rime of the Ancient Mariner", 1817.
【RIME】コールリッジ、サミュエル・テイラー、「古代マリナーのライム」、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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット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.は、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取り扱い"。
ODETTE Address
ODETTE住所
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セントラルオフィスを介して接触させることができます。
ODETTE INTERNATIONAL Limited Forbes House Halkin Street London SW1X 7DS United Kingdom
ODETTE INTERNATIONAL株式会社フォーブスハウスハルキンストリートロンドンSW1X 7DSイギリス
Phone: +44 (0)171 344 9227 Fax: +44 (0)171 235 7112 EMail: info@odette.org URL: http://www.odette.org
電話：+44（0）171 344 9227ファックス：+44（0）171 235 7112 Eメール：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友達データ交換Plcのリス・ハウスザ・ミネルヴァビジネスパークLynchwoodピーターバラPE2 6FTイギリス
Phone: +44 (0)1733 371 311 EMail: ieuan.friend@dip.co.uk
電話：+44（0）1733 371 311 Eメール：ieuan.friend@dip.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。