RFC855 日本語訳

Network Working Group                                          J. Postel
Request for Comments: 855                                    J. Reynolds
                                                                     ISI
Obsoletes: NIC 18640                                            May 1983

コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 855 J.レイノルズISIは以下を時代遅れにします。 NIC18640 1983年5月

                      TELNET OPTION SPECIFICATIONS

telnetオプション仕様

This RFC specifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet are expected to adopt and implement this standard.

このRFCはARPAインターネットコミュニティの規格を指定します。 ARPAインターネットのホストは、この規格を採用して、実行すると予想されます。

The intent of providing for options in the TELNET Protocol is to permit
hosts to obtain more elegant solutions to the problems of communication
between dissimilar devices than is possible within the framework
provided by the Network Virtual Terminal (NVT).  It should be possible
for hosts to invent, test, or discard options at will.  Nevertheless, it
is envisioned that options which prove to be generally useful will
eventually be supported by many hosts; therefore it is desirable that
options should be carefully documented and well publicized.  In
addition, it is necessary to insure that a single option code is not
used for several different options.

TELNETプロトコルにおけるオプションに備える意図はホストが異なった装置のコミュニケーションの問題のNetwork Virtual Terminal(NVT)によって提供された枠組みの中で可能であるより上品な解決を得ることを許可することです。 ホストがオプションを自由自在に発明するか、テストするか、または捨てるのが、可能であるべきです。 それにもかかわらず、思い描かれて、一般に、役に立つと判明するそのオプションが結局多くのホストによってサポートされるということです。 したがって、オプションが慎重に記録されて、よくピーアールされるのは、望ましいです。 さらに、ただ一つのオプションコードがいくつかの異なったオプションに使用されないのを保障するのが必要です。

This document specifies a method of option code assignment and standards
for documentation of options.  The individual responsible for assignment
of option codes may waive the requirement for complete documentation for
some cases of experimentation, but in general documentation will be
required prior to code assignment.  Options will be publicized by
publishing their documentation as RFCs; inventors of options may, of
course, publicize them in other ways as well.

このドキュメントはオプションのドキュメンテーションのためのオプションコード課題と規格の方法を指定します。 オプションコードの課題に責任がある個人は実験に関するいくつかのケースのために完全なドキュメンテーションのための要件を放棄するかもしれませんが、一般に、ドキュメンテーションがコード課題の前に必要でしょう。 オプションはRFCsとしてそれらのドキュメンテーションを発行することによって、ピーアールされるでしょう。 オプションの発明者はもちろんまた、他の方法でそれらについてピーアールするかもしれません。

   Option codes will be assigned by:

オプションコードは以下によって割り当てられるでしょう。

      Jonathan B. Postel
      University of Southern California
      Information Sciences Institute (USC-ISI)
      4676 Admiralty Way
      Marina Del Rey, California 90291
      (213) 822-1511

ジョナサンB.ポステル南カリフォルニア大学情報科学は(213) 822-1511に(USC-ISI)4676海軍省道マリナデル・レイ(カリフォルニア)90291を設けます。

      Mailbox = POSTEL@USC-ISIF

メールボックス= POSTEL@USC-ISIF

Documentation of options should contain at least the following sections:

オプションのドキュメンテーションは少なくとも以下のセクションを含むべきです:

   Section 1 - Command Name and Option Code

セクション1--コマンド名とオプションコード

   Section 2 - Command Meanings

セクション2--コマンド意味

      The meaning of each possible TELNET command relevant to this
      option should be described.  Note that for complex options, where

このオプションに関連しているそれぞれの可能なTELNETコマンドの意味は説明されるべきです。 複雑なオプション、どこによってそれに注意してくださいか。

Postel & Reynolds                                               [Page 1]

ポステルとレイノルズ[1ページ]

RFC 855                                                         May 1983

RFC855 1983年5月

      "subnegotiation" is required, there may be a larger number of
      possible commands.  The concept of "subnegotiation" is described
      in more detail below.

"副交渉"が必要であり、より多くの可能なコマンドがあるかもしれません。 "副交渉"の概念はさらに詳細に以下で説明されます。

   Section 3 - Default Specification

セクション3--デフォルト仕様

      The default assumptions for hosts which do not implement, or use,
      the option must be described.

道具ではなく、そうするホストのためのデフォルト仮定、または使用、オプションについて説明しなければなりません。

   Section 4 - Motivation

セクション4--動機

      A detailed explanation of the motivation for inventing a
      particular option, or for choosing a particular form for the
      option, is extremely helpful to those who are not faced (or don't
      realize that they are faced) by the problem that the option is
      designed to solve.

特定のオプションを発明するか、またはオプションのための特定のフォームを選ぶことに関する動機の詳説はオプションが解決するように設計されている問題で面していない(それらに面しているとわからないでください)人に非常に役立っています。

   Section 5 - Description (or Implementation Rules)

