Hi John, Barry, Ned, Richard, and Dave, Again, very positive about the document. Please just take these comments as input, as you move toward approval. Ned wrote: First, I agree with Dave that this is outside the scope of this specification. Congratulations! You’ve convinced me that this isn’t ready for PS. Going to the experiment goals: o Is there demonstrated interest by MUA developers? My concern is that without answering a few more questions and a bit more detail, you might not get critical mass. I hope that this back and forth has given you a few more. Here are some you could add:
o If MUA developers add this capability, is it used by authors? Who is expected to be an author in this context, and why is this question important to the experiment? o Does the presence of the Reaction capability create any
operational problems for recipients?
o Does the presence of the Reaction capability demonstrate
additional security issues?These are great questions. I hope that at least this discussion has partially answered some already, although proceeding with the experiment would be very useful. the notion that multiple emails from a sender can be ordered in time The Date: field should suffice, and indicates sender intent, which is useful in this case. It doesn’t get below 1 second accuracy, so it’s not perfect. Tie might go to last message received for that message. If you really want to get fancy, you could add an optional sequence number that would help with ordering. That might be something with which people could experiment. Then Ned and Dave both pointed out that there are neither constraints on how many emoji can be sent nor whether the same emoji could be sent multiple times. This raises a question as to how people might use the reaction. Since 1989 (I kid you not!) I (and certainly others) have noodled on how to handle voting. Now “voting” means different things to different people in different contexts. Here are a few examples:
To handle these cases in the experiment, you might want to consider defining one or more optional headers to indicate to the recipient (a) what emojis are allowed and (b) whether duplicates of the same emoji are allowed. Of course, not all of this has to be done in one experiment, but it seems to me that the more you can lay out, the richer the experimentation can be. Here’s what I would suggest: It’s mostly the mailing list case that I am thinking of. The difference between this and other messages is how the MUAs might present the information. So for instance, if you were to spoof a +1 from me to a mailing list, I would very quickly see that note on the list and say, “WOT?!” Now imagine an interface that counts reactions, but doesn’t present the message in any other way. And why would it if it only contained a reaction? Now I would not see a message that I didn’t send. How this is perceived will depend on the culture of the mailing list and its purpose. If there are votes, one could easily imagine people just mindlessly counting reactions. Eliot |
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
