Network Working Group A. Melnikov
Request for Comments: 3503 ACI Worldwide/MessagingDirect
Category: Standards Track March 2003
Message Disposition Notification (MDN) profile for
Internet Message Access Protocol (IMAP)
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 Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment.
RFC 2298で定義されたメッセージ気質通知（MDN）ファシリティメッセージが肯定応答並びに肯定応答に使用されるフォーマットされた受信者によってそのメッセージの処理を要求することができる手段を提供します。しかし、それはメールユーザエージェント（MUA）は、インターネットメッセージアクセスプロトコル（IMAP4）環境で開封通知の世代をどのように処理するかを複数記述していません。
This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products.
この文書では、このような環境の中で開封通知を処理する方法について説明し、自社製品にMDNのサポートを追加したいIMAP4の実装のためのガイドラインを提供します。
Table of Contents
目次
1. Conventions Used in this Document............................. 2
2. Introduction and Overview..................................... 2
3. Client behavior............................................... 3
3.1. Client behavior when receiving a message................. 5
3.2. Client behavior when copying a message................... 5
3.3. Client behavior when sending a message................... 5
3.4. Client behavior when saving a temporary message.......... 5
4. Server behavior............................................... 5
4.1. Server that supports arbitrary keywords.................. 5
4.2. Server that supports only $MDNSent keyword............... 5
4.3. Interaction with IMAP ACL extension...................... 6
5. Examples...................................................... 6
6. Security Considerations....................................... 7
7. Formal Syntax................................................. 7
8. Acknowledgments............................................... 7
9. Normative References.......................................... 8
10. Author's Address.............................................. 8
11. Full Copyright Statement...................................... 9
"C:" and "S:" in examples show lines sent by the client and server respectively.
「C：」と「S：」の例ではそれぞれクライアントとサーバから送られた行を示しています。
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document when typed in uppercase are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」「要件レベルを示すためのRFCsにおける使用のためのキーワード」で定義されているように解釈され、大文字で入力されたこの文書に記載されています[KEYWORDS]。
This memo defines an additional [IMAP4] mailbox keyword that allows multiple Mail User Agents (MUAs) to know if a requested receipt notification was sent.
このメモは、要求されたレシート通知が送信されたかどうかを知るために、複数のメールユーザエージェント（MUA）を可能にする追加の[IMAP4]メールボックスのキーワードを定義します。
Message Disposition Notification [MDN] does not require any special support of IMAP in the case where a user has access to the mailstore from only one computer and is using a single MUA. In this case, the MUA behaves as described in [MDN], i.e., the MUA performs automatic processing and generates corresponding MDNs, it performs requested action and, with the user's permission, sends appropriate MDNs. The MUA will not send MDN twice because the MUA keeps track of sent notifications in a local configuration. However, that does not work when IMAP is used to access the same mailstore from different locations or is using different MUAs.
メッセージ気質通知[MDNは、ユーザが1台のコンピュータからメールストアへのアクセスを持ち、単一のMUAを用いた場合のIMAPの特別なサポートを必要としません。この場合、MUAは、[MDN]に記載されているように振舞う、すなわち、MUAは、自動処理を実行し、対応する開封通知を生成し、それはユーザの許可を得て、適切な開封通知を送信し、要求されたアクションを実行し。 MUAはローカル設定に送信される通知を追跡しますので、MUAは二回MDNを送信しません。 IMAPは異なる場所から同じメールストアにアクセスするために使用されるか、異なるのMUAを使用している場合しかし、それは動作しません。
This document defines a new special purpose mailbox keyword $MDNSent that must be used by MUAs. It does not define any new command or response for IMAP, but describes a technique that MUAs should use to achieve interoperability.
この文書では、のMUAで使用されている必要があり、新たな特別な目的のメールボックスキーワードの$ MDNSentを定義します。これは、任意の新しいコマンドまたはIMAPのための応答を定義しますが、のMUAは、相互運用性を実現するために使用する技術が記載されていません。
When a client opens a mailbox for the first time, it verifies that the server is capable of storing the $MDNSent keyword by examining the PERMANENTFLAGS response code. In order to support MDN in IMAP, a server MUST support either the $MDNSent keyword, or arbitrary message keywords.
クライアントが初めてメールボックスを開くと、それは、サーバがPERMANENTFLAGS応答コードを調べることによって$ MDNSentキーワードを記憶することが可能であることを確認します。 IMAPでMDNをサポートするために、サーバは$ MDNSentキーワード、または任意のメッセージのキーワードのいずれかをサポートしなければなりません。
The use of IMAP requires few additional steps in mail processing on the client side. The following timeline modifies the timeline found in Section 4 of [MDN].
IMAPを使用すると、クライアント側でのメール処理中にいくつかの追加の手順が必要です。次のタイムラインは[MDN]のセクション4で見つかったタイムラインを修正します。
-- User composes message.
- ユーザーがメッセージを構成します。
-- User tells MUA to send message.
- ユーザーがメッセージを送信するMUAを伝えます。
-- MUA passes message to MSA (original recipient information passed along). MUA [optionally] saves message to a folder for sent mail with $MDNSent flag set.
- MUAは、MSA（元の受信者の情報に沿って渡される）にメッセージを渡します。 MUAは、[必要に応じて] $ MDNSentフラグを設定して送信されたメールのフォルダにメッセージを保存します。
-- MSA sends message to MTA.
- MSAは、MTAにメッセージを送信します。
-- Final MTA receives message.
- 最終的なMTAは、メッセージを受信します。
-- Final MTA delivers message to MUA (possibly generating DSN).
- 最終的なMTAは、MUA（おそらくDSNを生成する）にメッセージを配信します。
-- MUA logs into IMAP server, opens mailbox, verifies if mailbox can store $MDNSent keyword by examining PERMANENTFLAGS response.
- MUAは、IMAPサーバにログインするメールボックスを開き、メールボックスがPERMANENTFLAGS応答を調べることによって$ MDNSentキーワードを保存することができた場合に検証します。
-- MUA performs automatic processing and generates corresponding MDNs ("dispatched", "processed", "deleted", "denied" or "failed" disposition type with "automatic-action" and "MDN-sent-automatically" disposition modes) for messages that do not have $MDNSent keyword, or \Draft flag set. (*)
- MUAは、自動処理を実行し、対応する開封通知を生成する（「派遣」、「処理」、「削除」、「拒否」または「自動アクション」の配置タイプと「MDN-送信-自動的に」配置モードを「失敗」）のために$ MDNSentキーワード、または\ドラフトフラグが設定されていないメッセージ。 （*）
-- MUA sets the $MDNSent keyword for every message that required an automatic MDN to be sent, whether or not the MDN was sent.
- MUAはMDNが送信されたかどうかにかかわらず、送信される自動MDNを必要とするすべてのメッセージのための$ MDNSentキーワードを設定します。
-- MUA displays a list of messages to user.
- MUAは、ユーザへのメッセージのリストが表示されます。
-- User selects a message and requests that some action be performed on it.
- ユーザーは、メッセージを選択し、いくつかのアクションがそれに実行することを要求します。
-- MUA performs requested action and, with user's permission, sends appropriate MDN ("displayed", "dispatched", "processed", "deleted", "denied" or "failed" disposition type with "manual-action" and "MDN-sent-manually" or "MDN-sent-automatically" disposition mode). If the generated MDN is saved to a mailbox with the APPEND command, the client MUST specify the $MDNSent keyword in the APPEND.
- MUAは、ユーザーの許可を得て、要求されたアクションを実行し、適切なはMDN（、「派遣」、「処理」、「削除」、「拒否」または「マニュアルアクション」と「MDNと気質タイプを「失敗」「表示」を送信-sent-手動」または "MDN-送信-自動的に" 配置モード）。生成されたMDNは、APPENDコマンドを使用してメールボックスに保存されている場合、クライアントは、APPENDで$ MDNSentキーワードを指定する必要があります。
-- MUA sets the $MDNSent keyword for all messages for which the user confirmed the dispatching of disposition (or was explicitly prohibited to do so).
- MUAは、ユーザが処分のディスパッチを確認した（または明示的にそうすることを禁止された）そのためにすべてのメッセージのための$ MDNSentキーワードを設定します。
-- User possibly performs other actions on message, but no further MDNs are generated.
- ユーザは、おそらくメッセージに他のアクションを実行するが、更なる開封通知は生成されません。
(*) Note: MUA MUST NOT use \Recent flag as an indicator that it should send MDN, because according to [IMAP4], "If multiple connections have the same mailbox selected simultaneously, it is undefined which of these connections will see newly-arrived messages with \Recent set and which will see it without \Recent set". Thus, using \Recent as an indicator will cause unpredictable client behavior with different IMAP4 servers. However, the client MAY use \Seen flag as one of the indicators that MDN must not be sent. The client MUST NOT use any other standard flags, like \Draft or \Answered, to indicate that MDN was previously sent, because they have different well known meaning. In any case, in the presence of the $MDNSent keyword, the client MUST ignore all other flags or keywords for the purpose of generating an MDN and MUST NOT send the MDN.
（*）注：複数の接続が同時に選択された同じメールボックスを持っている場合は、[IMAP4]によると、」、表示されますこれらの接続のどの定義されていないので、MUAが、それはMDNを送る必要があることを示す指標として\ Recentフラグを使用してはならない新しく\最近のセットでメッセージを到着した\最近のセット」なしでそれを見ることができます。このように、指標として\最近のを使用すると、別のIMAP4サーバと予測不可能なクライアントの動作が発生します。ただし、クライアントはMDNが送信されてはならない指標の一つとして\見フラグを使用するかもしれません。彼らは別のよく知られた意味を持っているため、クライアントは、MDNが以前に送信されたことを示すために、回答\ドラフトまたは\、のような、他の標準的なフラグを使用してはなりません。いずれの場合も、$ MDNSentキーワードの存在下では、クライアントはMDNを生成する目的のために他のすべてのフラグやキーワードを無視しなければなりませんし、MDNを送ってはいけません。
When the client opens a mailbox for the first time, it must verify that the server supports the $MDNSent keyword, or arbitrary message keywords by examining PERMANENTFLAGS response code.
クライアントが初めてメールボックスを開くと、それは、サーバがPERMANENTFLAGS応答コードを調べることによって$ MDNSentキーワード、または任意のメッセージのキーワードをサポートしていることを確認する必要があります。
The client MUST NOT try to set the $MDNSent keyword if the server is incapable of storing it permanently.
クライアントは、サーバーが永久に保存することができない場合は$ MDNSentキーワードを設定してみてはなりません。
The client MUST be prepared to receive NO from the server as the result of STORE $MDNSent when the server advertises the support of storing arbitrary keywords, because the server may limit the number of message keywords it can store in a particular mailbox. A client SHOULD NOT send MDN if it fails to store the $MDNSent keyword.
サーバは、任意のキーワードを保存するサポートをアドバタイズするとき、サーバは、それが特定のメールボックスに格納できるメッセージのキーワードの数を制限する可能性があるため、クライアントは、STORE $ MDNSentの結果として、サーバからNO受け取るために準備しなければなりません。それは$ MDNSentキーワードを保存するために失敗した場合、クライアントはMDNを送るべきではありません。
Once the $MDNSent keyword is set, it MUST NOT be unset by a client. The client MAY set the $MDNSent keyword when a user denies sending the notification. This prohibits all other MUAs from sending MDN for this message.
$ MDNSentキーワードが設定されると、それはクライアントによって設定解除されてはなりません。ユーザーが通知を送信拒否したときに、クライアントは$ MDNSentキーワードを設定することができます。これは、このメッセージのMDNを送るから他のすべてのMUAを禁止します。
The client MUST NOT send MDN if a message has the $MDNSent keyword set. It also MUST NOT send MDN if a message has \Draft flag, because some clients use this flag to mark a message as incomplete.
メッセージは$ MDNSentキーワードが設定されている場合、クライアントはMDNを送ってはいけません。メッセージは\ドラフトフラグを持っている場合、一部のクライアントが不完全としてメッセージをマークするために、このフラグを使用するので、それはまた、MDNを送ってはいけません。
See the timeline in section 3 for details on client behavior when receiving a message.
メッセージを受信したときにクライアントの動作の詳細については、セクション3のタイムラインを参照してください。
The client SHOULD verify that $MDNSent is preserved on a COPY operation. Furthermore, when a message is copied between servers with the APPEND command, the client MUST set the $MDNSent keyword correctly.
クライアントは$ MDNSentはCOPY操作で保存されていることを確認する必要があります。メッセージはAPPENDコマンドを使用して、サーバ間でコピーされるときさらに、クライアントが正しく$ MDNSentキーワードを設定しなければなりません。
When saving a sent message to any folder, the client MUST set the $MDNSent keyword to prevent another client from sending MDN for the message.
任意のフォルダに送信されたメッセージを保存する場合、クライアントは、メッセージのためにMDNを送るから別のクライアントを防ぐために$ MDNSentキーワードを設定しなければなりません。
When saving an unfinished message to any folder client MUST set $MDNSent keyword to prevent another client from sending MDN for the message.
任意のフォルダクライアントに未完成のメッセージを保存する場合は、メッセージのためにMDNを送るから別のクライアントを防ぐために$ MDNSentキーワードを設定しなければなりません。
Server implementors that want to follow this specification must insure that their server complies with either section 4.1 or section 4.2. If the server also supports the IMAP [ACL] extension, it MUST also comply with the section 4.3.
この仕様をフォローしたいサーバの実装は、そのサーバがセクション4.1または4.2項のいずれかに準拠していることを保証しなければなりません。サーバはまた、IMAP [ACL]拡張機能をサポートしている場合、それはまた、セクション4.3を遵守しなければなりません。
No changes are required from the server to make it compatible with the extension described in this document if it supports arbitrary keywords.
変更は、それが任意のキーワードをサポートしている場合、この文書で説明する拡張機能と互換性を持たせるために、サーバーから必要ありません。
Servers that support only the $MDNSent keyword MUST preserve it on the COPY operation. It is also expected that a server that supports SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.
のみ$ MDNSentキーワードをサポートするサーバーは、COPY操作でそれを保存しなければなりません。また、検索<フラグ>をサポートしているサーバーでも検索キーワード$ MDNSentをサポートすることが期待されます。
Any server that conforms to either 4.1 or 4.2 and also supports the IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY even if the client does not have 'w' right. This will prevent the generation of a duplicated MDN for the same message. Note that the server MUST still check if the client has rights to perform the COPY operation on a message according to [ACL].
4.1または4.2のいずれかに準拠しており、また、IMAP [ACL]拡張をサポートするすべてのサーバは、クライアントが右の「W」を持っていない場合でも、COPYで$ MDNSentキーワードを維持すべきです。これは、同じメッセージの重複MDNの発生を防止します。クライアントは、[ACL]に従ってメッセージにコピー操作を実行する権限を持っている場合、サーバーがまだチェックしなければならないことに注意してください。
1) MUA opens mailbox for the first time.
1）MUAは、初めてのメールボックスを開きます。
a) The server supports storing of arbitrary keywords
a）は、サーバは、任意のキーワードの保存をサポートしています
C: a100 select INBOX S: * FLAGS (\Flagged \Draft \Deleted \Seen) S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)] S: * 5 EXISTS S: * 3 RECENT S: * OK [UIDVALIDITY 894294713] S: a100 OK [READ-WRITE] Completed
C：A100選択INBOXのS：* FLAGS（\ \ドラフト\削除\見たフラグ付き）S：* OK S [PERMANENTFLAGS（\フラグ付き\ドラフト\削除\ \ *見られる）]：* 5はSをEXISTS：* 3 RECENT S。 * OK [UIDVALIDITY 894294713] S：完成したA100 OK [READ-WRITE]
b) The server supports storing of the $MDNSent keyword
b）のサーバは$ MDNSentキーワードの保存をサポートしています
C: a100 select INBOX S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent) S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)] S: * 5 EXISTS S: * 3 RECENT S: * OK [UIDVALIDITY 894294713] S: a100 OK [READ-WRITE] Completed
C：A100を選択INBOXのS：* FLAGS（\フラグ付き\ドラフト\削除された\ $ MDNSent見て）S：* OK S [PERMANENTFLAGS（\フラグ付き\ドラフト\削除された\ $ MDNSent見られる）]：* 5はSをEXISTS：* 3 RECENT S：* OK [UIDVALIDITY 894294713] S：A100 OK [READ-WRITE]を完了
2) The MUA successfully sets the $MDNSent keyword
2）MUAが正常に$ MDNSentキーワードを設定し、
C: a200 STORE 4 +FLAGS ($MDNSent) S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent)) S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen) S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)] S: a200 OK STORE completed
C：A200 STORE 4つの+ FLAGS（$ MDNSent）S：* 4 FETCH S（FLAGS（\フラグ付き\ $ MDNSent）見た）：* FLAGS S（見$ MDNSent \フラグ付き\削除された\ドラフト\）：* OK [PERMANENTFLAGS（ $ MDNSent \フラグ付き\削除された\ドラフト\が見\ *）] S：A200 OKストア完了
3) The server refuses to store the $MDNSent keyword
3）サーバは$ MDNSentキーワードを保存することを拒否します
C: a200 STORE 4 +FLAGS ($MDNSent) S: a200 NO STORE failed : no space left to store $MDNSent keyword
C：A200 STORE 4つの+ FLAGS（$ MDNSent）S：A200はNO STOREに失敗しました：なしスペースは$ MDNSentキーワードを保存するために残っていません
4) All clients and servers MUST treat the $MDNSent keyword as case insensitive in all operations, as stated in [IMAP].
[IMAP]で述べたように4）すべてのクライアントとサーバは、すべての操作で大文字と小文字を区別しないで$ MDNSentキーワードを扱わなければなりません。
C: a300 FETCH 1:* FLAGS S: * 1 FETCH (FLAGS (\Seen)) S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt)) S: * 3 FETCH (FLAGS ()) S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT)) S: * 5 FETCH (FLAGS ($MDNSent)) S: * 6 FETCH (FLAGS (\Recent)) S: a300 OK FETCH completed C: a400 SEARCH KEYWORDS $mdnsent S: * SEARCH 2 4 5 S: a400 OK SEARCH completed
C：A300が1 FETCH：* FLAGSのS：（FLAGS（））S FETCH 3 *：（FLAGS（\答える\見$ MdnSENt））SをFETCH 2 *：*（FLAGS（\見られる））SをFETCH 1 * 4 （FLAGS（\ \見$ mdnSENTをフラグ付き））FETCH S：*（FLAGS（$ mDNSentを））FETCH 5 S：*（FLAGS（最近の\を））FETCH 6 S：A300 OK完了C FETCH：A400検索キーワードを$ mdnsent S ：* SEARCH 2 4 5 S：完成A400 OK検索
There are no known security issues with this extension, not found in [MDN] and/or [IMAP4].
これではない[MDN]で見つけ延長、および/または[IMAP4]とは、既知のセキュリティ上の問題はありません。
Section 4.3 changes ACL checking requirements on an IMAP server that implements IMAP [ACL] extension.
4.3節はACLがIMAP [ACL]拡張機能を実装してIMAPサーバ上の要件を確認し変更します。
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822], as modified by [IMAP4]. Non-terminals referenced, but not defined below, are as defined by [IMAP4].
[IMAP4]によって修正され、[RFC-822]で指定されるように、次の構文仕様は、拡張バッカスナウア記法（BNF）の表記を使用します。非端末は、参照が、以下に定義されていない、[IMAP4]で定義した通りです。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
flag_keyword ::= "$MDNSent" / other_keywords
other_keywords ::= atom
This document is the product of discussions that took place on the IMAP mailing list. Special gratitude to Cyrus Daboo and Randall Gellens for reviewing the document.
この文書は、IMAPメーリングリストで行われた議論の産物です。文書をレビューするためのCyrus DabooとランドールGellensに特別な感謝。
Thank you to my father who as he has helped to make me what I am. I miss you terribly.
彼は私は何私を作るために役立っているように私の父に感謝します。私はひどくあなたを欠場します。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MDN] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[MDN] Fajman、R.、RFC 2298、1998年3月の "メッセージ処分通知のための広げることができるメッセージフォーマット"。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[ACL]マイヤーズ、J.、 "IMAP4 ACL拡張"、RFC 2086、1997年1月。
Alexey Melnikov ACI Worldwide/MessagingDirect 59 Clarendon Road Watford, Hertfordshire United Kingdom, WD17 1FQ
アレクセイ・メルニコフACI世界/ MessagingDirect 59クラレンドンロードワトフォード、ハートフォードシャーイギリス、WD17 1FQ
Phone: +44 1923 81 2877 EMail: mel@messagingdirect.com
電話：+44 1923 81 2877 Eメール：mel@messagingdirect.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。