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

[Ned Freed <[e-mail]>]

> On 22.10.20 17:05, 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.
> >
> > Simply put, a reaction is a form of content, so carry it as content.


> Is the ability to compose a reply message with meaningful text *and* an
> emoji reaction really an important feature of this proposal? It feels
> like this adds a lot of complexity for a case that's unlikely to be very
> popular.

It more or less falls out of the design, so I don't see a reason not to
provide it.

> I propose the following: Return to the header-field. Reaction messages
> should only contain a textual representation of the header value in the
> body for compatibility reasons.

And now you've created an unnecessary silly state. Given that you have
to put the reaction in the body in order to maintain backwards compatibility,
why not take advantage of that fact and *only* put it in the body?

> Not conflating reply text with a summary reaction makes a lot of things
> easier for clients and users.

There's no such conflation in the present proposal. A part that's
marked as a reaction is a reaction only. The fallback to being
treated as a reply is just that: A fallback.

That said, I suppose we could restrict things to reactions having to be a
separate message with a single part. In practice this isn't as much of a
restriction as it appears since an ever-increasing percentage of messages are
structured objects, which can't be combined with a reaction. But there's
already been feedback objecting to the additional message traffic, so I think
this needs to be a decision made by the group.

> 1. There will be users who won't care about emoji reactions and will be
> annoyed by them. Being able to filter out messages by header-field is a
> fairly common feature of email clients. If reaction messages are not
> supposed to contain additional text there's no harm in filtering out
> those messages.

They can do that by filtering on the content-disposition field.

> 2. Using a header-field would make it easy to perform a server-side
> search to find all reactions to a given message. IMAP, for example,
> supports search by header-field. Using a body part would make this a lot
> more work.

Once again, this can be done by looking for the content-disposition.

> 3. Clients would most likely want to hide reaction messages and only
> display the reactions on the original message. By using a header-field
> clients that in a first step only download a set of interesting
> header-fields can identify such messages and never have to download the
> actual body (or body structure).

Absolutely. But someting is very wrong with your IMAP server if the
cost of downloading a body part only a few characters long is an issue.

> To my knowledge social networks don't support "comment carrying an emoji
> reaction to the original message" either. Yes, we are able to do this
> using email. But should we? As a client author I would be very annoyed
> if I had to deal with reaction-only messages that should be hidden and
> messages containing text and also a reaction.

I fail to see the relevance of what's incide the social media sausage factory.

				Ned