Re: [ietf-822] Review of and suggested changes for draft-crocker-inreply-react-01.txt

[Dave Crocker <[e-mail]>]

On 10/21/2020 6:43 AM, Ned Freed wrote:
> First of all, I think there's at least one more key insight that we need to
> pull out of existing reaction facilities: In many if not most cases they
> operate independently of reply messages. Indeed, this is what makes them so
> attractive: As a user I can offer an opinion of something without having to
> write anything. I just click on a button, up comes a panel of emoji, I make a
> selection, done. (Yes, I realize this is a UI detail, and we don't do UIs,
> but it's such an important capability that it warrants our attention.)


(I'm responding, here, only to the above text, and not yet to the 
proposal that followed.)


In spite of the above text's latter comment on UI detail, it seems to 
confuse UI design with semantics.

Specifically: Triggering a reaction is, in fact, making a reply.

The UI means of doing that are, of course, quite different from typing a 
text reply, and the display of the reaction is handled quite 
differently.  That's possible because the reply is data-typed specially.

In a sense, this is on a par with distinguishing a message's being a 
reply, versus being standalone.  It's created somewhat differently and 
it (can be) displayed somewhat differently (linking it to previous 
messages), by virtue of attaching the In-Reply-To header field.  (Let's 
ignore the earlier, heuristic of matching Subject: text.)


These creation-side and display-side UI differences are hugely 
important, of course, but they don't alter the underlying, transactional 
nature of an affect-indication response, from a free-form text response.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net