この文書はRFC855の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。

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

                      TELNET OPTION SPECIFICATIONS
                      ＴＥＬＮＥＴオプション仕様書


This RFC specifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet are expected to adopt and implement this standard.
このＲＦＣはＡＲＰＡインターネット共同体の標準を指定します。ＡＲＰＡイン
ターネット上のホストがこの標準を採用し、実行することを期待されます。

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.
ＴＥＬＮＥＴプロトコルでオプションを供給する意図はホストがネットワーク仮
想端末（ＮＶＴ）によって供給されたフレームワークの中で、似ていない装置よ
り似ている装置がより可能にする通信の問題に対する解決を得るのを許すはずで
す。ホストが思うままにオプションを作り出し、テストし、捨てることが可能で
あるべきです。にもかかわらず、一般に有用と判明するオプションが結局は多く
のホストがサポートすると思われます；それ故にオプションが慎重に文書化され、
上手に公表されることが望ましいです。加えて、ひとつのオプションコードがい
くつかの異なったオプションで使われないことを保証することは必要です。

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.
この文書はオプションの文書化のためのオプションコード割当てと標準の方法を
指定します。オプションコードの割当てに関して責任がある個人は実験の場合に
完全な文書化の必要条件を無視してもよいですが、一般に文書化がコード割当て
の前に必要とされるでしょう。オプションがＲＦＣとして文書を出版することで
公にされるでしょう；オプションの発明者が、もちろん、同様に他の方法でそれ
らを公にしてもよいです。

   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

      Mailbox = POSTEL@USC-ISIF

Documentation of options should contain at least the following sections:
オプションの文書化が少なくとも次の章を含んでいるべきです：

   Section 1 - Command Name and Option Code
   １章−コマンド名とオプションコード

   Section 2 - Command Meanings
   ２章−コマンドの意味

      The meaning of each possible TELNET command relevant to this
      option should be described.  Note that for complex options, where
      "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
   ３章−デフォルト仕様

      The default assumptions for hosts which do not implement, or use,
      the option must be described.
      オプションを、実行しないか使わないホストのデフォルトの仮定が記述
      されなくてはなりません。

   Section 4 - Motivation
   ４章−動機

      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)
   ５章−記述（あるいは実装規則）

      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.
      ただコマンド意味を定義することと、動機づけの文を供給することは常に
      オプションの２つの実装が通信が可能であることを保証するに十分であり
      ません。それ故に、より完全な記述がたいていの場合に供給されるべきで
      す。この記述はテキスト、サンプル実装、実装者への助言などの書式をと
      るかもしれません。

A Note on "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.
   あるオプションがひとつのオプションコードより多くの情報をホスト間で転
   送するように要求するでしょう。例えば、パラメータを必要とするオプショ
   ンの場合です。使われる戦略は２つのステップから成り立ちます：最初に、
   両者がパラメータを「討議」することに同意します、そして、第二に、「討
   議」は起きます。

   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.
   第一歩は、パラメータを論じることの同意が、標準的な方法で起きます；一
   方がDO（あるいはWILL）とオプションコードを送ることでオプションの使用
   を提案します、そして他者はWILL（又はDO）とオプションコードを返すこと
   によって受け入れます。両者がオプションを使うことに同意したら、コマン
   ドSBとオプションコードとパラメータとコマンドＳＥを使うことで副交渉が
   起きます。それぞれが、それぞれが（最初のWILLとDOの交換で）オプション
   を支援することを示したので、パラメータを解析可能であると推測されます。
   他方、受信者は、たとえ受信者がパラメータを解析不可能であるとしても、
   SEコマンド（すなわち、文字列ＩＡＣ ＳＥ）を捜すことによってパラメータ
   文字列の終わりの場所を突き止めるかもしれません。もちろん、どちらかが、
   WON'TかDON'Tを相手に送ることで、いつでもそれ以上の副交渉を追うことを
   拒否するかもしれません。

   Thus, for option "ABC", which requires subnegotiation, the formats of
   the TELNET commands are:
   それで、副交渉を必要とするオプション「ABC」のために、ＴＥＬＮＥＴコマ
   ンドフォーマットは以下です：

      IAC WILL ABC

         Offer to use option ABC (or favorable acknowledgment of other
         party's request)
         オプションABCを使う申し出 （あるいは他者要請の賛成応答）

      IAC DO ABC

         Request for other party to use option ABC (or favorable
         acknowledgment of other party's offer)
         他者にオプションABCを使うように頼む（あるいは他者の申出の
         賛成応答）

      IAC SB ABC <parameters> 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.
   「副交渉」を必要とするオプションのデザイナーが副交渉プロセスでの果て
   しないループを避けるのに大きい面倒を見なくてはなりません。例えば、も
   し両者がパラメータ値を受け入れることができ、両者が異なった値でパラメー
   タを提案するなら、「受取りの通知」の無限の振動を持つ可能性が高いです
   （それぞれの受信者がただ他の新しい提案を認めることだけをしていると信
   じている）。最終的に、もしオプション「副交渉」でのパラメータが２５５
   の値の１バイトを含むなら、一般的なＴＥＬＮＥＴ規則に従って、このバイ
   トを２倍にすることが必要です。