Subject: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-react-00.txt

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Sep 2020 12:37:06 -0700

-------- Forwarded Message --------
Subject: New Version Notification for draft-crocker-inreply-react-00.txt
Date: Mon, 14 Sep 2020 11:42:46 -0700
From: [email-masked]
To: Dave Crocker <[email-masked]>

A new version of I-D, draft-crocker-inreply-react-00.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name:		draft-crocker-inreply-react
Revision:	00
Title:		React: Indicating Summary Reaction to a Message
Document 	date:	2020-09-14
Group:		Individual Submission
Pages:		5
URL:       https://www.ietf.org/id/draft-crocker-inreply-react-00.txt
Status:    https://datatracker.ietf.org/doc/draft-crocker-inreply-react/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-crocker-inreply-react
Htmlized:  https://tools.ietf.org/html/draft-crocker-inreply-react-00

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 indication.  This specification
    permits a similar facility for Internet Mail.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brandon Long <[email-masked]>
Date: Mon, 14 Sep 2020 17:41:17 -0700

Is this the new April Fools?

Is it restricted to SMTPUTF8 or do you have a preferred encoding
mechanism?  How about UTF7?

Brandon

On Mon, Sep 14, 2020 at 12:37 PM Dave Crocker <[email-masked]> wrote:

> _______________________________________________
> ietf-822 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-822
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Sep 2020 18:23:03 -0700

> mechanism?  How about UTF7?

😟 Forgive me, Brandom.  Perhaps it's my age or impairment from smoke 
inhalation, but I can't seem to find the constructive content in your 
posting to the mailing list.  Care to try again?

d/

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Mon, 14 Sep 2020 21:50:21 -0400

> Title:		React: Indicating Summary Reaction to a Message

   For recipient MUAs that do not support this mechanism, the header
   field might not be displayed to the recipient.  To ensure that the
   reaction is presented to the recipient, the the responding MUA MAY
   automatically include a second copy of the header field in the
   message body.

In-Reply-React: Egads!

Is there enough overlap between "people who use emojis" and
people who use email and people who use MUAs likely to be updated
to support this, to have a decent chance of it getting traction?

   in-reply-react = "In-Reply-React:" emoji *(lwsp emoji) CRLF

So is that 'emoji' a raw UTF-8, or UTF-16, or encoded, or what?

It also fails to address the question of MUA behavior when the "nope badger"
is the proper response....

(Maybe I'm just cranky because I've been chasing a stupid font problem
that makes my MUA blow up every time certain emojis get used in a
Subject: line and it ends up pointing at a corrupted font character that
has a negative width, and Linux 'fontconfig' doesn't make it easy to
figure out which actual font file was used as the render source)

---

From: "John Levine" <[email-masked]>
Date: 14 Sep 2020 22:41:15 -0400

In article <CABa8R6vxujy=[email-masked]> you write:
>-=-=-=-=-=-

I'd rather repurpose X-Face so we can have any reaction image we want.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Sep 2020 19:48:18 -0700

> I'd rather repurpose X-Face so we can have any reaction image we want.

Have you ever tried to repurpose established practice on the Internet?

That's why I am, instead, directly use established practice, and merely 
add a new venue for it.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Sep 2020 09:27:23 +0200

Why not in the Subject:?

    o  Should the specification permit only one emoji?  Why (not)?

So users have to reply multiple react messages?

Best
Ale
--

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 15 Sep 2020 22:08:27 +1000

> That's why I am, instead, directly use established practice, and merely 

You see this even with text messages on some platforms now, where it says:

Foo reacted “👍” to “I love dogs” and quotes the full text message that you sent them.  I assume there's enough smarts in some clients to find the most recent matching message and assign the reaction to it.

This is a slightly more programatic way of doing that.  I would suggest that the body be something like that text message - a description of the reaction and the text being reacted to (as well as having the correct In-Reply-To to thread in the right place of course).  A client that doesn't know about the header gets a "Me Too!!!!" email in the thread, a client that does know can collapse it into something clever.

For that matter a server that knew about this could suppress the email entirely and turn it into a keyword update and some metadata on the replied-to message.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 15 Sep 2020 22:10:48 +1000

