Subject: Re: [Last-Call] Last Call: <draft-crocker-inreply-react-06.txt> (React: Indicating Summary Reaction to a Message) to Experimental RFC

From: Alessandro Vesely <[email-masked]>
Date: Sat, 16 Jan 2021 18:56:27 +0100

👍

---

From: Eliot Lear <[email-masked]>
Date: Sat, 16 Jan 2021 22:28:35 +0100

IMHO Email has been missing these reactions for years, and this is a great idea.  I have several comments about the text, and one process comment.  Let me start with the latter: was there a discussion about whether to make this PS rather than experimental?  I see one really substantial issue with the draft that isn’t discussed, but I don’t know that it is insurmountable (discussed below).

On the text, one issue in Section 2, in the ABNF:

part-content =  emoji *(lwsp emoji) CRLF

emoji = emoji_sequence
emoji_sequence = { defined in [Emoji-Seq] }

base-emojis = thumbs-up / thumbs-down / grinning-face / frowning-face / crying-face

thumbs-up = {U+1F44D}
thumbs-down = {U+1F44E}
grinning-face = {U+1F600}
frowning-face = {U+2639}
crying-face = {U+1F622}

I don’t understand where base-emojis are used.  Was “emoji" meant to be "emoji_sequence / base-emojis”?
In Security Considerations in Section 5, I think it’s probably useful to talk about the risk of spoofed messages creating spoofed reactions, perhaps a lot of them.  What mitigation techniques should be employed?  One might be to look for a valid Authentication-Results header.
Finally, what happens if the same source sends two reactions in two separate emails?  Can one send a blank message to remove a reaction?

In Section 3, one nit:

...

   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.

   2.  If R's In-Reply-To: does reference one, then check R's message
       content for a part with a "reaction" content-disposition at
       either the outermost level or as part of a multipart at the
       outermost level.
As “R” is only ever referenced here, my suggestion is to either lose the variable, or to refer to the other message with a variable, for consistency.
Again, thanks for the draft, and I look forward to its approval, preferably as a PS ;-)
Eliot

> On 16 Jan 2021, at 02:14, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from an individual submitter to consider the
> following document: - 'React: Indicating Summary Reaction to a Message'
>  <draft-crocker-inreply-react-06.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-02-12. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   The popularity of social media has led to user comfort with easily
>   signaling basic reactions to an author's posting, such as with a
>   'thumbs up' or 'smiley' graphic.  This specification permits a
>   similar facility for Internet Mail.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-crocker-inreply-react/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Barry Leiba <[email-masked]>
Date: Sat, 16 Jan 2021 16:53:44 -0500

On the process issue, the reason for Experimental is that we don’t know the
practical aspects of implementing this in MUAs and having users actually
use them, both in sending reactions and in viewing the reactions we get
back.  I’m very pleased that this document actually contains Section 7,
which describes what the experiment needs to answer (thanks, Dave!), and
wish all Experimental drafts did that.

Given the uncertainty about when this is actually practical, but the
necessity of having a standard protocol to try in order to find out, I
think Experimental is the right approach.

Barry

On Sat, Jan 16, 2021 at 4:28 PM Eliot Lear <[email-masked]> wrote:

> IMHO Email has been missing these reactions for years, and this is a great
> idea.  I have several comments about the text, and one process comment.
> Let me start with the latter: was there a discussion about whether to make
> this PS rather than experimental?  I see one really substantial issue with
> the draft that isn’t discussed, but I don’t know that it is insurmountable
> (discussed below).
>

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Jan 2021 14:48:44 -0800

On 1/16/2021 1:53 PM, Barry Leiba wrote:
> On the process issue, the reason for Experimental is that we don’t 
> know the practical aspects of implementing this in MUAs and having 
> users actually use them, both in sending reactions and in viewing the 
> reactions we get back.  I’m very pleased that this document actually 
> contains Section 7, which describes what the experiment needs to 
> answer (thanks, Dave!), and wish all Experimental drafts did that.
>
>> On Sat, Jan 16, 2021 at 4:28 PM Eliot Lear <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>

base-emojis is intended to sit there, as an available set, if an 
implementer wants to use it. It is an offer of core commonality among 
systems, if they want to adopt it, and encouragement that developers 
have a core, common set, if this isn't it.

It's similar to the Section B.1 Core Rules in the ABNF RFC (5234).  
Available, but not required.

>> In Security Considerations in Section 5, I think it’s probably useful 
>> to talk about the risk of spoofed messages creating spoofed 
>> reactions, perhaps a lot of them. What mitigation techniques should 
>> be employed? One might be to look for a valid Authentication-Results 
>> header.

Security Considerations is an opportunity with infinite possibilities.  
If anyone wants to supply text to add and others like it, then it should 
be added...

>> Finally, what happens if the same source sends two reactions in two 
>> separate emails? Can one send a blank message to remove a reaction?

What happens if the source provides two reactions in the /same/ email? 
Is that different from this? Because both are supported.

Trivial technical answer in the scope of this specification:  Both are 
entirely legal.

Difficult usability answer, outside the scope of this specification:  It 
will be interesting to see how and whether UI implementers support 
either or both of these.

>> As “R” is only ever referenced here, my suggestion is to either lose 
>> the variable, or to refer to the other message with a variable, for 
>> consistency.

The 'R' construct was added here, to resolve some language ambiguity.  
No, it isn't elegant writing. Yes, I'd be delighted for someone to 
supply alternative text that is clear, accurate and more appealing.

And thank /you/ for the detailed feedback.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

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

---

From: "John Levine" <[email-masked]>
Date: 16 Jan 2021 21:19:40 -0500

>have a core, common set, if this isn't it.

OK, but if that's the intention I think it would be good to say so.  It's
not clear whether those are supposed to be mandatory to implement, or
the only ones you can expect to interoperate, or what.

>If anyone wants to supply text to add and others like it, then it should 

This doesn't sound like a new or very interesting problem. I'm sure
we've all gotten mailboxes full of auto-acks from mail we didn't send.

