On Thu, Oct 8, 2020 at 11:13 AM Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
<plea>
What will make the basic mechanism useful to its specific goal,
sufficient as a specification, reasonable to implement, and as simple as
possible without defeating its other goals?
</plea>
If I understood your original point of this spec, it was seeing that
various other tools have such a reaction
mechanism, and the logical plan of bringing that to Email.
Would it be useful to see what those other tools do to make sure we aren't
leaving anything obvious out?
FB has their limited reactions, but it's just adding one, seems compatible
with the draft. There is alt text, but
presumably clients can handle that and there's some obvious handling of alt
text for emojis and it's all on the
client side, no need for anything in the spec. I don't think limiting the
selection of reactions is worthwhile.
Twitter/Instagram only have a single reaction, ditto on not thinking that's
worthwhile.
iMessage I haven't used, but I think it's just adding a limited reaction...
there is a translation for regular
sms as backward compatibility. For email, that would require a whole bunch
of work that's probably not worth
it... though if you think about someone receiving an email message that had
nothing in it and if their client didn't
support this, it would seem like a weird blank email ... so perhaps instead
of an empty message, an
implementation should include fallback support in some way in the body of
the message. The spec could
contain such suggestions, or it could not and just leave that to various
implementations to handle themselves.
No opinion on that.
Some systems have stickers or gifs, some systems (discord, slack) allow you
to add community specific
reactions. This could be handled with some of the url or data formats that
were brought up earlier. Part of
me likes the extensibility of that proposal, and part likes the simplicity
of just emojis. Of course, these can always
be put in the body of the message as well. The stickers/gifs are usually
done in a way that would be compatible with
the body of the message. The community reactions are usually handled like
regular emoji reactions, however.
Emoji's do update frequently, so we could consider some sort of fallback
support... but it seems like most uses I've seen
just fail to properly show the emoji and show an "unknown" character
instead... so adding a fallback system is probably overkill.
So, I don't have extensive usage of these other systems or ones beyond
these, but the simple spec seems to satisfy
the majority of the examples. Hopefully others will speak up if other
systems do more than this.
Brandon
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822