[Top] [All Lists]

[ietf-822] mappings and mechanisms

2020-09-16 10:36:40
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 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.


Dave Crocker
Brandenburg InternetWorking

Dave Crocker
Brandenburg InternetWorking

ietf-822 mailing list

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