RFC135 日本語訳

0135 Response to NWG/RFC 110. W. Hathaway. April 1971. (Format: TXT=5282 bytes) (Updates RFC0110) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                        W. Hathaway
Request for Comments: 135                                           AMES
NIC: 6712                                                  29 April 1971
Updates: 110

コメントを求めるワーキンググループW.ハザウェイ要求をネットワークでつないでください: 135 エームズNIC: 6712の1971年4月29日のアップデート: 110

                        Response to NWG/RFC #110
   (Conventions for Using an IBM 2741 Terminal as a User Console for
                    Access to Network Server Hosts)

NWG/RFC#110への応答(アクセスがサーバー・ホストをネットワークでつなぐのにユーザコンソールとしてIBM2741端末を使用するためのコンベンション)

   I would like to propose the following conventions to replace the ones
   proposed in RFC #110.  The original conventions suffer from lack of
   consideration of the correspondence 2741 and what I feel are
   inconsistencies and considerable difficulty of use.  (The 2741
   terminal with correspondence keyboard does not have all of the
   standard characters, notably:

RFC#110で提案されたものを取り替えるために以下のコンベンションを提案したいと思います。 オリジナルのコンベンションは通信2741と私が矛盾であると感じるものに関する考慮の不足と使用のかなりの困難が欠点です。 (通信キーボードがある2741年の端末には、標準のキャラクタのすべてが著しくありません:

      less than       <
      greater than    >
      logical not    [1]
      vertical bar    |

[1]縦棒ではなく、>論理的であるよりすばらしい<以下|

   Thus we must not use any of these characters in our conventions if we
   wish to support the correspondence 2741.)

その結果、通信2741を支持したいと思うなら、私たちはコンベンションにこれらのキャラクタのどれかを使用してはいけません。)

   The dedication of certain characters to special functions involves a
   trade-off: the convenience of having the function as a single key
   versus the inconvenience of having to use two keys to enter the
   character as data.  I believe that only two of the special functions
   listed in RFC #110 justify the dedication of a key: the "character
   escape" function and the "character delete" function.  For the
   "character escape" function I recommend the cent sign [2], as this
   character is on both the regular and correspondence 2741 terminals
   and is not in the ASCII character set.  For the "character delete"
   function I recommend the backspace key for obvious reasons.  While
   there is some need to be able to enter the character "backspace" (as
   for underscoring output etc.,) I feel that the trade-off mentioned
   above clearly indicates a single key "character delete" would be much
   more valuable than a single key "backspace" and a two key "character
   delete."

特別な機能への確信しているキャラクタの専念はトレードオフにかかわります: 単一のキーとしてデータとしてキャラクタに入るのに2個のキーを使用しなければならない不便に対して機能を持つ便利。 私は、RFC#110で記載された2つの特別な機能だけがキーの奉納を正当化すると信じています: そして、「キャラクタエスケープ」機能、「キャラクタは」 機能を削除します。 「キャラクタエスケープ」機能のために、私はセント記号[2]を推薦します、このキャラクタは通常、そして、通信両方の2741台の端末にあって、ASCII文字の組にないとき。 「キャラクタは」 私が明白な理由でバックスペースキーを推薦する機能を削除します。 キャラクタ「バックスペースキー」に入ることができる何らかの必要がある間(出力などを強調するように)、私は、前記のようにトレードオフがシングルよりはるかに貴重なキーが「キャラクタは削除する」「バックスペースキーを押して印字位置を一字分戻ってください」と2キーであったなら明確に「キャラクタは削除する」単一のキーを示すと感じます。

   For the other special functions I recommend two key combinations,
   consisting of "character escape" [2] and a key to define the
   function.  These are summarized below:

他の特別な機能のために、私は2つの主要な組み合わせを推薦します、機能を定義するために「キャラクタエスケープ」[2]とキーから成って。 これらは以下へまとめられます:

Hathaway                                                        [Page 1]

RFC 135                 Response to NWG/RFC #110           29 April 1971

NWG/RFC#110 1971年4月29日へのハザウェイ[1ページ]RFC135応答

      character escape        [2]
      character delete        backspace
      system delete           [2]$
      line delete             [2]# or [2]#NL
      logical line end        [2];
      line continuation       [2]NL
      ASCII control           [2]@

システムは[2]を削除します。キャラクタが削除するキャラクタエスケープ[2]がバックスペースキーを押して印字位置を一字分戻る、$線は[2]#か[2]#NL論理行終わりの[2]を削除します。 線継続[2]NL ASCIIコントロール[2]@

   The option in "line delete" is to allow the user to enter a new line
   (NL) immediately after the "line delete" to line up margins without
   entering a null line; to enter a null line after a "line delete"
   would require two NL characters.

中の「線は削除する」オプションがユーザが直後の復帰改行(NL)に入るのを許可することである、「線は」 顔触れのマージンへの入ることのない空行を削除します。 空行後aに入る、「線が削除する、」 2つのNLキャラクタを必要とするでしょう。

   The two new functions defined above, "line continuation" and "ASCII
   control," are used as follows.  The "line continuation" is used to
   enter a line which is longer than the 2741 carriage (or the margin
   placement) will permit.  It can be looked on as the complement of the
   "logical line end" in that is allows you to enter one logical line on
   several physical lines.

