--On Thursday, February 25, 2021 18:26 -0600 Adam Roach <adam@xxxxxxxxxxx> wrote: > On 2/25/21 18:03, John C Klensin wrote: >> Or, as I think Adam is >> suggesting, we could also allow symbol sequences, possibly >> drawn only from the ASCII symbol repertoire. If we were to do >> that, the question of whether emoji sequences and combinations >> were needed (i.e., whether there was significant user demand >> for them) should be explicitly part of the experiment. > > > My examples were decidedly not limited to those symbols that > ASCII can represent. :) > > I'll also concede that I was going fast and read: > > part-content = emoji *(lwsp emoji) CRLF > > as: > > part-content = emoji *(*lwsp emoji) CRLF > > ...so I was under the impression that the sequences you > describe were already part of the proposal. :) Adam, As Dave has sort of pointed out, turning the <part-content> of the response into "anything that can be expressed in UTF-8" or "anything that can be expressed in UTF-8 with emoji and emoji sequences constrained by UTS#51" or something similar, would be a rather different proposal. My recollection is that something closer to that was discussed during the (Northern Hemisphere) fall and that it obviously did not get enough traction to make it into the document. I find it easy to think of cases where other strings, or textual descriptions of "reactions" would be useful. For example, of course without using the specific body part structure proposed by the I-D, I've responded to a couple of messages within the last 48 hours by top-posting "Brilliant!" and "Great work" and to some other messages with brief disparaging "reactions". None of those comments has obvious corresponding emoji, which may be why they are seen frequently on social media and instant messages as well the the emoji themselves. In that context, if a non-trivial number of people believes that other symbols, free text, or even fewer restrictions would make this extension significantly more useful (or useful at all), I hope the authors and the IESG would be receptive to adding a bullet to Section 7 of the I-D asking if the constraint to emoji made the extension significantly less useful and/or less used, in practice. In particular, if an MUA provides special arrangements for a "reaction" as the I-D seems to suggest and one can send <frowning-face> using the facility but not "Snark!" or "Bleech" I think experience with user interfaces predicts that users will become frustrated with the distinction and either not use the reaction-specific mechanism or whine a lot. However, that makes the question a legitimate part of the experiment; the only important question about it, IMO, is whether it should be called out explicitly in Section 7. While a change to expand the repertoire of what can occur in <part-content> might be desirable, it feels to me late enough in the process that those who want to open that issue should either generate an I-D to modify/update this I-D to change the <part-content> definition to something significantly different and seek sponsorship for it or should ask the IESG to pull draft-crocker-inreply-react until the body part syntax can be sorted out and expanded. I have no idea how the IESG would react to such a request. If they asked me for advice (which I don't imagine they would do), I have no idea how I'd respond. While I have to admit that I find these more substantive discussions about allowed characters and interpretation more interesting, I want to try to concentrate right now (and urge others to do so) on a fairly narrow issue: getting the definition of <emoji> in the current I-D close enough to right that there is a reasonable expectation of implementers, senders, and receivers reaching the same conclusions about what they should do and not do (including about how responses will be interpreted) given the <part-content> production you quote above. And, if there are places where we don't know how to do that or cannot agree, let's explicitly identify those places in the document where problematic definitions can be found and then identify figuring out whether there are problems in practice (and, if so, what they are), as part of the experiment. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
