[Top] [All Lists]

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

2020-10-23 10:01:26
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

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.


ietf-822 mailing list