Re: [Last-Call] Last Call: <draft-crocker-inreply-react-06.txt> (React: Indicating Summary Reaction to a Message) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ned,

I think my voice will have been heard here quite enough, so I’ll sum things up here.  Again, I’m in favor of this draft going forward.


While I agree with all of these points, I don't think they are responsive to
what Eliot is suggesting. If I read what he said correctly, the MUA would act
on the authentication indicators by not showing the reaction, not with some
broken link indicator or similar. Since this is a reaction indication, not a
message, the issues with false positives are arguably less. Whether they're
enough less, well, that kind of depends on what you use reactions for.

Consider what you are defining here:  if an MUA designer is adding a reaction button in the message pane a’la FB or LinkedIn (for example), one could easily imagine quite a large number of reactions.  If all you are looking to do is present smiley faces in a message, you don’t need any of this.  You are looking for some sort of aggregation and/or special MUA treatment.  Ok… given that, you should address yourselves  to the risks of that special mistreatment, and what mitigations there may be.

How these reactions will be used will indeed vary, but neither you nor I get to say how they will be used, and thus some words of warning in advance seem appropriate.



Of course the idea of there being a trusted authority of sufficient
universality that someone could code their MUA to use it is a huge
stretch. And this, I think, is where the proposal falls apart.

Universality?  I never claimed any such thing.  However, there certainly are a group of services that are able to reasonably authenticate a good portion of the population. We are, of course, ever limited by the lack of a universally accepted and used authentication model for email.  C’est la vie, but it does have an impact here.


As for the idea of using heuristics, the idea of having an open-ended
suggestion that implementors pick something, anything, for this purpose is more
than a little scary given past experience with the things people use as spam
tests. So absent something more specific I don't think this is a good idea.
Although it is intriguing to think about various checks and latching schemes
and so on. But the siren song of a hack in the making is kind of the problem,
isn't it?

I left things open ended because this is supposed to be an experiment.  If you don’t like the word “heuristics”, consider how Google and Yahoo! deal with this problem and call it whatever that is...

Regards

Eliot

Attachment: signature.asc
Description: Message signed with OpenPGP

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux