RFC1845 日本語訳

Network Working Group                                         D. Crocker
Request For Comments: 1845                        Brandenburg Consulting
Category: Experimental                                          N. Freed
                                            Innosoft International, Inc.
                                                   A. Cargille, WG Chair
                                                          September 1995

コメントを求めるワーキンググループD.医者要求をネットワークでつないでください: 1845年のブランデンブルクコンサルティングカテゴリ: 実験的なN.の解放されたInnosoft国際Inc.A.Cargille、WG議長1995年9月

                         SMTP Service Extension
                         for Checkpoint/Restart

チェックポイント/再開のためのSMTPサービス拡張子

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   This memo defines an extension to the SMTP service whereby an
   interrupted SMTP transaction can be restarted at a later time without
   having to repeat all of the commands and message content sent prior
   to the interruption.

このメモは後で中断の前に送られたコマンドとメッセージ内容のすべてを繰り返す必要はなくて中断しているSMTPトランザクションを再開できるSMTPサービスと拡大を定義します。

1.  Introduction

1. 序論

   Although SMTP is widely and robustly deployed, various extensions
   have been requested by parts of the Internet community. In
   particular, when dealing with very large messages over less reliable
   connections it is possible for substantial resources to be consumed
   by repeated unsuccessful attempts to transmit the message in its
   entirety. The original SMTP specification [1] does not provide any
   means to pick up a partially completed transaction after the
   underlying TCP connection has been broken and reestablished.

SMTPは広さと強壮に配布されますが、様々な拡大はインターネットコミュニティの部品によって要求されます。 それほど頼もしくない接続の上で非常に大きいメッセージに対処するとき、多額の資金がメッセージを全体として送る繰り返された失敗の試みで消費されるのは、特に、可能です。 当初のSMTP仕様[1]は基本的なTCP接続が調教されて、回復した後に部分的に完成したトランザクションを拾うどんな手段も提供しません。

   This memo provides a facility by which a client can uniquely identify
   a particular SMTP transaction. The server then stores this
   identifying information along with all the information it receives as
   the transaction proceeds. If the transaction is interrupted during
   the data transfer phase the SMTP client may establish a new SMTP
   session at a later time and ask the server to continue the
   transaction from the point where the server lost its connection with
   the client. The server then reestablishes the transaction context and
   tells the client where to resume operations. If this is acceptable
   the client resumes operations at this point.

このメモはクライアントが唯一特定のSMTPトランザクションを特定できる施設を提供します。 そして、トランザクションが続くとき、サーバはそれが受け取るすべての情報に伴うこの身元が分かる情報を保存します。 トランザクションがデータ転送段階の間、中断されるなら、SMTPクライアントは、サーバがクライアントとの接続を失ったポイントからトランザクションを続けるようにサーバに確証して、新しいSMTPセッションで後で頼むかもしれません。 サーバは、次に、トランザクション文脈を回復させて、どこで運転を再開するかをクライアントに言います。 これが許容できるなら、クライアントはここに運転を再開します。

Crocker, Freed & Cargille     Experimental                      [Page 1]

RFC 1845                SMTP Checkpoint/Restart           September 1995

クロッカー、解放されるのとCargille[1ページ]実験的なRFC1845SMTPチェックポイント/再開1995年9月

   This extension may also be used to work around the common timeout
   problem where a client times out waiting for a response from the
   server acknowledging that the message has been accepted. However, use
   of this extension is not an acceptable substitute for proper setting
   of timeout parameters.

また、この拡張子は、メッセージが受け入れられたと認めながら外でサーバから応答を待ちながら一般的なタイムアウト問題の周りでクライアント回どこを扱うかに使用されるかもしれません。 しかしながら、この拡張子の使用はタイムアウトパラメタの適切な設定の許容できる代用品ではありません。

2.  Framework for the Checkpointing Extension

2. Checkpointing拡張子のためのフレームワーク

   The checkpointing extension is laid out as follows:

checkpointing拡大は以下の通り広げられます:

 (1)   the name of the SMTP service extension defined here is
       checkpointing;

(1) ここで定義されたSMTPサービス拡張子の名前はcheckpointingされています。

 (2)   the EHLO keyword value associated with the extension is
       CHECKPOINT;

(2) 拡大に関連しているEHLOキーワード価値はCHECKPOINTです。

 (3)   no parameter is used with the CHECKPOINT EHLO keyword;

