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

Kjetil Torgrim Homme <kjetilho@ifi.uio.no> Sat, 06 March 2021 00:05 UTC

Return-Path: <kjetilho@ifi.uio.no>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF52A3A1472; Fri, 5 Mar 2021 16:05:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikv8K0dpzt_E; Fri, 5 Mar 2021 16:05:22 -0800 (PST)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023F43A1450; Fri, 5 Mar 2021 16:05:21 -0800 (PST)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from <kjetilho@ifi.uio.no>) id 1lIKRS-0005Vm-LY; Sat, 06 Mar 2021 01:05:10 +0100
Received: from wireguard.i.bitbit.net ([87.238.42.12] helo=comm.ms.redpill-linpro.com) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user kjetilho (Exim 4.93.0.4) (envelope-from <kjetilho@ifi.uio.no>) id 1lIKRR-0000r9-W5; Sat, 06 Mar 2021 01:05:10 +0100
Message-ID: <d8449b5cf26d5ca64297dc583a5a4bf524d73d33.camel@ifi.uio.no>
From: Kjetil Torgrim Homme <kjetilho@ifi.uio.no>
To: Dave Crocker <dcrocker@bbiw.net>, Benjamin Kaduk <kaduk@mit.edu>
Cc: last-call@ietf.org, todd.herr@valimail.com, Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>, draft-crocker-inreply-react@ietf.org
Date: Sat, 06 Mar 2021 01:05:07 +0100
In-Reply-To: <b0c5fe01-daf5-9460-ac20-ffb9a55ff37b@bbiw.net>
References: <dbb0a7b2-07fc-348b-4e39-f5b3ff92a2c9@gmail.com> <20210225191159.GU21@kduck.mit.edu> <ef24bc92-b869-3882-d704-a44e4872c5f2@gmail.com> <CAC4RtVDRj_v2Jv9wixGtaLqVr+Q0Qg-z8rSQvRruJyhvVK9dFw@mail.gmail.com> <20210303191115.GG56617@kduck.mit.edu> <0e2a50e5-6f7d-a5c2-acf4-2be4fe34605c@bbiw.net> <20210303200117.GH56617@kduck.mit.edu> <13aca853-9466-81ae-9b8a-d403b49ecc79@bbiw.net> <20210303202035.GI56617@kduck.mit.edu> <9caa51e9-17e9-cb0e-dbba-79b148d40553@bbiw.net> <20210304015015.GL56617@kduck.mit.edu> <f66e48607d89190f341ed31f5d39201b72c661ba.camel@ifi.uio.no> <ded9ea39-a5c3-4426-aae5-a35fd1401349@bbiw.net> <9d9b046deeaccbfd2bc832571e4f7677d64a5cf3.camel@ifi.uio.no> <b0c5fe01-daf5-9460-ac20-ffb9a55ff37b@bbiw.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 87.238.42.12 is neither permitted nor denied by domain of ifi.uio.no) client-ip=87.238.42.12; envelope-from=kjetilho@ifi.uio.no; helo=comm.ms.redpill-linpro.com;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.020, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: CF7ACAD6205B88764228C212FDB8F2CDE7AADF56
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/FL8ewSSS0BULLkPMHlgtgiyxRy8>
Subject: Re: [Last-Call] Benjamin Kaduk's Discuss on draft-crocker-inreply-react-08: (with DISCUSS and COMMENT)
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2021 00:05:30 -0000

On Fri, 2021-03-05 at 15:32 -0800, Dave Crocker wrote:
> On 3/5/2021 3:07 PM, Kjetil Torgrim Homme wrote:
> > On Fri, 2021-03-05 at 13:52 -0800, Dave Crocker wrote:
> > > 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.
> > 
> > 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.
> 
> 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.

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.

> > OK, so processing MAY recurse into the MIME structure?  I don't think
> > the current step 2 allows this.
> 
> Yes it does:
> 
> > The emoji(s) express a recipient's summary reaction to the
> > 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.

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.

>    This can cause duplication in the
> > presentation of reactions, 
> 
> How?

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.