Buglet: in section 2 there are two places where it says bytes but
appears to mean code points. Individual bytes aren't relevant in
strings of UTF-8.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 17 Jan 2021 10:09:23 +0000

>    o  Does the presence of the Reaction capability create any
>       operational problems for recipients?

Broadly speaking, yes: this draft is about expressing meaning using 
cultural tokens but it's inherently rooted in a specific cultural 
background from a specific time period, which means that it's a product 
of the culture you're in, and relevant to the current time period. 
These parameters will change according to time and geography, rendering 
your proposal obsolete or worse.

Emojis are not interpreted the same way universally, e.g. there are 
significant cultural differences in how a thumbs-up emoji might be 
perceived in different parts of the world.  Although you haven't 
specified it in the draft, this is all the more so for the "OK" hand 
gesture, which was fine even 20 years ago in "western" culture, but not 
so much these days.  Zooming back in time, how would things look now if 
we had had this draft in the 1990s (let's pretend we had utf8 + 
widespread emojis then) and there were replies all over the place with 
the OK hand gesture?  This wouldn't have matured well.

IOW, there is merit to what you're suggesting here, but if you want to 
make this draft more relevant in the longer term to a wider cultural 
audience, then either:

1. open it up - to all UTF8 tokens, allowing users to make their own 
choices about what reaction would be culturally appropriate to them at 
that period in time.

2. restrict it - by abstracting the representation to better-defined 
universal tokens, e.g. "happy" / "affirmative-reply", which might be 
interpreted today in the US as <smiley-face> / <thumbs-up>, but which 
could be reimagined in other cultures in other time periods.

Nick

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Jan 2021 11:36:58 +0100

Hi Dave,

Again thanks for this draft.  I definitely think it should go forward.  See below for some replies.

>> 
>>> On Sat, Jan 16, 2021 at 4:28 PM Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> base-emojis is intended to sit there, as an available set, if an implementer wants to use it. It is an offer of core commonality among systems, if they want to adopt it, and encouragement that developers have a core, common set, if this isn't it.
> 
> It's similar to the Section B.1 Core Rules in the ABNF RFC (5234).  Available, but not required.
> 

I don’t know enough to know the prevalence of the unicode emoji set and whether base-emojis are needed.  I leave that to you.  I would just add a few words to indicate why you defined the set and when you would expect it be used.  That’s all.
> Security Considerations is an opportunity with infinite possibilities.  If anyone wants to supply text to add and others like it, then it should be added...
> 
> 

Here’s what I would suggest:

An attacker may transmit one, several, or many messages that lack any form of authentication, indicating one or more reactions, thus causing the MUA to mislead the reader into believing a general sentiment to be something other than what it is, or that a specific reaction is other than what it is.  The ultimate appropriate remediation is to authenticate the sender of a reaction against a trusted authority. Short of that, MUA designers are advised to consider only processing reactions that pass a heuristic test as to their likely authenticity.

> What happens if the source provides two reactions in the /same/ email? Is that different from this?  Because both are supported.
> 
> Trivial technical answer in the scope of this specification:  Both are entirely legal.
> 
> Difficult usability answer, outside the scope of this specification:  It will be interesting to see how and whether UI implementers support either or both of these.
> 
> 

There are really two possibilities:  reactions are additive, or reactions are replacements.  I don’t see any real case for additive, and quite a number for replacements.  For instance, one wants to avoid the case where the same sender is being counted as multiple +1s, as it were.

I agree that there are some interesting UI aspects to this, but I myself find that I first initially react on one common platform with a “like”, and then I get more specific, leading to two separate reactions.  By having a little bit of text here, one can establish some common expectations.

Here’s my suggestion:

When a subsequent message containing a reaction is received from the same source regarding the same original message, it is said to have superseded the previous reaction.

Also:

A blank reaction, a reaction containing containing no “emoji” as defined in the ABNF in Section 2, is said to have cleared any previously received reaction from the source.

That way, one can change one’s mind or correct a mistake.

I think these suggestions follow the principle of least astonishment, but I readily admit I could be wrong.  I recognize that this requires a reaction database to implement.  Yeah, that’s a small pain. THAT to me may be the real experiment here.

Eliot

> The 'R' construct was added here, to resolve some language ambiguity.  No, it isn't elegant writing.  Yes, I'd be delighted for someone to supply alternative text that is clear, accurate and more appealing.
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> 408.329.0791
> 
> [email-masked] <mailto:[email-masked]>

---

From: Richard Clayton <[email-masked]>
Date: Sun, 17 Jan 2021 12:23:41 +0000

In message <[email-masked]>, Eliot Lear
<lear=[email-masked]> writes

>    There are really two possibilities:  reactions are additive, or 
>    reactions are replacements.  I don’t see any real case for 
>    additive, and quite a number for replacements.  For instance, one 
>    wants to avoid the case where the same sender is being counted as 
>    multiple +1s, as it were.

the case for additive would be simplicity of implementation

>    Here’s my suggestion:
>
>    When a subsequent message containing a reaction is received from 
>    the same source regarding the same original message, it is said to 
>    have superseded the previous reaction.
>
>    Also:
>
>    A blank reaction, a reaction containing containing no “emoji” as 
>    defined in the ABNF in Section 2, is said to have cleared any 
>    previously received reaction from the source.
>

the notion that multiple emails from a sender can be ordered in time
(without any intervening response from the recipient) is, I think, a new
concept 

>    I think these suggestions follow the principle of least 
>    astonishment, but I readily admit I could be wrong.  I recognize 
>    that this requires a reaction database to implement.  Yeah, that’s 
>    a small pain. THAT to me may be the real experiment here.

yes indeed ... to do this correctly it's necessary to record details of
all previously received messages (whether or not they contain the new
feature) if one is to correctly place a newly arrived message (which has
the feature) into the correct place in the sequence before deciding
whether or not the UI needs to be invoked

I suspect many implementations will not bother... so why specify
something that is most likely going to be ignored ??

