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