> On Mon, 2021-03-01 at 15:00 -0800, Dave Crocker wrote: > > Small additional point: > > > > 1. The base-emoji rule is there to give people something to use if > > they want a set and don't have one of their own. It has no other role; > > it therefore does not matter where it came from. > I like the simple base-emoji rule. After all, to support the full set > of emojis as per the UTS51, you need Unicode 13 support, which is > relatively new. Let's put this into perspective. Unicode 13 added 5930 characters. The overwhelming majority of those (4939 characters) were CJK. Only 65 emoji were added. You can view them here: https://unicode.org/emoji/charts-13.0/emoji-released.html Obviously experiences vary, but none of these are things I've missed having available to express a reaction. > E.g, I wanted to try out the Emoji properties in Perl regexps, and I > found this support was only introduced in Perl 5.32, released in June > 2020. Similarily, GNU libc got Unicode 13 support in August 2020. Given that Unicode 13 was released in March, 2020, that's actually quite impressive. > So - base-emojis may be helpful to get traction for the extension. But > the draft only concerns itself with restricting *sending* to base- > emojis. It does not say explicitly that an implementation which only > understands received base-emojis is allowed or how it should behave > when it processes reaction emojis outside its repertoire. > Possible text, insert new point 4 in processing: > 4. If the part contains code points outside the implementation's > vocabulary, it MAY process them as undisplayable. I think this assigns the base-emoji set a too much importance in the overall scheme of things. But if the consensus is otherwise, I can live with it. Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