... now I've never studied how often sequences of email messages are
shuffled out of their sending order before delivery, but queuing
mechanisms in MTAs tend to speculatively try to deliver each new message
and then, if that succeeds, deal with any backlog. Clearly ??? it is not
the intent of this document to affect design decisions here.

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: "John Levine" <[email-masked]>
Date: 17 Jan 2021 16:35:36 -0500

In article <[email-masked]> you write:
>I don’t know enough to know the prevalence of the unicode emoji set and whether base-emojis are needed.  I leave
>that to you.  I would just add a few words to indicate why you defined the set and when you would expect it be
>used.  That’s all.

It is my impression that if a system can display any emoji at all,
it's likely to display all of them, give or take recent additions. I
still don't see the utility of base-emoji.

>An attacker may transmit one, several, or many messages that lack any form of authentication, indicating one or
>more reactions, thus causing the MUA to mislead the reader into believing a general sentiment to be something other
>than what it is, or that a specific reaction is other than what it is.  The ultimate appropriate remediation is to
>authenticate the sender of a reaction against a trusted authority. Short of that, MUA designers are advised to
>consider only processing reactions that pass a heuristic test as to their likely authenticity.

You'd need a pretty sophisticated attacker to know enough about
someone's mail stream to send fake responses that matched up well
enough to look plausible. I suppose you could attack mailing list mail
that way, but again that's nothing new. If I wanted, I could send a
dozen replies to this list faking the addresses of previous senders
saying that your suggestion is brilliant, or not.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sun, 17 Jan 2021 16:39:36 -0800 (PST)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> >    multiple +1s, as it were.

First, I agree with Dave that this is outside the scope of this specification.
I am sympathetic to having a consistent set of semantics for combining
multiple reactions in order to avoid least astonishment princple violations,
but I don't think we know enough at this point to nail down these details.

I also note that this is a lot more complicated than previously stated: Even in
the context of a single sender or even a single message additive can mean
multiple things: A set union or a count of the number of times an emoji has
appeared. (Nothing in the ABNF prevents someone from specifying the same emoji
more than once.)

> the case for additive would be simplicity of implementation

Doing additive right is actually harder to implement - you have to keep track
of every message-id in order to deal properly with duplicate messages. With
per-sender replacement all you need to track is the message-id and date of the
most recent message from each sender, then ignore duplicates and old messages.)

> (without any intervening response from the recipient) is, I think, a new

Not remotely new, actually. Sorting by sent date is an option
in the IMAP SORT extension (RFC 5256 section 2.2), but I'm pretty sure it was
an option in some user agents when I first started using email, circa 1980.

But as noted above, you don't need such elaborate capabilities to
implement replacement. All you need to keep track of is the most recent.

> whether or not the UI needs to be invoked

I think you may be misunderstanding the semantics we've defined. Reactions link
via in-reply-to. A reply to a reply is a reaction to that reply. Threads are
not involved.

> something that is most likely going to be ignored ??

Keeping track of the entire ordering isn't necessary AFAICT.

> the intent of this document to affect design decisions here.

To the extent that there's a potential issue here, it's probably that transient
delivery failures are now sufficiently uncommon that people may assume delivery
order is sufficient and not bother to track dates. And who knows? They may be
right; arrival ordering may actually work well enough.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Jan 2021 09:41:57 +0100

Hi John, Barry, Ned, Richard, and Dave,

Again, very positive about the document.  Please just take these comments as input, as you move toward approval.

> but I don't think we know enough at this point to nail down these details.

Congratulations! You’ve convinced me that this isn’t ready for PS.

Going to the experiment goals:
   o  Is there demonstrated interest by MUA developers?
My concern is that without answering a few more questions and a bit more detail, you might not get critical mass.  I hope that this back and forth has given you a few more.  Here are some you could add:
What, if any, sequencing capability needs to be added (see below)?
What constraints on emojis might be necessary, and how would they be applied (see below)?

   o  If MUA developers add this capability, is it used by authors?

Who is expected to be an author in this context, and why is this question important to the experiment?
   o  Does the presence of the Reaction capability create any
      operational problems for recipients?

   o  Does the presence of the Reaction capability demonstrate
      additional security issues?

These are great questions.  I hope that at least this discussion has partially answered some already, although proceeding with the experiment would be very useful.

> concept.

The Date: field should suffice, and indicates sender intent, which is useful in this case.  It doesn’t get below 1 second accuracy, so it’s not perfect.  Tie might go to last message received for that message.  If you really want to get fancy, you could add an optional sequence number that would help with ordering.  That might be something with which people could experiment.

Then Ned and Dave both pointed out that there are neither constraints on how many emoji can be sent nor whether the same emoji could be sent multiple times.  This raises a question as to how people might use the reaction.  Since 1989 (I kid you not!) I (and certainly others) have noodled on how to handle voting.  Now “voting” means different things to different people in different contexts.  Here are a few examples:

Checking working group consensus here at the IETF
Picking a meeting time a’la doodle.
Gauging general sentiment amongst a group for an idea.
Actually counting yeas and nays.

To handle these cases in the experiment, you might want to consider defining one or more optional headers to indicate to the recipient (a) what emojis are allowed and (b) whether duplicates of the same emoji are allowed.

Of course, not all of this has to be done in one experiment, but it seems to me that the more you can lay out, the richer the experimentation can be.

> saying that your suggestion is brilliant, or not.

It’s mostly the mailing list case that I am thinking of.  The difference between this and other messages is how the MUAs might present the information.  So for instance, if you were to spoof a +1 from me to a mailing list, I would very quickly see that note on the list and say, “WOT?!”  Now imagine an interface that counts reactions, but doesn’t present the message in any other way.  And why would it if it only contained a reaction?  Now I would not see a message that I didn’t send.  How this is perceived will depend on the culture of the mailing list and its purpose.  If there are votes, one could easily imagine people just mindlessly counting reactions.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Jan 2021 06:24:42 -0800

> the only ones you can expect to interoperate, or what.

Well, heck.  I thought I'd put in a sentence the explained it, but 
indeed, no.  Will add.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Jan 2021 06:45:02 -0800

Eliot,

Thanks for the detailed comments.  Inline...

