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

[Dave Crocker <[e-mail]>]

On 2/25/2021 7:57 AM, Patrik Fältström wrote:
> 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.


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

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 displayed in the email client or similar.

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 from sending an emoji might surprise people. A lot. Not worse than on social media, but we all know how bad that is.

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.


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

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

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
[e-mail]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[e-mail]