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

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Mar 2021 13:15:44 -0500

Ben, Dave will be making another update to the draft to address your
COMMENT stuff.  Will you please check your DISCUSS and update
accordingly (version -09 should be consistently using "REACTION" (not
"REACT") for the content-disposition.

Thanks,
Barry

On Thu, Feb 25, 2021 at 3:29 PM Dave Crocker <[email-masked]> wrote:
>
> On 2/25/2021 11:11 AM, Benjamin Kaduk wrote:
> > Could you please confirm whether the lack of response to the COMMENT
> > 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...
>
> > ----------------------------------------------------------------------
> > 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".
>
> 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.
>
>
> > Section 5
> >
> > Given the difficulty of conclusively proving a negative, the value of
> > 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.
>
>
> >     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.
>
> 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>
>
> > 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.
>
> 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."
>
>
> > 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'.
>
> 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
>
> Volunteer, Silicon Valley Chapter
> American Red Cross
> [email-masked]
>
> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 10:59:03 -0800

> "REACT") for the content-disposition.

fwiw, I believe I've already added the necessary changes, from Ben's 
Comments section, to the pending version.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Mar 2021 11:11:15 -0800

Hi Barry,

I checked the -09 and it covers the discuss bits just fine.
I wasn't in a hurry to clear my discuss, though, since the nature of the
ongoing discussions last week would arguably make for a discuss in its own
right.

However, that does not excuse me for failing to respond to Dave's responses
to my comments; see inline for those.

> > message 'level' as the In-reply-to: that it's associated with.

I expect that I (both when I wrote that and now) am failing to truly
appreciate the subtleties involved in the MIME hierarchy.  My comment was
intended to be more of an editorial one, though -- I was failing to come up
with a clear binding as to which specific "message" was being indicated and
how the other parts relate to it.

Your clarification about being at the same level helps, so let me take a
stab at naming things and writing down relationships, with the goal of
eventually being able to craft some text that reflects that.

There's some message A that came into being somehow; we don't care about
that.  Some entity X decides to react to A, and creates a new message B.
Message B contains a "Content-Disposition: Reaction" header field and
"In-Reply-To: A" header field, in order to be the reaction message.

In order for a reaction to be conveyed, the existing text says "both are
present".  Having just written the above, I now am thinking maybe the
"both" that are present are the two header fields Content-Disposition and
In-Reply-To?  Or maybe it is the emojis in the content of this part and the
In-Reply-To header field?  Or does the "both" refer to the messages A and B?

I'm not actually sure that my confusion trying to interpret this text has
much to do with complicated MIME hierarchies, having written the above...

> > Matching the minimal threat?

The presumed minimal threat, yes.

> > that, what else can we say?

We could say nothing?

Or "it is currently believed that the specific structure of this content
does not introduce any additional threat surface"

> > more indirectly, to solicit analyses.

If we want to solicit analysis, then I'd suggest "a detailed analysis of
this question has not yet been performed" or similar.

> > social engineering vulnerabilities?</t>

Okay, thanks.

> > when the formalities didn't."

There is a step for the authors/ADs/IANA to figure out what needs to happen
and check that it happened correctly, yes.  Writing it up clearly in the
RFC helps everyone else that didn't get to be a part of that exchange,
though.

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

I'm happy they were useful.
Sorry to have taken a week to get back to you about them.

-Ben

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 11:57:50 -0800

> ongoing discussions last week would arguably make for a discuss in its own

Since you mention it, I will question it.  A Discuss is an exercise in 
authority to prevent progress until a significant problem is fixed.

The various changes are almost certainly making the specification 
better, but were they essential to achieve an adequate 'experiment'?  
The document went through 3 months of discussion on an established list, 
one month of IETF last call, and an IESG review, with no one noting or 
demanding any of these changes.

It is not as if that sort of extended process guarantees adequacy, but 
it's nothing, either.

Again, it's not that the document is not better, but 'better' is an 
infinite task.

