[要約] RFC 5173は、Sieveメールフィルタリングの拡張であるBody Extensionについての仕様を定めています。このRFCの目的は、Sieveスクリプトでメールの本文をフィルタリングするための新しい機能を提供することです。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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によれば、Comparatorや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>
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".
コンパレータとマッチタイプのキーワードパラメーターは、[ふるい]で定義されています。[Sieve]のセクション2.7.1および2.7.3で指定されているように、デフォルトのコンパレータは「i; ascii-casemap」であり、デフォルトのマッチタイプは「：is」です。
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.
ボディトランスフォームは、メッセージの本体から一致する一致する文字列のセットがどのように抽出されるかを支配するキーワードパラメーターです。メッセージがヘッダーのみで構成されている場合、空の行が続くことなく、そのセットは空であり、すべての「ボディ」テストは、空の文字列をテストするものを含めて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が含まれます。これらをどのように一致させることができるかは、コンパレータとマッチタイプによって支配されます。たとえば、「i; ascii-casemap」のデフォルトのコンパレーターでは、文字通りキー文字列に含めるか、「*」または「？」と一致させることができます。ワイルドカード：マッチタイプのマッチング、またはスキップ：contains。
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.
メッセージ本文でコンテンツを一致させる前に、ボディの特定の部分をフィルタリングおよびデコードする「変換」を適用できます。これらの変換は、「ボディトランスフォーム」キーワードパラメーターによって選択されます。
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.
「：raw」変換は、単一のアイテムとしてメッセージのゼロードされていないボディ全体と一致します。
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.
指定されたボディトランスフォームが「：raw」の場合、体の[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.
＃これは、文字通りのテキスト＃を含むメッセージと一致します＃ボディパート（＃コンテンツ転送エンコードを無視する）または＃以外のMIMEヘッダーは、最も外側のRFC 2822ヘッダー以外のMIMEヘッダーです。
if body :raw :contains "MAKE MONEY FAST" {
discard;
}
If the body transform is ":content", the MIME parts that have the specified content types are matched against independently.
ボディ変換が「：コンテンツ」である場合、指定されたコンテンツタイプを持つマイムパーツは独立して一致します。
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.
個々のコンテンツタイプが「/」（スラッシュ）で開始または終了するか、複数のスラッシュを含む場合、コンテンツタイプは一致しません。それ以外の場合、スラッシュが含まれている場合、完全な<type>/<subtype>ペアを指定し、その特定のコンテンツタイプのみに一致させます。空の文字列の場合、すべてのMIMEコンテンツタイプが一致します。それ以外の場合は、A <type>のみを指定し、そのタイプのサブタイプはそれと一致します。
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.
以下のマイムパーツの検索は、以下を一致させるものであり、コンテンツ仕様は再帰的であり、自動的にマルチパートとメッセージ/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パーツと一致する場合、ネストされたメッセージのヘッダーのみがキー文字列を検索し、ヘッダーを単一の文字列として扱います。ネストされたメッセージ本体の部分の内容は、コンテンツタイプが以下と一致する場合にのみ検索されます。コンテンツ仕様。
For other MIME types, the entire part will be searched as a single string.
他のMIMEタイプの場合、部品全体が単一の文字列として検索されます。
(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：MultiPart/Alternative;境界=内
& This is a nested multi-part message in MIME format. & --inner Content-Type: text/plain; charset="us-ascii"
＆これは、MIME形式のネストされたマルチパートメッセージです。＆ - Inner Content-Type：Text/Plain;charset = "us-ascii"
$ Hello $ --inner Content-Type: text/html; charset="us-ascii"
$ hello $ - inner content-type：text/html;charset = "us-ascii"
% <html><body>Hello</body></html>
%
--inner--
&
& This is the end of the inner MIME multipart.
&
--outer
Content-Type: message/rfc822
! From: Someone Else
! Subject: hello request
$ Please say Hello $ --outer-- & & This is the end of the outer MIME multipart.
$ hello $ -outer-＆＆これは外側のマイムマルチパートの終わりです。
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.
- 「$」から始まる行は、「ボディ：コンテンツ「テキスト/プレーン」：「hello」 'テストが実行されるときにテストされる行です。
- the lines starting with '%' are the ones that are tested when a 'body :content "text/html" :contains "Hello"' test is executed.
- 「％」で始まる行は、「ボディ：コンテンツ「テキスト/html」：「hello」」テストが実行されたときにテストされた行です。
- the lines starting with '$' or '%' are the ones that are tested when a 'body :content "text" :contains "Hello"' test is executed.
- 「$」または「％」で始まる行は、「body：content "text"：contains "hello" 'テストが実行されたときにテストされた行です。
- the lines starting with '!' are the ones that are tested when a 'body :content "message/rfc822" :contains "Hello"' test is executed.
- 「！」で始まる線は「body：content "message/rfc822"：contas "hello" 'テストが実行されたときにテストされたものです。
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部品は、現地規則に従って、単純な米国ASCIIとして扱われたり、省略したり、処理されたりすることができます。Nul Octet（文字ゼロ）は、コンテンツの早期終了を引き起こすことはありません。実装は、「引用された印刷可能」、「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"];
["body"、 "fileinto"]を必要とします。
# Save any message with any text MIME part that contains the # words "missile" or "coordinates" in the "secrets" folder.
＃「Secrets」フォルダーに＃単語「ミサイル」または「座標」を含むテキストMIMEパーツでメッセージを保存します。
if body :content "text" :contains ["missile", "coordinates"] {
fileinto "secrets";
}
# Save any message with an audio/mp3 MIME part in # the "jukebox" folder.
＃＃ "Jukebox"フォルダーにAudio/mp3 Mimeパーツを使用してメッセージを保存します。
if body :content "audio/mp3" :contains "" {
fileinto "jukebox";
}
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"];
例：["body"、 "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".
コンパレータまたはマッチタイプの非ターミナルの文法を拡張する拡張機能も、「ボディ」の実装に影響します。
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:
次のテンプレートは、このドキュメントで指定されたSIVE拡張のIANA登録を指定します。
To: iana@iana.org Subject: Registration of new Sieve extension
宛先：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.
このドキュメントは、ふるいメーリングリストの内外で行われたコメントと議論に基づいて部分的に改訂されています。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、Christian Vogtのレビューと提案のおかげで。
[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月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年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月。
[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.
[変数] Homme、K。、「Sieve Emailフィルタリング：変数拡張」、RFC 5229、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. 6425 Christie Ave, 4th Floor Emeryville, CA 94608
Philip Guenther Sendmail、Inc。6425 Christie Ave、4th Floor 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への情報をお問い合わせください。