[要約] RFC 5293は、SieveメールフィルタリングのEditheader拡張機能に関する規格です。この規格の目的は、Sieveスクリプトを使用してメールヘッダーを編集するための機能を提供することです。
Network Working Group J. Degener
Request for Comments: 5293 P. Guenther
Category: Standards Track Sendmail, Inc.
August 2008
Sieve Email Filtering: Editheader Extension
ふるい電子メールフィルタリング：editheader拡張機能
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.
電子メールヘッダーフィールドは、電子メールプロセッサ間の柔軟で理解しやすい通信手段です。この拡張機能により、Sieve Scriptは、スクリプトがヘッダーフィールドを削除および追加できるようにすることにより、ヘッダーフィールドを消費または生成する他のコンポーネントと対話できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されていると解釈されます。
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>
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アクションは、既存のメッセージヘッダーにヘッダーフィールドを追加します。[IMAIL]「フィールド名」非末端構文要素で説明されているように、フィールド名が有効な7ビットUS-ASCIIヘッダーフィールド名でない場合、実装はエラーにフラグを立てる必要があります。Addheaderアクションは、Siveの暗黙のキープに影響しません。
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]「非構造化されていない」非末端構文要素と一致しない場合、または実装によって設定された長さ制限を超えている場合、実装は折りたたみホワイトスペースと[MIME33で説明されているエンコードを使用してエラーにフラグを立てるか、フィールドにエンコードする必要があります。]または[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.
デフォルトでは、既存のメッセージヘッダーの先頭にヘッダーフィールドが挿入されます。オプションのフラグ「：last」が指定されている場合、最後に追加されます。
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アクションは、Siveの暗黙のキープに影響しません。
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.
Field-Nameは必須であり、常にケースに依存しないUS-ASCII文字列として一致しています。[imail] "field-name"非末端構文要素で説明されているように、フィールド名が有効な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>が指定されている場合、値を一致させる試みは、最初の名前付きヘッダーフィールドである1から始まる名前付きヘッダーフィールドの<fieldno>の発生に限定されます。次の場合：最後に指定されている場合、カウントは後方になります。1は、最後の名前のヘッダーフィールド、2つの最後まで2つなどを示します。カウントは、<bule-Patterns>の試合前に発生します。例えば：
deleteheader :index 1 :contains "Delivered-To"
"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.
ヘッダーフィールドがDeleteHeaderアクションの条件と一致しない場合、またはインデックス引数が指定されたヘッダーフィールドの数よりも大きい場合は、エラーではありません。
The implementation MUST flag an error if :last is specified without also specifying :index.
実装は、次の場合、次の場合に指定されている場合、エラーにフラグを立てる必要があります。
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";
addheader "x-hello" "world";DeleteHeader：インデックス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:
同様に、3つ以上の「x-hello」ヘッダーフィールドを含むメッセージが与えられた場合、次の例は、1番目と2番目ではなく、それらの1つ目と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-hello」ヘッダーフィールドが含まれているかどうかに関係なく、常にTrueに評価されます。
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.
ただし、ヘッダーフィールドの存在または値が、実装がメッセージの他の部分を解析または解読する方法に影響を与える場合、その解析またはデコードの目的のために、実装はそれらのヘッダーフィールドに行われた一部またはすべての変更を無視する場合があります。たとえば、[ボディ]拡張をサポートする実装では、「ボディ」テストは、「コンテンツタイプ」または「コンテンツ転送エンコード」ヘッダーフィールドを削除または追加することで影響を受ける可能性があります。これは、これらのヘッダーフィールドの変更が直接テストに影響するという要件を取り消すことはありません。フィールドへの変更のセマンティックな副作用のみが無視される場合があります。
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」または「Keep」アクションのどれが実行され、どのアクションが無視されるかを選択するのは実装次第です。
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:
次のテンプレートは、このドキュメントで指定されたSIVE拡張のIANA登録を指定します。
To: iana@iana.org Subject: Registration of new Sieve extension
宛先：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説明：処理されているメッセージのヘッダーを変更するアクション「Addheader」と「DeleteHeader」を追加しますRFC番号：RFC 5293連絡先アドレス：SIVEディスカッションリスト<IETF-MTA-FILTERS＆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 editheader extension is explicitly prohibited to alter or delete Received header fields (i.e., it can't interfere with loop prevention).
これは、シーブエンジンによって処理されるメッセージの変更を可能にする標準化された最初のふるい拡張です。[Sieve]、Editheader拡張機能、および同じユーザーへのリダイレクトアクションで定義されたSieveテストを使用するふるいスクリプトは、同じメッセージの同じスクリプトの異なる呼び出しの間にある状態を維持できます。ただし、そのようなスクリプトを使用して無限のループを導入することはできないことに注意してください。各反復は新しい受信ヘッダーフィールドを追加するため、[SMTP]で説明されている電子メールループ防止は最終的にメッセージを送信します。受信したヘッダーフィールドを変更または削除することが明示的に禁止されています（つまり、ループ予防に干渉することはできません）。
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]のセクション5.5の「署名の署名」リストに含まれるヘッダーフィールドの変更（または削除/追加）の変更は、dkim署名を無効にする可能性があります。これには、ヘッダーフィールドの不在を保証する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.
EditheAder拡張機能は、[SMIME]または[OpenPGP]を使用して生成された[IMAIL]ヘッダーフィールド署名に直接影響しません。これらの署名スキームには、署名されたメッセージ/RFC822ボディパーツ内のヘッダーフィールドの個別のコピーが含まれるためです。ただし、ヘッダーフィールドの内側（署名）コピーと外側（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.
ヘッダーに基づいたユーザーのフィルター内の決定メカニズムは、ヘッダーのスプーフィングに対して脆弱です。たとえば、ユーザーが承認されたヘッダーまたはタグを追加した場合、悪意のある送信者はそのタグまたはヘッダー自身を追加する場合があります。これを守る1つの方法は、メッセージを処理する前に、そのようなヘッダーまたはスタンプを削除または名前変更することです。
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.
エリック・オールマン、サイラス・ダブー、マシュー・エルビー、ネッド・フリード、アルント・ガルブランドセン、キェティル・トーグリム・ホム、サイモン・ジョセフソン、ウィル・リー、ウィリアム・レイバーゾン、マーク・E・マレット、クリス・マークル、アレクシー・メルニコフ、ランドール・シュワンツ、アアロン・スウィン、大規模な修正と提案のためのランドワッカー。
[IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[imail] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Moore、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.
[Mimeparam] Freed、N。and K. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、RFC 2231、1997年11月。
[SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[Sieve] Guenther、P.、ed。、およびT. Showalter、ed。、「Sive：An Email Filtering Language」、RFC 5228、2008年1月。
[BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: Body Extension", RFC 5173, April 2008.
[Body] Degener、J。およびP. Guenther、「Sieve Emailフィルタリング：ボディエクステンション」、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] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J。、およびM. Thomas、「Domainkeys Idified Mail（DKIM）署名」、RFC 4871、2007年5月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[MDN] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
[MDN] Hansen、T.、ed。、およびG. Vaudreuil、ed。、「メッセージ処分通知」、RFC 3798、2004年5月。
[OPENPGP] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[OpenPGP] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「OpenPGPを使用したMime Security」、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.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[VACATION] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[休暇] Showalter、T。and N. Freed、ed。、「Sive Emailフィルタリング：休暇拡張」、RFC 5230、2008年1月。
Authors' Addresses
著者のアドレス
Jutta Degener 5245 College Ave, Suite #127 Oakland, CA 94618
Jutta Degener 5245 College Ave、Suite＃127 Oakland、CA 94618
EMail: jutta@pobox.com
Philip Guenther Sendmail, Inc. 6475 Christie Ave., Ste 350 Emeryville, CA 94608
Philip Guenther Sendmail、Inc。6475 Christie Ave.、STE 350 Emeryville、CA 94608
EMail: guenther@sendmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。