Subject: Re: [Last-Call] New Version Notification for draft-crocker-inreply-react-07.txt

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 25 Feb 2021 16:57:58 +0100

I am asked to repeat comments I have made on this document on the last-call list.

1. Personal comment: Cultural or technical experiment

The document must make it clear whether it is an experiment in technical solution to send simple well formed messages OR if it is a cultural experiment whether people do agree all over the planet what "thumbs up" means.

We already know that differences in culture and norm do vary over the planet, specifically when body parts are involved.

I would personally because of this rather see a signalling mechanism of "agree" or "disagree" or whatever, and then a mapping from these signals to emojis or otherwise indications that can be displayed in the email client or similar.

But, if the document will be about "sending emojis" it must be very very clear that IETF do understand that the meaning of emojis is definitely not the same in different cultures and the conclusion from sending an emoji might surprise people. A lot. Not worse than on social media, but we all know how bad that is.

2. As liaison from IETF to Unicode Consortium

I see the document do specify emoji sequences to make it possible to send such things.

emoji = emoji_sequence
emoji_sequence = { defined in [Emoji-Seq] }

I am strongly objecting to allow any emoji sequences without having a very well defined rule what what they are. This description above is in an EBNF and the spec references is definitely not that clear.

We also do know (see for example SAC-095) how problematic sequences of emoji are and we have definitely not a stable definition of emoji sequences yet.

I.e. I object to allow emoji sequences in this document unless it can be proven the definition is to the same level of clarity as an ABNF (i.e. copied an really included in this specification, just like the "base emoji"). While at the same time saying the field itself is not only one Unicode Code Point but can be more than one.

To summarise, let me say explicitly I do like the document, that it should be published, but, the dangers and dragons within it are still pretty large. Very large. And they have teeth.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Feb 2021 08:59:02 -0800

> I am asked to repeat comments I have made on this document on the last-call list.

Please send a link to that previous message.  I'm not finding it.

Looking at the IETF's IMAP-based Last-Call archive, the only posting I 
see from you, about this draft, is the one you sent today, roughly 6 
weeks after the IESG issued the last call.

> The document must make it clear whether it is an experiment in technical solution to send simple well formed messages OR if it is a cultural experiment whether people do agree all over the planet w…

Forgive me, but:

First, that's a false choice.  For example, there is no obvious reason 
it cannot test /both /of the issues you cite.  In addition, it might 
have additional issues.

Second, the draft is quite clear about what it is that is experimental 
and what questions need to be answered about the draft.

To be specific, please be specific with your difficulties with:

>
>   7. Experimental Goals
>
> The basic, email-specific mechanics for this capability are 
> well-established and well-understood. Points of concern, therefore, 
> are with market interest and with usability. So the questions to 
> answer, while the header field has experimental status are:
>
>   * Is there demonstrated interest by MUA developers?
>   * If MUA developers add this capability, is it used by authors?
>   * Does the presence of the Reaction capability create any
>     operational problems for recipients?
>   * Does the presence of the Reaction capability demonstrate
>     additional security issues?
>
FWIW, I'll suggest that the third bullet covers your concern about 
cultural issues.  If you feel otherwise, please explain.

Not that it's an essential point, but I believe the above list is more 
focused and specific than most other Experimental drafts have.

> We already know that differences in culture and norm do vary over the planet, specifically when body parts are involved.

The 'specifically' part of your sentence surprises me, because although 
it might be true, you are asserting that it is 'known' but you don't 
explain the basis for that knowledge.  (Although the IETF knows quite a 
lot about the technical details of MIME body-parts, the IETF is not a 
place with expertise that makes what you cite a widely known given.)  
Also I'm not aware of studies that substantiate it.

> I would personally because of this rather see a signalling mechanism of "agree" or "disagree" or whatever, and then a mapping from these signals to emojis or otherwise indications that can be displ…

You want the semantics of reader affect to be encrusted in formal 
protocol constructs?  I think the note that Ned posted yesterday 
provides the best rejoinder to that goal.

TL;DR:  1) This is the wrong venue for such work; it predominantly 
requires expertise in topics far outside the skillset of this community; 
and 2) such work is advanced and risky research.  Real research.

