[Top] [All Lists]

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

2020-10-29 06:12:29
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:
- 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.


ietf-822 mailing list