Re: [Last-Call] New Version Notification for draft-crocker-inreply-react-07.txt

[Kjetil Torgrim Homme <[e-mail]>]

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.