Thanks, John; having those suggestions to consider is really helpful. Barry On Tue, Mar 2, 2021 at 4:08 PM John C Klensin <john-ietf@xxxxxxx> wrote: > > > > --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? > > (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. > > To me clear, my motivations with regard to Section 7 are > different from those associated with issues in the rest of the > document. For the others, my goal was to make the document > accurately reflect what the document was intended to specify. I > believe that people being surprised that the document specified > only emoji and did not allow plain text and that others assumed > a pick list and a small repertoire are symptoms that it was no > clear enough (or that few people paid any attention to what it > actually specified it before the other issues were raised). > With regard to Section 7, however, my belief is that, if the > IETF is going to propose an experiment to the broader community, > we should strive to get as much information out of the > experiment as possible. In that context, questions that people > don't think have been asked and problems they have not been told > to look out for and report seem less likely to generate good > feedback than our being somewhat more explicit. I'll leave to > others whether that goal rises to "critical" or not. > > john > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
