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:
FWIW, I'll suggest that the third bullet covers your concern about cultural issues. If you feel otherwise, please explain.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?
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.
-- Dave Crocker dcrocker@xxxxxxxxx 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@xxxxxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
