--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
