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

[Dave Crocker <[e-mail]>]

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