>     automatically include a second copy of the header field in the

Many systems don't thread happily if you change the subject.

> So users have to reply multiple react messages?

If they have multiple reactions to make - sure.  I'm not too stressed either way, but I would argue that a single emoji per message is definitely simpler for everybody.

Bron.

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 15 Sep 2020 07:21:00 -0500

Someone asked me about this feature some years ago when social media was 
becoming popular and I suggested simply adding a disposition to Message 
Disposition Notification (RFC 8098, STD 85). The machinery is already in 
some systems, MDNs give you the ability to easily get back to the source 
message through Message-ID, and the adornment ("Joe Smith liked this 
message" or "❤️" or whatever) could then be added to the display of 
the original message, etc. No new mechanism needed and I think somewhat 
quicker deployment. It would probably just take an Informational 
document with a pointer to STD 85.

pr

On 14 Sep 2020, at 14:37, Dave Crocker wrote:

> Status:    
> https://datatracker.ietf.org/doc/draft-crocker-inreply-react/
> Htmlized: 

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 15 Sep 2020 07:25:38 -0500

I hit send before adding one question:

Was this a specific ask (as in someone wants to implement something like 
this), does someone have code to do this already, or is this just an 
idea for new functionality?

pr

On 15 Sep 2020, at 7:21, Pete Resnick wrote:

> Someone asked me about this feature some years ago when social media 
> was becoming popular and I suggested simply adding a disposition to 
> Message Disposition Notification (RFC 8098, STD 85). The machinery is 
> already in some systems, MDNs give you the ability to easily get back 
> to the source message through Message-ID, and the adornment ("Joe 
> Smith liked this message" or "❤️" or whatever) could then be added 
> to the display of the original message, etc. No new mechanism needed 
> and I think somewhat quicker deployment. It would probably just take 
> an Informational document with a pointer to STD 85.
>
> pr
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Sep 2020 08:11:44 -0700

On 9/15/2020 5:08 AM, Bron Gondwana wrote:
> Foo reacted “👍” to “I love dogs” and quotes the full text message 
> that you sent them.  I assume there's enough smarts in some clients to 
> find the most recent matching message and assign the reaction to it.
>
> This is a slightly more programatic way of doing that.

It's a more /semantic/ way of doing it.

Examples such as you describe get the symbol to the original author and 
have language that establish the semantics of the symbol in a way that 
that original author can interpret, but there is nothing to signal to 
the /software/ what the semantic is. That's what this proposal is for.

> I would suggest that the body be something like that text message - a 
> description of the reaction and the text being reacted to (as well as 
> having the correct In-Reply-To to thread in the right place of course).

I suggest we be careful about over-specifying this mechanism. There are 
is a variety of ways to use it that seem pretty reasonable.  What you 
suggest is only one.  I think we should let developers have the freedom 
to explore those variations, if they wish.  Again, it's not that the 
specifics of what you suggest are problematic but that locking into 
those details is unnecessary.

d/

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2020 15:44:53 -0000

In article <[email-masked]>,
>document with a pointer to STD 85.

That sounds right.  I'd add a Reaction: extension-field to the MDN with
the contents being a URL, typically a data: URL.  It might be something like
this for a single emoji:

Reaction: data:text/plain,%f0%9f%92%a9

But the kewl kids react with animated images, e.g.

Reaction: data:image/png;base64, ... encoded dancing baby here ...

or a remote reference to an image

Reaction: https://media.giphy.com/media/Ju7l5y9osyymQ/giphy.gif

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Sep 2020 08:59:00 -0700

On 9/15/2020 5:21 AM, Pete Resnick wrote:
> message through Message-ID, 

So does normal reply functions.

How does the person who is reacting also add a comment or extended text 
or..., if they want to?

> No new mechanism needed and I think somewhat 

I think that if you break down the implementation details carefully, 
you'll find that the effort for my proposal and the effort for yours 
will be about the same.  They sit on top of different 'interfaces, but 
the effort to add to them probably isn't very different.

Except that your proposal adds a capability that has less flexibility.

On 9/15/2020 5:25 AM, Pete Resnick wrote:
> Was this a specific ask (as in someone wants to implement something
> like this), does someone have code to do this already, or is this
> just an idea for new functionality?
One of the nice things about an environment that intends to evaluate 
proposals on their merits, rather than, say, their politics, is that the 
source of the proposal shouldn't matter.  So I'm not clear what 
difference the answer should make or why you are asking.

In any event, the proposal was motivated by my finding myself constantly 
wishing I could make a quick response to an email the same way I can to 
a social networking posting, and feeling unhappy that I can't just click 
on a smiley (though my own tendency is more often to click on the crying 
emoticon, these days.)  I think the mechanism has become an extremely 
efficient way to give very basic responses.  I'd like email to permit 
that efficiency.

d/

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 15 Sep 2020 08:53:29 -0500

This is a promising idea, but I think it’s got an important flaw.  (John and Bron have a point, we should specify an encoding, but that’s not the flaw I’m focused on.)

Reactions != Emojis.  My concern is that this proposal may be making a mistake that is the opposite of Facebook’s.  For years Facebook had only “like” and got lots of criticism.   They added a few more reactions and they now get a bit less criticism.  On the one hand, it seems unfair that they have so much power that they can dictate the set of acceptable emotional reactions for mankind.  But on the other hand, the kitchen-sink list from Unicode.org includes so many icons that it’s not clear that people will be able to speak a common emoji language and know what each other’s reactions mean.    The emoji list is a vast superset of the set of shared human reactions.  (If someone posts a message about a political rally, and someone else responds with an icon of a stack of pancakes, what does that mean?  I have no idea.  Or, as a color blind person, can you tell me what am I missing if I can’t differentiate between a "green heart” emoji and an "orange heart” emoji?)

I’m no fan of Facebook, but they have kept the set of emojis down to something that is pretty much universally comprehensible.  I think it’s worth considering whether we can create a set that is less restrictive than facebook’s, but remains close to universally comprehensible.  It’s tempting to say that emojis are trivial, but if the Internet is all about facilitating human communication, a common emotional language for reactions would be a big help.  — Nathaniel

---

From: Brandon Long <[email-masked]>
Date: Tue, 15 Sep 2020 11:15:47 -0700

Forgive me, I assumed it was a joke and reacted in kind.  I looked to see
if I could find if you were reacting to something, and found nothing, and
then assumed that since you didn't include a seemingly obviously required
encoding method that it must be a quick joke on your part.

As for actually solving the encoding issue, the url format with a data: for
local encoded emojis and the potential for remote reactionary gifs is
interesting,
if we want to go whole hog.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Tue, 15 Sep 2020 11:19:24 -0700

I was also thinking of the common apache-style +1 to messages for approval,
and the MUA could even sum them!

On Tue, Sep 15, 2020 at 11:15 AM Brandon Long <[email-masked]> wrote:

> As for actually solving the encoding issue, the url format with a data:
> for local encoded emojis and the potential for remote reactionary gifs is
> interesting,

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 15 Sep 2020 13:23:42 -0500

On 15 Sep 2020, at 10:59, Dave Crocker wrote:

>> to the source message through Message-ID,
>

Most, though I know of several clients (web-based and mobile) that don't 
do In-Reply-To and References correctly. That said, those likely don't 
support MDN either, there's going to have to be some UI added to get 
this useful, so it is probably a wash.

> How does the person who is reacting also add a comment or extended 
> text or..., if they want to?

In the body of the message. Remember, MDNs are multipart/report. If you 
look in the examples in 8098 you'll see a text part (normally presented 
to the user as a normal message) followed by the 
message/disposition-notification part which contains the details of the 
original message and a "Disposition", which in this case could contain 
"reaction", and some additional information indicating the type of 
reaction.

>> No new mechanism needed and I think somewhat quicker deployment. It 
>> would probably just take an Informational document with a pointer to 
>> STD 85.
>

That's probably true. Either way, you'd want a bit of new UI on both 
ends too. I know some clients already have UI for pushing the "I read 
this" button and generate an MDN in response. Changing that to a 
drop-down list of reactions and adding a different disposition parameter 
seems pretty straightforward.

> Except that your proposal adds a capability that has less flexibility.

Actually, I think quite the opposite. You get the comment or extended 
text, plus a lot more flexibility to add different sorts of parameters 
into the message/disposition-notification part.

> proposals on their merits, rather than, say, their politics, is that 
> the source of the proposal shouldn't matter.  So I'm not clear what 

Oh, I definitely wasn't interested in the politics. I was asking to see 
if there was already pre-deployment of the mechanism, which might lean 
toward continuing down that code path instead of doing new engineering 
on current MDN codebases, or if it fit very well in an existing code 
base, where something like MDN wouldn't. That would make a difference, 
IMO.

> In any event, the proposal was motivated by my finding myself 
> constantly wishing I could make a quick response to an email the same 
> way I can to a social networking posting, and feeling unhappy that I 
> can't just click on a smiley (though my own tendency is more often to 
> click on the crying emoticon, these days.)  I think the mechanism has 
> become an extremely efficient way to give very basic responses.  I'd 
> like email to permit that efficiency.

