RFC273 日本語訳

0273 More on standard host names. R.W. Watson. October 1971. (Format: TXT=4589 bytes) (Obsoletes RFC0237) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                      Richard W. Watson
Request for Comments #273                  SRI-ARC
NIC 7837                                   18 October 1971
Categories:
Related: 7625, 7626, 7661, 7688, 7650, 7646
Obsoletes: 7662

コメント#273様アークNIC7837 1971年10月18日のカテゴリを求めるワーキンググループリチャードW.ワトソン要求をネットワークでつないでください: 関連: 7625、7626、7661、7688、7650、7646は以下を時代遅れにします。 7662

                      MORE ON STANDARD HOST NAMES

標準のホスト名の以上

   The Network Information Center is a logical place to handle this
   problem of Standard Host Names and so the ball now rests here.
   This is clearly a delicate subject with people having strong
   feelings and attachments to names.  No past proposal, including
   RFC 247, NIC 7668, has yet achieved any acceptance.  This
   identification seems a natural thing and should be taken into
   account in setting up a naming scheme.  Therefore, the following
   proposal is offered which I hope may be satisfactory to everyone.

Networkインフォメーション・センターがStandard Host Namesのこの問題を扱う論理的な場所であるので、ボールは現在、ここに静止しています。 これは明確に強い意見と付属を名前に持っている人々がいる言いにくい話題です。 RFC247、NIC7668を含むどんな過去の提案もまだどんな承認も実現していません。 この識別は、自然なものに見えて、命名計画をセットアップする際に考慮に入れられるべきです。 したがって、私が皆にとって満足できることを望んでいる以下の提案を出します。

   Any naming scheme must:

どんな命名計画もそうしなければなりません:

      (1)  Recognize the expanding character of the Network, with
      the potential eventually of several hundred sites.

(1) 結局、数100のサイトについて可能性があるNetworkの拡張キャラクタを見分けてください。

      (2)  Recognize the need for abbreviations to simplify typing.

(2) 略語がタイプを簡素化する必要性を認識してください。

      (3) Recognize the use of names on hardcopy and online
      documentation

(3) ハードコピーとオンラインドキュメンテーションにおける名前の使用を認識してください。

      (4)  Recognize people's strong identification with historical
      names associated with their project.

(4) それらのプロジェクトに関連している歴史的な名前による人々の強い識別を認識してください。

   To meet these needs, we propose adoption of a hybrid scheme
   related to those in the other past proposals.

これらの需要を満たすために、私たちは提案の先におけるもう片方におけるそれらに関連するハイブリッド計画の採用を提案します。

   Each host will have a formal name of the form:

各ホストには、フォームの正式名があるでしょう:

      <Institution Mnemonic>    "-"   <Host or NIC Station Mnemonic>

団体ニーモニック>「-」<が接待する<かNIC駅のニーモニック>。

      and an optional nickname of the form:

フォームの任意のあだ名:

                  <Nickname>

<あだ名>。

                                                                [Page 1]

RWW 20 OCT 71 7837                                More on Standard Names

もう標準の名前に関する[1ページ]RWW10月20日の71 7837

   We have heard no arguments to support severe restrictions on name
   length and, therefore, human considerations should probably
   prevail, but would suggest the following guidelines.

私たちが名前の長さで厳しい制限をサポートするために議論を全く聞いていなくて、したがって、人間の問題は、たぶん行き渡るべきですが、以下のガイドラインを示すでしょう。

      <Institution Mnemonic> will be at most 4 characters, formed as
      per RFC 247, NIC (7688,).

NIC、<団体Mnemonic>がRFC247に従って形成されたほとんどの4つのキャラクタにあるでしょう(7688)。

         Examples of Institutions being:  AMES, CASE, BBN, UCLA,
         SRI, MIT, HARV, MITR, etc.

