Network Working Group J. Degener
Request for Comments: 5293 P. Guenther
Category: Standards Track Sendmail, Inc.
August 2008
Sieve Email Filtering: Editheader Extension
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields.
この文書は、電子メールのヘッダフィールドを追加および削除「ふるい」のメールフィルタリング言語のための2つの新しいアクションを定義します。
Email header fields are a flexible and easy-to-understand means of communication between email processors. This extension enables sieve scripts to interact with other components that consume or produce header fields by allowing the script to delete and add header fields.
電子メールのヘッダフィールドは、電子メールプロセッサ間通信の柔軟かつ簡単に理解する手段です。この拡張は、スクリプトがヘッダフィールドを削除して追加できるようにすることで、消費やヘッダフィールドを生成する他の成分と相互作用するためにふるいスクリプトを有効にします。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
Conventions for notations are as in Section 1.1 of [SIEVE], including use of the "Usage:" label for the definition of action and tagged arguments syntax.
表記の規則は、「使用方法：」の使用を含め、[SIEVE]のセクション1.1のようにしているアクションの定義のためのラベルと引数の構文をタグ付け。
The term "header field" is used here as in [IMAIL] to mean a logical line of an email message header.
用語「ヘッダーフィールドは、」電子メールメッセージのヘッダの論理回線を意味する[IMAIL]のように、ここで使用されます。
The capability string associated with the extension defined in this document is "editheader".
この文書で定義された拡張子に関連付けられた機能文字列は「editheader」です。
Usage: "addheader" [":last"] <field-name: string> <value: string>
使用法： "はaddheader" [ "：最後の" <フィールド名：文字列> <値：文字列>
The addheader action adds a header field to the existing message header. If the field-name is not a valid 7-bit US-ASCII header field name, as described by the [IMAIL] "field-name" nonterminal syntax element, the implementation MUST flag an error. The addheader action does not affect Sieve's implicit keep.
addheaderアクションは、既存のメッセージヘッダにヘッダフィールドを付加します。フィールド名は、有効な7ビットUS-ASCIIヘッダフィールド名でない場合、[IMAIL]「フィールド名」非終端記号構文要素、実施MUSTフラグ誤差によって記載されたように。 addheaderアクションは、ふるいの暗黙のキープには影響を与えません。
If the specified field value does not match the [IMAIL] "unstructured" nonterminal syntax element or exceeds a length limit set by the implementation, the implementation MUST either flag an error or encode the field using folding white space and the encodings described in [MIME3] or [MIMEPARAM] to be compliant with [IMAIL].
指定されたフィールドの値が[IMAIL]「非構造」非終端構文要素と一致または実装によって設定された長さ制限を超えていない場合、実装は、いずれかのMUSTフラグエラーまたはフォールディングホワイトスペースとに記載エンコーディングを使用して、フィールドを符号化する[MIME3 ]または[MIMEPARAM] [IMAIL]に準拠します。
An implementation MAY impose a length limit onto the size of the encoded header field; such a limit MUST NOT be less than 998 characters, not including the terminating CRLF supplied by the implementation.
実装は、符号化されたヘッダフィールドのサイズに長さの制限を課すことができます。そのような制限は、実装によって供給された終端CRLFを含まない未満998個の文字であるはずがありません。
By default, the header field is inserted at the beginning of the existing message header. If the optional flag ":last" is specified, it is appended at the end.
デフォルトでは、ヘッダフィールドは、既存のメッセージヘッダの先頭に挿入されます。オプションのフラグ場合「：最後」が指定され、それが最後に追加されます。
Example:
例：
/* Don't redirect if we already redirected */
if not header :contains "X-Sieve-Filtered"
["<kim@job.example.com>", "<kim@home.example.com>"]
{
addheader "X-Sieve-Filtered" "<kim@job.example.com>";
redirect "kim@home.example.com";
}
Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
[COMPARATOR] [MATCH-TYPE]
<field-name: string>
[<value-patterns: string-list>]
By default, the deleteheader action deletes all occurrences of the named header field. The deleteheader action does not affect Sieve's implicit keep.
デフォルトでは、deleteheaderアクションは名前のヘッダフィールドのすべてのオカレンスを削除します。 deleteheaderアクションは、ふるいの暗黙のキープには影響を与えません。
The field-name is mandatory and always matched as a case-insensitive US-ASCII string. If the field-name is not a valid 7-bit header field name as described by the [IMAIL] "field-name" nonterminal syntax element, the implementation MUST flag an error.
フィールド名は必須で、常に大文字と小文字を区別しないUS-ASCII文字列としてマッチしています。 [IMAIL]「フィールド名」非終端記号構文要素、実施MUSTフラグ誤差によって記載されているようにフィールド名は、有効な7ビットのヘッダフィールド名でない場合。
The value-patterns, if specified, restrict which occurrences of the header field are deleted to those whose values match any of the specified value-patterns, the matching being according to the match-type and comparator and performed as if by the "header" test. In particular, leading and trailing whitespace in the field values is ignored. If no value-patterns are specified, then the comparator and match-type options are silently ignored.
価値のパターンは、指定された場合、マッチングはマッチ型コンパレータに従ってあると「ヘッダ」であるかのように行わ、ヘッダ・フィールドの発生をその値は指定された価値のパターンのいずれに一致するものに削除された制限しますテスト。具体的には、フィールド値の先頭と末尾の空白は無視されます。何の価値パターンが指定されていない場合は、コンパレータとマッチタイプのオプションは黙って無視されます。
If :index <fieldno> is specified, the attempts to match a value are limited to the <fieldno> occurrence of the named header field, beginning at 1, the first named header field. If :last is specified, the count is backwards; 1 denotes the last named header field, 2 the second to last, and so on. The counting happens before the <value-patterns> match, if any. For example:
場合：インデックス<fieldno>が指定され、値が一致する試みは、<fieldno>という名前のヘッダフィールドの発生、1から始まり、最初の名前のヘッダフィールドに限定されます。もし：最後に指定されているが、カウントは後方です。図1は、これの最後の名前のヘッダフィールドは、最後には2秒であり、。もしあれば、カウントは、<値-パターン>試合前に行われます。例えば：
deleteheader :index 1 :contains "Delivered-To" "bob@example.com";
deleteheader：インデックス1： "配信-へ" "bob@example.com" が含まれています。
deletes the first "Delivered-To" header field if it contains the string "bob@example.com" (not the first "Delivered-To" field that contains "bob@example.com").
それは（「bob@example.com」が含まれていない最初の「配信先」フィールド）は、文字列「bob@example.com」が含まれている場合、最初の「配信先」ヘッダフィールドを削除します。
It is not an error if no header fields match the conditions in the deleteheader action or if the :index argument is greater than the number of named header fields.
引数indexという名前のヘッダフィールドの数よりも大きい：なしヘッダフィールドはdeleteheaderアクションで場合、または条件に一致しない場合はエラーではありません。
The implementation MUST flag an error if :last is specified without also specifying :index.
実施MUSTフラグエラー場合：最後も指定せずに指定されている：インデックス。
As a matter of local policy, implementations MAY limit which header fields may be deleted and which header fields may be added. However, implementations MUST NOT permit attempts to delete "Received" and "Auto-Submitted" header fields and MUST permit both addition and deletion of the "Subject" header field.
ローカルポリシーの問題として、実装は、ヘッダフィールドを削除してもよいし、どのヘッダフィールドを追加することができる制限することができます。しかし、実装は、「受信」と「自動提出」ヘッダフィールドを削除しようとする試みを許可してはならないし、「件名」ヘッダフィールドの両方の追加や削除を許可する必要があります。
If a script tries to make a change that isn't permitted, the attempt MUST be silently ignored.
スクリプトが許可されていない変更を行うためにしようとした場合、試みは黙って無視しなければなりません。
Actions that generate [MDN], [DSN], or similar disposition messages MUST do so using the original, unmodified message header. Similarly, if an error terminates processing of the script, the original message header MUST be used when doing the implicit keep required by Section 2.10.6 of [SIEVE].
生成アクションは[MDN]、[DSN]、または類似の配置メッセージは、元の、未修飾のメッセージヘッダを使用して行う必要があります。エラーは、スクリプトの処理を終了した場合、[SIEVE]のセクション2.10.6によって要求される暗黙的なキープを行う場合も同様に、元のメッセージヘッダが使用されなければなりません。
All other actions that store, send, or alter the message MUST do so with the current set of header fields. This includes the addheader and deleteheader actions themselves. For example, the following leaves the message unchanged:
他のすべての保存アクション、送信、またはメッセージを変更するには、ヘッダフィールドの現在のセットを使用しなければなりません。これは、はaddheaderとdeleteheaderアクションそのものを含んでいます。例えば、以下は変わらないメッセージを残します：
addheader "X-Hello" "World";
deleteheader :index 1 "X-Hello";
Similarly, given a message with three or more "X-Hello" header fields, the following example deletes the first and third of them, not the first and second:
同様に、三つ以上の「X-ハロー」ヘッダフィールドを持つメッセージが与えられると、次の例では、第一及び第二のない、第一及びそれらの3分の1を削除します。
deleteheader :index 1 "X-Hello";
deleteheader :index 2 "X-Hello";
Tests and actions such as "exists", "header", or "vacation" [VACATION] that examine header fields MUST examine the current state of a header as modified by any actions that have taken place so far.
これまでに行われたすべてのアクションによって修正されたヘッダフィールドを調べてテストし、そのような「存在」などのアクション、「ヘッダ」、または「休暇」[休暇]ヘッダの現在の状態を検査しなければなりません。
As an example, the "header" test in the following fragment will always evaluate to true, regardless of whether or not the incoming message contained an "X-Hello" header field:
一例として、以下の断片の「ヘッダ」試験は関係なく、常に着信メッセージが、「X-ハロー」ヘッダフィールドを含んでいたかどうかの、真と評価されます。
addheader "X-Hello" "World";
if header :contains "X-Hello" "World"
{
fileinto "international";
}
However, if the presence or value of a header field affects how the implementation parses or decodes other parts of the message, then, for the purposes of that parsing or decoding, the implementation MAY ignore some or all changes made to those header fields. For example, in an implementation that supports the [BODY] extension, "body" tests may be unaffected by deleting or adding "Content-Type" or "Content-Transfer-Encoding" header fields. This does not rescind the requirement that changes to those header fields affect direct tests; only the semantic side effects of changes to the fields may be ignored.
ヘッダフィールドの存在又は値は、実装がメッセージの他の部分を解析または復号化方法に影響を与える場合は、次に、その解析または復号化の目的のために、実装は、これらのヘッダフィールドに加えられた一部またはすべての変更を無視してもよいです。例えば、[BODY]拡張をサポートする実装では、「本体」のテストは、「コンテンツタイプ」または「Content-Transfer-Encoding」ヘッダフィールドを削除または追加することによって影響を受けてもよいです。これは、直接のテストに影響を与えるそれらのヘッダフィールドへの変更要求を撤回しません。フィールドへの変更の唯一のセマンティックな副作用を無視することができます。
For the purpose of weeding out duplicates, a message modified by addheader or deleteheader MUST be considered the same as the original message. For example, in an implementation that obeys the constraint in Section 2.10.3 of [SIEVE] and does not deliver the same message to a folder more than once, the following code fragment
重複を淘汰する目的で、はaddheaderまたはdeleteheaderによって修正されたメッセージは、元のメッセージと同じとみなされなければなりません。例えば、[SIEVE]のセクション2.10.3に制約に従うと、複数回のフォルダに同じメッセージを配信しない実装で、次のコードで
keep;
addheader "X-Flavor" "vanilla";
keep;
MUST only file one message. It is up to the implementation to pick which of the redundant "fileinto" or "keep" actions is executed, and which ones are ignored.
1つのメッセージのみを提出しなければなりません。これは、冗長「のfileinto」の選択またはアクションが実行され、どれが無視され、「続ける」ための実装に任されています。
The "implicit keep" is thought to be executed at the end of the script, after the headers have been modified. (However, a canceled "implicit keep" remains canceled.)
ヘッダが変更された後、「暗黙のキープ」は、スクリプトの終了時に実行されると考えられています。 （ただし、キャンセル「暗黙のキープは、」キャンセルされたままになります。）
The following template specifies the IANA registration of the Sieve extension specified in this document:
次のテンプレートは、この文書で指定されたSieve拡張のIANA登録を指定します。
To: iana@iana.org Subject: Registration of new Sieve extension
To：iana@iana.org件名：新しいふるい拡張の登録
Capability name: editheader Description: Adds actions 'addheader' and 'deleteheader' that modify the header of the message being processed RFC number: RFC 5293 Contact Address: The Sieve discussion list <ietf-mta-filters&imc.org>
能力名：editheader説明：RFC 5293連絡先住所：RFC番号処理されているメッセージのヘッダーを変更するアクション「はaddheader」と「deleteheader」追加ふるいディスカッションリスト<IETF-MTA-フィルタを＆imc.org>
Someone with write access to a user's script storage may use this extension to generate headers that a user would otherwise be shielded from (e.g., by a gateway Mail Transport Agent (MTA) that removes them).
ユーザのスクリプトストレージへの書き込みアクセスを持つユーザーは、ユーザーがそうでなければ（例えば、それらを除去するゲートウェイメール転送エージェント（MTA）による）から遮蔽されるヘッダを生成するために、この拡張を使用することができます。
This is the first Sieve extension to be standardized that allows alteration of messages being processed by Sieve engines. A Sieve script that uses Sieve tests defined in [SIEVE], the editheader extension, and the redirect action back to the same user can keep some state between different invocations of the same script for the same message. But note that it would not be possible to introduce an infinite loop using any such script, because each iteration adds a new Received header field, so email loop prevention described in [SMTP] will eventually non deliver the message, and because the
これは、ふるいエンジンによって処理されるメッセージの変更を可能にする標準化された最初の篩の拡張です。同じユーザに戻す[SIEVE]で定義されたふるい試験、editheader拡張、およびリダイレクトアクションを使用Sieveスクリプトは、同じメッセージの同じスクリプトの異なる呼び出しの間に、いくつかの状態を保つことができます。しかし、各反復は、新しいReceivedヘッダフィールドが追加されますので、[SMTP]で説明した電子メールのループ防止は、最終的に非メッセージ、およびためをお届けしますので、そのようなスクリプトを使用して無限ループを導入することが可能ではないことに注意してください
editheader extension is explicitly prohibited to alter or delete Received header fields (i.e., it can't interfere with loop prevention).
editheader拡張は明示的（すなわち、それはループ防止を妨害することができない）は、受信ヘッダフィールドを変更または削除することが禁止されています。
A sieve filter that removes header fields may unwisely destroy evidence about the path a message has taken.
ヘッダフィールドを除去ふるいフィルタは愚かメッセージが取った経路についての証拠を破壊することができます。
Any change in message content may interfere with digital signature mechanisms that include the header in the signed material. For example, changes to (or deletion/addition of) header fields included in the "SHOULD be included in the signature" list in Section 5.5 of [DKIM] can invalidate DKIM signatures. This also includes DKIM signatures that guarantee a header field absence.
メッセージ内容の変更は、署名された材料でヘッダを含むデジタル署名メカニズムを妨害する可能性があります。例えば、（または欠失/添加）ヘッダフィールドの変更はDKIM署名を無効にすることができる[DKIM]のセクション5.5の「署名に含まれるべきである」リストに含まれます。これはまた、ヘッダーフィールドが存在しないことを保証するDKIM署名を含みます。
The editheader extension doesn't directly affect [IMAIL] header field signatures generated using [SMIME] or [OPENPGP], because these signature schemes include a separate copy of the header fields inside the signed message/rfc822 body part. However, software written to detect differences between the inner (signed) copy of header fields and the outer (modified by editheader) header fields might be affected by changes made by editheader.
これらの署名方式は、署名されたメッセージ/ RFC822本体部の内部ヘッダフィールドの個別のコピーを含むのでeditheader拡張は直接、[SMIME]または[OpenPGPの]使用して生成[IMAIL]ヘッダーフィールドの署名に影響を及ぼしません。しかし、内側の違いを検出するために書かれたソフトウェアは、ヘッダフィールド及び（editheaderによって修飾された）外部ヘッダ・フィールドのコピーがeditheaderによって行われた変更によって影響を受ける可能性がある（符号付き）。
Since normal message delivery adds "Received" header fields and other trace fields to the beginning of a message, many such digital signature mechanisms are impervious to headers prefixed to a message, and will work with "addheader" unless :last is used.
通常のメッセージの配信は、メッセージの先頭に「受信」ヘッダフィールド及び他のトレースフィールドを追加しているので、多くのそのようなデジタル署名メカニズムは、メッセージに接頭辞ヘッダに不浸透性であり、そして場合を除き、「はaddheader」で動作します。最後に使用されています。
Any decision mechanism in a user's filter that is based on headers is vulnerable to header spoofing. For example, if the user adds an APPROVED header or tag, a malicious sender may add that tag or header themselves. One way to guard against this is to delete or rename any such headers or stamps prior to processing the message.
ヘッダーに基づいて、ユーザのフィルタ内の任意の決定メカニズムがスプーフィングをヘッダに脆弱です。ユーザが承認ヘッダーまたはタグを付加した場合、悪質な送信者は、そのタグを追加したり、自分自身をヘッダできます。これを防ぐための一つの方法は、前のメッセージを処理するには、そのようなヘッダーやスタンプを削除したり、名前を変更することです。
Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed, Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson, Will Lee, William Leibzon, Mark E. Mallett, Chris Markle, Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson, and Rand Wacker for extensive corrections and suggestions.
エリック・オールマンのおかげで、サイラスDaboo、マシュー・Elvey、ネッドフリード、ARNT Gulbrandsenの、はKjetil Torgrimオム、サイモンJosefsson氏、ウィル・リー、ウィリアム・Leibzon、マーク・E.マレット、クリス・マークル、アレクセイ・メルニコフ、ランドール・シュワルツ、アーロン・ストーン、ナイジェルSwinson、大規模な修正や提案のためとランドワッカー。
[IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[IMAIL]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[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月。
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[MIME3]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[MIMEPARAM] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
、RFC 2231、1997年11月：[MIMEPARAM]、N.、およびK.ムーア、 "文字セット、言語、および継続のMIMEパラメータ値およびエンコードされたWordの拡張機能を" フリード。
[SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]ギュンター、P.、エド、およびT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"。。、RFC 5228、2008年1月。
[BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: Body Extension", RFC 5173, April 2008.
[BODY] Degener、J.とP.ギュンター、 "ふるいメールフィルタリング：ボディ延長"、RFC 5173、2008年4月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM]オールマン、E.、カラス、J.、デラニー、M.、リビー、M.、フェントン、J.、およびM.トーマス、 "ドメインキー・アイデンティファイド・メール（DKIM）署名"、RFC 4871、2007年5月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
[MDN]ハンセン、T.、エド。、およびG.ボードルイ、エド。、 "メッセージ気質通知"、RFC 3798、2004年5月。
[OPENPGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[OpenPGPの]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "OpenPGPの持つMIMEセキュリティ"、RFC 3156、2001年8月。
[SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[SMIME] Ramsdell、B.、エド。、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様"、RFC 3851、2004年7月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[VACATION] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[VACATION]ショーウォルター監督、T.およびN.フリード、エド、 "ふるいメールフィルタリング：バケーション拡張"、RFC 5230、2008年1月。
Authors' Addresses
著者のアドレス
Jutta Degener 5245 College Ave, Suite #127 Oakland, CA 94618
ユッタ・デッジナー5245大学アベニュー、スイート＃127、オークランド、CA 94618
EMail: jutta@pobox.com
メールアドレス：jutta@pobox.com
Philip Guenther Sendmail, Inc. 6475 Christie Ave., Ste 350 Emeryville, CA 94608
フィリップ・ギュンターのSendmail社6475クリスティアベニュー、スイート350エメリービル、CA 94608
EMail: guenther@sendmail.com
メールアドレス：guenther@sendmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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に情報を記述してください。