RFC805 日本語訳

Network Working Group                                          J. Postel
Request for Comments:  805                                           ISI
                                                         8 February 1982

コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 805 ISI1982年2月8日

                      Computer Mail Meeting Notes

コンピュータメールミーティング注意

Introduction

序論

   A meeting was held on the 11th of January 1982 at USC Information
   Sciences Institute to discuss addressing issues in computer mail.
   The attendees are listed at the end of this memo.  The major
   conclusion reached at the meeting is to extend the
   "username@hostname" mailbox format to "username@host.domain", where
   the domain itself can be further structured.

会合がコンピュータメールで問題提示について議論するUSC情報Sciences Instituteの1982年1月11日に行われました。 出席者はこのメモの端に記載されています。 ミーティングで達した主要な結論は" username@hostname "メールボックス形式を" username@host.domain "に広げることです。そこでは、さらにドメイン自体を構造化できます。

Overview

概観

   The meeting opened with a brief discussion of the objectives of the
   meeting and a review of the agenda.

ミーティングはミーティングの目的の簡潔な議論と議題のレビューで開きました。

      The meeting was called to discuss a few specific issues in text
      mail systems for the ARPA Internet.  In particular, issues of
      addressing are of major concern as we develop an internet in which
      mail relaying is a common occurance.  We need to discuss
      alternatives in the design of the mail system to provide high
      utility at reasonable cost.  One scheme suggested is to create
      "mail domains" which are another level of addressing.  The ad hoc
      scheme of source routing, while effective for some cases, is seen
      to lead to some problems.  A key test of addressing schemes is the
      procedure for sending copies of a reply to a message to the people
      who received copies of the original message.  The key reference
      documents for the meeting were RFCs 788, 799, and 801.

ミーティングは、ARPAインターネットのテキストメールシステムのいくつかの特定の問題について議論するために召集されました。 アドレシングの問題は私たちがメールリレーが一般的なoccuranceであるインターネットを開発するように特に、主要な関心事のものです。 私たちは、手頃な費用で高いユーティリティを提供するためにメールシステムの設計における代替手段について議論する必要があります。 示された1つの計画は別のレベルのアドレシングである「メール・ドメイン」を作成することです。 ソースルーティングの臨時の計画はいくつかのケースに有効である間、いくつかの問題を引き起こすのを見られます。アドレシング計画の主要なテストは、オリジナルのメッセージのコピーを受け取った人々へのメッセージに回答のコピーを送るための手順です。 ミーティングのための主要な参考書類はRFCs788、799、および801でした。

   Jon Postel gave a brief review of the NCP-to-TCP transition plan (RFC
   801).  The emphasis was on mail, the internet host table, and the
   role of a Host Name Server.

ジョン・ポステルはNCPからTCPへの変遷プラン(RFC801)の寸評を与えました。 強調がHost Name Serverのメール、インターネットホストテーブル、および役割にありました。

   The major part of the meeting was devoted to a wide ranging
   discussion of the general mailbox identification problem.  In
   particular, the notion of a hierarchial structure of name domains was
   discussed, and the issues associated with name servers were discussed
   including the types of information name servers should provide.

ミーティングの大半が一般的なメールボックス識別問題の広い及んでいる議論にささげられました。 特に、名前ドメインのhierarchial構造の概念について議論しました、そして、ネームサーバに関連している問題は議論して、情報ネームサーバのタイプを含んでいて、提供するべきであるということでした。

Name Domains

名前ドメイン

   One of the interesting ideas that emerged from this discussion was
   that the "user@host" model of a mailbox identifier should, in

この議論から出て来たおもしろい考えの1つはメールボックス識別子の" user@host "モデルがそうするべきであるということでした、コネ

Postel                                                          [Page 1]

ポステル[1ページ]

Computer Mail Meeting Notes                              8 February 1982

コンピュータメールミーティングは1982年2月8日に注意します。

   principle, be replaced by a "unique-id@location-id" model, where the
   unique-id would be a globally unique id for this mailbox (independent
   of location) and the location-id would be advice about where to find
   the mailbox.  However, it was recognized that the "user@host" model
   was well established and that so many different elaborations of the
   "user" field were already in use that there was no point in persuing
   this "unique-id" idea at this time.

