Francesco Gennai <francesco(_dot_)gennai(_at_)isti(_dot_)cnr(_dot_)it> wrote:
Nice to hear from you Francesco!
On Wed, Oct 28, 2020 at 1:50 PM Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
On 10/22/2020 8:05 AM, Dave Crocker wrote:
Ned's MIME-based approach, for carrying the raction emoji's, is better
than using a new header-field, which had some significant drawbacks.
There have been some postings about the original version of the draft,
but not much on the latest revision, which adopted Ned's MIME-based
Any comments, criticisms, or suggested revisions on it?
I like the simpler solution, where the reaction message is only composed
by the top level MIME part.
I think it is more flexible and scalable than a multipart message structure
(mainly by a point of view of a client developer).
Thanks for the feedback.
But, I was thinking:
this nice idea came from the socials where (in some cases like facebook)
the reaction can be an emoji or a comment (or both).
So, why not to define two types of reaction:
- short text (comment)
The short text reaction is similar to a reply by a text message, but will
have a different semantics so that clients developers could use it
in a different way than a reply message.
It's not clear to me how this differs from a regular response, or perhaps
more to the point, how a client would handle it differently.
Emoji reactions and short-text reactions should be carried by two simple
reaction message types. "Simple" is for: a message with only the top level
Well, one of the nice things about this proposal is as long as we make it clear
that the current content-disposition is only defined in conjuction with an
"emoji", we can always extende it later to other uses. But for now I think
keeping the ask we're making of client developers small is a good idea.
ietf-822 mailing list