[Top] [All Lists]

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

2020-10-22 08:34:17
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.


Dave Crocker
Brandenburg InternetWorking

ietf-822 mailing list