セクション5--記述(または、実現規則)

      Merely defining the command meanings and providing a statement of
      motivation are not always sufficient to insure that two
      implementations of an option will be able to communicate.
      Therefore, a more complete description should be furnished in most
      cases.  This description might take the form of text, a sample
      implementation, hints to implementers, etc.

単にコマンド意味を定義して、動機の声明を提供するのは、オプションの2つの実現が交信できるのを保障するためにいつも十分であるというわけではありません。 したがって、多くの場合、より完全な記述は提供されるべきです。 この記述はテキストのフォーム、サンプル実現、implementersへのヒントなどを取るかもしれません。

A Note on "Subnegotiation"

"Subnegotiation"に関する注

   Some options will require more information to be passed between hosts
   than a single option code.  For example, any option which requires a
   parameter is such a case.  The strategy to be used consists of two
   steps:  first, both parties agree to "discuss" the parameter(s) and,
   second, the "discussion" takes place.

いくつかのオプションが、ただ一つのオプションコードより情報がホストの間で通過されるのを必要とするでしょう。 例えば、パラメタを必要とするどんなオプションもそのような場合です。 使用されるべき戦略は以下の2ステップから成ります: まず最初に、双方は、パラメタについて「議論すること」に同意します、そして、2番目に、「議論」は行われます。

   The first step, agreeing to discuss the parameters, takes place in
   the normal manner; one party proposes use of the option by sending a
   DO (or WILL) followed by the option code, and the other party accepts
   by returning a WILL (or DO) followed by the option code.  Once both
   parties have agreed to use the option, subnegotiation takes place by
   using the command SB, followed by the option code, followed by the
   parameter(s), followed by the command SE.  Each party is presumed to
   be able to parse the parameter(s), since each has indicated that the
   option is supported (via the initial exchange of WILL and DO).  On
   the other hand, the receiver may locate the end of a parameter string
   by searching for the SE command (i.e., the string IAC SE), even if
   the receiver is unable to parse the parameters.  Of course, either
   party may refuse to pursue further subnegotiation at any time by
   sending a WON'T or DON'T to the other party.

パラメタについて議論するのに同意して、第一歩は正常な方法で行われます。 あるパーティーがaを送るとオプションコードがあとに続いた(or WILL)がするオプションの使用を提案します、そして、相手はウィル(する)がオプションコードを続けた帰りを受け入れます。 双方が、オプションを使用するのにいったん同意すると、副交渉は、オプションコードがあとに続いたSBがコマンドSEによって従われたパラメタを続けたコマンドを使用することによって、行われます。 ウィルの初期の交換を通してあえて各当事者をパラメタを分析できます、それぞれが、オプションがサポートされるのを示したので(する、) 他方では、受信機はSEコマンド(すなわち、ストリングIAC SE)を捜し求めることによって、パラメタストリングの端の場所を見つけるかもしれません、受信機がパラメタを分析できないでも。 もちろん、aを送るのがそうしない何時でも一層の副交渉を追求するのを拒否するかもしれないか、または何れの当事者は相手に拒否しません。

Postel & Reynolds                                               [Page 2]

ポステルとレイノルズ[2ページ]

RFC 855                                                         May 1983

RFC855 1983年5月

   Thus, for option "ABC", which requires subnegotiation, the formats of
   the TELNET commands are:

したがって、telnetコマンドの形式はオプション"ABC"のための以下の通りです。(それは、副交渉を必要とします)。

      IAC WILL ABC

IACウィルABC

         Offer to use option ABC (or favorable acknowledgment of other
         party's request)

オプションABCを使用すると申し出てください。(または、相手の要求の好ましい承認)

      IAC DO ABC

IACはABCをします。

         Request for other party to use option ABC (or favorable
         acknowledgment of other party's offer)

相手がオプションABCを使用するという要求(または、相手の申し出の好ましい承認)

      IAC SB ABC <parameters> IAC SE

IAC SB ABC<パラメタ>IAC SE

         One step of subnegotiation, used by either party.

何れの当事者によって使用された副交渉のワンステップ。

   Designers of options requiring "subnegotiation" must take great care
   to avoid unending loops in the subnegotiation process.  For example,
   if each party can accept any value of a parameter, and both parties
   suggest parameters with different values, then one is likely to have
   an infinite oscillation of "acknowledgments" (where each receiver
   believes it is only acknowledging the new proposals of the other).
   Finally, if parameters in an option "subnegotiation" include a byte
   with a value of 255, it is necessary to double this byte in
   accordance the general TELNET rules.

"副交渉"を必要とするオプションのデザイナーは、副交渉の過程で果てしない輪を避けるために高度の注意を取らなければなりません。 例えば、各当事者がパラメタのどんな値も受け入れることができて、双方が異価でパラメタを示すなら、1つは「承認」(各受信機がもう片方の新規案件を承認しているだけであると信じているところ)の無限の振動を持っていそうです。 最終的に、"副交渉"というオプションにおけるパラメタが255の値に従った1バイトを含むなら、一般的なTELNETが統治するのが一致におけるこのバイトの二重に必要です。

Postel & Reynolds                                               [Page 3]

ポステルとレイノルズ[3ページ]