>>>> In Security Considerations in Section 5, I think it’s probably 
>>>> useful to talk about the risk of spoofed messages creating spoofed 
>>>> be employed? One might be to look for a valid 
>>>> Authentication-Results header.
>>
>> Security Considerations is an opportunity with infinite 
>> possibilities.  If anyone wants to supply text to add and others like 
>> it, then it should be added...
>>
>
> An attacker may transmit one, several, or many messages that lack any 
> form of authentication, indicating one or more reactions, thus causing 
> the MUA to mislead the reader into believing a general sentiment to be 
> something other than what it is, or that a specific reaction is other 
> than what it is.  The ultimate appropriate remediation is to 
> authenticate the sender of a reaction against a trusted authority. 
> Short of that, MUA designers are advised to consider only processing 
> reactions that pass a heuristic test as to their likely authenticity.

There are three, considerable problems with your suggestion:

    1. In reality, it applies to /any/ content.  Reactions are just one
    example.

    2. You've made the popular assumption and assertion that
    authentication reduces deception

    3. You made the popular assumption that recipients will be
    influenced by signals of authentication.

There is essentially no empirical evidence that authentication and 
signals associated with it, have much effect on average recipients.

That seems like heresy, because it is so completely counter-intuitive, 
but consider the failure of the Web's extended certification program.  
And the absence of a body of research showing efficacy of signals.

I can send a message from [email-masked], and have it fully 
authentication.  I can then have the body of the message purport to be 
from the President of the company the recipient works at, and the 
recipient is likely to believe it.

There are a variety of cognitive and behavioral explanations that seem 
to account for this, but the bottom line is that authentication has 
nothing to do with recipient behavior. Authentication provides a clean 
channel for filtering engines to use, when evaluating incoming mail. Period.

>> What happens if the source provides two reactions in the /same/ 
>> email? Is that different from this? Because both are supported.
>>
>> Difficult usability answer, outside the scope of this specification:  
>> It will be interesting to see how and whether UI implementers support 
>> either or both of these.
>>
>>
>
> reactions are replacements.
...
> Here’s my suggestion:

Adding to the responses about this already sent...
(and in case any misses the irony of my phrasing, this should make clear 
it was intentional.)

People send multiple replies all the time.  What are the semantics of 
that?  Why should a series of reactions have different semantics?

MUAs with threading deal with multiple replies.  We have no standards 
about that.  (One colleague, who might even be reading this, long-ago 
commented that they'd learned to wait after I sent a reply, because I 
often sent a second one that had a substantial elaboration.)

It's entirely possible that MUA developers will handle receipt of 
multiple reactions in a single reply, or a series of individual 
reactions, in different ways.  It will be interesting to see.

It is NOT reasonable for this specification to give direction about user 
interface design.  Nor, IMO, to constrain the semantics of reactions 
sent in series.

> I think these suggestions follow the principle of least astonishment, 
> but I readily admit I could be wrong.  I recognize that this requires 
> a reaction database to implement.  Yeah, that’s a small pain. THAT to 
> me may be the real experiment here.

Perhaps.

d/

---

From: tom petch <[email-masked]>
Date: Mon, 18 Jan 2021 17:03:57 +0000

> think Experimental is the right approach.

The question that comes to my mind is; does the MUA still exist?

My MUA was largely eliminated by my ESP over a year ago and while a 
search revealed many possible replacements, almost all of them ceased 
development many years ago.  Rather we are now in a world of social 
media and web.

Obviously the concept in this I-D is integral with social media but what 
happens with web mail?  I know that the mantra of the IETF is to avoid 
user interfaces when at all possible but it seems to me that this is a 
case where it should not be avoided.  At the same time, I find most 
aspects of the web inimical to working over e-mail so struggle to see 
where this would fit in without making things worse.

Tom Petch

---

From: "Ricardo Signes" <[email-masked]>
Date: Mon, 18 Jan 2021 12:25:40 -0500

> The question that comes to my mind is; does the MUA still exist?

Yes.

Speaking as the operator of a web-first MUA, I can tell you that many people still use native platform MUAs, they want to keep doing so, many platforms continue to support doing so, and new MUAs are produced at a rate of several a year, which do not all immediately fade into obscurity.

Beyond that, it's not clear to me why the question of interface or "what happens" is particularly different between web-based or native MUAs.  Any MUA will need to decide how (and whether) to indicate that replies within a thread are providing a reaction.

-- 
rjbs

---

From: Barry Leiba <[email-masked]>
Date: Mon, 18 Jan 2021 12:42:22 -0500

A web-based MUA is still an MUA, n'est-ce pas?

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Jan 2021 18:45:31 +0000

> A web-based MUA is still an MUA, n'est-ce pas?
Indeed. And so are email clients on mobile devices.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Jan 2021 12:55:00 -0800

> A web-based MUA is still an MUA, n'est-ce pas?

Indeed.

There's some nuance, beneath that fact, but really they are 
implementation issues and not email architecture issues.

Some Webmail MUAs have nothing running on the user's machine other than 
a browser, with no specialized code.  So only the simplest of user 
interaction details take place between the browser and the server.

Others download more interesting dynamic code into the browser, produced 
what's often called a split-UA. What's running in the browser might 
actually know some email semantics or syntax.

But yeah, still an MUA.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Jan 2021 13:16:27 -0800

