RFC5024 日本語訳
5024 ODETTE File Transfer Protocol 2.0. I. Friend. November 2007. (Format: TXT=276953 bytes) (Obsoletes RFC2204) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group I. Friend Request for Comments: 5024 ODETTE Obsoletes: 2204 November 2007 Category: Informational
コメントを求めるワーキンググループI.友人要求をネットワークでつないでください: 5024 オデットは以下を時代遅れにします。 2204 2007年11月のカテゴリ: 情報
ODETTE File Transfer Protocol 2
オデットFile Transfer Protocol2
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は配布しているプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実装と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
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.
このメモはオデットFile Transferプロトコルをアップデートします、確立したファイル転送プロトコルが貿易相手国の間の業務データの電子データ交換を容易にして、バージョン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.
プロトコルは、現在Transport Layer Securityを使用することで安全で認証されたインターネット通信をサポートして、Cryptographic Message Syntaxを使用することでファイル暗号化、署名、および圧縮を提供して、受信されたファイルの承認のための署名している領収書を提供します。
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を拠点とするネットワークと共に使用されるかもしれません。
Friend Informational [Page 1] RFC 5024 ODETTE FTP 2 November 2007
[1ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
1. 序論…4 1.1. バックグラウンド…4 1.2. 特徴の概要…5 1.3. 綱領…5 1.4. 構造…6 1.5. 仮想のファイル…6 1.6. 記述を修理してください…9 1.7. セキュリティ…9 2. サービスをネットワークでつないでください…11 2.1. 序論…11 2.2. 基関数を修理してください…11 2.3. オデット-FTPセッションを保証してください…12 2.4. 課題を移植してください…12 3. ファイル転送サービス…13 3.1. モデル化してください…13 3.2. セッションセットアップ…14 3.3. ファイル転送…16 3.4. セッションは下に取ります…20 3.5. 州のオートマトンを修理してください…23 4. 仕様を議定書の中で述べてください…28 4.1. 概要…28 4.2. セッションフェーズを始めてください…28 4.3. ファイルフェーズを始めてください…30 4.4. データ転送フェーズ…34 4.5. ファイルフェーズを終わらせてください…35 4.6. セッションフェーズを終わらせてください…36 4.7. 問題取り扱い…36 5. コマンドと形式…37 5.1. コンベンション…37 5.2. コマンド…37 5.3. 書式を命令してください…37 5.4. 識別コード…68 6. サービスをファイルしてください…69 6.1. 概要…69 6.2. 署名をファイルしてください…69 6.3. 暗号化をファイルしてください…70 6.4. 圧縮をファイルしてください…70 6.5. V形式ファイル--長さを記録してください…70 7. オデット-FTPデータはバッファを交換します…71 7.1. 概要…71 7.2. データはバッファ形式を交換します…71 7.3. 腹を満たす規則をバッファリングしてください…72 8. 流れ転送バッファ…73 8.1. 序論…73 8.2. 流れ転送ヘッダー形式…73
Friend Informational [Page 2] RFC 5024 ODETTE FTP 2 November 2007
[2ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
9. 州のマシンについて議定書の中で述べてください…74 9.1. オデット-FTP州のマシン…74 9.2. エラー処理…75 9.3. 述べます。76 9.4. イベントを入力してください…79 9.5. イベントを出力してください…79 9.6. 局所変数…80 9.7. 地方の定数…81 9.8. セッション接続ステートテーブル…82 9.9. 誤りとアボートはテーブルを述べます…85 9.10. 議長ステートテーブル1…86 9.11. 議長ステートテーブル2…91 9.12. リスナーステートテーブル…93 9.13. 例…96 10. その他…97 10.1. アルゴリズム選択…97 10.2. 暗号アルゴリズム…97 10.3. 拡大について議定書の中で述べてください…97 10.4. サービスを証明してください…98 11. セキュリティ問題…98の付録のA.の仮想のファイルマッピングの例…100 付録B.ISO646文字サブセット…103 付録C.X.25特殊情報…104 C.1。 X.25アドレシング制限…104 C.2。 特別な論理…105 C.3。 パラメタプロフィールを水増ししてください…116 ISDN推薦の上の付録D.OFTP X.25…118 D.1。 オデットISDN推薦…119 D.2。 ISDNへの序論…120 D.3。 設備はタイプされます…123 D.4。 実装…124の承認…132 標準の参照…132 有益な参照…133 オデットAddress…134
Friend Informational [Page 3] RFC 5024 ODETTE FTP 2 November 2007
[3ページ]友人の情報のRFC5024オデットFTP2007年11月2日
1. Introduction
1. 序論
1.1. Background
1.1. バックグラウンド
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.
ヨーロッパ(オデット)のTele TransmissionによるData Exchangeが、電子データ交換(EDI)がヨーロッパの自動車産業の要件であると扱うように、オデットFile Transferプロトコル(オデット-FTP)は1986年にOrganisationのワーキンググループfourによって定義されました。
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.
オデット-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.
オデット-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年間、インターネットは優位な国際ネットワークとして現れましたが、オデット-FTPはすべてのサイズのシステムの上でパーソナルコンピュータから大きいメインフレームまで広く配布されています、わずかの費用で高速通信を提供して。 EDIの需要をインターネットの上に合わせるなら、オデットは、セキュリティ機能を取り入れるためにファイル転送プロトコルの範囲を広げると決めて、情報交換技術の最先端に残るのを保証するために圧縮のテクニックを唱えました。
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.
プロトコルは、現在Transport Layer Securityを使用することで安全で認証されたインターネット通信をサポートして、Cryptographic Message Syntaxを使用することでファイル暗号化、署名、および圧縮を提供して、受信されたファイルの承認のための署名している領収書を提供します。
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.
オデット-FTPは多くのオデット会員会社から成るオデットSecurity作業部会によって定義されました。 すべてのメンバーには、OFTPとEDI解決策を働いて、見いだすという重要な運用経験があります。
Friend Informational [Page 4] RFC 5024 ODETTE FTP 2 November 2007
[4ページ]友人の情報のRFC5024オデットFTP2007年11月2日
1.2. Summary of Features
1.2. 特徴の概要
This memo is a development of version 1.4 of ODETTE-FTP [OFTP] with these changes/additions:
このメモはこれらの変化/追加へのオデット-FTP[OFTP]のバージョン1.4の開発です:
Session level encryption
File level encryption
Secure authentication
File compression
Signed End to End Response (EERP)
Signed Negative End Response (NERP)
Maximum permitted file size increased to 9 PB (petabytes)
Virtual file description added
Extended error codes
9PB(ペタバイト)の仮想のファイル記述に増強されたNegative End Response(NERP)の最大の受入れられたファイルサイズであると署名されるEnd Response(EERP)へのセッションレベル暗号化Fileレベル暗号化Secure認証File圧縮Signed EndはExtendedエラーコードを加えました。
Version 1.4 of ODETTE-FTP included these changes and additions to version 1.3:
オデット-FTPのバージョン1.4はこれらの変化と追加をバージョン1.3に含んでいました:
Negative End Response (NERP)
Extended Date and Time stamp
New reason code 14 (File direction refused)
否定的End Response(NERP)の拡張DateとTimeはNew理由コード14を押し込みます。(拒否されたファイルの方向)
1.3. General Principles
1.3. 綱領
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.
オデット-FTPの目的はデータ通信ネットワーク、システムハードウェア、およびソフトウェア環境から独立している方法で複数の位置の間のファイルの伝達を容易にすることです。
In designing and specifying the protocol, the following factors were considered.
プロトコルを設計して、指定する際に、以下の要素は考えられました。
1. The possible differences of size and sophistication of file
storage and small and large systems.
1. サイズの違いの可能性とファイル記憶装置と大小システムに関する洗練。
2. The necessity to work with existing systems (reduce changes to
existing products and allow easy implementation).
2. 既存のシステム(既存の製品への変化を減少させて、簡単な実装を許容する)で働く必要性。
3. Systems of different ages.
3. 異なった年令のシステム。
4. Systems of different manufactures.
4. 異なることのシステムは製造されています。
5. The potential for growth in sophistication (limit impact and avoid
changes at other locations).
5. 洗練(他の位置で影響を制限して、変化を避ける)の成長の可能性。
Friend Informational [Page 5] RFC 5024 ODETTE FTP 2 November 2007
[5ページ]友人の情報のRFC5024オデットFTP2007年11月2日
1.4. Structure
1.4. 構造
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.
オデット-FTPはOSI参照モデルに似せられます。 それは、モデルのレベル3によって提供されたNetwork Serviceを使用して、File Serviceをユーザに提供するように設計されています。 したがって、プロトコルはモデルのレベル4〜7にかかっています。
The description of ODETTE-FTP contained in this memo is closely related to the original 'X.25' specification of the protocol and in the spirit of the OSI model describes:
このメモに含まれたオデット-FTPの記述は、密接にプロトコルの当初の'X.25'仕様に関連して、OSIモデルの精神で以下について説明します。
1. A File Service provided to a User Monitor.
1. ファイルサービスはユーザモニターに供給されました。
2. A protocol for the exchange of information between peer
ODETTE-FTP entities.
2. 同輩オデット-FTP実体の間の情報交換のためのプロトコル。
1.5. Virtual Files
1.5. 仮想のファイル
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.
Virtual Fileと呼ばれる標準の表現におけるオデット-FTP実体の間でいつも情報を交換します。 これは交信システムの本質への尊敬なしでデータ転送を許容します。
The mapping of a file between a local and virtual representation will vary from system to system and is not defined here.
地方の、そして、仮想の表現の間のファイルに関するマッピングは、システムによって異なって、ここで定義されません。
Friend Informational [Page 6] RFC 5024 ODETTE FTP 2 November 2007
[6ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
o---------o サイト| ローカル| A| ファイルA| o---------o | o----------------------- Aを写像します。------------------------o | | | | o---------o | | | 仮想| | | | ファイル| | | o---------o | | o------------------------------------------------o | | | | | | | オデット-FTP| | | | | | | o------------------------------------------------o | | o---------o o---------o | | | 仮想| | 仮想| | | | ファイル| | ファイル| | | o---------o o----+----o | | | | | o------ Bを写像します。------------------------ Cを写像します。------o | | o---------o o----+----o | ローカル| サイトサイト| ローカル| | ファイルB| B C| ファイル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.
Virtual Fileは移すためにデータを特定して、定義する1セットの属性によって説明されます。 主な属性はセクション1.5で.1〜1.5に.4に詳細です。
1.5.1. Organisation
1.5.1. 機構
Sequential
連続する
Logical records are presented one after another. ODETTE-FTP must
be aware of the record boundaries.
論理レコードは相次いで提示されます。 オデット-FTPは境界の記録を意識しているに違いありません。
1.5.2. Identification
1.5.2. 識別
Dataset Name
データセット名
Dataset name of the Virtual File being transferred, assigned by
bilateral agreement.
データセット名(二国間条約によって割り当てられて、移されるVirtual File)。
Friend Informational [Page 7] RFC 5024 ODETTE FTP 2 November 2007
[7ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
Virtual Fileがトランスミッションに利用可能にされた時を示すファイル資格を与える人。 カウンタ(cccc=0001-9999)は、より高い解像度を与えます。
Date stamp (CCYYMMDD)
日付のスタンプ(CCYYMMDD)
A file qualifier indicating the date the Virtual File was made
available for transmission.
Virtual Fileがトランスミッションに利用可能にされた日付を示すファイル資格を与える人。
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.
Dataset Name、Date、およびTime属性は、Virtual Fileの創始者によって割り当てられて、唯一ファイルを特定するのに使用されます。 それらをすべて義務的であり、中間的な場所は変えてはいけません。
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.
User Monitorは、日付の比較と計算にかかわりながら、地方のプロセスでVirtual File DateとTime属性を使用するかもしれません。 どんなそのような使用もこのプロトコルの範囲をそらせます。
1.5.3. Record Format
1.5.3. レコード形式
Four record formats are defined:
4つのレコード形式が定義されます:
Fixed (F)
修理されています。(F)
Each record in the file has the same length.
ファイルでの各記録には、同じ長さがあります。
Variable (V)
変数(V)
The records in the file can have different lengths.
ファイルでの記録は異なった長さを持つことができます。
Unstructured (U)
不統一(U)
The file contains a stream of data. No structure is defined.
ファイルはデータのストリームを含んでいます。 構造は全く定義されません。
Text File (T)
テキストファイル(T)
A Text File is defined as a sequence of ASCII characters,
containing no control characters except CR-LF that delimit
lines. A line will not have more than 2048 characters.
系列を区切るCR-LF以外に、制御文字を全く含んでいなくて、Text FileはASCII文字の系列と定義されます。 系列には、2048以上のキャラクタがないでしょう。
1.5.4. Restart
1.5.4. 再開
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.
オデット-FTPは中断しているVirtual Fileトランスミッションの再開を交渉できます。 修理されて、Variable形式ファイルは公に知られていた状態で再開されます。境界。 UnstructuredとTextファイルに関しては、ファイルが1K(1024年の八重奏)のブロックで相殺されたので、再開位置は言い表されます。
Friend Informational [Page 8] RFC 5024 ODETTE FTP 2 November 2007
[8ページ]友人の情報のRFC5024オデットFTP2007年11月2日
The restart position is always calculated relative to the start of the Virtual File.
再開位置はいつもVirtual Fileの始まりに比例して計算されます。
1.6. Service Description
1.6. サービス記述
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.
オデット-FTPは、User Monitorに対するファイル転送サービスを提供して、同輩の間で交信するのに順番にインターネットトランスポート層ストリームサービスを利用します。
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.
サービスは、まさしく要求と指示プリミティブを使用することで要求、指示、応答、および確認プリミティブを使用して、確認されて、未確認であるかもしれません。
1.7. Security
1.7. セキュリティ
ODETTE-FTP provides a number of security services to protect a Virtual File transmission across a hostile network.
オデット-FTPは、敵対的なネットワークの向こう側にVirtual Fileトランスミッションを保護するために多くのセキュリティー・サービスを提供します。
These security services are as follows:
これらのセキュリティー・サービスは以下の通りです:
Confidentiality
Integrity
Non-repudiation of receipt
Non-repudiation of origin
Secure authentication
発生源Secure認証の領収書Non-拒否の秘密性Integrity Non-拒否
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
セッションレベル暗号化Fileレベル暗号化SignedファイルSignedはSessionレベル認証オデット-FTP Authenticationを領収書を出させます。
Session level encryption provides data confidentiality by encryption of all the protocol commands and data exchanged between two parties, preventing a third party from extracting any useful information from the transmission.
セッションレベル暗号化は2回のパーティーの間で交換されたすべてのプロトコルコマンドとデータの暗号化でデータの機密性を提供します、第三者がトランスミッションからどんな役に立つ情報も抜粋するのを防いで。
Friend Informational [Page 9] RFC 5024 ODETTE FTP 2 November 2007
[9ページ]友人の情報のRFC5024オデットFTP2007年11月2日
This session level encryption is achieved by layering ODETTE-FTP over Transport Layer Security [TLS], distinguishing between secure and unsecure TCP/IP traffic using different port numbers.
このセッションレベル暗号化はTransport Layer Security[TLS]の上でレイヤリングオデット-FTPによって達成されます、異なったポートナンバーを使用することで安全、そして、unsecure 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コードとVirtual File名はまだ見えています。
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.
また、オデット-FTP Authenticationは認証機構を提供しますが、オデット-FTPに不可欠の、そして、どのオデット-FTPの上ですべてのネットワークインフラで利用可能であるかものは操作されます(これは一般に、TCP/IPを拠点とするネットワークの上で利用可能であるだけである[TLS]と対照的になっています)。 オデット-FTP Authenticationが使用されているとき、双方には、証明書がなければなりません。
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.
オデット-FTP2におけるセキュリティ機能は[X.509]証明書の使用の周りを集中させられます。 両方の方向に提供されたセキュリティー・サービスの全種類を利用するために、各当事者には、[X.509]証明書がなければなりません。 2回のパーティーの間のデータの秘密性が唯一の関心であるなら、[TLS](接続要求(Responder)が証明書を持つのに必要である唯一のパートナーであると受け入れるパーティーを許容する)しか使用できません。
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]を技術的に排除しませんが、実装はまれです。
Friend Informational [Page 10] RFC 5024 ODETTE FTP 2 November 2007
[10ページ]友人の情報のRFC5024オデットFTP2007年11月2日
2. Network Service
2. ネットワーク・サービス
2.1. Introduction
2.1. 序論
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.
オデット-FTP同輩実体はOSI Network Serviceか通信制御プロトコルTransport Service[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.
インターネット環境において、Network Serviceのために以下に言及されたサービス基関数はそれぞれのTransport Service基関数に写像されなければなりません。 このセクションはオデット-FTPによって使用されるNetwork Service基関数とTCPインタフェースとのそれらの関係について説明します。 実際には、ローカル運送サービスアプリケーションプログラミングインターフェースは、TCPサービスにアクセスするのに使用されるでしょう。
2.2. Service Primitives
2.2. サービス基関数
All network primitives can be directly mapped to the respective Transport primitives when using TCP.
TCPを使用するとき、直接すべてのネットワーク基関数をそれぞれのTransport基関数に写像できます。
2.2.1. Network Connection
2.2.1. ネットワーク接続
N_CON_RQ ------> N_CON_IND
N_CON_CF <------ N_CON_RS
N_まやかし_RQ------>N_まやかし_インディアン座N_まやかし_Cf<。------ N_まやかし_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.
これは接続のセットアップについて説明します。 要求しているオデット-FTP同輩は同輩オデット-FTP、以前に受け身のオープンを要求したResponderに接続の活発なオープンを要求するために原始的にN_CON_RQを使用します。 ResponderはN_CON_INDを通して接続要求について通知されて、N_CON_RSと共にそれを受け入れます。 リクエスタはN_CON_CFを受け取り次第オープン要求の完成について通知されます。
Parameters
パラメタ
Request Indication Response Confirmation --------------------------------------------------------------------- Dest addr ------> same same same
指示応答確認を要求してください。--------------------------------------------------------------------- Dest addr------>の同じ同じ同じこと
2.2.2. Network Data
2.2.2. ネットワークデータ
N_DATA_RQ ------> N_DATA_IND
_N_データRQ------>N_データ_インディアン座
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を通したNetwork Serviceへの伝送のため原始的にデータを通過します。 ResponderはN_DATA_INDを通してデータの利用可能性について通知されます。
Friend Informational [Page 11] RFC 5024 ODETTE FTP 2 November 2007
[11ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
指示を要求してください。--------------------------------------------------------------------- データ------------------>同じです。
2.2.3. Network Disconnection
2.2.3. ネットワーク断線
N_DISC_RQ ------> N_DISC_IND
N_ディスク_RQ------>N_ディスク_インディアン座
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.
オデット-FTPは原始的なN_DISC_RQサービスとの関係の終了を要求します。 同輩はN_DISC_INDイベントによってCLOSEについて通知されます。 各同輩がTCPの左右対称の近い手順を完了するために原始的にN_DISC_RQを発行しなければならないと認められます。
2.2.4. Network Reset
2.2.4. ネットワークリセット
------> N_RST_IND
------>N_RST_インディアン座
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.
オデット-FTP実体はN_RST_INDイベントによってネットワーク誤りについて通知されます。 また、N_RST_INDが接続の同輩RESETTINGが生成されることに注意するべきですが、オデット-FTPでN_RST_RQをNetwork Serviceに決して送らないとき、ここでこれを無視します。
2.3. Secure ODETTE-FTP Session
2.3. 安全なオデット-FTPセッション
[TLS] provides a mechanism for securing an ODETTE-FTP session over the Internet or a TCP network. ODETTE-FTP is layered over [TLS], distinguishing between secure and unsecure traffic by using different server ports.
[TLS]はインターネットかTCPネットワークの上でオデット-FTPセッションを保証するのにメカニズムを提供します。 異なったサーバポートを使用することによって安全、そして、unsecureトラフィックを見分けて、オデット-FTPは[TLS]の上で層にされます。
The implementation is very simple. Layer ODETTE-FTP over [TLS] in the same way as layering ODETTE-FTP over TCP/IP. [TLS] provides both session encryption and authentication, both of which may be used by the connecting parties. A party acts as a [TLS] server when receiving calls and acts as a [TLS] client when making calls. When the [TLS] handshake has completed, the responding ODETTE-FTP may start the ODETTE-FTP session by sending the Ready Message.
実装は非常に簡単です。 TCP/IPの上でオデット-FTPを層にするのと同様に、[TLS]の上でオデット-FTPを層にしてください。 [TLS]はセッション暗号化と認証の両方を提供します。その両方が接続パーティーによって使用されるかもしれません。 パーティーは、受信するとき、[TLS]サーバが呼ぶように務めて、電話をかけるとき、[TLS]クライアントとして務めます。 [TLS]握手が始めたとき、完成していて、応じるオデット-FTPは、Ready Messageを送ることによって、オデット-FTPセッションを始めるかもしれません。
2.4. Port Assignment
2.4. ポート課題
An ODETTE-FTP requester will select a suitable local port.
オデット-FTPリクエスタは適当な地方のポートを選択するでしょう。
The responding ODETTE-FTP will listen for connections on Registered Port 3305; the service name is 'odette-ftp'.
応じるオデット-FTPはRegistered Port3305で接続の聞こうとするでしょう。 サービス名は'odette-ftp'です。
Friend Informational [Page 12] RFC 5024 ODETTE FTP 2 November 2007
[12ページ]友人の情報のRFC5024オデットFTP2007年11月2日
The responding ODETTE-FTP will listen for secure TLS connections on Registered Port 6619; the service name is 'odette-ftps'.
応じるオデット-FTPはRegistered Port6619で安全なTLS接続の聞こうとするでしょう。 サービス名は'odette-ftps'です。
3. File Transfer Service
3. ファイル転送サービス
The File Transfer Service describes the services offered by an ODETTE-FTP entity to its User Monitor (generally an application).
File Transfer Serviceはオデット-FTP実体によってUser Monitor(一般にアプリケーション)に提供されたサービスについて説明します。
NOTE: The implementation of the service primitives is an application
issue.
以下に注意してください。 サービス基関数の実装はアプリケーション問題です。
3.1. Model
3.1. モデル
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
o-------------------o o-------------------o | | | | | ユーザモニター| | ユーザモニター| | | | | o-------------------o o-------------------o | A| A| | | | _F XXX_RQ/RS| | _F_XXX_インディアン座/Cf F XXX_RQ/RS| | F_XXX_インディアン座/Cf V| V| o-------------------o o-------------------o | |- - - - - - >|、|、| オデット-FTP実体| 電子バッファ| オデット-FTP実体| | |<--、--、--、--、--、-| | o-------------------o o-------------------o | A| N_XXX_RQ/RS| | _N_XXX_インディアン座/Cf N XXX_RQ/RS| | N_XXX_インディアン座/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
キー: 電子バッファ--原始的にバッファのF_ ―ファイル転送のサービスの原始のN_ ―ネットワーク・サービスを交換してください。
Friend Informational [Page 13] RFC 5024 ODETTE FTP 2 November 2007
[13ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3.2. Session Setup
3.2. セッションセットアップ
3.2.1. Session Connection Service
3.2.1. セッション接続サービス
These diagrams represent the interactions between two communicating ODETTE-FTP entities and their respective User Agents.
これらのダイヤグラムは2の間のオデット-FTP実体と彼らのそれぞれのUserエージェントを伝える相互作用を表します。
The vertical lines represent the ODETTE-FTP entities. The User Agents are not shown.
縦線はオデット-FTP実体を表します。 Userエージェントは見せられません。
| |
F_CONNECT_RQ ---->|------------|----> F_CONNECT_IND
| |
F_CONNECT_CF <----|------------|<---- F_CONNECT_RS
| |
| | F_は_RQを接続します。---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_は_インディアン座を接続します。| | F_は_Cf<を接続します。----|、-、-、-、-、-、-、-、-、-、-、--、| <、-、-、-- F_は_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 ---------------------------------------------------------------------
応答が確認する指示を要求してください。--------------------------------------------------------------------- 着呼アドレス->同じです。--- ---- 呼んでいるアドレス>同じです。--- ---- ID1------------>の同じID2------------>の同じPSW1------------>の同じPSW2----------->の同じmode1---------->mode2---------->mode3---------->の同じrestart1------->同じです。----------->restart2------->の同じauthentication1->同じです。----------->authentication2->同じです。---------------------------------------------------------------------
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.
交渉: 交渉可能な送付者唯一のNot。 交渉可能な受信機唯一のNot。 両方、Can、User Monitorかオデット-FTP実体によってSenderだけかReceiverだけまで交渉されてください。
Friend Informational [Page 14] RFC 5024 ODETTE FTP 2 November 2007
[14ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
User Monitorのファイル転送再開能力を指定します。
Value:
Y The entity can restart file transfers.
N The entity cannot restart file transfers.
値: Y、実体はファイル転送を再開できます。 N、実体はファイル転送を再開できません。
Negotiation:
交渉:
Request Indication Response Confirm
---------------------------------------------------------------------
restart = Y ----> restart = Y --+-> restart = Y ----> restart = Y
or +-> restart = N ----> restart = N
応答が確認する指示を要求してください。--------------------------------------------------------------------- 再開=Y---->再開=Y--+->は=Yを再開します。---->再開=Yか+->再開=N---->再開=N
restart = N ----> restart = N ----> restart = N ----> restart = N ---------------------------------------------------------------------
再開=N---->再開=N---->再開=N---->再開=N---------------------------------------------------------------------
Authentication
認証
Specifies the authentication requirement of the User Monitor.
User Monitorの認証要件を指定します。
Value:
Y Authentication required.
N Authentication not required.
値: Y認証が必要です。 N認証は必要ではありません。
Negotiation: Not negotiable.
交渉: 交渉可能でない。
Friend Informational [Page 15] RFC 5024 ODETTE FTP 2 November 2007
[15ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Request Indication Response Confirm --------------------------------------------------------------------- auth = Y ----> auth = Y ----> auth = Y ----> auth = Y
応答が確認する指示を要求してください。--------------------------------------------------------------------- authはYと等しいです。---->authはYと等しいです。---->authはYと等しいです。---->authはYと等しいです。
auth = N ----> auth = N ----> auth = N ----> auth = N ---------------------------------------------------------------------
authはNと等しいです。---->authはNと等しいです。---->authはNと等しいです。---->authはNと等しいです。---------------------------------------------------------------------
3.3. File Transfer
3.3. ファイル転送
3.3.1. File Opening
3.3.1. ファイル・オープニング
| |
F_START_FILE_RQ ---->|------------|----> F_START_FILE_IND
| |
F_START_FILE_CF(+|-) <----|------------|<---- F_START_FILE_RS(+|-)
| |
| | F_は_ファイル_RQを始動します。---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_は_ファイル_インディアン座を始めます。| | F_が_ファイル_Cfを始める、(+|、-、)、<。----|、-、-、-、-、-、-、-、-、-、-、--、| <、-、-、-- F_が_ファイル_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 ------------------------------------------------------------------
インディアナ州を要求してください。 RS(+)Cf(+)RS(-)Cf(-)------------------------------------------------------------------ ファイル名------->同じです。---- ---- ---- ---- 日付-時間------>同じです。---- ---- ---- ---- 目的地---->同じです。---- ---- ---- ---- 創始者----->同じです。---- ---- ---- ---- rec-形式----->同じです。---- ---- ---- ---- rec-サイズ------>同じです。---- ---- ---- ---- ファイルサイズ------>同じです。---- ---- ---- ---- orgファイルサイズ--、>同じ---- ---- ---- ---- 署名しているeerp---->同じです。---- ---- ---- ---- 暗号--------->同じです。---- ---- ---- ---- 秒サービス--->同じです。---- ---- ---- ---- 圧縮---->同じです。---- ---- ---- ---- 同じ状態で>を封筒でフォーマットしてください。---- ---- ---- ---- 記述---->同じです。---- ---- ---- ---- 再開-pos1--->同じ>再開pos2>同じです。---- ---- ---- ---- ---- ---- 原因------>同じです。---- ---- ---- ---- 後の>を再試行している同じこと------------------------------------------------------------------
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以下です。
Friend Informational [Page 16] RFC 5024 ODETTE FTP 2 November 2007
[16ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3.3.2. Data Regime
3.3.2. データ政権
| |
F_DATA_RQ ---->|------------|----> F_DATA_IND
| |
F_DATA_CF <----|(---CDT----)|
| |
| | _F_データRQ---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_データ_インディアン座| | F_データ_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_RSコマンドでは、ローカル要素層はF_XXX_CF信号が結果であるところでこの信号を支給します。 この決定は受信機から現在のクレジットカウントとCDTのレセプションに基づいています(Creditを設定します)。
3.3.3. File Closing
3.3.3. ファイル閉鎖
| |
F_CLOSE_FILE_RQ --->|------------|----> F_CLOSE_FILE_IND
| |
F_CLOSE_FILE_CF(+|-) <---|------------|<---- F_CLOSE_FILE_RS(+|-)
| |
| | F_は_ファイル_RQを閉じます。--->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->のF_の近い_ファイル_インディアン座| | F_が_ファイル_Cfを閉じる、(+|、-、)、<。---|、-、-、-、-、-、-、-、-、-、-、--、| <、-、-、-- F_が_ファイル_RSを閉じる、(+|、-、)| |
Parameters
パラメタ
Request Ind RS(+) CF(+) RS(-) CF(-) --------------------------------------------------------------------- rec-count ---> same ---- ---- ---- ---- unit-count --> same ---- ---- ---- ---- ---- ---- Speaker=Y ---> Speaker=N ---- ---- ---- ---- Speaker=N ---> Speaker=Y ---- ---- ---- ---- ---- ---- cause ---> same ---------------------------------------------------------------------
インディアン座RS(+)Cf(+)RS(-)Cf(-)を要求してください。--------------------------------------------------------------------- rec-カウント--->同じです。---- ---- ---- ---- 装置台数--、>同じ---- ---- ---- ---- ---- ---- 議長=Y--->議長=N---- ---- ---- ---- 議長=N--->議長=Y---- ---- ---- ---- ---- ---- 原因--->同じです。---------------------------------------------------------------------
In a positive Close File response (F_CLOSE_FILE_RS(+)) the current Listener may either:
積極的なClose File応答(F_CLOSE_FILE_RS(+))では、現在のListenerはそうするかもしれません:
1. Set Speaker to "Yes" and become the Speaker or
2. Set Speaker to "No" and remain the Listener.
1. 「はい」に議長を設定してください、そして、議長か2になってください。 「いいえ」に議長を設定してください、そして、Listenerのままで残ってください。
The File Transfer service will ensure that the setting of the speaker parameter is consistent with the capabilities of the peer user.
File Transferサービスは、スピーカーパラメタの設定が同輩ユーザの能力と一致しているのを確実にするでしょう。
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.
議長だけが_FILE_RQ基関数をF_XXXに発行できます。
Friend Informational [Page 17] RFC 5024 ODETTE FTP 2 November 2007
[17ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3.3.4. Exchanging the Turn
3.3.4. 回転を交換します。
3.3.4.1. Initial Turn (First Speaker)
3.3.4.1. 初期の回転(最初の議長)
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).
InitiatorはSession Setup(CFがInitiatorで受けたF_CONNECT_とRSがResponderで送ったF_CONNECT_)の端で第1代議長になります。
3.3.4.2. Following Turns
3.3.4.2. 回転に続きます。
Rules:
規則:
1. At each unsuccessful End of File, the turn is not exchanged.
1. Fileのそれぞれの失敗のEndには、回転は交換されません。
2. At each successful End of File, the turn is exchanged if requested
by the Listener:
2. FileのそれぞれのうまくいっているEndと、Listenerが要求するなら、回転を交換します:
- The current Listener receives F_CLOSE_FILE_IND (Speaker =
choice).
- 現在のListenerは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.
- ListenerがF_CLOSE_FILE_RS(議長=YES)に答えるなら、議長になって、議長は、F_CLOSE_FILE_CF(議長=NO)を受け取って、Listenerになります。
- 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.
- ListenerがF_CLOSE_FILE_RS(議長=NO)に答えるなら、Listenerとして残っていて、議長は、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. 議長はListenerになるというChange Direction要求(_F CD_RQ)を出すことができます。 ListenerはChange Direction指示(_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の輪を防ぐために、_CD_INDを求められていないFで受けた後に、議長はF_CD_RQを送らないかもしれません。 EFPA(議長=Yes)を送ることの結果、Listenerが請求された_F CD_INDを受けるなら、すぐにF_CD_RQを送ることによって話す権利を放棄するのは許容できます。
3.3.5. End to End Response
3.3.5. 終わって、応答を終わらせてください。
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.
このサービスは、最終的な目的地からファイルの創始者までEndをEnd Responseに送るために現在の議長(進行中のどんなファイル転送もなければ)によって開始されます。
Friend Informational [Page 18] RFC 5024 ODETTE FTP 2 November 2007
[18ページ]友人の情報のRFC5024オデットFTP2007年11月2日
| |
F_EERP_RQ ---->|------------|----> F_EERP_IND
| |
F_RTR_CF <----|------------|<---- F_RTR_RS
| |
| | _F EERP_RQ---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_EERP_インディアン座| | 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.
- 議長だけがEnd Response要求にEndを送るかもしれません。
- Invoking the EERP service does not change the turn.
- EERPサービスを呼び出す場合、回転は変化しません。
- If an F_CD_IND has been received just before F_EERP_RQ is issued,
this results in leaving the special condition created by the
reception of F_CD_IND; i.e., while it was possible to issue
F_RELEASE_RQ and not possible to issue F_CD_RQ just after the
reception of F_CD_IND, after having issued F_EERP_RQ the normal
Speaker status is entered again (F_CD_RQ valid, but F_RELEASE_RQ
not valid).
- F_EERP_RQを発行するすぐ前にF_CD_INDを受け取ったなら、これは特別な状態を_F CD_INDのレセプションによって引き起こされたままにするのに結果として生じます。 すなわち、Fのレセプションのすぐ_F CD_RQ後に_CD_INDを発行するのが_F RELEASE_RQを発行するのにおいて可能であって、可能でなかった間、_F EERP_RQを発行した後に正常な議長状態が再び入られる、(_F CD_RQ有効であるのにもかかわらずの、F_RELEASE_RQ、有効でない、)
Notes:
注意:
1. The F_EERP_RQ (and also F_NERP_RQ) is confirmed with an F_RTR_CF
signal. The F_RTR_CF signal is common to both F_EERP_RQ and
F_NERP_RQ. There should be no ambiguity, since there can only be
one such request pending at any one time.
1. F_EERP_RQはF_RTR_CF信号で確認されます(_そして、FもNERP_RQ)。 F_RTR_CF信号は_F EERP_RQと_F NERP_RQの両方に共通です。 いかなる時も、そのような要求の未定の1つがあることができるだけであるので、あいまいさが全くあるべきではありません。
2. The signature is optional and is requested when sending the
F_START_FILE_RQ.
2. F_START_FILE_RQを送るとき、署名は、任意であり、要求されます。
3. If it is not possible to sign the EERP, then an unsigned EERP
should still be sent.
3. EERPに署名するのが可能でないなら、まだ未署名のEERPを送るべきです。
Friend Informational [Page 19] RFC 5024 ODETTE FTP 2 November 2007
[19ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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であると署名されるaが要求されたとき合法化に失敗するか、または署名されないEERPを受け取り次第どんな行動を取ったらよいかを決めるアプリケーション導入問題です。
3.3.6. Negative End Response
3.3.6. 否定的終わりの応答
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.
このサービスは、次の目的地にファイルを送ることができなかったとき、Negative End Responseを送るために現在のスピーカー(進行中のどんなファイル転送もなければ)によって開始されます。 問題が非一時的な種類のものである場合にだけそれを送ります。
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.
また、このサービスはファイルを処理できなかったときEndをEnd Responseに送ることの代わりに最終的な目的地によって開始されるかもしれません、首尾よくファイルを受け取った後に。
| |
F_NERP_RQ ---->|------------|----> F_NERP_IND
| |
F_RTR_CF <----|------------|----- F_RTR_RS
| |
| | _F NERP_RQ---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_NERP_インディアン座| | 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).
Endから終わりへの応答(セクション3.3.5を見る)のように、同じです。
Friend Informational [Page 20] RFC 5024 ODETTE FTP 2 November 2007
[20ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3.4. Session Take Down
3.4. セッションは下に取ります。
3.4.1. Normal Close
3.4.1. 近くでは、正常です。
| |
F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND
| |
| | _F_リリースRQ---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_リリース_インディアン座| |
Parameters
パラメタ
Request Indication --------------------------------------------------------------------- reason = normal -------> ---- ---------------------------------------------------------------------
指示を要求してください。--------------------------------------------------------------------- 理由は標準と等しいです。------->。---- ---------------------------------------------------------------------
The Release service can only be initiated by the Speaker.
議長はReleaseサービスを開始できるだけです。
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.
求められていないChange Direction指示(_F CD_IND)を受けたすぐ(_F RELEASE_RQ)後に、議長はRelease要求を出すことができるだけです。 これは、もう片方のパートナーがこのセッションのときにそれ以上のファイルを送りたがっていないのを確実にします。
Peer ODETTE-FTP entities action a normal session release by specifying Reason = Normal in an End Session (ESID) command.
通常のセッションがReasonを指定することによってリリースする同輩オデット-FTP実体動作はEnd Sessionの通常(ESID)のコマンドと等しいです。
3.4.2. Abnormal Close
3.4.2. 近くでは、異常です。
| |
F_RELEASE_RQ ---->|------------|----> F_ABORT_IND
| |
| | _F_リリースRQ---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_は_インディアン座を中止します。| |
Parameters
パラメタ
Request Indication
---------------------------------------------------------------------
reason = error value --> same (or equivalent)
AO (Abort Origin) = (L)ocal or (D)istant
---------------------------------------------------------------------
指示を要求してください。--------------------------------------------------------------------- 理由は誤り値と等しいです-->の同じで(同等)のAO(Originを中止する)は(L)ocalか(D)istantと等しいです。---------------------------------------------------------------------
Abnormal session release can be initiated by either the Speaker or the Listener and also by the user or provider.
議長かListenerのどちらかとユーザかプロバイダーは異常なセッションリリースを開始できます。
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.
異常なセッションがReasonを指定することによってリリースする同輩オデット-FTP実体動作はEnd Session(ESID)コマンドにおける誤り値と等しいです。
Friend Informational [Page 21] RFC 5024 ODETTE FTP 2 November 2007
[21ページ]友人の情報のRFC5024オデットFTP2007年11月2日
The abnormal session release deals with the following types of error:
異常なセッションリリースは以下のタイプの誤りに対処します:
1. The service provider will initiate an abnormal release in the
following cases:
1. サービスプロバイダーは以下の場合における異常なリリースを開始するでしょう:
1. Protocol error.
2. Failure of the Start Session (SSID) negotiation.
3. Command not recognised.
4. Data Exchange Buffer size error.
5. Resources not available.
6. Other unspecified abort code (with Reason = unspecified).
1. 誤りについて議定書の中で述べてください。 2. Start Session(SSID)交渉の失敗。 3. 認識されないで、命令してください。 4. データExchange Bufferサイズ誤り。 5. 利用可能でないリソース。 6. 他の不特定のアボートコード(Reason=が不特定の)。
2. The User Monitor will initiate an abnormal release in the
following cases:
2. User Monitorは以下の場合における異常なリリースを開始するでしょう:
1. Local site emergency close down.
2. Resources not available.
3. Other unspecified abort code (with Reason = unspecified).
1. ローカル・サイト非常時は休業します。 2. 利用可能でないリソース。 3. 他の不特定のアボートコード(Reason=が不特定の)。
Other error types may be handled by an abort of the connection.
他の誤りタイプは接続のアボートで扱われるかもしれません。
3.4.3. Abort
3.4.3. アボート
| |
F_ABORT_RQ ---->|------------|----> F_ABORT_IND
| |
User-Initiated Abort
| | F_は_RQを中止します。---->|、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-->F_は_インディアン座を中止します。| | ユーザによって開始されたアボート
| |
F_ABORT_IND <----|------------|----> F_ABORT_IND
| |
Provider-Initiated Abort
| | F_は_インディアン座<を中止します。----|------------|---->F_は_インディアン座を中止します。| | プロバイダーで開始しているアボート
Parameters
パラメタ
Request Indication --------------------------------------------------------------------- -- R (Reason): specified or unspecified -- AO (Abort Origin): (L)ocal or (D)istant ---------------------------------------------------------------------
指示を要求してください。--------------------------------------------------------------------- -- R(理由): 指定されるか不特定--、AO(Originを中止します): (L)(D) ocalかistant---------------------------------------------------------------------
The Abort service may be invoked by either entity at any time.
Abortサービスはいつでも、どちらの実体によっても呼び出されるかもしれません。
The service provider may initiate an abort in case of error detection.
サービスプロバイダーは誤り検出の場合にアボートを開始するかもしれません。
Friend Informational [Page 22] RFC 5024 ODETTE FTP 2 November 2007
[22ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3.4.4. Explanation of Session Take Down Services
3.4.4. サービスの下側へのセッション撮影に関する説明
User | OFTP | Network | OFTP | User
---------------|------|----------------------|------|---------------
| | | |
ユーザ| OFTP| ネットワーク| OFTP| ユーザ---------------|------|----------------------|------|--------------- | | | |
1. Normal Release
1. 通常のリリース
F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND
*--------------|-> ==|======================|=> --|-------------->
(R=normal) | | | |
_F_リリースRQ| | ESID(Rは標準と等しいです)| | F_リリース_インディアン座*--------------|->=|======================|=>--|-------------->(Rは標準と等しいです)| | | |
2. User-Initiated Abnormal Release
2. ユーザによって開始された異常なリリース
F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND
*--------------|-> ==|======================|=> -|-------------->
(R=error value)| | | | (R=error,AO=D)
_F_リリースRQ| | ESID(Rは誤りと等しいです)| | F_は_インディアン座*を中止します。--------------|->=|======================|=>、-|-------------->(Rは誤り値と等しいです)| | | | (誤り、R=AO=D)
3. Provider-Initiated Abnormal Release
3. プロバイダーで開始している異常なリリース
F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND
<--------------|-* *=|======================|=> --|-------------->
| | | |
F_は_インディアン座を中止します。| | ESID(Rは誤りと等しいです)| | F_は_インディアン座<を中止します。--------------|-* *=|======================|=>--|、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|
4. User-Initiated Connection Abort
4. ユーザによって開始された接続アボート
F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND
*--------------|-> --|--------->..----------|-> --|-------------->
| | N_DISC_IND | | (R=unsp.,AO=D)
F_は_RQを中止します。| | N_ディスク_RQ| | F_は_インディアン座*を中止します。--------------|->--|--------->。----------|->--|、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| N_ディスク_インディアン座| | (R=unsp、AO=D)
5. Provider-Initiated Connection Abort
5. プロバイダーで開始している接続アボート
F_ABORT_IND | | N_DISC_RQ | | F_ABORT_IND
<--------------|-* *-|--------->..----------|-> --|-------------->
(R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D)
F_は_インディアン座を中止します。| | N_ディスク_RQ| | F_は_インディアン座<を中止します。--------------|-* *-|--------->。----------|->--|-------------->(AO=L、Rは誤りと等しいです)| | N_ディスク_インディアン座| | (R=unsp、AO=D)
Key: * Origin of command flow
F_ ---> File Transfer Service primitive
N_ ---> Network Service primitive
===> ODETTE-FTP (OFTP) protocol message
キー: * コマンド流れF_の発生源--->ファイルのTransfer Serviceの原始のN_--->ネットワークService原始的です。===>オデット-FTP(OFTP)プロトコルメッセージ
3.5. Service State Automata
3.5. サービス州のオートマトン
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.
これらの州のオートマトンはUser Monitorによって見られるサービスを定義します。 状態遷移を引き起こすイベントが適切であるところに小文字と結果として起こる動作で大文字で示されます。
Friend Informational [Page 23] RFC 5024 ODETTE FTP 2 November 2007
[23ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3.5.1. Idle State Diagram
3.5.1. 使用されていない州のダイヤグラム
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 決定| | f_は_ind+を接続します。-----------------| 怠けてください。|-----------------+ | F_は_RQを接続します。| (0) | F_は_RSを接続します。| | o------------o | V| o-----------------o | | | | | _I WF_FCONNECTCF| | | | | o--------+--------o | | | | F_は_Cfを接続します。| V V o-----------------o o-----------------o | | | | | 活動していないスピーカー| | 活動していないリスナー| | (1) | | (2) | | 議長を見てください。| | リスナーを見てください。| | 州のダイヤグラム| | 州のダイヤグラム| | | | | o-----------------o o-----------------o
Friend Informational [Page 24] RFC 5024 ODETTE FTP 2 November 2007
[24ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3.5.2. Speaker State Diagram
3.5.2. 議長州のDiagram
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 | 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
Friend Informational [Page 25] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 25] RFC 5024 ODETTE FTP 2 November 2007
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 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)
3.5.3 Listener State Diagram
3.5.3 Listener State Diagram
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 | |
| |<-----------------------------| |
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 | | | |<-----------------------------| |
Friend Informational [Page 26] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 26] RFC 5024 ODETTE FTP 2 November 2007
| | 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
| | 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
Predicates: P1: Decision to send F_START_FILE_RS(+) P2: Decision to send F_CLOSE_FILE_RS(+) P3: Decision to become Speaker
Friend Informational [Page 27] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 27] RFC 5024 ODETTE FTP 2 November 2007
4. Protocol Specification
4. Protocol Specification
4.1. Overview
4.1. Overview
ODETTE-FTP is divided into five operating phases.
ODETTE-FTP is divided into five operating phases.
Start Session
Start File
Data Transfer
End File
End Session
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.
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 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 peers communicate by sending and receiving messages in Exchange Buffers via the Network Service. Each Exchange Buffer contains one of the following commands.
SSRM Start Session Ready Message
SSID Start Session
SECD Security Change Direction
AUCH Authentication Challenge
AURP Authentication Response
SFID Start File
SFPA Start File Positive Answer
SFNA Start File Negative Answer
DATA Data
CDT Set Credit
EFID End File
EFPA End File Positive Answer
EFNA End File Negative Answer
ESID End Session
CD Change Direction
EERP End to End Response
NERP Negative End Response
RTR Ready To Receive
SSRM Start Session Ready 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
The remainder of this section describes the protocol flows. Section five details the command formats.
The remainder of this section describes the protocol flows. Section five details the command formats.
4.2. Start Session Phase
4.2. Start Session Phase
The Start Session phase is entered immediately after the network connection has been established.
The Start Session phase is entered immediately after the network connection has been established.
Friend Informational [Page 28] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 28] RFC 5024 ODETTE FTP 2 November 2007
4.2.1. Entity Definition
4.2.1. Entity Definition
The ODETTE-FTP entity that took the initiative to establish the network connection becomes the Initiator. Its peer becomes the Responder.
The ODETTE-FTP entity that took the initiative to establish the network connection becomes the Initiator. Its peer becomes the Responder.
4.2.2. Protocol Sequence
4.2.2. Protocol Sequence
The first message must be sent by the Responder.
The first message must be sent by the Responder.
1. Initiator <-------------SSRM -- Responder Ready Message
-- SSID ------------> Identification
<------------ SSID -- Identification
1. Initiator <-------------SSRM -- Responder Ready Message -- SSID ------------> Identification <------------ SSID -- Identification
4.2.3. Secure Authentication
4.2.3. Secure Authentication
Having exchanged SSIDs, the Initiator may optionally begin an authentication phase, in which each party proves its identity to the other.
Having exchanged SSIDs, the Initiator may optionally begin an authentication phase, in which each party proves its identity to the other.
4.2.4. Protocol Sequence
4.2.4. Protocol Sequence
The first authentication message must be sent by the Initiator.
The first authentication message must be sent by the Initiator.
1. Initiator -- SECD ------------> Responder Change Direction
<------------ AUCH -- Challenge
-- AURP ------------> Response
<------------ SECD -- Change Direction
-- AUCH ------------> Challenge
<------------ AURP -- Response
1. 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).
The Initiator sends a Security Change Direction (SECD) to which the Responder replies with an Authentication Challenge (AUCH).
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.
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.
The Initiator decrypts the challenge using their private key and sends the decrypted challenge back to the Responder in the Authentication Response (AURP).
The Initiator decrypts the challenge using their private key and sends the decrypted challenge back to the Responder in the Authentication Response (AURP).
The Responder checks that the data received in the AURP matches the random challenge that was sent to the Initiator.
The Responder checks that the data received in the AURP matches the random challenge that was sent to the Initiator.
Friend Informational [Page 29] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 29] RFC 5024 ODETTE FTP 2 November 2007
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.
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.
4.3. Start File Phase
4.3. Start File Phase
4.3.1. Entity Definition
4.3.1. Entity Definition
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.
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.
4.3.2. Protocol Sequence
4.3.2. Protocol Sequence
1. Speaker -- SFID ------------> Listener Start File
<------------ SFPA -- Answer YES
1. Speaker -- SFID ------------> Listener Start File <------------ SFPA -- Answer YES
2. Speaker -- SFID ------------> Listener Start File
<------------ SFNA -- Answer NO
Go To 1
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.
Note: The User Monitor should take steps to prevent a loop situation occurring.
2. Speaker -- CD --------------> Listener Change Direction
Listener <------------ EERP -- Speaker End to End Response
-- RTR -------------> Ready to Receive
<------------ NERP -- Negative End Response
-- RTR -------------> Ready to Receive
<------------ SFID -- Start File
2. 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
4.3.3. Restart Facilities
4.3.3. Restart Facilities
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.
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.
4.3.4. Broadcast Facilities
4.3.4. Broadcast Facilities
The destination in a Start File command can be specified as follows.
The destination in a Start File command can be specified as follows.
1. An explicitly defined destination.
1. An explicitly defined destination.
2. A group destination that allows an intermediate location to
broadcast the Virtual File to multiple destinations.
2. A group destination that allows an intermediate location to broadcast the Virtual File to multiple destinations.
Friend Informational [Page 30] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 30] RFC 5024 ODETTE FTP 2 November 2007
The Listener will send a negative answer to the Speaker when the destination is not known.
The Listener will send a negative answer to the Speaker when the destination is not known.
4.3.5. Priority
4.3.5. Priority
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 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.
4.3.6. End to End Response (EERP)
4.3.6. End to End Response (EERP)
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.
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.
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.
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.
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.
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.
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.
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.
Example: Point to Point
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.
Location A sends file Ba to location B, which will send an EERP to location A after it successfully receives the file.
Friend Informational [Page 31] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 31] RFC 5024 ODETTE FTP 2 November 2007
o----------o o-----------o
| Loc. A |----------- S1 ---------->| Loc. B |
| | | |
| [Ba] |<---------- R2 -----------| [Ba] |
+----------o o-----------o
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
Key: S - File Transfer R - Response EERP [Ba] - File for B from A
Example: Data distribution
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.
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.
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
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
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.
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.
Friend Informational [Page 32] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 32] RFC 5024 ODETTE FTP 2 November 2007
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
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
4.3.7. Negative End Response (NERP)
4.3.7. Negative End Response (NERP)
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.
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.
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 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.
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.
The NERP will be sent back to the originator of the file.
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.
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.
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.
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.
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
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
Friend Informational [Page 33] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 33] RFC 5024 ODETTE FTP 2 November 2007
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.
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.
4.3.8. Ready To Receive Command (RTR)
4.3.8. Ready To Receive Command (RTR)
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.
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.
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
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:
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
SFID or CD (if there are no more EERPs or NERPs to be sent)
EERP NERP SFID or CD (if there are no more EERPs or NERPs to be sent)
4.4. Data Transfer Phase
4.4. Data Transfer Phase
Virtual File data flows from the Speaker to the Listener during the Data Transfer phase, which is entered after the Start File phase.
Virtual File data flows from the Speaker to the Listener during the Data Transfer phase, which is entered after the Start File phase.
4.4.1. Protocol Sequence
4.4.1. Protocol Sequence
To avoid congestion at the protocol level, a flow control mechanism is provided via the Set Credit (CDT) command.
To avoid congestion at the protocol level, a flow control mechanism is provided via the Set Credit (CDT) command.
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.
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.
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.
Friend Informational [Page 34] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 34] RFC 5024 ODETTE FTP 2 November 2007
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.
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.
The Listener should endeavour to send the Credit command without delay to prevent the Speaker blocking.
1. Speaker -- SFID ------------> Listener Start File
<------------ SFPA -- Answer YES
1. Speaker -- SFID ------------> Listener Start File <------------ SFPA -- Answer YES
2. If the credit value is set to 2
2. If the credit value is set to 2
Speaker -- Data ------------> Listener Start File
-- Data ------------>
<------------- CDT -- Set Credit
-- Data ------------>
-- EFID ------------> End File
Speaker -- Data ------------> Listener Start File -- Data ------------> <------------- CDT -- Set Credit -- Data ------------> -- EFID ------------> End File
4.5. End File Phase
4.5. End File Phase
4.5.1. Protocol Sequence
4.5.1. Protocol Sequence
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.
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.
1. Speaker -- EFID ------------> Listener End File
<------------ EFPA -- Answer YES
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
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
3. Speaker -- EFID ------------> Listener End File <------------ EFNA -- Answer NO
Friend Informational [Page 35] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 35] RFC 5024 ODETTE FTP 2 November 2007
4.6. End Session Phase
4.6. End Session Phase
4.6.1. Protocol Sequence
4.6.1. Protocol Sequence
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.
議長は、End Session(ESID)にコマンドを送ることによって、セッションを終えます。 Listenerがスピーカーとしてちょうど役割を放棄したところな場合にだけ、議長はこれをするかもしれません。
1. Speaker -- EFID ------------> Listener End File
<------------ EFPA -- Answer YES
-- CD --------------> Change Direction
Listener <------------ ESID -- Speaker End Session
1. 議長--EFID------------>リスナーエンドファイル<。------------ EFPA--はい--CDに答えてください。-------------->変化方向リスナー<。------------ ESID--議長終わりのSession
4.7. Problem Handling
4.7. 問題取り扱い
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.
オデット-FTPは州のマシンによってプロトコル誤りを検出できます、そして、セッションを検出する用途活動タイマは状態を掛けます。 これらのメカニズムはEndからEndコントロールまで別々です。
4.7.1. Protocol Errors
4.7.1. プロトコル誤り
If a protocol error occurs, the session will be terminated and application activity aborted. Both locations enter the IDLE state.
プロトコル誤りが発生すると、セッションは終えられて、アプリケーション活動は中止になられます。 両方の位置はIDLE状態に入ります。
4.7.2. Timers
4.7.2. タイマ
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".
アプリケーションとネットワークから守るには、応答が必要であるすべての状況のために状態、FTPが使用するオデット活動タイマを掛けてください。 期限が切れるなら取られるべきタイマと動作はセクション9、「プロトコル州のマシン」で説明されます。
4.7.3. Clearing Centres
4.7.3. センターをクリアします。
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.
開拓地のセンターの使用は誤りがセンターの中のデータ処理機能の結果、発生する可能性を導入します。 そのような誤りは、直接オデット-FTPか通信ネットワークに関連しないで、したがって、この仕様の範囲の外にあります。
Friend Informational [Page 36] RFC 5024 ODETTE FTP 2 November 2007
[36ページ]友人の情報のRFC5024オデットFTP2007年11月2日
5. Commands and Formats
5. コマンドと形式
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.
オデット-FTP実体はExchange Buffersを通って交信します。 Command Exchange Buffersは以下で説明されます。 仮想のFileデータはData Exchange Buffersで運ばれます。(Data Exchange Buffersはセクション7で説明されます)。
5.1. Conventions
5.1. コンベンション
5.1.1. Representation Unit
5.1.1. 表現ユニット
The basic unit of information is an octet, containing 8 bits.
情報の原単位は8ビットを含む八重奏です。
5.1.2. Values and Characters
5.1.2. 値とキャラクター
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.
Appendix Bによると、ISO646のIRVの7ビットのコード化文字集合[ISO-646]は、[UTF-8]が明らかに分野に対して示されるところを除いて、Command Exchange Buffersの中で定数とストリングをコード化するのに使用されます。
5.2. Commands
5.2. コマンド
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.
Command Exchange Bufferはバッファの始めからのただ一つのコマンドを含んでいます。 コマンドとデータはExchange Bufferの中で決して複雑ではありません。 コマンドを圧縮できません。 完全に必要でないなら、可変長のパラメタは省略されたかもしれません、そして、関連長さのインディケータ分野はゼロにセットしました。
Components:
コンポーネント:
1. Command identifier:
1. 識別子を命令してください:
The first octet of an Exchange Buffer is the Command Identifier
and defines the format of the buffer.
Exchange Bufferの最初の八重奏は、Command Identifierであり、バッファの書式を定義します。
2. Parameter(s):
2. パラメタ(s):
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.
コマンドパラメタはCommand Exchange Bufferの中の分野に保存されます。 可変長の分野が使用されているところでは、ヘッダーフィールドが長さを示していて、それらは先行されています。 明らかに示されるところを除いて、すべての値が必要です。
5.3. Command Formats
5.3. コマンド形式
The ODETTE-FTP commands are described below using the following definitions.
以下の定義を使用する下でオデット-FTPコマンドは説明されます。
Friend Informational [Page 37] RFC 5024 ODETTE FTP 2 November 2007
[37ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Position (Pos)
位置(Pos)
Field offset within the Command Exchange Buffer, relative to a
zero origin.
分野はCommand Exchange Bufferの中でaゼロ発生源に比例して相殺されました。
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:
Stringは以下のセットからの英数字を含んでいます:
The numerals: 0 to 9
The upper case letters: A to Z
The following special set: / - . & ( ) space.
数字: 0、9 大文字アルファベット: 次の特別番組が設定したAからZ: /--. ( ) スペース。
Space is not allowed as an embedded character.
スペースは埋め込まれたキャラクタとして許容されていません。
9(n) - A numeric field of length n octets.
9(n)--長さのn八重奏の数字フィールド。
U(n) - A binary field of length n octets.
U(n)--長さのn八重奏の2進の分野。
Numbers encoded as binary are always unsigned and in
network byte order.
いつも未署名であり、ネットワークバイトオーダーでバイナリーとしてコード化された数。
T(n) - An field of length n octets, encoded using [UTF-8].
T(n)--[UTF-8]を使用することでコード化された長さのn八重奏の分野。
String and alphanumeric fields are always left justified and right
padded with spaces where needed.
ストリングと英数字の野原は正当化されるようにいつも残されました、そして、権利は必要であるところで空間でそっと歩きました。
Numeric fields are always right justified and left padded with
zeros where needed.
数字フィールドはまさしくいつも正当です、そして、左は必要であるところでゼロでそっと歩きました。
Friend Informational [Page 38] RFC 5024 ODETTE FTP 2 November 2007
[38ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Reserved fields should be padded with spaces.
予約された分野は空間で水増しされるべきです。
5.3.1. SSRM - Start Session Ready Message
5.3.1. SSRM--セッションの持ち合わせのメッセージを始めてください。
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
o-------------------------------------------------------------------o | SSRMはセッションの持ち合わせのメッセージを始めます。| | | | セッションフェーズ創始者<を始動してください。---- 応答者| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | SSRMCMD| SSRMは、'私'と命令します。| F X(1)| | 1 | SSRMMSG| 持ち合わせのメッセージで、'オデットFTP準備ができています'。| F X(17)| | 18 | SSRMCR| 復帰| F X(1)| o-------------------------------------------------------------------o
SSRMCMD Command Code Character
SSRMCMDコマンドコードキャラクター
Value: 'I' SSRM Command identifier.
値: 'I'SSRM Command識別子。
SSRMMSG Ready Message String(17)
SSRMMSGの持ち合わせのメッセージストリング(17)
Value: 'ODETTE FTP READY '
値: 'オデットFTP準備ができています'。
SSRMCR Carriage Return Character
SSRMCR復帰文字
Value: Character with hex value '0D' or '8D'.
値: 十六進法値の'0D'か'8D'があるキャラクター。
Friend Informational [Page 39] RFC 5024 ODETTE FTP 2 November 2007
[39ページ]友人の情報のRFC5024オデットFTP2007年11月2日
5.3.2. SSID - Start Session
5.3.2. SSID--スタートセッション
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
o-------------------------------------------------------------------o | SSIDスタートセッション| | | | セッションフェーズ創始者<を始動してください。--->応答者| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | SSIDCMD| SSIDコマンド'X'| F X(1)| | 1 | SSIDLEV| プロトコルリリースレベル| F9(1)| | 2 | SSIDCODE| 創始者の識別コード| V X(25)| | 27 | SSIDPSWD| 創始者のパスワード| V X(8)| | 35 | SSIDSDEB| データ交換バッファサイズ| V9(5)| | 40 | SSIDSR| 能力(S/R/B)を送るか、または受けてください。| F X(1)| | 41 | SSIDCMPR| バッファ圧縮インディケータ(Y/N)| F X(1)| | 42 | SSIDREST| 再開インディケータ(Y/N)| F X(1)| | 43 | SSIDSPEC| 特別な論理インディケータ(Y/N)| F X(1)| | 44 | SSIDCRED| クレジット| V9(3)| | 47 | SSIDAUTH| 安全な認証(Y/N)| F X(1)| | 48 | SSIDRSV1| 予約されます。| F X(4)| | 52 | SSIDUSER| 利用者データ| V X(8)| | 60 | SSIDCR| 復帰| F X(1)| o-------------------------------------------------------------------o
SSIDCMD Command Code
Character
SSIDCMDコマンドコードキャラクター
Value: 'X' SSID Command identifier.
値: 'X'SSID Command識別子。
SSIDLEV Protocol Release Level Numeric(1)
SSIDLEVのプロトコルのリリースの平らな数値(1)
Used to specify the level of the ODETTE-FTP protocol
オデット-FTPプロトコルのレベルを指定するために、使用されます。
Value: '1' for Revision 1.2
'2' for Revision 1.3
'4' for Revision 1.4
'5' for Revision 2.0
値: '1'改正2.0のための改正1.4'5'のための改正1.3'4'のための改正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.
以下に注意してください。 改正1.3を固く守りますが、オデットFile Transfer Protocol1.3(RFC2204)は'1'をリリースレベルに指定します。
Friend Informational [Page 40] RFC 5024 ODETTE FTP 2 November 2007
[40ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
唯一、オデット-FTPセッションのときに参加しながら、Initiator(送付者)を特定します。
It is an application implementation issue to link the
expected [X.509] certificate to the SSIDCODE provided.
それは予想された[X.509]証明書を提供されたSSIDCODEにリンクするアプリケーション導入問題です。
SSIDPSWD Initiator's Password String(8)
SSIDPSWD創始者のパスワードストリング(8)
Key to authenticate the sender. Assigned by bilateral
agreement.
送付者を認証するために、主要です。 二国間条約で、割り当てられます。
SSIDSDEB Data Exchange Buffer Size Numeric(5)
SSIDSDEBデータ交換バッファサイズ数値(5)
Minimum: 128
Maximum: 99999
最小限: 128最大: 99999
The length, in octets, of the largest Data Exchange Buffer
that can be accepted by the location. The length includes
the command octet but does not include the Stream
Transmission Header.
位置で受け入れることができる中で最も大きいData Exchange Bufferの八重奏における長さ。 長さは、コマンド八重奏を含んでいますが、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.
値: 'aps'Locationはファイルを送ることができるだけです。 '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.
隣接している位置がともに指定するなら誤りが発生する、能力を送るか、または受けてください。
Friend Informational [Page 41] RFC 5024 ODETTE FTP 2 November 2007
[41ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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のデータバッファ圧縮と位置は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のファイル圧縮機構と異なっています。(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、'位置は部分的に伝えられたファイルの再開を扱うことができます。 ''位置はファイルを再開できません。
SSIDSPEC Special Logic Indicator Character
SSIDSPECの特別な論理インディケータキャラクター
Value: 'Y' Location can handle Special Logic
'N' Location cannot handle Special Logic
値: '''Y'位置はSpecial Logicを扱うことができます、そして、LocationはSpecial Logicを扱うことができません。
Special Logic is only used if supported by both locations.
両方の位置によってサポートされる場合にだけ、特別なLogicは使用されます。
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.
Special Logic拡張子は、単に非同期なエントリーを通って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.
Credit(CDT)を待たなければならない前に議長によって送られた連続したData Exchange Buffersの数はListenerから命令します。
The credit value is only applied to Data flow in the Data
Transfer phase.
クレジット値はData TransferフェーズにおけるData流動に適用されるだけです。
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.
ListenerからStart File Positive Answer(SFPA)コマンドを受け取るとき、議長の利用可能なクレジットはSSIDCREDに初期化されます。 それのゼロはEnd File(EFID)コマンドで合わせられています。
After negotiation, the smallest size must be selected in
the answer of the Responder, otherwise a protocol error
will abort the session.
交渉の後に、Responderの答えで最も小さいサイズを選択しなければなりません。さもなければ、プロトコル誤りはセッションを中止するでしょう。
Friend Informational [Page 42] RFC 5024 ODETTE FTP 2 November 2007
[42ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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".
ウィンドウサイズm--SSID------------><。------------ SSID--Size nに窓を付けてください、(n、 よりm) 以下に注意してください。 交渉された値は「n」でしょう。
SSIDAUTH Secure Authentication Character
SSIDAUTHの安全な認証キャラクター
Value: 'Y' The location requires secure authentication. 'N' The
location does not require secure authentication.
値: '位置が必要とするY'は認証を保証します。 ''位置は安全な認証を必要としません。
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.
Responderの答えがInitiatorの認証要件に合わせないなら、Initiatorはセッションを中止しなければなりません。
No negotiation of authentication is allowed.
認証の交渉は全く許されていません。
authentication p -- SSID ------------>
<------------ SSID -- authentication q
認証p--SSID------------><。------------ SSID--認証q
p == q -> continue.
p != q -> abort.
q p=->は. 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.
オデット-FTPによって何らかの方法で使用されるかもしれません。 未使用であるなら、それは空間に初期化されるべきです。 二国間条約がデータの意味に関して存在すると予想されます。
SSIDCR Carriage Return Character
SSIDCR復帰文字
Value: Character with hex value '0D' or '8D'.
値: 十六進法値の'0D'か'8D'があるキャラクター。
Friend Informational [Page 43] RFC 5024 ODETTE FTP 2 November 2007
[43ページ]友人の情報のRFC5024オデットFTP2007年11月2日
5.3.3. SFID - Start File
5.3.3. SFID--ファイルを始動してください。
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
o-------------------------------------------------------------------o | SFIDスタートファイル| | | | ファイルPhase議長を始めてください。---->リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | SFIDCMD| SFIDは、'H'と命令します。| F X(1)| | 1 | SFIDDSN| 仮想のファイルデータセット名| V X(26)| | 27 | SFIDRSV1| 予約されます。| F X(3)| | 30 | SFIDDATE| (CCYYMMDD)、仮想のFile Dateは押し込みます。| V9(8)| | 38 | SFIDTIME| (HHMMSScccc)、仮想のFile Timeは押し込みます。| V9(10)| | 48 | SFIDUSER| 利用者データ| V X(8)| | 56 | SFIDDEST| 目的地| V X(25)| | 81 | SFIDORIG| 創始者| V X(25)| | 106 | SFIDFMT| ファイル形式(F/V/U/T)| F X(1)| | 107 | SFIDLRECL| 最大のレコード・サイズ| V9(5)| | 112 | SFIDFSIZ| ファイルSize、Kが妨げる1| V9(13)| | 125 | SFIDOSIZ| オリジナルのFile Size、Kが妨げる1| V9(13)| | 138 | SFIDREST| 再開位置| V9(17)| | 155 | SFIDSEC| セキュリティー・レベル| F9(2)| | 157 | SFIDCIPH| 暗号スイート選択| F9(2)| | 159 | SFIDCOMP| ファイル圧縮アルゴリズム| F9(1)| | 160 | SFIDENV| 形式をおおって、ファイルしてください。| F9(1)| | 161 | SFIDSIGN| EERP要求であると署名されます。| F X(1)| | 162 | SFIDDESCL| 仮想のFile記述の長さ| V9(3)| | 165 | SFIDDESC| 仮想のファイル記述| V T(n)| o-------------------------------------------------------------------o
SFIDCMD Command Code Character
SFIDCMDコマンドコードキャラクター
Value: 'H' SFID Command identifier.
値: 'H'SFID Command識別子。
SFIDDSN Virtual File Dataset Name String(26)
SFIDDSNの仮想のファイルデータセット名前ストリング(26)
Dataset name of the Virtual File being transferred,
assigned by bilateral agreement.
データセット名(二国間条約によって割り当てられて、移されるVirtual File)。
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.
この分野は今後の使用のために予約されます。
Friend Informational [Page 44] RFC 5024 ODETTE FTP 2 November 2007
[44ページ]友人の情報のRFC5024オデットFTP2007年11月2日
SFIDDATE Virtual File Date stamp Numeric(8)
SFIDDATE Virtual File DateはNumericを押し込みます。(8)
Format: 'CCYYMMDD' 8 decimal digits representing the century,
year, month, and day.
形式: 世紀、年、月、および日を表す'CCYYMMDD'8 10進数字。
Date stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
いつファイルをトランスミッションに利用可能にしたかを示すVirtual FileのOriginatorによって割り当てられたスタンプの日付を入れてください。
See Virtual Files - Identification (Section 1.5.2)
仮想のファイルを見てください--、識別(セクション1.5.2)
SFIDTIME Virtual File Time stamp Numeric(10)
SFIDTIME Virtual File TimeはNumericを押し込みます。(10)
Format: 'HHMMSScccc' 10 decimal digits representing hours,
minutes, seconds, and a counter (0001-9999), which gives
higher resolution.
形式: 時間秒を何分も表す'HHMMSScccc'10 10進数字、およびカウンタ(0001-9999)。(そのカウンタは、より高い解像度を与えます)。
Time stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
いつファイルをトランスミッションに利用可能にしたかを示すVirtual FileのOriginatorによって割り当てられたタイムスタンプ。
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.
オデット-FTPによって何らかの方法で使用されるかもしれません。 未使用であるなら、それは空間に初期化されるべきです。 二国間条約がデータの意味に関して存在すると予想されます。
SFIDDEST Destination String(25)
SFIDDEST目的地ストリング(25)
Format: See Identification Code (Section 5.4)
形式: 識別コードを見てください。(セクション5.4)
The Final Recipient of the Virtual File.
仮想のファイルの最終的な受取人。
This is the location that will look into the Virtual File
content and perform mapping functions. It is also the
location that creates the End to End Response (EERP)
command for the received file.
これはVirtual File内容を調べて、マッピング機能を実行する位置です。 また、それは受信されたファイルのためのEnd Response(EERP)コマンドにEndを作成する位置です。
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.
それはトランスミッションのためのデータを作成した(写像されます)位置です。
Friend Informational [Page 45] RFC 5024 ODETTE FTP 2 November 2007
[45ページ]友人の情報のRFC5024オデットFTP2007年11月2日
SFIDFMT File Format Character
SFIDFMTファイル形式キャラクター
Value: 'F' Fixed format binary file
'V' Variable format binary file
'U' Unstructured binary file
'T' Text
値: 'F'固定フォーマットバイナリーファイル'V'Variable形式バイナリーファイル'U'Unstructuredバイナリーファイル'T'Text
Virtual File format. Used to calculate the restart
position (Section 1.5.4).
仮想のFile形式。 再開位置(セクション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 File Format Fieldは元のファイルの書式を示します、そして、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.
1K(1024年の八重奏)のブロックのスペースがOriginator位置で伝えられることになっている実際のVirtual Fileを保存するのが必要です。
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.
このパラメタがVirtual Fileサイズの良い見積りだけを提供することを意図します。
Using 13 digits allows for a maximum file size of
approximately 9.3 PB (petabytes) to be transmitted.
13ケタを使用するのは、およそ9.3PB(ペタバイト)の最大のファイルサイズが伝えられるのを許容します。
Friend Informational [Page 46] RFC 5024 ODETTE FTP 2 November 2007
[46ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
それが署名されて、圧縮される、そして/または、暗号化される前に1K(1024年の八重奏)のブロックのスペースがOriginator位置でオリジナルを保存するのが必要です。
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=File Sizeを送る準備ができている状態でファイルされます。
(b) signing/compression/encryption
(b) 署名/圧縮/暗号化
(c) transmission
SFIDFSIZ = Transmitted File Size
(c) トランスミッションSFIDFSIZ=はFile Sizeを伝えました。
(d) decryption/decompression/verification
(d) 復号化/減圧/検証
(e) received raw data file for in-house applications
SFIDOSIZ = Original File Size
(e) 受信された未加工データはオリジナルの社内のアプリケーションSFIDOSIZ=File Sizeを申し込みます。
The Transmitted File Size at (c) indicates to the receiver
how much storage space is needed to receive the file.
(c)のTransmitted File Sizeは、どのくらいの集積スペースがファイルを受け取るのに必要であるかを受信機に示します。
The Original File Size at (e) indicates to the in-house
application how much storage space is needed to process the
file.
(e)のOriginal File Sizeは、どのくらいの集積スペースがファイルを処理するのに必要であるかを社内のアプリケーションに示します。
Friend Informational [Page 47] RFC 5024 ODETTE FTP 2 November 2007
[47ページ]友人の情報のRFC5024オデットFTP2007年11月2日
SFIDREST Restart Position Numeric(17)
SFIDREST再開位置の数値(17)
Maximum: 99999999999999999
最大: 99999999999999999
Virtual File restart position.
仮想のFileは位置を再開します。
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'.
カウントが表す、: - SSIDFMTが'F'か'V'であるならNumberを記録してください。 - SFIDFMTが'U'か'T'であるなら1Kにおけるオフセット(1024年の八重奏)のブロックをファイルしてください。
The count will express the transmitted user data (i.e.,
before ODETTE-FTP buffer compression, header not included).
カウントは伝えられた利用者データ(すなわち、オデット-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.のように、ファイルは再開の目的のために形式Uとして扱われるべきです、SFIDFMTの実価にかかわらず。
SFIDSEC Security Level Numeric(2)
SFIDSECセキュリティー・レベル数値(2)
Value: '00' No security services
'01' Encrypted
'02' Signed
'03' Encrypted and signed
値: '00'セキュリティー・サービスでない'01'Encrypted'02'Signed'03'Encryptedであって署名されます。
Indicates whether the file has been signed and/or encrypted
before transmission. (See Section 6.2.)
ファイルがトランスミッションの前に署名される、そして/または、暗号化されたか否かに関係なく、示します。 (セクション6.2を見てください。)
SFIDCIPH Cipher suite selection Numeric(2)
SFIDCIPH Cipherスイート選択Numeric(2)
Value: '00' No security services
'01' See Section 10.2
値: '00'いいえセキュリティー・サービス'01'Seeセクション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.
署名しているEERPかNERPが要求されているときファイルを署名する、そして/または、暗号化して、また、使用されるべきである暗号スイートを示すのに使用される暗号スイートを示します。
Friend Informational [Page 48] RFC 5024 ODETTE FTP 2 November 2007
[48ページ]友人の情報のRFC5024オデットFTP2007年11月2日
SFIDCOMP File compression algorithm Numeric(1)
SFIDCOMP File圧縮アルゴリズムNumeric(1)
Value: '0' No compression
'1' Compressed with [ZLIB] algorithm
値: '0'[ZLIB]アルゴリズムがある圧縮がない'1'Compressed
Indicates the algorithm used to compress the file.
(See Section 6.4.)
アルゴリズムが以前はよくファイルを圧縮していたのを示します。 (セクション6.4を見てください。)
SFIDENV File enveloping format Numeric(1)
形式NumericをおおうSFIDENV File(1)
Value: '0' No envelope
'1' File is enveloped using [CMS]
値: '0'封筒がない'1'Fileはおおわれた使用です。[cm]
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 Signed EERPはキャラクターを要求します。
Value: 'Y' The EERP returned in acknowledgement of the file
must be signed
'N' The EERP must not be signed
値: '''EERPがファイルを承認して返したY'に署名しなければなりません、そして、EERPは署名されてはいけません。
Requests whether the EERP returned for the file must be
signed.
EERPがファイルのために戻ったか否かに関係なく、要求に署名しなければなりません。
SFIDDESCL Virtual File Description length Numeric(3)
SFIDDESCL Virtual File記述の長さのNumeric(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.
オデット-FTPによって何らかの方法で使用されるかもしれません。 使用されないなら、SFIDDESCLはゼロに用意ができるべきです。
No general structure is defined for this attribute, but it
is expected that a bilateral agreement exists as to the
meaning of the data.
一般構造体は全くこの属性のために定義されませんが、二国間条約がデータの意味に関して存在すると予想されます。
It is encoded using [UTF-8] to support a range of national
languages.
それは、さまざまな国語をサポートするのに[UTF-8]を使用することでコード化されます。
Maximum length of the encoded value is 999 octets.
コード化された価値の最大の長さは999の八重奏です。
Friend Informational [Page 49] RFC 5024 ODETTE FTP 2 November 2007
[49ページ]友人の情報のRFC5024オデットFTP2007年11月2日
5.3.4. SFPA - Start File Positive Answer
5.3.4. SFPA--ファイルの積極的な答えを始めてください。
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
o-------------------------------------------------------------------o | SFPAのスタートのファイルの積極的な答え| | | | ファイルPhase<議長を始動してください。---- リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | SFPACMD| SFPAは、'2'と命令します。| F X(1)| | 1 | SFPAACNT| 答えカウント| V9(17)| o-------------------------------------------------------------------o
SFPACMD Command Code Character
SFPACMDコマンドコードキャラクター
Value: '2' SFPA Command identifier.
値: '2'SFPA Command識別子。
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.
ListenerはStart File(SFID)コマンドで議長によって指定された再開カウントと下側である、または等しい状態でカウントに入らなければなりません。 カウントは受信された利用者データを言い表します。 リスタート機能が利用可能でないなら、ゼロのカウントを指定しなければなりません。
5.3.5. SFNA - Start File Negative Answer
5.3.5. SFNA--ファイル否定的な返答を始めてください。
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
o-------------------------------------------------------------------o | SFNAはファイル否定的な返答を始めます。| | | | ファイルPhase<議長を始動してください。---- リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | SFNACMD| SFNAは、'3'と命令します。| F X(1)| | 1 | SFNAREAS| 答え理由| F9(2)| | 3 | SFNARRTR| 再試行インディケータ、(Y/N)| F X(1)| | 4 | SFNAREASL| 答え理由テキストの長さ| V9(3)| | 7 | SFNAREAST| 答え理由テキスト| V T(n)| o-------------------------------------------------------------------o
SFNACMD Command Code Character
SFNACMDコマンドコードキャラクター
Value: '3' SFNA Command identifier.
値: '3'SFNA Command識別子。
Friend Informational [Page 50] RFC 5024 ODETTE FTP 2 November 2007
[50ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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年'Invalidはカウントを記録します。 '11年'Invalidバイト・カウント。 '12年'Accessメソッドの故障。 '13年'Duplicateはファイルします。 '14年'File方向は拒否しました。 Cipherスイートがサポートしなかった'15年'。 Encryptedファイルが許容しなかった'16年'。 Unencryptedファイルが許容しなかった'17年'。 Compressionが許容しなかった'18年'。 Signedファイルが許容しなかった'19年'。 Unsignedファイルが許容しなかった'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.
値: ''Transmissionを再試行するべきではありません。 '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).
このパラメタはそれが一時的な病態のため後でListenerサイトで再試行されるべきであるよう議長にアドバイスするのに使用されます、ストレージ不足スペースのように。 それはAnswer Reasonコード(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.
無効のファイル名エラーコードは実際のファイルへのVirtual Fileに関するマッピングの問題の結果であるかもしれません。 すぐに、いつもそのような問題を解決できるというわけではありません。 したがって、Retry=YがあるSFNAが受け取られているとき、それはUser Monitorが、その後のセッションのときに関連ファイルを再送するのを試みることが勧められます。
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野原が全く続かないのを示します。
Friend Informational [Page 51] RFC 5024 ODETTE FTP 2 November 2007
[51ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
一般構造体は全くこの属性のために定義されません。
5.3.6. DATA - Data Exchange Buffer
5.3.6. データ--データ交換バッファ
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
o-------------------------------------------------------------------o | データデータ交換バッファ| | | | データ転送段階議長---->リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | DATACMD| 'データが命令する、'であるだろう| F X(1)| | 1 | DATABUF| データExchange Bufferペイロード| V U(n)| o-------------------------------------------------------------------o
DATACMD Command Code Character
DATACMDコマンドコードキャラクター
Value: 'D' DATA Command identifier.
値: ''DATA Command識別子はそうするでしょう。
DATABUF Data Exchange Buffer payload Binary(n)
DATABUF Data Exchange BufferペイロードBinary(n)
Variable-length buffer containing the data payload. The
Data Exchange Buffer is described in Section 7.
データペイロードを入れてある可変長のバッファ。 Data Exchange Bufferはセクション7で説明されます。
5.3.7. CDT - Set Credit
5.3.7. CDT--クレジットを設定してください。
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
o-------------------------------------------------------------------o | CDTはクレジットを設定します。| | | | データ転送段階<議長---- リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | CDTCMD| CDTは、'C'と命令します。| F X(1)| | 1 | CDTRSV1| 予約されます。| F X(2)| o-------------------------------------------------------------------o
CDTCMD Command Code Character
CDTCMDコマンドコードキャラクター
Value: 'C' CDT Command identifier.
値: 'C'CDT Command識別子。
Friend Informational [Page 52] RFC 5024 ODETTE FTP 2 November 2007
[52ページ]友人の情報のRFC5024オデットFTP2007年11月2日
CDTRSV1 Reserved String(2)
CDTRSV1の予約されたストリング(2)
This field is reserved for future use.
この分野は今後の使用のために予約されます。
5.3.8. EFID - End File
5.3.8. EFID--エンドファイル
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
o-------------------------------------------------------------------o | EFIDエンドファイル| | | | 終わりファイルPhase議長---->リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | EFIDCMD| 'EFIDが命令する、'| F X(1)| | 1 | EFIDRCNT| レコード・カウント| V9(17)| | 18 | EFIDUCNT| 装置台数| V9(17)| o-------------------------------------------------------------------o
EFIDCMD Command Code Character
EFIDCMDコマンドコードキャラクター
Value: 'T' EFID Command identifier.
値: ''EFID Command識別子でない。
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.
SSIDFMT'F'か'V'、正確な記録に関しては、数えてください。 SSIDFMT'U'か'T'、ゼロのために。
The count will express the real size of the file (before
buffer compression, header not included). The total count
is always used, even during restart processing.
カウントはファイル(バッファ圧縮の前に含まれていなかったヘッダー)の本当のサイズを表すでしょう。 総カウントは再開処理の間さえ、いつも使用されます。
EFIDUCNT Unit Count Numeric(17)
EFIDUCNT装置台数数値(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.
カウントはファイルの本当のサイズを表すでしょう。 総カウントは再開処理の間さえ、いつも使用されます。
Friend Informational [Page 53] RFC 5024 ODETTE FTP 2 November 2007
[53ページ]友人の情報のRFC5024オデットFTP2007年11月2日
5.3.9. EFPA - End File Positive Answer
5.3.9. EFPA--ファイルの積極的な答えを終わらせてください。
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
o-------------------------------------------------------------------o | EFPAはファイルの積極的な答えを終わらせます。| | | | 終わりファイルPhase<議長---- リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | EFPACMD| EFPAは、'4'と命令します。| F X(1)| | 1 | EFPACD| 変化方向インディケータ、(Y/N)| F X(1)| o-------------------------------------------------------------------o
EFPACMD Command Code Character
EFPACMDコマンドコードキャラクター
Value: '4' EFPA Command identifier.
値: '4'EFPA Command識別子。
EFPACD Change Direction Indicator Character
EFPACD変化方向インディケータキャラクター
Value: 'N' Change direction not requested.
'Y' Change direction requested.
値: ''要求されなかったChange方向。 要求された'Y'変化方向。
This parameter allows the Listener to request a Change
Direction (CD) command from the Speaker.
このパラメタで、Listenerは議長からChange Direction(CD)コマンドを要求できます。
5.3.10. EFNA - End File Negative Answer
5.3.10. EFNA--ファイル否定的な返答を終わらせてください。
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
o-------------------------------------------------------------------o | EFNAはファイル否定的な返答を終わらせます。| | | | 終わりファイルPhase<議長---- リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | EFNACMD| EFNAは、'5'と命令します。| F X(1)| | 1 | EFNAREAS| 答え理由| F9(2)| | 3 | EFNAREASL| 答え理由テキストの長さ| V9(3)| | 6 | EFNAREAST| 答え理由テキスト| V T(n)| o-------------------------------------------------------------------o
EFNACMD Command Code Character
EFNACMDコマンドコードキャラクター
Value: '5' EFNA Command identifier.
値: '5'EFNA Command識別子。
Friend Informational [Page 54] RFC 5024 ODETTE FTP 2 November 2007
[54ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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年'Invalidはカウントを記録します。 '11年'Invalidバイト・カウント。 '12年'Accessメソッドの故障。 '13年'Duplicateはファイルします。 '14年'File方向は拒否しました。 Cipherスイートがサポートしなかった'15年'。 Encryptedファイルが許容しなかった'16年'。 Unencryptedファイルが許容しなかった'17年'。 Compressionが許容しなかった'18年'。 Signedファイルが許容しなかった'19年'。 Unsignedファイルが許容しなかった'20年'。 '21年'Invalidは署名をファイルします。 '22年'File復号化の故障。 '23年'File減圧の故障。 '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.
一般構造体は全くこの属性のために定義されません。
Friend Informational [Page 55] RFC 5024 ODETTE FTP 2 November 2007
[55ページ]友人の情報のRFC5024オデットFTP2007年11月2日
5.3.11. ESID - End Session
5.3.11. ESID--終わりのセッション
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
o-------------------------------------------------------------------o | ESID終わりのセッション| | | | 終わりセッションPhase議長---->リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | ESIDCMD| ESIDは、'F'と命令します。| F X(1)| | 1 | ESIDREAS| 理由コード| F9(2)| | 3 | ESIDREASL| 理由テキストの長さ| V9(3)| | 6 | ESIDREAST| 理由テキスト| V T(n)| | | ESIDCR| 復帰| F X(1)| o-------------------------------------------------------------------o
ESIDCMD Command Code Character
ESIDCMDコマンドコードキャラクター
Value: 'F' ESID Command identifier.
値: 'F'ESID Command識別子。
ESIDREAS Reason Code Numeric(2)
ESIDREAS理由コード数値(2)
Value: '00' Normal session termination
値: '00'通常のセッション終了
'01' Command not recognised
'01'認識されなかったコマンド
An Exchange Buffer contains an invalid command code
(1st octet of the buffer).
Exchange Bufferは無効のコマンドコード(バッファの最初の八重奏)を含んでいます。
'02' Protocol violation
'02'プロトコル違反
An Exchange Buffer contains an invalid command for
the current state of the receiver.
Exchange Bufferは受信機の現状のための無効のコマンドを含んでいます。
'03' User code not known
'03'知られないユーザコード
A Start Session (SSID) command contains an unknown or
invalid Identification Code.
Start Session(SSID)コマンドは未知の、または、無効のIdentification Codeを含んでいます。
'04' Invalid password
'無効の'04パスワード
A Start Session (SSID) command contained an invalid
password.
Start Session(SSID)コマンドは無効のパスワードを含みました。
'05' Local site emergency close down
'05'ローカル・サイト非常時は休業します。
The local site has entered an emergency close down
mode. Communications are being forcibly terminated.
ローカル・サイトはモードで近くに非常時を入れました。 コミュニケーションは強制的に終えられています。
Friend Informational [Page 56] RFC 5024 ODETTE FTP 2 November 2007
[56ページ]友人の情報のRFC5024オデットFTP2007年11月2日
'06' Command contained invalid data
'06'コマンドは無効のデータを含みました。
A field within a Command Exchange Buffer contains
invalid data.
Command Exchange Bufferの中の分野は無効のデータを含んでいます。
'07' Exchange Buffer size error
'07'交換Bufferサイズ誤り
The length of the Exchange Buffer as determined by
the Stream Transmission Header differs from the
length implied by the Command Code.
Stream Transmission Headerで同じくらい断固としたExchange Bufferの長さは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年'Modeか両立しない能力
'11' Invalid challenge response
'11年'Invalidチャレンジレスポンス
'12' Secure authentication requirements incompatible
両立しない'12年'Secure認証要件
'99' Unspecified Abort code
'99'不特定のAbortコード
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.
一般構造体は全くこの属性のために定義されません。
Friend Informational [Page 57] RFC 5024 ODETTE FTP 2 November 2007
[57ページ]友人の情報のRFC5024オデットFTP2007年11月2日
ESIDCR Carriage Return Character
ESIDCR復帰文字
Value: Character with hex value '0D' or '8D'.
値: 十六進法値の'0D'か'8D'があるキャラクター。
5.3.12. CD - Change Direction
5.3.12. CD--変化方向
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
o-------------------------------------------------------------------o | CD変化方向| | | | ファイルPhase議長を始めてください。---->リスナー| | 終わりファイルPhase議長---->リスナー| | 終わりのセッションフェーズ創始者<。--->応答者| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | CDCMD| CDコマンド、'R'| F X(1)| o-------------------------------------------------------------------o
CDCMD Command Code Character
CDCMDコマンドコードキャラクター
Value: 'R' CD Command identifier.
値: 'R'CD Command識別子。
5.3.13. EERP - End to End Response
5.3.13. EERP--終わって、応答を終わらせてください。
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
o-------------------------------------------------------------------o | EERPは、応答を終わらせるために終わります。| | | | ファイルPhase議長を始めてください。---->リスナー| | 終わりファイルPhase議長---->リスナー| |-------------------------------------------------------------------| | Pos| 分野| 記述| 形式| |-----+-----------+---------------------------------------+---------| | 0 | EERPCMD| EERPは、'E'と命令します。| F X(1)| | 1 | EERPDSN| 仮想のファイルデータセット名| V X(26)| | 27 | EERPRSV1| 予約されます。| F X(3)| | 30 | EERPDATE| (CCYYMMDD)、仮想のFile Dateは押し込みます。| V9(8)| | 38 | EERPTIME| (HHMMSScccc)、仮想のFile Timeは押し込みます。| V9(10)| | 48 | EERPUSER| 利用者データ| V X(8)| | 56 | EERPDEST| 目的地| V X(25)| | 81 | EERPORIG| 創始者| V X(25)| | 106 | EERPHSHL| 仮想のFileハッシュの長さ| V U(2)| | 108 | EERPHSH| 仮想のFileハッシュ| V U(n)| | | EERPSIGL| EERP署名の長さ| V U(2)| | | EERPSIG| EERP署名| V U(n)| o-------------------------------------------------------------------o
Friend Informational [Page 58] RFC 5024 ODETTE FTP 2 November 2007
[58ページ]友人の情報のRFC5024オデットFTP2007年11月2日
EERPCMD Command Code Character
EERPCMDコマンドコードキャラクター
Value: 'E' EERP Command identifier.
値: 'E'EERP Command識別子。
EERPDSN Virtual File Dataset Name String(26)
EERPDSNの仮想のファイルデータセット名前ストリング(26)
Dataset name of the Virtual File being transferred,
assigned by bilateral agreement.
データセット名(二国間条約によって割り当てられて、移されるVirtual File)。
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 Virtual File DateはNumericを押し込みます。(8)
Format: 'CCYYMMDD' 8 decimal digits representing the century,
year, month, and day, respectively.
形式: それぞれ世紀、年、月、および日を表す'CCYYMMDD'8 10進数字。
Date stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
いつファイルをトランスミッションに利用可能にしたかを示すVirtual FileのOriginatorによって割り当てられたスタンプの日付を入れてください。
See Virtual Files - Identification (Section 1.5.2)
仮想のファイルを見てください--、識別(セクション1.5.2)
EERPTIME Virtual File Time stamp Numeric(10)
EERPTIME Virtual File TimeはNumericを押し込みます。(10)
Format: 'HHMMSScccc' 10 decimal digits representing hours,
minutes, seconds, and a counter (0001-9999), which gives
higher resolution.
形式: 時間秒を何分も表す'HHMMSScccc'10 10進数字、およびカウンタ(0001-9999)。(そのカウンタは、より高い解像度を与えます)。
Time stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
いつファイルをトランスミッションに利用可能にしたかを示すVirtual FileのOriginatorによって割り当てられたタイムスタンプ。
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.
オデット-FTPによって何らかの方法で使用されるかもしれません。 未使用であるなら、それは空間に初期化されるべきです。 二国間条約がデータの意味に関して存在すると予想されます。
Friend Informational [Page 59] RFC 5024 ODETTE FTP 2 November 2007
[59ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
これはVirtual File内容を調べて、それに従って、それを処理する位置です。 また、それは受信されたファイルのためにEERPを作成する位置です。
EERPHSHL Virtual File hash length Binary(2)
EERPHSHL Virtual Fileハッシュの長さのBinary(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の2進の値は、どんなハッシュも存在していないのを示します。 EERPが署名されないなら、いつもこれはそうです。
EERPHSH Virtual File hash Binary(n)
EERPHSH Virtual FileハッシュBinary(n)
Hash of the transmitted Virtual File, i.e., not the hash of
the original file.
すなわち、伝えられたVirtual 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署名の長さのBinary(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が署名されたのを示します。
Friend Informational [Page 60] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 60] RFC 5024 ODETTE FTP 2 November 2007
EERPSIG EERP signature Binary(n)
EERPSIG EERP signature Binary(n)
Contains the [CMS] enveloped signature of the EERP.
Contains the [CMS] enveloped signature of the EERP.
Signature = Sign{EERPDSN
EERPDATE
EERPTIME
EERPDEST
EERPORIG
EERPHSH}
Signature = Sign{EERPDSN EERPDATE EERPTIME EERPDEST EERPORIG EERPHSH}
Each field is taken in its entirety, including any padding.
The envelope must contain the original data, not just the
signature.
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.
The [CMS] content type used is SignedData.
The encapsulated content type used is id-data.
The encapsulated content type used is id-data.
It is an application issue to validate the signature with
the contents of the EERP.
It is an application issue to validate the signature with the contents of the EERP.
5.3.14. NERP - Negative End Response
5.3.14. NERP - Negative End Response
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
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
Friend Informational [Page 61] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 61] RFC 5024 ODETTE FTP 2 November 2007
NERPCMD Command Code Character
NERPCMD Command Code Character
Value: 'N' NERP Command identifier.
Value: 'N' NERP Command identifier.
NERPDSN Virtual File Dataset Name String(26)
NERPDSN Virtual File Dataset Name String(26)
Dataset name of the Virtual File being transferred,
assigned by bilateral agreement.
Dataset name of the Virtual File being transferred, assigned by bilateral agreement.
No general structure is defined for this attribute.
No general structure is defined for this attribute.
See Virtual Files - Identification (Section 1.5.2)
See Virtual Files - Identification (Section 1.5.2)
NERPRSV1 Reserved String(6)
NERPRSV1 Reserved String(6)
This field is reserved for future use.
This field is reserved for future use.
NERPDATE Virtual File Date stamp Numeric(8)
NERPDATE Virtual File Date stamp Numeric(8)
Format: 'CCYYMMDD' 8 decimal digits representing the century,
year, month, and day, respectively.
Format: 'CCYYMMDD' 8 decimal digits representing the century, year, month, and day, respectively.
Date stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
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)
See Virtual Files - Identification (Section 1.5.2)
NERPTIME Virtual File Time stamp Numeric(10)
NERPTIME Virtual File Time stamp Numeric(10)
Format: 'HHMMSScccc' 10 decimal digits representing hours,
minutes, seconds, and a counter (0001-9999), which gives
higher resolution.
Format: 'HHMMSScccc' 10 decimal digits representing hours, minutes, seconds, and a counter (0001-9999), which gives higher resolution.
Time stamp assigned by the Virtual File's Originator
indicating when the file was made available for
transmission.
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)
See Virtual Files - Identification (Section 1.5.2)
NERPDEST Destination String(25)
NERPDEST Destination String(25)
Format: See Identification Code (Section 5.4)
Format: See Identification Code (Section 5.4)
Originator of the Virtual File.
Originator of the Virtual File.
This is the location that created the data for
transmission.
This is the location that created the data for transmission.
Friend Informational [Page 62] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 62] RFC 5024 ODETTE FTP 2 November 2007
NERPORIG Originator String(25)
NERPORIG Originator String(25)
Format: See Identification Code (Section 5.4)
Format: See Identification Code (Section 5.4)
The Final Recipient of the Virtual File.
The Final Recipient of the Virtual File.
This is the location that will look into the Virtual File
content and perform mapping functions.
This is the location that will look into the Virtual File content and perform mapping functions.
NERPCREA Creator of the NERP String(25)
NERPCREA Creator of the NERP String(25)
Format: See Identification Code (Section 5.4)
Format: See Identification Code (Section 5.4)
It is the location that created the NERP.
It is the location that created the NERP.
NERPREAS Reason code Numeric(2)
NERPREAS Reason code Numeric(2)
This attribute will specify why transmission cannot proceed
or why processing of the file failed.
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)" below should be interpreted as "EFNA or SFNA(RETRY=N)" where appropriate.
Value '03' ESID received with reason code '03'
(user code not known)
'04' ESID received with reason code '04'
(invalid password)
'09' ESID received with reason code '99'
(unspecified reason)
'11' SFNA(RETRY=N) received with reason code '01'
(invalid file name)
'12' SFNA(RETRY=N) received with reason code '02'
(invalid destination)
'13' SFNA(RETRY=N) received with reason code '03'
(invalid origin)
'14' SFNA(RETRY=N) received with reason code '04'
(invalid storage record format)
'15' SFNA(RETRY=N) received with reason code '05'
(maximum record length not supported)
'16' SFNA(RETRY=N) received with reason code '06'
(file size too big)
'20' SFNA(RETRY=N) received with reason code '10'
(invalid record count)
'21' SFNA(RETRY=N) received with reason code '11'
(invalid byte count)
'22' SFNA(RETRY=N) received with reason code '12'
(access method failure)
Value '03' ESID 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)
Friend Informational [Page 63] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 63] RFC 5024 ODETTE FTP 2 November 2007
'23' SFNA(RETRY=N) received with reason code '13'
(duplicate file)
'24' SFNA(RETRY=N) received with reason code '14'
(file direction refused)
'25' SFNA(RETRY=N) received with reason code '15'
(cipher suite not supported)
'26' SFNA(RETRY=N) received with reason code '16'
(encrypted file not allowed)
'27' SFNA(RETRY=N) received with reason code '17'
(unencrypted file not allowed)
'28' SFNA(RETRY=N) received with reason code '18'
(compression not allowed)
'29' SFNA(RETRY=N) received with reason code '19'
(signed file not allowed)
'30' SFNA(RETRY=N) received with reason code '20'
(unsigned file not allowed)
'31' File signature not valid.
'32' File decompression failed.
'33' File decryption failed.
'34' File processing failed.
'35' Not delivered to recipient.
'36' Not acknowledged by recipient.
'50' Transmission stopped by the operator.
'90' File size incompatible with recipient's
protocol version.
'99' Unspecified reason.
'23' SFNA(RETRY=N) 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 Reason Text Length Numeric(3)
Length in octets of the field NERPREAST.
Length in octets of the field NERPREAST.
0 indicates that no NERPREAST field follows.
0 indicates that no NERPREAST field follows.
NERPREAST Reason Text [UTF-8](n)
NERPREAST Reason Text [UTF-8](n)
Reason why transmission cannot proceed in plain text.
Reason why transmission cannot proceed in plain text.
It is encoded using [UTF-8].
It is encoded using [UTF-8].
Maximum length of the encoded reason is 999 octets.
Maximum length of the encoded reason is 999 octets.
No general structure is defined for this attribute.
No general structure is defined for this attribute.
Friend Informational [Page 64] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 64] RFC 5024 ODETTE FTP 2 November 2007
NERPHSHL Virtual File hash length Binary(2)
NERPHSHL Virtual File hash length Binary(2)
Length in octets of the field NERPHSH.
Length in octets of the field NERPHSH.
A binary value of 0 indicates that no hash is present.
This is always the case if the NERP is not signed.
A binary value of 0 indicates that no hash is present. This is always the case if the NERP is not signed.
NERPHSH Virtual File hash Binary(n)
NERPHSH Virtual File hash Binary(n)
Hash of the Virtual File being transmitted.
Hash of the Virtual File being transmitted.
The algorithm used is determined by the bilaterally agreed
cipher suite specified in the SFIDCIPH.
The algorithm used is determined by the bilaterally agreed cipher suite specified in the SFIDCIPH.
NERPSIGL NERP Signature length Binary(2)
NERPSIGL NERP Signature length Binary(2)
0 indicates that this NERP has not been signed.
0 indicates that this NERP has not been signed.
Any other value indicates the length of NERPSIG in octets
and indicates that this NERP has been signed.
Any other value indicates the length of NERPSIG in octets and indicates that this NERP has been signed.
NERPSIG NERP Signature Binary(n)
NERPSIG NERP Signature Binary(n)
Contains the [CMS] enveloped signature of the NERP.
Contains the [CMS] enveloped signature of the NERP.
Signature = Sign{NERPDSN
NERPDATE
NERPTIME
NERPDEST
NERPORIG
NERPCREA
NERPHSH}
Signature = Sign{NERPDSN NERPDATE NERPTIME NERPDEST NERPORIG NERPCREA NERPHSH}
Each field is taken in its entirety, including any padding.
The envelope must contain the original data, not just the
signature.
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.
The [CMS] content type used is SignedData.
The encapsulated content type used is id-data.
The encapsulated content type used is id-data.
It is an application issue to validate the signature with
the contents of the NERP.
It is an application issue to validate the signature with the contents of the NERP.
Friend Informational [Page 65] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 65] RFC 5024 ODETTE FTP 2 November 2007
5.3.15. RTR - Ready To Receive
5.3.15. RTR - Ready To Receive
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
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 Command Code Character
Value: 'P' RTR Command identifier.
Value: 'P' RTR Command identifier.
5.3.16. SECD - Security Change Direction
5.3.16. SECD - Security Change Direction
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
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 Command Code Character
Value: 'J' SECD Command identifier.
Value: 'J' SECD Command identifier.
5.3.17. AUCH - Authentication Challenge
5.3.17. AUCH - Authentication Challenge
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
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
Friend Informational [Page 66] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 66] RFC 5024 ODETTE FTP 2 November 2007
AUCHCMD Command Code Character
AUCHCMD Command Code Character
Value: 'A' AUCH Command identifier.
Value: 'A' AUCH Command identifier.
AUCHCHLL Challenge length Binary(2)
AUCHCHLL Challenge length Binary(2)
Indicates the length of AUCHCHAL in octets.
Indicates the length of AUCHCHAL in octets.
The length is expressed as an unsigned binary number using
network byte order.
The length is expressed as an unsigned binary number using network byte order.
AUCHCHAL Challenge Binary(n)
AUCHCHAL Challenge Binary(n)
A [CMS] encrypted 20-byte random number uniquely generated
each time an AUCH is sent.
A [CMS] encrypted 20-byte random number uniquely generated each time an AUCH is sent.
NOTE:
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.
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.
5.3.18. AURP - Authentication Response
5.3.18. AURP - Authentication Response
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
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 Command Code Character
Value: 'S' AURP Command identifier.
Value: 'S' AURP Command identifier.
AURPRSP Response Binary(20)
AURPRSP Response Binary(20)
Contains the decrypted challenge (AUCHCHAL).
Contains the decrypted challenge (AUCHCHAL).
Friend Informational [Page 67] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 67] RFC 5024 ODETTE FTP 2 November 2007
IMPORTANT:
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.
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.
5.4. Identification Code
5.4. Identification Code
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.
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.
The SIO has the following format.
The SIO has the following format.
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
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 Identifier Character
Value: 'O' Indicates ODETTE assigned Organisation Identifier.
Other values may be used for non-ODETTE codes.
Value: 'O' Indicates ODETTE assigned Organisation Identifier. Other values may be used for non-ODETTE codes.
SIOICD International Code Designator String(4)
SIOICD International Code Designator String(4)
A code forming part of the Organisation Identifier.
A code forming part of the Organisation Identifier.
SIOORG Organisation Code String(14)
SIOORG Organisation Code String(14)
A code forming part of the Organisation Identifier. This
field may contain the letters A to Z, the digits 0 to 9,
and space and hyphen characters.
A 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 Computer Subaddress String(6)
A locally assigned address that uniquely identifies a
system within an organisation (defined by an Organisation
Identifier).
A locally assigned address that uniquely identifies a system within an organisation (defined by an Organisation Identifier).
Friend Informational [Page 68] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 68] RFC 5024 ODETTE FTP 2 November 2007
6. File Services
6. File Services
6.1. Overview
6.1. Overview
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 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 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 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:
1. Insert record length indicators (V format files only; see Section
6.5)
2. Sign
3. Compress
4. Encrypt
1. Insert record length indicators (V format files only; see Section 6.5) 2. Sign 3. Compress 4. Encrypt
The cipher suite for the encryption and signing algorithms is assigned by bilateral agreement.
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.
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:
The [CMS] content types used are:
EnvelopedData - Indicates encrypted data CompressedData - Indicates compressed data SignedData - Indicates signed content Data - Indicates unstructured data
EnvelopedData - Indicates encrypted data CompressedData - Indicates compressed data SignedData - Indicates signed content Data - Indicates unstructured data
For signed or encrypted data, the encapsulated content type (eContentType field) is id-data.
For signed or encrypted data, the encapsulated content type (eContentType field) is id-data.
6.2. File Signing
6.2. File Signing
Files that are to be signed are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
Files that are to be signed are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
A file may be signed more than once to ease the changeover between old and new certificates.
A file may be signed more than once to ease the changeover between old and new certificates.
Friend Informational [Page 69] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 69] RFC 5024 ODETTE FTP 2 November 2007
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.
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.
6.3. File Encryption
6.3. File Encryption
Files that are to be encrypted are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
Files that are to be encrypted are enveloped according to the file enveloping format (SFIDENV). Generally, this will be as a [CMS] package.
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.
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.
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.
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.
6.4. File Compression
6.4. File Compression
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.
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.
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.
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.
6.5. V Format Files - Record Lengths
6.5. V Format Files - Record Lengths
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.
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.
Friend Informational [Page 70] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 70] RFC 5024 ODETTE FTP 2 November 2007
This is only applicable to V format files, which themselves are typically only of concern for mainframes.
This is only applicable to V format files, which themselves are typically only of concern for mainframes.
7. ODETTE-FTP Data Exchange Buffer
7. ODETTE-FTP Data Exchange Buffer
7.1. Overview
7.1. Overview
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.
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.
Virtual File records may be of arbitrary length. A simple compression scheme is defined for strings of repeated characters.
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.
An example of the use of the Data Exchange Buffer can be found in Appendix A.
7.2. Data Exchange Buffer Format
7.2. Data Exchange Buffer Format
For transmission of Virtual File records, data is divided into subrecords, each of which is preceded by a 1-octet Subrecord Header.
For transmission of Virtual File records, data is divided into subrecords, each of which is preceded by a 1-octet Subrecord Header.
The Data Exchange Buffer is made up of the initial Command Character followed by pairs of Subrecord Headers and subrecords, as follows.
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-------------------------------------------------------
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'.
The Data Exchange Buffer Command Character, 'D'.
HDR
HDR
A 1-octet Subrecord Header defined as follows:
A 1-octet Subrecord Header defined as follows:
0 1 2 3 4 5 6 7
o-------------------------------o
| E | C | |
| o | F | C O U N T |
| R | | |
o-------------------------------o
0 1 2 3 4 5 6 7 o-------------------------------o | E | C | | | o | F | C O U N T | | R | | | o-------------------------------o
Friend Informational [Page 71] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 71] RFC 5024 ODETTE FTP 2 November 2007
Bits
Bits
0 End of Record Flag
0 End of Record Flag
Set to indicate that the next subrecord is the last
subrecord of the current record.
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.
Unstructured files are transmitted as a single record; in this case, the flag acts as an end-of-file marker.
1 Compression Flag
1 Compression Flag
Set to indicate that the next subrecord is compressed.
Set to indicate that the next subrecord is compressed.
2-7 Subrecord Count
2-7 Subrecord Count
The number of octets in the Virtual File represented by the
next subrecord expressed as a binary value.
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 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.
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.
As 6 bits are available, the next subrecord may represent between 0 and 63 octets of the Virtual File.
7.3. Buffer Filling Rules
7.3. Buffer Filling Rules
A Data Exchange Buffer may be any length up to the value negotiated in the Start Session exchange.
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.
Virtual File records may be concatenated within one Data Exchange Buffer or split across a number of buffers.
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:
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:
1. Truncate the Exchange Buffer, and put the complete subrecord
(preceded by its header octet) in a new Exchange Buffer.
1. Truncate the Exchange Buffer, and put the complete subrecord (preceded by its header octet) in a new Exchange Buffer.
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. 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.
Friend Informational [Page 72] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 72] RFC 5024 ODETTE FTP 2 November 2007
A record of length zero may appear anywhere in the Exchange Buffer.
A record of length zero may appear anywhere in the Exchange Buffer.
A subrecord of length zero may appear anywhere in the record and/or the Exchange Buffer.
A subrecord of length zero may appear anywhere in the record and/or the Exchange Buffer.
8. Stream Transmission Buffer
8. Stream Transmission Buffer
8.1. Introduction
8.1. Introduction
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.
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.
Note: The Stream Transmission Buffer is not used when using ODETTE-
FTP over an X.25 network.
Note: The Stream Transmission Buffer is not used when using ODETTE- FTP over an X.25 network.
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.
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.
The Stream Transmission Buffer is composed of an STH and an OEB.
The Stream Transmission Buffer is composed of an STH and an OEB.
o-----+-----------------+-----+--------------------+-----+------ | STH | OEB | STH | OEB | STH | OEB/ o-----+-----------------+-----+--------------------+-----+----
o-----+-----------------+-----+--------------------+-----+------ | STH | OEB | STH | OEB | STH | OEB/ o-----+-----------------+-----+--------------------+-----+----
STH - Stream Transmission Header
OEB - ODETTE-FTP Exchange Buffer
STH - Stream Transmission Header OEB - ODETTE-FTP Exchange Buffer
8.2. Stream Transmission Header Format
8.2. Stream Transmission Header Format
The Stream Transmission Header is shown below. The fields are transmitted from left to right.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Friend Informational [Page 73] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 73] RFC 5024 ODETTE FTP 2 November 2007
Version
Version
Value: 0001 (binary)
Value: 0001 (binary)
Stream Transmission Header version number.
Stream Transmission Header version number.
Flags
Flags
Value: 0000 (binary)
Value: 0000 (binary)
Reserved for future use.
Reserved for future use.
Length
Length
Range: 5 - 100003 (decimal)
Range: 5 - 100003 (decimal)
The length of the Stream Transmission Buffer (STH+OEB).
The length of the Stream Transmission Buffer (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.
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.
The maximum Exchange Buffer length that can be negotiated is 99999
octets (Section 5.3.2) giving an STB length of 100003.
The maximum Exchange Buffer length that can be negotiated is 99999 octets (Section 5.3.2) giving an STB length of 100003.
The length is expressed as a binary number in network byte order.
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.
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.
9. Protocol State Machine
9. Protocol State Machine
9.1. ODETTE-FTP State Machine
9.1. ODETTE-FTP State Machine
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.
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.
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.
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.
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.
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.
Friend Informational [Page 74] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 74] RFC 5024 ODETTE FTP 2 November 2007
A Transition table contains the following fields:
A Transition table contains the following fields:
Index (I) State transition index.
Index (I) State transition index.
Predicate A list of predicates used to select between different
possible transitions. The predicates are defined in
the Predicate and Action lists.
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.
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.
Events Output events generated by the entity.
Next State The new state of the entity.
Next State The new state of the entity.
9.2. Error Handling
9.2. Error Handling
The receipt of an event in a given state may be invalid for three reasons.
The receipt of an event in a given state may be invalid for three reasons.
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. 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.
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. 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.
3. For all other cases, the event is considered to be a User Error,
denoted "U" in the state tables.
3. For all other cases, the event is considered to be a User Error, denoted "U" in the state tables.
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.
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.
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 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.
Friend Informational [Page 75] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 75] RFC 5024 ODETTE FTP 2 November 2007
9.3. States
9.3. States
The Command Mode is strictly a half-duplex flip-flop mode.
The Command Mode is strictly a half-duplex flip-flop mode.
A_NC_ONLY Responder, Network Connection opened
A_NC_ONLY Responder, Network Connection opened
The Responder has sent its Ready Message (SSRM) and is
waiting for Start Session (SSID) from the Initiator.
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
A_WF_CONRS Responder Waiting for F_CONNECT_RS
The Responder has received the Initiator's Start Session
(SSID) and is waiting for a response (F_CONNECT_RS) from
its User Monitor.
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 stored in WF_CD state
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.
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 Close Input Pending
The Listener has received an End File (EFID) command and
is waiting for the Close File response (F_CLOSE_FILE_RS)
from its User Monitor.
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 Close Out Pending
The Speaker has sent an End File (EFID) command and is
waiting for an End File Answer (EFPA or EFNA).
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 End to End Response stored in WF_CD state
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.
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 Connection IDLE
IDLELI Idle Listener
IDLELI Idle Listener
IDLELICD Idle Listener, F_CD_RQ Received
IDLELICD Idle Listener, F_CD_RQ Received
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.
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.
Friend Informational [Page 76] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 76] RFC 5024 ODETTE FTP 2 November 2007
IDLESP Idle Speaker
IDLESP Idle Speaker
IDLESPCD Idle Speaker, F_CD_IND Sent
IDLESPCD Idle Speaker, F_CD_IND Sent
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.
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 Initiator Waiting for Network Connection
The Initiator has requested a new network connection and
is waiting for a Connection confirmation (N_CON_CF) from
the Network Service.
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 Initiator Waiting for Ready Message
Before sending Start Session (SSID), the Initiator must
wait for a Ready Message (SSRM) from the Responder.
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 Initiator Waiting for SSID
The Initiator has sent a Start Session (SSID) command and
is waiting for Start Session from the Responder.
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
NRSTWFCD Negative End Response stored in WF_CD state
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.
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 Open Input (Data Transfer Phase)
The Listener is waiting for the Speaker to send a Data
Exchange Buffer.
The Listener is waiting for the Speaker to send a Data Exchange Buffer.
OPIP Open Input Pending
OPIP Open Input Pending
The Listener has received a Start File (SFID) command and
is waiting for the Start File response (F_START_FILE_RS)
from its User Monitor.
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 Open Out (Data Transfer Phase)
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.
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.
Friend Informational [Page 77] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 77] RFC 5024 ODETTE FTP 2 November 2007
OPOP Open Out Pending
OPOP Open Out Pending
The Speaker has sent a Start File (SFID) command and is
waiting for a Start File Answer (SFPA or SFNA).
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 Open Out Wait for Credit
The Speaker is waiting for a Set Credit (CDT) command
before sending further Data Exchange buffers.
The Speaker is waiting for a Set Credit (CDT) command before sending further Data Exchange buffers.
RTRP Ready to Receive (RTR) Pending
RTRP Ready to Receive (RTR) Pending
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.
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.
SFSTWFCD Start File Request stored in WF_CD state.
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.
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 Wait for Change Direction
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.
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 Wait for Ready To Receive
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.
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
WF_NDISC Wait for N_DISC_IND
ODETTE-FTP has sent an End Session (ESID) command and is
waiting for a Disconnection indication (N_DISC_IND) from
the Network Service.
ODETTE-FTP 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 Wait for Security Change Direction
The Speaker is expecting a Security Change Direction
(SECD) from the Listener.
The Speaker is expecting a Security Change Direction (SECD) from the Listener.
Friend Informational [Page 78] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 78] RFC 5024 ODETTE FTP 2 November 2007
WF_AUCH Wait for Authentication Challenge
WF_AUCH Wait for Authentication Challenge
The Speaker has sent a Security Change Direction (SECD)
command and must wait for Authentication Challenge (AUCH)
from the Listener.
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 Wait for Authentication Response
The Speaker has sent an Authentication Challenge (AUCH)
command and must wait for Authentication Response (AURP)
from the Listener.
The Speaker has sent an Authentication Challenge (AUCH) command and must wait for Authentication Response (AURP) from the Listener.
9.4. Input Events
9.4. Input Events
User Monitor Input Events (Section 3)
User Monitor Input Events (Section 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)
Network Input Events (Section 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)
Peer ODETTE-FTP Input Events (Section 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 DATA ESID EERP RTR CD CDT SSRM NERP SECD AUCH AURP
Internal Input Events
Internal Input Events
TIME-OUT - Internal ODETTE-FTP timer expires.
TIME-OUT - Internal ODETTE-FTP timer expires.
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.
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.
9.5. Output Events
9.5. Output Events
User Monitor Output Events (Section 3)
User Monitor Output Events (Section 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
Friend Informational [Page 79] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 79] RFC 5024 ODETTE FTP 2 November 2007
Network Output Events (Section 2.2)
Network Output Events (Section 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)
Peer ODETTE-FTP Output Events (Section 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 DATA 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.
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.
9.6. Local Variables
9.6. Local Variables
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.
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.
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
---------------------------------------------------------------------
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 ---------------------------------------------------------------------
Friend Informational [Page 80] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 80] RFC 5024 ODETTE FTP 2 November 2007
9.7. Local Constants
9.7. Local Constants
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.
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.
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
---------------------------------------------------------------------
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 ---------------------------------------------------------------------
Friend Informational [Page 81] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 81] RFC 5024 ODETTE FTP 2 November 2007
9.8. Session Connection State Table
9.8. Session Connection State Table
9.8.1. State Table
9.8.1. State Table
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
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
Friend Informational [Page 82] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 82] RFC 5024 ODETTE FTP 2 November 2007
9.8.2. Transition Table
9.8.2. Transition Table
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
---+-------------------------------------------------------------
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 ---+-------------------------------------------------------------
Friend Informational [Page 83] RFC 5024 ODETTE FTP 2 November 2007
Friend Informational [Page 83] RFC 5024 ODETTE FTP 2 November 2007
9.8.3. Predicates and Actions
9.8.3. Predicates and Actions
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)
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)
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.)
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.)
Predicate P3: C.Cap-init = Initiator
Predicate P3: C.Cap-init = Initiator
Predicate P4: Mode in SSID incompatible with C.Cap-mode
Predicate P4: Mode in SSID incompatible with C.Cap-mode
Predicate P5: V.Caller = Yes
Predicate P5: V.Caller = Yes
Predicate P6: (V.Caller = Yes) AND (AURP.Signature verifies with
V.Challenge)
Predicate P6: (V.Caller = Yes) AND (AURP.Signature verifies with V.Challenge)
Predicate P7: (V.Caller = No) AND (AURP.Signature verifies with
V.Challenge)
Predicate P7: (V.Caller = No) AND (AURP.Signature verifies with V.Challenge)
Predicate P8: V.Authentication = I.SSID.Authentication
Predicate P8: V.Authentication = I.SSID.Authentication
Predicate P9: I.F_CONNECT_RS.Authentication = Yes
Predicate P9: I.F_CONNECT_RS.Authentication = Yes
Predicate P10: O.F_CONNECT_IND.Authentication =
I.F_CONNECT_RS.Authentication
Predicate P10: O.F_CONNECT_IND.Authentication = I.F_CONNECT_RS.Authentication
Predicate P11: V.Authentication = Yes
Predicate P11: V.Authentication = Yes
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 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
Action 2: Start inactivity timer
Action 3: Set parameters in O.SSID = from local variables
Action 3: Set parameters in O.SSID = from local variables
Friend Informational [Page 84] RFC 5024 ODETTE FTP 2 November 2007
[84ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.モード、V.はBuf-サイズに従った圧縮対窓にSSIDからのV.認証=を再開します。
Action 6: Set V.Challenge = A random number unique to the
session
動作6: セッションにユニークなV.Challenge=乱数を設定してください。
9.9. Error and Abort State Table
9.9. 誤りとアボートステートテーブル
9.9.1. State Table
9.9.1. ステートテーブル
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
o--------------------------------------o | | 他の州| | S|------------------------------o | | T| WF_NDISC| | | A|--------------------------o | | | T| I_WF_NC| | | | E|----------------------o | | | | | 怠けてください。| | | | |===========o---+---+---+---| | | タイムアウト| X| X| A| B| | |------------------+---+---+---+---| | E| F_は_RQを中止します。| X| A| X| C| | V|------------------+---+---+---+---| | E| N_RST_インディアン座| X| X| A| D| | N|------------------+---+---+---+---| | T| N_ディスク_インディアン座| X| E| F| G| | |------------------+---+---+---+---| | | 無効のバッファ| X| X| H| I| o--------------------------------------o
Friend Informational [Page 85] RFC 5024 ODETTE FTP 2 November 2007
[85ページ]友人の情報のRFC5024オデットFTP2007年11月2日
9.9.2. Transition Table
9.9.2. 変遷テーブル
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
---------------------------------------------------------------------
I| 次の出力出来事が述べる述部動作==o================================= A| N_ディスク_RQは怠けます。---+----------------------------------------------------------------- B| F_は_インディアン座を中止します。| N_ディスク_RQは怠けます。---+----------------------------------------------------------------- C| RQが空費する1個のN_ディスクの_---+----------------------------------------------------------------- D| 1 N_ディスク_RQ| F_は活動していない状態で_インディアン座を中止します。---+----------------------------------------------------------------- E| F_は活動していない状態で_インディアン座を中止します。---+----------------------------------------------------------------- F| 1 怠けてください。---+----------------------------------------------------------------- G| 1つのF_アボート_インディアン座活動していません。---+----------------------------------------------------------------- H| WF_NDISC---+----------------------------------------------------------------- I| 1、2ESID(R=01)| F_は_インディアン座(R、AO=L)WF_NDISCを中止します。---------------------------------------------------------------------
9.9.3. Predicates and Actions
9.9.3. 述部と動作
Action 1: Stop inactivity timer
動作1: 不活発タイマを止めてください。
Action 2: Start inactivity timer
動作2: 不活発タイマを始動してください。
9.10. Speaker State Table 1
9.10. 議長ステートテーブル1
9.10.1. State Table
9.10.1. ステートテーブル
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_リリース_RQ理由=標準F REL_RQ(間違える)--F_リリース_RQ理由は誤りと等しいです。
o--------------------------------------------------------------------o | | Other States | | |--------------------------------------------------------------o | | | WF_NDISC | | | |----------------------------------------------------------o | | | | OPOWFC | | |
o--------------------------------------------------------------------o | | 他の州| | |--------------------------------------------------------------o | | | WF_NDISC| | | |----------------------------------------------------------o | | | | OPOWFC| | |
Friend Informational [Page 86] RFC 5024 ODETTE FTP 2 November 2007
[86ページ]友人の情報のRFC5024オデットFTP2007年11月2日
| |------------------------------------------------------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
| |------------------------------------------------------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_は_を始動します。| B| B| W| G| W| W| U| U| U| U| U| X| U| | | ファイル_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_データ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(間違えます)| 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
Friend Informational [Page 87] RFC 5024 ODETTE FTP 2 November 2007
[87ページ]友人の情報のRFC5024オデットFTP2007年11月2日
9.10.2. Transition Table
9.10.2. 変遷テーブル
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| 次の出力出来事が述べる述部動作==o================================= A| P5: 1、2、3、18EERP WF_RTR| P5: 1、2、3EERP WF_RTR---+----------------------------------------------------------------- B| P1: UE| P1: 1、2、5SFID OPOP---+----------------------------------------------------------------- C| 1、2ESID(R=02)| F_は_インディアン座(R、AO=L)WF_NDISCを中止します。---+----------------------------------------------------------------- D| 1、2CD IDLELICD---+----------------------------------------------------------------- E| 1、2ESID(R=00)WF_NDISC---+----------------------------------------------------------------- F| 4 ERSTWFCD---+----------------------------------------------------------------- G| P1: UE| P1: 6 SFSTWFCD---+----------------------------------------------------------------- H| 1、2IDLESP---+----------------------------------------------------------------- I| 1、2、10SFID OPOP---+----------------------------------------------------------------- J| 1、2CD IDLELICD---+----------------------------------------------------------------- K| P2: 1、2ESID(R=02)| F_は_インディアン座(R、AO=L)WF_NDISCを中止します。| P2: 1、2、7、12F_スタート_ファイル_Cf(+)OPO---+----------------------------------------------------------------- L| _1、2、8F_スタート_ファイルCf(-)IDLESP---+----------------------------------------------------------------- M| P3: 1、2、11、13データOPOWFC| P3: 1、2、11、13のデータ| _F_データCf OPO---+----------------------------------------------------------------- N| F_RTR_Cf IDLESP---+----------------------------------------------------------------- O| _12Fの_データCf OPO---+----------------------------------------------------------------- P| プロトコル1、2ESID(R=02)| 誤りF_は_インディアン座(R、AO=L)WF_NDISCを中止します。---+----------------------------------------------------------------- Q| 1、2ESID(R) WF_NDISC---+----------------------------------------------------------------- 続けられる--、>。
Friend Informational [Page 88] RFC 5024 ODETTE FTP 2 November 2007
[88ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
---------------------------------------------------------------------
I| 次の出力出来事が述べる述部動作==o================================= R| 1、2、9EERP WF_RTR---+----------------------------------------------------------------- S| WF_NDISC---+----------------------------------------------------------------- T| CDSTWFCD---+----------------------------------------------------------------- U| ユーザ誤りUE---+----------------------------------------------------------------- W| ユーザ誤り--注意1UE---+----------------------------------------------------------------- X| 誤り---+----------------------------------------------------------------- Y| P4とP5: 1、2、15、18NERP WF_RTR| P4とP5: 1、2、15、14NERP WF_RTR| P4とP5: 1、2、15NERP WF_RTR| P4とP5: 1、2、15、14、18NERP WF_RTR---+----------------------------------------------------------------- Z| 16 NRSTWFCD--------------------------------------------------------------------- Z1| P4: 1、2、17NERP WF_RTR| P4: 1、2、17、14NERP WF_RTR---------------------------------------------------------------------
9.10.3. Predicates and Actions
9.10.3. 述部と動作
Predicate P1: (I.F_START_FILE_RQ.Restart-pos > 0 AND V.Restart = No)
OR (V.Mode = Receiver-only)
述部P1: (I.F_スタート_ファイル_RQ.Restart-pos>0AND V.再開=ノー) OR(V.モード=受信機専用)
Note: Restart requested and not supported for this session.
以下に注意してください。 要求されていて、このセッションのために支持されないで、再開してください。
Predicate P2: I.SFPA.Restart-pos > V.Restart-pos
述部P2: I.SFPA.Restart-pos>V.再開-pos
Note: Protocol error due to the restart position in the SFPA
acknowledgement being greater than the position
requested in the SFID request.
以下に注意してください。 SFID要求で要求された位置より大きいSFPA承認における再開位置による誤りについて議定書の中で述べてください。
Predicate P3: V.Credit_S - 1 = 0
述部P3: V.クレジット_S--1 = 0
Note: Speaker's Credit is exhausted.
以下に注意してください。 議長のCreditは消耗しています。
Predicate P4: No special logic is in use
述部P4: どんな特別な論理も使用中ではありません。
Predicate P5: Signed EERP/NERP requested
述部P5: 要求されたサインされたEERP/NERP
Action 1: Stop inactivity timer
動作1: 不活発タイマを止めてください。
Friend Informational [Page 89] RFC 5024 ODETTE FTP 2 November 2007
[89ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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: 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_スタート_ファイル_RQ V.再開-pos=I.F_スタートファイル_RQ.Restart-posからSFIDを造ってください。
Action 6: Store F_START_FILE_RQ in V.Req-buf
動作6: V.Req-bufに_F_スタートファイル_RQを格納してください。
Action 7: Build F_START_FILE_CF(+) from I.SFPA
動作7: I.SFPAからF_始めに_ファイル_Cf(+)を築き上げてください。
Action 8: Build F_START_FILE_CF(-) from I.SFNA
動作8: I.SFNAからF_始めに_ファイル_Cf(-)を築き上げてください。
Action 9: Build EERP from F_EERP_RQ stored in V.Req-buf
動作9: RQがV.Req-bufに格納したF_EERP_からEERPを造ってください。
Action 10: Build SFID from F_START_FILE_RQ stored in V.Req-buf
Set V.Restart-pos
動作10: FILE_RQがV.Req-buf Set V.Restart-posに格納したF_START_からSFIDを造ってください。
Action 11: Build Exchange Buffer
動作11: 交換バッファを造ってください。
Action 12: V.Credit_S = V.Window
動作12: V.クレジット_SはV.の窓と等しいです。
Action 13: V.Credit_S = V.Credit_S - 1
動作13: V.クレジットV.クレジット_S=_S--1
Action 14: Activate CRC-calculus function. Wrap Exchange buffer
in special logic
動作14: CRC-微積分学機能を活性化してください。 Exchangeが特別な論理でバッファリングする包装
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: Req-bufに対して_F NERP_RQを蓄えてください。
Action 17: Build NERP from F_NERP_RQ stored in V.Req-buf
動作17: RQがV.Req-bufに格納したF_NERP_からNERPを造ってください。
Action 18: Sign the contents of NERP/EERP
動作18: NERP/EERPのコンテンツにサインしてください。
Note 1: Whether to accept this "Request/Event" while in this
state is a matter of local implementation. The ODETTE
state tables are based on the assumption that this
event cannot occur in this state and is considered to
be a user error (UE).
注意1: この状態にある間、この「要求/出来事」を受け入れるかどうかが、地方の実現の問題です。 オデットステートテーブルはこの出来事がこの状態に起こることができないで、ユーザ誤り(UE)であると考えられるという仮定に基づいています。
Friend Informational [Page 90] RFC 5024 ODETTE FTP 2 November 2007
[90ページ]友人の情報のRFC5024オデットFTP2007年11月2日
9.11. Speaker State Table 2
9.11. 議長ステートテーブル2
9.11.1. State Table
9.11.1. ステートテーブル
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
o---------------------------------o | S| こつこつという音| | T|-------------------------o | | A| OPOWFC| | | T|---------------------o | | | E| OPO| | | |= = = = = = = = = =はoと等しいです。---+---+---| | E| F_は_ファイル_RQを閉じます。| A| E| U| | V|-----------------+---+---+---| | E| EFPA| B| B| C| | N|-----------------+---+---+---| | T| EFNA| B| B| D| o---------------------------------o
9.11.2. Transition Table
9.11.2. 変遷テーブル
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
---------------------------------------------------------------------
I| 次の出力出来事が述べる述部動作==o================================= A| 1、2、5、7EFIDこつこつという音---+----------------------------------------------------------------- B| 1、2ESID(R=02)| F_は_インディアン座(R、AO=L)WF_NDISCを中止します。---+----------------------------------------------------------------- C| P1: 1、2、3Fの_の近い_ファイル_Cf(+ SPはいいえと等しいです)| CD IDLELI| P1: 1、2、4F_の近い_ファイル_Cf(+ SPははいと等しい)IDLESP---+----------------------------------------------------------------- D| _1、2、6のF_の近い_ファイルCf(-)IDLESP---+----------------------------------------------------------------- E| 注意1を見てください。---+----------------------------------------------------------------- U| ユーザ誤りUE---------------------------------------------------------------------
9.11.3. Predicates and Actions
9.11.3. 述部と動作
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: 不活発タイマを始動してください。
Friend Informational [Page 91] RFC 5024 ODETTE FTP 2 November 2007
[91ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Action 3: O.F_CLOSE_FILE_CF(+).Speaker = No
動作3: O.のF_の近い_ファイル_Cf(+).Speakerはいいえと等しいです。
Action 4: O.F_CLOSE_FILE_CF(+).Speaker = Yes
動作4: O.のF_の近い_ファイル_Cf(+).Speakerははいと等しいです。
Action 5: Build EFID from F_CLOSE_FILE_RQ
動作5: _F近い_ファイル_RQからEFIDを造ってください。
Action 6: Build F_CLOSE_FILE_CF(-) from EFNA
動作6: EFNAからF_の近い_ファイル_Cf(-)を築き上げてください。
Action 7: Set V.Credit_S = 0
動作7: V.クレジット_S=0を設定してください。
Action 8: Wrap Exchange buffer in special logic
動作8: Exchangeが特別な論理でバッファリングする包装
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: OPOWFC状態にある間、オデット-FTPの「半二重」の特性を尊敬するために、EFIDを送るのが禁じられます。 OPO状態だけでEFIDを送ることができます。
The ODETTE-FTP implementation must avoid sending EFID
(or receiving F_CLOSE_FILE_RQ) while in the OPOWFC
state.
OPOWFC状態にある間、オデット-FTP実現は、EFID(F_CLOSE_FILE_RQを受けて)を送るのを避けなければなりません。
Friend Informational [Page 92] RFC 5024 ODETTE FTP 2 November 2007
[92ページ]友人の情報のRFC5024オデットFTP2007年11月2日
9.12. Listener State Table
9.12. リスナーステートテーブル
9.12.1. State Table
9.12.1. ステートテーブル
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
o---------------------------------------------o | | RTRP| | |-------------------------------------o | | | クリップ| | | |---------------------------------o | | | | OPI| | | | S|-----------------------------o | | | | T| OPIP| | | | | A|-------------------------o | | | | | T| IDLELICD| | | | | | E|---------------------o | | | | | | | IDLELI| | | | | | |= = = = = = = = = =はoと等しいです。---+---+---+---+---+---+ | | SFID| A| A| B| B| B| B| | |-----------------+---+---+---+---+---+---+ | E| データ| B| B| B| I| B| B| | V|-----------------+---+---+---+---+---+---+ | E| EFID| B| B| B| J| B| B| | N|-----------------+---+---+---+---+---+---+ | T| F_は_ファイル_RSを始動します。| U| U| H| U| U| U| | |-----------------+---+---+---+---+---+---+ | | F_は_ファイル_RSを閉じます。| U| U| U| U| K| U| | |-----------------+---+---+---+---+---+---+ | | CD| C| B| B| B| B| B| | |-----------------+---+---+---+---+---+---+ | | ESID Rは標準と等しいです。| D| F| D| D| D| D| | |-----------------+---+---+---+---+---+---+ | | ESID Rは誤りと等しいです。| 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
Friend Informational [Page 93] RFC 5024 ODETTE FTP 2 November 2007
[93ページ]友人の情報のRFC5024オデットFTP2007年11月2日
9.12.2. Transition Table
9.12.2. 変遷テーブル
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
I| 次の出力出来事が述べる述部動作==o================================= A| P1: 1、2ESID(R=02)| F_は_インディアン座(R、AO=L)WF_NDISCを中止します。| P1: _1、2、3F_スタート_ファイルインディアン座OPIP---+----------------------------------------------------------------- B| 1、2ESID(R=02)| F_は_インディアン座(R、AO=L)WF_NDISCを中止します。---+----------------------------------------------------------------- C| _1、2F_CDインディアン座IDLESPCD---+----------------------------------------------------------------- D| 1F_アボート_IND(| ESID理由、AO=Dを受けます)| N_ディスク_RQは怠けます。---+----------------------------------------------------------------- E| 1、2、4F_EERP_インディアン座RTRP---+----------------------------------------------------------------- F| 1つのF_リリース_インディアン座| N_ディスク_RQは怠けます。---+----------------------------------------------------------------- H| P4: ユーザ誤りUE| P2、P4、およびP5: 1、2、8SFPA OPI| P2、P4、およびP5: 1、2SFNA IDLELI| P2とP4&P5: 1、2、5、8SFPA OPI| P2とP4&P5: 1、2、5SFNA IDLELI---+----------------------------------------------------------------- I| P6: 1、2ESID(R=02)| F_は_インディアン座(R、A0=L)WF_NDISCを中止します。| P5、P6、およびP7: _1、2、7Fの_データIND(注意1を見る)OPI| P5とP6&P7: 1、2、8F_データ_インディアン座| CDT(注意1を見る)OPI| P5とP6&P8: 1、2ESID(R=07)| F_は_インディアン座(R、A0=L)WF_NDISCを中止します。| P5、P6、およびP7: _1、2、6、7Fの_データIND(注意1を見る)OPI| P8| P5とP6&P7: 1、2、5、6、8F_データ_インディアン座OPI| P8 CDT(注意1を見ます)---+----------------------------------------------------------------- J| 1、2のF_の近い_ファイル_インディアン座クリップ---+----------------------------------------------------------------- K| P2&P3とP5: 1、2EFPA(CD-Req)WF_CD| P2、P3、およびP5: 1、2EFPA(CDがない)IDLELI| P2とP5: 1、2EFNA IDLELI| P2とP3&P5: 1、2、5EFPA(CDがない)IDLELI| P2とP5: 1、2、5EFNA IDLELI| P2&P3とP5: 1、2、5EFPA(CD-Req)WF_CD
Friend Informational [Page 94] RFC 5024 ODETTE FTP 2 November 2007
[94ページ]友人の情報のRFC5024オデットFTP2007年11月2日
---+-----------------------------------------------------------------
L | 1,2,10 F_NERP_IND RTRP
---+-----------------------------------------------------------------
M | 1,2 RTR IDLELI
---+-----------------------------------------------------------------
U | User Error UE
---------------------------------------------------------------------
---+----------------------------------------------------------------- L| 1、2、10F_NERP_インディアン座RTRP---+----------------------------------------------------------------- M| 1、2RTR IDLELI---+----------------------------------------------------------------- U| ユーザ誤りUE---------------------------------------------------------------------
9.12.3. Predicates and Actions
9.12.3. 述部と動作
Predicate P1: (I.SFID.Restart-pos > 0 AND V.Restart = No) OR (V.Mode
= Sender-only)
述部P1: (I.SFID.Restart-pos>0AND V.再開=ノー) OR(V.モード=送付者専用)
Note: Invalid Start File command.
以下に注意してください。 無効のStart Fileは命令します。
Predicate P2: Positive Response
述部P2: 積極的な応答
Predicate P3: I.F_CLOSE_FILE_RS(+).Speaker = Yes
述部P3: I.近い_ファイル_RS(+).Speaker=F_はい
Predicate P4: I.F_START_FILE_RS(+).Restart-pos > V.Restart
述部P4: I.F_スタート_ファイル_RS(+).Restart-pos>V.再開
Predicate P5: Special logic is used
述部P5: 特別な論理は使用されています。
Predicate P6: V.Credit_L - 1 < 0
述部P6: V.クレジット_L--1<0
Note: Protocol Error because the Speaker has exceeded its
available transmission credit.
以下に注意してください。 議長が利用可能なトランスミッションクレジットを超えていたので、Errorについて議定書の中で述べてください。
Predicate P7: V.Credit_L - 1 = 0
述部P7: V.クレジット_L--1 = 0
Note: The Speaker's credit must be reset before it can send
further Data Exchange Buffers.
以下に注意してください。 一層の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.I.SFID V.再開-pos=SFID.Restart-posから_F_スタートファイル_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: 議長に送られるべきコマンドに特別な論理ヘッダーを追加してください。
Friend Informational [Page 95] RFC 5024 ODETTE FTP 2 November 2007
[95ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.クレジットV.クレジット_L=_L--1
Action 8: V.Credit_L = V.Window
動作8: V.クレジット_LはV.の窓と等しいです。
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:
オデット-FTP Listenerは定期的に新しいクレジットを議長に送らなければなりません。 この操作のタイミングは以下に依存するでしょう。
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. データを受け取るUser Monitorの容量。 2. オデット-FTPに利用可能なバッファの数。 3. 議長の利用可能なクレジット。(そのクレジットは、ゼロに合わせるために等しくなければなりません)。
9.13. Example
9.13. 例
Consider an ODETTE-FTP entity that has sent a Start File (SFID) command and entered the Open Out Pending (OPOP) state. Its response on receiving a Positive Answer (SFPA) is documented in Speaker State Table 1, which shows that transition 'K' should be applied and is interpreted as follows:
Start File(SFID)にコマンドを送って、オープンOut Pending(OPOP)状態に入力したオデット-FTP実体を考えてください。 Positive Answer(SFPA)を受けるときの応答は州Table1議長に記録されます:(その議長は、変遷'K'が適用されるべきであり、以下の通り解釈されるのを示します)。
if (I.SFPA.Restart-pos > V.Restart-pos) then
begin // invalid restart
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Output: ESID(R=02), // to peer ODETTE-FTP
F_ABORT_IND(R,AO=L); // to User Monitor
New State: WF_NDISC;
end
else begin
Actions: Stop inactivity timer, // reset timer
Start inactivity timer;
Build F_START_FILE_CF(+) from I.SFPA
V.Credit_S = V.Window // initialise credit
Output: F_START_FILE_CF(+); // to User Monitor
New State: OPO;
end
次に、(I.SFPA.Restart-pos>V.Restart-pos)が//病人を始めるなら、Actionsを再開してください: 不活発タイマ、//リセットタイマStart不活発タイマを止めてください。 出力: ESID(R=02)、_同輩オデット-FTP F ABORT_INDへの//(R、AO=L)。 ユーザのモニターの新しい状態への//: WF_NDISC。 ほかの終わりはActionsを始めます: 不活発タイマ、//リセットタイマStart不活発タイマを止めてください。 _I. SFPA V.Credit_SからのFILE_CF(+)=V.をF_STARTに建ててください。Window//はクレジットOutputを初期化します: F_は_ファイル_Cf(+)を始めます。 ユーザのモニターの新しい状態への//: OPO。 終わり
Friend Informational [Page 96] RFC 5024 ODETTE FTP 2 November 2007
[96ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
オデット-FTPは容認されたStart File Positive Answer(SFPA)コマンドにおける再開位置をチェックします。 無効であるなら、それは、同輩へのEnd Session(ESID)コマンドとUser MonitorへのAbort指示(_F ABORT_IND)を送ることによって、セッションを中止します。 再開位置が有効であるなら、Start File確認(F_START_FILE_CF)をUser Monitorに組み込んで、送ります、そして、クレジットウィンドウを初期化します、そして、オープンOut(OPO)状態を入れます。
10. Miscellaneous
10. その他
10.1. Algorithm Choice
10.1. アルゴリズム選択
The choice of algorithms to use for security or compression between partners is for bilateral agreement outside of ODETTE-FTP.
パートナーの間のセキュリティか圧縮に使用するアルゴリズムの選択は二国間条約のためにオデット-FTPの外にあります。
10.2. Cryptographic Algorithms
10.2. 暗号アルゴリズム
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_エーデ_CBC_3KEY RSA_PKCS1_15SHA-1 02AES_256_CBC RSA_PKCS1_15SHA-1
Support of all cipher suites listed here is mandatory.
ここに記載されたすべての暗号スイートのサポートは義務的です。
The certificates used must be [X.509] certificates.
使用される証明書は[X.509]証明書であるに違いありません。
TripleDES is using Cipher Block Chaining (CBC) mode for added security and uses the Encryption Decryption Encryption (EDE) process with 3 different 64-bit keys.
TripleDESは加えられたセキュリティにCipher Block Chaining(CBC)モードを使用していて、3個の異なった64ビットのキーと共にEncryption Decryption Encryption(EDE)プロセスを使用します。
RSA padding is as defined in [PKCS#1].
RSA詰め物が[PKCS#1]で定義されるようにあります。
AES is using a 256-bit key in CBC mode.
AESはCBCモードで256ビットのキーを使用しています。
An extended list of optional cipher suites may be used (Section 10.3), but there is no guarantee that two communicating ODETTE-FTP entities would both support these optional cipher suites.
任意の暗号スイートの拡張リストは使用されるかもしれませんが(セクション10.3)、2つの交信しているオデット-FTP実体が、これらが任意の暗号スイートであるとともにサポートするだろうという保証が全くありません。
10.3. Protocol Extensions
10.3. プロトコル拡大
The algorithms and file enveloping formats available in ODETTE-FTP may be extended outside of this document.
オデット-FTPで利用可能な形式をおおうアルゴリズムとファイルはこのドキュメントの外で広げられるかもしれません。
Friend Informational [Page 97] RFC 5024 ODETTE FTP 2 November 2007
[97ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
オデット-FTPにおける使用のための暗号スイート値の最新のリストはwww.odette.orgでインターナショナルで、それらのウェブサイトで発行されたオデットによって維持されます。
10.4. Certificate Services
10.4. 証明書サービス
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]ファイルを交換するのは有効です。 それはそのようなファイルを受け取り次第正しい行動を決定するアプリケーション導入問題です。
11. Security Considerations
11. セキュリティ問題
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.
オデット-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.
オデット-FTPで利用可能なセキュリティオプションのすべて、いくつか、またはいずれも使用されないかもしれません。 これらのオプションの使用のための推薦を全くこの仕様に提供しません。 最強力価暗号化アルゴリズムの使用は賞賛に値するように思えるかもしれませんが、作られている性能見返りがしばしばあります、そして、すべてのファイルと承認に調印すると、考えられるべきである可能性のある法的影響は持たれています。
It should be noted that whilst the security measures ensure that an ODETTE-FTP partner is authenticated, it does not necessarily mean that the partner is authorised. Having proven the identity of a partner, it is an application issue to decide whether that partner is allowed to connect or exchange files.
安全策が、オデット-FTPパートナーが認証されるのを確実にしている間必ずパートナーが認可されていることを意味するというわけではないことに注意されるべきです。 パートナーのアイデンティティを立証したので、それは、そのパートナーが接続できるか否かに関係なく、決めるアプリケーション問題か交換ファイルです。
Extracted from [RFC3850]:
[RFC3850]から抽出される:
"When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures have not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it.
「証明書を処理するとき、多くの状況が処理が失敗するかもしれないところにあります。」 ユーザエージェント、セキュリティゲートウェイ、または他のプログラムで処理をするかもしれないので、そのような失敗を扱うどんなただ一つの方法もありません。 失敗を扱うメソッドが記載されているだけではないので、しかしながら、読者は、それらが重要でないと仮定するべきではありません。 正反対は本当です: 証明書がメッセージに有効であって、関連していて、証明可能に、処理ソフトウェアがそれに関してエンドユーザに知らせるために即座の、そして、めぼしい方法を採るはずであるということでないなら。
Friend Informational [Page 98] RFC 5024 ODETTE FTP 2 November 2007
[98ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
証明書An無効のCRLがないかどうかCertificate Revocation List(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."
確かに、チェックが失敗するなら、他のインスタンスが証明書が無効であるかもしれなく、それらを皆、徹底的にチェックして、何をしたらよいかを決めるのが、処理ソフトウェアの責任であるところにあります。 「証明書経路合法化の追加情報に関してRFC3280を見てください。」
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.
パーティーが外国行きの別のファイアウォールからパーティーと交換までの接続をすることができるオデット-FTP手段のプッシュ/牽引力の本質は両方の方向にファイルされます。 接続要求を許容するために、それらのファイアウォールの上に両方のパートナーがポートを開ける必要は全くありません。 1回のパーティーだけが、接続要求を許容する必要があります。
See Section 1.7 for a discussion of the benefits of session security [TLS] versus file security.
セッションセキュリティ[TLS]の利益の議論に関してデータ安全保護に対してセクション1.7を見てください。
Friend Informational [Page 99] RFC 5024 ODETTE FTP 2 November 2007
[99ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
この例はオデット-FTP Data Exchange Buffersの系列にVirtual Fileに関するマッピングを示します。
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]による'古代のMarinerの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?
それは古代のMarinerであり、Andは彼です。3のstoppeth1つ。 「あなたの長さがあごひげときらめきの目を灰色にして、現在のいわれstopp'stがなんじである、私--、」
"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."
「Bridegroomのドアは大きく開かれて、And Iは親類で次です」。 ゲストは会われて、饗宴は設定されます: 「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.
言われていて、彼は彼の痩せぎすの手、「船がいた」と共に彼を保持します。彼。 食い止めてください!「灰色のあごひげ狂人は私を手放してください!」 彼のものが手渡す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.
彼はきらめきの目と共に彼を保持します--Wedding-ゲストが静止していて、Andは3年のように聴きます。 子供: 彼のものが望んでいるMariner hath。
The Wedding-Guest sat on a stone:
He cannot chuse but hear;
And thus spake on that ancient man,
The bright-eyed Mariner.
Wedding-ゲストは石の上に座りました: 彼は、chuseするのではなく、聞くことができます。 その結果、その古代の男性の上のspake、明るい目をしたMariner。
The ship was cheered, the harbour cleared,
Merrily did we drop
Below the kirk, below the hill,
Below the light-house top.
私たちは丘の下でBelow教会Belowを下げました。船は励まされて、港はクリアされました、メリ、軽い家の先端。
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.
以下のExchange Buffersは上記に造られました。 それぞれのトップラインはASCIIコードを表しますが、以下の2つの系列が16進値を与えます。
Note that:
以下のことに注意してください。
. The "D" at the beginning of each Exchange Buffer is the command
code.
. それぞれの交換バッファの始めの「D」はコマンドコードです。
Friend Informational [Page 100] RFC 5024 ODETTE FTP 2 November 2007
[100ページ]友人の情報のRFC5024オデットFTP2007年11月2日
. 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?Itは古代のMarinerです。「そして、彼は3の1つをstoppethします」…4347267266266666672467666720046626627767767626662662767662002472 4F9409301E01E395E40D129E52CDA1E4085034F005480FE50F6048255EDA2290
t?hy long grey beard and glittering eye,..Now wherefore stopp'st
7367266662676726667626662666776766626762004672766766676277677277
4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
t?長い灰色のあごひげときらめきがじっと見るhy現在のいわれstopp'st7367266662676726667626662666776766626762004672766766676277677277 4F890CFE70725902512401E407C944529E70595CDAEF70785256F25034F00734
?thou me?...."The Bridegroom's doors are opened wide,..And I am
2376672663000025662476666766627266677267626766662766620046624266
0F48F50D5FDADA248502294572FFD7304FF2301250F05E5407945CDA1E40901D
なんじ、「私--、」、…Bridegroomのドアは大きく開かれます。そして、私は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
「a?陽気なrは鳴り響きます。」「彼は痩せぎすの手と共に彼を保持します」Ther6372766266777266622000046266667266627676266727666672666620025667 1F204850D5229049EE2DADA8508FC43089D07948089303B9EE9081E4CDA24852
e? was a ship," quoth he..."Hold off! unhand me, grey-beard loon
6327672627667222776762662002466626662276666626622676726667626666
5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE
e?「aは船であった」、言われていて、彼…、」食い止めてください!灰色のあごひげ狂人6327672627667222776762662002466626662276666626622676726667626666 5F07130103890C2015F48085EDA28FC40F66105E81E40D5C07259D251240CFFE、私を手放してください。
!?"..Eftsoons his hand dropt he.....He holds him with his glitte
2320046776667266726666267677266200004626666726662767626672666776
1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445
!?"..Eftsoons、彼の手のdroptな彼…彼は彼のglitte2320046776667266726666267677266200004626666726662767626672666776 1F2DA5643FFE30893081E4042F04085EDADA8508FC43089D07948089307C9445と共に彼を保持します。
r?ing eye--..The Wedding-Guest stood still,..And listens like a
7366626762200566256666662476772776662776662004662667766726666262
2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010
r(ing目)。Wedding-ゲストは静止していました。7366626762200566256666662476772776662776662004662667766726666262 2F9E70595DDDA485075449E7D75534034FF40349CCCDA1E40C9345E30C9B5010のような聴取
t?hree years; child:..The Mariner hath his will.....The Wedding-
7367662766773266666300566246766672667626672766620000566256666662
4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
t?hree数年。 子供:彼のものが望んでいるMariner hath…結婚7367662766773266666300566246766672667626672766620000566256666662 4F8255095123B0389C4ADA4850D129E52081480893079CCEDADA485075449E7D
G?uest sat on a stone:..He cannot chuse but hear;..And thus spak
4376772767266262776663004626666672667762677266673004662767727766
7F553403140FE01034FE5ADA85031EEF4038535025408512BDA1E4048530301B
G--aにuestに座っているのは以下に石を投げます。彼は、chuseするのではなく、聞くことができます。そして、その結果、spak4376772767266262776663004626666672667762677266673004662767727766 7F553403140FE01034FE5ADA85031EEF4038535025408512BDA1E4048530301B
e? on that ancient man,..The bright-eyed Mariner.....The ship wa
6326627667266666672666200566267666726766246766672000056627667276
5F0FE0481401E395E40D1ECDA4850229784D59540D129E52EDADA48503890071
e?その古代の男性に関して明るい目をしたMariner…船のwa6326627667266666672666200566267666726766246766672000056627667276 5F0FE0481401E395E40D1ECDA4850229784D59540D129E52EDADA48503890071
Friend Informational [Page 101] RFC 5024 ODETTE FTP 2 November 2007
[101ページ]友人の情報のRFC5024オデットFTP2007年11月2日
s? cheered, the harbour cleared,..Merrily did we drop..Below the
7326666766227662667667726666766200467766726662762676700466672766
3F03855254C048508122F5203C51254CDAD5229C90494075042F0DA25CF70485
s?励まされて、港はクリアされました。陽気に、私たちは低下しましたか?7326666766227662667667726666766200467766726662762676700466672766 3F03855254C048508122F5203C51254CDAD5229C90494075042F0DA25CF70485の下で
.kirk, below the hill,..Below the light-house top...
2B667622666672766266662004666727662666672667762767200
03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
丘の下の.kirk軽い家の先端の下で… 2B667622666672766266662004666727662666672667762767200 03B92BC025CF70485089CCCDA25CF704850C9784D8F53504F0EDA
Friend Informational [Page 102] RFC 5024 ODETTE FTP 2 November 2007
[102ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Appendix B. ISO 646 Character Subset
付録B.ISO646文字サブセット
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
o-----------------------------------------------------------------o | | 7| 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | | | B-+-----+-----+-----+-----+-----+-----+-----+-----| | | I6| 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 | | ビット| | | | | | | | | | | 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
Friend Informational [Page 103] RFC 5024 ODETTE FTP 2 November 2007
[103ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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)モデルはオデット-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.
オデット-FTPはレベル4〜7をカバーしています、そして、元々、CCITT X.25はOSIの層1、2、3のための唯一のお勧めの電気通信プロトコルでした。
ISO Reference Model:
ISO規範モデル:
+------------------------------+ <==== File Service
| Level-7 FTP application |
|------------------------------|
| Level-6 FTP presentation |
|------------------------------|
| Level-5 FTP session |
|------------------------------|
| Level-4 FTP transport |
|------------------------------| <==== Network Service
| Level-3 X.25 |
|------------------------------|
| Level-2 X.25 |
|------------------------------|
| Level-1 X.25 |
+------------------------------+
+------------------------------+ <。==== ファイルサービス| レベル-7FTPアプリケーション| |------------------------------| | レベル-6FTPプレゼンテーション| |------------------------------| | レベル-5FTPセッション| |------------------------------| | レベル-4FTP輸送| |------------------------------| <== ネットワーク・サービス| レベル-3X.25| |------------------------------| | レベル-2X.25| |------------------------------| | レベル-1X.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.
PSDNであることをX.25呼び出しを変更されるとき、PTTが呼び出しを発送できるように、目的地のNetwork User Address(NUA)を指定しなければなりません。 出された電話はユーザの構内での終了設備に向けられます。
It is possible to provide extra information in the Call Request Packet in addition to the mandatory NUA required by the PTT.
PTTによって必要とされた義務的なNUAに加えてCall Request Packetのその他の情報を提供するのは可能です。
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.
それは単にアドレスへの拡大です、そして、Call Request Packetの着呼アドレス分野にそれを入れます。 _F CONNECT_RQの目的地アドレス・フィールドからこの情報(アドレス+Subaddress)を取ります。 したがって、ユーザの観点から、区別は全く主なアドレスと「副-アドレス」の部分の間で来ていません。
Friend Informational [Page 104] RFC 5024 ODETTE FTP 2 November 2007
[104ページ]友人の情報のRFC5024オデットFTP2007年11月2日
(b) User data:
(b) 利用者データ:
There is no standard for user data. Moreover, there is no
information in the F_CONNECT_RQ from which the ODETTE-entity may
derive user data to be put in the N_CONNECT_RQ; therefore, user
data shall not be used.
利用者データの規格が全くありません。 そのうえ、_F CONNECT_RQのオデット-実体がN_に入れられた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は、オデット-FTPがデータをNSDU(ネットワークService Data Unit)に動かして、コントロールをNetwork Serviceに通過する前に特別な論理をData Exchange Bufferに適用しなければならないかどうか(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。 交換バッファの「おおう」である必要性
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.
「特別な論理」パラメタは、非同期なリンクの上にオデット-FTPの使用を許すために作成されました。 「特別な論理」が、端末が非同期なエントリー(PAD: パケット議会/分解による)を通ってX.25ネットワークにアクセスするのを可能にするのに必要であったかもしれません。 「特別な論理」は全体のX.25接続の場合に必要ではありません。 この「特別な論理」は、非同期な媒体による誤りを検出するためにCRC機能がわかります。
Negotiation of the "special-logic" parameter in the SSID command is as follows:
SSIDコマンドにおける、「特別な論理」パラメタの交渉は以下の通りです:
SSID 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(はい)を指定するとき、この論理は活性です。
Friend Informational [Page 105] RFC 5024 ODETTE FTP 2 November 2007
[105ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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 |
+------------------------------+
+------------------------------+ <。==== ファイルサービス| レベル-7FTPアプリケーション| |------------------------------| | レベル-6FTPプレゼンテーション| |------------------------------| | レベル-5FTPセッション| |------------------------------| | レベル-4FTP輸送| | 特別な論理処理| |------------------------------| <== ネットワーク・サービス| レベル-3X.25| |------------------------------| | レベル-2X.25| |------------------------------| | レベル-1X.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.
Exchange Bufferと特別な論理を伝えるのがアクティブであると、層4は、同期と輪郭描写キャラクタでExchange Bufferを包装して、ブロックチェックサム(BCS)によってデータ保全を保護するでしょう。 Exchange Bufferと特別な論理を受け取るのがアクティブであるときに、層4は同期のようなものと輪郭描写キャラクタなどを取り外すでしょう、より高い層にExchange Bufferを渡す前に。
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.
各封筒で、それ、および終わりまで追加された2バイトのチェックサムへ1バイトのヘッダーを前に置いています。 チェックサムはISO DIS8073TRANSPORT LAYERドキュメンテーションで指定された方法で引き出されます。
Friend Informational [Page 106] RFC 5024 ODETTE FTP 2 November 2007
[106ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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 --------------------+
+------------------------------------------------------------------+ | S| B| | B| C| | T| S| 完全交換バッファ(CEB)| C| / | | X| N| | S| R| +------------------------------------------------------------------+ A A A| | | | | +------------- ブロック法番号| | | | | +----------------- 同期キャラクタ| | | | ブロックチェックサム-----------------------+ | | 輪郭描写キャラクタ--------------------+
The envelope is initialised with an STX and the checksum variables are set to 0. The leading STX is not protected by the checksum calculation but is explicitly protected by a character compare at the receiver's end. The Exchange Buffer is processed character by character. As each character is removed from the Exchange Buffer, it is put through the checksum calculation and then, prior to its insertion in the envelope, it is put through the Shift-out transparency logic, which will result in either one or two characters being inserted. When the contents of the Exchange Buffer have been entirely processed, then the checksum variables are brought up to date by inserting two X'00's through the checksum calculator and the two resultant checksum characters forwarded to the Shift-out transparency logic for insertion into the envelope. Finally, a carriage return (CR) is appended to the envelope. The segment is now ready for transmission to line.
封筒はSTXと共に初期化されます、そして、チェックサム変数は0に設定されます。 主なSTXによるチェックサム計算で保護されませんが、明らかに保護されて、キャラクタが受信機の終わりに比較するということです。 Exchange Bufferはキャラクタですごとに処理される。 各キャラクタがExchange Bufferから外されるのに従って、それはチェックサム計算で置かれます、そして、次に、封筒への挿入の前に、どちらかの結果か挿入される2つのキャラクタがそうする外のShift透明論理はそれに通されます。 Exchange Bufferの内容を完全に処理してあると、チェックサム変数は、2を挿入することによって'封筒への挿入のために外のShift透明論理に送られたチェックサム計算機と2つの結果のチェックサムキャラクタを通した00年代'とXの日付を入れるために持って来られます。 最終的に、復帰(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を置いて、チェックサム変数をリセットするでしょう。 '彼らが彼らがそのポイントでチェックサム計算機によって処理されないバッファの中に挿入される前にすべてのその後のキャラクタが外のShift論理を使用することで処理されます、Shift-アウトの後をつけるキャラクタですが(X20年を引き算した後、'、)、あるでしょう。 チェックサムキャラクタ自体はチェックサムアルゴリズムのデザインによってチェックサム計算機によって処理されるでしょう。
Friend Informational [Page 107] RFC 5024 ODETTE FTP 2 November 2007
[107ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
エラー修正計画はC/Rによって続かれた3個のタイマの定義とASCII NAK(否定的Acknowledgement)キャラクタの使用で実行されます。 <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系列によって検出されるでしょう。 しかしながら、ある状態をそう検出できません。 例えば、1ブロックの端は受信機が知らない平均ですが、不正なC/Rは達した状態でそうするでしょう。 彼がどれくらい長い間待っても、それ以上のデータは全く送付者から来ないでしょう。 したがって、タイマはこのタイプの不正を検出する唯一の方法です。 このタイプのすべての可能な悪性の状態を検出するのに必要である3個のタイマがあります。
T1 - Exchange Buffer Time Out (Inactivity or Response)
T2 - Inter Character Time Out
T3 - Data Carrier Detect Loss Time Out
T1(交換バッファタイムアウト(不活発か応答)T2)はキャラクタータイムアウトT3を埋葬します--データキャリヤーは損失タイムアウトを検出します。
The three timers are in addition to the timer defined in the original protocol.
3個のタイマがオリジナルのプロトコルで定義されたタイマに加えています。
TIMER T1 - RESPONSE TIME OUT (DEFAULT = 45 SECONDS):
タイマT1--、(45秒のデフォルト=)からの応答時間:
Used to detect a high-level block Time Out, e.g., the Time Out
between an SFID and its associated SFPA or SFNA response.
そのSFIDと関連SFPAかSFNA応答の間にハイレベルのブロックTime Out、例えばTime Outを検出するのにおいて、使用されています。
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.
満期--再試行限界のような時間に達するまで、もう一度全体のブロックを再送してください。
Friend Informational [Page 108] RFC 5024 ODETTE FTP 2 November 2007
[108ページ]友人の情報のRFC5024オデットFTP2007年11月2日
TIMER T2 - INTER CHARACTER TIME OUT (DEFAULT = 7 SECONDS):
タイマT2--キャラクタタイムアウト(7デフォルト=秒)を埋葬してください:
Used to detect errors in the reception of individual characters.
個性のレセプションで誤りを検出するのにおいて、使用されています。
Started - For an asynchronous entity, it is started upon receipt
of each character while in synchronisation mode. For an
X.25 entity, it is started after a received block that
did not terminate an Exchange Buffer.
非同期な実体のために始められて、それは各キャラクタを受け取り次第連動モードで始める間、始められます。 X.25実体において、それはExchange Bufferを終えなかった受信されたブロックの後に始められます。
Stopped - Upon receipt of the next character.
次のキャラクタを受け取り次第、止まりました。
Expiry - Send a <NAK><C/R>, drop out of synchronised mode, and go
back and listen to line.
満期--<NAK><C/R>を送ってください、そして、連動したモードを脱落してください、そして、戻ってください、そして、立ち並ぶために聴いてください。
TIMER T3 - DATA CARRIER TEMPORARY LOSS (DEFAULT = 1 SECOND):
タイマT3--データ記憶媒体の一時的な損失(1デフォルト=秒):
Used by an asynchronous entity only and is used to detect a
temporary carrier failure.
非同期な実体だけを使用して、一時的保菌者の故障を検出するのに使用されます。
Started - When DCD (Data Carrier Detect) is lost.
DCD(データCarrier Detect)が無くなるとき、始められます。
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つでデータの汚染を分類できます:
(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>を除いた)の外で受け取られたすべてのデータが無視されます。
Friend Informational [Page 109] RFC 5024 ODETTE FTP 2 November 2007
[109ページ]友人の情報のRFC5024オデットFTP2007年11月2日
(A) (B)
(A)(B)
Dropped Start of Text (STX)
低下しているテキスト開始(STX)
+-------------------------+
| | B | | B | C |
-----| | S | CEB | C | / |-----> Not sync
| | N | | S | R |
+-------------------------+
+-------------------------+ | | B| | B| C| -----| | S| CEB| C| / |-----同時性ではなく、>。| | N| | S| R| +-------------------------+
+-------+
| N | C |
<-----| A | / |----- Not sync
| K | R |
+-------+
+-------+ | N| C| <、-、-、-、--、| A| / |----- 同時性でない| K| R| +-------+
Exchange Buffer Resent
再送された交換バッファ
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
+-------------------------+ | S| B| | B| C| -----| T| S| CEB| C| / |----->の同時性| X| N| | S| R| +-------------------------+
(2) CORRUPT TERMINATION (C/R)
(2) 不正な終了(C/R)
This situation manifests itself as an extended period of
synchronisation with no activity. The T2 timer will detect this
condition.
この状況は連動の長期間として活動なしで現れます。 T2タイマはこの状態を検出するでしょう。
(A) (B)
(A)(B)
Corrupt Carriage Return
不正な復帰
+-------------------------+
| S | B | | B | |
-----| T | S | CEB | C | |-----> No activity
| X | N | | S | |
+-------------------------+
+-------------------------+ | S| B| | B| | -----| T| S| CEB| C| |----->いいえ活動| X| N| | S| | +-------------------------+
+-------+
| N | C | T2
<-----| A | / |----- Timed out
| K | R |
+-------+
+-------+ | N| C| T2<。-----| A| / |----- 外では、調節されています。| K| R| +-------+
Friend Informational [Page 110] RFC 5024 ODETTE FTP 2 November 2007
[110ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Exchange Buffer Resent
再送された交換バッファ
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Sync
| X | N | | S | R |
+-------------------------+
+-------------------------+ | S| B| | B| C| -----| T| S| CEB| C| / |----->の同時性| X| N| | S| R| +-------------------------+
(3) BAD DATA (4) BAD BCS (BLOCK CHECK SUM)
(3) 悪いデータ(4)の悪いBCS(ブロックチェックサム)
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 Bufferを捨てて、<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 |
+-------------------------+
+-------------------------+ | S| B| | B| C| 悪いデータ-----| T| S| "%! | C| / |-----検出された>。| X| N| | S| R| +-------------------------+
+-------+
| N | C |
<-----| A | / |----- Discard Block
| K | R |
+-------+
+-------+ | N| C| <、-、-、-、--、| A| / |----- ブロックを捨ててください。| K| R| +-------+
Exchange Buffer Resent
再送された交換バッファ
+-------------------------+
| S | B | | B | C |
-----| T | S | CEB | C | / |-----> Data OK
| X | N | | S | R |
+-------------------------+
+-------------------------+ | S| B| | B| C| -----| T| S| CEB| C| / |----->Data OK| X| N| | S| R| +-------------------------+
(5) BAD BLOCK SEQUENCE NUMBER (BSN)
(5) 悪いブロック法番号(BSN)
A circular sequential number (0 up to and including 9) is assigned
to transmitted Exchange Buffers. This is to aid detection of
duplicate or out-of-sequence Exchange Buffers. Once a duplicate
block is detected, the Exchange Buffer in question is discarded.
Once an out of sequence block is detected, this should result in a
protocol violation.
円形の連番(9を含めた0)は伝えられたExchange Buffersに割り当てられます。 これは、写しか順序が狂ってExchange Buffersの検出を支援するためのものです。 写しブロックがいったん検出されると、問題のExchange Bufferは捨てられます。 一度、順序が狂ってブロックは検出されて、これはプロトコル違反をもたらすべきです。
Friend Informational [Page 111] RFC 5024 ODETTE FTP 2 November 2007
[111ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
+-------------------------+
+-------------------------+ | S| | | B| C| 予想-----| T| 0 | EERP| C| / |----->BSN=0| X| | | S| R| トランスミッション+-------------------------+
Exchange Buffer Being Sent
送られる交換バッファ
+-------------------------+
| S | | | B | C | Response to
<----| T | 0 | RTR | C | / |----- Previous
| X | | | S | R | Block
+-------------------------+
+-------------------------+ | S| | | B| C| <への応答----| T| 0 | RTR| C| / |----- 戻る| X| | | S| R| ブロック+-------------------------+
Exchange Buffer Being Sent
送られる交換バッファ
+-------------------------+ Expecting
| S | | | B | C | BSN=1 (Block
-----| T | 1 | SFID | C | / |- // -> lost in
| X | | | S | R | Transmission)
+-------------------------+ T1 Timed Out
+-------------------------+ 予想| S| | | B| C| BSN=1、(ブロック、-、-、-、--、| t|1|SFID|C|/、|、-、中でなくされた//->| X| | | S|R|トランスミッション) +-------------------------+ 外で調節されたT1
Exchange Buffer Being Sent
送られる交換バッファ
+-------------------------+
| S | | | B | C | Send last
<----| T | 0 | RTR | C | / |----- Block
| X | | | S | R | again
+-------------------------+
+-------------------------+ | S| | | B| C| 最後の<を送ってください。----| T| 0 | RTR| C| / |----- ブロック| X| | | S| R| 再び+-------------------------+
Discard Block
and start
Timer T1
Blockを捨ててください、そして、Timer T1を始動してください。
T1 Timed Out
外で調節されたT1
Friend Informational [Page 112] RFC 5024 ODETTE FTP 2 November 2007
[112ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Exchange Buffer Resent
再送された交換バッファ
+-------------------------+
| S | | | B | C | Expecting
-----| T | 1 | SFID | C | / |-----> BSN=1
| X | | | S | R | Block OK
+-------------------------+
+-------------------------+ | S| | | B| C| 予想-----| T| 1 | SFID| C| / |----->BSN=1| X| | | S| R| ブロックOK+-------------------------+
Exchange Buffer Being Sent
送られる交換バッファ
+-------------------------+
| S | | | B | C | Response
<----| T | 1 | SFPA | C | / |----- BSN=1
| X | | | S | R | Block OK
+-------------------------+
+-------------------------+ | S| | | B| C| 応答<。----| T| 1 | SFPA| C| / |----- BSN=1| X| | | S| R| ブロックOK+-------------------------+
Exchange Buffer Being Sent
送られる交換バッファ
+-------------------------+
| S | | | B | C |
-----| T | 2 | DATA | C | / |-----> Data OK
| X | | | S | R |
+-------------------------+
+-------------------------+ | S| | | B| C| -----| T| 2 | データ| 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:
以下の機能は連続して実行されるでしょう:
1. Calculation of the Block Sequence Number (BSN):
1. ブロック一連番号(BSN)の計算:
BSN is set to zero by SSID. First block will be sent with value
zero. Value of BSN is increased by one for each data buffer to be
transmitted. When BSN value exceeds 9, counter will be reset to
zero.
SSIDはゼロにBSNを用意ができさせます。 値ゼロと共に最初のブロックを送るでしょう。 BSNの値は、それぞれのデータバッファが伝えられるために1つ増加します。 BSN値が9を超えているとき、カウンタはゼロにリセットされるでしょう。
Format: numeric/1 pos.
形式: 数値/1pos。
2. Calculation of the Block Checksum (BCS):
2. ブロックチェックサム(BCS)の計算:
Calculation is done as specified in the ISO DIS 8073 TRANSPORT
LAYER document.
ISO DIS8073TRANSPORT LAYERドキュメントで指定されるように計算をします。
Format: binary/2 pos.
形式: バイナリー/2pos。
Friend Informational [Page 113] RFC 5024 ODETTE FTP 2 November 2007
[113ページ]友人の情報のRFC5024オデットFTP2007年11月2日
3. Shift-out transparency (See TRANSMIT/RECEIVE logic.)
3. 外でのシフト透明(TRANSMIT/RECEIVE論理を見てください。)
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.
制御文字への'データ・ストリームにおける、どんな制御文字の外観も避けるために、外のShift論理は拡張Exchange Buffer(STXと復帰文字の例外がバッファをおおっている)のすべてのキャラクタに通されて、挿入されるキャラクタ(SO)と十六進法価値を高めることにおけるどの結果が20年です'。
4. The carriage return is inserted at the end of the data buffer.
4. 復帰はデータバッファの端に挿入されます。
Note: After adding STX, BSN, BCS, CR, and SO-logic, the data buffer
may exceed the Data Exchange Buffer size.
以下に注意してください。 STX、BSN、BCS、CR、およびSO-論理を加えた後に、データバッファはData Exchange Bufferサイズを超えるかもしれません。
C.2.7. Checksum Creation Algorithm
C.2.7。 チェックサム創造アルゴリズム
These follow the ISO DIS 8073 TRANSPORT LAYER standard.
これらはISO DIS8073TRANSPORT LAYER規格に続きます。
SYMBOLS:
シンボル:
The following symbols are used:
以下のシンボルは使用されています:
C0,C1 Variables used in the algorithm
L Length of the complete NSDU
X Value of the first octet of the checksum parameter
Y Value of the second octet of the checksum parameter
C0、C1 VariablesはアルゴリズムLでチェックサムパラメタの2番目の八重奏のチェックサムパラメタY Valueの最初の八重奏の完全なNSDU X ValueのLengthを使用しました。
ARITHMETIC CONVENTIONS:
算数のコンベンション:
Addition is performed in one of the two following modes:
添加は2つの次のモードの1つで実行されます:
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).
ゼロ(すなわち、255)を引いて変数のどれかに値があるならそれが見なされるものとするa)法255演算b)1の補数演算、プラスゼロ(すなわち、0)はそうです。
ALGORITHM FOR GENERATING CHECKSUM PARAMETERS:
チェックサムパラメタを発生させるためのアルゴリズム:
. 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
. i=1からLまで各八重奏を連続して処理してください。
a) adding the value of the octet to C0, then
b) adding the value of C0 to C1.
a) 次に、b)がC0の価値をC1に高めて、八重奏の価値をC0に高めること。
Friend Informational [Page 114] RFC 5024 ODETTE FTP 2 November 2007
[114ページ]友人の情報のRFC5024オデットFTP2007年11月2日
. Calculate X and Y such that
XとYについて計算してください。
X = C0 - C1
Y = C1 - 2*C0
XはC0と等しいです--C1Yは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
. i=1からLまでNSDUの各八重奏を連続して処理してください。
a) adding the value of the octet to C0, then
b) adding the value of C0 to C1.
a) 次に、b)がC0の価値をC1に高めて、八重奏の価値をC0に高めること。
. 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')
論理を伝えてください。(したがって、: X'0E'かX'8E'を評価します)
Buffer(1), ... , (n) is a character in the buffer to be sent.
バッファ(1)… , (n) キャラクタが送られるバッファにありますか?
FOR i=1 to n /* for all octets of the buffer */
バッファ*/のすべての八重奏のためのn/*へのFOR i=1
IF ((buffer(i) & X'7F') < X'20')
IF'('7F') <X20年'というバッファ(i)とX)
THEN output (SO)
output (buffer(i) + X'20')
THEN出力(SO)出力'、((i)+X20年をバッファリングしてください、'、)
ELSE output (buffer(i))
ELSE出力((i))をバッファリングしてください。
Friend Informational [Page 115] RFC 5024 ODETTE FTP 2 November 2007
[115ページ]友人の情報のRFC5024オデットFTP2007年11月2日
NEXT:
次:
RECEIVE LOGIC (values SO: X'0E' or X'8E')
論理を受け取ってください。(したがって、: 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 */
バッファ*/のすべての八重奏のためのn/*に=偽のFOR i=1を落としてください。
IF drop = true
= 本当に低下してくださいなら
THEN output (buffer(i) - X'20')
drop = false
'THEN、((i)をバッファリングしてください--X20年'、出力されて、)、= 虚偽で低下してください。
ELSE IF buffer(i) = (X'0D' or X'8D')
THEN Stop
ELSE IF buffer(i) = SO
THEN drop = true
ELSE output (buffer(i))
'SO THENが落とすバッファ(i)=が本当のELSE出力と等しいなら、ELSE IFは(i)=(X'0D'かX'8D')THEN Stop ELSEをバッファリングします。((i))をバッファリングしてください。
NEXT:
次:
C.3. PAD Parameter Profile
C.3。 パッドパラメタプロフィール
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).
以前、(オデット-FTP)非同期な実体-->Modem-->PAD-->(オデット-FTP)のネイティブのX.25リンクを設立できて、目標PADパラメタを設定しなければならないので、正しいコミュニケーションは確立されます。 PADパラメタがX.25実体によって設定されることが強く勧められます。 CCITT推薦のX.3、X.28、およびX.29はPADとパケット形態Data Terminal Equipment(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.
Parameterリストが以下にあって、値は以前はよくオデット-FTPコミュニケーションにPADを設定していました。 さらなる詳細な情報に関しては、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
いいえ 記述値の意味--------------------------------------------------------------- 1つのエスケープ、Idle Timer Delay20 1秒の5Ancillary Device Controlのホスト2Echo0ノーEcho3Data Forwarding Signal2Carriage Return4SelectionによるData Transfer0Controlledから、0X-ON、X-OFFが6を使用しなかった、PAD Service Signals、Break2Reset8Discard Output0Doの上の迅速な7Procedure以外の1AllはCarriage Return0いいえ詰め物の後に9Paddingを捨てません。
Friend Informational [Page 116] RFC 5024 ODETTE FTP 2 November 2007
[116ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
10 Line Folding 0 No line folding 11 Terminal Data Rate - Read only 12 Flow Control of the PAD 0 No flow control used 13 Linefeed Insertion after C/R 0 No linefeed 14 Linefeed Padding 0 No linefeed padding 15 Editing 0 No editing 16 Character Delete 127 Delete 17 Line Delete 24 <CTRL>X 18 Line Display 18 <CTRL>R 19 Editing PAD Service Signals 0 No service signal 20 Echo Mask 0 No echo mask 21 Parity Treatment 0 No parity check 22 Page Wait 0 No page wait
Note 1:
注意1:
Refer to CCITT (1984)
- Parameters 1 - 12 are mandatory and available internationally.
- Parameters 13 - 22 may be available on certain networks and may
also be available internationally.
- A parameter value may be mandatory or optional.
CCITT(1984)を参照してください--パラメタ1--12は、国際的に義務的であって、利用可能です。 - パラメタ13--22も、あるネットワークで利用可能であるかもしれなく、また、国際的に利用可能であるかもしれません。 - パラメタ値は、義務的であるか、または任意であるかもしれません。
The ODETTE profile refers only to parameter values which must be internationally implemented if the parameter is made available internationally.
オデットプロフィールはパラメタを利用可能に国際的にするなら国際的に実行しなければならないパラメタ値だけについて言及します。
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.)
彼らがいくつかのパラメタ(13--22)のどんなサポートもしないので、オデット-FTP「特別な論理」パラメタはいくつかのPADsで不可能であるかもしれません。 (PADがデフォルトでパリティチェック(21)を支持しているなら、オデット-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実体オデット-FTPモニター機能を始めで止めてください。 - 実行されたPADサービス。 - パケット形態DTE実体オデット-FTPモニター機能。
Friend Informational [Page 117] RFC 5024 ODETTE FTP 2 November 2007
[117ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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)の使用のためのオデットGroup4(1)の推薦について説明します。
(1) ODETTE Group 4 is responsible for the specification of
Telecommunications standards and recommendations for use
within the Automotive Industry.
(1) オデットGroup4はAutomotive Industryの中の使用のためのTelecommunications規格と推薦の仕様に責任があります。
(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(オデットFile Transfer Protocol)はEDIと非EDIデータの両方の転送のために設計されたオデットGroup4によって指定されたコミュニケーション規格です。
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に詳しくない人への紹介している情報、および推薦の実現に関連している問題に関する注と共に。
The first section provides the detailed ODETTE recommendation, which is followed by a general discussion. If you are not familiar with the terminology, please read the subsequent sections first.
最初のセクションは詳細なオデット推薦を提供します。(一般的な議論はそれのあとに続きます)。 用語に詳しくないなら、最初に、その後のセクションを読んでください。
How far an existing X.25 Line adapter may be replaced by an ISDN line adapter in an installation depends on the opportunities in view of connections (X.25 or ISDN) of the involved partners for file transfer.
どれくらい遠くにインストールで既存のX.25線アダプターをISDN回線アダプタに取り替えるかもしれないかはファイル転送のためにかかわったパートナーの接続(X.25かISDN)から見て機会に依存します。
Companies that keep many connections to external partners (for example, car manufacturing companies) may use the OFTP file transfer in view of compatibility, which must always be considered anyway only in parallel to the X.25 network.
域外パートナー(例えば、車の製造会社)に多くの接続を保つ会社は互換性から見てOFTPファイル転送を使用するかもしれません。平行だけでとにかくいつもX.25ネットワークと互換性を考えなければなりません。
It is not the aim of this recommendation to remove the OFTP file transfer generally from the X.25 network to the ISDN network. This will not always be possible for international connections because of technical reasons, and this does not always make sense for connections with a low size of data to be transmitted.
それは一般に、X.25ネットワークからISDNネットワークまでのOFTPファイル転送を取り除くというこの推薦の目的ではありません。 これは技術的な理由でいつも国際的な接続に可能になるというわけではないでしょう、そして、いつも、伝えられるべきデータの低サイズとの関係のために理解できるというわけではありません。
Certainly, the use of ISDN, when exchanging a high volume of data (for example, CAD/CAM files), is very much cheaper than the use of an X.25 network. For such cases, this recommendation shall provide a cost-effective possibility for file transfer.
高いデータ量(例えば、CAD・CAMファイル)を交換するとき、確かに、ISDNの使用はX.25ネットワークの使用よりたいへん安いです。 そのような場合のために、この推薦は費用対効果に優れた可能性をファイル転送に提供するものとします。
This appendix is organized as follows. D.1 defines the ODETTE recommendation in these terms, D.2 introduces the ISDN environment to the unfamiliar reader, D.3 describes the various methods of connecting to ISDN, and D.4 covers implementation issues.
この付録は以下の通りまとめられます。 D.1はこれらの用語でオデット推薦を定義します、そして、D.2はなじみのない読者にISDN環境を紹介します、そして、D.3はISDNに接続する様々な方法を説明します、そして、D.4は導入問題をカバーしています。
Friend Informational [Page 118] RFC 5024 ODETTE FTP 2 November 2007
[118ページ]友人の情報のRFC5024オデットFTP2007年11月2日
D.1. ODETTE ISDN Recommendation
D.1。 オデットISDN推薦
X.25: Level 2 ISO 7776
Protocol
X.25: レベル2 ISO7776プロトコル
Level 3 ISO 8208
Protocol
レベル3 ISO8208プロトコル
Packet Size 128
パケットサイズ128
Level 2 7
Window Size
レベル2 7 ウィンドウサイズ
Level 3 7
Window Size
レベル3 7 ウィンドウサイズ
First LCN 1
最初に、LCN1
Number of LCNs 1
LCNs1の数
Facilities Window Size and Packet Size
negotiation shall be supported
by everybody. Call User Data
should not be required.
施設Window SizeとPacket Size交渉はみんなによって支持されるものとします。 呼び出しUser Dataを必要とするべきではありません。
Calling NUA Optionally provided by the call
initiator.
呼ぶNUA Optionallyは呼び出し創始者で提供しました。
Called NUA Should be set to a value where
the last 'n' digits can be
specified by the called party.
'NUA Shouldと呼ばれて、被呼者が最終と'ケタを指定できる値に設定されてください。
ISDN: Apart from requesting a 64K unrestricted digital
call, no ISDN features shall be required.
ISDN: 64Kの無制限なデジタル呼び出しを要求することは別として、ISDN機能を全く必要としないものとします。
Timeout control: To avoid connections (B channels) within the
circuit-switched ISDN network remaining active
but unused for a long time, the adapter should
include a timeout control.
タイムアウトコントロール: 長い間アクティブですが、未使用のままで残りながらサーキットで切り換えられたISDNネットワークの中で接続(Bチャネル)を避けるために、アダプターはタイムアウトコントロールを含んでいるはずです。
An ISDN connection (B channel) should be released
if no X.25 packets have been transmitted on this
connection for a longer time. For flexibility a
variable user definable timer should be
incorporated into the adapter.
X.25パケットが全くこの接続のときに、より長い時間伝えられていないなら、ISDN接続(Bチャネル)は釈放されるべきです。 柔軟性において、可変ユーザ定義可能なタイマはアダプターに組み入れられるべきです。
Friend Informational [Page 119] RFC 5024 ODETTE FTP 2 November 2007
[119ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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).
そのような高品質で、エラーのない背骨ネットワークの上のデジタル符号化のテクニックの使用で、PTTは高帯域をエンドユーザに提供できました。 サービスはISDN(統合Services Digital Network)と命名されます。
The increasing need to transfer larger volumes of EDI data, in particular CAD/CAM drawings, has focused attention upon high-speed, low-cost communication. The traditional X.25 over a Packet Switched Data Network (PSDN) has been a good general purpose communications subsystem. Unfortunately, its cost and transfer speed make PSDN expensive for the new requirement.
EDIデータの、より大量を移す増加する必要性(特にCAD・CAM図面)は高速で、安価のコミュニケーションに集中している注意を持っています。 Packet Switched Data Network(PSDN)の上の伝統的なX.25は良い汎用のコミュニケーションサブシステムです。 残念ながら、その費用と転送速度で、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(パケットSwitched Data Network)はX.25プロトコルが操作されるネットワークです。
PSPDN: A PSPDN (Packet Switched Public Data Network) is a PSDN
operated by the PTTs. PSPDNs are given trade names,
such as PSS in the UK, Datex-P in Germany, and Transpac
in France.
PSPDN: PSPDN(パケットSwitched Public Data Network)はPTTによって運用されたPSDNです。 イギリスのPSSや、ドイツのDatex-Pや、フランスのTranspacなどの商号をPSPDNsに与えます。
BRI: Basic Rate Interface, also known as Basic Rate Access,
defines an ISDN facility with 2 x 64 K B channels.
ブライ: 基本的なまた、Basic Rate Accessとして知られているRate Interfaceは2x64KのBチャネルのISDN能力を定義します。
PRI: Primary Rate Interface, also known as Primary Rate
Access, defines an ISDN facility with 30 x 64 K B
channels.
PRI: 第一のまた、Primary Rate Accessとして知られているRate Interfaceは30x64KのBチャネルのISDN能力を定義します。
Friend Informational [Page 120] RFC 5024 ODETTE FTP 2 November 2007
[120ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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は、消費者の構内に1ツイストペアのワイヤを使用することで通常もたらされています。 このワイヤの上に、周波数帯でデータを送ることができます。 チャンネルとしてこれらの周波数帯を割り当てます。
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チャネルは、データ・チャンネルであり、64KBで作動します。 接続の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チャネルで接続をセットアップして、釈放するのに使用されます。 また、いくつかの国では、PTTのPSDNへの限られたX.25アクセスにDチャネルを使用できます。
The D channel operates at the lower speed of 16 Kb as it
is normally used only at the beginning and end of a
connection.
それが単に接続の首尾に通常使用されるとき、Dチャネルは16KBの下側の速度で作動します。
Bandwidth Allocation:
2 Wire B2 - 64 Kb
Twisted Pair B1 - 64 Kb
D Channel - 16 Kb
帯域幅配分: 2 B2を配線してください--64KBは組B1--64KBのDチャネル--16KBをねじりました。
The standard for the operation of the D channel is
called ETSI and is used in most European countries.
However, some countries that started the introduction
very early used proprietary standards, for example:
Dチャネルの操作の規格は、ETSIと呼ばれて、ほとんどの欧州諸国で使用されます。 しかしながら、例えば、非常に早く序論を始めたいくつかの国が独占規格を使用しました:
1TR6 - Used in Germany
BTNR - Used in the UK
イギリスで使用される1TR6(ドイツBTNRでは、使用されます)
Although there are D channel variations, this will not
affect communications over the B channels as the
communication over the D channel is between the
subscriber and the ISDN service provider.
Dチャネル変化がありますが、加入者とISDNサービスプロバイダーの間にDチャネルの上のコミュニケーションがあるとき、これはBチャネルの上でコミュニケーションに影響しないでしょう。
However, the consumer's equipment must be able to handle
the channel D signalling operated by the ISDN service
provider and so there may be a problem of equipment
availability and certification.
しかしながら、消費者の設備は設備の問題が有用性であったかもしれないならしたがって、そこでISDNサービスプロバイダーによって運用されたチャンネルD合図と証明を扱うことができなければなりません。
All the PTTs have committed to migrate to ETSI (also
known as EURO-ISDN and Q.931) and many are currently
supporting both their national variant and ETSI. It is
advisable that in this situation the subscriber select
the ETSI variant to avoid unnecessary equipment
obsolescence.
すべてのPTTがETSI(また、ユーロISDNとQ.931として、知られている)にわたるように公約されました、そして、多くが現在、それらの国家の異形とETSIの両方を支持しています。 この状況における加入者が不要な設備老廃を避けるためにETSI異形を選択するのは、賢明です。
Friend Informational [Page 121] RFC 5024 ODETTE FTP 2 November 2007
[121ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Services: The high-speed service is provided in two forms, Basic
and Primary.
サービス: 2つのフォーム、Basic、および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.
基本的: 2+D、D2B channelは16KBで作動します。 通常、簡単なツイストペアケーブルの上の加入者にBasic Rateアクセスを提供します。
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チャネルは64KBで作動します。 通常、保護された同軸ケーブルの上の加入者に第一のRateアクセスを提供します。 Primaryのための帯域幅が2.048であることに注意してください。メガビット/s。
Protocols: The B channel is a binary channel and is transparent to
the flow of data. Therefore, all of the currently
available protocols can operate over a B channel. The
most common protocol is X.25.
プロトコル: Bチャネルは、2進のチャンネルであり、データの流れに透明です。 したがって、現在利用可能なプロトコルのすべてがBチャネルの上で作動できます。 最も一般的なプロトコルはX.25です。
X.25: The X.25 protocol is a primary protocol for open
computer-to-computer communication.
X.25: X.25プロトコルはコンピュータからコンピュータへの開いているコミュニケーションのための第一のプロトコルです。
Passive Bus: It is possible to have an ISDN service enter a building
and then have an 8-core cable laid within the building
with multiple ISDN junction points, in the same way as
one would have multiple telephone points (extensions)
for a particular external telephone line.
受け身のバス: ISDNサービスで建物に入って、次に、複数のISDN合流点ポイントがあるビルの中に8コアのケーブルを置くのを持っているのは可能です、1つには特定の外部の電話回線のための複数の電話ポイント(拡大)があるだろうというのと同様に。
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 Call Request Packetを伝播して。
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呼び出しの終了段階は、Clear Requestと共に作られていて、Clear Confirmationと共に成立させられます。 そして、Clear Confirmの受取人は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接続のときにアクティブな他のどんなSwitched Virtual Circuits(SVCs)もない場合にだけ、ISDN接続の明確な下であるのは作られるべきです。 複数の同時のSVCsの使用法が単に二国間条約によってあることに注意してください。
Friend Informational [Page 122] RFC 5024 ODETTE FTP 2 November 2007
[122ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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 BUS速度にはアダプターとアプリケーションとのコミュニケーションの速度があるということです。 したがってですおそらく、ほぼ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チャネルが平行であって、かつ64KBで作動できる状態で使用されるかもしれないということです。
Elementary Terminal Adapter
基本のティーエー
In this scenario, the computer has an integral X.25 adapter
communicating X.21 with a Terminal Adapter that fronts the ISDN
network. This allows a host with a X.25 capability to interface
to ISDN, normally on a one-to-one basis.
このシナリオでは、コンピュータで、不可欠のX.25アダプターはISDNネットワークに向かうティーエーとX.21を伝えます。 これはISDNに連結するX.25能力と、通常1〜1個のベースの上にホストを許容します。
The interface between the Terminal Adapter and the PC will
typically only support one 64K B channel. This is obviously an
inefficient usage of the ISDN service.
ティーエーとPCとのインタフェースは1つ64のK 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ネットワークが経営されるより大きいcorporatesかどこの二元的なX.25の中で見つけられるか、そして、ISDNが必要です。
The main benefit of a switch is to support both PSDN and ISDN
simultaneously. Also, multiple X.21 lines may be implemented
between the X.25 switch and the computer.
スイッチの主な利益は同時にPSDNとISDNの両方を支持することです。 また、複数のX.21線がX.25スイッチとコンピュータの間で実行されるかもしれません。
This solution normally requires more effort to configure and may
require obligations to be placed upon how incoming callers
specify routing.
この解決策は、通常、構成するより多くの努力を必要として、電話をかけてきた人がどうルーティングを指定するかに置かれるべき義務を必要とするかもしれません。
Friend Informational [Page 123] RFC 5024 ODETTE FTP 2 November 2007
[123ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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
属性承認が成長パフォーマンスを発行する呼び出し論理チャネル課題施設交渉ISDN呼び出しを受けながら電話をかけるX.25/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は、PTT(PSPDNs)によって提供されたX.25ネットワークの上で働くように設計されました。 国家のX.25ネットワークはグローバルなX.25ネットワークを提供するためにインタコネクトされました、そして、一般的なアドレシング計画はすべてによって採用されました。 全国的なネットワークの中にアドレシングのいくつかの違いがありましたが、他国へのインタフェースは、全く堅く、正常化しました。
PSPDN Numbering
PSPDN付番
The addressing scheme adopted in X.25 is a 15-digit number
(Network User Address, NUA) where the first three identify the
country, the fourth digit identifies the network within the
country, and the remainder specify the individual subscriber plus
an optional subaddress. In the UK where a full X.25 numbering
scheme is adopted, a NUA is, e.g., 234221200170, where 2342 is the
DNIC (Data Network Identification Code) and 21200170 is the
subscriber number.
X.25に採用されたアドレシング計画は最初の3が国を特定するところの15桁数(User Addressをネットワークでつないでください、NUA)です、そして、4番目のケタは国内でネットワークを特定します、そして、残りは個々の加入者と任意の「副-アドレス」を指定します。 完全なX.25ナンバリングスキームが採用されて、NUAがそうであるイギリス、例えば、234221200170には、加入者番号があります。そこでは、2342は、DNIC(データNetwork Identification Code)と21200170です。
ISDN Numbering
ISDN付番
ISDN is an extension of the normal telephone system; consequently,
it adopts (or rather is) the same numbering scheme as the
telephone system (PSTN).
ISDNは正常な電話の拡大です。 その結果、それは電話(PSTN)と同じナンバリングスキームを採用します(または、むしろ、あります)。
The Numbering Conflict
付番闘争
The PSDN and PSTN numbering schemes are two totally different
numbering schemes. There is no relationship between them. It is
this conflict that is at the heart of the matter.
PSDNとPSTNナンバリングスキームは2つの完全に異なったナンバリングスキームです。 それらの間には、関係が全くありません。 それは問題の核心にあるこの闘争です。
Friend Informational [Page 124] RFC 5024 ODETTE FTP 2 November 2007
[124ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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番号を引き出すためにケタの引き算、そして/または、添加で操作されます。 したがって、接頭語2が00944733に削除されて、取り替えられる00944733394023のPSTN番号を引き出すために2394023を操ることができました。
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 NUA0733394023に発行されたX.25呼び出しはPSTN No.0733394023へのISDN呼び出しをもたらすでしょう。 呼び出しが確立された後に、次にX.25発呼要求がNUA0733394023と共に移されるHDLC/X.25プロトコルセットアップは確立されるでしょう。
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はガラッと変わるでしょう。
Friend Informational [Page 125] RFC 5024 ODETTE FTP 2 November 2007
[125ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Such variation of X.25 NUA, in particular the changing prefix, can
be difficult to be accommodated by X.25 routing logic in many
products.
X.25 NUAのそのような変化(特に変化接頭語)は、多くの製品の中のX.25ルーティング論理によって設備されるために難しい場合があります。
When an international PSTN call is being made, then it is likely
that the PSTN number exceeds 15 digits, which is the maximum
length of an X.25 NUA. Therefore, using un-mapped addressing may
make some international calls impossible to make.
国際的なPSTN電話をかけていると、PSTN番号は15ケタを超えていそうです(X.25 NUAの最大の長さです)。 したがって、不-写像しているアドレシングを使用するのは、いくつかの国際電話を作るのを不可能にするかもしれません。
Manipulated Calls
操られた呼び出し
The X.25 called NUA is manipulated by the subtraction and/or
addition of digits to derive a resultant PSTN number.
NUAと呼ばれるX.25は、結果のPSTN番号を引き出すためにケタの引き算、そして/または、添加で操作されます。
Let us assume that by internal convention we have identified the
prefix '2' to indicate an international ISDN call. Thus, an X.25
call request of 244733394023 could be manipulated to derive a PSTN
number of 00944733394023, where the prefix '2' is deleted and
replaced by '009' (the international prefix).
内部のコンベンションで、私たちが国際的なISDN呼び出しを示すために接頭語'2'を特定したと仮定しましょう。 したがって、接頭語'2'が'009'(国際的な接頭語)に削除されて、取り替えられる00944733394023のPSTN番号を引き出すために244733394023に関するX.25発呼要求を操ることができました。
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が56733394023であるために望んでいるイギリスとそうがPSTN番号を引き出すか。そこでは、56年を''00944に削除して、取り替えます'。
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ルータ箱の中にテーブルを変えるためにコンピュータ室か特別な構成に設備にアクセスします。
Friend Informational [Page 126] RFC 5024 ODETTE FTP 2 November 2007
[126ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
私たちは、前項からISDNかかってきた電話からの呼ばれたX.25 NUAがかなり異なるかもしれないのを見ました。 ISDN/X.25が国境に閉じ込められると、ほとんどの呼び出しにはX.25 NUAと呼ばれるマッチングとPSTN番号があるので、そのような変化はそれほどすばらしくならないでしょう。
X.25 switches and X.25 adapters normally route/accept/reject calls
based upon their X.25 called NUA. In particular, routing is made
upon the X.25 called NUA subaddress.
通常、X.25スイッチとX.25アダプターは、NUAと呼ばれるそれらのX.25に基づく呼び出しを、発送するか、受け入れる、または拒絶します。 特に、ルーティングはNUA subaddressと呼ばれるX.25で作られています。
To derive this subaddress, there are 2 methods:
この「副-アドレス」を引き出すために、2つの方法があります:
1) the last 'n' digits are analysed.
'1) 最終と'ケタは分析されます。
2) the base X.25 NUA of the line is removed from the called NUA.
For example, if the called X.25 NUA is 23422120017010 and the
PSDN subscriber NUA is 234221200170, then the subaddress
derived from subtraction is 10.
2) 線のベースX.25 NUAは呼ばれたNUAから取り外されます。 例えば、呼ばれたX.25 NUAが23422120017010であり、PSDN加入者NUAが234221200170であるなら、引き算から得られた「副-アドレス」は10です。
Obviously, the second method will not work if the incoming NUA varies.
明らかに、入って来るNUAが異なると、2番目の方法は利かないでしょう。
ISDN Features
ISDN機能
ISDN, like X.25, has a core set of features that are then enriched
with options. In the original OFTP X.25 specification, it was
decided that the Q-bit and D-bit options were not common to all
networks or applications; they were therefore positively excluded
from the specification.
ISDNには、X.25のように、次にオプションで豊かにされる1人の巻き癖の特徴があります。 当初の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
Subaddressingします。
There are two forms of ISDN subaddressing, overdialled and specific.
過剰ダイヤルされて特定のISDN副記述の2つのフォームがあります。
The overdial method allows an ISDN number to be artificially
extended. A typical case would be where a private exchange has been
installed in a larger company. Assume that the base number is
394023 and the computer is on internal extension 1234, then by
specifying an ISDN number of 3940231234, direct access may be made
to the internal extension.
「過剰-ダイヤル」方法は、ISDN番号が人工的に広げられるのを許容します。 典型的なケースは私設交換機が、より大きい会社にインストールされたところでしょう。 基本数が394023であると仮定して、内部の拡大1234にはコンピュータがあります、そして、次に、3940231234のISDN番号を指定することによって、直接アクセスを内部の拡大にしてもよいです。
Friend Informational [Page 127] RFC 5024 ODETTE FTP 2 November 2007
[127ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
X.25 datalineは多くの論理チャネルをそれに関連づけてしまうでしょう。
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が呼び出しを理解すると、最も大きい定義された論理チャネル番号は選択されるでしょう。 リモートData Communications Equipment(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.
PSPDN環境で、ウィンドウサイズとパケットサイズの交渉に加入するのは可能です。 創始者のDTEによって要求されたこの交渉は創始者のDCEの裁量でリモートDTEに伝播されるかもしれませんが、それはDTEとDCE組の間の地方の責任です。
In the ISDN scenario where it is a DTE-DTE type connection, the
window size and packet size may be left at the default value and
consequently the values may be omitted from the call request. If no
values are specified, then it is vital that both DTEs have
configured themselves to the recommended defaults.
それがDTE-DTEタイプ関係であるISDNシナリオでは、ウィンドウサイズとパケットサイズはデフォルト値で残されるかもしれません、そして、その結果、値は発呼要求から省略されるかもしれません。 値が全く指定されないなら、両方のDTEsがお勧めのデフォルトに自分たちを構成したのは、重大です。
The symptom of a window size mismatch is a hang situation without
any informational error codes.
ウィンドウサイズミスマッチの兆候は少しも情報のエラーコードがなければハング状況です。
Friend Informational [Page 128] RFC 5024 ODETTE FTP 2 November 2007
[128ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
Call RequestパケットのFacilities分野で要求されたウィンドウサイズを指定することによって、明らかにウィンドウサイズ交渉を要求できます。
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.
PTTは、CCITT X.25パケットサイズには、'128'八重奏のデフォルト値があります、加入者に他のデフォルト値、例えば、'1024'があるかもしれませんが同意しました。
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.
ISDN呼び出しの初期のセットアップはQ.931 SETUPコマンドの送信によって着手されます。 呼び出しが確立されるよう要求することは別として、SETUPコマンドは任意に設立されるよう要求されているプロトコルの起呼側、被呼者、ルーティング情報、必要であるサーキット(例えば、声かデータ)のタイプ、および情報の情報を運ぶことができます。
Setup Parameters:
パラメタをセットアップしてください:
Bearer capability Information transfer and
access attributes
運搬人能力情報転送とアクセス属性
Called Party number Destination's network address
パーティ番号Destinationのネットワーク・アドレスと呼ばれます。
Called Party subaddress Destination's complete
address
パーティsubaddress Destinationの完全なアドレスと呼ばれます。
Calling Party number Source's network address
Sourceのネットワーク・アドレスにパーティ番号に電話をします。
Low-layer compatibility Layer 1-3 indication
低い層の互換性Layer1-3指示
High-layer compatibility Layer 4-7 indication
高層の互換性Layer4-7指示
Friend Informational [Page 129] RFC 5024 ODETTE FTP 2 November 2007
[129ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
承認手順は、採用されてPTTによって提供されたサービスに接続された通信装置の品質と順応に関してPTTによって活発に実施されていました。
In particular, commercial X.25 products had to be tested and approved before they could be connected to the PTTs' PSPDN. The advantage of this to the subscriber was that there was very little chance of the approved equipment not working.
PTTのPSPDNにそれらを接続できる前に、商業X.25製品は、特に、テストされて、承認されなければなりませんでした。 加入者へのこの利点は承認された設備が働いていないという非常に小さい見込みがあったということでした。
With ISDN, similar approval standards are still enforced. So the subscriber has the same confidence in their ISDN equipment. Wrong, the ISDN equipment itself is approved, but the X.15 protocol that operates on top of ISDN is now outside of the scope of approval services.
ISDNで、同様の認可基準はまだ励行されています。 それで、加入者には、それらのISDN設備における同じ信用があります。 悪事、ISDN設備自体は承認されていますが、ISDNの上で作動するX.15プロトコルが現在承認のサービスの範囲の外にあります。
This means that quality of conformance to standards of X.25 over ISDN is subject to the variable quality procedures within the various ISDN equipment manufacturers.
これは、ISDNの上のX.25の規格への製造品質が様々なISDN設備メーカーの中で可変上質の手順を受けることがあることを意味します。
Although it is likely that commercial reputation will place pressure upon the manufacturers with a programming bug to correct such errors, it still requires the subscribers that do not communicate well to put time and effort into finding the party with the error.
その商業評判がそのような誤りを修正するためにプログラミングバグで圧力をメーカーに置くのが、ありそうですが、誤りがあるパーティーを見つけるのに時間と努力をそそぐのがまだよく交信しない加入者を必要としています。
So far, tests have shown a number of subtle errors, such as timing problems, that have taken many days to find, prove, and fix.
今までのところ、テストは見つけて、立証して、修理する取られた何日も過すタイミング問題などの微妙な多くの誤りを示しました。
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.
ユーザが、始めからの成長の計画を立てると決めるなら、Primary Rate Accessには、見かけの財政的な利益があります。 通常、そのような見かけの貯蓄は、ユーザハードウェアのコストの上昇のためそのようなインタフェースを支持するために失われています。 データ用法のためのBRIは非常に一般的です、そして、カード/アダプターは費用で低いのですが、極めてまれでその結果、PRIカード/アダプターは非常に値を付けられます。
Basic Rate Access
基本料金アクセス
One way to grow with ISDN is to buy multiple BRI lines, increasing
slowly in units of 2 x B channels. The PTTs will be able to
provide the same subscriber number for all the lines provided in a
similar way to the traditional hunting group associated with PSTN
type working.
ISDNで成長する1つの方法は複数のBRI線を買うことです、ゆっくり2つのx Bチャネルのユニットを増やして。 PTTは働いているPSTNタイプに関連している伝統的なハンティング用のグループへの同様の方法で提供されたすべての線の同じ加入者番号を提供できるでしょう。
Friend Informational [Page 130] RFC 5024 ODETTE FTP 2 November 2007
[130ページ]友人の情報のRFC5024オデットFTP2007年11月2日
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.
ISDNの明白な利益は速度です。 残念ながら、使用中のコンピュータ・システムの大部分には、今日、限られた額の利用可能なコンピューティングパワーがあります。 ファイル転送モードで使用される複数のアクティブな高速通信線の付属はシステムの上の他のユーザの損傷にかなりの量のCPUリソースを取るかもしれません。
Connecting an ISDN line with the default 2 B channels to your
computer using an X.21 interface is going to give a consistent 64
Kb throughput only if one of the B channels is active at any one
time.
あなたのコンピュータへのX.21インタフェースを使用するデフォルト2BチャネルにISDN回線を接続すると、Bチャネルの1つがいかなる時もアクティブである場合にだけ、64KBの一貫したスループットは与えられるでしょう。
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%.
64KBの2個のチャンネルがあれば、能動態と64KBの独身の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.
また、メインフレームフロントエンドをもっているユーザは、費用が問題であることがわかるでしょう。 コミュニケーションインタフェースをスキャンするスキャナは集合スループットに基づいています。 64KBのインタフェースは何サイクルも取ります。
Determining 'DTE' or 'DCE' Characteristics
'DTE'か'DCE'の特性を決定します。
The following section is an extract from the ISO/IEC 8208
(International Standards Organization, International
Electrotechnical Commission) (1990-03-15) standard, which is an
ISO extension of the CCITT X.25 standard.
以下のセクションはISO/IEC8208(国際Standards Organization、国際電気標準化会議)(1990年3月15日)規格からの抽出です。(それは、CCITT X.25規格のISO拡張子です)。
The restart procedure can be used to determine whether the DTE
acts as a DCE or maintains its role as a DTE with respect to the
logical channel selection during Virtual Call establishment and
resolution of Virtual Call collision.
DTEがVirtual Call衝突のVirtual Call設立と解決の間、論理チャネル選択に関して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.
Packet Layerを初期化するように準備されるとき、DTEは再開手順に着手するものとします(すなわち、RESTART REQUESTパケットを伝えてください)。 決断は以下に概説されているようにデータ交換設備(DXE)から受けられた応答に基づいています。
a) If the DTE receives a RESTART INDICATION packet with a
restarting cause code that is not 'DTE Originated' (i.e., it
came from a DCE), then the DTE shall maintain its role as a DTE.
a) DTEが'DTE Originated'でない再開している原因コードでRESTART INDICATIONパケットを受けるなら(すなわち、それはDCEから来ました)、DTEはDTEとして役割を維持するものとします。
Friend Informational [Page 131] RFC 5024 ODETTE FTP 2 November 2007
[131ページ]友人の情報のRFC5024オデットFTP2007年11月2日
b) If the DTE receives a RESTART INDICATION packet with a
restarting cause code of 'DTE Originated' (i.e., it came from
another DTE), then the DTE shall confirm the restart and act as
a DCE.
b) DTEが'DTE Originated'の再開している原因コードでRESTART INDICATIONパケットを受けるなら(すなわち、それは別のDTEから来ました)、DTEはDCEとして再開と行為を確認するものとします。
c) If the DTE receives a RESTART INDICATION packet with a
restarting cause code of 'DTE Originated' (i.e., it came from
another DTE) and it does not have an unconfirmed RESTART REQUEST
packet outstanding (i.e., a restart collision), then the DTE
shall consider this restart procedure completed but shall take
no further action except to transmit another RESTART REQUEST
packet after some randomly chosen time delay.
c) DTEが'DTE Originated'の再開している原因コードでRESTART INDICATIONパケットを受けて(すなわち、それは別のDTEから来ました)、未払いの未確認のRESTART REQUESTパケット(すなわち、再開衝突)を持っていないなら、DTEは、完成しますが、何らかの手当たりしだいに選ばれた時間遅れの後に別のRESTART REQUESTパケットを伝える以外に、この再開手順がこれ以上行動を取らないだろうと考えるものとします。
d) If the DTE issues a RESTART REQUEST packet that is subsequently
confirmed with a RESTART CONFIRMATION packet, then the DTE shall
maintain its role as a DTE.
d) DTEが次にRESTART CONFIRMATIONパケットで確認されるRESTART REQUESTパケットを発行するなら、DTEはDTEとして役割を維持するものとします。
Acknowledgements
承認
This document draws extensively on revision 1.4 of the ODETTE File Transfer Specification [OFTP].
このドキュメントは手広くオデットFile Transfer Specification[OFTP]の改正1.4を利用します。
Many people have contributed to the development of this protocol and their work is hereby acknowledged.
多くの人々がこのプロトコルの開発に貢献しました、そして、彼らの仕事はこれにより承諾されます。
Normative References
引用規格
[CMS-Compression]
Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[cm圧縮] ガットマン、P.、「暗号のメッセージ構文(cm)のためのデータの圧縮された内容タイプ」、RFC3274、2002年6月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[ISO-646] International Organisation for Standardisation, ISO
Standard 646:1991, "Information technology -- ISO 7-bit
coded character set for information interchange", 1991.
Standardisation、ISO Standardのための[ISO-646]国際Organisation、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インチ、RFC3447、2月2003日
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[UTF-8] Yergeau, F., "UTF-8, A Transformation Format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
Friend Informational [Page 132] RFC 5024 ODETTE FTP 2 November 2007
[132ページ]友人の情報のRFC5024オデットFTP2007年11月2日
[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[ZLIB] ドイツ語、P.、およびJ-L。 ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
Informative References
有益な参照
[ISO-6523] International Organisation for Standardisation, ISO
Standard 6523:1984, "Data interchange -- Structures for
the identification of organisations", 1984.
Standardisation、ISO Standardのための[ISO-6523]国際Organisation、6523:1984 「データは交換されます--機構の識別のための構造」、1984
[OFTP] Organisation for Data Exchange by Tele Transmission in
Europe, Odette File Transfer Protocol, Revision 1.4, April
2000.
ヨーロッパでのテレビトランスミッション、オデットFile Transfer Protocol、改正1.4によるデータ交換のための2000年4月の[OFTP]機構。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985.
[FTP] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RIME] Coleridge, Samuel Taylor, "The Rime of the Ancient
Mariner", 1817.
[霧で覆います] コールリッジ、サミュエル・テイラー、「古代の船員の霜」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.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling", RFC
3850, July 2004.
[RFC3850] Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書取り扱い」、RFC3850、2004年7月。
Friend Informational [Page 133] RFC 5024 ODETTE FTP 2 November 2007
[133ページ]友人の情報のRFC5024オデットFTP2007年11月2日
ODETTE Address
オデットAddress
The ODETTE File Transfer Protocol is a product of the Technology Committee of Odette International. The Technology Committee can be contacted via the ODETTE Central Office:
オデットFile Transferプロトコルはオデットの国際Technology Committeeの製品です。 オデットセントラルオフィスを通してTechnology Committeeに連絡できます:
ODETTE INTERNATIONAL Limited Forbes House Halkin Street London SW1X 7DS United Kingdom
オデット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 9227Fax: +44 (0)171 235 7112はメールされます: 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はメールされます: ieuan.friend@dip.co.uk
Friend Informational [Page 134] RFC 5024 ODETTE FTP 2 November 2007
[134ページ]友人の情報のRFC5024オデットFTP2007年11月2日
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Friend Informational [Page 135]
友人情報です。[135ページ]
一覧
スポンサーリンク
