[Top] [All Lists]

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

2020-10-23 11:24:42
On 23.10.20 16:46, Ned Freed wrote:
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.

The proposal doesn't mandate it. But currently it's certainly an option
to have a text part containing a reply and a reaction part in the same

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.

Isn't not wanting additional traffic an additional reason to limit
reaction messages to only a reaction? That way people who don't like
them, say on their mailing list, can easily reject those messages
without users being annoyed that they have to resend the text without a
reaction or mailing list software having to rewrite the message to
remove the reaction part.

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.

This is only true if the reaction part is the only part and the
header-field is part of the top-level header.

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.

Again, I believe this is only true if we don't allow multiparts.

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.

It would be a client-side optimization. Not having to issue an
additional command to fetch message bodies certainly doesn't hurt, both
bandwidth- and latency-wise.

But I'm not hung up on this. The restriction to the reaction part being
the only part would be fine for me, too.

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.

I guess I wanted to say that users are used to this limitation and don't
seem to be bothered by it. You can add a reaction and write a comment.
It's two UI operations, it could easily be two different emails.

ietf-822 mailing list

<Prev in Thread] Current Thread [Next in Thread>