For which of these changes would its absence have ensured failure?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Mar 2021 12:01:17 -0800

> authority to prevent progress until a significant problem is fixed.

Documents published on the IETF stream require IETF Consensus.
If we are still arguing over what text to include relating to issues for
which there is no prior discussion and prior determination of consensus,
how can there be IETF consensus?

(Note that I do not assert that any or all of the predicates are in fact
true in this particular case, and would have to do a bit more research
before taking a position on them.)

-Ben

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 12:10:28 -0800

> how can there be IETF consensus?

Except that we weren't still arguing.

The feeding frenzy only began because a couple of people made private 
comments to the IESG.  One was pressed to go public. My impression is 
that the other had not intended their concerns to go public.

That private comments to the IESG are not automatically surfaced, in 
some fashion, for public resolution, is a process point the IESG and the 
IETF might want to consider, so that a frenzy like this happens at a 
more reasonable point.

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Mar 2021 12:20:35 -0800

> Except that we weren't still arguing.

Note the part where I said "I do not assert that any or all of the
predicates are in fact true"; your claim seems irrelevant to my point.

> IETF might want to consider, so that a frenzy like this happens at a 

My understanding is that it is intentionally a supported part of the
process for the IESG to be able to receive private feedback.  (This would
be why it is specifically listed as something covered by the Note Well.)
The IESG or IESG members who receive feedback can do several things with
that feedback, including incorporating the technical points made into their
own ballot positions and asking for public discussion of those technical
points, with or without the direct involvement of the person who submitted
the feedback.

I think there's pretty universal sentiment that getting earlier feedback is
preferred, but I don't think that adding more process is going to cause the
phenomenon of late feedback to disappear.

-Ben

P.S. I think there is still an open (editorial) question regarding "the
message in which they both are present", for which I need more data to be
able to suggest a resolution.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Mar 2021 17:13:35 -0800

On 3/3/2021 12:20 PM, Benjamin Kaduk wrote:
> process for the IESG to be able to receive private feedback. 

Ben,

Of course.  And as an escape-hatch, for special circumstances, it's an 
important option.

But when it is used as a means of bypassing public discussion?

Of the two contacts we know about, using that option for this draft, one 
was not active in the public discussion.  Why?  The other was, but did 
not raise these concerns in that forum.  Why?

This is important, for an organization with such a profound reliance on 
open and inclusive participation and accountability.

There is a danger in not asking such 'whys' about people choice, because 
it has too much potential for creating an image of cronyism and 
back-room deals.

> phenomenon of late feedback to disappear.

"Preferred" is a characterization that makes a lot of sense for dealing 
constructively when someone happens to think of something later.

However I suggest that it is entirely too weak for dealing with folk who 
are attempting to bypass public discussion, especially when they already 
have a track record of public participation.

> able to suggest a resolution.

I responded to that point.  The wording is the best we -- there was 
public group discussion on it -- could come up with.

If it is not sufficient, better wording is of course eagerly sought.

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Mar 2021 17:50:15 -0800

Hi Dave,

> But when it is used as a means of bypassing public discussion?

If there was an attempt to bypass public discussion (note "if"), it does
not seem to have worked, given that there has been a substantial volume of
public discussion...

> it has too much potential for creating an image of cronyism and 

Speaking only for myself, I am interested in producing high-quality
technical documents.  I basically don't care by whom or in what forum a
potential issue is raised; I care about whether the technical content is
properly discussed (in an open forum, of course) and a satisfactory
resolution found.

I think we have had some recent threads over on [email-masked] that have
indicated the risks of attempting to assign motive to the words and actions
of others, and I do not expect to get involved in a discussion of why
anyone did or did not send what comments where at what time.

> have a track record of public participation.