Yep, I think, whichever mechanism is used, the functionality would be a 
nice little addition.

I can try to write up a quick draft of using MDN to compare and 
contrast.

pr

---

From: Richard Clayton <[email-masked]>
Date: Tue, 15 Sep 2020 19:37:18 +0100

In message <[email-masked]>, Pete
Resnick <[email-masked]> writes

>I know some clients already have UI for pushing the "I read 

I have a button in my software that says "this was never delivered". It
generates a DSN ... and only someone concentrating hard on the header
fields would be able to know that in fact the email was delivered and
the DSN is telling an untruth.

My users (back when my job was to make users of my software delighted to
be using it) were very happy indeed with this feature and found it was
quite cathartic for dealing with spam, unwanted admirers and of course
gas bills.

Far better than a thumbs down image.

- -- 
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: "Pete Resnick" <[email-masked]>
Date: Tue, 15 Sep 2020 13:51:34 -0500

> Far better than a thumbs down image.

Perhaps cathartic, but with much spam today probably not as effective as 
it once was since quite a bit of it has bogus Return-Path addresses. But 
I have always been fond of such a feature.

That said a reminder that MDN and DSN are somewhat different mechanisms, 
though they both use multipart/report.

pr

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2020 15:06:45 -0400

> or a remote reference to an image

