[Top] [All Lists]

Re: [ietf-822] mappings and mechanisms

2020-09-23 14:41:40
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 <dhc(_at_)dcrocker(_dot_)net> 

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

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 

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 

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.


Dave Crocker
Brandenburg InternetWorking

Dave Crocker
Brandenburg InternetWorking

ietf-822 mailing list

ietf-822 mailing list

<Prev in Thread] Current Thread [Next in Thread>