(this is an open note, not directed at anyone in particular.)
<rant>
The draft specifies a simple header field, to be added to a regular
email message.
There have been a number of suggestions looking to make enhancements to
this basic model.
Thee suggestions are all predicated on reasonable thoughts, but they
wind up altering the nature of the basic proposal.
They create basic limitations to extensibility or usability, such as by
not having this be a regular email message. Or they start the slide
down a slope of complexity by what really is the start of an effort to
replicate functions that are likely to be useful -- or already are --
but which are separate from signalling a reaction.
The basic proposal is intentionally simplistic and incremental. Just
add a place for signaling a reaction.
Everything else about the message is left unspecified because... it's a
regular email message. Add or don't add whatever would be in a regular
email message.
A regular email message might or might not have a Subject line. It
might or might not have a body. The body might or might not be complex,
such as including an entire survey form. It's regular email.
</rant>
<plea>
What will make the basic mechanism useful to its specific goal,
sufficient as a specification, reasonable to implement, and as simple as
possible without defeating its other goals?
</plea>
d/
ps. besides the encoding issue, which certainly satisfies the plea,
another one in the works modifies the emoji details a bit. A useful
bit. But only a bit.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822