RFC1312 日本語訳
1312 Message Send Protocol 2. R. Nelson, G. Arnold. April 1992. (Format: TXT=18037 bytes) (Obsoletes RFC1159) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Nelson Request for Comments: 1312 Crynwr Software Obsoletes: RFC 1159 G. Arnold Sun Microsystems, Inc. April 1992
コメントを求めるワーキンググループR.ネルソン要求をネットワークでつないでください: 1312 Crynwrソフトウェアは以下を時代遅れにします。 RFC1159G.アーノルドサン・マイクロシステムズ・インク1992年4月
Message Send Protocol 2
メッセージはプロトコル2を送ります。
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Discussion
議論
The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. Unix's write command offers a limited form of this service through its host-local write command. This service is also known on some hosts as "SEND".
Message Sendプロトコルは、与えられたホストの上の与えられた端末で短いメッセージを与えられたユーザに送るのに使用されます。 unixのものはホストローカルの書きコマンドでこのサービスの限局型をコマンド申し出に書きます。 また、このサービスは「発信してください」として何人かのホストの上で知られています。
As the Internet grows, more and more people are using hosts that do not run Internet protocols at all times. These hosts may be able to use a simple protocol that can be implemented using UDP and IP. The Message Send Protocol is one such protocol.
インターネットが発展するとき、ますます多くの人々がいつもインターネットプロトコルを実行するというわけではないホストを使用しています。 これらのホストはUDPを使用して、IPであると実装することができる簡単なプロトコルを使用できるかもしれません。 Message Sendプロトコルはそのようなプロトコルの1つです。
Note that a message sending protocol is already defined using TCP. The SMTP protocol includes a "SEND" command that will direct mail to a user's terminal. SMTP's SEND is not useful in this instance because SMTP's SEND is not implemented by the majority of vendors at this time, and is difficult to use by unskilled users. For the purposes of standardization, we will include a TCP based Message Send Service.
メッセージ送信プロトコルがTCPを使用することで既に定義されることに注意してください。 SMTPプロトコルはユーザの端末へのダイレクトメールがそうする「発信」コマンドを含んでいます。 SMTPのSENDはこの場合SMTPのSENDがこのときベンダーの大部分によって実装されないので役に立たないで、下手なユーザで使用するのは難しいです。 標準化の目的のために、私たちはTCPのベースのMessage Send Serviceを入れるつもりです。
Message Syntax
メッセージ構文
The message consists of several parts, all of which must be present The first part is a single octet indicating the protocol revision, currently decimal 66, 'B'. The remaining parts are null-terminated sequences of eight-bit characters in the ISO 8859/1 alphabet. Some parts may be empty. All comparisons of parts (e.g., recipient,
メッセージは数個の部品から成ります。そのすべては1番目が分けるプレゼントがプロトコル改正、現在10進の66、'B'を示すただ一つの八重奏であるということであるに違いありません。 残存部分はISO8859/1アルファベットの8ビットのキャラクタのヌルで終えられた系列です。 いくつかの部分が空であるかもしれません。 部品のすべての比較、(例えば、受取人
Nelson & Arnold [Page 1] RFC 1312 Message Send Protocol 2 April 1992
ネルソンとアーノルド[1ページ]RFC1312メッセージはプロトコル1992年4月2日を送ります。
cookie, etc.) are case-insensitive. The parts are as follows:
クッキーなど)、大文字と小文字を区別しないです。 部品は以下の通りです:
RECIPIENT The name of the user that the message is directed to. If this part is empty, the message may be delivered to any user of the destination system.
RECIPIENT、メッセージが向けられるユーザの名前。 この部分が空であるなら、メッセージは目的地システムのどんなユーザにも提供されるかもしれません。
RECIP-TERM The name of the terminal to which the message is to be delivered. The syntax and semantics of terminal names are outside the scope of this specification. If this part is empty, the "right" terminal is chosen. This is a system-dependent function. If this part consists of the string "*", all terminals on the destination system are implied. If the RECIPIENT part is empty but the RECIP-TERM is not, the message is written on the specified terminal. If both the RECIPIENT and RECIP-TERM parts are empty, the message should be written on the "console", which is defined as some place where the message is most likely to be seen by a human operator or administrator.
RECIP-TERM、提供されるメッセージがことである端末の名前。 この仕様の範囲の外にターミナル名の構文と意味論があります。 この部分が空であるなら、「正しい」端末は選ばれています。 これはシステム依存する機能です。 この部分がストリング「*」から成るなら、目的地システムの上のすべての端末が含意されます。 RECIPIENT部分が空ですが、RECIP-TERMが空であるというわけではないなら、メッセージは指定された端末で書かれます。 RECIPIENTとRECIP-TERMの部品の両方が空であるなら、メッセージは「コンソール」に書かれるべきです。(それは、メッセージが人間のオペレータか管理者によって最も見られそうであるいくつかの場所と定義されます)。
MESSAGE The actual message. The server need not preserve the formatting and white-space content of the message if this is necessary to display it. New lines should be represented using the usual Netascii CR + LF. (Following the Internet tradition, a server should probably be prepared to accept a message in which some other end-of-line convention is followed, but a conforming client must use CR + LF.)
実際のMESSAGEは通信します。 これがそれを表示するのに必要であるなら、サーバはメッセージの形式と余白内容を保存する必要はありません。 復帰改行は、普通のNetascii CR+LFを使用することで表されるべきです。 (インターネット伝統に従って、サーバはたぶんある他の行末規約が続かれているメッセージを受け入れるように準備されるべきですが、従っているクライアントはCR+LFを使用しなければなりません。)
The message text may only contain printable characters from the ISO 8859/1 set, which is upward compatible from USASCII, plus CR, LF and TAB. No other control codes or escape sequences may be included: the client should strip them from the message before it is transmitted, and the server must check each incoming message for illegal codes. (A server may choose to display the message after stripping out such codes, or may reject the entire message.) If the MESSAGE part is empty, the message may be discarded by the server.
メッセージ・テキストはUSASCIIから互換性があった状態で上向きのISO8859/1セット、CR、LF、およびTABからの印刷可能なキャラクタを含むだけであるかもしれません。 どんな他の制御コードもエスケープシーケンスも含まれないかもしれません: それが伝えられる前にクライアントはメッセージからそれらを剥取るべきです、そして、サーバは不正コードがないかどうか各入力メッセージをチェックしなければなりません。 (サーバは、そのようなコードを取り除いた後にメッセージを表示するのを選ぶか、または全体のメッセージを拒絶するかもしれません。) MESSAGE部分が空であるなら、メッセージはサーバによって捨てられるかもしれません。
SENDER The username of the sender. (This and subsequent parts were not present in version 1 of the Message Send Protocol.) This part should not be empty. A server may choose to accept, reject or ignore messages in which the SENDER part is empty.
SENDER、送付者のユーザ名。 (これとその後の部品はMessage Sendプロトコルのバージョン1に存在していませんでした。) この部分は空であるべきではありません。 サーバは、SENDER部分が空であるメッセージを受け入れるか、拒絶するか、または無視するのを選ぶかもしれません。
SENDER-TERM The name of the sending user's terminal. This part may be empty. The intention is that a recipient may reply
SENDER-TERM、送付ユーザの端末の名前。 この部分は空であるかもしれません。 意志は受取人が返答するかもしれないということです。
Nelson & Arnold [Page 2] RFC 1312 Message Send Protocol 2 April 1992
ネルソンとアーノルド[2ページ]RFC1312メッセージはプロトコル1992年4月2日を送ります。
to a message by sending the reply to the user SENDER at terminal SENDER-TERM on the originating system. (The sender's hostname should be retrieved from the transport software.)
起因するシステムの上で端末のSENDER-TERMのユーザSENDERに回答を送るのによるメッセージに。 (送付者のホスト名は輸送ソフトウェアから検索されるべきです。)
COOKIE A magic cookie. This part must be present in all messages, but is only of significance for the UDP service. The combination of the sender's UDP port number and this cookie should be unique. A client may elect to transmit a particular message several times to increase the chances of its reception; a server may use the cookie and port to identify duplicate messages and discard them. A reasonable cookie is the time of day represented in a readable format. The maximum length of a cookie is 32 octets, excluding the terminating null.
COOKIEのA魔法のクッキー。 この部分は、すべてのメッセージに存在していなければなりませんが、UDPサービスのための意味だけのものです。 送付者のUDPポートナンバーの組み合わせとこのクッキーはユニークであるべきです。 クライアントは、レセプションの可能性を増強するために何度か特定のメッセージを送るのを選ぶかもしれません。 サーバは、写しメッセージを特定して、それらを捨てるのにクッキーとポートを使用するかもしれません。 妥当なクッキーは読み込み可能な形式で表された時刻です。 終わりヌルを除いて、クッキーの最大の長さは32の八重奏です。
SIGNATURE A token which, if present, may be used by the server to verify the identity of the sender. The use of the SIGNATURE part is discussed further in the section on Security, below.
存在しているならサーバによって使用される、送付者のアイデンティティについて確かめるかもしれないSIGNATURE Aトークン。 以下のSecurityの上のセクションで、より詳しくSIGNATURE部分の使用について議論します。
The total length of the message shall be less than 512 octets. This includes all eight parts, and any terminating nulls. UDP packets are limited to 512 octets.
メッセージの全長は512未満の八重奏になるでしょう。 これはすべての8つの部品、およびどんな終わりヌルも含んでいます。 UDPパケットは512の八重奏に制限されます。
If this protocol is changed, the revision number will be changed.
このプロトコルを変えると、改訂番号を変えるでしょう。
TCP Based Message Send Service
TCPのベースのメッセージはサービスを送ります。
One Message Send Service is defined as a connection based application on TCP. A server listens for TCP connections on TCP port 18. Once a connection is established a message is sent by the client over the connection.
1Message Send ServiceがTCPで接続に基づいているアプリケーションと定義されます。 サーバはTCPポート18の上でTCP接続の聞こうとします。 接続がいったん確立されると、メッセージはクライアントによって接続の上に送られます。
The server replies with a single character indicating positive ("+") or negative ("-") acknowledgment, immediately followed by an optional message of explanation, terminated with a null. The positive acknowledgement means that the message was successfully delivered to some user/terminal, and that the negative acknowledgement means that the message was NOT delivered to any terminal.
単独のキャラクタが積極的な(「+」)か否定的(「-」)承認を示している説明の任意のメッセージがすぐにあとに続くサーバ回答はヌルで終わりました。 積極的な承認は、メッセージが首尾よくあるユーザ/端末に提供されて、否定的承認が、メッセージがどんな端末にも提供されなかったことを意味することを意味します。
The positive acknowledgement message can contain information about what user and terminal the message was delivered to in the case of incomplete user/terminal fields in the message. The negative acknowledgement can contain information about WHY the message was not delivered (no such user/terminal, system failure, user doesn't accept
積極的な確認メッセージはメッセージがメッセージにおける、不完全なユーザ/端末の分野の場合でどんなユーザと端末に提供されたかの情報を含むことができます。 否定的承認がメッセージが提供されなかったWHYの情報を含むことができる、(そのようなユーザ/端末でない、システム障害、ユーザは受け入れません。
Nelson & Arnold [Page 3] RFC 1312 Message Send Protocol 2 April 1992
ネルソンとアーノルド[3ページ]RFC1312メッセージはプロトコル1992年4月2日を送ります。
messages, etc).
メッセージなど)
Multiple messages can be sent over the same channel. The client should close first (the server may/should not close directly after the acknowledgement is sent) and the server may close after some timeout on the order of minutes. If the sever is unable to decode a message, or no message is received within a suitable timeout, it may close the channel (on the assumption that the sender may have formatted the data incorrectly).
同じチャンネルの上に複数のメッセージを送ることができます。 クライアントが最初に閉じるべきである、(サーバ、/が承認直後閉じるべきでないかもしれない、送る、)、サーバは数分の注文でのいくらかのタイムアウトの後に閉じるかもしれません。 切れる、それは、適当なタイムアウトの中に暗号文を普通文に直すことができませんし、いいえ、メッセージを受け取って、チャンネル(送付者が不当にデータをフォーマットしたかもしれないという前提での)を閉じるかもしれません。
UDP Based Message Send Service
UDPのベースのメッセージはサービスを送ります。
Another Message Send Service is defined as a datagram based application on UDP. A server listens for UDP datagrams on UDP port 18. When a datagram is received by the server, an answering datagram may be sent back to the client. If the message was addressed to a particular user (i.e., the RECIPIENT part was non-empty) and was successfully delivered to that user, a positive acknowledgement should be sent (as described above). If the message was directed at any user (i.e., the RECIPIENT part is empty), or if the message could not be delivered for some reason, no reply is sent.
別のMessage Send ServiceはUDPでデータグラムに基づいているアプリケーションと定義されます。 サーバはUDPポート18の上のUDPデータグラムの聞こうとします。 サーバでデータグラムを受け取るとき、回答データグラムをクライアントに送り返すかもしれません。 メッセージを特定のユーザ(すなわち、RECIPIENT部分は非空であった)に扱って、首尾よくそのユーザに提供するなら、積極的な承認を送るでしょうに(上で説明されるように)。 どんなユーザにもメッセージを向けることができなかったか(すなわち、RECIPIENT部分は空です)、ある理由でメッセージを提供できないなら、回答を全く送りません。
The reason for this policy is that the UDP service may be used to broadcast messages addressed to a particular user on an unknown system or all users on all systems. In either case, it is inappropriate for all servers to send replies. An alternative approach might have been to require that a server only send a reply if a message was addressed explicitly to that system and was not broadcast. Unfortunately, the most popular network programming API does not provide an easy way for an application to determine this; furthermore such a policy would provide no feedback to the sender of a broadcast message to a particular recipient. The approach adopted here provides a reasonable compromise.
この方針の理由はUDPサービスがすべてのシステムで未知のシステムかすべてのユーザの上で特定のユーザに扱われたメッセージを放送するのに利用されるかもしれないということです。どちらかの場合では、すべてのサーバが回答を送るのは、不適当です。 代替的アプローチはメッセージが明らかにそのシステムに扱われて、放送されなかったならサーバだけが返信するのが必要であることであったかもしれません。 残念ながら、最もポピュラーなネットワーク・プログラミングAPIはこれを決定するためにアプリケーションに簡単な道で備えません。 その上、そのような方針は特定の受取人への同報メッセージの送付者にフィードバックを全く提供しないでしょう。 ここで取られたアプローチは妥当な感染を提供します。
Example of Message Encoding
メッセージコード化に関する例
Consider a situation in which the user "sandy" is logged into the console of system "alpha", and wishes to send a message to the user "chris". "chris" is known to be logged in on the system "beta" but the exact terminal is unknown. The message consists of two lines of text, "Hi" followed by "How about lunch?".
ユーザ「砂地」がシステム「アルファ」のコンソールに登録される状況、およびユーザ"chris"にメッセージを送るという願望を考えてください。 システム「ベータ」で"chris"がログインされるのが知られていますが、正確な端末は未知です。 「こんにちは」は、「どうであるか昼食」でメッセージがテキストの2つの系列から成るのに続きました。
The message would be encoded as follows:
メッセージは以下の通りコード化されるでしょう:
Nelson & Arnold [Page 4] RFC 1312 Message Send Protocol 2 April 1992
ネルソンとアーノルド[4ページ]RFC1312メッセージはプロトコル1992年4月2日を送ります。
+--------+---------+---------+---------+ 0 | B | c | h | r | +--------+---------+---------+---------+ 4 | i | s | <NULL> | <NULL> | +--------+---------+---------+---------+ 8 | H | i | <CR> | <LF> | +--------+---------+---------+---------+ 12 | H | o | w | | +--------+---------+---------+---------+ 16 | a | b | o | u | +--------+---------+---------+---------+ 20 | t | | l | u | +--------+---------+---------+---------+ 24 | n | c | h | ? | +--------+---------+---------+---------+ 28 | <NULL>| s | a | n | +--------+---------+---------+---------+ 32 | d | y | <NULL> | c | +--------+---------+---------+---------+ 36 | o | n | s | o | +--------+---------+---------+---------+ 40 | l | e | <NULL> | 9 | +--------+---------+---------+---------+ 44 | 1 | 0 | 8 | 0 | +--------+---------+---------+---------+ 48 | 6 | 1 | 2 | 1 | +--------+---------+---------+---------+ 52 | 3 | 2 | 5 | <NULL> | +--------+---------+---------+---------+ 56 | <NULL> | +--------+
+--------+---------+---------+---------+ 0 | B| c| h| r| +--------+---------+---------+---------+ 4 | i| s| <のヌル>。| <のヌル>。| +--------+---------+---------+---------+ 8 | H| i| <CR>。| <LF>。| +--------+---------+---------+---------+ 12 | H| o | w| | +--------+---------+---------+---------+ 16 | a| b| o | u| +--------+---------+---------+---------+ 20 | t| | l| u| +--------+---------+---------+---------+ 24 | n| c| h| ? | +--------+---------+---------+---------+ 28 | <ヌル>| s| a| n| +--------+---------+---------+---------+ 32 | d| y| <のヌル>。| c| +--------+---------+---------+---------+ 36 | o | n| s| o | +--------+---------+---------+---------+ 40 | l| e| <のヌル>。| 9 | +--------+---------+---------+---------+ 44 | 1 | 0 | 8 | 0 | +--------+---------+---------+---------+ 48 | 6 | 1 | 2 | 1 | +--------+---------+---------+---------+ 52 | 3 | 2 | 5 | <のヌル>。| +--------+---------+---------+---------+ 56 | <のヌル>。| +--------+
Note that the RECIP-TERM and SIGNATURE parts are empty. The COOKIE is the string "910806121325", which in this implementation indicates that the message was sent at 12:13:25 on the 6th of August, 1991. The identity if the sending and receiving systems is not included in the message; the server must obtain this information from the transport service.
RECIP-TERMとSIGNATURE部分が空であることに注意してください。 COOKIEはストリング「910806121325」です。(そのストリングは、この実装でメッセージが1991年8月6日12:13:25に送られたのを示します)。 アイデンティティは発信と受電方式であるならメッセージに含まれていません。 サーバは輸送サービスからこの情報を得なければなりません。
Advisories
状況報告
Client and server implementations must follow the character set restrictions noted in the MESSAGE part description. Failure to do so may have undesirable effects on the operation of the receiver's terminal; more seriously, it may open up a significant security
クライアントとサーバ実装はMESSAGE部分記述で注意した文字集合制限の後をつけなければなりません。 そうしない場合、受信機の端末の操作に望ましくない影響を与えるかもしれません。 より真剣に、それは重要なセキュリティを開けるかもしれません。
Nelson & Arnold [Page 5] RFC 1312 Message Send Protocol 2 April 1992
ネルソンとアーノルド[5ページ]RFC1312メッセージはプロトコル1992年4月2日を送ります。
"hole". The checks must be made on any part of the message which may be displayed, including the sender's name and terminal. This is one case where the admonition to "be liberal in what you accept" is not applicable. A server may chose to apply additional checks to an incoming message, and to reject any message which may pose a security risk. For example, a system using a PostScript-based display may reject a message which might be interpreted as an executable PostScript program.
「掘ってください。」 表示されるかもしれないメッセージのどんな部分の上でもチェックをしなければなりません、送付者の名前と端末を含んでいて。 これは「あなたが受け入れるものでは寛容である」訓戒が適切でない1つのそうです。 サーバは選ぶかもしれません。追加チェックを入力メッセージに適用して、セキュリティリスクを引き起こすかもしれないどんなメッセージも拒絶するのを選びました。 例えば、ポストスクリプトベースのディスプレイを使用するシステムは実行可能なポストスクリプトプログラムとして解釈されるかもしれないメッセージを拒絶するかもしれません。
The underlying transport, whether TCP or UDP, is expected to provide checksums for the message and any response.
TCPかUDPであることにかかわらず基本的な輸送がメッセージとどんな応答にもチェックサムを提供すると予想されます。
The semantics of the various RECIPIENT and RECIP-TERM combinations may be confusing. The introduction of the "*" wildcard designation in the RECIP-TERM part makes it possible to send a message to all terminals on the designated system (if RECIPIENT is empty), or to all terminals at which a particular recipient has logged in.
様々なRECIPIENTとRECIP-TERM組み合わせの意味論は混乱させられているかもしれません。 RECIP-用語一部での「*」ワイルドカード名称の導入で、指定されたシステム(受取人が空であるなら)の上のすべての端末、または、特定の受取人がログインしたすべての端末にメッセージを送るのは可能になります。
A positive acknowledgement may indicate only that the Message Send server was able to successfully invoke a local message delivery service. It may not be possible for true end-to-end semantics to be inferred.
積極的な承認は、Message Sendサーバが首尾よく地方のメッセージデリバリ・サービスを呼び出すことができただけであるのを示すかもしれません。 終わりから終わりへの本当の意味論が推論されるのは、可能でないかもしれません。
For example, a Message Send server may employ a local delivery mechanism which calls upon the services of a window system to display the message in a pop-up window. This process may take some significant time to complete, and it is unclear whether it is useful for the server to wait for an indeterminate period before returning an acknowledgement. Therefore, this specification does not prescribe whether the acknowledgement is associated with delivery of the message to the local service, the display of the message, or confirmation by the user that the message has been read by, e.g., dismissing the pop-up window.
例えば、Message Sendサーバはポップアップウィンドウでウィンドウシステムのサービスがメッセージを表示するのを要求するローカルの排紙機構を使うかもしれません。 このプロセスは完成するいくらかの重要な時かかるかもしれません、そして、承認を返す前にサーバが不確定の期間、待つのが、役に立つかどうかが、不明瞭です。 したがって、この仕様は承認がローカル・サービスへのメッセージの配送に関連しているか、そして、メッセージのディスプレイ、またはユーザによるメッセージを読んである確認、例えば、棄却にポップアップウィンドウを定めません。
Security Considerations
セキュリティ問題
Those who plan to implement this service must ensure that the following issues are reflected in the documentation of their products, and that their implementations include sufficient configuration controls to allow systems and network administrators to achieve the appropriate levels of usability and security.
このサービスを実装するのを計画している人は、以下の問題がそれらの製品のドキュメンテーションに反映されて、それらの実装がシステムとネットワーク管理者がユーザビリティとセキュリティの適正水準を実現するのを許容できるくらいの構成管理を含んでいるのを確実にしなければなりません。
First, this service may allow someone to write on a user's terminal without the user giving his or her permission. Where possible, users should be provided with a mechanism for disabling this.
まず最初に、このサービスで、ユーザがその人の許可を与えないで、だれかがユーザの端末を書き続けることができるかもしれません。 可能であるところでは、これを無効にするためにメカニズムをユーザに提供するべきです。
Second, it is extremely important for implementors to observe the rules for filtering message text as discussed under Message Syntax
2番目に、作成者がMessage Syntaxの下で議論するようにメッセージ・テキストをフィルターにかけるために規律を守るのは、非常に重要です。
Nelson & Arnold [Page 6] RFC 1312 Message Send Protocol 2 April 1992
ネルソンとアーノルド[6ページ]RFC1312メッセージはプロトコル1992年4月2日を送ります。
above. Failure to do this may introduce major security holes.
上。 これをしない場合、主要なセキュリティーホールを紹介するかもしれません。
The third issue concerns the verification of the sender's identity. If the recipient is fooled into believing that a message is from a particular user, various security issues may arise. For example, the recipient may send a reply containing confidential material.
3番目の問題は送付者のアイデンティティの検証に関係があります。 受取人がメッセージが特定のユーザから来ていると信じているようにだまされるなら、様々な安全保障問題は起こるかもしれません。 例えば、受取人は機密資料を含む回答を送るかもしれません。
This service is primarily intended for "open" environments: controlled local area networks used by reasonably trusted participants, in which security considerations may be relaxed in the interests of ease of use and administration. In such an environment it is appropriate to trust the user name and source IP address as identifying the actual sender of the message.
このサービスは「開いている」環境のために主として意図します: セキュリティ問題が使いやすさと管理のためにリラックスするかもしれない合理的に信じられた関係者によって使用された制御ローカル・エリア・ネットワーク。 そのような環境で、メッセージの実際の送付者を特定するとしてユーザ名とソースIPアドレスを信じるのは適切です。
Within more security-conscious environments, this assumption is probably unacceptable. As has been widely noted, there is no way within the current Internet architecture to ensure that the source address of an IP datagram is correct. Hence it is entirely possible for someone to spoof the IP address.
より安全志向の環境の中では、この仮定はたぶん容認できません。 広く注意されていたように、IPデータグラムのソースアドレスが確実に正しくなるようにするために、現在のインターネットアーキテクチャの中に道は全くありません。 したがって、だれかがIPアドレスを偽造するのは、完全に可能です。
The obvious, and simplest, answer is to disallow the use of this protocol in such situations. However a more constructive approach is to incorporate within the protocol some mechanism by which a server can reliably identify the sender.
明白で、最も簡単な答えはそのような状況におけるこのプロトコルの使用を禁じることです。 しかしながら、より建設的なアプローチはプロトコルの中にサーバが送付者を確かに特定できる何らかのメカニズムを組み込むことです。
In this version of the protocol specification, we define a SIGNATURE part within a message. If this part is empty, the identity of the sender cannot be verified, and the server implementation may elect to reject all such requests. If the part is not empty, it is treated as a case-insensitive text encoding of some security token. This RFC does not define the encoding or interpretation of this token. We expect that such matters will form part of future RFCs on security and privacy issues; at an appropriate time, this RFC will be re- issued to include references to these RFCs.
プロトコル仕様のこのバージョンでは、私たちはメッセージの中でSIGNATURE部分を定義します。 この部分が空であるなら、送付者のアイデンティティについて確かめることができません、そして、サーバ実装はそのようなすべての要求を拒絶するのを選ぶかもしれません。 部分が空でないなら、それは何らかのセキュリティトークンの大文字と小文字を区別しないテキストコード化として扱われます。 このRFCはこのトークンのコード化か解釈を定義しません。 私たちは、そのような件がセキュリティとプライバシーの問題で将来のRFCsの一部を形成すると予想します。 適当な機会に、このRFCは、これらのRFCsの指示するものを含むように再発行されるでしょう。
Acknowledgements
承認
PostScript is a trademark of Adobe Systems, Inc.
ポストスクリプトはアドビ・システムズInc.の商標です。
Nelson & Arnold [Page 7] RFC 1312 Message Send Protocol 2 April 1992
ネルソンとアーノルド[7ページ]RFC1312メッセージはプロトコル1992年4月2日を送ります。
Authors' Addresses
作者のアドレス
Russell Nelson Crynwr Software 11 Grant St. Potsdam, NY 13676
聖ポツダム、ラッセルネルソンCrynwr Software11Grantニューヨーク 13676
Phone: (315) 268-1925 EMail: nelson@crynwr.com
以下に電話をしてください。 (315) 268-1925 メールしてください: nelson@crynwr.com
Geoff Arnold Sun Microsystems, Inc. 2 Federal Street Billerica, MA 01821
ビルリカ、ジェフアーノルドサン・マイクロシステムズ・インク2の連邦政府の通りMA 01821
Phone: (508) 671-0317 EMail: geoff@east.sun.com
以下に電話をしてください。 (508) 671-0317 メールしてください: geoff@east.sun.com
Nelson & Arnold [Page 8]
ネルソンとアーノルド[8ページ]
一覧
スポンサーリンク