> But, if the document will be about "sending emojis" it must be very very clear that IETF do understand that the meaning of emojis is definitely not the same in different cultures and the conclusion…

Based on an exchange with Barry, the latest draft -- which I will submit 
when the submission embargo is lifted -- has:

>
>   4. Usability Considerations
>
> This specification defines a mechanism for the structuring and 
> carriage of information. It does not define any user-level details of 
> use. However the design of the user-level mechanisms associated with 
> this facility is paramount. This section discusses some issues to 
> consider.
>
> Creation:
>     ...
> Display:
>     ...
> Culture:
>     The use of an image, intended to serve as a semantic signal, is
>     determined and affected by cultural factors, which differ in
>     complexity and nuance. It is important to remain aware that an
>     author's intent when sending a particular emoji might not match
>     how the recipient interprets it. Even simple, commonly used emojis
>     may be subject to these cultural differences.
>
If you feel this added text is insufficient, please offer an alternative.

> I am strongly objecting to allow any emoji sequences without having a very well defined rule what what they are. This description above is in an EBNF and the spec references is definitely not that…

1. I don't know what you mean by "what they are".

2. I don't know what you want that would make it clearer.  (I also 
suspect I'll find that I don't agree with you.)

> We also do know (see for example SAC-095) how problematic sequences of emoji are and we have definitely not a stable definition of emoji sequences yet.

1. When citing a document in a forum like this, it helps to provide 
enough information to be able to find that document. You've left us to 
guess what document has that identifier and where to find it.

2. I guessed and believe I found the document you have in mind:

    SSAC Advisory on the Use of Emoji in Domain
    Names
    https://www.icann.org/en/system/files/files/sac-095-en.pdf

    Except that the scope of that document is domain names, which has
    nothing at all to do with the scope of use for this specification. 
    Since you feel the document is relevant, please explain.