On 1/17/2021 2:09 AM, Nick Hilliard wrote:
> background from a specific time period, which means that it's a 
> product of the culture you're in, and relevant to the current time 
> period. These parameters will change according to time and geography, 
> rendering your proposal obsolete or worse.
>
> gesture, which was fine even 20 years ago in "western" culture, but 
> not so much these days.  Zooming back in time, how would things look 
> now if we had had this draft in the 1990s (let's pretend we had utf8 + 

Nick,

This is one of those cases that distinguish theory from practice.  There 
can't be any argument against your observation that cultures differ in 
their communication styles and symbols. If we knew how to do tools that 
were infinitely adaptable to those differences -- while also being 
substantial and helpful -- that would be excellent.  But the nature of 
doing Internet standards for user-level capabilities typically requires 
doing things that are constrained -- and, by some views, biased.

Earlier during development of this specification, there was in fact some 
consideration to having the 'value' part of the construct take 
essentially anything, not just emojis.  The problem is that it 
essentially dilutes the utility of the field and certainly eliminates 
any predictability to its content. Besides, if the user wants to add 
more than an emoji, they are free to put that in the regular part (rest) 
of the body.

Emojis have quite a bit of established practice, and especially for 
social networks.  The current specification is seeking to leverage 
established practice, rather than invent a broader, more flexible range 
of uses or meanings.

Allowing the full set of Unicode emojis is actually quite flexible, 
relatively to established practice, for some social networking 
services.  The base-emojis rule is intended to demonstrate of example of 
an established and limited repertoire. To the extent that there are 
groups wanting a different, common set, they can define it.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Jan 2021 14:19:35 -0800

On 1/17/2021 2:36 AM, Eliot Lear wrote:
> A blank reaction, a reaction containing containing *no* “emoji” as 
> but I readily admit I could be wrong.

Apologies.  I managed to miss the 'blank' point.  It's an interesting 
one, but my current guess is that it's really more general than just for 
emojis.

An extreme version of this greater generality was summarized by an 
associated dean of engineering, when I was in graduate school, who told 
an anecdote that ended with: "I understand why you wrote than memo.  But 
what I cannot fathom is why you sent it.)

So, yes, deleting or replacing an emoji makes intuitive sense, designing 
additional semantics or, worse, mechanism to cover it -- absent 
compelling need -- misses the fact that this is only one example of what 
might be needed for email.

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Jan 2021 14:30:38 -0800

On 1/18/2021 2:19 PM, Dave Crocker wrote:
> So, yes, deleting or replacing an emoji makes intuitive sense, 
> designing additional semantics or, worse, mechanism to cover it -- 
> absent compelling need -- misses the fact that this is only one 
> example of what might be needed for email.

Second thought, just to prime the topic, if folk are interested:

    Define a MIME type for a message that is to replace a previous message.

So I send a fresh message, with this, and the receiver can choose to use 
the embedded message as a replacement for some referenced message it 
received earlier.

Hmmm...

d/

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 Jan 2021 13:40:04 -0800 (PST)

>     influenced by signals of authentication.

While I agree with all of these points, I don't think they are responsive to
what Eliot is suggesting. If I read what he said correctly, the MUA would act
on the authentication indicators by not showing the reaction, not with some
broken link indicator or similar. Since this is a reaction indication, not a
message, the issues with false positives are arguably less. Whether they're
enough less, well, that kind of depends on what you use reactions for.

Of course the idea of there being a trusted authority of sufficient
universality that someone could code their MUA to use it is a huge
stretch. And this, I think, is where the proposal falls apart.

As for the idea of using heuristics, the idea of having an open-ended
suggestion that implementors pick something, anything, for this purpose is more
than a little scary given past experience with the things people use as spam
tests. So absent something more specific I don't think this is a good idea.
Although it is intriguing to think about various checks and latching schemes
and so on. But the siren song of a hack in the making is kind of the problem,
isn't it?

				Ned

---

From: "John Levine" <[email-masked]>
Date: 18 Jan 2021 20:19:34 -0500

>    Define a MIME type for a message that is to replace a previous message.

No need.  See RFC 4021, section 2.1.46.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Jan 2021 08:44:49 +0100

Hi Ned,

I think my voice will have been heard here quite enough, so I’ll sum things up here.  Again, I’m in favor of this draft going forward.

> enough less, well, that kind of depends on what you use reactions for.

Consider what you are defining here:  if an MUA designer is adding a reaction button in the message pane a’la FB or LinkedIn (for example), one could easily imagine quite a large number of reactions.  If all you are looking to do is present smiley faces in a message, you don’t need any of this.  You are looking for some sort of aggregation and/or special MUA treatment.  Ok… given that, you should address yourselves  to the risks of that special mistreatment, and what mitigations there may be.

How these reactions will be used will indeed vary, but neither you nor I get to say how they will be used, and thus some words of warning in advance seem appropriate.

> stretch. And this, I think, is where the proposal falls apart.

Universality?  I never claimed any such thing.  However, there certainly are a group of services that are able to reasonably authenticate a good portion of the population. We are, of course, ever limited by the lack of a universally accepted and used authentication model for email.  C’est la vie, but it does have an impact here.

> and so on. But the siren song of a hack in the making is kind of the problem,

I left things open ended because this is supposed to be an experiment.  If you don’t like the word “heuristics”, consider how Google and Yahoo! deal with this problem and call it whatever that is...

Regards

Eliot

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 19 Jan 2021 17:54:15 +0100

On Mon, 2021-01-18 at 13:40 -0800, Ned Freed wrote:
> suggestion that implementors pick something, anything, for this
> purpose is more than a little scary given past experience with the
> things people use as spam tests. So absent something more specific I
> don't think this is a good idea.  Although it is intriguing to think
> about various checks and latching schemes and so on. But the siren
> song of a hack in the making is kind of the problem, isn't it?

I like the idea of reactions in e-mail, but any method of conveying
information will be misused by pranksters and spammers, so I think it
is useful to think about abuse.

point 1: there is no restriction on the number of emojis in your
reaction.

example:

  🧚 🧚🏻 🧚🏼 🧚🏽 🧚🏾 🧚🏿 🧚‍♂️ 🧚🏻‍♂️ 🧚🏼‍♂️ 🧚🏽‍♂️ 🧚🏾‍♂️
🧚🏿‍♂️ 🧚‍♀️ 🧚🏻‍♀️ 🧚🏼‍♀️ 🧚🏽‍♀️ 🧚🏾‍♀️ 🧚🏿‍♀️ 🧚 🧚🏻 🧚🏼 🧚🏽
🧚🏾   🧚🏿 🧚‍♂️ 🧚🏻‍♂️ 🧚🏼‍♂️ 🧚🏽‍♂️ 🧚🏾‍♂️ 🧚🏿‍♂️ 🧚‍♀️ 🧚🏻‍♀️
🧚🏼‍♀️ 🧚🏽‍♀️ 🧚🏾‍♀️ 🧚🏿‍♀️

