RFC747 日本語訳
0747 Recent extensions to the SUPDUP Protocol. M.R. Crispin. March 1978. (Format: TXT=2870 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
NWG/RFC# 747 MRC 21-MAR-78 44015 Recent Extensions to the SUPDUP Protocol
SUPDUPプロトコルへのNWG/RFC#747のMRCの21 3月の78 44015の最近の拡張子
Network Working Group Mark Crispin Request for Comments 747 SU-AI NIC 44015 21 March 1978
ネットワークワーキンググループのマーククリスピンはコメント747SU-AI NIC44015のために1978年3月21日を要求します。
Updates: RFC 734. See also RFC 746.
アップデート: RFC734。 また、RFC746を見てください。
Recent Extensions to the SUPDUP Protocol
SUPDUPプロトコルへの最近の拡大
Recently, some extensions have been made to the SUPDUP protocol. RFC 746, by Richard Stallman, documented the SUPDUP graphics extension. In addition, a TTYOPT bit has been added and two more variables have been added to the initial negotiation. This RFC describes the changes from RFC 734, but excludes the detailed information in RFC 746. These extensions are upwards and downwards compatable, and are completely optional. For most SUPDUP user and server programs, RFC 734 remains an adequate description of the protocol. However, it is suggested that if the console's line speed is known, the user SUPDUP should be modified to send the new ISPEED and OSPEED variables (sending 0 for SMARTS if the graphics extension is not to be used) so the server can handle buffering for the terminal better.
最近、いくつかの拡大をSUPDUPプロトコルにしました。 リチャード・ストールマンで、RFC746はSUPDUPグラフィックス拡張子を記録しました。 さらに、TTYOPTビットは加えられます、そして、もう2つの変数が初期の交渉に加えられます。 このRFCはRFC734から変化について説明しますが、RFC746で詳細な情報を除きます。 これらの拡大が上向きに、そして、下向きにそう、compatableして、完全に任意です。 ほとんどのSUPDUPユーザとサーバプログラムのために、RFC734はプロトコルの適切な記述のままで残っています。 しかしながら、コンソールのライン・スピードが知られているなら、ユーザSUPDUPがサーバが端末のためのバッファリングをよりよく扱うことができるように、変数(グラフィックス拡大が使用されていないことであるならSMARTSのために0を送る)を新しいISPEEDとOSPEEDに送るように変更されるべきであると示唆されます。
Since these changes are compatable and optional, and since the SUPDUP protocol is being actively worked on at the present time, I have elected to issue this update RFC rather than an updated version of RFC 734. An updated 734 will be issued when the protocol stabilizes again.
これらの変化がcompatableであって、任意であり、現在で活発にSUPDUPプロトコルに働いているので、私は、RFC734のアップデートされたバージョンよりむしろこのアップデートRFCを発行するのを選びました。 プロトコルが再び安定しているとき、アップデートして、734は発行されるでしょう。
Three new variables have been added to the initial negotiation. In order, they are SMARTS, ISPEED, and OSPEED. Consequently, the count should now be -10,,0, or, in octal, 777770000000.
3つの新しい変数が初期の交渉に加えられます。 オーダーでは、それらは、SMARTSと、ISPEEDと、OSPEEDです。 現在その結果、カウントが-10であるべきである、0、または8進における777770000000
The SMARTS variable specifies what "smarts" (in general, what graphics capabilities) the terminal has. Like the TTYOPT variable, a bit being true implies that the terminal has this option. RFC 746 describes this variable and the SUPDUP graphics option in complete detail. If the graphics extension is not to be used, SMARTS should be set to 0.
可変SMARTSは、何が「痛むか」を指定します。(一般に、何というグラフィックス能力) 端末はそうしたか。 TTYOPT変数のように、少し本当であるのは、端末にはこのオプションがあるのを含意します。 RFC746は遺漏なく詳細にこの変数とSUPDUPグラフィックスオプションについて説明します。 グラフィックス拡大が使用されていないことであるなら、SMARTSは0に用意ができるべきです。
The ISPEED and OSPEED variables are respectively the input and output baud rates of the terminal, if known. For example, a 150./1200. baud terminal would have an ISPEED of 150. and an OSPEED of 1200. A speed of zero means the line speed is indeterminate.
知られているなら、ISPEEDとOSPEED変数はそれぞれ端末の入出力ボーレートです。 例えば、a150./1200ボー端末には、150のISPEEDと1200年のOSPEEDがあるでしょう。 ゼロの速度は、ライン・スピードが不確定であることを意味します。
The %TPPRN TTYOPT bit (value 0,,200) has been added. This bit specifies that the system should swap parenthesis with square brackets on input. This is often desirable for LISP users who are using a terminal which has parenthesis as a shift character but not square brackets. This bit is normally off and servers are not required to implement it.
%TPPRN TTYOPTが噛み付いた、(値、0 200は)加えられます。 このビットは、システムが入力での角括弧で挿入句を交換するはずであると指定します。 角括弧ではなく、シフト文字として挿入句を持っている端末を使用しているLISPユーザにとって、これはしばしば望ましいです。 通常、このビットはオフです、そして、サーバは、それを実装するのに必要ではありません。
-1-
-1-
一覧
スポンサーリンク