John, While I agree with your analysis, please see the note I posted to Adam. To say part of it differently, one goal of this discussion (at least the one I'm guilty of starting) is to assume that there really is consensus that this piece of protocol should be about emoji and emoji sequences, presumably covering a very wide range of emoji sequences, and nothing else. That is what the spec says and it says it very clearly, even if perhaps more clearly to those with intimate familiarity with the details of Unicode and the contents of UTS#51 including the supporting tables than to others. If that is the case (or at least our collective assumption), then the goal is to be sure that emoji and emoji sequences are adequately defined -- "adequately" in terms of being an understandable and implementable specification and "adequately" in terms of appropriately setting expectations about the relationship between what goes in and what comes out, not only in terms of code points but in terms of graphics, rendering, and understanding of the response. I'm trying to get the document to the point that it does that; my contention is that, through -08, it didn't and that, while -09 makes a start on the needed improvements. Another possibility, and to one to which Dave is objecting if I understand him correctly, is essentially to argue that there was no such consensus about reactions consisting solely of emoji (and emoji sequences, which as you know, is a rather specialized term in which single-code-point emoji characters are just a special case). That would, I believe, require withdrawal of the document and a new or renewed discussion of what should, or should not, be allowed in the actual content of the body part. That would be, as I think Dave has been trying to suggest, a rather different enterprise. Again, see the note to Adam. john --On Friday, February 26, 2021 19:07 -0500 John Levine <johnl@xxxxxxxxx> wrote: > In article <cf05c85a-1674-5c23-2eff-6d5b7f9a3736@xxxxxxxx> you > write: >> On 2/26/2021 2:54 PM, John Levine wrote: >>> At this point I don't see any compelling reason to limit the >>> reactions to Unicode emoji and exclude text reactions like >>> :-( ... > >> Which means that the data in that body-part can be anything, >> since there's no obvious way to restrict it. > > Yup. > >> For example something like the common mechanism of showing >> the symbol and then putting a count next to it, for the >> number of responses that were received using it, does not >> work if the 'symbol' can be a long string of arbitrary text. > > It only works if there's a small controlled vocabulary, but it > doesn't matter what the vocabulary is. There are over 3500 > Unicode emoji and exponentially more if you add modifiers like > skin tone, so that's not very controlled either. > >> That level of data flexibility is likely to make MUA design >> choices pretty limited, which in turn might limit the utility >> of the mechanism. > > I think we all agree that we are not very good at guessing > what MUAs will do or what UI will turn out to be more or less > successful. The recent discussion with Patrik tells us that > trying to pick a small universal set of emoji won't work. Let > the reaction be whatever people want to send, and if MUAs > find, e.g., they feature the same set of reactions as in some > popular IM system, they can do so without asking us for > permission. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
