Subject: [Last-Call] Benjamin Kaduk's Discuss on draft-crocker-inreply-react-08: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 24 Feb 2021 14:49:14 -0800

Benjamin Kaduk has entered the following ballot position for
draft-crocker-inreply-react-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-crocker-inreply-react/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I thought you were going to clean up whether the Content-Disposition was
"React" or "Reaction" based on the gen-art review, but the document still seems
internally inconsistent about it.
https://mailarchive.ietf.org/arch/msg/gen-art/zun860KMrKdwqyKSWbrvWSPMuYM/
indicates that "React" was the intent, but Sections 2 and 4.1 still use
"Reaction", while the IANA Considerations register "React".  Section 3
uses lowercase "reaction" in the context of a "Content-Disposition"
header field as well.  Section 7 mentions a "Reaction capability".

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

   The emoji(s) express a recipient's summary reaction to the specific
   message referenced by the accompanying In-Reply-To header field, for
   the message in which they both are present.  [Mail-Fmt].  For
   processing details, see Section 3.

I don't think I understand what "for the message in which they both are
present" is intended to mean (specifically "for the message").  My best guess
is that "when both 'Content-Disposition: Reaction' and 'In-Reply-To:' are
present in a message, these are the semantics; if 'Content-Disposition:
Reaction' is present without 'In-Reply-To:', the semantics are undefined".

Section 5

Given the difficulty of conclusively proving a negative, the value of
stating "there is no analysis demonstrating it does" seems minimal.

   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.

The potential for new implementation vulnerabilities when new code is
added for the specialized processing seems clear; it seems there may
also be human-factor vulnerabilities depending on how the information is
displayed, which may be less obvious to some readers and thus worth a
dedicated mention.

Section 6

   The IANA is request to register the React MIME Content-Disposition
   parameter, per [RFC2183]

    Content-Disposition parameter name:    React

   Allowable values for this parameter:    (none)

At https://www.iana.org/assignments/cont-disp/cont-disp.xhtml I see
distinct registries for "Content Disposition Values" and "Content
Disposition Parameters".
It notably does not have any columns relating what parameters are
allowed for use with a given value.

My undersatnding is that "React" is intended to be a "content
disposition value" and that no changes to the "content disposition
parameters" registry is to be made (and thus that the last quoted line
serves no purpose for IANA).  Some prose discussion, separate from the
registration, that no parameters are used with the content-disposition
value, would of course be welcome.

I also note that all of the existing entries in the "content disposition
values" registry are written in all lowercase form, but "React" contains
the majuscule 'R'.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Feb 2021 15:16:26 -0800

> header field as well.  Section 7 mentions a "Reaction capability".

Well, drat.  I thought I /did/ fix that, but indeed did /not/.

I've like 'react' as a quick reference, but staying consistent between 
it and the full term has obviously proved more of a challenge than I'm 
up to.

So I've changed all of the strings to 'reaction', except for internal 
xml labels and the filename (for continuity.)

Thanks.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Feb 2021 15:50:59 -0800

> xml labels and the filename (for continuity.)

Thanks; that works for me.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Feb 2021 11:11:59 -0800

Hi Dave,

Could you please confirm whether the lack of response to the COMMENT
section was intentional and no further comments are forthcoming?

Thanks,

Ben

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Feb 2021 12:28:03 -0800

> section was intentional and no further comments are forthcoming?

The drats just keep on coming.  Sorry.  It was completely NOT 
intentional.  I stopped at the Discuss and forgot that there might be 
Comments.

So...

Given that MIME can have a hierarchy that includes messages within 
messages within the body, there is bit of a challenge in how to get the 
references precise and accurate here.  This language has been reworked a 
couple of times, but better wording would be... better.  Offerings will 
be eagerly considered.

In hierarchy terms, the Reaction information needs to be at the same 
message 'level' as the In-reply-to: that it's associated with.

> stating "there is no analysis demonstrating it does" seems minimal.

Matching the minimal threat?

But seriously, if there IS an analysis  I/we don't know of it. Absent 
that, what else can we say?

Remembering that this is targeting Experimental, I'll suggest that the 
real purpose of that minimal comment is to highlight the issue and, even 
more indirectly, to solicit analyses.

> displayed, which may be less obvious to some readers and thus worth a

Ack.  Here's what I've added:

             <t>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?</t>

> allowed for use with a given value.

I hadn't re-read the spec in detail, for this effort, but now that I 
have, yeah, I suspect a number of things could have been done better in 
the specification and the administration of it.  I suspect this falls 
under the cover of "actual practice takes care of such niceties even 
when the formalities didn't."

> values" registry are written in all lowercase form, but "React" contains

Oh my.  That level of attention to detail might be offensive, if it were 
not so useful.

As in: good catch.  Fixed.

Again, I apologize for having missed the Comments initially. And thanks 
for making them.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791