(3) パラメタは全くCHECKPOINT EHLOキーワードと共に使用されません。

 (4)   one optional parameter using the keyword TRANSID is
       added to the MAIL FROM command.  The value associated
       with this parameter, coupled with the name of the
       client taken from EHLO command, forms a globally unique
       value that identifies this particular transaction and
       serves to distinguish it from all others. This value is
       case-sensitive. The syntax of the value is as follows,
       using the ABNF notation of [2]:

(4) キーワードTRANSIDを使用する1つの任意のパラメタがMAIL FROMコマンドに追加されます。 EHLOコマンドから連れて行かれたクライアントの名前に結びつけられたこのパラメタに関連している値は、この特定の取引を特定するグローバルにユニークな値を形成して、すべての他のものとそれを区別するのに役立ちます。 この値は大文字と小文字を区別しています。 [2]のABNF記法を使用して、価値の構文は以下の通りです:

            transid-value  ::= "<" transid-spec ">"
                               ; transid-value may not be longer than
                               ; 80 characters
            transid-spec   ::= transid-local "@" transid-domain
            transid-domain ::= transid-token
            transid-local  ::= transid-token
            transid-token  ::= transid-atom *("." transid-atom)
            transid-atom   ::= 1*<any (ASCII) CHAR except SPACE,
                                  CTLs, tspecials, or ".">

以下をtransid評価してください:= "<"transid-仕様">"。 transid-値が、より長くないかもしれない、。 80キャラクタtransid-仕様:、:= transid地方の"@"transid-ドメインtransid-ドメイン:、:= transid-トークンtransid-ローカル:、:= transid-トークンtransid-トークン:、:= transid-原子*、(「. 」 transid-原子) transid-原子:、:= 「」 . SPACE以外のどんな(ASCII)CHAR(CTLs)もtspecialsする1*<、または">"

       NOTE: tspecials is defined in [3]. The TRANSID is
       likely to be different from the RFC822 message id,
       since it must uniquely identify the particular copy of
       the message being sent over this SMTP link. However,
       the syntax of transid-value is designed so that any
       TRANSID is both a legal RFC822 msg-id as well as being
       a legal esmtp-value [4].

以下に注意してください。 tspecialsは[3]で定義されます。 TRANSIDはRFC822メッセージイドと異なる傾向があります、唯一このSMTPリンクの上に送られるメッセージの特定のコピーを特定しなければならないので。 しかしながら、transid-価値の構文は、どんなTRANSIDも法的なRFC822 msg-イドと法的なesmtp-値の[4]である両方であるように設計されています。

 (5)   The maximum length of a MAIL FROM command line is
       increased by 88 characters by the possible addition of
       the TRANSID keyword and value;

(5) MAIL FROMコマンドラインの最大の長さはTRANSIDキーワードと価値の可能な追加によって88のキャラクタによって増強されます。

Crocker, Freed & Cargille     Experimental                      [Page 2]

RFC 1845                SMTP Checkpoint/Restart           September 1995

クロッカー、解放されるのとCargille[2ページ]実験的なRFC1845SMTPチェックポイント/再開1995年9月

 (6)   no additional SMTP verbs are defined by this extension;
       and,

(6) どんな追加SMTP動詞もこの拡大で定義されません。 そして

 (7)   the next section specifies how support for the
       extension affects the behavior of a server and client
       SMTP.

(7) 次のセクションは拡大のサポートがどうサーバとクライアントSMTPの動きに影響するかを指定します。

3.  The checkpointing service extension

3. checkpointingは拡大を修理します。

   When a client SMTP wishes to use checkpointing to eliminate the need
   to retransmit all message data in its entirety in the event of a
   session interruption, it first issues the EHLO command to the server
   SMTP. If the server SMTP responds with code 250 to the EHLO command,
   and the response includes the EHLO keyword value CHECKPOINT, then the
   server SMTP is indicating that it supports SMTP checkpointing and
   will honor requests to restart interrupted SMTP transactions.

クライアントSMTPがセッション中断の場合、すべてのメッセージデータを全体として再送する必要性を排除するのにcheckpointingを使用したがっているとき、それは最初に、サーバSMTPにEHLOコマンドを発行します。 サーバSMTPがコード250でEHLOコマンドに応じて、応答がEHLOキーワード値のCHECKPOINTを含んでいると、サーバSMTPはSMTP checkpointingをサポートするのを示していて、中断しているSMTPトランザクションを再開するという要求を光栄に思うでしょう。

   The extended MAIL command is issued by a client SMTP when it wishes
   to enable server checkpointing. The syntax for this command is
   identical to the MAIL command in [1], except that a TRANSID parameter
   must appear after the address.

