Network Working Group G. White
Request for Comments: 4865 Independent
Updates: 3463, 3464 G. Vaudreuil
Category: Standards Track Alcatel-Lucent
May 2007
SMTP Submission Service Extension for Future Message Release
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time.
このメモは、配信のためにリリースされるメッセージのための未来の時間を示すために、クライアントのSMTP送信プロトコルの拡張を定義します。この拡張は、将来的に任命されるまでキューに保持されるべきメッセージをサーバーベースのストレージを使用するようにクライアントを許可します。これは、ローカルストレージを持っているか、そうでない場合は指定された時間に配信するためのメッセージを解放することはできませんしていないクライアントのために有用です。
There is a widely used feature within the voice messaging community to compose and send a message for delivery in the future. This is useful for sending announcements to be heard at the beginning of a work day, to send birthday greetings a day or so ahead, or to use as a lightweight facility to build a personal reminder service.
構成し、将来の配信のためにメッセージを送信するために音声メッセージングコミュニティ内で広く使われている機能があります。これは、一日の誕生日の挨拶を送信するか、そう先、または個人的なリマインダーサービスを構築するために軽量の施設として使用するために、作業日の始めに聞こえるようにアナウンスを送信する場合に便利です。
This extension uses the SMTP submission protocol [n3] to allow a client, when submitting a message, to indicate a future time for the message to be released for delivery.
この拡張は、配信のためにリリースされるメッセージの将来の時間を示すメッセージを、提出するとき、クライアントを許可する[N3] SMTP送信プロトコルを使用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [n1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[N1]に記載されているように解釈されます。
The Future Message Release service extension for SMTP submission uses the SMTP service extension mechanism [n4] to extend the SMTP submission protocol [n3]. The following SMTP submission service extension is hereby defined:
SMTP送信のための未来のメッセージリリースサービス拡張は、SMTP送信プロトコル[N3]を拡張するために、[N4] SMTPサービス拡張メカニズムを使用しています。以下のSMTP送信サービス拡張は、ここで定義されています。
The name of the SMTP submission service extension is "Future Message Release".
SMTP送信サービス拡張の名前は、「未来のメッセージリリース」です。
1) The Extended Hello (EHLO) keyword associated with this service extension is "FUTURERELEASE".
1）本サービス拡張に関連した拡張のHello（EHLO）キーワードは「FUTURERELEASE」です。
2) Two required parameters, the max-future-release-interval and the max-future-release-date-time, are combined with the EHLO keyword in the manner specified in [n4].
2）2つの必須パラメータ、MAX-将来放出間隔および最大将来リリース日時、[N4]で指定された方法でEHLOキーワードと組み合わされます。
The max-future-release-interval is a positive integer indicating the maximum amount of time for which the message submission server (MSA) will hold messages for future release.
MAX-将来のリリース間隔は、メッセージ送信サーバ（MSA）は、将来のリリースのためのメッセージを保持する時間の最大量を示す正の整数です。
Using ABNF [n2], the syntax of this parameter is as follows:
次のようにABNFを使用すると、[N2]、このパラメータの構文は次のとおりです。
future-release-integer = %x31-39 *8DIGIT
; integer in the range 1-999999999
; measured in seconds
max-future-release-interval = future-release-integer
MAX-将来のリリース間隔=将来のリリース整数
The max-future-release-date-time is a timestamp, normalized to Universal Coordinated Time (UTC), indicating the most remote date and time in the future until which the MSA will hold messages for future release.
MAX-将来のリリース-日時はMSAは、将来のリリースのためにメッセージを保持なるまで、将来的に最も離れた日時を示す協定世界時（UTC）に正規化されたタイムスタンプ、です。
Using ABNF [n2], the syntax of this parameter is as follows:
次のようにABNFを使用すると、[N2]、このパラメータの構文は次のとおりです。
max-future-release-date-time = date-time
MAX-将来のリリース・日時=日時
where the format of date-time is defined in [n10].
日時の形式は、[N10]で定義されます。
3) When forming the portion of the EHLO reply containing the FUTURERELEASE keyword, the keyword is followed by the max-future-release-interval, and then the max-future-release-date-time. The keyword and two values are delimited by spaces.
EHLOの部分FUTURERELEASEキーワードを含む応答を形成する場合3）、キーワードはMAX-将来のリリース間隔が続き、その後MAX-将来リリース日時。キーワードと2つの値は、スペースで区切られます。
For example, the ABNF for a continuation line in the EHLO response that contains the FUTURERELEASE keyword is:
例えば、FUTURERELEASEキーワードが含まれているEHLO応答における継続行のためのABNFは、次のとおりです。
line = "250-FUTURERELEASE" SP max-future-release-interval SP max-future-release-date-time
ライン= "250-FUTURERELEASE" SP-maxの将来のリリース間隔SP MAX-将来のリリース・日時
4) One required parameter, the hold-param, is added to the MAIL command using either the keyword "HOLDFOR" or the keyword "HOLDUNTIL".
4）1つの必須パラメータ、ホールドPARAMは、キーワード「HOLDFOR」またはキーワード「HOLDUNTIL」のいずれかを使用してメールコマンドに追加されます。
The HOLDFOR parameter value is a future-release-interval, which is a positive integer indicating the amount of time the message is to be held by the MSA before release.
HOLDFORパラメータ値は、メッセージがリリース前MSAによって保持される時間の量を表す正の整数である今後のリリース間隔、です。
The HOLDUNTIL parameter value is a future-release-date-time, which is a timestamp, normalized to UTC, indicating the future date and time until which the message is to be held by the MSA before release.
HOLDUNTILパラメータ値は、メッセージがリリース前MSAによって保持されるようになるまで、将来の日付と時間を示すUTCに正規化されたタイムスタンプを、ある将来リリース日時です。
Using ABNF [n2], the syntax of this parameter is as follows:
次のようにABNFを使用すると、[N2]、このパラメータの構文は次のとおりです。
future-release-interval = future-release-integer
今後のリリース間隔=将来のリリース整数
future-release-date-time = Internet-style-date-time-UTC
将来のリリース・日時=インターネット・スタイル・日付・時間のUTC
hold-for-param = "HOLDFOR=" future-release-interval
ホールド用-PARAM = "HOLDFOR =" 将来のリリース間隔
hold-until-param = "HOLDUNTIL=" future-release-date-time
ホールドまで-のparam = "HOLDUNTIL =" 将来のリリース・日時
hold-param = hold-for-param / hold-until-param
/ホールド用-PARAM =-PARAMを保持するホールドまで-PARAM
The absence of this parameter on the MAIL command does not imply a default value for this parameter.
MAILコマンドでこのパラメータが存在しない場合は、このパラメータのデフォルト値を意味するものではありません。
5) The maximum length of a MAIL command is increased by 34 characters by the possible addition of the hold-param.
5）MAILコマンドの最大長は、ホールドPARAMの可能な添加により34文字だけ増加させます。
6) No additional SMTP verbs are defined by this extension.
6）追加のSMTP動詞はこの拡張によって定義されていません。
7) This service extension is appropriate only for the SMTP submission protocol [n3]. This service extension is not appropriate for standard SMTP [n4].
7）このサービス拡張は、SMTP送信プロトコル[N3]に適しています。このサービス拡張は、標準のSMTP [N4]には適していません。
It is unfortunate to define two seemingly identical ways to indicate a future message release time. When the client has both accurate time and accurate time zone information, either interval or date-time can be trivially calculated from the other. However, in the current world of clients, there are clients with accurate local time but no indication of their time zone, and clients without a suitably accurate clock. Based on the limited facilities available to these time-challenged clients, it is likely that only one or the other of these mechanisms will be useful.
将来のメッセージのリリースタイムを示すには、2つの一見同じ方法を定義することが残念です。クライアントは、正確な時間と正確なタイムゾーン情報の両方を持っている場合は、間隔または日付時刻のどちらかは自明他から計算することができます。しかし、クライアントの現在の世界では、正確なローカルタイムを持つクライアントが、その時間帯の表示なし、およびクライアントが適切に正確なクロックなしです。これらの時間チャレンジのクライアントに利用可能な限られた施設に基づいて、これらのメカニズムのどちらか一方のみが有用であろうと思われます。
It is believed that servers will have accurate time, and can trivially convert between these mechanisms. It is also accepted that the protocol and implementation overhead of offering these two mechanisms is low, and that few interoperability challenges are anticipated.
サーバが正確な時間を持つことになり、かつ自明これらのメカニズムの間で変換することができると考えられます。また、これら2つのメカニズムを提供するプロトコルと実装のオーバーヘッドが低いこと、およびいくつかの相互運用性の課題が予想されていることが認められています。
1) An SMTP client preparing to use Future Message Release MUST first verify that the MSA supports this extension.
1）今後のメッセージリリースを使用するための準備SMTPクライアントは、最初のMSAは、この拡張機能をサポートしていることを確かめなければなりません。
2) An SMTP client using Future Message Release MUST include one, and only one, hold-param with the MAIL command.
2）今後のメッセージリリースを使用してSMTPクライアントが1、そして唯一の、MAILコマンドでホールドのparamを含まなければなりません。
3) An SMTP client using Future Message Release with the "for" option of the hold-param MUST ensure that the future-release-interval is less than or equal to the max-future-release-interval advertised by the MSA.
3）ホールドPARAMの「ため」オプションを使用して未来のメッセージリリースを使用してSMTPクライアントは、将来のリリース間隔がMAX-将来のリリース間隔MSAによってアドバタイズ以下であることを保証しなければなりません。
4) An SMTP client using Future Message Release with the "until" option of the hold-param MUST ensure that the future-release-date-time is earlier than or equal to the max-future-release-date-time advertised by the MSA.
ホールド-PARAMのオプションは、将来のリリース・日時よりも早いかによってアドバタイズMAX-将来のリリース-日時に等しいであることを保証しなければならない「まで」と今後のメッセージリリースを使用して4）SMTPクライアントMSA。
1) An MSA supporting Future Message Release MUST comply with the SMTP submission protocol as described in [n3].
[N3]に記載されているように1）MSA支持将来のメッセージリリースSMTP送信プロトコルに従わなければなりません。
2) An MSA supporting Future Message Release MUST NOT advertise this support (i.e. include the FUTURERELEASE keyword in its EHLO reply) on any port other than the submission port.
2）アンMSA支える未来のメッセージリリースは、サブミッションポート以外のポートで（すなわち、そのEHLO応答でFUTURERELEASEキーワードを含め）このサポートを広告してはなりません。
3) An MSA supporting Future Message Release MUST include the FUTURERELEASE keyword, and associated max-future-release-interval and max-future-release-date-time parameters, in its reply to the EHLO command.
3）今後のメッセージリリースをサポートしているアンMSAは、EHLOコマンドへの応答でFUTURERELEASEキーワード、および関連するMAX-将来のリリース間隔とmax-将来のリリース・日時パラメータを含まなければなりません。
4) An MSA supporting Future Message Release MUST accept a MAIL command containing a valid hold-param, given that the MAIL command contains no other errors.
4）MSA支える未来のメッセージリリースは、MAILコマンドは、他のエラーが含まれていないことを考えると、有効なホールドのparamを含むMAILコマンドを受け入れなければなりません。
5) An MSA that accepts a message with a request for Future Message Release indicating the "for" option MUST NOT release the message until the amount of time specified in the future-release-interval elapses.
5）を示す未来のメッセージリリースのための要求にメッセージを受け入れアンMSAが経過し、将来のリリース間隔で指定した時間の量になるまでメッセージを解放してはならないオプション「の」。
6) An MSA that accepts a message with a request for Future Message Release indicating the "until" option MUST NOT release the message until the date and time indicated by the future-release-date-time occurs.
オプションがするまでメッセージを解放てはならない「まで」6）を示す未来のメッセージリリースのための要求にメッセージを受け入れMSAは、将来のリリース・日時によって示された日付と時刻が発生します。
7) An MSA supporting Future Message Release MUST reject a MAIL command containing the "for" option specifying a value that is greater than the advertised max-future-release-interval, or otherwise invalid.
7）アンMSA支える未来のメッセージリリース「の」広告を出してMAX-将来のリリース間隔よりも大きい値を指定するオプション、またはその他の無効を含むMAILコマンドを拒絶しなければなりません。
8) An MSA supporting Future Message Release MUST reject a MAIL command containing the "until" option specifying a value that is later than the advertised max-future-release-date-time, or otherwise invalid.
8）MSA支える未来のメッセージリリースは、後に広告を出してMAX-将来のリリース・日時よりも値を指定するオプション、またはそうでなければ無効「までを」含むMAILコマンドを拒絶しなければなりません。
9) An MSA supporting Future Message Release MUST reject a MAIL command containing more than one hold-param.
9）MSA支える未来のメッセージリリースは、複数のホールドのparamを含むMAILコマンドを拒絶しなければなりません。
10) An MSA supporting Future Message Release, when rejecting a MAIL command per items 7, 8, or 9, above, SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
アイテム7、8、または9当たりMAILコマンドを拒否する場合10）今後のメッセージリリースをサポートアンMSAは、上記パラメータまたは応答における引数[N4]）で応答コード501（構文エラーを提供する必要があります。
11) An MSA supporting Future Message Release, when rejecting a MAIL command per items 7, 8, or 9, above, SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply.
11）項目7,8、または9当たりMAILコマンドを拒否する場合アンMSAは、将来のメッセージのリリースをサポートする、上記応答に拡張メールシステムステータスコードを5.5.4（無効なコマンド引数[I1]）を供給すべきです。
The Delivery Status Notification (DSN) service extension is described in [n7], and DSN message format is described in [n8].
配信状態通知（DSN）サービス拡張が[N7]に記載されており、DSNメッセージフォーマットは、[N8]に記載されています。
1) An SMTP client MUST NOT request Future Message Release when sending a DSN to the MSA.
MSAへのDSNを送信するとき1）SMTPクライアントは、今後のメッセージリリースを要求してはなりません。
1) If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include an Arrival-Date field in the machine-readable body part of the DSN.
1）MSAは、将来のメッセージ解除要求を含むメッセージのDSNを生成する場合、MSAは、DSNの機械可読本体部に到着日付フィールドを含まなければなりません。
2) If an MSA generates a DSN for a message that includes a Future Message Release request, the MSA MUST include a Future-Release-Request field in the machine-readable body part of the DSN. The value of this field is the value of the HOLD parameter contained in the MAIL command of the original message.
2）MSAは、将来のメッセージ解除要求を含むメッセージのDSNを生成する場合、MSAは、DSNの機械可読本体部に将来-RELEASE-要求フィールドを含まなければなりません。このフィールドの値は、元のメッセージのMAILコマンドに含まHOLDパラメータの値です。
The Future-Release-Request field is an extension to the set of DSN per-message fields described in [n8]. Using ABNF [n2], the syntax of this new field is as follows:
将来-RELEASE-要求フィールドは、[N8]に記載DSNメッセージごとのフィールドのセットに拡張したものです。次のようにABNFを使用すると、[N2]、この新しいフィールドの構文は次のとおりです。
orig-hold-param-value = ("for;" future-release-interval) / ("until;" future-release-date-time) ; this is the value of the HOLD param from ; the MAIL command of the original message
ORIGホールドPARAM値=（「で、」将来のリリース間隔）/（「まで;」将来リリース日時）。これは、HOLDのPARAMからの値です。元のメッセージのMAILコマンド
future-release-request-field = "Future-Release-Request:" orig-hold-param-value
将来の解放要求フィールド= "未来-リリースリクエスト：" ORIGホールドのparam-値
If an MSA supports the Future Message release and Deliver By service extensions, it is possible for an SMTP client to make simultaneous requests for future message release and deliver-by times when submitting a message. A problem will occur if the future message release time is farther in the future than the deliver-by time. In order to honor the deliver-by request, the future message release request has to be ignored. In order to honor the future message release request, the deliver-by request has to be ignored. This section addresses that problem. The Deliver By extension is described in [n6].
MSAは、今後のメッセージのリリースをサポートし、サービス拡張により、お届けした場合、SMTPクライアントは、将来のメッセージリリースの同時要求を作成し、提供-によって回メッセージを提出する際にすることが可能です。将来のメッセージのリリース時には遠く将来的に実現-によってよりも時間があれば、問題が発生します。提供-の要求を尊重するためには、将来のメッセージの解放要求を無視する必要があります。将来のメッセージの解放要求を尊重するためには、提供-の要求を無視する必要があります。このセクションでは、その問題に対処しています。拡張により配信[N6]に記載されています。
1) When an SMTP client wishes to use the Future Message Release and Deliver By extensions with the same message, the client MUST ensure that the specified deliver-by time is farther in the future than the specified ("until" option) or implied ("for" option) future message release time.
1）SMTPクライアントは将来のメッセージリリースを使用し、同じメッセージを拡張することで配信を希望する場合、クライアントはオプション「まで」（指定）または暗黙の（より将来的に遠く提供-することにより、時間指定されていることを確認しなければなりません。オプション「について」）将来のメッセージのリリースタイム。
1) If an MSA supports Future Message Release and Deliver By extensions, and receives a message requesting the use of both extensions, the MSA MUST reject the MAIL command if it determines that the future message release time is farther in the future than the deliver-by time.
MSAは将来のメッセージリリースをサポートし、拡張することで配信し、そして両方の拡張機能の使用を要求するメッセージを受信した場合、それは将来のメッセージのリリース時には遠く将来にdeliver-よりであると判断した場合1）、MSAはMAILコマンドを拒絶しなければなりません時間によります。
2) When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the reply code 501 (syntax error in parameters or arguments [n4]) in the reply.
MSAは、上記、項目1あたりMAILコマンドを拒否された場合2）、それは応答で応答コード501（パラメータ又は引数[N4]の構文エラー）を供給すべきです。
3) When an MSA is rejecting a MAIL command per item 1, above, it SHOULD supply the Enhanced Mail System Status Code 5.5.4 (invalid command arguments [i1]) in the reply.
MSAは、上記、項目1あたりMAILコマンドを拒否された場合3）、それは応答で）強化されたメールシステムステータスコード5.5.4（無効なコマンド引数[I1]を提供する必要があります。
The Message Disposition Notification (MDN) function is described in [n9].
メッセージ気質通知（MDN）関数は、[N9]に記載されています。
1) An SMTP client MUST NOT request Future Message Release when sending an MDN to the MSA.
MSAにMDNを送信するとき1）SMTPクライアントは、今後のメッセージリリースを要求してはなりません。
The Future Message Release service extension presents a number of security considerations:
未来のメッセージリリースサービス拡張は、セキュリティ上の考慮事項の数を提示します：
1) Unauthorized future-release messages provide a means to overwhelm the storage of an MSA. The authorization mechanisms required for the base mail submission protocol [n3] are expected to provide appropriate defense against such attacks.
1）不正な将来のリリースメッセージは、MSAのストレージを圧倒するための手段を提供します。基本メール送信プロトコル[N3]に必要な認証機構は、このような攻撃に対する適切な防衛を提供することが期待されています。
2) Authorized future message release without a per-user quota may also provide a way to overwhelm an MSA's storage. An MSA's future release message storage SHOULD be subject to a per-user quota.
2）また、MSAのストレージを圧倒するための方法を提供することができるユーザーごとのクォータなしで、将来のメッセージのリリースを承認しました。 MSAの将来のリリースメッセージストレージは、ユーザーごとのクォータの対象とすべきです。
3) If an MSA is imposing a per-user quota on future-release message storage, and detects that an incoming future-release message will exceed the user's future-release message storage quota, the MSA MUST reject the MAIL command.
MSAは、将来のリリースメッセージストレージにユーザーごとのクォータを課す、着信将来リリースメッセージは、ユーザの将来のリリースメッセージの保存容量を超過することを検出された場合3）、MSAは、MAILコマンドを拒絶しなければなりません。
4) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the reply code 552 (requested mail action aborted: exceeded storage allocation [n4]) in the reply.
MSAが5.3あたりMAILコマンドを拒否された場合4）、要求されたメールアクションは中止（応答コード552を供給する必要があります応答に記憶割当[N4]）を超え。
5) When an MSA is rejecting a MAIL command per 5.3, it SHOULD supply the new Enhanced Mail System Status Code defined for this purpose. This new status code updates [i1].
MSAは5.3あたりにMAILコマンドを拒否された場合5）、それは、この目的のために定義された新しい強化されたメールシステムステータスコードを提供する必要があります。この新しいステータスコードの更新[I1]。
X.7.16 Future release per-user message quota exceeded
超過X.7.16今後のリリースで、ユーザーごとのメッセージ割り当て
There is insufficient per-user quota to queue the message for future release. This code suggests the client can submit again only after the per-user queue has drained.
将来のリリースのためにメッセージをキューに不十分なユーザ単位のクォータがあります。このコードは、クライアントは、ユーザーごとのキューを排出した後にのみ、再提出することができます示唆しています。
X.7.17 Future release system message quota exceeded
X.7.17将来のリリースのシステムメッセージのクォータを超過します
There is insufficient system quota to queue the message for future release. This code suggests the client can submit again after the system queue has drained.
将来のリリースのためにメッセージをキューに不足しているシステムのクォータがあります。このコードは、システム・キューを排出した後に、クライアントが再び提出することができます示唆しています。
6) Inaccurate time on the MSA may result in premature or delayed release of messages. Both HOLDUNTIL and HOLDFOR request mechanisms are sensitive to inaccurate or changing clocks on the MSA.
6）MSAに不正確な時間は、メッセージの早期または遅延放出をもたらすことができます。両方HOLDUNTILとHOLDFOR要求メカニズムは、MSAに不正確な又は変化クロックに敏感です。
7) Some element of deception is inherent in the future message release concept. The message release time is intentionally delayed past the time it would otherwise be released; hence, the message delivery time is delayed past the time it would otherwise be delivered. This extension provides no mechanism for hiding this from the message recipient. The RFC 2822 [n5] message header, and specifically the Date field, remain unchanged after submission. While a sending client MAY elect to place the future-message-release-time as the date in the Date field, there is no requirement or expectation that the Received fields and other trace information be modified by the transport system to further this deception.
7）詐欺のいくつかの要素は、将来のメッセージのリリース概念に固有のものです。メッセージのリリース時には、意図的にそれはそうリリースされる時間を過ぎて遅れています。したがって、メッセージの配信時間は、それがそうでなければ送達される時間を越えて遅延されます。この拡張は、メッセージ受信者からこれを隠すためのメカニズムを提供していません。 RFC 2822 [N5]メッセージヘッダ、および具体的に日付フィールドは、提出後に変わりません。送信クライアントは、日付フィールドに日付と未来のメッセージ・リリース・タイムを置くことを選択するかもしれないが、受信したフィールドやその他のトレース情報は、この詐欺を促進するために、トランスポートシステムによって変更されることは要求や期待はありません。
This extension has been added to the list of SMTP Service Extensions on the Mail Parameters Web page.
この拡張は、メールのパラメータ、Webページ上のSMTPサービス拡張のリストに追加されました。
Much of the credit for this document is due to the LEMONADE working group. Through many revisions, the discussion resulted in fundamental new understandings of this protocol and corresponding refinement of the implied requirements and protocol. Special thanks to those who patiently lead the WG to understand that doing both interval and date-time was the pragmatically correct approach to the needs of diverse clients.
このドキュメントのための信用の多くはレモネードワーキンググループによるものです。多くの改訂を経て、議論はこのプロトコルと暗黙の要件とプロトコルの対応改善の基本的な新しい理解が得られました。辛抱強く間隔と日時の両方を行うことは、多様な顧客のニーズに実用的に正しいアプローチだったことを理解することがWGをリードする人に感謝します。
[n1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[N1]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[n2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[N2]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[n3] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[N3] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。
[n4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[N4] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[n5] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[N5]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[n6] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[N6]ニューマン、D.、RFC 2852、2000年6月 "SMTPサービス拡張により、お届け"。
[n7] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[N7]ムーア、K.、RFC 3461 "配信状態通知（DSN）のための簡易メール転送プロトコル（SMTP）サービス拡張"、2003年1月。
[n8] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[N8]ムーア、K.とG.ボードルイ、RFC 3464、2003年1月、 "配信状態通知のための広げることができるメッセージフォーマット"。
[n9] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[N9]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、RFC 3798、2004年5月。
[n10] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002
[N10] Klyne、G.とC.ニューマン、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年7月
[i1] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[I1]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
Authors' Addresses
著者のアドレス
Gregory A. White 6519 Camille Ave. Dallas, TX 75252 USA EMail: g.a.white@tx.rr.com
グレゴリーA.ホワイト6519カミーユ・アベニュー。ダラス、TX 75252 USA電子メール：g.a.white@tx.rr.com
Gregory M. Vaudreuil Alcatel-Lucent 9489 Bartgis Ct Frederick, MD 21702 USA EMail: GregV@ieee.org
グレゴリーM.ヴォードルイユアルカテル・ルーセント9489 BartgisのCtフレデリック、MD 21702 USA Eメール：GregV@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。