RFC757 日本語訳
0757 Suggested solution to the naming, addressing, and deliveryproblem for ARPANET message systems. D.P. Deutsch. September 1979. (Format: TXT=35618 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC 757
RFC757
A Suggested Solution to the Naming, Addressing, and Delivery
Problem for ARPAnet Message Systems
ARPAnetメッセージシステムのための命名、アドレシング、および配送問題の提案された解決法
Debra P. Deutsch
デブラP.ドイツ語
10 September 1979
1979年9月10日
Bolt Beranek and Newman
ボルトBeranekとニューマン
50 Moulton Street
50モールトン通り
Cambridge, Massachusetts 02138
ケンブリッジ、マサチューセッツ 02138
(617) 491-1850
Preface Page 1
(617) 491-1850 序文1ページ
Preface
序文
Unlike many RFCs, this is not a specification of a soon-to-be-implemented protocol. Instead this is a true request for comments on the concepts and suggestions found within this document, written with the hope that its content, and any discussion which it spurs, will contribute towards the design of the next generation of computer-based message creation and delivery systems.
多くのRFCsと異なって、これはもうすぐ実装しているプロトコルの仕様ではありません。 代わりに、概念のコメントを求めてこれは本当の要求です、そして、提案によって、望みをもって書かれたこのドキュメントの中に内容、およびそれが拍車をかけるどんな議論もコンピュータベースのメッセージ作成と配送システムの次世代のデザインを寄付するのがわかりました。
A number of people have made contributions to the form and content of this document. In particular, I would like to thank Jerry Burchfiel for his general and technical advice and encouragement, Bob Thomas for his wisdom about the TIP Login database and design of a netmail database, Ted Myer for playing devil's advocate, and Charlotte Mooers for her excellent editorial assistance.
多くの人々がこのドキュメントのフォームと中身への貢献をしました。 特に、彼の一般的で技術的なアドバイスと奨励のためのジェリーBurchfiel、netmailデータベースのTIP Loginデータベースとデザインに関する彼の知恵のためのボブ・トーマス、異を立てる人をプレーするためのテッドマイヤー、および彼女の素晴らしい編集の支援のためのシャーロットMooersに感謝申し上げます。
Debbie Deutsch
デビー、ドイツ語
RFC 757 September 1979 Introduction Page 2
RFC757 1979年9月の序論2ページ
1. Introduction
1. 序論
The current ARPAnet message handling scheme has evolved from rather informal, decentralized beginnings. Early developers took advantage of pre-existing tools -- TECO, FTP -- in order to implement their first systems. Later, protocols were developed to codify the conventions already in use. While these conventions have been able to support an amazing variety and amount of service, they have a number of shortcomings.
現在のARPAnetメッセージハンドリング体系はかなり非公式の、そして、分散している始めから発展しました。 初期の開発者はそれらの最初のシステムを導入するために、ツール(TECO、FTP)を先在させる利点を活用しました。後で、プロトコルは、既に使用中のコンベンションを成文化するために開発されました。 これらのコンベンションが驚くべきバラエティーと量のサービスをサポートすることができた間、それらには、多くの短所があります。
One difficulty is the naming/addressing problem, which deals with the need both to identify the recipient and to indicate correctly a delivery point for the message. The current paradigm is deficient in that it lacks a sharp distinction between the recipient's name and the recipient's address, which is the delivery point on the net.
1つの困難が命名/アドレシング問題です。(その問題はともに受取人を特定して、メッセージのために正しく荷渡地を示す必要性に対処します)。 受取人の名前と受取人のアドレスの間で峻別を欠いているので、現在のパラダイムは不十分です。アドレスはネットの荷渡地です。
The naming/addressing scheme does not allow users to address their messages using human names, but instead forces them to employ designations better designed for machine parsing than human identification.
命名/アドレシング体系によって、ユーザが彼らのメッセージを扱うのを人間の名前を使用することで許容しませんが、それらは代わりにやむを得ずマシンのために人間の識別より設計するほうがよい名称で構文解析を使います。
Another source of limitations lies in the delivery system, which is simply an extension of the File Transfer Protocol. The delivery system is fairly limited in its operation, handling only simple transactions involving the transfer of a single message to a single user on the destination host. The ability to bundle messages and the ability to fan-out messages at the foreign host would improve the efficiency and usefulness of the system.
制限の別の源は配送システムに横たわっています。(それは、単にFile Transferプロトコルの拡大です)。 配送システムは稼働中であり公正に制限されます、あて先ホストの上でただ一つのメッセージの転送にシングルユーザーにかかわる単純取引だけを扱って。 メッセージを添付する能力と異種宿主でメッセージを四方八方に広げる能力はシステムの効率と有用性を改良するでしょう。
An additional drawback to the delivery system is caused, to some extent, by the addressing scheme. A change in address, or incorrect address usually causes the delivery system to handle the message incorrectly. While some hosts support some variety of a mail forwarding database (MFDB), this solution is at best inadequate and spotty for providing reliable service to the network as a whole. Because the same username may belong to different people at different hosts, ambiguities which may crop up when messages are incorrectly addressed keep even the best MFDBs from always being able to do their job.
配送システムへの追加欠点はアドレシング体系によってある程度引き起こされます。 アドレスの、または、不正確なアドレスにおける変化で、通常、配送システムは不当にメッセージを扱います。 何人かのホストがメール転送データベース(MFDB)の何らかのバラエティーをサポートしますが、全体でネットワークに対する信頼できるサービスを提供するのに、このソリューションは、せいぜい不十分であって、まだらです。 同じユーザ名が異なったホストの異なった人々のものであるかもしれないので、メッセージが不当に扱われるとき現れるかもしれないあいまいさは、最も良いMFDBsさえいつも仕事できるのを妨げます。
This proposal envisions a system in which the identity and address of the recipient are treated as two separate items. A network database supports a directory service which supplies correct address information for all recipients. Additionally, the scheme allows mail delivery to be restricted to authorized users of the network, should that be a desirable feature.
この提案は受取人のアイデンティティとアドレスが2つの別々の項目として扱われるシステムを思い描きます。ネットワークデータベースは正しいアドレス情報をすべての受取人に提供するディレクトリサービスをサポートします。 さらに、体系は、郵便配達がネットワークの認定ユーザに制限されるのを許容します、それが望ましい特徴であるなら。
RFC 757 September 1979 Names and Addresses Page 3
RFC757 1979年9月は、3ページを命名して、扱います。
2. Names and Addresses
2. 名前とアドレス
Today's ARPAnet naming and addressing scheme (as specified in
RFC 733[3]) does not discriminate between the identity of a user
1
and his address . Both are expressed the same way:
USERNAME@HOST. While this should always result in a unique
handle for that user, it has proved to be inadequate in practice.
Users who change the location of their mailboxes, because of
either a change in affiliation or a simple shift in host usage,
also get their names changed. If their old host employs an MFDB
the problem is not too bad. Mail is simply forwarded on to the
new address, slightly delayed. Other less fortunate users who
cannot rely upon an MFDB must notify all their correspondents of
the change in address/name. Any mail addressed to the old
address becomes undeliverable. (An excellent discussion of the
differences between naming, addressing, and routing is found in a
paper by John Shoch [1].)
今日のARPAnet命名とアドレシングは計画します。指定されるように、RFC 733[3])はユーザ1と彼のアドレスのアイデンティティを区別しません。(両方が同じ道に言い表されます: USERNAME@HOST これはいつもそのユーザにとって、ユニークなハンドルをもたらすべきですが、それは実際には不十分であると判明しました。 また、提携における変化かホスト用法における簡単なシフトのどちらかのために彼らのメールボックスの位置を変えるユーザがそれらの名前を変えさせます。 彼らの年取ったホストがMFDBを使うなら、問題は残念ではありません。 メールは、単に新しいアドレスに送って、わずかに遅らせます。 MFDBを当てにすることができない他のそれほど幸いでないユーザはアドレス/名前における変化について彼らのすべての通信員に通知しなければなりません。 旧住所に扱われたどんなメールも「非-提出物」になります。 (命名と、アドレシングと、ルーティングの違いの素晴らしい議論は論文でジョンShoch[1]によって見つけられます。)
The desire to use "real" names in the address fields of
messages is also thwarted by the current system. An elaborate
system for using human-compatible vs. machine-interpretable
2
information has been evolved for use in message headers . The
most recent developments indicate that many users would feel
happiest if the real human name could appear;
machine-interpretable information should not intrude too heavily
into the writer's work- and thought-space.
また、メッセージのアドレス・フィールドで「本当」の名前を使用する願望は現在のシステムによって阻まれます。 マシン解明できる2とのに対して人間コンパチブル情報を使用する精巧なシステムはメッセージヘッダーにおける使用のために発展されました。最新の開発は、全く人間の名前が現れることができるなら多くのユーザが幸せだと思うのを示します。 マシン解明できる情報は大いに作家の仕事と考えスペースに押し入り過ぎるべきであるというわけではありません。
The solution proposed here calls for a total break between the way a recipient is named or identified and the way in which his location is specified. Since the ARPAnet is a regulated environment, a unique (and not necessarily human-readable) ID could be assigned to each authorized recipient of network mail. This ID would stay with the user throughout his lifetime on the network, through changes in address and affiliation.
ここで提案されたソリューションは受取人が命名されるか、または特定される方法と彼の位置が指定される方法の間で総中断を求めます。 ARPAnetが規制された環境であるので、ユニークで(必ず人間読み込み可能であるというわけではない)のIDをネットワークメールのそれぞれの認可された受取人に割り当てることができました。 このIDは彼の生涯の間中ユーザと共にネットワークにアドレスと提携で変化で滞在するでしょう。
A network database (which could be derived from the same database that has been proposed to support TIP login) would associate each ID with one or more addresses indicating where the mail for that ID may be delivered. If more than one address were
ネットワークデータベース(TIPがログインであるとサポートするために提案されたのと同じデータベースから得ることができた)はそのIDのためのメールがどこに提供されるかもしれないかを示す1つ以上のアドレスに各IDを関連づけるでしょう。 1つ以上のアドレスがそうであったなら
_______________ 1 See, for example, RFC 733's discussion of the semantics of address fields, in which it is specified that the To: field "contains the identity of the primary recipients of the message". 2 See the "Syntax of General Addressee Items" section of RFC 733.
_______________ 1が例えばRFC733のそれが指定されるアドレス・フィールドの意味論の議論を見る、それ、To: 分野は「メッセージのプライマリ受取人のアイデンティティを含んでいます」。 2はRFC733の「一般受け取り人項目の構文」セクションを見ます。
RFC 757 September 1979 Names and Addresses Page 4
RFC757 1979年9月は、4ページを命名して、扱います。
associated with an ID, that would indicate an ordered preference
in delivery points. The delivery system would attempt delivery
to the first addressee, and, if that failed, try the second, and
3
so on . Most IDs would probably have only one address. Also
associated with each ID would be some information about the ID's
owner: name, postal address, affiliation, phone number, etc.
IDに関連していて、それは荷渡地で命令された優先を示すでしょう。 配送システムは、最初の受け取り人に配送を試みて、それが失敗するなら、などに2番目、および3を試みるでしょうに。ほとんどのIDには、1つのアドレスしかたぶんないでしょう。 また、各IDに関連づけられているのは、IDの所有者の何らかの情報でしょう: 名前、郵便の宛先、提携、電話番号など
Rather than being forced to type some awkward character string in order to name his correspondent, the writer would have to supply only enough information to allow some process to determine the unique identity of the recipient. This information might be the recipient's name or anything else found in the database.
何らかの厄介な文字列が彼の通信員を任命するためにタイプさせられるというよりむしろ、作家はあるプロセスが受取人のユニークなアイデンティティを決定するのを許容できるくらいの情報だけを提供しなければならないでしょう。 この情報は、受取人の名前かデータベースで見つけられた他の何かであるかもしれません。
The access to this data would also free the writer from any need to know the location of the recipient. Once the unique ID were known, the correct location for delivery would be only a look-up away.
また、このデータへのアクセスは受取人の位置を知るどんな必要性からも作家を解放するでしょう。 固有のIDがいったん知られていると、配送のための正しい位置は遠くのルックアップにすぎないでしょうに。
2.1 A distributed database approach
2.1 分散データベースアプローチ
It is clear that if the network database had only one instantiation there would be a tremendous contention problem. All message traffic would be forced to query that one database. This is extremely undesirable, both in terms of reliability and speed. It is also clear that requiring each host to maintain a complete local copy of the entire network database is an undesirable and unnecessary burden on the hosts.
ネットワークデータベースがそこに1つの具体化しか持っていないならそれが物凄い主張問題であることは明確です。 すべてのメッセージトラフィックがやむを得ずその1つのデータベースについて質問するでしょう。 これは信頼性と速度において非常に望ましくありません。 また、各ホストが全体のネットワークデータベースの完全な地方のコピーを維持するのが必要であるのが、ホストでの望ましくなくて不要な負担であるのも明確です。
A better approach would be to build some sophistication into the local delivery system, and use local mini-databases which are based upon the contents of a distributed network database. (It may be redundant and/or partitioned, etc., but is probably not resident on the local host.) When a local host queries the network database about an ID (or, in a more costly operation, asked to supply an ID given enough identification such as name, etc.) the database may be asked to return all its information on that ID. At this point the local host can enter all or some of that information into a locally maintained database of its own. It will always refer to that database first when looking for a name or address, only calling the network database if it cannot find a local entry. Depending upon the desired level of sophistication of the local message handling programs, additional information may be added to that database, including, for
より良いアプローチは、何らかの洗練をローカルの配送システムに組み込んで、分配されたネットワークデータベースのコンテンツに基づいているローカルのミニデータベースを使用するだろうことです。 (それは、余分である、そして/または、仕切られるかもしれないなどが、たぶんローカル・ホストで居住していません。) ローカル・ホストがID(または、名前などの十分な識別を考えて、より高価な操作でIDを供給するように頼む)に関するネットワークデータベースについて質問するとき、データベースがそのIDのすべての情報を返すように頼まれるかもしれません。 ここに、ローカル・ホストはそのすべてか何らかの情報をそれ自身の局所的に維持されたデータベースに入力できます。 最初に、名前かアドレスを探すとき、それはいつもそのデータベースを示すでしょう、地方のエントリーを見つけることができない場合にだけネットワークデータベースを呼んで。 追加情報がそのデータベースに追加されるかもしれなくて、包含して、メッセージハンドリングがプログラムを作る必要なレベルに関する地方に関する洗練によります。
_______________ 3 Multiple addresses might also be used to indicate that multiple deliveries are desired.
_______________ 3 また、複数のアドレスが、多重配信が望まれているのを示すのに使用されるかもしれません。
RFC 757 September 1979 Names and Addresses Page 5
RFC757 1979年9月は、5ページを命名して、扱います。
example, nicknames.
例、あだ名。
The database might be shared by a cluster of hosts (such as exist at BBN or ISI), or it might be used by only one. Hosts which originate small amounts of message traffic might rely upon the network database entirely.
データベースがホスト(BBNかISIに存在します)のクラスタによって共有されるかもしれませんか、またはそれは1だけ時までに使用されるかもしれません。 少量のメッセージトラフィックを溯源するホストはネットワークデータベースを完全に当てにするかもしれません。
The structure and maintenance of the local databases is left solely to the local hosts. They may or may not store addresses. It may be desirable either to garbage collect them, or to let them grow. The local databases might be linked to smaller, more specialized databases which are owned by individual users or groups. These individual databases would be the equivalent of address books in which users might note special things about individuals: interests, last time seen, names of associates, etc. The existence and scope of these databases are not mandated by this scheme, but it does allow for them.
ローカルのデータベースの構造とメインテナンスは唯一ローカル・ホストに任せます。 彼らはアドレスを保存するかもしれません。 ゴミの料金先方払いのそれらに、それが望ましいかもしれませんか、またはそれらをさせるのは成長します。 ローカルのデータベースは個々のユーザかグループによって所有されているより小さくて、より専門化しているデータベースにリンクされるかもしれません。 これらの個々のデータベースはユーザが個人に関して特別なことに注意するかもしれないアドレス帳の同等物でしょう: 前回見られた関心、仲間の名前など これらのデータベースの存在と範囲はこの体系によって強制されませんが、それはそれらを考慮します。
The same individual databases may be used by message creation programs in order to determine the recipient's ID from user-supplied input. For example, a user may address a message to someone named Nick. The message creation program may associate "Nick" with an ID, and hand that ID off to the delivery system, totally removing the matter of address or formal ID from the user's world.
同じ個々のデータベースは、ユーザによって供給された入力から受取人のIDを決定するのにメッセージ作成プログラムで使用されるかもしれません。 例えば、ユーザはニックというだれかにメッセージを扱うかもしれません。 メッセージ作成プログラムは、ユーザの世界から配送システム、アドレスの物質を完全に取り除くか、または正式なIDに「ニック」をIDに関連づけて、そのIDを渡すかもしれません。
2.2 Delivery
2.2 配送
The delivery operation consists of three parts:
配送操作は3つの部品から成ります:
1. Determining the address to which the message must be
sent,
1. メッセージを送らなければならないアドレスを決定します。
2. Sending the message,
2. メッセージを送ります。
3. Processing by foreign host.
3. 異種宿主で、処理します。
The first step usually means looking up, in either a local or the network database, the correct address(es) for message delivery, given the recipient's ID. Should the ID not be known at the time the message is submitted for delivery, any operation necessary to determine that ID (such as a call to either the local or network database) is also performed as part of this step.
通常、第一歩は、見上げることを意味します、ローカルかネットワークデータベースのどちらかで、メッセージ配送のための正しいアドレス(es)、受取人のIDを考えて。 配送(また、ID(地方かネットワークデータベースへの呼び出しなどの)がこのステップの一部として実行されることを決定するのに必要などんな操作)のためにメッセージを提出するとき、IDを知っていないべきですか?
The second step is not too different from what happens today. The local host establishes a connection to the foreign host. It is then able to send one or messages to one or more people. The options are:
第2ステップは今日起こることとそれほど異なっていません。 ローカル・ホストは異種宿主に取引関係を築きます。 それはその時、1かメッセージを1人以上の人に送ることができます。 オプションは以下の通りです。
- Bulk mail. Several recipients all get the same message.
- メールを膨らませてください。 数人の受取人が皆、同じメッセージを得ます。
RFC 757 September 1979 Names and Addresses Page 6
RFC757 1979年9月は、6ページを命名して、扱います。
- Bundled mail. Several messages get sent to the same
recipient.
- メールであると添付されます。 いくつかのメッセージを同じ受取人に送ります。
- A combination of the above
- 上記の組み合わせ
- One recipient gets one message.
- 1人の受取人が1つのメッセージを得ます。
The foreign host should be able to accept mail for each ID.
異種宿主は各IDのためのメールを受け入れることができるべきです。
The rejection of mail for a given ID by the foreign host would usually indicate an inconsistency between the sender's local database and the network database. In this case, the local host updates its local database from the network database, and attempts delivery at the "new" host. (This is mail forwarding.) If a host taken from the network database is found to be incorrect, there is a problem in the network database, and appropriate authorities are notified. Thus, address changes propagate out from the network database only as the out-of-date information is referenced. This reduces the magnitude of the local database update problem.
通常、異種宿主による与えられたIDのためのメールの拒絶は送付者のローカルのデータベースとネットワークデータベースの間の矛盾を示すでしょう。 この場合、ローカル・ホストは、ネットワークデータベースからローカルのデータベースをアップデートして、「新しい」ホストで配送を試みます。 (これはメール転送です。) ネットワークデータベースから抜粋されるホストが不正確であることがわかっているなら、ネットワークデータベースには問題があります、そして、適切な当局は通知されます。 したがって、単に古くさい情報が参照をつけられるようにアドレス変化はネットワークデータベースからの外に伝播されます。 これはローカルのデータベース更新問題の大きさを減少させます。
Once the foreign host recognizes the ID(s), the message(s) may be transmitted to the foreign host. Upon successful transmission, the job of the local host is done.
異種宿主がいったんIDを認識すると、メッセージは異種宿主に送られるかもしれません。 うまくいっているトランスミッションのときに、ローカル・ホストの仕事をします。
The third step requires the foreign host to process the message(s). This is analogous to what may occur in a mail room. A foreign host may have to sort the bundled or bulk mail it receives. In addition, the foreign host might perform internal or external fan-out functions or other special functions, at the option of the ID owner.
第3ステップは、異種宿主がメッセージを処理するのを必要とします。 これはメール部屋に起こるかもしれないことに類似しています。 異種宿主はそれが受け取る添付されたか大量のメールを分類しなければならないかもしれません。 さらに、異種宿主が内部で働くかもしれませんか、または外部は機能か他の特別な機能を四方八方に広げます、ID所有者の選択のときに。
The implemention and design of possible functions which may be performed in the mail rooms are neither mandated nor restricted by this delivery scheme. Since they are too numerous to allow even a small portion of them to be described here, only a few examples will be mentioned.
メール部屋で実行されるかもしれない可能な機能のimplementionとデザインは、この配送体系によって強制されないで、また制限されません。 それらがそれらの少量さえここで説明されるのを許容できないくらい非常に多いので、ほんのいくつかの例が言及されるでしょう。
Fan-out functions might include placing messages in multiple files, sending copies to one or more other users, or rebroadcasting the messages onto the network. (In that last case, the foreign host might evaluate an ID list, in much the same way that the ITS mail repeater broadcasts messages addressed to certain mailboxes.) Special functions might include automatic hard-copy creation or reply generation, processing by various daemons, or any other service found desirable by the host's user population and administration. The implementation of fan-out functions is up to the local host, as are any additional functions which the user population might wish of its local "mail room". Whatever services are available, the mail room will distribute the mail to the correct location for each ID.
複数のファイルでメッセージを置くのを含めるかもしれなくて、他の1人以上のユーザにコピーを送るのを機能に四方八方に広げるか、またはネットワークへのメッセージを再放送に四方八方に広げてください。 (その最後の場合では、異種宿主はIDリストを評価するかもしれません、ITSがメッセージが、あるメールボックスに扱ったリピータ放送を郵送する似たり寄ったりの方法で。) 特別な機能は自動ハードコピー作成か回答世代を含むかもしれません、様々なデーモン、またはいかなる他の望ましいホストのユーザ人口と管理によってわかったサービスでも処理して。 四方八方に広がってください。実装、機能はローカル・ホスト次第です、ユーザ人口が願っている地方の「メール部屋」のどんな追加機能のようにも。 いかなるサービスも利用可能であっても、メール部屋は各IDのために正しい位置にメールを配布するでしょう。
RFC 757 September 1979 Names and Addresses Page 7
RFC757 1979年9月は、7ページを命名して、扱います。
2.2.1 Additional delivery options
2.2.1 追加配送オプション
It may be desirable to allow mail rooms to accept a username in place of an ID. Use of a username is a less reliable method of addressing than use of an ID.
IDに代わってユーザ名を受け入れるメール部屋を許容するのは望ましいかもしれません。 ユーザ名の使用はIDの使用よりアドレシングのそれほど信頼できないメソッドです。
- A username may not be sufficiently unambiguous for
getting an ID and host from the network database.
- ネットワークデータベースからIDとホストを得るには、ユーザ名は十分明白でないかもしれません。
- Since a recipient's username may change from time to
time, there is a chance that the username supplied by
4
the sender will be incorrect , or that the host may not
recognize it.
- 受取人のユーザ名が時々変化するかもしれないので、送付者が不正確になるか、またはホストがそれを認識しないかもしれないというユーザ名が4時までに供給した見込みがあります。
Because a recipient's ID does not change with time,
errors such as those caused by username changes cannot
occur if IDs are used. Similarities or ambiguities can
be discovered before delivery occurs, and the sender can
be prompted for additional identifying information about
his intended recipient.
受取人のIDが時間を交換しないので、IDが使用されているなら、ユーザ名変化によって引き起こされたものなどの誤りは発生できません。 配送が起こって、彼の意図している受取人に関する追加身元が分かる情報のために送付者をうながすことができる前に類似性かあいまいさを発見できます。
- In an even worse case, a correct username can still
result in an incorrect delivery when it is paired with
an incorrect host or acted upon by a mail forwarding
5
database .
- さらに悪い場合では、それが不正確なホストと対にされるか、または5データベースを転送する郵便配達人に作用されるとき、正しいユーザ名はまだ不正確な配送をもたらすことができます。
Because unique IDs are unambiguous, the possibility of
such a situation is eliminated by the use of unique IDs.
固有のIDが明白であるので、そのような状況の可能性は固有のIDの使用で排除されます。
_______________ 4 A particularly insidious source of addressing errors stems from the inconsistent use of (human) names and initials to generate usernames. The sender can easily guess his recipient's username incorrectly by using, or failing to use a combination of initials and last name. (For example, a user wishing to address Jim Miller at BBNA and using the address "Miller@BBNA" will have his message successfully delivered to Duncan Miller at the same site.) 5 The author has observed a mail forwarding database redirect messages correctly addressed to one JWalker to different JWalker at another host.
_______________ 4 アドレシング誤りの特に油断のならない源は(人間)の名前とユーザ名を生成するイニシャルの無節操な使用によります。 送付者は使用か、イニシャルの組み合わせを使用する失敗と姓で容易に不当に彼の受取人のユーザ名を推測できます。 (例えば、BBNAでジム・ミラーに演説することを願って、アドレス" Miller@BBNA "を使用しているユーザは同じサイトで彼のメッセージをダンカン・ミラーに首尾よく提供させるでしょう。) 5 作者は、メール転送データベースが別のホストで正しく1JWalkerに扱われたメッセージを異なったJWalkerに向け直すのを観測しました。
RFC 757 September 1979 Names and Addresses Page 8
RFC757 1979年9月は、8ページを命名して、扱います。
2.2.2 Failures
2.2.2 失敗
The case in which the network database is found to be incorrect
has already been discussed. It may make sense to mark the entry
as "possibly in error" and to notify both the network database
6
and the ID owner when such a situation occurs. In this case mail
delivery to the ID's owner will not occur, but this is not too
bad, considering that that is what happens today when a host does
not recognize a username.
既にネットワークデータベースが不正確であることがわかっている場合について議論しました。 そのような状況が起こると、それは「ことによると間違う」としてエントリーを示して、両方に通知する意味にネットワークデータベース6とID所有者になるかもしれません。 この場合、IDの所有者への郵便配達は起こらないでしょうが、これは残念ではありません、それがホストが今日ユーザ名を認めないとき起こることであると考える場合。
One additional failure mode, the loss of the network database from the net, must be considered, even though a well-designed distributed network database should be robust enough to almost rule out this possibility.
1つの追加故障モード(ネットからのネットワークデータベースの損失)を考えなければなりません、よく設計された分配されたネットワークデータベースはこの可能性をほとんど除外するほど強健であるべきですが。
If such a failure should occur, the local databases should be able to handle most of the traffic. What would be lost is the ability to add new IDs to the network database, the ability to change hosts for an ID, the ability to update local databases, and the ability to query the network database. In essence, there would be a regression to the state we are in today.
そのような失敗がそうするなら、起こってください、そして、ローカルのデータベースはトラフィックの大部分を扱うことができるべきです。 失われていることは新しいIDをネットワークデータベースに追加する能力です、ホストをIDに変える能力、ローカルのデータベース、およびネットワークデータベースについて質問する能力をアップデートする能力。 本質には、今日の私たちがいる状態への復帰があるでしょう。
A well-administered network database should be backed up frequently. Should a catastrophic series of hardware failures remove one or more of the network database's hosts from the net, the database could be moved elsewhere. Such a change would entail notification of all hosts on which mail originates. Software which queries the database should be designed to be able to easily handle such a move.
よく管理されたネットワークデータベースは頻繁に支援されるべきです。 壊滅的なシリーズのハードウェアの故障がネットからネットワークデータベースのホストのより多くのひとりを取り除くなら、データベースはほかの場所に動かされるかもしれません。 そのような変化はメールが起因するすべてのホストの通知を伴うでしょう。 データベースについて質問するソフトウェアは、容易にそのような移動を扱うことができるように設計されるべきです。
_______________ 6 Such notification would presumably be by hardcopy mail or telephone.
_______________ おそらく、そのような6つの通知がハードコピーメールか電話であるでしょう。
RFC 757 September 1979 Relationship to TIP Login database Page 9
TIP Loginデータベース9ページへのRFC757 1979年9月のRelationship
3. Relationship to TIP Login database
3. TIP Loginデータベースとの関係
A number of references to the TIP Login problem and a database which has been proposed as part of its solution have been made in this note. A series of working papers [5] written by Bob Thomas, Paul Santos, and Jack Haverty describe an approach to TIP Login. In brief, the method is to build and maintain a distributed TIP Login database, containing information necessary to allow a new entity called a "login-host" to decide whether or not to grant a user access to a given TIP, and whether or not to allow the user to make various modifications to the database itself.
TIP Login問題の多くの参照とソリューションの一部として提案されたデータベースはこの注意で作られています。 ボブ・トーマス、ポール・サントス、およびジャックHavertyによって書かれた一連の働く論文[5]がアプローチをTIP Loginに説明します。 要するに、メソッドは、分配されたTIP Loginデータベースを築き上げて、維持することです、「ログインホスト」と呼ばれる新しい実体が与えられたTIPへのユーザアクセスを承諾するかどうかと、ユーザがデータベース自体への様々な変更をするのを許容するかどうか決めるのを許容するのに必要な情報を含んでいて。
The TIP login database is derived from a "network user data base", which contains information above and beyond that necessary to support TIP login. This comprehensive database is designed to support applications other than TIP Login, either directly or by means of databases derived from it.
「ネットワーク利用者データベース」からTIPログインデータベースを得ます。(それは、それにTIPがログインであるとサポートするのに必要な状態で情報を含みます)。 この総合データベースは、TIP Login、直接またはそれから得られたデータベースによってアプリケーションをサポートするように設計されています。
Contained in the TIP Login database are each user's login string, a list of TIPs the user is authorized to access, the user's unique ID, his password, and any other "permissions" (in addition to which TIPs may be accessed). These permissions may indicate that the user may create, delete, or modify entries in the database, to assume other user's roles, and to what extent he may do so. The notion of permissions as developed by Steve Warshall is discussed in an NSW memo [2].
含まれて、各ユーザのログインストリングがTIP Loginデータベースに、あって、ユーザのTIPsのリストはアクセス、ユーザの固有のID、彼のパスワード、およびいかなる他の「許容」(に加えてTIPsがアクセスされるかもしれないそこで)にも認可されます。 これらの許容は、ユーザが他のユーザの役割を引き受けるようにデータベースにおけるエントリーを作成するか、削除するか、または変更するかもしれないのを示すかもしれません、そして、彼がどんな範囲にするかもしれないかはそうします。 NSWメモ[2]でスティーブWarshallによる開発されるとしての許容の概念について議論します。
It seems entirely reasonable to derive a netmail database from the same comprehensive database that is designed to support TIP Login. The concept of a unique ID is supported by that database. Much of the required information for a netmail database is already included, and the maintenance tools necessary to modify it seem well-suited for the purpose. The concept of permissions extends well to the needs of netmail. Permissions specific to network mail might include, for example, the ability to modify the delivery host list associated with a given user.
TIP Loginをサポートするように設計されているのと同じ総合データベースからnetmailデータベースを得るのは完全に妥当に思えます。 固有のIDの概念はそのデータベースによってサポートされます。 netmailデータベースのための必須情報の多くが既に含められています、そして、それを変更するのに必要なメンテナンス用工具は目的に十分合っているように見えます。 許容の概念はnetmailの必要性によく達します。 ネットワークメールに特定の許容は与えられたユーザに関連している配送ホストリストを変更する例えば能力を含むかもしれません。
The mechanisms necessary for the maintenance of the comprehensive network database and its derived databases give us a netmail database very inexpensively. This proposal takes advantage of that situation.
包括的なネットワークデータベースとその派生しているデータベースのメインテナンスに必要なメカニズムはnetmailデータベースを私たちに非常に安く与えます。 この提案はその状況を利用します。
RFC 757 September 1979 Relationship to RFC 753 Page 10
RFC753 10ページとのRFC757 1979年9月の関係
4. Relationship to RFC 753
4. RFC753との関係
RFC 753 [4] describes an internetwork message delivery system. Very briefly, the approach is to locate one or more "message processing modules" (or MPMs) on each network. These MPMs pass messages across network boundaries, and are also capable of making deliveries to users on the local network. The document also details a proposed message format, along the envelope and letter paradigm. An external "envelope", read by the delivery system, allows the (unread) message to be correctly routed and delivered to the proper recipient. Groups of messages passed between a pair of MPMs are sent together in a "mail bag".
RFC753[4]はインターネットワークメッセージ配送システムについて説明します。 非常に簡潔に、アプローチは1「メッセージ処理モジュール」(または、MPMs)の各ネットワークに場所を見つけることです。 これらのMPMsはネットワーク限界の向こう側にメッセージを通過して、また、企業内情報通信網でユーザに配送できます。 また、ドキュメントは封筒と手紙パラダイムに沿って提案されたメッセージ・フォーマットを詳しく述べます。 配送システムによって読まれた外部の「封筒」は適切な受取人に正しく発送された、提供されるべき(読まれていません)のメッセージを許容します。 「郵便袋」で1組のMPMsの間で通過されたメッセージのグループを一緒に送ります。
This proposal differs from RFC 753 in that it is primarily intended to operate within a network or a concatenation of networks using a common host-host protocol, e.g. TCP. Where RFC 753 addresses the problems of internetwork communication (differing message formats, complex routing, and correct identification of the proper recipient), this note concentrates primarily on what can be done within a single protocol. The two are not incompatible. While a general internetwork protocol must provide general methods which can be compatible with different host-host protocols in different networks, a proposal such as this one can capitalize on the capabilities, resources, and policies of a given catenet (catenated network) such as the ARPAnet/PRnet/SATNET etc.
この提案はネットワークのネットワークか連結の中で一般的なホスト兼ホストプロトコルを使用することで作動することを主として意図するという点においてRFC753と異なっています、例えば、TCP。 RFC753がインターネットワークコミュニケーション(適切な受取人の異なったメッセージ・フォーマット、複雑なルーティング、および正しい識別)のその問題を訴えるところでは、この注意は主としてただ一つのプロトコルの中でできることに集中します。 2は両立しなくはありません。 一般的なインターネットワークプロトコルが一般的なメソッドを提供しなければならない間、どれがSATNET ARPAnet/PRnet/などの与えられたcatenet(ネットワークをcatenatedした)の異なったネットワーク、この人が能力で大文字で書くことができる提案、リソース、および方針で異なったホスト兼ホストプロトコルと互換性がある場合があるか。
4.1 Compatibility
4.1 互換性
The delivery system described in RFC 753 is compatible with the system outlined here. Let's examine this for each of the three basic delivery options performed by the MPM. (In the discussion that follows, "local networks" means a concatenation of networks using a common host-host protocol, e.g. TCP. "Foreign network" means some network which uses a different host-host protocol, e.g. X.25. (See Figure 4-1.)
RFC753で説明された配送システムはここに概説されているシステムと互換性があります。 MPMによって実行されたそれぞれの3つの基本的な配送オプションがないかどうかこれを調べましょう。 続く議論では、「企業内情報通信網」は一般的なホスト兼ホストプロトコルを使用することでネットワークの連結を意味します、例えば、TCP。(「外国ネットワーク」は異なったホスト兼ホストプロトコルを使用する何らかのネットワークを意味します、例えば、X.25。(図4-1を参照してください。)
4.1.1 Outgoing message
4.1.1 送信されるメッセージ
4.1.1.1 RFC 753
4.1.1.1 RFC753
The sender's process hands a message to the local network MPM. The message may be destined to an address on the local network or on a foreign network. In the former case, the MPM performs the local delivery function (see "Incoming message"). In the latter case, the MPM passes the message along to another MPM which is "closer" to the end user.
送付者のプロセスは企業内情報通信網MPMにメッセージを手渡します。 メッセージは企業内情報通信網か外国ネットワークに関するアドレスに運命づけられるかもしれません。 前の場合では、MPMは地方の配送機能を実行します(「入力メッセージ」を見てください)。 後者の場合では、MPMは「より近いところにエンドユーザの」ある別のMPMにメッセージを伝えます。
RFC 757 September 1979 Relationship to RFC 753 Page 11
RFC753 11ページとのRFC757 1979年9月の関係
+---------+ +----------+
| | | |
| RCC-NET | | WIDEBAND | .......
| | | NET | . .
+---------+ | | . MPM .
* * +----------+ .......
+---------+ * * * * ....... |
| | +---------+ . . +---------+
| BBN-NET |***| |__. MPM . ..... | |
| | | ARPANET | ....... . .xxxx| TELENET |
+---------+***| |***********. G . | |
+---------+*** ..... +---------+
* * * * ** .......
+--------+ +-------+ ***..... +-------------+ . .
| | | | . . | |--. MPM .
| SATNET | | PRNET | . G .oooo| DIAL-UP NET | .......
| | | | ..... | |
+--------+ +-------+ +-------------+
+---------+ +----------+ | | | | | RCC-ネット| | 広帯域| ....... | | | ネット| . . +---------+ | | . mpm**+----------+ ....... +---------+ * * * * ....... | | | +---------+ . . +---------+ | BBN-ネット|***| |__. mpm。 | | | | | アルパネット| ....... . .xxxx| テレネット| +---------+***| |***********. G。| | +---------+*** ..... +---------+ * * * * ** ....... +--------+ +-------+ ***..... +-------------+ . . | | | | . . | |--. mpm。| SATNET| | PRNET| . G.oooo| ダイヤルアップネット| ....... | | | | ..... | | +--------+ +-------+ +-------------+
"Local Nets", TCP based | "Foreign Nets", other (direct addressing using IP) | host-host protocols
TCPは、「ローカルのネット」と基礎づけました。| 他(IPを使用する直接アドレス指定)の「外国ネット」| ホスト兼ホストプロトコル
*** = TCP xxx = X.25 ooo = other communications protocol
G = gateway
*** = TCP xxx=X.25 oooは他の通信規約G=ゲートウェイと等しいです。
Figure 4-1: The Internet Environment
図4-1: インターネット環境
4.1.1.2 This proposal
4.1.1.2 この提案
The sender's process determines the proper host for delivery given the recipient's unique ID. If the message is destined to the local network, delivery takes place as described earlier in this proposal. If the recipient is not local, the message may be passed to an MPM for foreign delivery. (A discussion of internet delivery which does not presuppose RFC 753 implementation is found later in this note.)
受取人の固有のIDを考えて、送付者の過程は配送のために適切なホストを決定します。 メッセージが企業内情報通信網に運命づけられているなら、配送はこの提案で、より早く説明されるように行われます。 受取人が地元でないなら、メッセージは外国配送のためにMPMに通過されるかもしれません。 (RFC753実現を予想しないインターネット配信の議論は後でこの注意で見つけられます。)
The environment in which the MPM operates does not assume any knowledge on the part of the local networks about addressees on foreign networks. Thus there are two possibilities which arise:
MPMが作動する環境は外国ネットワークの受け取り人に関する企業内情報通信網側の少しの知識も仮定しません。 したがって、起こる2つの可能性があります:
RFC 757 September 1979 Relationship to RFC 753 Page 12
RFC753 12ページとのRFC757 1979年9月の関係
- The recipient has an ID known to the local networks.
- 受取人は企業内情報通信網においてIDを知らせます。
In this case, the local networks supply the RFC 753
"address". This can take place in the local networks'
MPM or the user's sending or mail creation process.
この場合、企業内情報通信網は「アドレス」をRFC753に供給します。 これはユーザの企業内情報通信網のMPM、発信またはメール創造の過程で行われることができます。
- The recipient is unknown to the local networks.
- 企業内情報通信網において、受取人は未知です。
Here the sender must supply "mailbox" information
himself, either explicitly or with help of his local
host's database.
ここに、送付者は明らかか彼のローカル・ホストのデータベースの助けで自分で「メールボックス」情報を提供しなければなりません。
Thus, outgoing mail as described in this memo is compatible with RFC 753, with the benefit of reducing the burden on the MPM by handling mail deliveries that are local to local networks.
したがって、このメモで説明される送信するメールはRFC753と互換性があります、MPMで企業内情報通信網に地方であることの取り扱い郵便配達で負担を減少させる利益で。
4.1.2 Messages in transit
4.1.2 トランジットにおけるメッセージ
Traffic between two MPMs is not affected by this proposal.
2MPMsの間の交通はこの提案で影響を受けません。
4.1.3 Incoming mail
4.1.3 入って来るメール
The MPM on the networks local to the recipient will have access to the netmail database, allowing it to translate "mailboxes" to "addresses". It can determine the unique ID of the recipient (if not known), and initiate delivery to that recipient. Here RFC 753 and this proposal complement each other very well.
受取人にとっての、ローカルのネットワークのMPMはnetmailデータベースに近づく手段を持つでしょう、「メールボックス」を「アドレス」に翻訳するのを許容して。 それは、受取人(そうでなければ、知られている)の固有のIDを決定して、その受取人に配送を開始できます。 ここで、RFC753とこの提案は互いの非常によく補足となります。
RFC 757 September 1979 Implications of an internetwork message environment Page 13
インターネットワークメッセージ環境13ページのRFC757 1979年9月Implications
5. Implications of an internetwork message environment
5. インターネットワークメッセージ環境の含意
The scheme described above is based upon the assumption that a unique identifier can be assigned to each registered recipient of mail. Whether or not this uniqueness can be guaranteed in a fairly unregulated internetwork environment is questionable. It is technically feasible, certainly. The difficulties are more political, because it is necessary to gain the cooperation of the administrators and user populations of foreign networks. Let's assume cooperation, however, and see what might happen in an internet environment.
上で説明された計画はメールのそれぞれの登録された受取人にユニークな識別子を割り当てることができるという仮定に基づいています。 かなり調節されないインターネットワーク環境でこのユニークさを保証できるかどうかが疑わしいです。 確かに、それは技術的に可能です。 困難は、より政治上です、管理者の協力と外国ネットワークのユーザの母集団を獲得するのが必要であるので。 しかしながら、協力を仮定して、何がインターネット環境で起こるかもしれないかを見ましょう。
5.1 Birthplaces
5.1 出生地
Each set of local networks would have its own database, for ease in access. It does not seem practical to register each ID in every database, however. That would be unnecessary, and would create access and storage problems at the network databases. Here the concept of a "birthplace", or ID origin, may be of use.
それぞれのセットの企業内情報通信網はアクセサリーに容易さのためのそれ自身のデータベースを持っているでしょう。 しかしながら、あらゆるデータベースの各IDを登録するのは実用的に思えません。それは、不要であるだろう、ネットワークデータベースでアクセスと格納問題を生じさせるでしょう。 ここで、「出生地」、またはIDの起源の概念は役に立つかもしれません。
While an ID does not imply where the user is now, it can say something about who issued it. A simple system for determining the address for any ID can be maintained by having the issuing network keep a pointer for each ID it issues. One double indirection would yield the desired address, even if the ID were not issued on the local nets. A message originating on the local nets with an ID which is unknown to its database can be handled by determining the birthplace of the ID. An inquiry to the birthplace database would return a list of one or more networks on which the ID is registered. An inquiry to any of those would get the requisite information. All that is necessary to support this is for the birthplace record (small enough!) to be kept, and for the act of registration at a given net to automatically cause that net to notify the birthplace of the registration. (Conversely, a de-registration would cause a similar notification of the birthplace.)
IDは、だれがそれを発行したかに関して現在ユーザがそうで何かを示すことができるのを含意しませんが。 発行ネットワークにそれが発行する各IDのためのポインタを保たせることによって、どんなIDへのアドレスも決定する簡単なシステムを維持できます。 IDがローカルのネットで発行されなかったとしても、1つの二重間接指定が必要なアドレスをもたらすでしょうに。 IDの出生地を決定することによって、データベースにおいて、未知であることのIDと共にローカルのネットで由来するメッセージは扱うことができます。 出生地データベースへの問い合せはIDが登録されている1つ以上のネットワークのリストを返すでしょう。 それらのどれかへの問い合せは必要な情報を得るでしょう。 これを支持するのに必要なすべては、出生地記録(十分小さい!)がつけられて、そのネットが与えられたネットにおける登録の行為で自動的に登録の出生地に通知することです。 (逆に、反-登録は出生地の同様の通知を引き起こすでしょう。)
5.1.1 ID resolution
5.1.1 ID解決
The handling of ID resolution when the ID is not known to the local net does not seem to have a solution simpler than querying foreign nets until some success is achieved.
IDがローカルのネットに知られていない場合、ID解決の取り扱いは解決策を何らかの成功が遂げられるまで外国ネットについて質問するより簡単にするように思えません。
5.1.2 Hosts in an internet environment
5.1.2 インターネット環境におけるホスト
The substitution of internet host names for simple host names should not cause any difficulty.
簡単なホスト名のためのインターネットホスト名の代替は少しの困難も引き起こすべきではありません。
RFC 757 September 1979 Implications of an internetwork message environment Page 14
インターネットワークメッセージ環境14ページのRFC757 1979年9月Implications
5.1.3 Orphans
5.1.3 孤児
Should a birthplace cease to exist (usually because its network is dismantled), it would be necessary for a second birthplace to "adopt" the first birthplace's records. Notification of this change could be propagated throughout the internet environment in much the same way as the addition of a new birthplace would be treated.
出生地が消滅するなら(通常、ネットワークが解体されるので)、2番目の出生地が最初の出生地の記録を「採用」であることが必要でしょう。 大体同じようなやり方で新しい出生地の添加が扱われるようにインターネット環境中でこの変化の通知を伝播できました。
RFC 757 September 1979 Conclusions Page 15
RFC757 1979年9月結論が15を呼び出します。
6. Conclusions
6. 結論
While ARPAnet message systems have been amazingly successful, there is much room for improvement in the quality and quantity of the services offered. Current protocols are limiting the development of new message systems. This paper has discussed a means of providing the underlying support necessary for building a new generation of message systems which can be better human-engineered in addition to providing more services and greater reliability.
ARPAnetメッセージシステムは驚くほどうまくいっていますが、サービスの品質と量に改善の余地が提供した多くがあります。 現在のプロトコルは新しいメッセージシステムの開発を制限しています。この論文は新しい世代の間、より良いより多くのサービスを提供することに加えて人間によって設計されて、より大きい信頼性であるかもしれないメッセージシステムを造るのに必要な基本的なサポートを提供する手段について議論しました。
Critics may argue that the proposal is too radical, too much of a departure from current practice. After all, today's message service is extremely straightforward in design, and therefore has comparatively few failure modes. The protocols in use have descended, with relatively few changes, from the first file transfer and message format protocols implemented on the ARPAnet. This makes them well understood; people are aware of both their shortcomings and usage. Finally, there are people who will not feel comfortable about requiring a network database, distrusting the reliability and questioning the possible cost of such a scheme.
評論家は、提案が現在の習慣からの急進的過ぎて、大した過ぎる出発であると主張するかもしれません。 結局、今日のメッセージサービスは、デザインで非常に簡単であり、したがって、比較的わずかな故障モードしか持っていません。 使用中のプロトコルは下りました、比較的わずかな変化で、ARPAnetで実行された最初のファイル転送とメッセージ・フォーマットプロトコルから。 これで、それらをよく理解しています。 人々は彼らの短所と用法の両方を意識しています。 最終的に、ネットワークデータベースを必要とすることに関して快適であると感じない人々がいて、不信用が信頼性であり、そのようなものの可能な費用に質問するのは、計画です。
On the other hand, it is undeniably true that very little more can be done to improve message services while staying within today's practices. New message systems which will be able to transmit facsimile, voice, and other media along with text require us to rethink message formats and do away with delivery protocols which are predicated upon the characteristics of ASCII text. The inception of internetwork message delivery causes us to re-evaluate how we handle messages locally. Finally, the USERNAME@HOST naming scheme has proved to be inadequate, while the divorce of recipients' identities from their locations seems a promising possibility as a replacement.
他方では、今日の習慣の範囲内にとどまっている間、メッセージサービスを改良するためにほとんどさらにすることができないのは明白に本当です。 テキストと共にファクシミリ、声、および他のメディアを伝えることができる新しいメッセージシステムは、私たちがメッセージ・フォーマットを再考して、ASCIIテキストの特性で叙述される配送プロトコルを片づけるのを必要とします。 インターネットワークメッセージ配送の始まりで、私たちはどう局所的にメッセージを扱うかを再評価します。 最終的に、 USERNAME@HOST 命名計画は不十分であると判明しました、それらの位置からの受取人のアイデンティティの離婚が交換として有望な可能性に見えますが。
The ARPAnet will soon have a distributed database for supporting TIP Login. Only small, incremental costs would be associated with building and maintaining a netmail database at the same time. It can be argued that TIP Login requires at least the level of reliability required by a message delivery system. If the TIP Login database is successful, a netmail database can work, too.
ARPAnetには、すぐ、TIP Loginを支持するための分散データベースがあるでしょう。 小さくて、増加のコストだけが同時にnetmailデータベースを築き上げて、維持すると関連しているでしょう。 TIP Loginが少なくともメッセージ配送システムによって必要とされた信頼性のレベルを必要とすると主張できます。 TIP Loginデータベースがうまくいくなら、また、netmailデータベースは働くことができます。
It is clear that we will be implementing a new set of message format and delivery protocols in the near future, in order to allow for multi-media messages, internetwork message traffic, and the like. New message composition and delivery systems will be built to meet those specifications and take advantage of the avenues of development which they will open. If there will ever be an advantageous time to re-evaluate and re-design how messages are addressed and delivered, it is now, when we are about to enter upon an entirely new cycle of message composition and
私たちが近い将来新しいセットのメッセージ・フォーマットと配送プロトコルを実行するのは、明確です、マルチメディアメッセージ、インターネットワークメッセージ交通、および同様のものを考慮するために。 新しいメッセージ構成と配送システムは、それらの仕様を満たして、それらが開く開発の大通りを利用するために構築されるでしょう。 そしてどうメッセージを記述して、送るかを再評価して、再設計する有利な時間があれば、現在です、私たちがメッセージ構成の完全に新しいサイクルを始めようとしているとき。
RFC 757 September 1979 Conclusions Page 16
RFC757 1979年9月結論が16を呼び出します。
delivery program implementation.
配送プログラム実施。
RFC 757 September 1979 References Page 17
RFC757 1979年9月参照箇所が17を呼び出します。
REFERENCES
参照
[1] John F. Shoch.
Inter-Network Naming, Addressing, and Routing.
In Proceedings, COMPCON. IEEE Computer Society, Fall, 1979.
[1] ジョンF.Shoch。 インターネットワーク命名、アドレシング、およびルート設定。 議事、COMPCONで。 IEEEコンピュータ社会、1979年秋。
[2] Stephen Warshall.
On Names and Permissions.
Mass. Computer Associates. 1979.
[2] スティーブンWarshall。 名前と許容に関して。 マサチューセッツ州 コンピュータ・アソシエイツ。 1979.
[3] David H. Crocker, John J. Vittal, Kenneth T. Pogran,
D. Austin Henderson, Jr.
STANDARD FOR THE FORMAT OF ARPA NETWORK TEXT MESSAGES.
RFC 733, The Rand Corporation, Bolt Beranek and Newman Inc,
Massachussets Institute of Technology, Bolt Beranek and
Newman Inc., November, 1977.
[3] デヴィッド・H.クロッカー、ジョンJ.Vittal、ケネスT.Pogran、D.オースチンヘンダーソン、アルパの形式のJr.STANDARDはテキスト・メッセージをネットワークでつなぎます。 RFC733、ランド研究所、ボルトBeranek、およびニューマンInc(Massachussets工科大学)はBeranekとニューマン株式会社(1977年11月)をボルトで締めます。
[4] Jonathan B. Postel.
INTERNET MESSAGE PROTOCOL.
RFC 753, Information Sciences Institute, March, 1979.
[4] ジョナサン・B.ポステル。 インターネットメッセージプロトコル。 RFC753、科学が1979年3月に設ける情報。
[5] Robert H. Thomas, Paul J. Santos, and John F. Haverty.
TIP Login Notes.
Bolt Beranek and Newman. 1979.
[5] ロバート・H.トーマス、ポール・J.サントス、およびジョンF.Haverty。 ログイン注意をくつがえしてください。 Beranekとニューマンをボルトで締めてください。 1979.
RFC 757 September 1979 Table of Contents Page i
RFC757 1979年9月目次ページi
Table of Contents
目次
1. Introduction 2
1. 序論2
2. Names and Addresses 3
2. 名前とアドレス3
2.1 A distributed database approach 4
2.2 Delivery 5
2.2.1 Additional delivery options 7
2.2.2 Failures 8
2.1 分散データベースアプローチ4 2.2Delivery5 2.2.1Additional配送オプション7 2.2.2Failures8
3. Relationship to TIP Login database 9
3. TIP Loginデータベース9との関係
4. Relationship to RFC 753 10
4. RFC753 10との関係
4.1 Compatibility 10
4.1.1 Outgoing message 10
4.1.1.1 RFC 753 10
4.1.1.2 This proposal 11
4.1.2 Messages in transit 12
4.1.3 Incoming mail 12
4.1 トランジット12 4.1.3Incomingメール12による互換性10 4.1.1Outgoingメッセージ10 4.1.1.1RFC753 10 4.1.1.2This提案11 4.1.2Messages
5. Implications of an internetwork message environment 13
5. インターネットワークメッセージ環境13の含意
5.1 Birthplaces 13
5.1.1 ID resolution 13
5.1.2 Hosts in an internet environment 13
5.1.3 Orphans 14
5.1 インターネット環境13 5.1.3Orphans14の出生地13 5.1.1ID解決13 5.1.2Hosts
6. Conclusions 15
6. 結論15
RFC 757 September 1979 List of Figures Page ii
図ページiiのRFC757 1979年9月のList
List of Figures
数字のリスト
Figure 4-1: The Internet Environment 10
図4-1: インターネット環境10
RFC 757 September 1979
RFC757 1979年9月
一覧
スポンサーリンク
