ietf-822
[Top] [All Lists]

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

2020-10-23 10:33:02

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

It's not obvious to me that this is true. (In fact, I suspect it isn't.) So feel free to provide a comparison between the two approaches, in terms of affects on 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.

There is an appeal of 'purity' in having a reaction be in a message containing only a reaction. The downside is that email is relatively slow and there is an appeal in permitting commentary to be carried in the same message as the reaction. (It isn't uncommon in social media to mark a reaction and then write a comment.)


1. There will be users who won't care about emoji reactions and will be
annoyed by them.

For any action, there is an equal and opposite reaction. In this case that means doing anything is certain to result in someone, somewhere being unhappy about the action. Ultimately, this is a user-to-user issue, not something to fix in the software...


 Being able to filter out messages by header-field is a
fairly common feature of email clients.

Yes, but it's one of many features that average users do not know about and have no motivation to learn.


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.

+1


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.

+1


3. Clients would most likely want to hide reaction messages

Why?


 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.

They don't have the construct of 'carrying' anything. But it's common to be able to mark a reaction AND post a comment.



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822