サーバcheckpointingを可能にしたがっているとき、拡張メールコマンドはクライアントSMTPによって発行されます。 このコマンドのための構文は[1]のメールコマンドと同じです、TRANSIDパラメタがアドレスの後に現れなければならないのを除いて。

   The complete syntax of this extended command is defined in [4], with
   the esmtp-keyword TRANSID and transid-value parameter as previously
   defined.

この拡張コマンドの完全な構文は[4]で定義されます、以前に定義されているとしてのesmtp-キーワードTRANSIDとtransid-値のパラメタで。

   The value associated with the TRANSID parameter must be an identifier
   that serves to uniquely identify this particular SMTP transaction.
   Only one TRANSID parameter may be used in a single MAIL command. Care
   must be used in constructing TRANSID values to simultaneously insure
   both uniqueness and the ability to reidentify interrupted
   transactions.

TRANSIDパラメタに関連している値は唯一この特定のSMTPトランザクションを特定するのに役立つ識別子でなければなりません。 ただ一つのメールコマンドに1つのTRANSIDパラメタだけを使用してもよいです。 注意は同時にユニークさと再特定する能力の両方がトランザクションを中断したのを保障するためにTRANSID値を構成する際に働かなければなりません。

   The TRANSID is structured to ensure globally uniqueness without any
   additional registry. The transid-domain part should be a valid domain
   name that uniquely identifies the SMTP client. Note that this is
   usually the same as the domain name given in conjunction with the
   EHLO command, but not always. The EHLO domain name identifies the
   specific host the SMTP connection originated from, whereas the
   transid-domain may refer to a group of hosts that collectively host a
   multi-homed SMTP client. The transid-local part should be an
   identifier that distinguishes this SMTP transaction from any other
   originating from this SMTP client.

TRANSIDは、少しも追加登録なしでユニークさをグローバルに確実にするために構造化されます。 transid-ドメイン部分は唯一SMTPクライアントを特定する有効なドメイン名であるべきです。 通常、これがEHLOコマンドに関連して与えられたドメイン名と同じであることに注意しますが、いつも注意するというわけではなくなってください。 EHLOドメイン名がSMTP接続が発した特定のホストを特定しますが、transid-ドメインがaをまとめて接待するホストのグループを参照するかもしれない、マルチ、家へ帰り、SMTPクライアント。 transid地方の部分はこのSMTPクライアントからのいかなる他のも起因するのとこのSMTPトランザクションを区別する識別子であるべきです。

   Despite the structured nature of the TRANSID the server should treat
   the value as an opaque, case-sensitive string.

TRANSIDの構造化された自然にもかかわらず、サーバは不透明で、大文字と小文字を区別するストリングとして値を扱うべきです。

Crocker, Freed & Cargille     Experimental                      [Page 3]

RFC 1845                SMTP Checkpoint/Restart           September 1995

クロッカー、解放されるのとCargille[3ページ]実験的なRFC1845SMTPチェックポイント/再開1995年9月

   Note that the contents of the RFC822 message-id header typically are
   NOT appropriate for use as the TRANSID parameter value, since such
   identifiers may be associated with multiple copies of the same
   message -- e.g., as it is split during transmission down different
   network paths -- and hence with multiple distinct SMTP transactions.

使用には、RFC822メッセージイドヘッダーの内容がTRANSIDパラメタ価値として通常適切でないことに注意してください、そのような識別子が例えば、それがトランスミッションの下にの異なったネットワーク経路の間、分けられるので複本に関する同じメッセージとしたがって、複数の異なったSMTPトランザクションに関連しているかもしれないので。

   A server which supports the checkpointing extension will then retain
   the transaction identifer as well as the most recent state of the
   transaction in non-volatile storage. This information should deleted
   only when the transaction is known to be complete from the client's
   perspective. Completion is assured only when the client either
   explicitly aborts the transaction, starts a new transaction, or
   requests that the connection be closed with a QUIT command.

そして、checkpointingに拡大をサポートするサーバは非揮発性記憶装置でトランザクションの最新の状態と同様にトランザクションidentiferを保有するでしょう。 トランザクションがクライアントの見解から完全であることが知られているときだけ、削除されて、この情報はそうするべきです。 クライアントが、明らかにトランザクションを中止するか、新しいトランザクションを始めるか、または接続がQUITコマンドで閉店するよう要求する場合にだけ、完成は保証されます。

   In the event of an interruption prior to completing a transaction
   this preserved state will remain for some period of time defined by
   the operational policies of the server administrator. It is
   recommended that transaction state information be preserved for at
   least 48 hours, although no specific time is required.

