I see a rule allowing a string of emoji, which we've heard is problematic,
With precious little evidence to back it up, and no suggestions at all as to a useful alternative. ...
I can see two possibilities. One is to say it's a single emoji, since that seems to be what reaction buttons in existing chat applications do. The other is to say that since it's an experiment, allow any UTF-8 string and let people see what's useful.
John,
You might consider an eye exam, since apparently you can't see
the possibility that is in the draft actually in front of you.
Interesting astigmatism there. Or is it just tunnel vision?
And you seem not to have responded to the point that Ned made.
And your preferences seem to be only that, personal preferences. Rather than an argument for superior functionality, or unworkability for the current draft, or better still, established practice, of the sort the current draft represents.
I seem to recall your lobbying for these preferences during the 2-month discussion on ietf-822, last Fall, also. I don't recall their getting traction then.
Single vs. multiple choices: Having the carriage mechanism -- which is what this draft for -- permit multiple does not require implementations to support that, if they don't want to. If the 'market' prefers to enforce selection of a single choice only, this spec will work just fine for them.
Emoji vs. free text. Other than uninterpreted, free text -- ie, no semantic context -- there is no existing practice for that. If you feel otherwise, please document it.
d/
-- Dave Crocker Brandenburg InternetWorking bbiw.net
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