If I put a Discuss position in, I and only I am on the hook to defend that
position.  Any other position does not block a document's approval.  If I
learn of an issue in a private discussion but I don't think it justifies a
discuss, that's in many ways the same as if I had never learned of that
issue at all.  If I do think the issue merits a discuss, then it's on me to
defend my position ... and it still doesn't matter where I learned of the
issue.  So where is the harm in receiving a private comment?  I only see a
risk that an issue actually should have blocked the document but did not,
which is the same situation as if no comment was made at all.  It seems to
me that attempting to forbid private comments would be much more likely to
result in no comments than in public comments, and that seems like a
strictly inferior situation to the current one.

> public group discussion on it -- could come up with.

I put some thoughts into
https://mailarchive.ietf.org/arch/msg/last-call/T8Rm8E5KZ7-590Rj0QYnuTj1yeQ/
but do not see any follow-ups on the substance of this topic.  Please send
a link if I am missing something.

> If it is not sufficient, better wording is of course eagerly sought.

I would be happy to suggest better wording ... if I knew which to things
are indicated by the "both" in "both are present".  I think it's two of:
emoji as the content of a message part, the In-Reply-To header field, the
Content-Disposition: Reaction header field, the message being responded to,
and the message conveying the response.  But which two?

Thanks,

Ben

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 04 Mar 2021 09:41:24 +0100

> and the message conveying the response.  But which two?

Let me take a stab at it.  First the current text in the tracker:

  2.  Reaction Content-Disposition

     A message sent as a reply MAY include a part containing:

     Content-Disposition: Reaction
[...]
     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.

First I'd like to say - whenever there is a ambiguity in such
introductory text, read the detailed processing instructions to resolve
them.  But I think we can resolve this by replacing "both" with "both
the Reaction part and the In-Reply-To header field".

Sort of unrelated - from the processing instructions:

   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.

This means a forwarded message will *not* get its embedded reactions
processed.  Well, forwarded messages will typically not have I-R-T set,
but if a message includes previous correspondence as an attached MIME
document.  However, In-reply-to in messages in the attached
correspondence will get their reactions processed if they are at the
correct relative level in the structure.

Please correct me if I am wrong, Dave.  If this is *not* the intention,
I think step 1 in the processing instructions need to state this only
applies to I-R-T found at the top level of the message.

-- 
venleg helsing,
Kjetil T.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Mar 2021 06:42:58 -0800

The current text in the draft is:

> message referenced by the
>                 accompanying In-Reply-To header field, for the message 
> in which they both are present.

I read 'both' as referring to "the emoji(s)" and "the accompanying 
In-Reply-To header field".  And that's what is intended.

If you are reading it differently, I don't understand how and why.

If you are reading it the same as I am, I don't understand what the 
confusion is.

> this question has not yet been performed" or similar.

I said indirectly.

Unfortunately, I am not understanding what it is about the current 
wording that is sufficiently deficient and important to warrant this 
extent of discussion.

> RFC helps everyone else that didn't get to be a part of that exchange,

On the offchance my response wasn't clear, I was referring to the cited 
details for those registries, not the text in this draft specification.  
I read your comment as observing some issues with the way the registries 
were organized and I was agreeing with you.  But, of course, that's 
outside the scope of this draft.

I do not see that changes are needed in the the draft's Section 6.  If 
you feel otherwise, please suggest the changes.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Mar 2021 13:52:09 -0800

On 3/4/2021 12:41 AM, Kjetil Torgrim Homme wrote:
> This means a forwarded message will*not*  get its embedded reactions
> document.  

Not 'typically'.  A forwarded message is not a reply.  So I'm not sure 
how this is a problem.

In any event, if there is no In-reply-to: field, then this specification 
is not relevant to that message.

> However, In-reply-to in messages in the attached

Let's see whether I understand, with an example meant to be more 
interesting than the one in the specification:

> From:  me
> To: you
> Subject: I just got this message
> 
> ---- Forwarded message
> From: someone else
> To: me
> In-Reply-To: a previous message between us
> Content-Disposition: reaction
> 
> U+1F997

