[要約] RFC 9078は、メッセージに対する要約反応を示すための仕様です。コミュニケーションの効率化を目的とし、電子メールやメッセージングプラットフォームでの利用が想定されています。
Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 9078 Brandenburg InternetWorking
Category: Experimental R. Signes
ISSN: 2070-1721 Fastmail
N. Freed
Oracle
August 2021
Reaction: Indicating Summary Reaction to a Message
反応：メッセージへの要約反応を示す
Abstract
概要
The popularity of social media has led to user comfort with easily signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic. This specification permits a similar facility for Internet Mail.
ソーシャルメディアの人気は、「親指」または「スマイリー」グラフィックのように、著者の投稿に対する基本的な反応を簡単にシグナリングすることで、ユーザーの快適さをもたらしました。この仕様では、インターネットメールの同様の機能が可能になります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9078.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9078で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Reaction Content-Disposition
4. Reaction Message Processing
5. Usability Considerations
5.1. Example Message
5.2. Example Display
6. Security Considerations
7. IANA Considerations
8. Experimental Goals
9. Normative References
Acknowledgements
Authors' Addresses
The popularity of social media has led to user comfort with easily signaling summary reactions to an author's posting, by using emoji graphics, such as with a 'thumbs up', 'heart', or 'smiley' indication. Sometimes the permitted repertoire is constrained to a small set, and sometimes a more extensive range of indicators is supported.
ソーシャルメディアの人気は、「親指」、「心」、または「スマイリー」の指示を使用して、絵文字グラフィックスを使用することによって、著者の投稿に対する概要反応を簡単にシグナリングすることで、ユーザーの快適さをもたらしました。許可されたレパートリーが小さなセットに制約されることがあり、時にはより広範な範囲のインジケータがサポートされていることがあります。
This specification extends this existing practice in social media and instant messaging into Internet Mail.
この仕様は、この既存の慣行をソーシャルメディアおよびインスタントメッセージングでインターネットメールに拡張します。
While it is already possible to include symbols and graphics as part of an email reply's content, there has not been an established means of signaling the semantic substance that such data are to be taken as a summary 'reaction' to the original message -- that is, a mechanism to identify symbols as specifically providing a summary reaction to the cited message rather than merely being part of the free text in the body of a response. Such a structured use of the symbol(s) allows recipient Mail User Agents (MUAs) to correlate this reaction to the original message and possibly to display the information distinctively.
電子メール返信の内容の一部としてシンボルやグラフィックを含めることはすでに可能ですが、そのようなデータを元のメッセージに要約 '反応」と見なされるべき意味の物質をシグナリングするための確立された手段はありませんでした - は、対応の身体内のフリーテキストの一部であるのではなく、引用されたメッセージに概要反応を提供するようにシンボルを識別するメカニズムです。シンボルの構造化された使用は、受信者メールユーザエージェント（MUAS）がこの反応を元のメッセージに相関させ、場合によってはその情報を明確に表示することを可能にする。
This facility defines a new MIME Content-Disposition, to be used in conjunction with the In-Reply-To header field, to specify that a part of a message containing one or more emojis can be treated as a summary reaction to a previous message.
この機能は、1つ以上のEMOJISを含むメッセージの一部を前のメッセージに対する要約反応として扱うことができることを指定するために、「In-Reply-To Header」フィールドと組み合わせて使用する新しいMIMEコンテンツ配置を定義します。
Unless provided here, terminology, architecture, and specification notation used in this document are incorporated from:
ここで提供されない限り、この文書で使用されている用語、アーキテクチャ、および仕様表記は以下から組み込まれています。
* [Mail-Arch]
* [メールアーチ]
* [Mail-Fmt]
* [Mail-FMT]
* [MIME]
* [マイム]
Syntax is specified with
構文を指定します
* [ABNF]
* [ABNF]
The ABNF rule emoji-sequence is inherited from [Emoji-Seq]; details are in Section 3.
ABNF規則Emoji-Sequenceは[Emoji-Seq]から継承されます。詳細はセクション3にあります。
Normative language, per [RFC2119] and [RFC8174]:
[RFC2119]と[RFC8174]ごとの規範的な言語：
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A message sent as a reply MAY include a part containing:
返信として送信されたメッセージは、以下の部分を含むことができる。
Content-Disposition: reaction
含有量の配置：反応
If such a field is specified, the Content-Type of the part MUST be:
そのようなフィールドが指定されている場合、その部分のコンテンツタイプは次のようにしてください。
Content-Type: text/plain; charset=utf-8
The content of this part is restricted to a single line of emoji. The [ABNF] is:
この部分の内容は、絵文字の単一行に制限されています。[ABNF]は次のとおりです。
part-content = emoji *(WSP emoji) CRLF
パートコンテンツ=絵文字*（WSP絵文字）CRLF
emoji = emoji-sequence
emoji-sequence = { defined in [Emoji-Seq] }
base-emojis = thumbs-up / thumbs-down / grinning-face /
frowning-face / crying-face
; Basic set of emojis, drawn from [Emoji-Seq]
; thumbs-up = {U+1F44D}
; thumbs-down = {U+1F44E}
; grinning-face = {U+1F600}
; frowning-face = {U+2639}
; crying-face = {U+1F622}
The part-content is either the message's single MIME body or the content portion of the first MIME multipart body part.
部品内容は、メッセージの単一のMIME本体または最初のMIMEマルチパート本体部分の内容部分のいずれかです。
The ABNF rule emoji-sequence is inherited from [Emoji-Seq]. It defines a set of Unicode code point sequences, which must then be encoded as UTF-8. Each sequence forms a single pictograph. The BNF syntax used in [Emoji-Seq] differs from [ABNF] and MUST be interpreted as used in Unicode documentation. The referenced document describes these as sequences of code points.
ABNF規則Emoji-Sequenceは[Emoji-Seq]から継承されます。それは一組のUnicodeコードポイントシーケンスを定義し、それはUTF-8としてエンコードされなければならない。各シーケンスは単一の絵文字を形成します。[Emoji-Seq]で使用されているBNF構文は[ABNF]とは異なり、Unicodeのマニュアルで使用されていると解釈する必要があります。参照されている文書は、これらをコードポイントのシーケンスとして説明しています。
Note: The part-content can first be parsed into candidate reactions, separated by WSP. Each candidate reaction that does not constitute a single emoji-sequence (as per [Emoji-Seq]) is invalid. Invalid candidates can be treated individually, rather than affecting the remainder of the part-content's processing. The remaining candidates form the set of reactions to be processed. This approach assumes use of a mechanism for emoji sequence validation that is not specified here.
注：部分内容は、まずWSPで区切られた候補反応に解析することができます。単一の絵文字配列を構成しない各候補反応（Emoji-SEQ）は無効です。部分コンテンツの処理の残りの部分に影響を与えるのではなく、無効な候補を個別に扱うことができます。残りの候補は、処理されるべき反応のセットを形成する。このアプローチは、ここで指定されていないemojiシーケンス検証のためのメカニズムの使用を想定しています。
The rule base-emojis is provided as a simple, common list, or 'vocabulary' of emojis. It was developed from some existing practice in social networking and is intended for similar use. However, support for it as a base vocabulary is not required. Having providers and consumers employ a common set will facilitate user interoperability, but different sets of users might want to have different, common (shared) sets.
Rule Base-Emojisは、Emojisのシンプルで一般的なリスト、または「語彙」として提供されています。それはソーシャルネットワーキングにおける既存の慣習から開発され、そして同様の使用を目的としています。ただし、基本語彙としてのサポートは不要です。プロバイダーとコンシューマを使用する共通のセットを使用すると、ユーザーの相互運用性が向上しますが、異なるユーザーセットは異なる、一般的な（共有）セットを持つことをお勧めします。
The reaction emoji or emojis are linked to the current message's In-Reply-To field, which references an earlier message and provides a summary reaction to that earlier message [Mail-Fmt]. For processing details, see Section 4.
反応EmojiまたはEmojisは、現在のメッセージのIn-Reply-Toフィールドにリンクされており、これは以前のメッセージを参照し、その前のメッセージ[Mail-FMT]に要約反応を提供します。処理の詳細については、セクション4を参照してください。
Reference to unallocated code points SHOULD NOT be treated as an error; the corresponding UTF-8-encoded code points SHOULD be processed using the system default method for denoting an unallocated or undisplayable code point.
未割り当てコードポイントへの参照はエラーとして扱われるべきではありません。対応するUTF-8エンコードコードポイントは、未割り当てまたは未割り当てのコードポイントを示すためのシステムのデフォルトメソッドを使用して処理されます。
Note: The "emoji" token looks simple. It isn't. Implementers are well advised not to assume that emoji sequences are trivial to parse or validate. Among other concerns, an implementation of the Unicode Character Database is required. An emoji is more than a stand-in for a simple alternation of characters. Similarly, one emoji sequence is not interchangeable with, or equivalent to, another one, and comparisons require detailed understanding of the relevant Unicode mechanisms. Use of an existing Unicode implementation will typically prove extremely helpful, as will an understanding of the error modes that may arise with a chosen implementation.
注：「絵文字」トークンは簡単に見えます。そうではありません。実装者は、絵文字シーケンスが解析または検証に些細なことを想定しないことをよくお勧めします。他の懸念の中でも、Unicode文字データベースの実装が必要です。絵文字は、文字の簡単な交代のためのスタンド以上のものです。同様に、1つの絵文字シーケンスは別のものと交換可能ではなく、別のものと同等であり、比較は関連するUnicodeメカニズムの詳細な理解を必要とする。選択された実装で発生する可能性があるエラーモードを理解するように、既存のUnicode実装の使用は通常非常に役立ちます。
The presentation aspects of reaction processing are necessarily MUA specific and beyond the scope of this specification. In terms of the message itself, a recipient MUA that supports this mechanism operates as follows:
反応処理の提示面は必然的にMUA特異的であり、この仕様の範囲を超えている。メッセージ自体の面では、このメカニズムをサポートする受信者MUAは次のように動作します。
1. If a received message R's header contains an In-Reply-To field, check to see if it references a previous message that the MUA has sent or received.
1. 受信したメッセージRのヘッダーにin-reply-toフィールドが含まれている場合は、MUAが送受信した前のメッセージを参照するかどうかを確認します。
2. If R's In-Reply-To: does reference one, then check R's message content for a part with a "reaction" Content-Disposition header field, at either the outermost level or as part of a multipart at the outermost level.
2. REPLY-TO（REPLY）が参照している場合は、最外レベルで、または最も外側のレベルでのマルチパートの一部として、「反応」コンテンツディスプライスヘッダーフィールドを持つ部分のRのメッセージコンテンツを確認してください。
3. If such a part is found and the content of the part conforms to the restrictions outlined above, remove the part from the message and process the part as a reaction.
3. そのような部分が見つからず、その部分の内容が上記の制限に準拠している場合は、メッセージから部分を取り外し、その部分を反応として処理します。
Note: A message's content might include other, nested messages. These can be analyzed for reactions, independently of the containing message, applying the above algorithm for each contained message, separately.
注：メッセージの内容には、他のネストされたメッセージが含まれる場合があります。これらは、収容メッセージとは無関係に、それぞれの含有メッセージに対して上記のアルゴリズムを別々に適用するために、反応について分析することができる。
Again, the handling of a message that has been successfully processed is MUA specific and beyond the scope of this specification.
繰り返しますが、正常に処理されたメッセージの処理は、MUA固有のものであり、この仕様の範囲を超えています。
This specification defines a mechanism for the structuring and carriage of information. It does not define any user-level details of use. However, the design of the user-level mechanisms associated with this facility is paramount. This section discusses some issues to consider.
この仕様は、情報の構造化および搬送のためのメカニズムを定義しています。ユーザーレベルの使用の詳細を定義しません。ただし、この機能に関連するユーザーレベルのメカニズムの設計は最優先です。このセクションでは、考慮すべきいくつかの問題について説明します。
Creation: Because an email environment is different from a typical social media platform, there are significant -- and potentially challenging -- choices in the design of the user interface, to support indication of a reaction. Is the reaction to be sent only to the original author, or should it be sent to all recipients? Should the reaction always be sent in a discrete message containing only the reaction, or should the user also be able to include other message content? (Note that carriage of the reaction in a normal email message enables inclusion of this other content.)
作成：電子メール環境は典型的なソーシャルメディアプラットフォームとは異なるため、反応の指示をサポートするための、ユーザーインターフェースの設計には重要で挑戦的な選択肢があります。元の作者にのみ送信される反応は、またはそれがすべての受信者に送信されるべきですか？反応のみを含むディスクリートメッセージで反応を常に送信する場合、またはユーザーが他のメッセージコンテンツを含めることができるはずですか？（通常の電子メールメッセージでの反応の送料は、この他のコンテンツを含めることを可能にします。）
Display: Reaction indications might be more useful when displayed in close visual proximity to the original message, rather than merely as part of an email response thread. The handling of multiple reactions, from the same person, is also an opportunity for making a user experience design choice that could be interesting.
表示：単に電子メールの応答スレッドの一部としてではなく、元のメッセージへの視覚的な視覚的な近さで表示されている場合、反応の表示はより便利な場合があります。同じ人からの複数の反応の処理もまた、興味深い可能性があるユーザーエクスペリエンスデザイン選択をする機会です。
Culture: The use of an image, intended to serve as a semantic signal, is determined and affected by cultural factors, which differ in complexity and nuance. It is important to remain aware that an author's intent when sending a particular emoji might not match how the recipient interprets it. Even simple, commonly used emojis can be subject to these cultural differences.
文化：意味信号として機能することを意図した画像の使用は、複雑さとニュアンスが異なる文化的要因によって決定され影響を受ける。特定の絵文字を送るときの著者の意図が受領者がどのように解釈するのか一致しないかもしれないことを知っていることは重要です。単純で、一般的に使用されるEmojisはこれらの文化的な違いの対象となる可能性があります。
A simple message exchange might be:
単純なメッセージ交換は次のとおりです。
To: recipient@example.org
From: author@example.com
Date: Today, 29 February 2021 00:00:00 -800
Message-ID: 12345@example.com
Subject: Meeting
Can we chat at 1pm pacific, today?
今日、太平洋毎にチャットできますか？
with a thumbs-up, affirmative response of:
親指を立て、次の肯定的な反応
To: author@example.com
From: recipient@example.org
Date: Today, 29 February 2021 00:00:10 -800
Message-ID: 56789@example.org
In-Reply-To: 12345@example.com
Subject: Meeting
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8
Content-Disposition: reaction
{U+1F44D}
The Unicode character, represented here as "{U+1F44D}" for readability, would actually be sent as the UTF-8-encoded character.
読みやすさのために、ここで表されるUnicode文字は、実際にはUTF-8エンコードされた文字として送信されます。
The example could, of course, be more elaborate, such as the first of a MIME multipart sequence.
この例は、もちろん、MIMEマルチパートシーケンスの最初のものなど、より複雑なものになる可能性があります。
Repeating the caution that actual use of this capability requires careful usability design and testing, this section describes simple examples -- which have not been tested -- of how the reaction response might be displayed in a summary list of messages:
注意を繰り返すこの機能の実際の使用には慎重な使いやすさ設計とテストが必要な場合は、このセクションではテストされていない単純な例 - メッセージの要約リストに表示されている可能性があります。
Summary: Summary listings of messages in a folder include columns such as Subject, From, and Date. Another might be added to show common reactions and a count of how many of them have been received.
概要：フォルダ内のメッセージの要約リストには、件名、From、Dateなどの列が含まれています。一般的な反応を示すために別のものが追加され、それらのうちの数の数の数が追加されるかもしれません。
Message: A complete message is often displayed with a tailored section for header fields, enhancing the format and showing only selected header fields. A pseudo-field might be added for reactions, again showing the symbol and a count.
メッセージ：完全なメッセージは、ヘッダーフィールドのためのテーラードセクションで表示され、フォーマットを強化し、選択したヘッダーフィールドのみを表示します。疑似フィールドを反応のために追加することができ、またシンボルとカウントを表示します。
This specification employs message content that is a strict subset of existing possible content and thus introduces no new content-specific security considerations. The fact that this content is structured might seem to make it a new threat surface, but there is no analysis demonstrating that it does.
この仕様は、既存の可能なコンテンツの厳密なサブセットであるメッセージコンテンツを採用し、したがって、新しいコンテンツ固有のセキュリティ上の考慮事項を導入しません。このコンテンツが構造化されているという事実はそれを新しい脅威の表面にするように思われるかもしれませんが、それがそうであることを示す分析はありません。
This specification defines a distinct Content-Disposition value for specialized message content. Processing that handles the content differently from other content in the message body might introduce vulnerabilities. Since this capability is likely to produce new user interaction features, that might also produce new social engineering vulnerabilities.
この仕様は、特殊なメッセージコンテンツのための異なるコンテンツ配置値を定義します。メッセージ本文の他のコンテンツとは異なるコンテンツを処理する処理は脆弱性を導入する可能性があります。この機能は新しいユーザーインタラクション機能を生み出す可能性があるため、新しいソーシャルエンジニアリングの脆弱性も生み出す可能性があります。
IANA has registered the Reaction MIME Content-Disposition parameter, per [RFC2183].
IANAは、[RFC2183]ごとに反応MIMEの含有配置パラメータを登録しています。
Content-Disposition parameter name: reaction
コンテンツ配置パラメータ名：反応
Allowable values for this parameter: (none)
このパラメータの許容値:(なし）
Description: Permit a recipient to respond by signaling basic reactions to an author's posting, such as with a 'thumbs up' or 'smiley' graphic
説明：「親指」または「スマイリー」グラフィックなど、著者の投稿に基本的な反応をシグナリングすることによって受信者が対応することを許可します。
The basic, email-specific mechanics for this capability are well established and well understood. Points of concern, therefore, are:
この機能のための基本的な電子メール固有の力学は、確立され、よく理解されています。したがって、懸念点は次のとおりです。
* Technical issues in using emojis within a message body
* メッセージボディの中でEmojisを使用する際の技術的な問題
* Market interest
* 市場の興味
* Usability
* 使いやすさ
So the questions to answer for this Experimental specification are:
そのため、この実験的仕様に答える質問は次のとおりです。
* Is there demonstrated interest by MUA developers?
* MUA開発者による興味がありますか？
* If MUA developers add this capability, is it used by authors?
* MUA開発者がこの機能を追加した場合、それは作者によって使用されますか？
* Does the presence of the Reaction capability create any operational problems for recipients?
* 反応能力の存在は受信者にとっての操作上の問題を生み出すのか？
* Does the presence of the Reaction capability demonstrate additional security issues?
* 反応能力の存在は追加のセキュリティ問題を示していますか？
* What specific changes to the specification are needed?
* 仕様に対する特定の特定の変更が必要ですか？
* What other comments will aid in use of this mechanism?
* このメカニズムの使用を支援する他にどのようなコメントがありますか？
Please send comments to ietf-822@ietf.org.
ietf-822@ietf.orgにコメントを送ってください。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[ABNF] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[Emoji-Seq] Davis, M., Ed. and P. Edberg, Ed., "Unicode Technical Standard #51: Unicode Emoji", September 2020, <https://www.unicode.org/reports/ tr51/#def_emoji_sequence>.
[Emoji-SEQ]デイビス、M.、ED。P. Edberg、Ed。、「Unicode Technical Standard＃51：Unicode Emoji」、2020年9月、<https：//www.unicode.org/reports/tr51 /＃def_emo_sequence>。
[Mail-Arch] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>.
[Mail-Arch] Crocker、D.、「インターネットメールアーキテクチャ」、RFC 5598、DOI 10.17487 / RFC5598、2009年7月、<https://www.rfc-editor.org/info/rfc5598>。
[Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[Mail-FMT] Resnick、P.、Ed。、「インターネットメッセージフォーマット」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https：//www.rfc-editor.org/info/rfc5322>。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[MIME] Freed、N.およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）パート1：インターネットメッセージボディのフォーマット」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<https：///www.rfc-editor.org/info/rfc2045>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, <https://www.rfc-editor.org/info/rfc2183>.
[RFC2183] Troost、R.、Dorner、S.、K. Moore、ED。、「インターネットメッセージ内のプレゼンテーション情報の通信：コンテンツ配置ヘッダーフィールド」、RFC 2183、DOI 10.17487 / RFC2183、1997年8月、<HTTPS///www.rfc-editor.org/info/rfc2183>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
Acknowledgements
謝辞
This specification had substantive commentary on three IETF mailing lists.
この仕様は、3つのIETFメーリングリストで実質的な解説を持っていました。
This work began as a private exercise, in July 2020, with private discussion, for draft-crocker-reply-emoji. It morphed into draft-crocker-inreply-react, with significant discussion on the ietf-822 mailing list <https://www.ietf.org/mailman/listinfo/ietf-822>, September through November 2020. The discussion produced a fundamental change from proposing a new header field to instead defining a new Content-Disposition type, as well as significantly enhancing its text concerning Unicode. It also produced two additional coauthors.
この作品は、2020年7月、ドラフトCROCKER-REPLYE-Emojiのためのプライベートディスカッションで民間演習として始まりました。Draft-Crocker-Inreply-Reactにモーフィングされ、IETF-822メーリングリスト<https://www.ietf.org/mailman/listinfo/ietf-822>、2020年11月から2020年11月までに議論しました。基本的な変更は、新しいコンテンツ配置タイプを定義するだけでなく、Unicodeに関するテキストを大幅に向上させるだけでなく、新しいヘッダフィールドを提案することからの変化。それはまた2つの追加のCoAuthorsを製造しました。
In November 2020, the Dispatch mailing list <https://www.ietf.org/mailman/listinfo/dispatch> was queried about the draft, but it produced no discussion, though it did garner one statement of interest.
2020年11月、ディスパッチメーリングリスト<https：//www.ietf.org/mailman/listinfo/dispatch>はドラフトについて照会されましたが、それは議事態様は興味のある声明を得ていましたが、議論は行われませんでした。
A 4-week Last Call was issued on this document, January 2021, resulting in quite a bit of fresh discussion on the last-call mailing list <https://www.ietf.org/mailman/listinfo/last-call> and producing further changes to this document. After Last Call completed, additional concerns regarding the Unicode-related details surfaced, producing yet more changes to the document. It also produced a challenge that prompted the current version of this Acknowledgements section.
このドキュメントで4週間の最後の通話が2021年1月に発行され、最後のコールメーリングリスト<https：//www.ietf.org/mailman/listinfo/last-call>ではかなりの新鮮なディスカッションが行われました。この文書にさらに変更を加えます。最後のコールが完了した後、Unicode関連の詳細に関する追加の懸念は、文書にさらに変更を加えています。また、この確認応答セクションの現在のバージョンを促した課題を作成しました。
Readers who are interested in the details of the document's history are encouraged to peruse the archives for the three lists, searching Subject fields for "react".
文書の履歴の詳細に興味を持っている読者は、3つのリストのアーカイブを熟読し、「React」のサブジェクトフィールドを検索することをお勧めします。
Authors' Addresses
著者の住所
Dave Crocker Brandenburg InternetWorking
Dave Crocker Brandenburgインターネットワーキング
Email: dcrocker@bbiw.net
Ricardo Signes Fastmail
RicardoはFastMailに署名します
Email: rjbs@semiotic.systems
Ned Freed Oracle
NED FREED Oracle
Email: ned.freed@mrochek.com