これが保存した取引を完了する前の中断の場合、状態はサーバアドミニストレータの運用政策によって定義されたいくつかの期間の間、残るでしょう。 どんな特定の時間も必要ではありませんが、トランザクション州の情報が少なくとも48時間保存されるのは、お勧めです。

   When a client detects that a transaction has been interrupted, it
   then must wait for some period before reconnecting. This period must
   be long enough for server connections to time out and for the
   transaction state associated with such connections to be released for
   use by a new connection. The Internet Host Requirements [5] also
   impose restriction on how quickly reconnection attempts can be made
   (section 5.3.1.1).

クライアントがそれを検出すると、トランザクションは中断されて、次に、それは再接続する前に、いつかの期間、待たなければなりません。 この期間は新しい接続が使用のためにタイムアウトと、そして、そのような接続に関連しているトランザクション状態とのサーバ接続を釈放できるくらい長くなければなりません。 また、インターネットHost Requirements[5]がどれくらいすぐに再接続試みをすることができるかに関する制限を課す、(セクション5.3 .1 .1)。

   Once the necessary period has elapsed the client first checks the DNS
   as described in [6] and determine the set of acceptable IP addresses
   the message can be transferred to. If the IP address used to connect
   to the original server is still on this list it should be tried
   first, since this server is most likely to be capable of restarting
   the transaction. If this connection attempt fails the client must
   then proceed as described in [6] to try all the remaining IP
   addresses and restart the transaction there. If the attempt to
   restart fails on one of the other servers the client is required to
   retransmit the transaction in its entirety at that point.  Waiting
   for a server with an interrupted transaction state to come back
   online is not acceptable.

必要な期間がいったん経過する後、クライアントは最初に[6]で説明されるようにDNSをチェックします、そして、メッセージを移すことができる許容できるIPアドレスのセットを決定してください。 オリジナルのサーバに接続するのに使用されるIPアドレスがまだこのリストにあるなら、それは最初に試みられるべきです、このサーバがトランザクションを最も再開できそうであるので。 この接続試みが失敗するなら、クライアントはすべての残っているIPアドレスを試みて、そこでトランザクションを再開するために[6]で説明されるように続かなければなりません。 再開する試みが他のサーバの1つで失敗するなら、クライアントはその時、トランザクションを全体として再送しなければなりません。 中断しているトランザクション状態とのサーバがオンラインで戻るのを待つのは許容できません。

   Note: Multi-homed SMTP servers do exist, which means that it is
   entirely possible for a transaction to restart on a different server
   host.

以下に注意してください。 マルチ、家へ帰り、SMTPサーバーは存在しています(トランザクションが異なったサーバー・ホストの上で再開するのが、完全に可能であることを意味します)。

   Once the connection is made the client issues the same MAIL command
   with exactly the same transaction identifier. If the transaction was
   interrupted during or at the end of the transfer of actual message

接続がいったん作られると、クライアントはまさに同じトランザクション識別子で同じメールコマンドを発行します。 トランザクションが終わりか実際のメッセージの転送の終わりに中断されたなら

Crocker, Freed & Cargille     Experimental                      [Page 4]

RFC 1845                SMTP Checkpoint/Restart           September 1995

クロッカー、解放されるのとCargille[4ページ]実験的なRFC1845SMTPチェックポイント/再開1995年9月

   data, the server first reestablishes its context to a point close as
   possible to the point of interruption and then responds with the
   status message:

データ、サーバは、最初に、可能であるとしての中断までポイント閉鎖に文脈を回復させて、次に、ステータスメッセージで反応します:

     355 octet-offset is the transaction offset

355八重奏オフセットはトランザクションオフセットです。

   The actual status text can vary. However the octet-offset field is
   required to be the first thing on the first line of the reply, it
   must be separated from any following text by linear whitespace, and
   it is structured as follows:

実際の状態テキストは異なることができます。 八重奏オフセット分野が回答の最初の系列の最初のものになるのにどのように必要であっても、どんな次のテキストとも直線的な空白でそれを切り離さなければなりません、そして、それは以下の通り構造化されます:

     octet-offset ::= 1*DIGIT