The containing message isn't using MIME, to make the forwarded message 
an attachment.  I think it doesn't matter, for this example.

And the question is whether the contained message's reaction will be 
processed as a reaction.  The answer depends on how the MUA processes 
such things.

In terms of semantics, the reaction is associated with that contained 
(forwarded) message and not with the upper level (containing) message.

d/

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 06 Mar 2021 00:07:12 +0100

On Fri, 2021-03-05 at 13:52 -0800, Dave Crocker wrote:
> >         at the outermost level.
> Not 'typically'.  A forwarded message is not a reply.

I can forward a message as a reply to a different message (drag and
drop it as an attachment), but the "forward" button in my mail reader
will not do that - it will only set References and not I-R-T.

> So I'm not sure how this is a problem.

It's not a problem, just an edge case.

> is not relevant to that message.

There is an In-Reply-To inside the attached message, that's my point.
 It could even be nested further.

> an attachment.  I think it doesn't matter, for this example.

Well, a real example would have to use MIME, a MUA should not try to
assign meaning to "---- Forwarded message" or "---- Vidaresendt
melding", but I'll consider your example a shorthand for a proper MIME
structure.

> (forwarded) message and not with the upper level (containing) message.

OK, so processing MAY recurse into the MIME structure?  I don't think
the current step 2 allows this.  This can cause duplication in the
presentation of reactions, but I'm OK with this being a quality of
implementation thing (e.g., keep track of messages-ids for messages
with reactions to eliminate the duplication).

-- 
venleg helsing,
Kjetil T.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Mar 2021 15:32:19 -0800

> will not do that - it will only set References and not I-R-T.

You mean you can include a message in a reply.  That's not typically 
what is meant by forwarding.  But yes, you can do that.

The example in my previous note still applies.  The contained message is 
self-contained and any references inside it are not affected by the 
containing message.  Similar, the contents of the containing message 
(typically) does not reflect the contained message.

> It's not a problem, just an edge case.

Sorry, but so far, I am not seeing how it is even that.

>   It could even be nested further.

So? Again, I am still missing the point.

> melding", but I'll consider your example a shorthand for a proper MIME

As I said, I believe use of MIME to make the contained message an 
attachment, rather than inline, does not affect this.

Since you apparently think otherwise, please explain.

> the current step 2 allows this.

Yes it does:

> specific message referenced by the accompanying In-Reply-To header field,

The In-Reply-To: and Content-Disposition must be 'accompanying' each 
other.  In the same message.

   This can cause duplication in the
> presentation of reactions, 

How?

d/

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 06 Mar 2021 01:05:07 +0100

> Since you apparently think otherwise, please explain.

Your example message had a body text which happened to contain the
string "Content-Disposition".  It was not a header field, so it should
not be handled as such.

> other.  In the same message.

OK, step 1 says:

   1.  If a received message R contains an In-Reply-To: header-field,
       check to see if it references a previous message the MUA has
       sent or received.

So this is not just the top-level message R, but repeated for every
message R contained inside the message.  If you mean R *is* top-level,
and you think recursion is valid, the text should use the plural.

   1.  If a received message R contains In-Reply-To: header-fields,
    
   check to see if they reference previous messages the MUA has
     
 sent or received.

But I don't like that.  Better to spell it out.

   1.  If a received message R (or a message contained within it)
     
 contains an In-Reply-To: header-field,
       check to see if it
references a previous message the MUA has
       sent or received.

> > presentation of reactions, 

By getting multiple copies of the same attached thread.  E.g., by
someone replying and including all preceding content.  Hence, the
processing may rack up the same reaction to a message multiple times.
 This is solvable though, and the exact method does not need to be
specified in the draft.

-- 
venleg helsing,
Kjetil T.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 7 Mar 2021 11:31:10 -0800

Hi Dave,

> In-Reply-To header field".  And that's what is intended.

