ietf-822
[Top] [All Lists]

Re: [ietf-822] mappings and mechanisms

2020-09-28 19:55:36
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 
<nsb(_at_)guppylake(_dot_)com>
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.

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

_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822
<Prev in Thread] Current Thread [Next in Thread>