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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822