RFC805 日本語訳
0805 Computer mail meeting notes. J. Postel. February 1982. (Format: TXT=12522 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
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ページ]
一覧
スポンサーリンク