On Mon, 28 Sep 2020 at 11:03, Ruslan N. Marchenko <[email protected]> wrote:
> Am Montag, den 28.09.2020, 09:51 +0100 schrieb Dave Cridland: > > > > > > On Sun, 27 Sep 2020 at 16:46, Holger Weiß <[email protected]> > > wrote: > > > > > > I think it would be good to find a better solution. > > > > OK, just out of curiosity, why? > > I for one want that to be formalized. > So far the formal response to that problem in the XEP is mere > acknoledgement of the problem and its declaration to be out of scope. > Which invites for follow-up and resolution. The de-facto state is based > on hell lot of assumptions which are not formalized anywhere. > Message id - not mandated. Message frame storage - not mandated. To > store any data allowing the dedup - not mandated. > > Yes, I wasn't quite right there. I don't mean to suggest there is no solution that is worse than the problem; any solution that is indeed "better" is clearly worthwhile. My suggestion here is merely that so far, solutions proposed have been worse than the problem in terms of traffic efficiency. I accept that is not the only metric, but for me it's a pretty important one. I readily agree that formalizing an approach to deduplication would be a huge benefit - even if we do find ourselves with a better solution. The use of a globally-unique message id, and so on, all seem to be areas within the remit of the sending client, so it feels like we can solve this. > > > > (2) and (3) (and your un-numbered proposal) cause both an additional > > response *and* a further '198 ack back from the client to acknowledge > > that response, which seems dramatically ugly. > > It is in general off-topic but I'd expect behaving client to do > selective 198 ack (window and time based - as per 198's recommendation) > rather than blind _every stanza_, so that does not put major concern to > me. Yes, true. So it's at least one additional stanza received per send, which is still substantially worse than a de-dup based solution. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
