> --On Monday, 01 March, 2021 15:58 +1100 Bron Gondwana > <brong@xxxxxxxxxxxxxxxx> wrote: > > On Sat, Feb 27, 2021, at 09:54, 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 :-( I can. Reactions have to have the proper appearance in a user interface. "Emoji style" rendering is designed to meet that need, and it's the required default for Unicode Emoji. So for the most part if you send an emoji to whatever UI toolkit you're using you're likely to get something acceptable. Some non-Emoji character, not so much. Now, you can specify Emoji style rendering for any character (variation selector 16, U+FEOF). The trouble is, it seems that almost nobody supports it. (The likely reason for that is doing so not only requires having a huge number of additional character forms, it also isn't at all obvious how you do stuff like, say, maintain the distinction between single and double width characters. AFAIK all of this is completely undefined.) Amusingly, a similar problem occurs when you want Emoji to render as regular text (U+FE0E). This isn't well supported either, but the good news is we don't have to care. > > I can see the compelling reason, and it's because Dave is > > trying to define a vespa here, not a monster truck. Indeed. It may seem simple to open the door to any character, but it's really a pretty major change. > > Every attempt to bolt on more wheels, spoilers and giant > > chrome bumpers just because somebody might need them takes > > what was a very simple experiment and turns it back into the > > everything spec. > Bron, I agree with the principle and share your belief that what > was intended was an extremely modest and focused extension. > Certainly that is what the discussion that I think started in > September was about and I don't recall any discussion that would > have led to even a medium-sized limousine. > However, the specification as now written incorporates all or > UTS#51, a long (very long if the required supporting tables are > considered( specification of what several people outside the > IETF have described as a Unicode-based picture language of very > high complexity that is necessary to understand. It defines > emoji combining and qualifying characters and has specific rules > about whether consecutive emoji code point combine into a single > graphic image or remain separate and whether, and how, that is > separated by ZWJ, and so on, including multiple types of > combining sequences each with its own rules. This is only true if you're writing your own full-on Unicode rendering engine, in which case I rather suspect that by the time you get to worrying about UTS#51 you will have faced so many other problems getting past UTS#51 won't be that difficult. However, I would be *tremendously* surprised if anyone coding this in a user agent would go to the trouble of writing such a renderer. And even if you're writing the back end of such a thing, the odds are you're going to delegate the handling of Unicode to a library like HarfBuzz. The odds of such a library not having Emoji support are low. And frankly, if for some reason this amount of coding necessary because existing renderers lack some crucial ability, the experiment is guaranteed to fail no matter what cautionary words we put in the text. > Incorporating UTS#51 that way probably should require text > about, for example, whether validation is required, Being to > use what is permitted requires very different models of the Ux > than what I think most of us were anticipating and what is > justified by the type of current practice that has been pointed > to to justify this experiment. We have a vast number of specifications, including most of the email ones, that operate by specifying what must or should be emitted by compliant implementations. Which is what this one does as well: We define what a valid reaction part looks like, and that includes restricting the text content. In few if any cases do we bother to say stuff like, "Implementations MUST validate header fields containing addresses before displaying them" or, "Implementations MUST validate a requirement that a particular MIME part is of the proper type". We leave it up to implementations to decide when this is appropriate. Maybe we should in fact be calling for validation where we think it's critical, but we don't. And absent some really compelling reason why this case is different - something I have not seen - an experiment in sending reactions around strikes me as exactly the wrong time to start. > That situation exists with draft-crocker-inreply-react-09, with > no specification, a definition that essentially amounts to > "anything that UTS#51 allows is permitted and anything it does > not is prohibited". That's exactly the intent. And part of the justification for that is it lets email implementors use off-the-shelf components written by people who have already dealt with UTS#51 and everything else below it. > Continuing with your metaphor, I don't see > a monster truck. I see either that Vespa on which someone has > removed the rear wheel and tyre and replaced them with someone > over a meter in diameter without otherwise changing the vehicle > or someone having somehow attached a trailer hitch to the rear > fender and a six-horse trailer to the hitch. Neither is likely > to work well unless people implement what they think the spec > was intended to say rather than what it does say. I'm trying to > restore the possibility of functional Vespa-ness by making the > question of how much of UTS#51 a sensible implementation would > use, and what adjustments need to be made, part of the > experiment. If we don't do that, the spec is due for a trip to > the mechanic to see if there is a way to cut the horse trailer > off and reinstall a proper-sized rear wheel. Again, this assumes a start-from-scratch approach I am skeptical anyone will use. I will also point out that requiring implementation of a profile/subset of UTS#51 may in fact complicate things rather than simplify them. Unless the profile/subset can easily be expressed as some kind of pattern matching operation - you have now significantly increased, rather than decreased the difficuly of implementing this specification. And to what end? If there was evidence that the widely used UI toolkits out there can't handle some specific aspect of UTS#51 and this is likely to remain the case indefinitely, then it might - and I emphasize might - be cause to mention it in the specification. But I haven't seen such evidence - and I have looked. Indeed, what I have seen is a rather surprising degree of consistency with how various agents render Emoji. To be sure, there are some annoying inconsistencies like how some render most animals as faces whereas others render the entire body, not to mention some oddities like how JoyPixels renders bell pepper in red rather than green. But major omissions? Citations needed. And given the extensibility of Unicode - extensibility that seems certain to be used to increase the number of Emoji in the immediate future - you may end up forcing implementations to maintain yet another copy of the Unicode propety table. I don't think this is a good idea. Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