Good ideas, although I'm with Nathaniel.
I have no idea what three pancakes means, so I'd rather have semantic words,
which are mapped locally to icons.

    > Reaction: https://media.giphy.com/media/Ju7l5y9osyymQ/giphy.gif

A poor idea because it's another URL that may or might not be fetched, and
can be used to track people.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Sep 2020 16:13:18 -0400

Pete Resnick <[email-masked]> wrote:
    > Perhaps cathartic, but with much spam today probably not as effective as it
    > once was since quite a bit of it has bogus Return-Path addresses. But I have
    > always been fond of such a feature.

I have long wanted some way to get non-delivery notices authenticated such
that they could get through the spam filters and really connect to the message in
my outbox.  I really want this based upon something in the outgoing message,
rather than depending upon DKIM/SPF/etc. for the sending MAILER-DAEMON identity.

I remember that time when CC: local-postmaster was possible.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Sep 2020 19:39:09 -0700

On 9/15/2020 11:15 AM, Brandon Long wrote:
> Forgive me, I assumed it was a joke and reacted in kind.

You assumed that I wrote an internet-draft specification, submitted it, 
and forwarded a copy of the notice to this list was a joke?  A draft 
which contained pointedly mundane specification language, followed 
typically mundane specification style, and had no language, reference or 
apparent indication of irony.  You thought that was a joke?

And you thought that acting on an assumption lacking any meaningful 
foundation was appropriate to pursue in public, in that fashion?

What's most odd is that your usual tone and content of postings in this 
forum are notably professional.

So, forgive me but your forgive me seems just a bit thin.

d/

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 16 Sep 2020 14:27:21 +1000

> forum are notably professional.