「線継続」と「ASCIIコントロール」という上で定義された2つの新しい機能が、以下の通り使用されます。 「線継続」は、2741年のキャリッジ(または、マージンプレースメント)が可能にするより長い線に入るのに使用されます。 あなたが中のそうする「論理行終わり」の補数でいくつかの物理行のある論理行に入ることができて、それを見ることができます。

   The use of the "ASCII control" function requires some background.
   There are of course many characters in ASCII which are keyed as
   combinations of "control" and another key.  The "character escape"
   function may be used to handle these control characters as follows: a
   "character escape" followed by a letter will be the equivalent of the
   ASCII "control" "letter", written as Xc (where X is the letter).
   This will greatly simplify the conventions for users, as they will
   simply key "[2]A" where they are used to using Ac and so forth.  For
   completeness, however, there needs to be a way to key the additional
   control characters which require both "control" and "shift" in
   addition to a letter (such as ESC, which is SHIFT Mc).  Further it is
   desirable that a more mnemonic system be provided for the non-
   Teletype user, who knows he wants a LF but does not know that it is a
   Jc.  To satisfy both of these needs I recommend the "ASCII control"
   special function, which is used to enter any of the ASCII control
   character as "[2]@" followed by the standard two or three character
   abbreviation.  Thus "escape" would be [2]@ESC, "line feed" would be
   [2]@LF, and so forth.  The use of the variable length abbreviation
   does not introduce any ambiguity, although from an implementation
   standpoint it may be advantageous to use the two character
   abbreviation proposed in RFC #110.

「ASCIIコントロール」機能の使用は何らかのバックグラウンドを必要とします。 もちろん、「コントロール」と別のキーの組み合わせとして合わせられるASCIIには多くのキャラクタがあります。 「キャラクタエスケープ」機能は以下のこれらの制御文字を扱うのに使用されるかもしれません: 手紙が支えた「キャラクタエスケープ」はXc(Xが手紙であるところ)として書かれたASCII「コントロール」「手紙」の同等物になるでしょう。 これはユーザのためにコンベンションを大いに簡素化するでしょう、彼らが単にAcなどを使用するのに使用されるところに「[2]A」を合わせるとき。 しかしながら、完全性のために、両方を必要とする追加制御文字が手紙(SHIFT McであるESCなどの)に加えて「制御し」て、「移行する」というキーへの道があるのが必要です。 さらに、非テレタイプのユーザにより簡略記憶のシステムを提供するのは望ましいです。(そのユーザは、彼がLFが欲しいのを知っていますが、それがJcであることを知りません)。 これらの必要性の両方を満たすために、私は「ASCIIコントロール」特別な機能を推薦します。(それは、「[2]@」が標準の2か3キャラクタ略語で続いたのでASCII制御文字のどれかを入れるのに使用されます)。 「改行」は、したがって、「エスケープ」は[2]@ESCであるだろう、[2]@LFなどでしょう。 可変長略語の使用は少しのあいまいさも導入しません、RFC#110で提案された2キャラクタ略語を使用するのが実現見地から有利であるかもしれませんが。

   Finally we must be able to enter the eight ASCII graphics which do
   not appear on either 2741 terminal, as well as the "cent sign" and
   "backspace" themselves (without their special functions).  For these
   I recommend the following:

最終的に私たちは2741で「セント記号」と同様に端末に見えて、自分たちで「バックスペースキーを押して印字位置を一字分戻らない」(それらの特別な機能なしで)8つのASCIIグラフィックスを入れることができなければなりません。 これらに関しては、私は以下を推薦します:

Hathaway                                                        [Page 2]

RFC 135                 Response to NWG/RFC #110           29 April 1971

NWG/RFC#110 1971年4月29日へのハザウェイ[2ページ]RFC135応答

      [2](            for     [
      [2])            for     ]
      [2]6            for     {
      [2]9            for     }
      [2]/            for     \
      [2]'            for     '
      [2]"            for     ^
      [2]-            for     ~
      [2][2]          for     [2]
      [2]backspace    for     backspace

「'[2]、([ [2])、]、[2]6、[2]9、[2] ^[2]のための''[2]」のための\[2]の/--[2]がバックスペースキーを押して印字位置を一字分戻る[2]のための~[2][2]に関してバックスペースキーを押して印字位置を一字分戻ってください、'

   Note that the characters "<" and ">" do not appear on the
   correspondence 2741 and hence should not be used.

キャラクタの"<"と">"が通信2741に現れないで、したがって、使用されるべきでないことに注意してください。

Endnotes

エンドノート

   [1] logical not

[1]論理的

   [2] cent sign

[2] セント記号

          [This RFC was put into machine readable form for entry]
          [into the online RFC archives by Lorrie Shiota, 10/02]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田によるオンラインRFCアーカイブへの10/02]

Hathaway                                                        [Page 3]

ハザウェイ[3ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<META> その文書に関する情報(メタ情報)を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る