Re: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-react-03.txt

[Ned Freed <[e-mail]>]

Francesco Gennai <[e-mail]> wrote:

Nice to hear from you Francesco!

> On Wed, Oct 28, 2020 at 1:50 PM Dave Crocker <[e-mail]> wrote:

> > 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
> > approach.
> >
> > 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:
> - emoji
> - 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
> MIME part.

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.

				Ned