[Top] [All Lists]

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

2020-09-15 13:24:04
On 15 Sep 2020, at 10:59, Dave Crocker wrote:

On 9/15/2020 5:21 AM, Pete Resnick wrote:
Someone asked me about this feature some years ago when social media was becoming popular and I suggested simply adding a disposition to Message Disposition Notification (RFC 8098, STD 85). The machinery is already in some systems, MDNs give you the ability to easily get back to the source message through Message-ID,

So does normal reply functions.

Most, though I know of several clients (web-based and mobile) that don't do In-Reply-To and References correctly. That said, those likely don't support MDN either, there's going to have to be some UI added to get this useful, so it is probably a wash.

How does the person who is reacting also add a comment or extended text or..., if they want to?

In the body of the message. Remember, MDNs are multipart/report. If you look in the examples in 8098 you'll see a text part (normally presented to the user as a normal message) followed by the message/disposition-notification part which contains the details of the original message and a "Disposition", which in this case could contain "reaction", and some additional information indicating the type of reaction.

No new mechanism needed and I think somewhat quicker deployment. It would probably just take an Informational document with a pointer to STD 85.

I think that if you break down the implementation details carefully, you'll find that the effort for my proposal and the effort for yours will be about the same. They sit on top of different 'interfaces, but the effort to add to them probably isn't very different.

That's probably true. Either way, you'd want a bit of new UI on both ends too. I know some clients already have UI for pushing the "I read this" button and generate an MDN in response. Changing that to a drop-down list of reactions and adding a different disposition parameter seems pretty straightforward.

Except that your proposal adds a capability that has less flexibility.

Actually, I think quite the opposite. You get the comment or extended text, plus a lot more flexibility to add different sorts of parameters into the message/disposition-notification part.

On 9/15/2020 5:25 AM, Pete Resnick wrote:
Was this a specific ask (as in someone wants to implement something
like this), does someone have code to do this already, or is this
just an idea for new functionality?
One of the nice things about an environment that intends to evaluate proposals on their merits, rather than, say, their politics, is that the source of the proposal shouldn't matter. So I'm not clear what difference the answer should make or why you are asking.

Oh, I definitely wasn't interested in the politics. I was asking to see if there was already pre-deployment of the mechanism, which might lean toward continuing down that code path instead of doing new engineering on current MDN codebases, or if it fit very well in an existing code base, where something like MDN wouldn't. That would make a difference, IMO.

In any event, the proposal was motivated by my finding myself constantly wishing I could make a quick response to an email the same way I can to a social networking posting, and feeling unhappy that I can't just click on a smiley (though my own tendency is more often to click on the crying emoticon, these days.) I think the mechanism has become an extremely efficient way to give very basic responses. I'd like email to permit that efficiency.

Yep, I think, whichever mechanism is used, the functionality would be a nice little addition.

I can try to write up a quick draft of using MDN to compare and contrast.

Pete Resnick
All connections to the world are tenuous at best

ietf-822 mailing list