As has been seen many time, what would have been immediately recognised by body language in person devolves into misunderstandings via email :(

Dave, Brandon - please let this misunderstanding go and let's get back to the technical detail.

Cheers,

Bron.

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Wed, 16 Sep 2020 01:14:08 -0400

> foundation was appropriate to pursue in public, in that fashion?

To be fair, when I saw the lack of any specified encoding for the emoji text, I
also had a moment of "Who are you and what did you do with the real Dave
Crocker?"....

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 16 Sep 2020 07:22:25 -0500

I sent this yesterday but it appears to have bounced, so I’m trying again…

> Begin forwarded message:
> 
> From: Nathaniel Borenstein <[email-masked]>
> Subject: Re: [ietf-822] New Version Notification for draft-crocker-inreply-react-00.txt
> Date: September 15, 2020 at 8:53:29 AM CDT
> To: Pete Resnick <[email-masked]>
> Cc: [email-masked], [email-masked]
> 

> On Sep 15, 2020, at 9:39 PM, Dave Crocker <[email-masked]> wrote:
> 
> You assumed that I wrote an internet-draft specification, submitted it, and forwarded a copy of the notice to this list was a joke?  A draft which contained pointedly mundane specification language, followed typically mundane specification style, and had no language, reference or apparent indication of irony.  You thought that was a joke?
> 
> And you thought that acting on an assumption lacking any meaningful foundation was appropriate to pursue in public, in that fashion?
> 
> What's most odd is that your usual tone and content of postings in this forum are notably professional.
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Sep 2020 07:20:05 -0700

> Dave, Brandon - please let this misunderstanding go and let's get back 

This would not have been aided by body language.

The IETF is a place of casual disrespect. And the disrespect is 
diligently tolerated, in spite of claims to the contrary.

The usual response to someone's publicly taking exception to the 
disrespect is the sort of posting you've made. It only attends to 
getting rid of immediate discomfort of everyone.  Everyone but the 
person who was disrespected.

This is what makes continues to make the IETF a hostile work environment.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Sep 2020 07:32:28 -0700

On 9/15/2020 10:14 PM, Valdis Klētnieks wrote:
> To be fair, when I saw the lack of any specified encoding

Perhaps folks haven't noticed that my original reply included an 
emoticon? 😟

The low-level issue of encoding might well be necessary to cover in the 
final specification, but it never occurred to me that it was an issue at 
all, given the emoticons are already conveyed successfully.

And it isn't relevant at all to the basic design issues.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Sep 2020 08:36:14 -0700

On 9/15/2020 6:53 AM, Nathaniel Borenstein wrote:
> Reactions != Emojis.  My concern is that this proposal may be making
> a mistake that is the opposite of Facebook’s.  For years Facebook had
> only “like” and got lots of criticism.   They added a few more
> reactions and they now get a bit less criticism.  On the one hand, it
> seems unfair that they have so much power that they can dictate the
> set of acceptable emotional reactions for mankind.  But on the other
> hand, the kitchen-sink list from Unicode.org includes so many icons
> that it’s not clear that people will be able to speak a common emoji
> language and know what each other’s reactions mean.  

1. A graphic is not the same as the 'reaction' it is intended to 
represent.  That's certainly true.  So it's certainly reasonable to 
attend to the nature and method of creating shared mappings between them.

2. Established practice is for a small set of graphics to have 
reasonably consistent use in expressing reactions.  That's a solid 
working set of established mapping. That the practice was largely 
determined by a company isn't important to this specification.  What is 
important is that that practice is a behavioral foundation that 
establishes a basis for expecting market acceptance, here, as well as 
defining an initial working set for use.

3. Allowing people choices beyond that established practice lets them 
expand upon it.  Give a wide population expanded choice and there will 
be abuses and other problems.  That's not an argument for withholding 
choice. It does carry the possibility that additional conventions will 
not develop.  To the extent that that is perceived as a problem, 
organized efforts to create additional conventions are free to develop. 
The mechanism proposed here does not preclude such independent 
effort(s).  It merely takes such work out of the critical path of 
creating a basic mechanism (infrastructure).

4. Constraining choice requires a mechanism for imposing permitted 
choices, selecting emoticons and declaring their semantics in this use. 
  Such mechanisms constitute an ongoing expense and create their own set 
of social and political problems.  IANA might maintain registrations of 
mappings, but they won't decide what goes into the list.  The proposal, 
here, lets the 'mechanism' be the market of users.  And the market of 
developers, some of whom one assumes will create user interfaces that 
offer constrained choices in line with established practice, while 
others will allow more flexibility.

5. The proposal, here, is intentionally trivial.  It seeks to provide as 
simple a mechanism as possible, to make its adoption as easy as 
possible.  It is layered onto regular email messages so that it augments 
use rather than replaces it.  Or rather to make the bottom ("transport" 
mechanism) of the interoperability stack as simple as possible. The 
really challenges are -- and should be -- at the user level, not at the 
conveyance mechanism.  That is, I'm arguing for an end-to-end model that 
minimizes the infrastructure portion...

Anecdote 1:

In the earliest days of the Internet's moving into the mass market, with 
vendors resisting support for open systems, but being forced in that 
direction, they did whatever they could to lock customers into their 
products, since proprietary solutions have higher margins than open 
ones.  A common indicator would be "based on Internet standards", which 
invariably meant that the actual product would /not/ interoperate with 
products of other vendors.

I had many interactions with vendors who were so inclined and I 
developed a simple bit of guidance: "More is better. Different is worse".

The point is to exploit established practice in defining the core of a 
product.  Anything that defeats established practice creates a barrier 
to adoption.  It's fine to /add/ features.  It's not fine to eliminate 
existing, successful features.  Established practice provides the core 
of a product specification.

So while the concern for mapping between meaning and representation has 
obvious legitimacy, that concern should be secondary, here, because 
established practice has already provided a core mapping.

To the extent that anyone wants to insist on having a means of defining 
permissible emoticons to use for this capability, they need to specify 
how that definition will be performed as an ongoing function and explain 
why we should believe that that mechanism will be viable, essentially 
forever.

Anecdote 2:

Part A -- As the Domain Name System developed use, there was pressure to 
define top-level domains (TLD).  Most of the historical drama has been 
about what came to be called 'generic' TLDs, with the original set 
including com, net, and org.  But another demand was for TLDs that 
covered individual countries, since that constituted a significant area 
of independent registration control. Jon Postel was the ultimate 
authority for deciding this and after community debate failed to 
converge he decided that this set of TLDs would be defined by a table 
maintained by ISO.  He stated simply that he didn't want to be in the 
business of deciding what a country was, and that ISO already had a 
functioning mechanism.

Part B -- The original mandate that produced MIME was to add email 
support for 'international' characters. Some of us will recall extremely 
protracted -- many, many months long -- debate about whether we should 
define a new set of conventions or should support an existing set and 
which one.  Unicode had been defined and looked promising but did not 
yet have a sufficiently established base of use and other conventions 
also had use.  The working group ultimately decided to avoid making a 
definitive choice and, instead, defined a mechanism for letting the user 
select which convention to use.  This allowed the market to settle on a 
single choice, if it wanted to, without requiring that.

These demonstrate a useful design philosophy of deferring difficult 
choices, if possible, rather than to take the assignment to make a basic 
mechanism be to comprehensive.

d/

---

From: Brandon Long <[email-masked]>
Date: Wed, 16 Sep 2020 17:58:46 -0700

> So, forgive me but your forgive me seems just a bit thin.

I realize that "it was just a joke" is a thin excuse in general.  I could
further
attempt to explain my rationale, but that is ultimately irrelevant.

Instead, I apologize for my statements.

Brandon

---

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 23 Sep 2020 14:41:24 -0500

On reflection, and on balance, I think I agree with you.  Perhaps an unfettered set of reactions and associated emoticons will function the way hashtags do — a chaotic, unregulated space that takes on a life of its own.

> On Sep 16, 2020, at 10:36 AM, Dave Crocker <[email-masked]> wrote:
> 
> 1. A graphic is not the same as the 'reaction' it is intended to represent.  That's certainly true.  So it's certainly reasonable to attend to the nature and method of creating shared mappings between them.
> 
> 2. Established practice is for a small set of graphics to have reasonably consistent use in expressing reactions.  That's a solid working set of established mapping. That the practice was largely determined by a company isn't important to this specification.  What is important is that that practice is a behavioral foundation that establishes a basis for expecting market acceptance, here, as well as defining an initial working set for use.
> 
> 3. Allowing people choices beyond that established practice lets them expand upon it.  Give a wide population expanded choice and there will be abuses and other problems.  That's not an argument for withholding choice. It does carry the possibility that additional conventions will not develop.  To the extent that that is perceived as a problem, organized efforts to create additional conventions are free to develop. The mechanism proposed here does not preclude such independent effort(s).  It merely takes such work out of the critical path of creating a basic mechanism (infrastructure).
> 
> 4. Constraining choice requires a mechanism for imposing permitted choices, selecting emoticons and declaring their semantics in this use.  Such mechanisms constitute an ongoing expense and create their own set of social and political problems.  IANA might maintain registrations of mappings, but they won't decide what goes into the list.  The proposal, here, lets the 'mechanism' be the market of users.  And the market of developers, some of whom one assumes will create user interfaces that offer constrained choices in line with established practice, while others will allow more flexibility.
> 
> 5. The proposal, here, is intentionally trivial.  It seeks to provide as simple a mechanism as possible, to make its adoption as easy as possible.  It is layered onto regular email messages so that it augments use rather than replaces it.  Or rather to make the bottom ("transport" mechanism) of the interoperability stack as simple as possible. The really challenges are -- and should be -- at the user level, not at the conveyance mechanism.  That is, I'm arguing for an end-to-end model that minimizes the infrastructure portion...
> 
> 
> Anecdote 1:
> 
> In the earliest days of the Internet's moving into the mass market, with vendors resisting support for open systems, but being forced in that direction, they did whatever they could to lock customers into their products, since proprietary solutions have higher margins than open ones.  A common indicator would be "based on Internet standards", which invariably meant that the actual product would /not/ interoperate with products of other vendors.
> 
> I had many interactions with vendors who were so inclined and I developed a simple bit of guidance: "More is better. Different is worse".
> 
> The point is to exploit established practice in defining the core of a product.  Anything that defeats established practice creates a barrier to adoption.  It's fine to /add/ features.  It's not fine to eliminate existing, successful features.  Established practice provides the core of a product specification.
> 
> So while the concern for mapping between meaning and representation has obvious legitimacy, that concern should be secondary, here, because established practice has already provided a core mapping.
> 
> To the extent that anyone wants to insist on having a means of defining permissible emoticons to use for this capability, they need to specify how that definition will be performed as an ongoing function and explain why we should believe that that mechanism will be viable, essentially forever.
> 
> 
> Anecdote 2:
> 
> Part A -- As the Domain Name System developed use, there was pressure to define top-level domains (TLD).  Most of the historical drama has been about what came to be called 'generic' TLDs, with the original set including com, net, and org.  But another demand was for TLDs that covered individual countries, since that constituted a significant area of independent registration control. Jon Postel was the ultimate authority for deciding this and after community debate failed to converge he decided that this set of TLDs would be defined by a table maintained by ISO.  He stated simply that he didn't want to be in the business of deciding what a country was, and that ISO already had a functioning mechanism.
> 
> Part B -- The original mandate that produced MIME was to add email support for 'international' characters. Some of us will recall extremely protracted -- many, many months long -- debate about whether we should define a new set of conventions or should support an existing set and which one.  Unicode had been defined and looked promising but did not yet have a sufficiently established base of use and other conventions also had use.  The working group ultimately decided to avoid making a definitive choice and, instead, defined a mechanism for letting the user select which convention to use.  This allowed the market to settle on a single choice, if it wanted to, without requiring that.
> 
> These demonstrate a useful design philosophy of deferring difficult choices, if possible, rather than to take the assignment to make a basic mechanism be to comprehensive.
> 
> d/
> 
> 
> -- 
> Dave Crocker

---

From: Brandon Long <[email-masked]>
Date: Mon, 28 Sep 2020 17:55:11 -0700

I also agree that it shouldn't be restrained.

I doubt we could come up with a universal set of reactions, and I don't
think universality is actually a requirement, no doubt some communities
will come up with their own reactions (or rather, understanding based on
the available reactions).

Communities often have their own in-language, expressions, memes even.

I also find the "limited" sets of reactions for certain systems to be
entirely too restrictive.

Brandon

On Wed, Sep 23, 2020 at 12:41 PM Nathaniel Borenstein <[email-masked]>
wrote:

> On reflection, and on balance, I think I agree with you.  Perhaps an
> unfettered set of reactions and associated emoticons will function the way
> hashtags do — a chaotic, unregulated space that takes on a life of its own.
>
> represent.  That's certainly true.  So it's certainly reasonable to attend
> to the nature and method of creating shared mappings between them.
> >
> reasonably consistent use in expressing reactions.  That's a solid working
> set of established mapping. That the practice was largely determined by a
> company isn't important to this specification.  What is important is that
> that practice is a behavioral foundation that establishes a basis for
> expecting market acceptance, here, as well as defining an initial working
> set for use.
> >
> expand upon it.  Give a wide population expanded choice and there will be
> abuses and other problems.  That's not an argument for withholding choice.
> It does carry the possibility that additional conventions will not
> develop.  To the extent that that is perceived as a problem, organized
> efforts to create additional conventions are free to develop. The mechanism
> proposed here does not preclude such independent effort(s).  It merely
> takes such work out of the critical path of creating a basic mechanism
> (infrastructure).
> >
> Such mechanisms constitute an ongoing expense and create their own set of
> social and political problems.  IANA might maintain registrations of
> developers, some of whom one assumes will create user interfaces that offer
> constrained choices in line with established practice, while others will
> allow more flexibility.
> >
> simple a mechanism as possible, to make its adoption as easy as possible.
> It is layered onto regular email messages so that it augments use rather
> than replaces it.  Or rather to make the bottom ("transport" mechanism) of
> the interoperability stack as simple as possible. The really challenges are
> -- and should be -- at the user level, not at the conveyance mechanism.
> That is, I'm arguing for an end-to-end model that minimizes the
> infrastructure portion...
> >
> >
> > Anecdote 1:
> >
> products, since proprietary solutions have higher margins than open ones.
> A common indicator would be "based on Internet standards", which invariably
> meant that the actual product would /not/ interoperate with products of
> other vendors.
> >
> product.  Anything that defeats established practice creates a barrier to
> adoption.  It's fine to /add/ features.  It's not fine to eliminate
> existing, successful features.  Established practice provides the core of a
> product specification.
> >
> permissible emoticons to use for this capability, they need to specify how
> that definition will be performed as an ongoing function and explain why we
> should believe that that mechanism will be viable, essentially forever.
> >
> >
> > Anecdote 2:
> >
> including com, net, and org.  But another demand was for TLDs that covered
> individual countries, since that constituted a significant area of
> independent registration control. Jon Postel was the ultimate authority for
> deciding this and after community debate failed to converge he decided that
> this set of TLDs would be defined by a table maintained by ISO.  He stated
> simply that he didn't want to be in the business of deciding what a country
> was, and that ISO already had a functioning mechanism.
> >
> define a new set of conventions or should support an existing set and which
> one.  Unicode had been defined and looked promising but did not yet have a
> sufficiently established base of use and other conventions also had use.
> The working group ultimately decided to avoid making a definitive choice
> and, instead, defined a mechanism for letting the user select which
> convention to use.  This allowed the market to settle on a single choice,
> if it wanted to, without requiring that.
> >

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Sep 2020 18:43:58 -0700

> I also agree that it shouldn't be restrained.
...
> entirely too restrictive.

Excellent.  Maybe that's settled.

But now I'll go a slightly different direction: I'm a fan of the word 
"extensible" and the phrase "priming the pump".

Interoperability is about shared details.

The draft specification does that, to one level, but it might be worth 
putting a tiny layer on top of that:  I'm wondering about adding a 
section the offers and entirely optional initial set to use, so people 
can choose to start with something in common.  If they wish.

This would be a non-normative set -- I don't even see a benefit in 
classing it as a MAY, since, really, it's a tiny subset of the Unicode list.

d/