obnoxious?  abusive?  it certainly would be a challenge to present this
in a UI, I think.  would the functionality be hampered by specifying a
limit on the number of emojis in a single Reaction?  or a limit on the
number of (distinct) emojin from a single respondent?

point 2: although the set of characters with the emoji property
generally don't contain letters, there is bound to be creative spammers
abusing those available.

example:

🐴 🧲 ⭕ ❌ ‼️

(the magnet looks like a C in the font I use.)

point 3: since the spam message can be spread across more messages, the
filtering is harder.  bear in mind the reactions can themselves be to
the spammer's own message.

point 4: should we disallow reactions coming from the author?

-- 
regards,
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Tue, 19 Jan 2021 10:53:00 -0800 (PST)

> is useful to think about abuse.

Sure, but the basis of comparison always has to be against both existing email
systems which do not have a reaction facility as well as other messaging
systems that do. It's neither fair nor reasonable to look at this as a new
system operating outside of these contexts.

> in a UI, I think.

Actually, the issues are reduced by having a well defined mechanism for
flagging reactions and linking them to the message being reacted to. As things
currently stand you can send such a message and nothing will prevent it from
simply being displayed as-is, with recipients them drawing their own, possible
incorrect, conclusions.

But if you know that it's a reaction the UA can check for this sort of thing
and handle it appropriately. I note that handling is unlikely to be to display
the message as-is, so tricks like this are unlikely to work all that well.

Of course it would be better if we were able to fully specify how all this
works down to the last detail. But we don't think we're up to the task, nor
do we think it's appropriate for us to try.

> would the functionality be hampered by specifying a

What would a reasonable limit be? Slack allows each emoji to specified
exactly once. Medium, OTOH, has a limit of 50 repeats. I've seen BBSes
that impose no limits whatsoever.

> (the magnet looks like a C in the font I use.)

Once again the comparison needs to be against existing systems. Creative
spammers are more likely to acheive success by posting this sort of thing as a
regular message part, not a reaction. Any sort of  nontrivial reaction
processing is likely to mess this up.

I also question the need to worry all that much about traditional spammers in
these circumstances. Remember that for a reaction to be valid it has to link to
a previous valid message. So in order to do this you need access to a
valid previous message. In the case of interpersonal mail this means having
access to one of the mailvboxes or the mail system, in which case you
have much bigger things to worry about than spoofed reactions.

As for list mail, despite many dire predictions the willingness of spammers to
subscribe to lists in order to spam them haven't not been borne out. Reactions
seem unlikely to change this.

> the spammer's own message.

And once again you're talking about a problem with email in general that's
almost certainly made more difficult by calling out reactions and handling them
as such.

> point 4: should we disallow reactions coming from the author?

Existing practice for this is all over the map. Slack lets you react to your
own postings. Other systems don't. Others only let you react when you
haven't contributed to the thread, and wipe out your reactions if you
post a contribution.

More generally, you seem to be assuming the purpose of reactions is some sort
of voting. Sometimes a reaction is just a reaction, and it's entirely
reasonable to post a reaction to your own message as a form of emphasis.

					Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 20 Jan 2021 19:41:36 +0100

On Tue, 2021-01-19 at 10:53 -0800, Ned Freed wrote:
> > information will be misused by pranksters and spammers, so I think
> > it is useful to think about abuse.
> 
> Sure, but the basis of comparison always has to be against both
> existing email systems which do not have a reaction facility as well
> as other messaging systems that do. It's neither fair nor reasonable
> to look at this as a new system operating outside of these contexts.
> 
> > 🧚🏿‍♂️ 🧚‍♀️ 🧚🏻‍♀️ 🧚🏼‍♀️ 🧚🏽‍♀️ 🧚🏾‍♀️ 🧚🏿‍♀️ 🧚 🧚🏻 🧚🏼
> > 🧚🏽 🧚🏾 🧚🏿 🧚‍♂️ 🧚🏻‍♂️ 🧚🏼‍♂️ 🧚🏽‍♂️ 🧚🏾‍♂️ 🧚🏿‍♂️ 🧚‍♀️
> > 🧚🏻‍♀️ 🧚🏼‍♀️ 🧚🏽‍♀️ 🧚🏾‍♀️ 🧚🏿‍♀️
> > obnoxious?  abusive?  it certainly would be a challenge to present
> > this in a UI, I think.
> 
> Actually, the issues are reduced by having a well defined mechanism
> for flagging reactions and linking them to the message being reacted
> to.
> As things currently stand you can send such a message and nothing
> will prevent it from simply being displayed as-is, with recipients
> them drawing their own, possible incorrect, conclusions.

yes, it will take some time before UA will pick up support for this and
collate the reactions rather than presenting each reaction mail as a
normal message.

> But if you know that it's a reaction the UA can check for this sort
> of thing and handle it appropriately. I note that handling is
> unlikely to be to display the message as-is, so tricks like this are
> unlikely to work all that well.

"appropriately" is too vague, IMHO.  some guidance on how this should
be presented is called for, I think.  otherwise this is no better than
the "me too" or "*rofl*" messages we already had.

> Of course it would be better if we were able to fully specify how all
> this works down to the last detail. But we don't think we're up to
> the task, nor do we think it's appropriate for us to try.

if the reactions aren't summarised and presented in a compact manner,
the feature has failed.

> > limit on the number of emojis in a single Reaction?  or a limit on
> > the number of (distinct) emojin from a single respondent?
> 
> What would a reasonable limit be? Slack allows each emoji to
> specified exactly once.

all the emojis in my example were unique, the skin tone and gender were
varied.

>  Medium, OTOH, has a limit of 50 repeats. I've seen BBSes

I think it is reasonable to restrict the number of emojis to a handful,
perhaps 2-3.

> > generally don't contain letters, there is bound to be creative
> > spammers abusing those available.
> > example:
> > 🐴 🧲 ⭕ ❌ ‼️
> Once again the comparison needs to be against existing systems.
> Creative spammers are more likely to acheive success by posting this
> sort of thing as a regular message part, not a reaction. Any sort of
> nontrivial reaction processing is likely to mess this up.

