> --On Tuesday, 02 March, 2021 12:49 -0500 Barry Leiba > <barryleiba@xxxxxxxxxxxx> wrote: > > Authors, thanks for this text: I think it's good, and, at > > least to my mind, covers what John Klensin was looking for. > > John, can you live with this text? > > > > As to changing the list in Section 7, the more I talk with > > Dave about it the more I become convinced that the third > > bullet is really all we need. It is broad and vague, but I'm > > not sure there's much value in being more precise: as I read > > that bullet (now, for the 97th time, so it's really deep in my > > brain at this point), it says that we're looking for > > information about any issues that recipients have in consuming > > the results of this... which would cover UI issues, user > > confusion issues, issues involving cultural > > (mis-)understanding, and so on. > > > > John K, if you really think it's critical that we say more > > here, can you please post a bullet or two of specific text > > that you'd like to see added/changed? > Barry, > I have also reread that text several times (perhaps 50 rather > than 97), agree that it can be read as including anything that > happens including catastrophic software failures, outbreaks of > disease, or, given the cultural issues, users being struck by > lightning, that cannot be absolutely proven to not be associated > in some odd way with this feature. The one place that it is not > broad is that it singles out recipients and, if interpreted to > cover the emoji cases, operational problems for originators are > possible too. > On the other hand, the IETF has usually tried to avoid getting > sucked into, or even wanting to hear complaints about, user > interface issues for reasons I vividly remember Dave explaining > forcefully to me and several others many year ago. Because of > the semantics associated with emoji and their binding to > graphemes -- issues that do not arise with what we normally > consider "text", even text in logographic scripts -- this > specification comes very close to that territory. I still think > we should move ahead with it, but believe that being clear that > we are interested in those issue would be useful (I'm not going > to try to make a case for "critical"). However, I don't think it > requires even an extra bullet; see the first suggestion below. > Two possible suggestions: > (1) Change the third bullet to read: > Does the presence of the Reaction capability create any > operational problems, including problems associated with > the handling of emoji characters, for message > originators or recipients? I can already answer this one: Yes, of course it will create problems. The use of inline emoji in regular email subject lines and text is creating problems as I write this; it's nonsensical to think that moving those characters to a different part with a slightly different label will change this in any way. Indeed, if this proves popular it will likely cause more problems, not less. As such, this isn't a valid way of assessing the experiment. The goal here isn't to address the many issues with Unicode emoji; it's to add a new capability to email. We believe that the best mechanism on which to base this new capability is Unicode emoji, but that's in large part due to there being no viable alternative. I completely understand the desire to try and fix problems with Unicode in general and problems with Unicode emoji in particular. But after watching these attempts play out over and over again, in specification after specification, for the past 30 years (yes, it has been that long), and seen the results of our attempts to address these issues, I've become convinced that this isn't even the right venue, let alone the right specification, for that. I also understand that when you don't see the changes you want happening on the Unicode side of things, you want to warn everyone about the possible pitfalls. But we need to be realistic about what's possible here and what's not. For better or worse, anyone implementing this is almost certainly going to use some library or other to do all the Emoji handling. They'll use someone else's emoji picker to select them, they'll use someone else's Unicode display code to present them, and they will use someone else's regexp library to check them. Absent precise articulaion of things that can be done to address specific issues we know exist given such an implementation strategy, any text we add is unlikely to have any impact. And by the same token, in assesing the experiment's results the only thing it's sensible to measure is whether or not the specification got the specifics right. All that said, we do need to know if the capability itself causes operational problems, e.g., lots of clients can't properly deal with the additional message parts. But this needs to be distinct from emoji/Unicode issues. > (2) Add an additional bullet, probably after the current third > one, reading something like: > Does the use of emoji characters pose any special > challenges in processing or to users, including the > issues mentioned in Section NN above? Do > implementations prefer to support only a limited set of > emoji (on either input or output) using a list similar > to the <base-emojis> set or are users permitted to > specify, and receivers expected to be able to render, > the full range of emoji specified by UTS#51? > I think I (slightly) prefer the first, but the second smuggles > in an extra issue, one that others have implicitly raised in the > last 48 hours: what choices implementations make among those > implied by the paragraph starting "The rule base-emojis MAY be > used..." in Section 2. I think it's approprate to ask for an assessment of how many implementations require subsetting, and if they do, what subsets they opted to use, and how. But beyond that we're back in "things we can't fix" territory. Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
