RFC238 日本語訳
0238 Comments on DTP and FTP proposals. R.T. Braden. September 1971. (Format: TXT=2735 bytes) (Updates RFC0171, RFC0172) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. T. Braden Request for Comments #238 UCLA-CCN NIC #7663 September 29, 1971 Category: Updates: RFC #171, RFC #172
コメント#238UCLA-CCN NIC#7663 1971年9月29日カテゴリを求めるワーキンググループR.T.ブレーデン要求をネットワークでつないでください: アップデート: RFC#171、RFC#172
COMMENTS ON DTP AND FTP PROPOSALS
DTPのコメントとFTP提案
Data Transfer Protocol ----------------------
データ転送プロトコル----------------------
1. In the Descriptor/Count mode, the Information Separators should have a transaction sequence number field. Otherwise, the receiver cannot be sure he received all transactions before the separation. This requires that there be two forms of information separators, one for Descriptor/Count mode, the other for the DLE mode.
1. Descriptor/カウントモードで、情報Separatorsには、トランザクション一連番号分野があるはずです。 さもなければ、受信機は彼が分離の前にすべてのトランザクションを受けたのを確信しているはずがありません。 これは2が情報分離のフォーム、Descriptor/カウントモードのためのもの、DLEモードのためのもう片方であったならそこでそれを必要とします。
2. The modes-available handshake should not be mandatory, as it makes no sense in the simplex case. The receiver doesn't care what modes the transmitter _might_ use; he only cares what mode _is_ used, which he discovers when the first data or control transaction arrives. Even in the duplex case, it is not clear what use the receiver should make of the modes-available information from the transmitter.
2. シンプレクス場合で意味をなさないときに、利用可能なモード握手は義務的であるべきではありません。 受信機は、_が送信機_がそうするかもしれないすべてのモードを使用するかを気にかけません。 彼が、どんなモード_が使用される_であるかを気にかけるだけですか、またはコントロールトランザクションは到着します。(最初のデータであるときに、彼は_を発見します)。 複式の場合ではさえ、受信機が送信機からモード入手可能な情報でどんな使用をするはずであるかは、明確ではありません。
File Transfer Protocol ----------------------
ファイル転送プロトコル----------------------
1. The protocol allows an end-of-file to be indicated by closing the connection. This is the same mistake which we made in an early version of NETRJS. Closing the connection without a File Separator transaction should only be used to indicate an error, i.e., to abort the transmission; it should never be used to indicate normal completion of file transfer. The reason is obvious: there is no way for the receiver to tell whether CLS indicates normal completion or an abnormal condition in the other host (e.g. the file transfer program died).
1. プロトコルは、ファイルの終りが接続を終えることによって示されるのを許容します。 これはNETRJSの早めのバージョンに関する同じ誤りです。 File Separatorトランザクションなしで接続を終えるのがすなわち、トランスミッションを中止するために誤りを示すのに使用されるだけであるべきです。 それは、ファイル転送の正常完了を示すのに決して使用されるべきではありません。 理由は明白です: 受信機が、CLSがもう片方のホストで正常完了か異常な状態を示すかどうか(例えばファイル転送プログラムは消え失せました)言う方法が全くありません。
2. There should be two forms of the _store_ request, one which fails if a file of the same name already exists, and one which replaces an existing file of the same name (as now).
2. 2つのフォームの_店_要求、同じ名前のファイルが既に存在しているなら失敗するもの、および同じ名前(現在のように)に関する既存ファイルに取って代わる1つがあるべきです。
3. A service center host may be expected to require username and password transactions before any others are accepted.
3. どんな他のものも受け入れる前にサービスセンターのホストがユーザ名とパスワードトランザクションを必要とすると予想されるかもしれません。
4. There are no error transactions defined for lost data or lost synch. It is assumed there are handled at the DTP level?
4. ロストデータか無くなっている同時性のために定義された誤りトランザクションが全くありません。 レベルがDTPで扱われると思われますか?
5. All of the defined error codes should be allowed (and encouraged) to have explanatory text following them.
5. それらに続いて、定義されたエラーコードのすべてが説明しているテキストを持つことができるべきです(そして、奨励されます)。
[Page 1] RTB:gjm [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 12/96 ]
RTB: [1ページ]gjm[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームであった]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの方向。 12/96 ]
[Page 2]
[2ページ]
一覧
スポンサーリンク