> I.e. I object to allow emoji sequences in this document unless it can be proven the definition is to the same level of clarity as an ABNF (i.e. copied an really included in this specification, just…

Sorry, no.  Copying specification details invites divergence. And the 
style of inclusion by reference done in this specification is not that 
unusual.

Also it still is not clear to me what the technical concern is that you 
have, with the way this has been specified.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: "Ricardo Signes" <[email-masked]>
Date: Thu, 25 Feb 2021 21:50:08 -0500

> I am strongly objecting to allow any emoji sequences without having a very well defined rule what what they are. This description above is in an EBNF and the spec references is definitely not that…

It looks like objections have perhaps been rescinded now, but:  I don't understand the nature of this objection, if it stands.

This is not like the use of non-ASCII characters in domain names, because reactions are not used as resource locators.  If a visually confusable emoji is used to replace another, the reader is not misled into arriving at the wrong resource.

It's true that the definition of emoji sequence is not (yet?) entirely stable.  In the context of message content, I'm not sure what teeth the dragon is presenting here.  I agree that I would not want to use this reference to TR51 in specifying many kinds of things, but in this context, I don't see the problem.

-- 
rjbs

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Feb 2021 00:30:16 -0500

--On Thursday, February 25, 2021 21:50 -0500 Ricardo Signes
<[email-masked]> wrote:

>> I am strongly objecting to allow any emoji sequences without
>> having a very well defined rule what what they are. This
>> description above is in an EBNF and the spec references is
>> definitely not that clear.
> 
> It looks like objections have perhaps been rescinded now, but:
> I don't understand the nature of this objection, if it stands.
> 
> This is not like the use of non-ASCII characters in domain
> names, because reactions are not used as resource locators.
> If a visually confusable emoji is used to replace another, the
> reader is not misled into arriving at the wrong resource.

No, but the user may be misled.  Since you mention a dragon
below, consider how would you respond to receiving a single
dragon emoji response and what would assume the sender was
trying to convey?  I can sort of guess given your comment about
teeth, but, if you sent the same symbol/ code point to a Chinese
colleague, I'd hope you would expect a rather different
interpretation.

> It's true that the definition of emoji sequence is not (yet?)
> entirely stable.  In the context of message content, I'm not
> sure what teeth the dragon is presenting here.  I agree that I
> would not want to use this reference to TR51 in specifying
> many kinds of things, but in this context, I don't see the
> problem.

See my last two notes.

best,
   john

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 26 Feb 2021 07:07:18 +0100

> It's true that the definition of emoji sequence is not (yet?) entirely stable.  In the context of message content, I'm not sure what teeth the dragon is presenting here.  I agree that I would not w…

As I introduced the wording of "dragon" and "teeth" while being relaxed over what Adam suggested, here is the explanation.

If the IETF have a formal definition of what is allowed and not allowed, that might imply people for various reasons, regardless of the Postel Principle, take for granted there really is one set of unicode characters in a specific sequence which are allowed, and some that are not. Specifically as the Unicode spec for emoji sequence is VERY detailed talking about what emoji characters can be joined and not, and in what way. This to make the rendering easier, and (what they claim) more predictable and safer. See the SSAC document that I named and Dave linked to (thanks) for examples of such combination of characters and the dangers when comparing them (ordering of characters for example).

This specification in the Unicode spec is as John has explained not stable between unicode versions, and in a very different format than the grammar formats IETF is used to. Because of that, to force people that read the RFC to also understand, parse and correctly implement the Unicode specification is I claim something that just will not happen.

The unicode spec will be interpreted correctly by unicode people. Maybe. It is VERY complicated. Have you tried to implement it yourself? I am just asking, because you might be one of the persons that do understand it. I do not understand all details and can not say what is in there or not given a random sequence of unicode characters. And I normally read Unicode specifications for breakfast since a number of years back.

This is also why I am so explicit saying that it is the _reference_ that is the dangerous thing here. And why I think what Adam wrote is ok, (at least what I read) that the value of the attribute we pass around could be, according to IETF standard, "a sequence of unicode characters" (see John's comment on why you should not talk about octets). This because IETF already (as Adam writes between the lines) know what details and odds and dangers there is with text. Control characters, line breaks and what not.

So even though it might at first look at MORE dangerous to allow the field to be a series of unicode characters, it is from my perspective MUCH MORE safe than trying to get IETF people understand the Unicode Specification of Emoji Sequences.

Thats where from my perspective there is a dragon there, and why the teeth are sharp.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Feb 2021 14:37:20 -0800

John,

On 2/25/2021 9:30 PM, John C Klensin wrote:
> No, but the user may be misled.

And they may not.

>   Since you mention a dragon

The specter you raise is that an author might make a choice that will be 
misunderstood by a recipient.

Since that problem is not going to be solved in its general form, what 
makes it reasonable to impose it here?

What makes this small mechanism worthy of such a great fear?  And 
especially what makes it greater than for the rest of an author's message?

This is a mechanism that provides a very simple context, for conveying a 
very rich array of symbols.  It lets author and MUA developer decide 
what symbols to use.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 26 Feb 2021 17:54:13 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

In every reaction scheme I've seen, from Twitter to Zoom to Slack, you
pick a reaction, and it sends what you told it to send. It's up to the
user sending the reaction to anticipate what the other party will
think of it.

I cannot imagine why we would make this any different.  Send what the
user says to send.

At this point I don't see any compelling reason to limit the reactions
to Unicode emoji and exclude text reactions like :-(

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Feb 2021 15:01:19 -0800

On 2/26/2021 2:54 PM, John Levine wrote:
> to Unicode emoji and exclude text reactions like:-(

Which means that the data in that body-part can be anything, since 
there's no obvious way to restrict it.

That level of data flexibility is likely to make MUA design choices 
pretty limited, which in turn might limit the utility of the mechanism.

For example something like the common mechanism of showing the symbol 
and then putting a count next to it, for the number of responses that 
were received using it, does not work if the 'symbol' can be a long 
string of arbitrary text.

d/

---

From: "John Levine" <[email-masked]>
Date: 26 Feb 2021 19:07:45 -0500

In article <[email-masked]> you write:
>> to Unicode emoji and exclude text reactions like :-( ...

>there's no obvious way to restrict it.

Yup.

>string of arbitrary text.

It only works if there's a small controlled vocabulary, but it doesn't
matter what the vocabulary is.  There are over 3500 Unicode emoji
and exponentially more if you add modifiers like skin tone, so that's
not very controlled either.

>pretty limited, which in turn might limit the utility of the mechanism.

I think we all agree that we are not very good at guessing what MUAs
will do or what UI will turn out to be more or less successful. The
recent discussion with Patrik tells us that trying to pick a small
universal set of emoji won't work. Let the reaction be whatever people
want to send, and if MUAs find, e.g., they feature the same set of
reactions as in some popular IM system, they can do so without asking
us for permission.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Feb 2021 16:16:46 -0800

> not very controlled either.

If there is, really, no limit to what can be put there, then there is, 
really, infinite variety possible for every message, in terms of the 
physical characteristics of what needs displaying.

If the vocabulary is merely graphic symbols, a natural working set will 
develop among a set of users, even if one isn't imposed.

The Ux design constraints between these two are quite different. The 
first is essentially unbounded (and I believe has little field 
experience beyond just being a message body portion.)

The second has quite a lot of field experience and is demonstrably useful.

There is a difference between attempting to specify the details of UI 
behavior, here, versus ignoring potential effects upon such designs.

There is also a difference between offering flexibility just because we 
can, versus offering it because it has clear utility.

d/

---

From: "John R Levine" <[email-masked]>
Date: 26 Feb 2021 19:24:13 -0500

On Fri, 26 Feb 2021, Dave Crocker wrote:
> really, infinite variety possible for every message, in terms of the physical 
> characteristics of what needs displaying.

Well, we can limit it to strings of Unicode.

> develop among a set of users, even if one isn't imposed.

  :-)  :-(  ;-)  ¯\_(ツ)_/¯

> There is also a difference between offering flexibility just because we can, 
> versus offering it because it has clear utility.

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?

I suppose we could say that it might work better if a group of people have 
a shared set of reaaction symbols but I don't see anything we can say that 
wouldn't be vague and obvious.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Feb 2021 16:51:23 -0800

On 2/26/2021 4:24 PM, John R Levine 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.)

d/

---

From: "John R Levine" <[email-masked]>
Date: 26 Feb 2021 20:39:51 -0500

> free-form text, which is what you now seem to be proposing

I see a rule allowing a string of emoji, which we've heard is problematic, 
and a base-emoji rule which has an unupported assertion that it's five 
emoji developed from existing practice, although I'm not aware of any 
existing application that uses that set.  Do you have a reference?  In the 
apps I use, the set of emoji responses differs from one device to the next 
and is invariably very large, hundreds at least.

> (which is odd, > given what stage of processing this draft is in.)

I agree that it was extremely premature to last call this draft.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Feb 2021 22:42:19 -0500

John,

While I agree with your analysis, please see the note I posted
to Adam.  To say part of it differently, one goal of this
discussion (at least the one I'm guilty of starting) is to
assume that there really is consensus that this piece of
protocol should be about emoji and emoji sequences, presumably
covering a very wide range of emoji sequences, and nothing else.
That is what the spec says and it says it very clearly, even if
perhaps more clearly to those with intimate familiarity with the
details of Unicode and the contents of UTS#51 including the
supporting tables than to others.  If that is the case (or at
least our collective assumption), then the goal is to be sure
that emoji and emoji sequences are adequately defined --
"adequately" in terms of being an understandable and
implementable specification and "adequately" in terms of
appropriately setting expectations about the relationship
between what goes in and what comes out, not only in terms of
code points but in terms of graphics, rendering, and
understanding of the response.  I'm trying to get the document
to the point that it does that; my contention is that, through
-08, it didn't and that, while -09 makes a start on the needed
improvements.

Another possibility, and to one to which Dave is objecting if I
understand him correctly, is essentially to argue that there was
no such consensus about reactions consisting solely of emoji
(and emoji sequences, which as you know, is a rather specialized
term in which single-code-point emoji characters are just a
special case).  That would, I believe, require withdrawal of the
document and a new or renewed discussion of what should, or
should not, be allowed in the actual content of the body part.
That would be, as I think Dave has been trying to suggest, a
rather different enterprise.

Again, see the note to Adam.

   john

--On Friday, February 26, 2021 19:07 -0500 John Levine
<[email-masked]> wrote:

>>> At this point I don't see any compelling reason to limit the
>>> reactions to Unicode emoji and exclude text reactions like
>>> :-( ...
> 
>> Which means that the data in that body-part can be anything,
>> since  there's no obvious way to restrict it.
> 
> Yup.
> 
>> For example something like the common mechanism of showing
>> the symbol  and then putting a count next to it, for the
>> number of responses that  were received using it, does not
>> work if the 'symbol' can be a long  string of arbitrary text.
> 
> It only works if there's a small controlled vocabulary, but it
> doesn't matter what the vocabulary is.  There are over 3500
> Unicode emoji and exponentially more if you add modifiers like
> skin tone, so that's not very controlled either.
> 
>> That level of data flexibility is likely to make MUA design
>> choices pretty limited, which in turn might limit the utility
>> of the mechanism.
> 
> I think we all agree that we are not very good at guessing
> what MUAs will do or what UI will turn out to be more or less
> successful. The recent discussion with Patrik tells us that
> trying to pick a small universal set of emoji won't work. Let
> the reaction be whatever people want to send, and if MUAs
> find, e.g., they feature the same set of reactions as in some
> popular IM system, they can do so without asking us for
> permission.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 26 Feb 2021 22:47:06 -0500

Two things here, speaking as he AD who agreed to sponsor what I thought
would be an uncontroversial Experimental document:

1. This is an Experimental draft defining a way to put an (or a few, and
maybe the problem is not keeping it to one) emoji symbol in a reply as a
reaction to the original message, with the idea that said emoji symbol
might be shown in a conveniently streamlined way in the UI.  Variations of
that, such as putting in arbitrary strings, might also be reasonable
experiments, but they’re not this one.  I agree with Dave when he says that
keeping it simpler is better.

2. My personal image of this, which does relate to existing practice, is
based on the iOS Message app.  If I get a text message from someone, I can
long-press the message and get a popup that offers me six symbols to react
with.  Those symbols are a heart, a thumb up, a thumb down, a “ha ha”, two
exclamation points, and a question mark.  Of course, I can compose a text
message in response that has anything else I want to say, including a whole
long string of emoji... but the “reaction” interface is quite simple and
easy.  And when someone sends, say, a heart reaction to me, it’s up to me
to decide whether that means, “What a great photo!”, or “I’m in love with
you!”, or “I’d really like to be your cardiologist.”

I do think that this might be useful, is a worthwhile experiment, won’t
cause any real damage to the email system, and should best be kept simpler,
rather than being made more complicated.

I think text suggestions that add clarification or make the extent of the
experiment clearer are quite reasonable.  But I’m puzzled by objections to
trying it out to see how well it works.

Barry

On Fri, Feb 26, 2021 at 8:40 PM John R Levine <[email-masked]> wrote:

> particular
> Please consider the environment before reading this e-mail. https://jl.ly--
>
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 27 Feb 2021 16:50:58 -0500

--On Friday, February 26, 2021 16:51 -0800 Dave Crocker
<[email-masked]> 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.

---

From: "Ricardo Signes" <[email-masked]>
Date: Sun, 28 Feb 2021 11:59:40 -0500

> solve the problem, considerably improve the experiment, and let

I am sincerely unsure what this paragraph means.

Do you mean that you (sometimes) feel that disallowing (for example) the reaction "Nice!" (that sequence of five characters) is likely to doom the proposal?  Or are you saying that the complexity of validation of the part-content is too high, and that it will too often be done wrong?

As for the proposed remedy, I think I'd need to read more about the way that experimental docs work before I had a clue as to its appropriateness, so I'll leave that to others for now.

-- 
rjbs

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Feb 2021 18:02:21 -0500

--On Sunday, 28 February, 2021 11:59 -0500 Ricardo Signes
<[email-masked]> wrote:

>> even though it may not be easy to figure that out.  If the
>> spec is followed strictly, then I think John (and some others,
>> 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
>> solve the problem, considerably improve the experiment, and
>> let us move forward.
> 
> Do you mean that you (sometimes) feel that disallowing (for
> example) the reaction "Nice!" (that sequence of five
> characters) is likely to doom the proposal?  Or are you saying
> that the complexity of validation of the part-content is too
> high, and that it will too often be done wrong?
>...

Sorry to not have been more clear.

There are a few separate issues getting tangled up here and, if
my paragraph above makes sense at all, it may do so only in the
context of the rest of the note.  To avoid a long message, let
me identify only two of the issues.

(i) Paraphrasing what Dave has said several times (and hoping he
will agree with this characterization), it is unfortunate that
the issues of the definition of what can appear in the body part
were not raised much earlier.  I don't think a debate about why
that didn't occur is helpful: as far as I know, IETF procedures
and precedents have never allowed dismissing substantive
technical objections on the grounds that they were made at an
inconvenient time.  However, AFAIK, all of the discussions of
this draft prior to the last week or so have focused on emoji
and at most one line of emoji.  If free text is going to be
permitted in addition, and multiple lines of free text at that,
it becomes, IMO, a rather different proposal with far less
justification for treating a "reaction" as different from a
text/plain body part with a UTF-8 charset, perhaps with some
sort of priority indication.   I'm not sure Content-Disposition
would not still be the right way to deal with that, but it would
almost certainly a big enough conceptual change to justify
ending the Last Call and going back to discussion on an ordinary
mailing list.

(ii) Free text opens up another issue that we have not discussed
in this context.  I don't see an issue with "Nice!" or even with
"Can of worms".  However, given what the rest of the document
says and the focus on emoji, it seems to me that it would be
important to clarify whether, e.g., 
     Nice! grinning-face
was expected to be interpreted using the relevant graphic, i.e.,
whether parts of the string should be treated as emoji
indicators (or, as UTS#51 would have it, annotations).  If the
answer to the above is "it is all just text" (without thinking
about this much, I think any other conclusion would lead to
madness, especially as emoji are added to Unicode), how about 
    Nice! :grinning-face:
    Nice! \N(grinning-face)     or
    Nice! \u(1F600)
and, if so, which one(s)?

If the answer is that what follows "Nice!" in any of those forms
is that we expect the emoji symbol to be produced, then is
text/plain still appropriate or should we be talking about,
e.g., text/emoji content?

I haven't formed opinions about any of those questions or
options but, because the answers don't seem obvious, if we need
to address them, it would seem obvious we would then have a
somewhat different (and, incidentally, more complex) proposal
that should go back to the ietf-822 list for discussion and
refinement rather than continuing on the Last Call list.

Those questions are, of course, independent of my concerns about
the implications of expecting or wanting to enable tabulation.

It seems to me (YMMD and, to a certain extent, only Barry's
opinion and then that of the IESG count) there are three options
here:

(1) Conclude that my concerns and/or Patrik's about how
<part-content> and <emoji_sequence> are defined in the document
are not significant and just move forward with the document as
is.

(2) Conclude that those concerns are significant but that they
can be dealt with by adding the kind of "health warning" and
"part of the experiment" text I/we have suggested, get that text
added, and move forward with the document.

(3) Conclude, presumably based on the discussion and other
suggestions made in the last week, that the Last Call was, as
John Levine put it, premature and that it should be withdrawn so
that more discussion about what was actually intended can occur,
presumably on the ietf-822 list.

Personally, I am still pushing for (2).  However, I think every
time someone says something like "the part-content should be
allowed to have free text", "multiple lines should be allowed",
"require white space between emoji graphemes", or "we should
restrict (or expand) the <base-emojis> list or restrict <emoji>
to an enumerated list rather than <emoji_sequence> and a broad
reference to UTS#51", and gets any traction, I think it takes us
closer to concluding the document was not carefully enough
developed and discussed and that we should go back to (3).

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 01 Mar 2021 15:58:18 +1100

> to Unicode emoji and exclude text reactions like :-(

I can see the compelling reason, and it's because Dave is trying to define a vespa here, not a monster truck.

Every attempt to bolt on more wheels, spoilers and giant chrome bumpers just because somebody might need them takes what was a very simple experiment and turns it back into the everything spec.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]