以下を八重奏で相殺してください:= 1*ケタ

   The octet-offset represents an offset, counting from zero, to the
   particular octet in the actual message data the server expects to see
   next. (This is also a count of how many octets the server has
   received and stored successfully.) This offset does NOT account for
   envelope data, i.e., MAIL FROM and RCPT TO commands. A value of 0
   would indicate that the client needs to start sending the message
   from the beginning, a value of 1 would indicate that the client
   should skip one octet, and so on.

八重奏オフセットはオフセットを表します、ゼロから数えて、サーバが次であることを見ると予想する実際のメッセージデータにおける特定の八重奏に。 (また、これはサーバが首尾よくいくつの八重奏を受けて、保存したかに関するカウントです。) このオフセットは封筒データ、すなわち、MAIL FROMの原因になりません、そして、RCPT TOは命令します。 0の値は、クライアントが、始めからメッセージを送り始める必要であるのを示して、1の値は、クライアントが1つの八重奏などをサボるべきであるのを示すでしょう。

   The SMTP canonical format for messages is used when this offset is
   computed.  Any octets added by any SMTP data-stuffing algorithm do
   not count as part of this offset. In the case of data transferred
   with the DATA command the offset must also correspond to the
   beginning of a line.

このオフセットが計算されるとき、メッセージのためのSMTPの正準な形式は使用されています。 どんなデータを詰めるSMTPアルゴリズムでも加えられたどんな八重奏もこのオフセットの一部にみなしません。 また、DATAコマンドで移されたデータの場合では、オフセットは系列の始まりに対応しなければなりません。

   Once this context is reestablished the client issues another data
   transfer command (e.g., DATA) and sends the remaining message data.
   Once this data is terminated the transaction completes in the normal
   fashion and the server deletes the transaction context from non-
   volatile storage.

この文脈がいったん回復すると、クライアントは、別のデータ転送コマンド(例えば、DATA)を発行して、残っているメッセージデータを送ります。 このデータがいったん終えられると、トランザクションは標準でファッションを終了します、そして、サーバは非揮発性記憶装置からトランザクション文脈を削除します。

   Note that the semantics of the octet-offset immediately suggest a
   particularly simple implementation strategy, where the client
   retransmits the message data as it normally would but suppresses
   output of the first octet-offset octets of material. The semantics
   used here are intentionally designed to make such implementation
   possible, but care must be taken to insure that such an
   implementation strategy does not impose a significant performance
   penalty on the client.

八重奏オフセットの意味論がすぐに特に簡単な実装戦略を示すことに注意してください。(そこでは、クライアントは、通常、再送するようにメッセージデータを再送しますが、材料の最初の八重奏オフセット八重奏の出力を抑圧します)。 ここで使用された意味論はそのような実装を可能にするように故意に設計されていますが、そのような実装戦略が重要なパフォーマンスに不利な条件をクライアントに課さないのを保障するために注意しなければなりません。

Crocker, Freed & Cargille     Experimental                      [Page 5]

RFC 1845                SMTP Checkpoint/Restart           September 1995

クロッカー、解放されるのとCargille[5ページ]実験的なRFC1845SMTPチェックポイント/再開1995年9月

5.  Usage Example

5. 使用例

   The following dialogue illustrates the use of the checkpointing
   service extension:

以下の対話はcheckpointingサービス拡張子の使用を例証します:

S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 CHECKPOINT
C: MAIL FROM:<ned@ymir.claremont.edu> TRANSID=<12345@claremont.edu>
S: 250 <ned@ymir.claremont.edu>... Sender and TRANSID ok
C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
C: DATA
S: 354 Send checkpointed message, ending in CRLF.CRLF
<some amount of message data transmitted>
<session is interrupted and TCP connection is broken>

S: TCPポート25>Cにおける接続のための<待ち: サーバ>Sとの<のオープンな接続: 220 dbc.mtview.ca.us SMTPは持ち合わせのCを修理します: EHLO ymir.claremont.edu S: 250-dbc.mtview.ca.usはこんにちは、Sを言います: 250 チェックポイントC: FROM:<ned@ymir.claremont.edu に郵送してください、gt;、 TRANSID=<12345@claremont.edu 、gt;、S: 250 <ned@ymir.claremont.edu 、gt;、… 送付者とTRANSID OK C: RCPT TO:<mrose@dbc.mtview.ca.us 、gt;、S: 250 <mrose@dbc.mtview.ca.us 、gt;、… 受取人OK C: データS: 354 いくらかの量のメッセージのデータの伝えられた><セッションをCRLF.CRLF<に終わらせるのは中断されます、そして、checkpointedメッセージを送ってください、そして、TCP接続は壊れている>です。

