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

[Ned Freed <[e-mail]>]

> 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
> message.

Which means they are separate and not conflated.

> > 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?

Forcing separate messages is funny way to define less traffic,

> 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.

First, as I previously noted, the best way for those not interested in seeing
reactions to achieve that goal is to use a reaction-enabled client and disable
display of reactions.

Second, I am *extremely* skeptical that people who dislike reactions
specifically exist in such numbers to justify mailing list support for
reaction-stripping, let alone torquing the protocol itself in such a fashion as
to cater to their interests.

Third, even if they do exist, mailing lists already commonly provide the
ability to strip attachments, so this just isnt that big of a reach.

> >> 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.

Yes, which is why I suggested seeing if there is general agreement this and
similar use-cases is worth catering to by restricting the protocol to only be 
used in this way.

The bottom line is this entire line of argument hinges on there being
sufficient need to limit the protocol in order to support easier suppression of
reactions. If there's general agreement that there is then I guess I'm OK with
limiting the protocol, but I haven't seen anything like that so far.

				Ned