Thank you for answering my question about what the "both" is intended to
refer to.  It's a shame that it took four round trips to get around to
that.

> If you are reading it differently, I don't understand how and why.

Well, my whole point at the start is that I don't know how to properly read
it.  My ballot position included "my best guess" as to what was intended
(which, to be fair, does not have to always bear much resemblance to what
the words on the page actually say).  So ... I don't understand why you're
writing comments that come across as saying that the text is perfect as-is
and I was wrong to have even asked a question about it.

As an aside, this does not seem like the first time that I have tried
to comment on how "the words on the page" may not quite map up to what you
intended to convey, and it is not the first time that we've taken several
round trips to clarify that that is the main focus of my comment.  Is there
something that one or both of us could change in order to make such
communication more efficient?

> If you are reading it the same as I am, I don't understand what the 

The sentence starts out by talking about a "summary reaction" to a
"specific message" and the "accompanying In-Reply-To header field".  There
are three things listed, and I have to pick two in order for "both" to
apply.  (On the face of it, of course, requiring both the message that is
being responded to and the In-Reply-To header field to be present before
doing anything would make the mechanism pretty weird, but that requires
knowledge of the protocol and not just parsing the sentence.)  Furthermore,
this sentence uses "the message" twice (once as "the specific message"), to
refer to two different messages.  This further complicates the job of the
reader in parsing the sentence, and the writer can help by providing clear
descriptors to justify the respective uses of the definite article.  And
finally, we have the "recipient" being an entity who is *generating* a
(reaction) message, which is a mismatch for the normal meanings of those
terms.

So, my suggestion would be to take

OLD:
   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.
NEW:
   The emoji(s) express a recipient's summary reaction to a specific
   message.  The message being reacted to is referenced by the accompanying
   In-Reply-To header field; both the emoji(s) and the header field must be
   present in order to indicate a reaction.  [Mail-Fmt].  For
   processing details, see Section 3.

(I'm also a bit confused that we are specifically mentioning that the
header and content have to be present, but not mentioning the
content-disposition as a mandatory element.  Yes, this spec is only about
the content-disposition and we wouldn't be randomly talking about other
things, but if we want a nice tidy list of what's required, making it
comprehensive would not be so hard.)

> wording that is sufficiently deficient and important to warrant this 

It's redundant.  If there was analysis demonstrating there is new attack
surface, we would reference it.

Since you are so fond of asking for specific proposed text, I will be so
bold as to suggest something here without being specifically asked:

OLD:
                             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.
OLD:
                             This new content has a specific structure,
   but this structure is not believed to present a new threat surface.

As another aside, I'm also a bit surprised to see your note about "this
extent of discussion".  I think that two round-trips is acceptable for
basically any comment, and we're not writing long essays about this point.
About other points, sure, but not this one.  After all, once the RFC is
published it is immutable, so this is our only chance to spend effort on
the topic.

> outside the scope of this draft.

Well, I was actually trying to refer to the text in this draft
specification.

Specifically, the part where it is telling IANA to do things that IANA
can't actually do given the current state of the registry.  Assuming that
we want the final RFC to reflect what IANA actually did, this text will
need to change at some point.

In general, if I am making a comment about something other than the draft
being evaluated, I will preface it explicitly as a "side note", "tangent",
or similar.  But perhaps this gets back into the recurring issue that I
mentioned above of it taking multiple round-trips for the two of us to
actually agree on what is being commented on, and the same question about
how to make communication more efficient applies.

> you feel otherwise, please suggest the changes.

How about

OLD:
    Content-Disposition parameter name:    Reaction

    Description:   Permit a recipient to respond by signaling basic
      reactions to an author's posting, such as with a 'thumbs up' or
      'smiley' graphic
NEW:
    Content-Disposition value name:    Reaction

    Description:   Permit a recipient to respond by signaling basic
      reactions to an author's posting, such as with a 'thumbs up' or
      'smiley' graphic

    Reference: [this document]

Thanks,

Ben