原則、" unique-id@location-id "モデルに取り替えられてください。そうすれば、位置イドはどこでメールボックスを見つけるかに関するアドバイスでしょう。(そこでは、ユニークなイドがこのメールボックス(位置の如何にかかわらず)のためのグローバルにユニークなイドでしょう)。 しかしながら、" user@host "モデルが確固として、「ユーザ」分野のとても多くの異なった労作が既に使用中であったのでこのときこの「ユニークなイド」考えをpersuingする意味が全くなかったと認められました。

   Several alternatives for the structuring and ordering of the
   extensions to the "host" field to make it into a general
   "location-id" were discussed.

一般的な「位置イド」にそれを作りかえる「ホスト」分野への拡大の構造と注文のためのいくつかの選択肢について議論しました。

      These basically involved adding more hierarchical name information
      either to the right or the left of the @, with the "higher order"
      portion rightmost or leftmost.  It was clear that the information
      content of all these syntactic alternatives was the same, so that
      the one causing least difficulty for existing systems should be
      chosen.  Hence it was decided to add all new information on the
      right of the @ sign, leaving the "user" field to the left
      completely to each system to determine (in particular to avoid the
      problem that some systems already use dot (.) internally as part
      of user names).

これらは、「より高いオーダー」部分が一番右であることでの@の右か左か一番左のどちらかで、より階層的な名前情報を加えることを基本的に伴いました。 これらのすべての構文の選択肢の情報量が同じであったのは、明確でした、既存のシステムのために最少の困難を引き起こす選ばれるべきであるように。 したがって、それは@サインの右に関するすべての新情報を加えるために決められました、完全に決定する各システムへの左に「ユーザ」野原を出て(いくつかのシステムが既にドットを使用するという問題を避けるために特定である、()、内部的である、ユーザ名の一部)

   The conclusion in this area was that the current "user@host" mailbox
   identifier should be extended to "user@host.domain" where "domain"
   could be a hierarchy of domains.

この領域での結論は現在の" user@host "メールボックス識別子が「ドメイン」がドメインの階層構造であるかもしれない" user@host.domain "に広げられるべきであるということでした。

      In particular, the "host" field would become a "location" field
      and the structure would read (left to right) from the most
      specific to the most general.

特に、「ホスト」分野は「位置」分野になるでしょう、そして、構造は最も特定であるのから最も多くの一般まで読み込まれるでしょう(右にいなくなります)。

         For example: "Postel@F.ISI.IN" might be the mailbox of Jon
         Postel on host F in the ISI complex of the Internet domain.

例えば: " Postel@F.ISI.IN "はインターネットドメインのISI複合体のホストFの上のジョン・ポステルのメールボックスであるかもしれません。

      Formally, in RFC733, the host-indicator definition rule would
      become:

正式に、RFC733では、ホストインディケータ定義規則はなるでしょう:

         host indicator = ( "at" / "@" ) domains

