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. 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. 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. In light of this, I think it is a bit unfortunate that support for base-emojis is not mandated, we can in theory get implementations with no overlapping emojis in their vocabulary. In practice, I don't think this is a problem, however. There is little or nothing gained from explicitly leaving out the base-emojis from the implementation's known set. > 2. It is intentional that there is no reference provided, because > providing one would merely create an opportunity to debate whether that > was the right set to choose. :-D I like your set! > 3. If it makes folk feel better, let's call it "daves-emojis" or > "random-emojis". Perhaps we need a new IANA registry for this? I jest, I jest! -- venleg helsing, Kjetil T. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
