> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > In message <26ACFB13-7850-4880-99C1-B1B1FF9E13EA@xxxxxxxxx>, Eliot Lear > <lear=40cisco.com@xxxxxxxxxxxxxx> writes > > There are really two possibilities: reactions are additive, or > > reactions are replacements. I don’t see any real case for > > additive, and quite a number for replacements. For instance, one > > wants to avoid the case where the same sender is being counted as > > multiple +1s, as it were. First, I agree with Dave that this is outside the scope of this specification. I am sympathetic to having a consistent set of semantics for combining multiple reactions in order to avoid least astonishment princple violations, but I don't think we know enough at this point to nail down these details. I also note that this is a lot more complicated than previously stated: Even in the context of a single sender or even a single message additive can mean multiple things: A set union or a count of the number of times an emoji has appeared. (Nothing in the ABNF prevents someone from specifying the same emoji more than once.) > the case for additive would be simplicity of implementation Doing additive right is actually harder to implement - you have to keep track of every message-id in order to deal properly with duplicate messages. With per-sender replacement all you need to track is the message-id and date of the most recent message from each sender, then ignore duplicates and old messages.) > > Here’s my suggestion: > > > > When a subsequent message containing a reaction is received from > > the same source regarding the same original message, it is said to > > have superseded the previous reaction. > > > > Also: > > > > A blank reaction, a reaction containing containing no “emoji” as > > defined in the ABNF in Section 2, is said to have cleared any > > previously received reaction from the source. > > > > That way, one can change one’s mind or correct a mistake. > the notion that multiple emails from a sender can be ordered in time > (without any intervening response from the recipient) is, I think, a new > concept Not remotely new, actually. Sorting by sent date is an option in the IMAP SORT extension (RFC 5256 section 2.2), but I'm pretty sure it was an option in some user agents when I first started using email, circa 1980. But as noted above, you don't need such elaborate capabilities to implement replacement. All you need to keep track of is the most recent. > > I think these suggestions follow the principle of least > > astonishment, but I readily admit I could be wrong. I recognize > > that this requires a reaction database to implement. Yeah, that’s > > a small pain. THAT to me may be the real experiment here. > yes indeed ... to do this correctly it's necessary to record details of > all previously received messages (whether or not they contain the new > feature) if one is to correctly place a newly arrived message (which has > the feature) into the correct place in the sequence before deciding > whether or not the UI needs to be invoked I think you may be misunderstanding the semantics we've defined. Reactions link via in-reply-to. A reply to a reply is a reaction to that reply. Threads are not involved. > I suspect many implementations will not bother... so why specify > something that is most likely going to be ignored ?? Keeping track of the entire ordering isn't necessary AFAICT. > ... now I've never studied how often sequences of email messages are > shuffled out of their sending order before delivery, but queuing > mechanisms in MTAs tend to speculatively try to deliver each new message > and then, if that succeeds, deal with any backlog. Clearly ??? it is not > the intent of this document to affect design decisions here. To the extent that there's a potential issue here, it's probably that transient delivery failures are now sufficiently uncommon that people may assume delivery order is sufficient and not bother to track dates. And who knows? They may be right; arrival ordering may actually work well enough. Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