this ties into point 3 below: each emoji is sent as a separate reaction
and presented like this in the summary the UA provides.

> I also question the need to worry all that much about traditional
> spammers in these circumstances. Remember that for a reaction to be
> valid it has to link to a previous valid message. So in order to do
> this you need access to a valid previous message. In the case of
> interpersonal mail this means having access to one of the mailvboxes
> or the mail system, in which case you have much bigger things to
> worry about than spoofed reactions.

that ties in to point 4 - the spammer can send an innocuous message,
and the actual attention grabbing text via reactions to their own
message.

> As for list mail, despite many dire predictions the willingness of
> spammers to subscribe to lists in order to spam them haven't not been
> borne out.

right, I have only seen e-mail which are replies to list mail when the
mail archive was openly available on the web.  hardly any such archives
with headers intact exist anymore.

> > point 3: since the spam message can be spread across more messages,
> > the filtering is harder.  bear in mind the reactions can themselves
> > be to the spammer's own message.
> 
> And once again you're talking about a problem with email in general
> that's almost certainly made more difficult by calling out reactions
> and handling them as such.

I don't understand this point.

> Existing practice for this is all over the map. Slack lets you react
> to your own postings. Other systems don't. Others only let you react
> when you haven't contributed to the thread, and wipe out your
> reactions if you post a contribution.
> 
> More generally, you seem to be assuming the purpose of reactions is
> some sort of voting. Sometimes a reaction is just a reaction, and
> it's entirely reasonable to post a reaction to your own message as a
> form of emphasis.

well, my mental model of this is like the emoji reactions in
Mattermost, Slack and many other IM apps.  in those, the reactions are
not votes per se, but it is common social behaviour that if one person
adds a specific emoji, others will just select the same reaction, and
you get an increasing count.  if you hover over the emoji, you will get
a list of persons who have reacted using that emoji.  Facebook works
similarily, but only allows one reaction per user and the selection of
reactions is much more limited.

I'm not opposed to allowing authors to react to themselves, but it does
make the rather precarious security of In-Reply-To even more
precarious.

-- 
regards,
Kjetil T.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Jan 2021 14:45:39 -0800

> the "me too" or "*rofl*" messages we already had.

Forgive me, but it is important that this specification NOT specify or 
give substantial guidance about presentation choices.

Such choices are the purview of user experience / usability designers. 
As a body, the IETF does not have expertise in that realm.

Further, there is no established body of experience in doing such 
designs, within the context of email.  Gaining experience in such 
designs is a goal of this experiment.

That means that this specification for the underlying, enabling 
mechanism, needs to leave UX designers free to try alternative methods 
of handling this capability, to see which work better and which don't.

>> this works down to the last detail. 

No it really wouldn't.

The considerable history of the Internet's considerable success is, 
rather, a lesson in specifying as little as is essential, rather than as 
much as is possible.  The result is to enable innovation.

> I think it is reasonable to restrict the number of emojis to a handful,

Why?

Is there an established pattern of excess?  No.
Is there a danger to system operation?  No.
Do we have a basis for deciding what the limit should be? No.
What will the damage be to the recipient?  None.

> and the actual attention grabbing text via reactions to their own

Perhaps you can point to some empirical research that substantiates this 
threat?

d/

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 20 Jan 2021 23:49:04 +0100

On Wed, 2021-01-20 at 14:45 -0800, Dave Crocker wrote:
> > > But if you know that it's a reaction the UA can check for this
> > > sort of thing and handle it appropriately. I note that handling
> > > is unlikely to be to display the message as-is, so tricks like
> > > this are unlikely to work all that well.
> > 
> > "appropriately" is too vague, IMHO.  some guidance on how this
> > should be presented is called for, I think.  otherwise this is no
> > better than the "me too" or "*rofl*" messages we already had.
> 
> Forgive me, but it is important that this specification NOT specify
> or give substantial guidance about presentation choices.

I don't mean very specific guidance, but some wording about whether the
reactions should be aggregated or not?  or some wording that reactions
will not necessarily be presented in any specific order, neither
chronologically, origin-wise nor thematically.

I don't think that would be any more restrictive than the language
about the use of base-emojis.

I do like how the steps for processing are specified, in particular
that the reaction itself should be considered removed from the message
itself (internally to the MUA).  This implies quite a bit of the
presentation, really.

> Such choices are the purview of user experience / usability
> designers. As a body, the IETF does not have expertise in that realm.

granted.

> > I think it is reasonable to restrict the number of emojis to a
> > handful, perhaps 2-3.
> 
> Why?
> 

ok.  the current draft says "The content of this part is restricted to
single line of emoji."  this does set an upper bound, although in
octets (MUST 998, SHOULD 78) rather than emojis.

> > that ties in to point 4 - the spammer can send an innocuous
> > message, and the actual attention grabbing text via reactions to
> > their own message.
> 
> Perhaps you can point to some empirical research that substantiates
> this threat?

it is well established that spammers will exploit just about any
communication channel available to them.

in any case, nothing of this is an objection to the draft, I just
wanted to bring up some considerations.

-- 
regards,
Kjetil T.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Jan 2021 15:00:40 -0800

On 1/20/2021 2:49 PM, Kjetil Torgrim Homme wrote:
> reactions should be aggregated or not?

Even that level of guidance is, IMO, far too specific.  The simple 
reason is that there is no empirical basis for it, and certainly not 
enough to put it into a standard.

To be clear, my concern is not that the suggestion is unreasonable, but 
that user interface design problems are littered with choices that were 
reasonable but turned out to be wrong.

UX really is an entirely different design context from lower-level work. 
  Efficacy is affected in fundamentally different ways.  Humans being 
notably different than computers, and average humans being notably 
different from engineers...

Having a section that raises concerns, rather than suggesting approaches 
or solutions, seems entirely reasonable to me.  Even if the concern 
turns out to be wrong, there's no danger in listing issues.  But we 
really do need to make /all/ presentation and handling issues at the 
user level up to the people tasks with knowing how to do that.

