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>
wrote:
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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822