以下の通りであるInstitutionsに関する例 エームズ、ケース、BBN、UCLA、様、MIT、HARV、MITRなど

         We must recognize that in the future there may be multiple
         IMPS and TIPS and combinations at a given institution, so
         that there is not a one-to-one correspondence between
         <Institution Mnemonic> and IMPS or TIPS.  Also affiliated
         with the Network, there will be groups and individuals
         without an IMP or a TIP, or with just a terminal to a TIP,
         whose organizations need unique names.

私たちは、複数のIMPS、TIPS、および組み合わせが将来与えられた団体にあるかもしれないと認めなければなりません、<Institution Mnemonic>とIMPSかTIPSとの1〜1つの通信がないように。また、Networkと共に系列であり、IMPかTIPのはないまさしくTIPへの端末をもっている組織がユニークな名前を必要とするグループと個人がいるでしょう。

      <Host or Nic Station Mnemonic> will not have any restriction
      on length, but should if possible be short.  In picking <Host
      or NIC Station Mnemonic>, an order of priority for choosing
      this mnemonic might be

<ホストかNic駅のMnemonic>が長さに少しの制限も持ちませんが、できれば、背が低いはずです。 <HostかNIC駅のMnemonic>を選ぶのにおいて、このニーモニックを選ぶための優先権の注文はそうです。

         (1)  Suborganization within the <Institution Mnemonic>.

(1) <団体ニーモニック>の中のSuborganization。

         (2)  Project mnemonic.

(2) ニーモニックを映し出してください。

         (3)  Machine designation.

(3) 名称を機械加工してください。

         (4) The suggestion in RFC 247, NIC 7688 to include the
         designation TIP or TEST should probably be followed as
         conveying useful information.

(4) RFC247での提案、名称のTIPかTESTを含むNIC7688はたぶん役に立つ情報を伝えるとして続かれるべきです。

         Examples might be:

例は以下の通りです。

            ARC, NMC, NCCTIP, TENEXA, TENEXB, MULTICS, ILLIAC, SAIL,
            DMCG, IMP, TX2, etc.

アーク、NMC、NCCTIP、TENEXA、TENEXB、MULTICS、ILLIAC、帆、DMCG、悪童、TX2など

      The <nickname> should be unique within the network community,
      short, and preferably should be the same as <Host or NIC
      Station Mnemonic> to make life easy for people having to learn
      them.

<あだ名>は、短いネットワーク共同体の中でユニークであるべきであり、望ましくは、彼らを学ばなければならない人々のために問題を楽にするために<HostかNIC駅のMnemonic>と同じであるべきです。

   I would strongly recommend that Telnets recognize both the Formal
   Name and the Nickname.

私は、TelnetsがFormal NameとNicknameの両方を認識することを強く勧めるでしょう。

                                                                [Page 2]

RWW 20 OCT 71 7837                                More on Standard Names

もう標準の名前に関する[2ページ]RWW10月20日の71 7837

   Now the sticky question:  who chooses the names?  The only
   satisfactory answer is to allow the hosts, through their liaison,
   to choose their own names, possibly subject to some discussion if
   duplicate or extra long names are picked.  Hosts or stations at a
   given institution should use the same <Institution Mnemonic>.

現在の厄介な問題: だれが名前を選びますか? 唯一の申し分のない答は、写しか余分な長い名前が粒選りであるなら、彼らの連絡でホストを許容して、ことによると何らかの議論を条件としたそれら自身の名前を選ぶことです。 与えられた団体のホストかステーションが同じ<Institution Mnemonic>を使用するべきです。

   Let's settle this issue as soon as possible, say by November 5;
   each liaison please send me your names by then.

できるだけ早く、この問題に決着をつけて、11月5日までに言いましょう。 その時までにあなたの名前を各連絡を私に送ってください。

   If there are any implementation hardship cases, other than TIPs,
   caused by the above scheme, please let me know as soon as
   possible.

何か実現苦労事件があれば、上の計画によって引き起こされたTIPsを除いて、できるだけ早く、私にお知らせください。

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by BBN Corp. under the   ]
         [ direction of Alex McKenzie.                   12/96   ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの指示。 12/96 ]

                                                                [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 

スポンサーリンク

apacheのSSL設定

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

上に戻る