--On Friday, February 26, 2021 16:51 -0800 Dave Crocker <dcrocker@xxxxxxxx> wrote: > On 2/26/2021 4:24 PM, John R Levine wrote: >> On Fri, 26 Feb 2021, Dave Crocker wrote: >> >> I'd flip it around. What reason do we have to believe that >> any particular restricted vocabulary that we might define >> would be useful to users we don't know and who may not even >> speak any language we speak? > > > cf, the reference to established practice, which is > distinguished from free-form text, which is what you now seem > to be proposing (which is odd, given what stage of processing > this draft is in.) Actually, Dave, I see two families of existing user-facing practice on the input side. Your experience, and John's, is likely broader than mine, so I would not be surprised if there are exceptions to this distinction but I hope it is still useful. (1) An emoji symbol gets picked from a menu (commonly called a "pick list" or equivalent) or possibly a palette (I just used "menu" below). That menu may be a handful of symbols or it may be a few (or even several) hundred, but it isn't 3000 or some much larger (and growing) number [1]. The user typically does not know (or care) whether that symbol represents a single code point or a multi-code-point sequence, only that a grapheme that at least vaguely resembles what they see and will ultimately be seen by the recipient. If, for example, the application wants to make faces with five different skin tones available, that is typically supported by either showing five separate face graphemes or by having the five pop up or pull down when the face is selected -- not by having the user select a face and then an explicit Fitzpatrick modifier. If a user wants to use a response that isn't in the menu, they are just not going to be able to use the response mechanism [2]. And note that I said "An emoji symbol" because most (not all) of the applications that use this approach allow exactly one of them per response although some allow asynchronous responses or several responses in a row. (2) The second category (which I think is much more typically about the use of emoji in running text and attempts to create what might loosely be called sentences in picture-language than about quick "reactions") allows far more flexibility. That usually includes at least some of the ability to intermix emoji characters with text, automatic handling of keyboard shortcuts (UTS#51 Section 6 mentions ":-)" or annotations (ibid.) and to construct arbitrary emoji sequences. Of course, some of these systems allow symbol menus too, but they are just not restricted to them. And while they can often be used to provide a "response", it just typically is not quick (unless the application provides a cache of recent or frequent graphemes). Obviously one advantage of the first category is that, other than users whining about what is not in the menu, it is extremely simple for both users and implementers. The repertoire is known, there is no need to get involved with validation according to UTS#51, and, assuming the repertoire is plausible (<base-emojis> is a start but, as others have pointed out, it is a subset of common practice), no need to worry about whether what goes in at one end will render plausibly at the other. The concerns about rendering and interpretation choices are, as you have pointed out, a different issue.. We may need to agree to disagree about how important it is to address in this spec, even if only as another "health warning" and/or subject on which feedback is sought. The I-D, depending on one's perspective, either intermixes the two categories or talks about the first and focuses on the second. That is confusing and raises issues that sticking more closely to the model of the first category would avoid. I don't think that is necessarily bad for an experimental spec -- in particular, I see no need and have no desire to try to settle the disagreement you and John appear to be having-- but I think text that identifies these issues as part of the experiment is at least desirable and probably necessary. Take "should free Unicode text be allowed in reactions?" as an example and put aside the issue that "text" does not have a uniform meaning in Unicode discussions. The I-D now says "no" even though it may not be easy to figure that out. If the spec is followed strictly, then I think John (and some others, including me on odd-numbered days) are not only predicting it will fail, but that it will probably fail badly enough that the IETF would be wasting the community's time by publishing it. However, put a sentence in somewhere indicating that the choice or all of what UTS#51 allows and only what it allows as an Emoji Sequence (UTS#51, version 13.1, ED-17) is known to be controversial and one in Section 7 asking for feedback on whether users insisted that implementations be more or less restrictive (and whether more or less) would, I think, both solve the problem, considerably improve the experiment, and let us move forward. If you and your co-authors are resistant to putting in those types of sentences --and, again, I'm willing to work with you on precise text as needed once there is consensus about what we intend -- then I am forced to agree with John that the Last Call was premature... and discuss the reasons why there were not complaints about its being premature when it was announced, in some other, broader, context. But, at the moment, I still favor adding qualifying and warning language, expanding the list in Section 7 to include questions suggested by the discussions of the last several days, and then pushing the document out over trying to re-examine basic assumptions or syntax. best, john [1] John has explained where the latter numbers come from. [2[ They could make suggestions to the implementer or proposals to Unicode, but that does them no good in real time. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
