There were Internationalization issues raised by John Klensin and Patrik Fältström that need to bbe addressed, and I haven’t seen a response to them yet. The primary one involves cross-cultural understanding of the meaning of emoji symbols, and, thus, weather it makes sense to use the emoji symbols themselves as protocol elements, rather than defining specific protocol elements and letting the implementation select emoji based on regional/cultural custom.
FORM:
- Copying the last-call list, to permit public participation in
this Discuss
- For clarity and accuracy, a reference to prior online activity should point to the specific activity that is meant, rather than leaving the reader -- and, of course, worse, the author -- to guess what the reference is to, as I am having to do here. And the guessing is made more complicated when there are multiple possible venues, as there almost always is. Note that neither John nor Patrick posted comments on the react- draft to the last-call mailing list.
- For the reference to John's concern I am guessing that your
reference is to his only posting on the draft, in the ietf-822
mailing list:
https://mailarchive.ietf.org/arch/msg/ietf-822/hiuC3SbGvGhS0j_vAaEXAk3Hiu8/ - Of the 87 messages concerning the react- draft in the ietf-822 mailing list, none is from Patrick. So I can't even guess at the basis for your referencing him.
- John's note does not contain anything that seems to relate to the concern you raise.
SUBSTANCE:
Discussion of the draft quickly included a focus on I8N issues. This produced major improvements to the draft (and the addition of two co-authors.)
The question of flexibility in choice of emoticon vocabularies was discussed. As I recall, the draft offered a small set of emoticons as a 'core' set, but the draft didn't make clear it's role. The current draft does. In particular it clarifies that that small set is entirely optional and is provided for convenience. The relevant text is:
The rule base-emojis MAY be used as a simple, common list, or 'vocabulary' of emojis. It was developed from some existing practice, in social networking, and is intended for similar use. However support for it as a base vocabulary is not required. Having providers and consumers employ a common set will facilitate user interoperability, but different sets of users might want to have different, common (shared) sets.
Please especially note the last clause of the last sentence.
This leaves me unclear what the specific concern is that you have for the draft and, obviously, what would satisfy the concern.
To the extent that you might be questioning the spec's
'restricting' to only emojis, they are a widely-used convention;
to the extent some groups want to use some other construct, they
are playing in an entirely different sandbox. Revising the
specification to cover them will likely look like the generality
of a MIME body-part.
By way of seeking some comfort in the generality of the current
approach, I came across:
https://emojipedia.org/chinese-new-year/
and clicked down to Moon Cake, to focus on a common cultural reference:
https://emojipedia.org/moon-cake/
That page includes:
Moon Cake was approved as part of Unicode 11.0 in 2018 and added to Emoji 11.0 in 2018.
Which should add some comfort to 'restricting' the specification to use of Unicode emojis.
d/
-- Dave Crocker Brandenburg InternetWorking bbiw.net
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
