Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-crocker-inreply-react-07 Reviewer: Dale R. Worley Review Date: 2021-01-27 IETF LC End Date: 2021-02-12 IESG Telechat date: [unknown] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: 1. Introduction by marking basic emoji graphics Probably intended to be "by marking with basic emoji graphics". Normative language, per [RFC8174]: In most drafts, this material is placed in a separate section from the Introduction. Also, this draft contains a much longer version of this boilerplate than is common. 2. Reaction Content-Disposition If such a field is specified the content-type of the part MUST be: Probably should be capitalized as "Content-Type". The rule emoji_sequence is inherited from [Emoji-Seq]. It permits one or more bytes to form a single presentation image. I haven't traced the definition of emoji_sequence, but it seems to be essentially a set of Unicode characters that have one or another of certain attributes. That is perfectly sensible. But if I understand correctly, "emoji_sequence" is a sequence of characters, and you want to say "In the UTF-8 encoding, some of these characters may be encoded as multiple bytes." or something like that. The emoji(s) express a recipient's summary reaction to the specific message referenced by the accompanying In-Reply-To header field. [Mail-Fmt]. This is not specific as to where the In-Reply-To header is. I assume you want to say that it is a header of the parent multipart component of "Reaction" part. Or perhaps this should be forward-referenced to the discussion in section 3. Reference to unallocated code points SHOULD NOT be treated as an error; associated bytes SHOULD be processed using the system default method for denoting an unallocated or undisplayable code point. Code points that do not have the requisite attributes to qualify as part of an emoji_sequence should also not be treated as an error, although you probably want to allow the system to alternatively display them normally (rather than as an unallocated or undisplayable code point). 4.1. Example Message with a thumbs-up, affirmative response of: To: author@xxxxxxxxxxx From: recipient@xxxxxxxxxxx Date: Today, 29 February 2021 00:00:10 -800 Message-id: 12345@xxxxxxxxxxx Subject: Meeting Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Disposition: Reaction {U+1F44E} This example does contain an In-Reply-To header, contrary to the specification. 4.2. Example Display Message: A complete message is often displayed with a tailored section for header-fields, enhancing the format and showing only selected header fields. It might include one for reactions, again showing the symbol and a count. I think it would be more accurate to expand "It might include one for reactions ..." to "It might include a quasi-header summarizing the reactions that have been received ...". Then again, perhaps "one" meant "a tailored section", which would be clarified differently. 5. Security Considerations This specification defines a distinct label for specialized message content. Perhaps s/label/Content-Disposition/. 6. IANA Considerations The React MIME Content-Disposition parameter is registered, per [RFC2183] I think s/React/Reaction/ is intended. Comparing with https://www.iana.org/assignments/cont-disp/cont-disp.xhtml, it would be The Reaction MIME Content-Disposition value is registered, per [RFC2183] Content Disposition value: Reaction Allowable parameters for this value: (none) 7. Experimental Goals o Does the presence of the Reaction capability demonstrate additional security issues? Perhaps s/demonstrate/create/. [END] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
