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

Kjetil Torgrim Homme <kjetilho@ifi.uio.no> Fri, 05 March 2021 23:07 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 6DE243A11A0; Fri, 5 Mar 2021 15:07:30 -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 QP6zAo--Rjxh; Fri, 5 Mar 2021 15:07:28 -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 D3F813A119E; Fri, 5 Mar 2021 15:07:27 -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 1lIJXS-0002RU-6n; Sat, 06 Mar 2021 00:07:18 +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 1lIJXR-000EzN-Hm; Sat, 06 Mar 2021 00:07:18 +0100
Message-ID: <9d9b046deeaccbfd2bc832571e4f7677d64a5cf3.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 00:07:12 +0100
In-Reply-To: <ded9ea39-a5c3-4426-aae5-a35fd1401349@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>
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: 9055472ADA48FC112D0CF604D263B6147C995F95
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/cJakBKq7sajn5EIjsQuelWk7IZw>
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: Fri, 05 Mar 2021 23:07:31 -0000

On Fri, 2021-03-05 at 13:52 -0800, Dave Crocker wrote:
> On 3/4/2021 12:41 AM, Kjetil Torgrim Homme wrote:
> >     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.  
> 
> 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.

> In any event, if there is no In-reply-to: field, then this specification 
> 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.

> > 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.
> 
> 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.

> 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.

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.