idnits 2.17.1 draft-crocker-inreply-react-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 97: '... sent as a reply MAY indicate the resp...' RFC 2119 keyword, line 115: '... recipient, the the responding MUA MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 14, 2020) is 1318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Informational September 14, 2020 5 Expires: March 18, 2021 7 React: Indicating Summary Reaction to a Message 8 draft-crocker-inreply-react-00 10 Abstract 12 The popularity of social media has led to user comfort with easily 13 signaling basic reactions to an author's posting, such as with a 14 'thumbs up' or 'smiley' graphic indication. This specification 15 permits a similar facility for Internet Mail. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 18, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. In-Reply-React . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Usability Considerations . . . . . . . . . . . . . . . . . . 3 54 4. Possible Issues . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 7.2. Informative References . . . . . . . . . . . . . . . . . 4 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 The popularity of social media has led to user comfort with easily 65 signaling summary reactions to an author's posting, by marking basic 66 emoji graphics, such as with a 'thumbs up', 'heart', or 'smiley' 67 indication. Sometimes the permitted repertoire is constrained to a 68 small set and sometimes a more extensive range of indicators is 69 supported. 71 This specification defines a similar facility for Internet Mail. 73 While it is already possible to include symbols and graphics as part 74 of an email reply's content, there has not been an established means 75 of signalling the semantic substance that such data are to be taken 76 as a summary 'reaction' to the original message. That is, a 77 mechanism to identify symbols as specifically providing a summary 78 reaction to the cited message, rather than merely being part of the 79 free text in the body of a response. Such a structured use of the 80 symbol(s) allows recipient MUAs to correlate this reaction to the 81 original message and possibly to display the information 82 distinctively. 84 This facility defines a header field, to be used in junction with the 85 In-Reply-To header field, to link one or more emojis as a summary 86 reaction to a previous message. 88 Unless provided here, terminology, architecture and specification 89 used in this document are incorporated from [Mail-Arch], [Mail-Fmt] 90 and [ABNF]. 92 Discussion of this specification should take place on the ietf- 93 822@ietf.org mailing list. 95 2. In-Reply-React 97 A message sent as a reply MAY indicate the responder's summary 98 reaction to the original message by including an In-Reply-React 99 header field: 101 The [ABNF] for the header field is: 103 in-reply-react = "In-Reply-React:" emoji *(lwsp emoji) CRLF 105 emoji = {character from Unicode Emoji List} 107 An emoji character is taken from [Emoji-List]. 109 The emoji(s) express a recipient's summary reaction to the specific 110 message referenced by the accompanying In-Reply-To header field. 111 [Mail-Fmt]. 113 For recipient MUAs that do not support this mechanism, the header 114 field might not be displayed to the recipient. To ensure that the 115 reaction is presented to the recipient, the the responding MUA MAY 116 automatically include a second copy of the header field in the 117 message body. This might be as the first line of the body or as the 118 first mime-part. [MIME] By making the text be the full header field, 119 it also allows MUAs that do support the mechanism to identify this 120 redundant information and possibly remove it from display. 122 3. Usability Considerations 124 This specification defines a mechanism for the structuring and 125 carriage of information. It does not define any user-level details 126 of use. However the design of the user-level mechanisms associated 127 with this facility is paramount. This section discusses some issues 128 to consider . 130 Creation: Because an email environment is different from a typical 131 social media platform, there are some choices needed in the design 132 of the user interface to support indication of a reaction. Is the 133 reaction to be sent only to the original author, or should it be 134 sent to all recipients? Should the reaction always be sent in a 135 discrete message containing only the reaction, or should the user 136 also be able to include other message content? (Note that this 137 specification permits the inclusion of this other content.) 139 Display: Reaction indications are likely to be most useful when 140 displayed in close visual proximity to the original message, 141 rather than merely as part of an email response thread. 143 4. Possible Issues 145 o Should the specification permit only one emoji? Why (not)? 147 5. Security Considerations 149 This specification defines a distinct location for specialized 150 message content. Processing that handles the content differently 151 from content in the message body might introduce vulnerabilities. 152 However the mere definition or use of this mechanism does not create 153 new vulnerabilities. 155 6. IANA Considerations 157 None. 159 7. References 161 7.1. Normative References 163 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 164 Specifications: ABNF", RFC 5234, January 2008. 166 [Emoji-List] 167 Unicode Consortium, "Full Emoji List, v13.0", WEB 168 https://unicode.org/emoji/charts/full-emoji-list.html. 170 [Mail-Arch] 171 Crocker, D., "Internet Mail Architecture", RFC 5598, July 172 2009. 174 [Mail-Fmt] 175 Resnick, P., Ed., "Internet Message Format", RFC 5322, 176 October 2008. 178 7.2. Informative References 180 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 181 Extensions (MIME) Part One: Format of Internet Message 182 Bodies", RFC 2045, November 1996. 184 Author's Address 186 Dave Crocker 187 Brandenburg InternetWorking 189 Email: dcrocker@bbiw.net