ホストインディケータ=(“at"/"@")ドメイン

         domains = node / node "." domains

「ドメイン=ノード/ノード」 」 ドメイン

            Note only one "at" or "@" is allowed, and that the domains
            form a hierarchy with the most general in scope last.

1“at"か"@"が許容されていて、ドメインが最後に最も多くの一般と共に範囲で階層構造を形成するだけであることに注意してください。

            And note that the choice of domain names must be
            administratively controlled and the highest level domain
            names must be globally unique.

そして、行政上ドメイン名の選択を制御しなければならなくて、最高水準ドメイン名がグローバルにユニークでなければならないことに注意してください。

Postel                                                          [Page 2]

ポステル[2ページ]

Computer Mail Meeting Notes                              8 February 1982

コンピュータメールミーティングは1982年2月8日に注意します。

      The hierarchial domain type naming differs from source routing in
      that the former gives absolute addressing while the latter gives
      relative adressing.

hierarchialドメインタイプ命名は後者が相対的なadressingを与えますが、前者が絶対アドレス指定を与えるという点においてソースルーティングと異なっています。

Name Servers

ネームサーバ

   The discussion of name servers identified three separate name server
   functions: "white pages", "unique-id to location-id", and
   "location-id to address".

ネームサーバの議論は3つの別々のネームサーバ機能を特定しました: 「ホワイトページ」、「位置イドへのユニークなイド」、および「記述する位置イド。」

      The "white pages" service is a way of looking up a user by name
      and other properties using pattern matching and may return several
      data base "hits".  Each hit must have an associated unique-id.

「ホワイトページ」サービスは、名前と他の特性でパターン・マッチングを使用することでユーザを訪ねる方法であり、数個のデータベース「ヒット」を返すかもしれません。 各ヒットには、関連ユニークなイドがなければなりません。

      The "unique-id to location-id" service returns the character
      string location-id where the unique-id is currently found.

「位置イドへのユニークなイド」のサービスはユニークなイドが現在見つけられるところに文字列位置イドを返します。

      The "location-id to address" service returns a network address
      (numeric) corresponding to the location-id.

「記述する位置イド」サービスは位置イドに対応するネットワーク・アドレス(数値)を返します。

         If the location-id is the name of a host in the current domain
         it is clear that the address returned will be the address to
         send the mail to, but if the location-id is that of some other
         domain then the address returned may be either the address to
         send the mail to, or the address of a name server for that
         domain, and these two cases must be distinguished.

位置イドがメールを送るのが返されたアドレスがなるアドレスが明確である現在のドメインのホストの名前ですが、位置イドがある他のドメインのものであるなら、返されたアドレスは、メールを送るアドレスかそのドメインへのネームサーバのアドレスのどちらかであるかもしれません、そして、これらの2つのケースを区別しなければなりません。

   The conclusion of this discussion was that a location-id to address
   name service must be defined soon.  The other types of name servers
   were not further discussed, and are not required in the
   implemenation.

この議論の結論はすぐ名前サービスを記述する位置イドを定義しなければならないということでした。 他のタイプのネームサーバは、さらに議論しないで、またimplemenationで必要ではありません。

   Another aspect of the name server is returning additional information
   besides the address.  In particular, for mail it is important to know
   which mail procedures the destination implements (NCP/FTP, TCP/SMTP,
   etc.).  Two approaches were discussed: one is coding the information
   as service names (e.g., NCP/SMTP), and the other is by reference to
   protocol and port numbers (e.g., PROTOCOL=6, PORT=25).  Another
   suggestion was that the request ought to be "location-id,service"
   (e.g., "ISIF.IN,MAIL") and the response ought to be the location-id,
   address, protocol, and port.  A different way of getting this
   information was suggested that instead of (or in addition to) having
   this information in the name server, one should get this data from
   the host itself via some sort of query or "who are you" protocol.

ネームサーバのもう一つの側面はアドレス以外に追加情報を返しています。 メールに関して、目的地がどのメール手順を実行するかを(NCP/FTP、TCP/SMTPなど)知るのは特に、重要です。 2つのアプローチについて議論しました: サービスが(例えば、NCP/SMTP)を命名するとき、1つは情報をコード化しています、そして、議定書の中で述べる参照とポートナンバーに従って、もう片方があります(例えばプロトコルは6、PORT=25と等しいです)。 別の提案は応答が要求が「位置イド、サービス」であるべきであり(例えば、「ISIF.IN、メール」)、位置イドと、アドレスと、プロトコルと、ポートであるべきであるということでした。 に加えてまたは、の代わりにする、この情報を得る異なった方法が示された、その()、ネームサーバにおけるこの情報を持っていて、ホスト自身からある種の質問でこのデータを得るべきですか、または「あなたはだれです」は議定書を作るか。

   Also discussed was the initial  provision for name service.  It seems
   useful to start with a text file that can be accessed via FTP, and to
   have both "Telnet-Like" (i.e., based on TCP) and "Datagram" (i.e.,

また、議論しているのは、名前サービスへの初期の支給でした。 すなわちFTPでアクセスできるテキストファイルから始まって、「telnetのよう(すなわち、TCPに基づいている)」と「データグラム」の両方を持っているのが役に立つように思える、(。

Postel                                                          [Page 3]

ポステル[3ページ]

Computer Mail Meeting Notes                              8 February 1982

コンピュータメールミーティングは1982年2月8日に注意します。

   based on UDP) access to a query server.  This might be possible as an
   extension of the IEN-116 name server.

UDP) 質問サーバへのアクセスに基づいて. これはIEN-116ネームサーバの拡大として可能であるかもしれません。

   Another issue was the central vs. distributed implementation of the
   name look up service.  It is recognized that separate servers for
   each domain has administrative and maintenance advantages, but that a
   central server may be a useful first step.  It is also recognized
   that each distinct database should be replicated a few times and be
   avialiable from distinct servers for robust and reliable service.

別の問題は見上げるという名前の分配された実現に対して主要なサービスでした。 各ドメインへの別々のサーバには管理と維持利点がありますが、セントラルサーバーが役に立つ第一歩であるかもしれないと認められます。 また、それぞれの異なったデータベースが数回模写されて、強健で信頼できるサービスのための異なったサーバからavialiableであるはずであると認められます。

   An Example:

例:

      Suppose that the new mailbox specification is of the form
      USER@HOST.ORG.DOMAIN.

新しいメールボックス仕様がフォーム USER@HOST.ORG.DOMAIN のものであると仮定してください。

         e.g., Postel@F.ISI.IN

例えば、 Postel@F.ISI.IN

      A source host sending mail to this address first queries a name
      server for the domain IN (giving the whole location "F.ISI.IN").

このアドレスにメールを送る送信元ホストは最初に、ドメインINにネームサーバについて質問します(全体の位置の「F.ISI.IN」を与えて)。

      The result of the query is either (1) the final address of the
      destination host (F.ISI), or (2) the address of a name server for
      ISI, or (3) the address of a forwarder for ISI.  In cases 1 and 3,
      the source host sends the mail to the address returned.  In case
      2,  the source host queries the ISI name server and ... (recursive
      call to this paragraph).

質問の結果はそうです。(1) あて先ホスト(F. ISI)の最終アドレス(2) ISIのためのネームサーバのアドレス、または(3) ISIのための混載業者のアドレスのどちらか。 場合1と3では、送信元ホストは返されたアドレスにメールを送ります。 場合2では、送信元ホストはISIネームサーバと…について質問します。 (このパラグラフへの再帰的呼び出し。)

Action Items:

宿題:

   RFC 733 Revision

RFC733改正

      To include the hierarchial host and domain naming procedure, and
      to delete the features decommitted at the Computer Mail meeting on
      10-JAN-79.

hierarchialホストとドメイン命名手順を含んで、10 1月の79でコンピュータメールミーティングで反遂行された特徴を削除するために。

      By: Dave Crocker

: デーヴ・クロッカー

      Due: 15-Feb-82

支払われるべきもの: 1982年2月15日

   Host Name Server Description

ホスト名サーバ記述

      To specify a way to get name to address conversions and to find
      out about services offered.  Also how to get info on domain names.

名前が変換を記述して、提供されたサービスを見つけるのを得る方法を指定するために。 ドメイン名に関するインフォメーションを得る方法も。

      By: Jon Postel

: ジョン・ポステル

      Due: 15-Feb-82

支払われるべきもの: 1982年2月15日

Postel                                                          [Page 4]

ポステル[4ページ]

Computer Mail Meeting Notes                              8 February 1982

コンピュータメールミーティングは1982年2月8日に注意します。

   Transition Plan Revision

変遷プラン改正

      To include new host and domain names.

新しいホストとドメイン名を含むように。

      By: Jon Postel

: ジョン・ポステル

      Due: 15-Feb-82

支払われるべきもの: 1982年2月15日

   SMTP Revision

SMTP改正

      To include new host and domain names.

新しいホストとドメイン名を含むように。

      By: Jon Postel

: ジョン・ポステル

      Due: Unspecified

支払われるべきもの: 不特定

   Mail System Description Revision

システム記述改正を郵送してください。

      How to do mail systems, including use of SMTP and Host Name
      Server.

SMTPとHost Name Serverの使用を含むシステムを郵送する方法。

      By: Jon Postel

: ジョン・ポステル

      Due: Unspecified

支払われるべきもの: 不特定

   Conversion of User Programs and Mailer Programs.

ユーザ・プログラムと郵送者プログラムの変換。

      Programs have to handle dots in the "host" field.  Many programs
      on many hosts will have to be modified to a greater or lesser
      extent.  In many cases the modifications should be quite simple.

プログラムは「ホスト」分野でドットを処理しなければなりません。 多くのホストの上の多くのプログラムが多かれ少なかれ変更されなければならないでしょう。 多くの場合、変更はかなり簡単であるべきです。

      By: A Cast of Thousands

: 数千のキャスト

      Due: Unspecified (See the Following Item)

支払われるべきもの: 不特定(以下の項目を見ます)

   Set a date when it ok to send messages with dots in "host" field.

それであることの日付にドットが「ホスト」分野にある状態でメッセージを送るようにOKに設定してください。

      The must be a date after which it is ok to send host fields with
      dots  throughout the ARPANET and Internet world without the
      recipients complaining.

必須である、受取人が不平を言わないでアルパネット中にドットがあるホスト分野とインターネットの世界を送るのが間違いない日付になってください。

      By: DARPA (Duane Adams)

: DARPA(ドウェイン・アダムス)

      Due: 1-Mar-82

支払われるべきもの: 1982年3月1日

Postel                                                          [Page 5]

ポステル[5ページ]

Computer Mail Meeting Notes                              8 February 1982

コンピュータメールミーティングは1982年2月8日に注意します。

Attendees:

出席者:

   Duane A. Adams    DARPA/IPTO    Adams@ISI           (202) 694-8096
   Vint Cerf         DARPA/IPTO    Cerf@ISI            (202) 694-3049
   Harry Forsdick    BBN           Forsdick@BBN        (617) 497-3638
   Eric Schienbrood  BBN           shienbrood@bbn-unix (617) 497-3756
   Bob Thomas        BBN           BThomas@BBND        (617) 497-3483
   Bob Fabry         Berkeley      Fabry@Berkeley      (415) 642-2714
   Bill Joy          Berkeley      unj@berkeley        (415) 642-7780
   Gene Ball         CMU           Ball@CMUA           (412) 578-2569
   Anil Agarwal      COMSAT        Agarwal@ISID        (301) 863-6103
   David L. Mills    COMSAT        Mills@ISID          (202) 863-6092
   Dave Crocker      Univ. Del     DCrocker@Udel       (302) 738-8913
   Ray McFarland     DoD           McFarland@ISIA      (301) 796-6290
   Dave Lebling      MIT           PDL@MIT-XX          (617) 253-1440
   Paul Mockapetris  ISI           Mockapetris@ISIF    (213) 822-1511
   Jon Postel        ISI           Postel@ISIF         (213) 822-1511
   Carl Sunshine     ISI           Sunshine@ISIF       (213) 822-1511
   Mark Crispin      Stanford U.   Admin.MRC@SCORE     (415) 497-1407
   Bob Braden        UCL[A]        braden@ISIA      (uk) (01)387-7050
   Steve Kille       UCL           UCL-Netwiz@ISIE  (uk) (01)387-7050
   Bill Tuck         UCL           UKSAT@ISIE       (uk) (01)387-7050
   Marv Solomon      Univ. Wisc    Solomon@UWisc
   Ed Taft           Xerox Parc    Taft@Parc-Maxc      (415) 494-4419

ドウェインA.アダムスDARPA/IPTO Adams@ISI (202)694-8096VintサーフDARPA/IPTO Cerf@ISI (202)694-3049ハリーForsdick BBN Forsdick@BBN (617)497-3638エリックSchienbrood BBN shienbrood@bbn-unix (617)497-3756ボブトーマスBBN BThomas@BBND (617)497-3483ボブファブリバークレー Fabry@Berkeley (415)642-2714ビル喜びバークレー unj@berkeley (415)642-7780遺伝子ボール米カーネギーメロン大学 Ball@CMUA (412)578-2569コマツナギAgarwalコミュニケーションサテライトコーポレーション Agarwal@ISID (301)863-6103デヴィッドL.はコミュニケーションサテライトコーポレーション Mills@ISID (202)863-6092デーヴ医者大学を製粉します。 デル DCrocker@Udel (302)738-8913レイマクファーランドDoD McFarland@ISIA (301)796-6290デーヴLebling MIT PDL@MIT-XX (617)253-1440ポールMockapetris ISI Mockapetris@ISIF (213)822-1511ジョンポステルISI Postel@ISIF (213)822-1511カール日光ISI Sunshine@ISIF (213)822-1511マーククリスピンスタンフォードU. Admin.MRC@SCORE (415)497-1407ボブブレーデンUCL[A] braden@ISIA (uk)(01)387-7050スティーブKille UCL UCL-Netwiz@ISIE (uk)(01)387-7050ビルタックUCL UKSAT@ISIE (uk)(01)387-7050マーヴソロモン大学 Wisc Solomon@UWisc エドタフトゼロックスParc Taft@Parc-Maxc (415)494-4419

Postel                                                          [Page 6]

ポステル[6ページ]