RFC1053 日本語訳
1053 Telnet X.3 PAD option. S. Levy, T. Jacobson. April 1 1988. (Format: TXT=48952 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Levy
Request for Comments: 1053 T. Jacobson
Minnesota Supercomputer Center
April 1988
コメントを求めるワーキンググループS.課税要求をネットワークでつないでください: 1053 T.ジェーコブソンミネソタスーパーコンピュータセンター1988年4月
Telnet X.3 PAD Option
telnet X.3パッドオプション
Status of this Memo
このMemoの状態
This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティのために新しいオプションをTelnetに提案して、改良のために議論と提案を要求します。 このメモの分配は無制限です。
1. Command name and code
1. コマンド名とコード
X.3-PAD 30
X.3-パッド30
2. Command meanings
2. コマンド意味
IAC DO X.3-PAD
IACはX.3そっと歩きます。
The issuing telnet requests that its peer perform X.3-PAD
functions, or accepts an offer to do so.
発行telnetは、同輩がX.3-PAD機能を実行するよう要求するか、またはそうするという申し出を受け入れます。
IAC DON'T X.3-PAD
IACはX.3そっと歩きません。
The issuing telnet demands that its peer not perform or cease
performing X.3-PAD functions.
発行telnetは、同輩がX.3-PAD機能を実行しながら働きもしませんし、やみもしないのを要求します。
IAC WILL X.3-PAD
IACウィルX.3-PAD
The issuing telnet offers to perform X.3-PAD functions or confirms
that it will do so.
発行telnetは、X.3-PAD機能を実行すると申し出るか、またはそれがそうすると確認します。
IAC WON'T X.3-PAD
IACはX.3そっと歩かないでしょう。
The issuing telnet refuses to perform X.3-PAD functions or
indicates that it is ceasing to handle them.
発行telnetは、X.3-PAD機能を実行するのを拒否するか、またはそれらを扱うのをやめているのを示します。
Typically a server (host) telnet will use DO and DON'T, while a client (user) telnet will use WILL and WON'T. For convenience, in the rest of this RFC 'host' and 'user' telnets refer to those saying 'DO X.3-PAD' or 'WILL X.3-PAD' respectively.
そしてであるだろうそして、通常、(ホスト)telnetが使用するサーバがする、クライアント(ユーザ)telnetがウィルを使用する。 便利について、このRFC'ホスト'と'ユーザ'の残りでは、telnetはそれぞれ'DO X.3-PAD'か'WILL X.3-PAD'を言うものについて言及します。
Both telnet peers may use this option without confusion, as all messages unambiguously identify whether they come from the host
すべてのメッセージが、それらがホストから来るかどうか明白に特定するとき、両方のtelnet同輩は混乱なしでこのオプションを使用するかもしれません。
Levy & Jacobson [Page 1] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[1ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
("DO") or the user ("WILL") side.
(「してください」)かユーザ(“WILL")が面があります。
Once DO and WILL have been exchanged, the host ("DO") telnet may
send the following messages:
一度して、ウィルを交換しました、そして、ホスト(「する」)telnetは以下のメッセージを送ってもよいです:
IAC SB X.3-PAD SET <param1> <value1> ... IAC SE IAC SB X.3-PAD RESPONSE-SET <param1> <value1> ... IAC SE IAC SB X.3-PAD SEND IAC SE
IAC SB X.3-パッドは<param1><value1>を設定しました… IAC SE IAC SB X.3-パッド応答セット<param1><value1>… IAC SE IAC SB X.3-パッドはIAC SEを送ります。
while the user ("WILL") telnet may send the following messages:
ユーザ(“WILL")telnetは以下のメッセージを送るかもしれませんが:
IAC SB X.3-PAD IS <param1> <value1> ... IAC SE IAC SB X.3-PAD RESPONSE-IS <param1> <value1> ... IAC SE
IAC SB X.3-パッドは<param1><value1>です… IAC SE IAC SB X.3-パッド、応答存在、<param1><value1>… IAC SE
The code for SET is 0 The code for RESPONSE-SET is 1 The code for IS is 2 The code for RESPONSE-IS is 3 The code for SEND is 4
SETのためのコードが0である、RESPONSE-SETのためのコードが1である、コード、2である、コード、RESPONSE存在、3である、SENDのためのコードは4です。
Messages listing parameter-value pairs may contain any number of
such pairs, including zero. Each parameter and each value
occupies one octet, except that 255 (IAC) is doubled wherever it
appears.
パラメタ価値の組を記載するメッセージはゼロを含むそのようないろいろな組を含むかもしれません。 各パラメタと各値は1つの八重奏を占領して、どこに見えても、その255を除いて、(IAC)は倍にされます。
3. Default conditions
3. デフォルト条件
The initial state is DON'T X.3-PAD, WON'T X.3-PAD. This RFC does not specify default values for most X.3 parameters. If the host telnet wishes a particular initial state (as it normally will), it should negotiate for it after exchange of DO/WILL messages.
初期状態はDON'T X.3-PAD、WON'T X.3-PADです。 このRFCはほとんどのX.3パラメタにデフォルト値を指定しません。 ホストtelnetが特定の初期状態を願うなら(それのように、通常、望んでください)、交換の後にそれを交渉するべきである、/ウィルメッセージをしてください。
X.3-PAD parameter values need not be preserved except when DO/WILL
X.3-PAD is in effect. Thus if a host enables ("DO") X.3-PAD,
negotiates about some parameters, then for some reason disables
("DONT") and later re-enables X.3-PAD, it must renegotiate any
parameters it cares about.
X.3-PADパラメタ価値は守られる必要はありません、そして、いつが/をするか。WILL X.3-PADは有効です。 したがって、ホストがX.3-パッドを可能にして(「する」)、いくつかのパラメタを交渉して、次に、ある理由で(「ドント」)を無効にして、後でX.3-パッドを再可能にするなら、それは心配するどんなパラメタも再交渉しなければなりません。
Keeping in mind that the host telnet may not recognize all the parameters known to the user telnet, it is suggested that the user telnet's initial parameters allow a reasonable level of service even if they are never changed (e.g., it would be unwise to begin with all data forwarding conditions disabled). Extensions to X.3 should default to states resembling normal X.3 service where possible.
ホストtelnetがユーザtelnetに知られているすべてのパラメタを認識しないかもしれないのを覚えておいて、それらを決して変えないでもユーザtelnetの初期値パラメタが妥当な水準のサービスを許すことが提案される、(例えば、それが初めに賢明でないだろう、推進状態が無効にしたすべてのデータ) X.3への拡大は可能であるところで通常のX.3サービスに類似している州をデフォルトとするべきです。
Levy & Jacobson [Page 2] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[2ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
4. Motivation for the option
4. オプションに関する動機
Where interactive terminals (or computers simulating them) are attached to host computers across a network, it is often desirable to provide them the same services as have long been provided for terminals directly attached to those hosts.
会話型端末装置(または、それらをシミュレートするコンピュータ)がネットワークの向こう側にホストコンピュータに取り付けられるところでは、同じサービスをそれらに提供するのは長い間直接それらのホストに愛着している端末に供給しているようにしばしば望ましいです。
Many systems handle this by simply leaving all character processing to the host running the applications. Each character typed by the user is sent, often in its own packet, immediately to the host. This gives good control over interaction, but can cause a significant load on hosts and networks. Long-distance packet networks tend to be unreasonably slow or expensive or both when used in this mode.
多くのシステムが、単にアプリケーションを実行するホストにすべての文字処理を任せることによって、これを扱います。 しばしばそれ自身のパケットと、すぐホストにユーザによってタイプされた各文字を送ります。 これは、良い支配力を相互作用の上に与えますが、ホストとネットワークでかなりの負荷を引き起こす場合があります。 または、長距離のパケット網が、無分別に遅いか、または高価である傾向がある、ともにこのモードで使用されると。
Suitable character processing on the client (near the user's terminal) can greatly improve the situation. Unfortunately for standardization efforts, there are many possible approaches with differing purposes.
クライアント(ユーザの端末の近くの)における適当な文字処理は大いに状況を改善できます。 残念ながら、標準化取り組みのために、異なった目的に関する多くの可能なアプローチがあります。
Some have already been proposed as Telnet options. The Remote Controlled Transmission and Echo option, [3], provides fine control over local buffering and echoing. The SUPDUP option, [4], offers a variety of input and display functions in terminal-independent form.
或るものはTelnetオプションとして既に提案されました。 Remote Controlled TransmissionとEchoオプション([3])は地方のバッファリングと反響の上にファイン制御を提供します。 SUPDUPオプション([4])は端末から独立しているフォームでさまざまな入力と画面ファンクションを提供します。
This RFC's proposal is intended to support efficient, approximate emulation, across a Telnet connection, of a host's normal handling of character-oriented terminals. Ideally, a user and an application program would not need to know whether they were linked by an RS-232 line or a TCP/IP network, except where the medium required a distinction (e.g., when establishing a connection).
このRFCの提案が効率的で、大体のエミュレーションをサポートすることを意図します、ホストのキャラクタ指向の端末の通常の取り扱いのTelnet接続の向こう側に。 理想的に、ユーザとアプリケーション・プログラムは、それらがRS-232系列かTCP/IPネットワークによってリンクされたかどうかを知る必要はないでしょう、媒体が区別を必要とした(例えば、取引関係を築くとき)ところを除いて。
Server implementors would wish for enough to emulate, purely locally, everything offered by their host's operating system; on the other hand, a standard calling on user telnets to provide all terminal handling functions of all known operating systems will find few implementors. One might settle on a subset of common operations, but which ones?
作成者が、十分に純粋に局所的に見習って欲しいだろうサーバ、彼らのホストのオペレーティングシステムで提供されたすべて。 他方では、ユーザtelnetがすべての知られているオペレーティングシステムのすべての端末の取り扱い機能を提供するよう呼びかける規格はわずかな作成者しか見つけないでしょう。 人は一般的な操作の部分集合について決めるかもしれませんが、どれですか?
The CCITT world has used one approach to these problems: the set of PAD services defined by recommendation X.3. This RFC proposes that the Internet community adopt that solution to handle the same problems under Telnet. It is fairly simple, widely known and used, extensible, and solves most of the relevant problems.
CCITT世界はこれらの問題への1つのアプローチを使用しました: 推薦X.3によって定義されたPADサービスのセット。 このRFCは、インターネット共同体がTelnetの下で同じ問題を扱うためにそのソリューションを採用するよう提案します。 それは、かなり簡単であって、広く知られていて中古であって、広げることができて、関連のある問題の大部分を解決します。
Adopting X.3 would have another advantage. X.25 is the dominant worldwide standard interface between commercial packet networks and Internet systems, as evidenced by the DDN's adoption of X.25 basic and standard services as replacements for BBN 1822 and HDH. Telnet
X.3を採用するのにおいて、別の利点があるでしょう。 X.25はBBN1822とHDHとの交換としてDDNのX.25の基本的で標準のサービスの採用で証明されるように商業パケット網とインターネット・システムの間の優位な世界的な標準インターフェースです。 telnet
Levy & Jacobson [Page 3] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[3ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
and X.3 PAD traffic will have to coexist on X.25 networks; there will be a consequential desire for effective interoperation at the virtual terminal level. Extending Telnet along these lines would vastly simplify bridging the two.
そして、X.3 PADトラフィックはX.25ネットワークに共存しなければならないでしょう。 有効なinteroperationに関するゆゆしい願望が仮想端末レベルにあるでしょう。 2をブリッジするこれらの系列に沿ったTelnetが広大に簡素化する広がり。
Described here is a scheme for implementing X.3 services and negotiating their parameters across a Telnet connection.
ここで説明されているのは、Telnet接続の向こう側にX.3にサービスを実装して、それらのパラメタを交渉するのが体系です。
5. Description of the option
5. オプションの記述
Many, though not all, X.3 services are meaningful in the context of remote terminal processing; for some, it may be desirable to allow local control (by the user) but not remote control (by the server host). Some functions may not be provided, or provided in only limited form, by particular implementations. In general, an implementation should follow the Telnet norm of requesting desired service but continuing to function somehow in case it is not available.
多くであり、すべてではありませんが、X.3サービスは遠隔端末処理の文脈で重要です。 いくつかに関しては、遠隔操作(サーバー・ホストによる)ではなく、現場制御(ユーザによる)を許容するのは望ましいかもしれません。 特定の実装はいくつかの機能を限局型だけに提供しませんし、また提供しないかもしれません。 一般に、実装はそれが利用可能でないといけないので、必要なサービスを要求しますが、どうにか機能し続けるTelnet標準に続くべきです。
Negotiations are asymmetrical. Since the user telnet is charged with local character handling while engaged in the session with the remote host, the X.3 parameters "belong" to the user side. The host telnet requests parameter changes with SET or RESPONSE-SET messages. Host requests might be on behalf of an application program, for example, disabling local echo while a password is being entered. The user telnet should give its "best effort" to accommodate these requests, but guarantees nothing except accurate status reporting.
交渉は非対称的です。 リモートホストとのセッションに従事している間、地方のキャラクタ取り扱いでユーザtelnetを告発するので、X.3パラメタはユーザ側に「属します」。 ホストtelnetはSETかRESPONSE-SETメッセージでパラメータ変動を要求します。 ホスト要求は、アプリケーション・プログラムを代表して例えば、パスワードが入力されている間、ローカルエコーを無効にしながら、いるかもしれません。 ユーザtelnetはそれがしかし、これらの要求に対応するために「ベストエフォート型である」という保証に正確な状態報告以外の何も与えるべきではありません。
A user telnet may allow the local user to request parameter changes too, though this RFC does not specify a way.
地元のユーザはユーザtelnetからパラメータ変動も要求できるかもしれません、このRFCが道を指定しませんが。
Where requests conflict, or where a user telnet cannot satisfy a request, the user telnet has the last word, since it does the relevant character processing. It may allow control from the host only, from the user only, may seek a compromise type of processing and so on, at the implementor's discretion.
要求が闘争できないか、ユーザtelnetが要望に応じることができないところでは、ユーザtelnetは締め括りの言葉を持っています、関連文字処理をするので。 それはホストだけからコントロールを許すかもしれません、ユーザだけから処理などの感染タイプを求めるかもしれません、作成者の裁量で。
Host ("DO") telnets may also ask the user telnet to SEND its current
parameter values. The user ("WILL") telnet must reply to each SEND
message with a RESPONSE-IS message listing the values of all the
parameters it knows about. It is strongly recommended that all
parameters known to the telnet implementor be included in this list,
even if their values cannot be changed. The intent is to give the
host telnet the most complete information possible about the style of
interaction which the user telnet is providing.
また、ホスト(「する」)telnetは、現在のパラメタ値を送るようにユーザtelnetに頼むかもしれません。 ユーザ(“WILL")telnetがそれぞれaがあるメッセージを送るために返答しなければならない、応答存在、それが知っているすべてのパラメタの値を記載するメッセージ。 telnet作成者にとって知られているすべてのパラメタがこのリストに含まれることが強く勧められます、それらの値を変えることができないでも。 意図はユーザtelnetが供給している相互作用のスタイルに関して可能な最も完全な情報をホストtelnetに教えることです。
If possible, user telnets should also inform the server host (with an IS message) whenever local conditions (e.g., user requests) change a
現地の状況(例えば、ユーザ要求)がaを変えるときはいつもまた、できれば、ユーザtelnetがサーバー・ホストに知らせるべきである、(メッセージ)。
Levy & Jacobson [Page 4] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[4ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
parameter's state. This may not be feasible in some circumstances, and such behavior is negotiable -- see the discussion of parameter 0.
パラメタの状態。 そのような振舞いは交渉可能です--これはいくつかの事情で可能でないかもしれません、そして、パラメタ0の議論を見てください。
Note that there are no "error" messages defined in section 2. Almost all detectable errors (use of nonexisistent parameters or undefined values for known parameters) are indistinguishable from valid uses of options known to one peer but not the other. Hosts will normally wish to poll the user telnet's state after making a request anyway, so error responses do not seem to be needed.
セクション2で定義された「誤り」メッセージが全くないことに注意してください。 ほとんどすべての検出可能な誤り(nonexisistentパラメタか未定義値の知られているパラメタの使用)がもう片方ではなく、1人の同輩にとって知られているオプションの有効な用途から区別がつきません。 とにかく要求をした後にホストが通常ユーザtelnetの状態に投票したくなるので、誤り応答は必要であるように思えません。
The protocol messages listed in section 2 are to be used as follows.
セクション2でリストアップされたプロトコルメッセージは以下の通り使用されることです。
SET and RESPONSE-SET ask the user telnet to change its values for the given X.3 parameters. The user telnet ignores unrecognized parameters; it sends no reply. The host sends SET to begin a negotiation, when some event on the host side causes a change in the desired set of parameters. The host sends RESPONSE-SET to continue negotiation, when it is dissatisfied with the user telnet's choice of parameters indicated in a RESPONSE-IS message. Typically, the host will test the user telnet's chosen behavior by issuing a SEND message following the SET or RESPONSE-SET, though the user telnet should not rely on this.
SETとRESPONSE-SETは、与えられたX.3パラメタのために値を変えるようにユーザtelnetに頼みます。 ユーザtelnetは認識されていないパラメタを無視します。 それは回答を全く送りません。 ホストは交渉を始めるためにSETを送ります、ホスト側の上の何らかのイベントが必要なセットのパラメタにおける変化を引き起こすと。 ホストは交渉を続行するためにRESPONSE-SETを送ります、中に示されたパラメタのユーザtelnetの選択がある状態でそれが不満であるときにRESPONSE存在、メッセージ 通常、ホストはSETかRESPONSE-SETに続いて、SENDメッセージを発行することによって、ユーザtelnetの選ばれた振舞いをテストするでしょう、ユーザtelnetがこれを当てにするべきではありませんが。
A SEND message from the host demands that the user telnet send RESPONSE-IS.
ホストからのSENDメッセージが、ユーザtelnetが発信するのを要求する、RESPONSE存在
IS and RESPONSE-IS inform the host telnet of the current states of some or all of the user telnet's parameters. The user telnet sends IS when the user telnet changes a parameter for some local reason, e.g., at a request from the (human) user. An IS message may but need not list all parameters, e.g., it might list just those which changed.
RESPONSE存在、ユーザtelnetのパラメタについていくつかかすべての現状のホストtelnetを知らせてください。 ユーザtelnetが発信する、要求は例えば、ユーザtelnetが何らかのローカルの理由でパラメタを変えるaで(人間)のユーザから来ていますか? 必要性だけがすべてのパラメタをリストアップするというわけではなくしますようにて、例えば、まさしく変化したものを記載するかもしれないというメッセージはそうです。
It sends RESPONSE-IS in answer to each SEND request from the host. Every RESPONSE-IS should list ALL X.3-PAD parameters known to the user telnet implementor, even those which cannot be changed. Any host requests (SET or RESPONSE-SET) received before a SEND message should be processed before sending the answering RESPONSE-IS, so that their effects are reflected in the parameter values indicated there.
それが発信する、いるホストからのそれぞれのSEND要求に答えてRESPONSE。 あらゆる、RESPONSE存在、ユーザtelnet作成者、変えることができないものにおいてさえ知られているリストALL X.3-PADパラメタはそうするべきです。 SENDメッセージが発信する前に処理されるべき前にどんなホスト要求(SETかRESPONSE-SET)も受信された、回答、RESPONSE存在、それらの効果がそこで示されたパラメタ値に反映されるように。
To permit synchronization (which SEND is this an answer to?), the user telnet should count SEND messages, and send exactly one RESPONSE-IS per SEND.
許可証同期、(どのSEND、これが答えであるか、)?、ユーザtelnetがSENDメッセージを数えて、ちょうど1つを送るべきである、RESPONSE1SENDあたりの存在
One might think that this protocol could be implemented with only SET, SEND and IS messages. The seemingly redundant RESPONSE-SET and RESPONSE-IS codes are needed to let both the user and host telnets distinguish new peer requests from attempts to renegotiate previous
人はこのプロトコルがSETだけ、SENDと共に実装することができて、メッセージであると思うかもしれません。 外観上余分なRESPONSE-SET、RESPONSE存在、ユーザとホストtelnetの両方に前であることの状態で再交渉する試みと新しい同輩要求を区別させるのにコードが必要です。
Levy & Jacobson [Page 5] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[5ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
actions, while preventing potential infinite negotiation loops.
潜在的無限のネゴシエーション・ループを防いでいる間の動作。
SET and IS messages are sent when the host or user telnet wishes to inform its peer of a change in the X.3 processing mode desired by some higher level entity. This might happen at initialization, or on user or application-program request. The important thing is that these messages are NOT sent merely in response to another X.3-PAD message from the peer.
SET、ホストか何らかのより高い平らな実体によって望まれていたX.3処理モードにおける変化について同輩に知らせるというユーザtelnet願望であるときに、メッセージを送るということです。 これは初期化において、または、ユーザかアプリケーション・プログラム要求ときの起こるかもしれません。 重要なものはこれらのメッセージが単に同輩からの別のX.3-PADメッセージに対応して送られないということです。
RESPONSE-SET and RESPONSE-IS messages should be sent in reply to a peer's [RESPONSE-]IS or SEND message. They reflect negotiation at the telnet level, rather than changes in the higher-level environment. A host which sends a SEND message may complain about the status indicated in the answering RESPONSE-IS by sending RESPONSE-SET but not SET.
RESPONSE-SET、RESPONSE存在、メッセージは同輩の[RESPONSE]に関する送られた回答がそうであるかSENDがメッセージであるということであるべきです。 彼らは、よりハイレベルの環境における変化よりむしろtelnetレベルで交渉を反映します。 SENDメッセージを送るホストが中に示された状態の周りで不平を言うかもしれない、回答、RESPONSE存在、SETではなく、RESPONSE-SETを送ることによって。
Under this scheme, a possible rule for preventing infinite negotiations would be for the host to send at most zero, one, or some fixed number, of RESPONSE-SET messages following receipt of one IS message or one higher-level host-side request. After that, the host telnet simply accepts the user telnet's last offer as well as it can. Note that only the host needs to worry about loop prevention, since it does all the asking.
1の領収書に従うRESPONSE-SETメッセージの1、または何らかの定数が、この体系の下では、無限の交渉を防ぐための可能な規則がホストがゼロを高々送るだろうことである、メッセージまたは1つのよりハイレベルのホストサイド要求です。 その後に、ホストtelnetは、受け入れることができるようにユーザtelnetの最後の申し出が良いと単に受け入れます。 すべて尋ねることをするので、ホストだけが、輪の防止を心配する必要に注意してください。
A given parameter should not be listed more than once in a single message.
ただ一つのメッセージの一度より与えられたパラメタをもう少しリストアップするべきではありません。
A sample negotiation might look like this. (Here line breaks are not meaningful; ASCII carriage returns and line feeds are indicated by <CR> and <LF>; other characters stand for themselves. In the IAC SB octet values.)
サンプル交渉はこれに似るかもしれません。 (ここで、ラインブレイクは重要ではありません。 ASCII復帰と改行は<CR>と<LF>によって示されます。 他のキャラクタは自分たちに立候補します。 IAC SB八重奏値で。)
Levy & Jacobson [Page 6] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[6ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Host: <CR><LF>%
(User types "cd gibber<CR>")
User: cd gibber<CR><LF>
Host: Password required.<CR>LF>
(Host disables echoing)
IAC SB X.3-PAD SET 2 0 IAC SE
(Host polls for status)
IAC SB X.3-PAD SEND IAC SE
User: (User telnet has disabled local
echo. Note that some
parameters (e.g., 9, 10, 11)
are not present, presumably
unimplemented, and a few
extension parameters
(129, 134) in extension
set 1 are also defined.)
IAC SB X.3-PAD RESPONSE-IS 1 29 2 0 3 2 4 0 5 0 7 17 8 0
12 0 13 3 15 1 16 8 17 21 18 0
128 1 129 23 134 1 IAC SE
Host: password:
(User types "squeak<CR>",
User: squeak<CR><LF> which is not echoed.)
Host: (Host re-enables echoing)
IAC SB X.3-PAD SET 2 1 IAC SE
(Host polls for status)
IAC SB X.3-PAD SEND IAC SE
User:
IAC SB X.3-PAD RESPONSE-IS 1 29 2 1 3 2 4 0 5 0 7 17 8 0
12 0 13 3 15 1 16 8 17 21 18 0
128 1 129 23 134 1 IAC SE
以下を接待してください。 <CR><LF>%(ユーザタイプは「cdに、<CR>に早口でしゃべる」)ユーザ: cdは<CR><LF>Hostに早口でしゃべらせます: パスワードは. <CR>LF>(ホストは反響を無効にする)IAC SB X.3-PAD SET2 0IAC SE(状態のためのホスト投票)IAC SB X.3-PAD SEND IAC SE Userを必要としました: (ユーザtelnetはローカルエコーを無効にしました。 いくつかのパラメタ(例えば、9、10、11)が現在でなくて、おそらく、非実装されて、また、拡大セット1におけるいくつかの拡大パラメタ(129、134)が定義されることに注意してください。) IAC SB X.3-パッド、応答存在、1、29、2 0 3 2 4 0 5 0 7、17、8 0、12、0、13、3、15、1、16、8、17 21 18、0 128 1 129 23 134 1 IAC SEは以下を接待します。 パスワード: (User、ユーザは「キシリ音<CR>」をタイプします: 反響されないキシリ音<CR><LF>) 以下を接待してください。 (ホストは反響を再可能にします) IAC SB X.3-PAD SET2 1IAC SE(状態のためのホスト投票)IAC SB X.3-PAD SEND IAC SE User: IAC SB X.3-パッド、応答存在、1、29、2 1 3 2 4 0 5 0 7、17、8 0、12、0、13、3、15、1、16、8、17 21 18、0、128、1、129、23、134、1IAC SE
6. Parameters
6. パラメタ
In outline, the X.3-PAD option uses the following parameters.
アウトラインでは、X.3-PADオプションは以下のパラメタを使用します。
Parameter 0 indicates whether the user telnet notifies the host
about parameter changes made for local reasons.
パラメタ0は、ユーザtelnetがパラメータ変動に関してホストに通知するかどうかがローカルの理由になったのを示します。
Parameters 1 through 22 are basically those of CCITT X.3, with
some changes in interpretation; they are listed in detail below.
パラメタ1〜22は基本的に解釈におけるいくつかの変化を伴うCCITT X.3のものです。 それらは以下に詳細に記載されています。
Parameters 23 through 127 are reserved for potential extensions to
CCITT's X.3 definition.
パラメタ23〜127は潜在的拡大のためにCCITTのX.3定義に予約されます。
Parameter 128 selects an "extension set", determining the meaning
of parameters 129 through 255. One extension set is proposed in
this RFC, others may be added. The extension mechanism is
explained under parameter 128's description.
129〜255にパラメタの意味を決定して、パラメタ128は「拡大セット」を選択します。 1つの拡大セットがこのRFCで提案されて、他のものは加えられるかもしれません。 拡張機能はパラメタ128記述で説明されます。
Levy & Jacobson [Page 7] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[7ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Parameters 129 through 255 are meaningful only when defined in the
extension set indicated by the current value of parameter 128.
パラメタ128の現行価値によって示された拡大セットで定義される場合にだけ、パラメタ129〜255は重要です。
It should NOT be assumed that all implementations will necessarily support all parameters defined here, or all values of those parameters. Supported parameter/value combinations, however, should behave as described here.
すべての実装が必ずここで定義されたすべてのパラメタ、またはそれらのパラメタのすべての値をサポートすると思うべきではありません。 しかしながら、サポートしているパラメタ/値の組み合わせはここで説明されるように振る舞うべきです。
The following parameter is specific to this Telnet option.
以下のパラメタはこのTelnetオプションに特定です。
Parameter 0 -- Notify host of user-initiated parameter changes.
パラメタ0--ユーザによって開始されたパラメータ変動についてホストに通知してください。
Code 0 -- Host is not notified.
Code 1 -- User telnet notifies host by sending IS message.
コード0--ホストは通知されません。 コード1--発信することによってtelnetがホストに通知するユーザはメッセージです。
If the user telnet, for some local reason, changes a parameter,
should it send an IS message to the host? This is desirable, since
the host telnet cannot be sure of knowing the user telnet's current
status otherwise. On the other hand, some user telnets may be
unable to send notification. Consider a user calling from an X.25
PAD through an X.25-to-telnet gateway. The user may change local
PAD parameters freely, but since normal PADs send no message when
this happens, the gateway cannot inform the host telnet. Moreover,
some sloppy host telnets may not wish to know about user parameter
changes.
何らかのローカルの理由で、ユーザtelnetがパラメタを変えるなら、発信するべきである、ホストにはメッセージがありますか? ホストtelnetが別の方法でユーザtelnetの現在の状態を知っているのが確かであるはずがないので、これは望ましいです。 他方では、いくつかのユーザtelnetは通告を送ることができないかもしれません。 X.25 PADからX.25からtelnetへのゲートウェイまで電話をするユーザを考えてください。 自由にもかかわらず、これが起こる場合正常なPADsがメッセージを全く送らないので、ユーザはローカルのPADパラメタを変えるかもしれません、とゲートウェイはホストtelnetを知らせることができません。 そのうえ、いくつかのずさんなホストtelnetはユーザパラメータ変動に関して知りたがっていないかもしれません。
In normal usage, the host will ask to SET parameter 0 to its
preferred state upon initialization; the user telnet accepts the
setting if it can; then the host polls (using SEND) for the user
telnet's decision. A disappointed host might periodically poll for
changes, or admonish the (human) user not to change parameters, or
remain silent and simply work oddly if changes are made.
正常な用法で、ホストは初期化の都合のよい状態へのSETパラメタ0に尋ねるでしょう。 受け入れることができるなら、ユーザtelnetは設定を受け入れます。 そして、ユーザtelnetの決定のためのホスト投票(SENDを使用します)。 変更が行われるなら、失望したホストは、定期的に変化に投票するか、またはパラメタを変えない、静かなままで残って、または奇妙にも絶対に働かないように(人間)のユーザに訓戒するかもしれません。
The following parameters are as defined by the 1984 CCITT X.3 standard.
以下のパラメタが1984年のCCITT X.3規格によって定義されるようにあります。
Numbers are in decimal.
小数には数があります。
Parameter 1 -- Character to escape to local telnet command mode.
パラメタ1--ローカルのtelnetコマンドモードに逃げるキャラクター。
Code 0 -- No ASCII character performs this function (though
some special mechanism, e.g., a function key, still may).
Code 1 -- DLE (ASCII code 16).
Codes 32 through 126 -- ASCII code of the character.
コード0--どんなASCII文字もこの機能を実行しません(何らかの特別なメカニズム、例えば、ファンクションキー、スチール写真がそうするかもしれませんが)。 1をコード化してください--DLE(ASCIIコード16)。 コード32〜126--キャラクタのASCIIコード。
Codes 2 through 31 are not defined by X.3, but might also be taken
to refer to the corresponding ASCII control characters. X.3 seems
to be unable to name SOH (control-A) as a command escape character.
コード2〜31をX.3が定義しませんが、また、対応するASCII制御文字を示すために取るかもしれません。 X.3は、SOHを命名できないように思えます。(a)を制御しているaコマンド拡張文字。
Levy & Jacobson [Page 8] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[8ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Parameter 2 -- Local echo of characters typed by the user.
パラメタ2--ユーザによってタイプされた文字のローカルエコー。
Code 0 -- No local echo.
Code 1 -- Local echo.
0をコード化してください--ローカルエコーがありません。 1--ローカルエコーをコード化してください。
Several echoing styles are possible. Parameter 13 selects whether
a carriage return echoes as itself or as CR LF. Parameter 20 may
suppress echoing of particular ASCII characters. The extension
parameter 134 selects a style for echoing non-printing characters
such as ESC.
いくつかの反響スタイルが可能です。 パラメタ13は、復帰がそれ自体として、または、CR LFとしてまねられるかどうかを選択します。 パラメタ20は特定のASCII文字の反響を抑圧するかもしれません。 拡大パラメタ134はESCなどのような非表示文字の反響のためにスタイルを選択します。
Parameter 3 -- Set of forwarding characters.
パラメタ3--推進キャラクタのセット。
The value is bit-encoded; each nonzero bit specifies a set of
characters. The user telnet should accept characters from the
user's keyboard, buffering them until it receives any of the
specified characters (or until some other forwarding condition is
satisfied, see below), and then sending the buffer to the host.
値はビットによってコード化されています。 それぞれの非零ビットは1セットのキャラクタを指定します。 ユーザtelnetはユーザのキーボードからキャラクタを受け入れるべきです、指定されたキャラクタのどれかを受けるまで(ある他の推進状態が満たされるまで、以下を見てください)彼らをバッファリングして、次に、バッファをホストに送って。
It may forward earlier if necessary, e.g., if it runs out of buffer
space. It MUST eventually forward after receiving one of the
indicated characters.
例えば、バッファ領域を使い果たすなら、必要なら、それは、より早いのを進めるかもしれません。 表示のものを受け取った後に、それは結局、キャラクタを進めなければなりません。
Code 0 -- No forwarding characters.
Code 1 -- Alphanumeric characters (a-z, A-Z, 0-9).
Code 2 -- CR.
Code 4 -- ESC, BEL, ENQ, ACK.
Code 8 -- DEL, CAN, DC2.
Code 16 -- ETX, EOT.
Code 32 -- HT, LF, VT, FF.
Code 64 -- ASCII character codes 0 through 31 not listed above.
0をコード化してください--推進キャラクタがありません。 1をコード化してください--英数字(a-z、0-9のA-Z)。 2をコード化してください--CR。 4をコード化してください--ESC、ベル、ENQ、ACK。 8をコード化してください--DEL、CAN、DC2。 16をコード化してください--ETX、EOT。 32をコード化してください--HT、LF、バーモントff。 コード64--ASCII文字コード0〜31は上に記載しませんでした。
Note that there is no way provided here to forward on printable,
non-alphanumeric characters (punctuation marks).
印刷可能で、非英数字の(句読点)で進めるためにそれがここに提供された道が全くいないことに注意してください。
Codes may be added to select the union of the associated sets of
characters.
コードは、関連キャラクタの組合を選択するために加えられるかもしれません。
Parameter 4 -- Forward after idle time.
パラメタ4--遊休時間の後に前進しています。
When this parameter is nonzero, the user telnet sends its input
buffer to the host after a given period in which no characters are
typed, even if no forwarding character was received.
文字が全くタイプされない与えられた時代の後にこのパラメタが非零であるときに、ユーザtelnetは入力バッファをホストに送ります、推進キャラクタを全く受け取らなかったとしても。
Code 0 -- Infinite time limit.
Codes 1 through 255 -- Time limit in 1/20 second units.
0--無限のタイムリミットをコード化してください。 コード1〜255--Timeは2番目でユニットを制限します。
The value "1" may be taken to mean "forward immediately" if timed
値、「1インチを取るかもしれない、調節されているなら平均が「すぐに、進める」、」
Levy & Jacobson [Page 9] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[9ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
input is inconvenient to provide. For other values, when timing is
available but the exact requested value is not, rounding to larger
time delays is suggested. If timing is requested but none is
available, immediate forwarding on every character is much
preferred over an infinite time limit.
入力は、提供するために不便です。 タイミングが利用可能ですが、正確な要求された値が利用可能であるというわけではないときに、他の値において、より大きい時間が遅らせる船首を風上に向けて停泊するのは示されます。 タイミングが要求されていますが、なにも利用可能でないなら、すべてのキャラクタにおける即座の推進は無限のタイムリミットより非常に好まれます。
Note the interaction with parameter 15, Local editing, and the
notes made under that heading.
その見出しの下で作られたパラメタ15、Local編集、およびメモとの相互作用に注意してください。
Parameter 5 -- Flow control of user-to-host data.
パラメタ5--ユーザからホストへのデータのフロー制御。
A user telnet may be overwhelmed by data typed by the user. If
parameter 5 is 1, it may output X-OFF (DC3, ASCII code 19) to ask
the user to suspend input and X-ON (DC1, ASCII code 17) when the
user may resume typing.
ユーザtelnetはユーザによってタイプされたデータによって圧倒されるかもしれません。 パラメタ5が1であるなら、ユーザが、タイプするのを再開するかもしれないなら、それは、入力とX-ON(DC1、ASCIIコード17)を中断させるようにユーザに頼むために、X-OFF(DC3、ASCIIコード19)を出力するかもしれません。
Code 0 -- X-OFF and X-ON considered normal output data.
Code 1 -- X-OFF and X-ON used to control user input.
コード0--X-OFFと正常であると考えられたX-ONはデータを出力しました。 コード1--X-OFFとX-ONは以前はよくユーザ入力を制御していました。
The extension parameters 130 and 131, if defined, specify other
codes to be used instead of ASCII DC3 and DC1.
定義されるなら、拡大パラメタ130と131は、ASCII DC3とDC1の代わりに使用されるために他のコードを指定します。
Parameter 6, referring to messages sent from the PAD to the user,
does not seem to be relevant in this context.
PADからユーザに送られたメッセージを示して、パラメタ6はこのような関係においては関連しているように思えません。
Parameter 7 -- Function of Break, Interrupt, Attention, etc.
パラメタ7--中断、中断、注意などの機能
This parameter describes handling of some special key or other
character, implementation-defined, on the user's keyboard. It is
bit-encoded; codes may be added to select multiple functions.
Multiple functions may be performed in any order. Any messages
generated should be promptly sent to the host.
このパラメタはユーザのキーボードにおける特別な主要であるか他のキャラクタの実装で定義された取り扱いについて説明します。 それはビットによってコード化されています。 コードは、多面的機能を選択するために加えられるかもしれません。 多面的機能は順不同に実行されるかもしれません。 即座に生成されたどんなメッセージもホストに送るべきです。
Code 0 -- No action.
Code 1 -- Send interrupt packet (Telnet IAC IP).
Code 2 -- Reset (break Telnet connection).
Code 4 -- Discard input from user not yet consumed by host.
Code 8 -- Escape to local Telnet command mode.
Code 16 -- Discard output from host (see parameter 8).
0をコード化してください--動作がありません。 コード1--中断パケット(telnet IAC IP)を送ってください。 コード2--(中断Telnet接続)をリセットしてください。 コード4--ホストがまだ疲れていなかったユーザからの入力を捨ててください。 コード8--ローカルのTelnetコマンドモードに逃げてください。 コード16--ホストから出力を捨ててください(パラメタ8を見てください)。
The X.25 'Interrupt', 'Reset', and 'Indication of Break' messages
are here translated to Telnet equivalents. See section 8 for
suggestions on discarding input and output.
Telnet同等物に翻訳されて、X.25'中断'、'リセット'、および'Breakのしるし'メッセージがここにあります。 捨てるときの提案のためのセクション8が入出力されるのを見てください。
Levy & Jacobson [Page 10] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[10ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Parameter 8 -- Discarding output from host.
パラメタ8--ホストから出力を捨てます。
This parameter is intended as a flag, indicating whether host
output is being ignored.
ホスト出力が無視されているかどうかを示して、このパラメタは旗として意図します。
Code 0 -- Host output is sent to user.
Code 1 -- Host output is discarded.
コード0--ホスト出力をユーザに送ります。 コード1--ホスト出力は捨てられます。
This parameter is normally used in conjunction with parameter 7
when the 16's bit (Discard output on Break/Interrupt/Attention) is
set. An implementation is suggested in section 8 of this RFC.
16年代ビット(Break/中断/注意のときに出力を捨てる)が設定されるとき、通常、このパラメタはパラメタ7に関連して使用されます。 実装はこのRFCのセクション8で示されます。
Note that, if a signal from the user causes parameter 8 to be
changed and parameter 0 is set to 1, an X.3-PAD IS message should
be sent to the host.
ユーザからの信号でパラメタ8を変えて、パラメタ0が1に設定されるならX.3-PAD ISメッセージがホストに送られるべきであることに注意してください。
Parameter 9 -- Padding after carriage return.
パラメタ9--復帰の後にそっと歩きます。
This parameter selects insertion of ASCII NUL padding characters
after output of each carriage return.
このパラメタはそれぞれの復帰の出力の後にASCII NUL暫定記号の挿入を選択します。
Codes 0 through 7 -- Insert that many padding characters.
コード0〜7--そんなに多くの暫定記号を挿入してください。
Parameter 10 -- Line folding.
パラメタ10--折り重なりを裏打ちしてください。
Output lines may be folded (e.g., by insertion of carriage return
and line feed) when they exceed a specified width.
指定された幅を超えているとき、出力系列は折り重ねられるかもしれません(例えば、復帰と改行の挿入で)。
Code 0 -- No output line folding.
Codes 1 through 255 -- Fold lines after that many characters.
コード0--いいえは系列の折り重なりを出力しました。 コード1〜255--Foldはそんなに多くのキャラクタの後に立ち並びます。
Parameter 11 -- Bit rate.
パラメタ11--ビット伝送速度。
This parameter indicates the serial data rate of the user's
terminal, if any. Though CCITT X.3 considers this parameter to be
read-only, it may be meaningful to allow the host to set as well as
read this value, thus changing the user's line speed dynamically.
このパラメタはもしあればユーザの端末のシリアルデータ料金を示します。 CCITT X.3は、このパラメタが書き込み禁止であると考えますが、ホストがこの値を設定して、読むのを許容するのは重要であるかもしれません、その結果、ダイナミックにユーザのライン・スピードを変えます。
Code 0 -- 110 bps Code 10 -- 50 bps
Code 1 -- 134.5 bps Code 11 -- 75 bps in, 1200 out
Code 2 -- 300 bps Code 12 -- 2400 bps
Code 3 -- 1200 bps Code 13 -- 4800 bps
Code 4 -- 600 bps Code 14 -- 9600 bps
Code 5 -- 75 bps Code 15 -- 19200 bps
Code 6 -- 150 bps Code 16 -- 48000 bps
Code 7 -- 1800 bps Code 17 -- 56000 bps
Code 8 -- 200 bps Code 18 -- 64000 bps
Code 9 -- 100 bps
中で0 -- 110 ビーピーエスCode10 -- 50ビーピーエスCode1 -- 134.5ビーピーエスCode11 -- 75ビーピーエスをコード化してください、1200の出ているCode2 -- 300ビーピーエスCode12 -- 2400ビーピーエスCode3 -- 1200ビーピーエスCode13 -- 4800ビーピーエスCode4 -- 600ビーピーエスCode14 -- 9600ビーピーエスCode5 -- 75ビーピーエスCode15 -- 19200ビーピーエスCode6 -- 150ビーピーエスCode16 -- 48000ビーピーエスCode7 -- 1800ビーピーエスCode17 -- 56000ビーピーエスCode8 -- 200ビーピーエスCode18 -- 64000ビーピーエスCode9 -- 100ビーピーエス
Levy & Jacobson [Page 11] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[11ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Parameter 12 -- Flow control of host-to-user data.
パラメタ12--ホストから利用者データのフロー制御。
When this parameter is 1, the user may type X-OFF (DC3, ASCII code
19) to suspend printing output, and X-ON (DC1, ASCII code 17) to
resume output.
このパラメタが1であるときに、ユーザは、印刷出力、およびX-ON(DC1、ASCIIコード17)を履歴書出力に吊すために、X-OFF(DC3、ASCIIコード19)をタイプするかもしれません。
Code 0 -- X-OFF and X-ON are sent as data to host.
Code 1 -- X-OFF and X-ON control output.
コード0--ホスティングするデータとしてX-OFFとX-ONを送ります。 コード1--X-OFFとX-ONは出力を制御します。
See also the extension parameters 130, 131 and 132.
また、拡大パラメタ130、131、および132を見てください。
Parameter 13 -- Line feed insertion; Telnet CR LF vs CR NUL.
パラメタ13--改行挿入。 telnet CR LF対CR NUL
The CCITT uses this parameter to select whether a typed CR should
be sent as CR or CR-LF, whether an output CR should have a LF
printed after it, and whether an echoed CR should be echoed with an
accompanying LF.
CCITTはタイプされたCRがCRかCR-LFとして送られるべきであるかどうかを選択するのにこのパラメタを使用します、出力CRがそれの後にLFを印刷させるはずであり、反響しているCRが付随のLFと共に反響されるべきであるか否かに関係なく。
Here, it resolves the questions of mapping between the Telnet CR-LF
sequence and single ASCII codes (i.e., when the user presses the
carriage return key, should CR LF or CR NUL be sent to the host?
When the host sends CR LF, should the user see CR LF or merely CR?)
ここで、それはTelnet CR-LF系列とただ一つのASCIIの間でコードを写像する問題を解決します。(すなわち、ユーザがキャリッジリターンキーを押すと、CR LFかCR NULをホストに送るべきですか? ホストがCR LFを送るとき、ユーザはCR LFか単にCRを見るべきですか?)
The value is bit-encoded; codes may be added to select multiple
functions.
値はビットによってコード化されています。 コードは、多面的機能を選択するために加えられるかもしれません。
Code 0 -- No line feed insertion
(typed CR sent as CR NUL; host CR LF printed as CR).
Code 1 -- Add line feed on output (host CR LF printed as CR LF).
Code 2 -- Add line feed on input (typed CR sent as CR LF to host).
Code 4 -- When echoing a typed CR locally, echo as CR LF.
0をコード化してください--改行挿入がありません(CR NULとして送られたタイプされたCR; CRとして印刷されたホストCR LF)。 コード1--出力のときに改行を加えてください(ホストCR LFはCR LFとして印刷しました)。 コード2--入力のときに改行を加えてください(タイプされたCRはCR LFとしてホストに発信しました)。 コード4--局所的にタイプされたCRを反響するときには、CR LFとして反響してください。
Note the interaction with the TRANSMIT-BINARY Telnet option [5].
If the host has said WILL TRANSMIT-BINARY, then CR has no special
meaning on output; it always stands for the single character CR
regardless of this parameter's value. If the user telnet has said
WILL TRANSMIT-BINARY, a typed CR should likewise always be sent as
itself and not as CR LF or CR NUL.
TRANSMIT-BINARY Telnetオプション[5]との相互作用に注意してください。 ホストがWILL TRANSMIT-BINARYを言ったなら、CRはどんな特別な意味も出力に持っていません。 それはこのパラメタの値にかかわらずいつも独身のキャラクタCRを表します。 ユーザtelnetがWILL TRANSMIT-BINARYを言ったなら、CR LFかCR NULとして送るのではなく、それ自体としていつも同様にタイプされたCRを送るべきです。
Parameter 14 -- Output padding after line feed.
パラメタ14--改行の後に詰め物を出力してください。
Gives the number of ASCII NUL padding characters to be sent to the
user's terminal after each output line feed.
それぞれが改行を出力した後にユーザの端末に送るためにASCII NUL暫定記号の数を与えます。
Codes 0 through 7 -- Send that many padding characters.
コード0〜7--そんなに多くの暫定記号を送ってください。
Levy & Jacobson [Page 12] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[12ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Parameter 15 -- Local editing.
パラメタ15--地方の編集。
If this parameter is 1, the character delete, line delete and line
reprint functions (parameters 16, 17 and 18), if implemented,
should be enabled. Data should be sent to the host when a
forwarding character (see parameter 3) is typed or in case the user
telnet's input buffer becomes full.
このパラメタはそうです。1 キャラクタが削除する、系列は、増刷機能(パラメタ16、17、および18)を削除して、裏打ちします、実装されるなら可能にされるべきです。 推進文字(パラメタ3を見る)がタイプされるか、または場合では、ユーザtelnetの入力バッファが完全になるとき、データをホストに送るべきです。
Note the interaction with parameter 4, Forward after idle time.
User telnets need not handle the case where idle-time forwarding
and local editing are both enabled, i.e., the host should
explicitly request changing parameter 4 to 0 along with setting
parameter 15 to 1.
遊休時間の後にパラメタ4、Forwardとの相互作用に注意してください。 ユーザtelnetは、15〜1にパラメタを設定すると共にパラメタを4〜0に変えながら、すなわち遊休時間推進と地方の編集がともに可能にされるホストが明らかに要求するべきであるケースを扱う必要はありません。
Code 0 -- No input editing. Any editing characters are considered
data.
Code 1 -- Input editing. Editing characters edit the input buffer.
コード0--いいえは編集を入力しました。 どんな編集用文字もデータであると考えられます。 コード1--編集を入力してください。 編集用文字は入力バッファを編集します。
Parameter 16 -- Character-delete character.
パラメタ16--キャラクター抹消文字。
While local editing (parameter 15) is enabled, typing this
character erases the last character in the editing buffer, if any.
When editing is disabled, this character is not treated specially.
地方の編集(パラメタ15)は可能にされますが、この文字をタイプすると、編集バッファにおける最後のキャラクタはもしあれば消されます。 編集は障害があるとき、特に、このキャラクタが扱われません。
Code 0 -- No character has this function.
Codes 1 through 127 -- ASCII code of character-delete character.
コード0--どんなキャラクタにも、この機能がありません。 コード1〜127--キャラクタ抹消文字のASCIIコード。
See also parameter 19.
また、パラメタ19を見てください。
Parameter 17 -- Line-delete character.
パラメタ17--線抹消文字。
While local editing (parameter 15) is enabled, this character
erases the entire contents of the editing buffer. When editing is
disabled, this character is not treated specially.
地方の編集(パラメタ15)は可能にされますが、このキャラクタは編集バッファの全体のコンテンツを消します。 編集は障害があるとき、特に、このキャラクタが扱われません。
Code 0 -- No character has this function.
Codes 1 through 127 -- ASCII code of line-delete character.
コード0--どんなキャラクタにも、この機能がありません。 コード1〜127--系列抹消文字のASCIIコード。
See also parameter 19.
また、パラメタ19を見てください。
Parameter 18 -- Line-display character.
パラメタ18--線ディスプレイキャラクタ。
While local editing (parameter 15) is enabled, typing this
character causes the current contents of the editing buffer to be
printed on the user's terminal; nothing is sent to the host. When
editing is disabled, this character is not treated specially.
地方の編集(パラメタ15)は可能にされますが、この文字をタイプするのに、ユーザの端末で編集バッファの現在のコンテンツを印刷します。 何もホストに送りません。 編集は障害があるとき、特に、このキャラクタが扱われません。
Code 0 -- No character has this function.
コード0--どんなキャラクタにも、この機能がありません。
Levy & Jacobson [Page 13] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[13ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Codes 1 through 127 -- ASCII code of line-display character.
コード1〜127--系列ディスプレイキャラクタのASCIIコード。
Parameter 19 -- Editing service signals.
パラメタ19--サービスを編集するのは合図します。
This determines what is echoed to the user when local editing is
enabled and the character-delete or line-delete character is
entered.
または、そして、これが、地方の編集が可能にされるとき、何がユーザに反響されるかを決定する、キャラクタ削除、系列抹消文字は入れられます。
Code 0 -- Nothing is echoed.
Code 1 -- Editing style is suitable for printing terminals.
Code 2 -- Editing style is suitable for display terminals.
Codes 8 and 32-126 -- Echo that ASCII character for
character-delete.
コード0--何も反響されません。 コード1--スタイルを編集するのは印刷端末に適当です。 コード2--スタイルを編集するのはディスプレー装置に適当です。 コード8と32-126--そのASCII文字の言葉を繰り返してください、キャラクタで削除します。
X.3 is specific on handling character- and line-deletion. If
parameter 19 is 1, echo character-delete with a "line delete with
three X's followed by CR LF. If 2, a character-delete echoes BS
SPACE BS, while a line delete echoes enough BS SPACE BS's to erase
the entire line. If 8 or 32-126, character-delete echoes that
character, and line delete echoes XXX CR LF. An extension
parameter could override these, selecting other styles if desired,
though none is proposed here.
X.3は取り扱キャラクタいと行消去のときに特定です。 19はパラメタであるならそうです。1 エコーは「CR LFによって続かれて、系列は3でXのものを削除すること」でキャラクタで削除します。 2であるならaがキャラクタで削除する、エコーBS SPACE BS、系列はエコーを削除しますが、消すことができるくらいのBS SPACE BSは全体の系列です。 8か32-126であるなら、エコーをキャラクタで削除してください、そのキャラクタ、系列はエコーXXX CR LFを削除します。 なにもここで提案されませんが、望まれているなら他のスタイルを選択して、拡大パラメタはこれらをくつがえすかもしれません。
Parameter 20 -- Echo mask.
パラメタ20--エコーマスク。
When local echoing, parameter 2, is enabled, each nonzero bit in
this bit-encoded parameter's value suppresses echoing of some
subset of ASCII characters. Adding values suppresses echo for the
union of the specified subsets.
ローカル・エコーイング(パラメタ2)が可能にされるとき、このビットでコード化されたパラメタの値におけるそれぞれの非零ビットはASCII文字の何らかの部分集合の反響を抑圧します。 指定された部分集合の組合のためにエコーを抑圧します付加が、評価する。
Code 0 -- all ASCII characters are echoed.
Code 1 -- CR is not echoed.
Code 2 -- LF is not echoed.
Code 4 -- VT, HT, and FF are not echoed.
Code 8 -- BEL and BS are not echoed.
Code 16 -- ESC and ENQ are not echoed.
Code 32 -- ACK, NAK, STX, SOH, EOT, ETB and ETX are not echoed.
Code 64 -- Editing characters are not echoed.
Code 128 -- other non-printing ASCII characters, and DEL, not
echoed.
コード0--すべてのASCII文字が言葉を繰り返されます。 コード1--CRは反響されません。 コード2--LFは反響されません。 コード4--バーモント、HT、およびFFは反響されません。 コード8--BELとBSは反響されません。 コード16--ESCとENQは反響されません。 コード32--ACK、NAK、STX、SOH、EOT、ETB、およびETXは反響されません。 コード64--編集用文字は反映されません。 コード128--他の非印刷のASCII文字、およびDELは反響しませんでした。
Nothing is echoed when parameter 2 is 0. Some characters should
not be echoed regardless of parameter 20. If any of parameters 5,
12, or 22 are enabled (non-zero), then the XON and XOFF characters
should not be echoed. Nor should the escape-to-local command mode
character, parameter 1.
パラメタ2が0であるときに、何も反響されません。 キャラクタの中にはパラメタ20にかかわらず言葉を繰り返す人もいるべきではありません。 パラメタ5、12、または22のどれかを可能にするなら(非ゼロ)、XONとXOFFキャラクタの言葉を繰り返すべきではありません。 地方へのエスケープコマンドモードキャラクタ、パラメタ1もそうするべきではありません。
Levy & Jacobson [Page 14] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[14ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Parameter 21 -- Parity.
パラメタ21--同等。
This parameter determines whether parity is checked on user input
and generated on output to the user. Values may be added to select
both.
このパラメタは同等がユーザ入力のときにチェックされて、出力のときにユーザに生成されるかどうか決定します。 値は、両方を選択するために加えられるかもしれません。
Code 0 -- Parity neither generated nor checked.
Code 1 -- Even parity checked on input.
Code 2 -- Even parity generated on output.
0をコード化してください--どちらも生成して、チェックしなかった同等。 コード1--Evenの同等は入力について検査しました。 2をコード化してください--出力のときに生成されたEvenの同等。
Parameter 22 -- Page wait.
パラメタ22--ページ待ち。
If enabled, this parameter causes the user telnet to pause after
every N lines of output as if X-OFF had been received. Output
resumes when X-ON is typed.
可能にされるなら、ユーザtelnetがこのパラメタで後に止まる、あらゆる、Nが立ち並んでいる、まるでX-OFFを受け取ったかのように、出力します。 X-ONがタイプされるとき、出力は再開します。
Code 0 -- No pause.
Codes 1-255 -- Pause after output of that many line feeds.
0をコード化してください--くぎりがありません。 コード1-255--そんなに多くの改行の出力の後に止まってください。
See also parameters 130, 131 and 132.
また、パラメタ130、131、および132を見てください。
The following parameters are not part of CCITT X.3, but use the extension mechanism proposed for this Telnet option.
以下のパラメタはCCITT X.3の一部ではなく、拡張機能がこのTelnetオプションのために提案した使用です。
Parameter 128 -- Extension set number.
パラメタ128--拡大は数を設定しました。
This parameter selects one of a potentially large number of
"extension sets" -- more or less coherent collections of parameters
added to the basic X.3 family. User telnets may support several
extension sets. The host may determine whether a particular one is
supported by trying to set parameter 128. The user telnet should
accept the value if it provides some or all of the parameters in
that set.
このパラメタは潜在的に多くの「拡大セット」の1つを選択します--基本的なX.3ファミリーに追加されたパラメタの多少論理的な収集。 ユーザtelnetは数個の拡大セットを支えるかもしれません。 ホストは、特定のものがパラメタ128を設定しようとすることによってサポートされるかどうかと決心するかもしれません。 設定されるのでパラメタのいくつかかすべてを提供するなら、ユーザtelnetは値を受け入れるべきです。
Extension sets might be defined for a variety of purposes. For
example, Berkeley UNIX tty emulation, VMS emulation, Telenet's
extended parameters, French national PDN parameters, and so on.
拡大セットはさまざまな目的のために定義されるかもしれません。 例えば、バークレーUNIX ttyエミュレーション、VMSエミュレーション、テレネットの拡張パラメタ、フランスの国家のPDNパラメタなど。
Initial values need not be specified for extension parameters
(i.e., a host should explicitly negotiate for their values after
selecting an extension set). However, it is recommended that
default settings give service that resembles normal CCITT X.3
behavior where possible.
初期の値は拡大パラメタに指定される必要はありません(拡大セットを選択した後に、すなわち、ホストは明らかにそれらの値を交渉するべきです)。 しかしながら、既定の設定が可能であるところで通常のCCITT X.3の振舞いに類似しているサービスを与えるのは、お勧めです。
Extension sets are mutually exclusive. Different sets may use the
same parameters (from 129 through 255) for different purposes.
拡大セットは互いに唯一です。 異なったセットは異なる役割に、同じパラメタ(129〜255の)を使用するかもしれません。
Only one extension set is in effect at a time. That is, if a host
1つの拡大セットだけが一度に、有効です。 ホストであるなら、それはそうです。
Levy & Jacobson [Page 15] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[15ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
requests service X from extension set A, then switches to extension
set B and requests its service Y, it should not expect that service
X is still being provided.
拡大からのサービスXがAを設定して、次に、拡大セットBと要求にサービスYを切り換えるという要求、それはサービスXがまだ提供されていると予想するべきではありません。
Some values of this parameter are reserved:
このパラメタのいくつかの値が予約されています:
Code 0 -- Null extension set. Only (a subset of) the basic CCITT
X.3 parameters is provided. Every user telnet should
accept this setting.
Code 1 -- (A subset of) the extension set 1 parameters described
below is provided.
Code 255 -- Reserved for purely local (e.g., to a site), non-
standard collections of extensions.
コード0--ヌル拡大はセットしました。 唯一、(部分集合、)、基本のCCITT X.3パラメタを提供します。 あらゆるユーザtelnetがこの設定を受け入れるべきです。 コード1--、(部分集合、)、1パラメタが以下で説明した拡大セットを提供します。 コード255--拡大の純粋に地方(例えば、サイトへの)の、そして、非標準の収集のために、予約されます。
Other extension sets may be proposed and assigned set numbers in
the range 2 through 254.
他の拡大セットは2〜254に提案されて、範囲でセット番号を割り当てられるかもしれません。
Set number are registered with the Internet Assigned Numbers
Coordinator at USC-ISI. Please contact:
セット番号はUSC-ISIのインターネットAssigned民数記Coordinatorに示されます。 連絡してください:
Joyce K. Reynolds
USC Information Sciences Institute
Suite 1001
4676 Admiralty Way
Marina del Rey, CA 90292-6695
ジョイスK.レイノルズUSC情報Sciences Institute Suite1001 4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695
213-822-1511 JKReynolds@ISI.EDU
213-822-1511 JKReynolds@ISI.EDU
The following parameters form extension set number 1.
以下のパラメタは拡大セットNo.1を形成します。
Parameter 129, extension set 1 -- Word-delete character.
パラメタ129、拡大セット1--Word抹消文字。
Typing this character while local editing is enabled causes the
last word in the editing buffer to be erased. Several definitions
for a "word" are in common use; this RFC does not specify one.
There should be an indication to the user of what was erased. When
editing is disabled, this character is not treated specially.
地方の編集が可能にされている間、この文字をタイプするのに、編集バッファの締め括りの言葉を消します。 「単語」のためのいくつかの定義が共用です。 このRFCは1つを指定しません。 消されたことに関するユーザへの指示があるべきです。 編集は障害があるとき、特に、このキャラクタが扱われません。
Code 0 -- No character has this function.
Codes 1 through 127 -- ASCII code of word-delete character.
コード0--どんなキャラクタにも、この機能がありません。 コード1〜127--単語抹消文字のASCIIコード。
Parameter 130, extension set 1 -- Flow control OFF character.
パラメタ130、拡大セット1--フロー制御OFFキャラクタ。
Parameter 131, extension set 1 -- Flow control ON character.
Typing these characters while parameter 12 is enabled cause output
to be suspended or resumed, respectively. The user telnet may send
them to the user while parameter 5 is enabled to ask the user to
cease or resume supplying input.
パラメタ131、拡大セット1--フロー制御ONキャラクタ。 パラメタ12が中断するために出力されるか、またはそれぞれ再開された可能にされた原因である間、これらの文字をタイプします。 パラメタ5が、やむか、または入力を提供するのを再開するようにユーザに頼むのが可能にされている間、ユーザtelnetはそれらをユーザに送るかもしれません。
Levy & Jacobson [Page 16] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[16ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
If defined, these parameters should have default values of 19
(ASCII DC3) for parameter 130, and 17 (ASCII DC1) for parameter
131.
定義されるなら、これらのパラメタには、パラメタ131のためのパラメタ130、および17(ASCII DC1)のための19(ASCII DC3)のデフォルト値があるべきです。
Code 0 -- No character has this function.
Codes 1 through 127 -- Function performed by that ASCII code.
コード0--どんなキャラクタにも、この機能がありません。 コード1〜127--機能はそのASCIIコードで働きました。
Parameter 132, extension set 1 -- Host-to-user flow control convention.
パラメタ132、拡大セット1--ホストからユーザへのフロー制御コンベンション。
Some styles of flow control accept only a particular character
(e.g., X-ON) to resume output; others resume on receipt of any
character. This parameter selects which to use. The default
should be zero, as this matches the X.3 convention.
フロー制御のいくつかのスタイルが出力を再開するために、特定のキャラクタ(例えば、X-ON)だけを受け入れます。 他のものはどんなキャラクタを受け取り次第再開します。 このパラメタは、どれを使用したらよいかを選択します。 これがX.3コンベンションに合っているとき、デフォルトはゼロであるべきです。
Code 0 -- Resume output only when correct character is received.
Code 1 -- Resume output when any character is received.
コード0--正しいキャラクタが受け取られているだけときには出力を再開してください。 コード1--どんなキャラクタも受け取られているときには出力を再開してください。
Parameter 133, extension set 1 -- Alternate Attention, etc., character.
パラメタ133、拡大セット1--キャラクタはAttentionなどを交替してください。
This character serves as a synonym for the Break, Attention, etc.,
key whose function is given by parameter 7.
このキャラクタはBreak、Attentionなどのための同義語、機能がパラメタ7によって与えられるキーとして勤めます。
Code 0 -- No ASCII character has this function
(there may still be a special key or other mechanism).
Codes 1 through 127 -- ASCII code of the character.
コード0--どんなASCII文字にも、この機能がありません(まだ、特別な主要であるか他のメカニズムがあるかもしれません)。 コード1〜127--キャラクタのASCIIコード。
Parameter 134, extension set 1 -- Local echo style.
パラメタ134、拡大セット1--ローカルエコースタイル。
This parameter selects how non-printing characters should be
echoed, when parameter 2 is set to 1. The default should be zero,
where all characters are simply echoed as themselves (except
possibly carriage return; see parameter 13).
このパラメタは、パラメタ2が1に設定されるとき、非表示文字がどのように言葉を繰り返されるべきであるかを選択します。 デフォルトはすべてのキャラクタが自分たちとして単に言葉を繰り返されるところの(ことによると復帰を除いて; パラメタ13を見てください)ゼロであるべきです。
Code 0 -- All characters echo as themselves.
Code 1 -- Non-editing control characters echo as ^X for some
printable character X.
コード0--すべてのキャラクタが自分たちとして反響します。 コード1--非編集制御文字は^印刷可能なキャラクタXのためのXとして反映します。
See also parameters 2, Local echo, and 20, Echo mask, which may
suppress echo of some or all characters regardless of this
parameter.
また、2、Localエコー、および20、Echoがマスクをかけるパラメタを見てください。(パラメタはこのパラメタにかかわらずいくつかかすべてのキャラクタのエコーを抑圧するかもしれません)。
Parameter 135, extension set 1 -- Accept following character as data.
パラメタ135、拡大セット1--データとして次のキャラクタを認めてください。
After typing this character, the next character entered is accepted
as data for transmission to the host even if it would normally have
a special meaning.
この文字をタイプした後に、通常格別の意味があっても、入られた次のキャラクタはホストへの伝送のためデータとして認められます。
The default should be zero.
デフォルトはゼロであるべきです。
Levy & Jacobson [Page 17] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[17ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
Code 0 -- No character has this function.
Codes 1 through 127 -- ASCII code of the character.
コード0--どんなキャラクタにも、この機能がありません。 コード1〜127--キャラクタのASCIIコード。
Parameter 136, extension set 1 -- Character to toggle discarding output.
パラメタ136、拡大セット1--出力を捨てる切り換えるキャラクター。
Typing this character changes the state of parameter 8 (discarding
host-to-user output) from 0 to 1 or from 1 to 0. Thus an
indeterminate amount of host output, received between successive
instances of this character, will be discarded.
この文字をタイプすると、パラメタ8(ホストからユーザへの出力を捨てます)の状態は0〜1まで1〜0に変化します。 したがって、このキャラクタの連続したインスタンスの間に受けられた不確定の量のホスト出力が捨てられるでしょう。
As usual, the host should be notified of each change if parameter 0
is set to 1. The host might wish to send SET messages at
appropriate points (e.g., preceding command prompts) to re-enable
output.
いつものように、パラメタ0が1に設定されるなら、ホストはそれぞれの変化について通知されるべきです。 ホストは出力を再可能にする適切なポイント(例えば、コマンド・プロンプトに先行する)のメッセージをSETに送りたがっているかもしれません。
The default should be zero.
デフォルトはゼロであるべきです。
Code 0 -- No character performs this function (though another
mechanism still may do so).
コード0--どんなキャラクタもこの機能を実行しません(別のメカニズムがまだそうしているかもしれませんが)。
Codes 1 through 127 -- Typing that character toggles parameter 8.
コード1〜127--キャラクタがパラメタ8を切り換えるのをタイプします。
Parameter 137, extension set 1 -- User-to-host bits per character.
パラメタ137、拡大セット1--ユーザからホストへの1キャラクタあたりのビット。
Parameter 138, extension set 1 -- Host-to-user bits per character.
パラメタ138、拡大セット1--ホストからユーザへの1キャラクタあたりのビット。
These parameters determine whether, for example, a full 8-bit input
or output data path is available, or whether the most significant
bit(s) of input or output data is stripped. Typical values would
be 7 or 8.
これらのパラメタは、例えば、完全な8ビットの入力か出力データ経路が利用可能であるかどうか、または最も重要なビットの入力か出力データが剥取られるかどうか決定します。 典型的な値は、7か8でしょう。
Note that an 8-bit data path does not by itself imply transparent
input/output; CR -> CR LF translation, XON/XOFF interpretation,
parity and so on must also be disabled to achieve this.
8ビットのデータ経路自体がわかりやすい入力/出力を含意しないことに注意してください。 また、これを達成するためにCR->CR LF翻訳、XON/XOFF解釈、同等などを無効にしなければなりません。
7. Subsets, Extensions and Conflicts
7. 部分集合、拡大、および闘争
An option as complex (and easy to extend) as this one, needs a policy for what subsets and extensions are allowed, and recommendations for negotiating one's way through a maze of partial implementations. In short, what does it mean to say DO or WILL X.3-PAD?
これと同じくらい複雑、そして、同じくらい(広げる簡単)オプション、どんな部分集合と拡大のための方針が許容されている必要性、および部分的な実装の迷宮を通って人のやり方を交渉するための推薦。 要するにするように言うために意地悪な状態でそれをすることですかそれともWILL X.3-PADですか?
A basic principle is that, since hardly any user telnet implementation will provide all possible features, a host cannot expect to get precisely any desired kind of service.
基本原理はほとんどどんなユーザtelnet実装もすべての可能な特徴を提供するというわけではなくて、ホストが、正確にどんな必要な種類のサービスも得ることを期待できないということです。
[This may be an arguable point. The CCITT defines a mandatory
subset of supported values for each X.3 parameter, with further
これは疑わしいポイントであるかもしれません。[CCITTがそれぞれのX.3パラメタのためにサポートしている値の義務的な部分集合を定義する、一層
Levy & Jacobson [Page 18] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[18ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
values optional. For example, the set of forwarding characters,
parameter 4, must accept at least the values 0 (none), 2 (carriage
return), and 126 (any control character or DEL). Though it would be
possible to adopt the CCITT's set of mandatory values there, I don't
think that would be desirable for two reasons.
値、任意です。 例えば、推進キャラクタのセット(パラメタ4)は少なくとも値0(なにも)、2(復帰)、および126(どんな制御文字やDELも)を受け入れなければなりません。 そこにCCITTの義務的な値のセットを採用するのが可能でしょうが、私は、それが2つの理由で望ましいと思いません。
First, some of the features specified (e.g., timed input) may be
hard to implement in some environments, and may well not be
necessary for many applications.
まず最初に、指定された(例えば、入力を調節します)特徴のいくつかは、いくつかの環境で実装するのが困難であるかもしれなく、たぶん多くのアプリケーションに必要でないでしょう。
Second, this option provides for definition of entirely new
parameters. Unlike the X.3 case, one peer may use parameters whose
very existence is unknown to the other. So one cannot specify
mandatory or default values for ALL parameters.]
2番目に、このオプションは完全に新しいパラメタの定義に備えます。 X.3ケースと異なって、ある同輩がもう片方において、まさしくその存在が未知であるパラメタを使用するかもしれません。 したがって、1つは義務的であるかデフォルト値をすべてのパラメタに指定できません。]
On the other hand, a host is at least entitled to know what kind of service is being provided to the ultimate user. A user telnet's status report may be incomplete (not describing features its implementor did not know of); it may not describe the style of interaction the host (or user, or application) would wish for, but it should at least describe reality.
他方では、ホストは少なくともどういうサービスが究極のユーザに提供されているかを知っている権利を与えられます。 ユーザtelnetの現状報告は不完全であるかもしれません(作成者が知らなかった特徴について説明しないで)。 ホスト(または、ユーザ、またはアプリケーション)が望んでいる相互作用のスタイルについて説明しないかもしれませんが、それは現実について少なくとも説明するべきです。
For telnet parameters with a range of possible values, if a user telnet implements only one "enabled" and one "disabled" value, it should choose the "enabled" value when asked for a setting it cannot supply. A VMS telnet, for example, might allow only DEL or nothing as the character-delete code. If a host asks it to use "backspace", it should choose DEL rather than nothing. The host may then interpret this contrary behavior as indicating a preferred value.
それが供給できない設定を求めるとき、さまざまな可能な値があるtelnetパラメタのために、ユーザtelnetが、唯一の1つが「障害がある」「可能にする」と1つの値であると実装するなら、それは「可能にされた」値を選ぶべきです。 例えば、VMS telnetが唯一のDELか何も許容しないかもしれない、コードをキャラクタで削除してください。 ホストが、「バックスペースキーを押して印字位置を一字分戻ってください」を使用するようにそれに頼むなら、それは無よりむしろDELを選ぶべきです。 そして、ホストは都合のよい値を示すとこの反対の振舞いを解釈するかもしれません。
The problem of conflicting parameters, where several parameters control overlapping services and may conflict, is a serious one. The extension set scheme (see parameter 128) is intended to limit the problem. Each extension set's parameters should be selfconsistent and consistent with the CCITT X.3 parameters, but separate extension sets need not be concerned with each other's parameters.
闘争パラメタの問題は重大なものです。(そこでは、いくつかのパラメタが、サービスを重ね合わせながら制御して、闘争するかもしれません)。 拡大セット体系(パラメタ128を見る)が問題を制限することを意図します。 それぞれの拡大セットのパラメタは、CCITT X.3パラメタと自己一致であって一致しているべきですが、別々の拡大セットは互いのパラメタに関係がある必要はありません。
Where parameters might conflict, it is important to specify priority as part of the parameters' description. For example, among parameters 2 (Local echo), 20 (Echo mask), and extension set 1's 134 (Local echo style), Echo mask is significant only if Local echo is enabled, and Local echo style applies only to characters selected for echoing by the first two parameters.
パラメタが闘争するかもしれないところでは、パラメタの記述の一部として優先権を指定するのは重要です。 例えば、2の(ローカルエコー)、20(エコーマスク)、および拡大はパラメタにおける1の134(ローカルエコースタイル)を設定します、そして、Localエコーが可能にされる場合にだけ、Echoマスクは重要です、そして、Localエコースタイルは最初の2つのパラメタで反響するように選ばれたキャラクタだけに適用されます。
This option's functions overlap with those of some existing Telnet options, for example, ECHO (which can be interpreted to affect local echo and possibly local line editing), NAOCRD and NAOLFD [6] (specifying padding after output carriage returns and line feeds),
このオプションの機能は例えばTelnetオプションECHO(ローカルエコーとことによるとローカル線編集に影響するように、解釈できる)、NAOCRD、およびNAOLFD[6]をいくつかの存在のものに重ね合わせます(出力復帰と改行の後にそっと歩く指定)。
Levy & Jacobson [Page 19] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[19ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
TRANSMIT-BINARY, Remote Controlled Transmission and Echo [3], and SUPDUP [4].
バイナリーを伝えていて、遠隔操作のトランスミッション、エコー[3]、およびSUPDUP[4]。
Where X.3-PAD completely subsumes the function of another option, as for ECHO, NAOCRD and NAOLFD, it's probably best to let the X.3-PAD option, where acceptable to both sides, supplant them and to refuse the other option.
X.3-PADがECHO、NAOCRD、およびNAOLFDのように別のオプションの機能を完全に包括するところでは、X.3-PADオプションを両側に許容できるところでそれらに取って代わらせて、別の選択肢を拒否するのはたぶん最も良いです。
The TRANSMIT-BINARY option can change (actually suppress) the interpretation of some bits of parameter 13 related to Telnet newline encoding, as mentioned under that parameter. As such it is compatible with this option but must be kept in mind.
TRANSMIT-BINARYオプションが変化できる、(実際に抑圧する、)、パラメタ13の数ビットの解釈はTelnetニューラインコード化に関連しました、そのパラメタの下で言及されるように。 そういうものとして、それをこのオプションと互換性がありますが、覚えておかなければなりません。
RCTE would be a much more difficult case, since its service does not fit into this option's scheme and vice versa. However, it probably is unimportant because of the scarcity of RCTE implementations.
RCTEははるかに難しいケースでしょう、サービスが逆もまた同様にこのオプションの計画に収まらないので。 しかしながら、それはRCTE実現への不足のためにたぶん重要ではありません。
Some existing Telnet options can serve related but complementary functions, for example NAOHTS [7] for output tab handling, or TERMINAL-TYPE [8].
いくつかの既存のTelnetオプションが関連しますが、補足的な機能を果たすことができます、例えば、出力のためのNAOHTS[7]は取り扱い、またはTERMINAL-TYPE[8]にタブを付けます。
8. Implementation suggestions
8. 実現提案
It is strongly recommended that a user telnet support at least the
combination with parameters 2=0, 3=126, and 4=1 (no local echo,
forward immediately or nearly so on any input character) so that a
dissatisfied host has the option of backing off and doing its own
character handling.
ユーザtelnetが2=0、3=126、および4=1(ローカルエコーがない、いずれもキャラクタを入力したようにすぐにかほとんどとてもオンなフォワード)に少なくともパラメタへの組み合わせるのをサポートすることが強く勧められるので、不満なホストには、それ自身のキャラクタ取り扱いを戻して、するオプションがあります。
The "discard output" function invoked by the Break, Interrupt,
Attention, etc., key if the 16's bit is set in parameter 7 may be
implemented as follows.
「出力を捨ててください」というBreak、Interrupt、Attentionなどによって呼び出された機能、16年代ビットであるならキーによるパラメタ7におけるセットが以下の通り実行されるかもしれないということです。
1. When the key is pressed, set parameter 8 to 1, begin
discarding output, send IAC SB X.3-PAD IS 8 1 IAC SE to
notify the host. (It may not need to know, but the
message should be sent for consistency.)
1. キーが押されるときには8〜1にパラメタを設定してください、そして、出力を捨て始めてください、そして、IAC SB X.3-PAD IS8 1IAC SEを送って、ホストに通知してください。 (それは知る必要はないかもしれませんが、一貫性のためにメッセージを送るべきです。)
2. Send IAC DO TIMING-MARK.
2. 発信してください。IACはタイミング・マークをします。
3. Send any other messages associated with the key (e.g.,
IAC IP).
3. キー(例えば、IAC IP)に関連しているいかなる他のメッセージも送ってください。
4. Eventually, the host should send either IAC WILL
TIMING-MARK or IAC WON'T TIMING-MARK, even if it knows
nothing about the TIMING-MARK option. It will probably
appear close, in the output stream, to the point where
the host recognized any associated messages (e.g., IP).
4. 結局、ホストはIAC WILL TIMING-マークかIAC WON'T TIMING-マークのどちらかを送るべきです、TIMING-マークのオプションに関して何も知らないでも。 それはたぶん近くに現れるでしょう、出力ストリームで、ホストがどんな関連メッセージ(例えば、IP)も認めたポイントに。
Levy & Jacobson [Page 20] RFC 1053 Telnet X.3 PAD Option April 1988
課税とジェーコブソン[20ページ]RFC1053telnet X.3はオプション1988年4月にそっと歩きます。
When the TIMING-MARK arrives, reset parameter 8 to 0 and
cease discarding output. Send IAC SB X.3-PAD IS 8 0
IAC SE.
TIMING-マークが到着したら8〜0にパラメタをリセットしてください、そして、出力を捨てるのをやめてください。 発信してください。IAC SB X.3-パッドは8 0IAC SEです。
The Telnet SYNCH mechanism (see [2]) may be employed in concert with such a scheme. A closed-loop flush, though, will be more effective at discarding excess output than SYNCH used alone. Provision of some such mechanism for discarding unwanted output, e.g., after interrupting the host, is heartily recommended.
Telnet SYNCHメカニズム、([2])がそのような計画と協力して使われるかもしれないのを確実にしてください。 もっとも、閉ループ水洗は単独で使用されるSYNCHより超過生産量を捨てるところでさらに効果的になるでしょう。 例えば、ホストを遮った後に求められていない出力を捨てるためのそのような何らかのメカニズムに関する条項は心から推薦されます。
Discarding input is less clear cut. Certainly, any buffered data not yet sent should be discarded; one might also use SYNCH to encourage the host telnet to discard more.
捨てることは切れました入力がそれほど明確でない。 確かに、まだ送られなかった少しのバッファリングされたデータも捨てられるべきです。 また、1つは、ホストtelnetがさらに捨てられるよう奨励するのにSYNCHを使用するかもしれません。
9. References
9. 参照
1. Recommendation X.3, from International Telecommunications Union
CCITT Red Book, volume VIII, fascicle VIII.2, 1984.
1. 国際Telecommunications Union CCITT Red Book、巻VIII、分冊VIII.2、1984からの推薦X.3。
2. Postel, J., and J. Reynolds, "Telnet Protocol Specification",
RFC-854, USC Information Sciences Institute, May 1983.
2. ポステル(J.、およびJ.レイノルズ、「telnetプロトコル仕様」、RFC-854、科学が設けるUSC情報)は、1983がそうするかもしれません。
3. Postel, J., and D. Crocker, "Remote Controlled Transmission and
Echoing Telnet Option", RFC-726 and NIC-39237, SRI-ARC, March
1977.
3. ポステル、J.、およびD.クロッカー、「遠隔操作のトランスミッションと反響しているtelnetオプション」(RFC-726とNIC-39237、様アーク)は1977を行進させます。
4. Crispin, M., "SUPDUP Protocol", RFC-734 and NIC-41953, SU-AI
October 1977; Crispin, M., "Telnet SUPDUP Option", RFC-736 and
NIC-42213, SU-AI, October 1977; also Greenberg, B., "Telnet
SUPDUP-OUTPUT Option", RFC-749 and NIC-45499, MIT-Multics,
September 1978.
4. クリスピンとM.と「SUPDUPプロトコル」とRFC-734とNIC-41953、SU-AI1977年10月。 クリスピンとM.と「telnet SUPDUPオプション」とRFC-736とNIC-42213、SU-AI、1977年10月。 グリーンバーグともB.と「telnet SUPDUP-出力オプション」とRFC-749とNIC-45499、MIT-Multics、1978年9月。
5. Postel, J., and J. Reynolds, "Telnet Binary Transmission
Option", RFC-856, USC Information Sciences Institute, May 1983.
5. ポステル(J.、およびJ.レイノルズ、「telnetバイナリートランスミッションオプション」、RFC-856、科学が設けるUSC情報)は、1983がそうするかもしれません。
6. Crocker, D., "Telnet Output Linefeed Disposition Option", RFC-
658 and NIC-31161, UCLA-NMC, October 1974; and "Telnet Output
Carriage Return Disposition Option", RFC-652 and NIC-31155,
UCLA-NMC, October 1974.
6. クロッカーとD.と「telnet出力ラインフィード気質オプション」とRFC658とNIC-31161、UCLA-NMC、1974年10月。 「telnet出力復帰気質オプション」とRFC-652とNIC-31155、UCLA-NMC、1974年10月。
7. Crocker, D., "Telnet Output Horizontal Tab Stops Option", RFC-
653 and NIC-31156, UCLA-NMC, October 1974. [RFC numbers 652
through 658 (NIC 31155 through 31161) are in a similar vein.]
7. クロッカーとD.と「telnet出力水平タブ停止位置オプション」とRFC653とNIC-31156、UCLA-NMC、1974年10月。 [RFC No.652〜658(NIC31155〜31161)が同様の静脈にあります。]
8. Solomon, M., and E. Wimmers, "Telnet Terminal Type Option",
RFC-884, University of Wisconsin - Madison, December 1983.
8. ソロモン、M.、およびE.Wimmers、「telnet端末タイプオプション」、RFC-884、ウィスコンシン大学--1983年12月のマディソン。
Levy & Jacobson [Page 21]
課税とジェーコブソン[21ページ]
一覧
スポンサーリンク