Some time later a new connection is established:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 CHECKPOINT
C: MAIL FROM:<ned@ymir.claremont.edu> TRANSID=<12345@claremont.edu>
S: 355 6135 is the transaction offset
C: DATA
S: 354 Send previously checkpointed message starting at octet 6135
C: <message data minus first 6135 octets sent>
C: .
S: 250 OK
C: QUIT
S: 221 Goodbye

その後、新しい接続は確立されます: S: TCPポート25>Cにおける接続のための<待ち: サーバ>Sとの<のオープンな接続: 220 dbc.mtview.ca.us SMTPは持ち合わせのCを修理します: EHLO ymir.claremont.edu S: 250-dbc.mtview.ca.usはこんにちは、Sを言います: 250 チェックポイントC: FROM:<ned@ymir.claremont.edu に郵送してください、gt;、 TRANSID=<12345@claremont.edu 、gt;、S: 355 6135はトランザクションオフセットCです: データS: 354 以前にcheckpointedされたメッセージに八重奏で6135Cを始めさせてください: 最初の6135の八重奏を引いた<メッセージデータは>Cを送りました: . S: 250 OK C: Sをやめてください: 221さよなら

6.  Security Considerations

6. セキュリティ問題

   This RFC does not discuss security issues and is not believed to
   raise any security issues not already endemic in electronic mail and
   present in fully conforming implementations of [1].

このRFCは安全保障問題について議論しないで、また既に電子メールの風土病の、そして、[1]の実装を完全に従わせることにおける現在でないどんな安全保障問題も提起すると信じられていません。

Crocker, Freed & Cargille     Experimental                      [Page 6]

RFC 1845                SMTP Checkpoint/Restart           September 1995

クロッカー、解放されるのとCargille[6ページ]実験的なRFC1845SMTPチェックポイント/再開1995年9月

7.  References

7. 参照

   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

[1] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。

   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

   [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
       Extensions", RFC 1521, Bellcore, Innosoft, September 1993.

[3] Borenstein、N.と解放されたN.、「マルチパーパスインターネットメールエクステンション」、RFC1521、Bellcore、Innosoft、1993年9月。

   [4] Rose, M., Stefferud, E., Crocker, D., Klensin, J., and N. Freed,
       "SMTP Service Extensions", RFC 1651, Dover Beach Consulting,
       Inc., Network Management Associates, Inc., Silicon Graphics,
       Inc., MCI, Innosoft, July 1994.

[4] ローズ、M.、Stefferud、E.、クロッカー、D.、Klensin、J.、および解放されたN.「SMTPサービス拡張子」、RFC1651、ドーヴァービーチコンサルティングInc.、ネットワークマネージメントはInc.を関連づけます、シリコングラフィックス、MCI、Innosoft、1994年7月。

   [5] Braden, R., Editor, "Requirements for Internet Hosts -
       Application and Support", STD 3, RFC 1123, USC/Information
       Sciences Institute, October 1989.

[5] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123(科学が1989年10月に設けるUSC/情報)

   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, BBN, January 1986.

[6] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、STD14、RFC974、BBN、1月1986日

8.  Authors' Addresses

8. 作者のアドレス

       Dave Crocker
       Brandenburg Consulting
       675 Spruce Dr.
       Sunnyvale, CA 94086 USA
       USA

デーヴの医者ブランデンブルクのコンサルティング675はサニーベルカリフォルニア94086米国博士(米国)を小綺麗にします。

       Phone: +1 408 246 8253
       Fax: +1 408 249 6205
       EMail: dcrocker@mordor.stanford.edu

以下に電話をしてください。 +1 408 246、8253Fax: +1 6205年の408 249メール: dcrocker@mordor.stanford.edu

       Ned Freed
       Innosoft International, Inc.
       1050 East Garvey Avenue South
       West Covina, CA 91790
       USA

ネッドは東ガーヴェーアベニューSouth West Innosoftの国際Inc.1050カリフォルニア91790コビーナ(米国)を解放しました。

       Phone: +1 818 919 3600
       Fax: +1 818 919 3614
       EMail: ned@innosoft.com

以下に電話をしてください。 +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com

Crocker, Freed & Cargille     Experimental                      [Page 7]

解放されてCargille実験的なクロッカー[7ページ]