>  or some wording that reactions

Given the points I repeated, above, you are, of course, still welcome to 
suggest text and see whether folk support its inclusion.

> communication channel available to them.

It is NOT well-established that everything a spammer does causes 
problems.  We should create standards that deal not just with behaviors 
that are intended to help a spammer, but with behaviors that actually do.

d/

---

From: "John Levine" <[email-masked]>
Date: 20 Jan 2021 19:41:08 -0500

>enough to put it into a standard.

I'm with Dave here. The IETF has a long history of guessing wrong
about UX design.

>or solutions, seems entirely reasonable to me.

I wouldn't put a lot of effort into it, since I don't see any reason
to expect us to come up with useful concerns, either.

>> communication channel available to them.

That's not true at all. They exploit channels that let them broadcast
a lot of messages (counted at least in millions) at little or no cost.
Even though it would be technically easy for spammers to subscribe to
mailing lists and send spam, they don't because the return is too low.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Thu, 21 Jan 2021 04:46:22 -0800 (PST)

> I'm with Dave here. The IETF has a long history of guessing wrong

I don't think this is quite fair or quite accurate. It's more like the IETF
ends up being, as the saying goes, "not even wrong".

What I mean by this is that all too often the UX concerns the IETF attempts to
address don't have much in common with the actual UX issues implementors end up
facing.

The concerns being expressed here about the things "spammers" will do that the
UX needs to guard against are a case in point. As you point out below, spammers
are interested in things that let them send lots of mail. A facility that lets
them tortuously create a false indication on a message by message basis don't
seem likely to be of much use, but in the unlikely event it is, it will be
through  a gap we don't currently see, and thus cannot advise against.

> to expect us to come up with useful concerns, either.

Exactly right.

I would suggest that the people who think such text would be helpful might 
want to try and craft something specific.

> mailing lists and send spam, they don't because the return is too low.

And this is even harder: In order to spoof a reaction you need the
message-id of an original message, and that id along with avoiding
whatever other safeguards are in place only lets you fiddle with the
display attached to that one message.

Why bother?

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 21 Jan 2021 17:54:07 -0500

> address don't have much in common with the actual UX issues implementors end up

I think we actually agree, but I didn't express it very well.  It's one 
thing to say this is a way to send emoji intended to be displayed as 
reactions to prior messages, another to offer advice about how that 
display might work.

> UX needs to guard against are a case in point. ...

Piling on a little, while spammers don't target individuals, spear 
phishers do.  On the other hand I am not coming up with any plausible 
scenarios where sending an emoji would be an effective way to spear 
phish, or any advice different from the advice about any spear phish.

We do occasionally see examples of people doing drive-by bulk posts to 
mailing lists, e.g. the Free Software Foundation occasionally dislikes 
something they think the IETF is planning, and a bunch of people show up 
to send one or two cookie cutter messages.  We haven't had trouble dealing 
with that, and again I don't see reactions making it any worse.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ned Freed <[email-masked]>
Date: Fri, 22 Jan 2021 11:19:03 -0800 (PST)

> reactions to prior messages, another to offer advice about how that

That and more. IME it's not that the IETF comes up with the wrong UX answers,
it's that they ask the wrong UX questions.

Now, anticipating Dave, it may well be that we're not alone in this, and that
only actual experimentation can determine the right UX direction to take. If
so, it's just another reason why we need an experiment.

> with that, and again I don't see reactions making it any worse.

Yeah, and when this happens, or when a so-called "influencer" decides to sick
their horde onto some online poll of little if any relevance, the obviousness
of it makes it actively counterproductive.

We don't need to invent technical solutions to well-solved problems.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Jan 2021 11:45:37 -0800

> so, it's just another reason why we need an experiment.

Well... Totally bikeshedding on this issue...

I'll claim it very much is NOT another reason for the IETF to treat this 
as an experiment.  (In effect, that would expand the scope of concern 
for the IETF, which exactly what we should avoid, wrt this realm.)

I have no doubt that UI designers can find useful presentation 
approaches.  I don't consider that a risk.  (They might do it less well 
or better, but doing something useful isn't that tough 'for someone 
trained in the art'...)

The risks I do see are the ones now listed in the draft.  And these are 
reasonably within the purview of the IETF.

d/

---

From: Ned Freed <[email-masked]>
Date: Fri, 22 Jan 2021 12:57:09 -0800 (PST)

> for the IETF, which exactly what we should avoid, wrt this realm.)

Some idea of the overall UX direction is important to the IETF effort because
it's possible we've specified the wrong underlying mechanism. (Or more likely,
we need to specify some additional stuff.)

This doesn't mean we should standardize any of it.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Jan 2021 13:11:45 -0800

> This doesn't mean we should standardize any of it.

It's gotten deployment, at some scale.  It hasn't gotten deployment, at 
some scale.

Or maybe:  It is / isn't being used, at some scale.

That's as much as the IETF needs to know, since that's as much as the 
IETF usually (ever) looks for.

d/

---

From: Ned Freed <[email-masked]>
Date: Fri, 22 Jan 2021 14:18:05 -0800 (PST)

> IETF usually (ever) looks for.

I would hope for a little more than that. If it doesn't deploy, it would
be interesting to know why. Similarly, if it does, it would be interesting
to know what additional technical underpinnings could or should be
standardized.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 22 Jan 2021 14:30:08 -0800

> to know what additional technical underpinnings could or should be

I was focused on musts.  The IETF typically does not reflect on the 
reasons for failures.  I'd wish otherwise, but... it is what it is.(*)

As for success analysis, I'll class that as out of scope.  Not bad to 
do, of course, but beyond the current work.

d/

(*) I tried to get an activity going that looked at exactly such issues. 
  In spite of ISOC and IETF management making quite a to-do of it, it 
had zero update.  Not a single effort to build upon the base of work, 
from before its release:

      https://trac.tools.ietf.org/misc/outcomes/

https://www.ietfjournal.org/ietf-outcomes-an-interview-with-dave-crocker/