Network Working Group J. Degener
Request for Comments: 5173 P. Guenther
Updates: 5229 Sendmail, Inc.
Category: Standards Track April 2008
Sieve Email Filtering: Body 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 a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message.
この文書は、電子メールメッセージの本文内の1つのまたは複数の文字列の出現をテストする「ふるい」のメールフィルタリング言語のための新しいコマンドを定義します。
The "body" test checks for the occurrence of one or more strings in the body of an email message. Such a test was initially discussed for the [SIEVE] base document, but was subsequently removed because it was thought to be too costly to implement.
「本体」電子メールメッセージの本体内の1つ以上の文字列の出現のために試験をチェック。そのような試験は、最初に[SIEVE]ベース文書に関して説明したが、それを実現するにはあまりにも高価であると考えられたため、その後除去しました。
Nevertheless, several server vendors have implemented some form of the "body" test.
それにもかかわらず、いくつかのサーバー・ベンダーは、「身体」のテストのいくつかのフォームを実装しました。
This document reintroduces the "body" test as an extension, and specifies its syntax and semantics.
このドキュメントは、拡張子として「身体」のテストを再導入し、その構文とセマンティクスを指定します。
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 [SIEVE] Section 1.1, including the use of the "Usage:" label for the definition of text and tagged argument syntax.
テキストとタグ付き引数構文の定義のためのラベル：表記の規則は、「使用」の使用を含む[SIEVE]セクション1.1、のようです。
The rules for interpreting the grammar are defined in [SIEVE] and inherited by this specification. In particular, readers of this document are reminded that according to [SIEVE] Sections 2.6.2 and 2.6.3, optional arguments such as COMPARATOR and MATCH-TYPE can appear in any order.
文法を解釈するためのルールは、[SIEVE]で定義されており、本明細書に継承されます。具体的には、この文書の読者は、セクション2.6.2および2.6.3 [SIEVE]によれば、そのような比較器及びMATCH-TYPEなどのオプションの引数は任意の順序で現れることができることに留意されます。
The capability string associated with the extension defined in this document is "body".
この文書で定義された拡張子に関連付けられた機能文字列は「体」です。
Usage: "body" [COMPARATOR] [MATCH-TYPE] [BODY-TRANSFORM] <key-list: string-list>
使用法： "身体" [コンパレータ] [MATCH-TYPE] [BODY-TRANSFORM] <キーリスト：文字列のリスト>
The body test matches content in the body of an email message, that is, anything following the first empty line after the header. (The empty line itself, if present, is not considered to be part of the body.)
身体検査は、ヘッダの後の最初の空行以下のものである電子メールメッセージの本文の内容と一致します。 （空行自体は、存在する場合、身体の一部であるとは考えられません。）
The COMPARATOR and MATCH-TYPE keyword parameters are defined in [SIEVE]. As specified in Sections 2.7.1 and 2.7.3 of [SIEVE], the default COMPARATOR is "i;ascii-casemap" and the default MATCH-TYPE is ":is".
比較器及びMATCH-TYPEキーワードパラメータは[SIEVE]で定義されています。 「ある」、「ASCII-CASEMAP I」とデフォルトのマッチタイプは[SIEVE]のセクション2.7.1及び2.7.3で指定されるように、デフォルトの比較です。
The BODY-TRANSFORM is a keyword parameter that governs how a set of strings to be matched against are extracted from the body of the message. If a message consists of a header only, not followed by an empty line, then that set is empty and all "body" tests return false, including those that test for an empty string. (This is similar to how the "header" test always fails when the named header fields aren't present.) Otherwise, the transform must be followed as defined below in Section 5.
BODY-TRANSFORM合致させる文字列のセットは、メッセージの本文から抽出される方法を支配するキーワードパラメータです。メッセージはヘッダのみで構成されている場合、空行が続いていない、そのセットは空であり、すべての「本体」試験は、その空の文字列のためのテストのものを含む、falseを返します。第5節で以下に定義する（これは、指定されたヘッダフィールドが存在しないとき、「ヘッダ」テストは常に失敗した方法に似ている。）それ以外の場合、変換は従わなければなりません。
Note that the transformations defined here do *not* match against each line of the message independently, so the strings will usually contain CRLFs. How these can be matched is governed by the comparator and match-type. For example, with the default comparator of "i;ascii-casemap", they can be included literally in the key strings, or be matched with the "*" or "?" wildcards of the :matches match-type, or be skipped with :contains.
ここで定義された変換は、独立したメッセージの各行に対して*ない*試合を行うことに注意してくださいので、文字列は通常のCRLFが含まれています。どのようにこれらを一致させることができることは、比較器とのマッチタイプによって支配されています。たとえば、デフォルトのコンパレータで「私、ASCII-CASEMAP」、彼らは、キーの文字列に文字通り含めることができ、または「*」またはと一致します「？」ワイルドカード：マッチ型と一致する、またはでスキップさ：含まれています。
Prior to matching content in a message body, "transformations" can be applied that filter and decode certain parts of the body. These transformations are selected by a "BODY-TRANSFORM" keyword parameter.
メッセージ本文のコンテンツを照合する前に、「形質転換」とは、そのフィルタを適用し、身体の特定の部分を復号することができます。これらの変換は、「BODY-TRANSFORM」キーワードパラメータによって選択されています。
Usage: ":raw" / ":content" <content-types: string-list> / ":text"
使用法：「：生」/「：コンテンツ」<コンテンツの種類：文字列 - リスト> /「：テキスト」
The default transformation is :text.
デフォルトの変換は、次のとおりです。テキスト。
The ":raw" transform matches against the entire undecoded body of a message as a single item.
「：生の」単一の項目として、メッセージの全体デコードされていない身体に対する一致を変換します。
If the specified body-transform is ":raw", the [MIME] structure of the body is irrelevant. The implementation MUST NOT remove any transfer encoding from the message, MUST NOT refuse to filter messages with syntactic errors (unless the environment it is part of rejects them outright), and MUST treat multipart boundaries or the MIME headers of enclosed body parts as part of the content being matched against, instead of MIME structures to interpret.
指定されたボディの変換が「：生」、本体の[MIME]構造は無関係です。実装は、メッセージから任意の転送エンコーディングを削除してはなりません構文エラー（環境ない限り、それは完全にそれらを拒否する部分である）でメッセージをフィルタリングすることを拒否してはならない、との一部として、マルチパート境界や囲まれた体の部分のMIMEヘッダを扱わなければなりませんコンテンツが代わりに解釈するMIME構造から、と照合されています。
Example:
例：
require "body";
「身体」を必要とします。
# This will match a message containing the literal text # "MAKE MONEY FAST" in body parts (ignoring any # content-transfer-encodings) or MIME headers other than # the outermost RFC 2822 header.
＃これは、体の部分の「FASTお金を稼ぐ」リテラルテキスト＃を含むメッセージを一致する（無視する任意＃コンテンツ転送エンコーディング）または＃最外RFC 2822ヘッダー以外のMIMEヘッダ。
if body :raw :contains "MAKE MONEY FAST" { discard; }
生：「FASTお金を稼ぐ」{捨てる含まれています。体があれば}
If the body transform is ":content", the MIME parts that have the specified content types are matched against independently.
ボディは、変換した場合は「：コンテンツ」、指定したコンテンツタイプを持つMIMEパートを独立と照合されています。
If an individual content type begins or ends with a '/' (slash) or contains multiple slashes, then it matches no content types. Otherwise, if it contains a slash, then it specifies a full <type>/<subtype> pair, and matches only that specific content type. If it is the empty string, all MIME content types are matched. Otherwise, it specifies a <type> only, and any subtype of that type matches it.
個々のコンテンツタイプが開始または「/」（スラッシュ）で終わるか、複数のスラッシュが含まれている場合、それは何のコンテンツタイプと一致しません。それはスラッシュが含まれている場合はそうでない場合、それは完全な<タイプ> / <サブタイプ>のペアを指定し、その特定のコンテンツタイプと一致します。それは空の文字列である場合は、すべてのMIMEコンテンツタイプが一致しています。それ以外の場合は、<タイプ>のみを指定し、そのタイプの任意のサブタイプは、それに一致します。
The search for MIME parts matching the :content specification is recursive and automatically descends into multipart and message/rfc822 MIME parts. All MIME parts with matching types are searched for the key strings. The test returns true if any combination of a searched MIME part and key-list argument match.
MIMEの部品の検索が一致：コンテンツ仕様は再帰的であり、自動的にマルチパートとメッセージ/ RFC822のMIME部分に下降します。一致タイプを持つすべてのMIME部分は、キーの文字列で検索されています。テストでは、検索MIMEパートとキー・リストの引数の試合を任意に組み合わせた場合にtrueを返します。
If the :content specification matches a multipart MIME part, only the prologue and epilogue sections of the part will be searched for the key strings, treating the entire prologue and the entire epilogue as separate strings; the contents of nested parts are only searched if their respective types match the :content specification.
場合：コンテンツ仕様は、マルチパートMIME部分に一致する、パーツのみプロローグおよびエピローグのセクションでは、全体のプロローグと別の文字列として全体のエピローグを治療、キー文字列を検索します。コンテンツ仕様：それぞれの型が一致した場合、ネストされた部分の内容は検索されます。
If the :content specification matches a message/rfc822 MIME part, only the header of the nested message will be searched for the key strings, treating the header as a single string; the contents of the nested message body parts are only searched if their content type matches the :content specification.
場合：コンテンツ仕様は、メッセージ/ RFC822のMIME部分と一致する場合、ネストされたメッセージのヘッダだけが1つの文字列としてヘッダを治療、キー文字列を検索します。コンテンツ仕様：そのコンテンツタイプが一致した場合、ネストされたメッセージ本体部分の内容は検索されます。
For other MIME types, the entire part will be searched as a single string.
他のMIMEタイプについては、全体の一部には、1つの文字列として検索されます。
(Matches against container types with an empty match string can be useful as tests for the existence of such parts.)
（空の一致文字列を有する容器型の照合は、このような部品の存在についての試験として有用であり得ます。）
Example:
例：
From: Whomever
To: Someone
Date: Whenever
Subject: whatever
Content-Type: multipart/mixed; boundary=outer
& This is a multi-part message in MIME format. & --outer Content-Type: multipart/alternative; boundary=inner
＆これは、MIME形式のマルチパートメッセージです。 ＆--outerのContent-Type：マルチパート/代替;インナー=境界
& This is a nested multi-part message in MIME format. & --inner Content-Type: text/plain; charset="us-ascii"
＆これは、MIME形式のネストされたマルチパートメッセージです。 ＆--innerのContent-Type：text / plainの。文字セット= "US-ASCII"
$ Hello $ --inner Content-Type: text/html; charset="us-ascii"
$こんにちは$ --innerのContent-Type：text / htmlの。文字セット= "US-ASCII"
% <html><body>Hello</body></html> % --inner-- & & This is the end of the inner MIME multipart. & --outer Content-Type: message/rfc822
％<HTML> <BODY>こんにちは</ body> </ html>この％--inner--＆＆これは、内側のMIMEマルチパートの終わりです。 ＆--outerのContent-Type：メッセージ/ RFC822
! From: Someone Else ! Subject: hello request
！投稿者：他の誰か！件名：こんにちは要求
$ Please say Hello $ --outer-- & & This is the end of the outer MIME multipart.
$＆＆こんにちは$ --outer--を言うこれは、外側のMIMEマルチパートの終わりでください。
In the above example, the '&', '$', '%', and '!' characters at the start of a line are used to illustrate what portions of the example message are used in tests:
上記の例では、 '＆'、 '$'、 '％'、および '！'ラインの開始時の文字は、例えばメッセージの部分が試験に使用されているものを説明するために使用されます。
- the lines starting with '&' are the ones that are tested when a 'body :content "multipart" :contains "MIME"' test is executed.
- 「＆」で始まる行はテストされているものであり、テストが実行された「ボディ：コンテンツ 『マルチパート』 『MIME』が含まれて」。
- the lines starting with '$' are the ones that are tested when a 'body :content "text/plain" :contains "Hello"' test is executed.
テストが実行された「：コンテンツ 『text / plainの』 『こんにちは』が含ま体」 - 「$」で始まる行は、ときにテストされているものがあります。
- the lines starting with '%' are the ones that are tested when a 'body :content "text/html" :contains "Hello"' test is executed.
テストが実行された「：コンテンツ 『text / htmlの』 『こんにちは』が含ま体」 - 「％」で始まる行は、ときにテストされているものがあります。
- the lines starting with '$' or '%' are the ones that are tested when a 'body :content "text" :contains "Hello"' test is executed.
テストが実行された「：コンテンツ 『テキスト』 『こんにちは』が含ま体」 - 「$」や「％」で始まる行は、ときにテストされているものがあります。
- the lines starting with '!' are the ones that are tested when a 'body :content "message/rfc822" :contains "Hello"' test is executed.
- で始まる行「！」テストされているものであり、テストが実行された「：コンテンツ 『メッセージ/ RFC822』身体 『こんにちは』が含まれて」。
Comparisons are performed on octets. Implementations decode the content-transfer-encoding and convert text to [UTF-8] as input to the comparator. MIME parts that cannot be decoded and converted MAY be treated as plain US-ASCII, omitted, or processed according to local conventions. A NUL octet (character zero) SHOULD NOT cause early termination of the content being compared against. Implementations MUST support the "quoted-printable", "base64", "7bit", "8bit", and "binary" content transfer encodings. Implementations MUST be capable of converting to UTF-8 the US-ASCII, ISO-8859-1, and the US-ASCII subset of ISO-8859-* character sets.
比較はオクテット上で実行されています。実装では、コンテンツ転送エンコードをデコードし、コンパレータへの入力として[UTF-8]にテキストを変換します。復号化され、変換できないMIMEパートは、ローカル規則に従って、プレーンなUS-ASCIIとして扱われ、省略、または処理されてもよいです。 NULオクテット（文字ゼロ）と比較されているコンテンツの早期終了が発生することはありません。実装は、「quoted-printableの」、「BASE64」、「7ビット」、「8ビット」、および「バイナリ」コンテンツ転送エンコーディングをサポートしなければなりません。実装は、UTF-8 US-ASCII、ISO-8859-1、およびISO-8859- *文字セットのUS-ASCIIのサブセットに変換することができなければなりません。
Each matched part is matched against independently: search expressions MUST NOT match across MIME part boundaries. MIME headers of the containing part MUST NOT be included in the data.
各マッチした部分を独立に照合されます。検索式は、MIMEパートの境界を越えて一致してはなりません。収容部のMIMEヘッダがデータに含まれてはなりません。
Example:
例：
require ["body", "fileinto"];
[ "ボディ"、 "のfileinto"]を必要とします。
# Save any message with any text MIME part that contains the # words "missile" or "coordinates" in the "secrets" folder.
##ワード「ミサイル」や「秘密」フォルダ内の「座標」が含まれている任意のテキストMIME部分を持つ任意のメッセージを保存します。
if body :content "text" :contains ["missile", "coordinates"] { fileinto "secrets"; }
コンテンツ「テキスト」：「秘密」のfileinto [「ミサイル」、「座標」] {含み、本体があれば}
# Save any message with an audio/mp3 MIME part in # the "jukebox" folder.
##オーディオ/ mp3のMIMEパート「ジュークボックス」フォルダに任意のメッセージを保存します。
if body :content "audio/mp3" :contains "" { fileinto "jukebox"; }
もしボディ：コンテンツ「オーディオ/ mp3」：「」ジュークボックス「{のfileinto」が含まれています。 }
The ":text" body transform matches against the results of an implementation's best effort at extracting UTF-8 encoded text from a message.
「：テキスト」身体がメッセージからUTF-8でエンコードされたテキストを抽出することで、実装のベストエフォートの結果に対する一致を変換します。
It is unspecified whether this transformation results in a single string or multiple strings being matched against. All the text extracted from a given non-container MIME part MUST be in the same string.
この変換は、単一の文字列になる、または複数の文字列が照合されるかどうかは不定です。所与の非容器MIME部分から抽出されたすべてのテキストは、同じ文字列でなければなりません。
In simple implementations, :text MAY be treated the same as :content "text".
簡単な実装では、：コンテンツ「テキスト」：テキストと同じように処理することができます。
Sophisticated implementations MAY strip mark-up from the text prior to matching, and MAY convert media types other than text to text prior to matching.
洗練された実装では、前のマッチングにテキストからマークアップを取り除くことができ、前のマッチングにテキストにテキスト以外のメディアタイプを変換することができます。
(For example, they may be able to convert proprietary text editor formats to text or apply optical character recognition algorithms to image data.)
（例えば、それらは、テキストや画像データに光学文字認識アルゴリズムを適用する独自のテキストエディタフォーマットに変換することができるかもしれません。）
Example: require ["body", "fileinto"];
例：「本文」、「のfileinto」]を必要とします。
# Save messages mentioning the project schedule in the
# project/schedule folder.
if body :text :contains "project schedule" {
fileinto "project/schedule";
}
Any extension that extends the grammar for the COMPARATOR or MATCH-TYPE nonterminals will also affect the implementation of "body".
コンパレータまたはMATCH-TYPE非終端記号のための文法を拡張し、任意の拡張子は「体」の実現に影響を与えます。
Wildcard expressions used with "body" are exempt from the side effects described in [VARIABLES]. That is, they MUST NOT set match variables (${1}, ${2}...) to the input values corresponding to wildcard sequences in the matched pattern. However, if the extension is present, variable references in the key strings or content type strings are evaluated as described in this document.
「本体」で使用されるワイルドカード式は、[変数]に記載の副作用が免除されます。すなわち、それらが一致変数を設定してはいけません、である（$ {1}、$ {2} ...）マッチしたパターンにワイルドカードの配列に対応する入力値に。拡張子が存在する場合、この文書で説明したようにしかし、キーの文字列またはコンテンツタイプの文字列内の変数の参照が評価されます。
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: body Description: Provides a test for matching against the body of the message being processed RFC number: RFC 5173 Contact Address: The Sieve discussion list <ietf-mta-filters@imc.org>
能力名：体説明：メッセージ処理されているRFC番号のボディに対してマッチングするためのテストを提供します：RFC 5173問い合わせ先：ふるいディスカッションリスト<ietf-mta-filters@imc.org>
The system MUST be sized and restricted in such a manner that even malicious use of body matching does not deny service to other users of the host system.
システムは、大きさと体のマッチングのも、悪意の使用は、ホストシステムの他のユーザーにサービスを否定するものではないように制限しなければなりません。
Filters relying on string matches in the raw body of an email message may be more general than intended. Text matches are no replacement for a spam, virus, or other security related filtering system.
電子メールメッセージの生の身体内の文字列の一致に依存するフィルタは、意図したよりも、より一般的かもしれません。テキストマッチは、スパム、ウイルス、またはその他のセキュリティ関連のフィルタリングシステムのための代替ではありません。
This document has been revised in part based on comments and discussions that took place on and off the SIEVE mailing list. Thanks to Cyrus Daboo, Ned Freed, Bob Johannessen, Simon Josefsson, Mark E. Mallett, Chris Markle, Alexey Melnikov, Ken Murchison, Greg Shapiro, Tim Showalter, Nigel Swinson, Dowson Tong, and Christian Vogt for reviews and suggestions.
この文書では、SIEVEメーリングリストのオンとオフ行われたコメントや議論に基づいて、一部に改訂されました。レビューや提案のためのCyrus Daboo、ネッドフリード、ボブJohannessenの、サイモンJosefsson氏、マーク・E.マレット、クリス・マークル、アレクセイ・メルニコフ、ケンマーチソン、グレッグ・シャピロ、ティム・ショーウォルター監督、ナイジェルSwinson、Dowsonトン、そしてキリスト教のフォークトに感謝します。
[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月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]ギュンター、P.、エド、およびT.ショーウォルター監督、エド、 "ふるい：メールフィルタリング言語"。。、RFC 5228、2008年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[変数]オム、K.、 "ふるいメールフィルタリング：変数の拡張"、RFC 5229、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. 6425 Christie Ave, 4th Floor Emeryville, CA 94608
フィリップ・ギュンターのSendmail社6425クリスティアベニュー、4階エメリービル、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に情報を記述してください。