On 28 Feb 2018, at 09:35, Jonas Wielicki <[email protected]> wrote: > > On Mittwoch, 28. Februar 2018 10:28:01 CET Kevin Smith wrote: >> On 26 Feb 2018, at 15:59, Simon Friedberger <[email protected]> wrote: >>> So, lest this discussion just die. Here is a proposal: >> Thanks for the proposal. Bashing follows. >> >>> Client-A generates message-ID based on HASH(connection_counter, >>> server_salt). The connection_counter needs to be maintained only for >>> one connection. The server salt is server generated, anew for each >>> connection and is sent to. >>> >>> Server-A checks that this is correct and uses it for MAM. This >>> should make life easier for clients because they only need to deal >>> with one ID. >> >> I think stopping servers being able to use their own IDs for DB storage is >> probably disadvantageous. Although I see the appeal of a client knowing its >> own MAM IDs, I’m not sure that simply knowing it is sufficient - you also >> need to know where it fits into the order of the archive, if you’re going >> to use it for archive sync, so I’m not sure this is actually buying >> anything, at the cost of of lack of flexibility in server implementations. > > Good point about the order. This essentially means that we need a reflection. > Self-carbons essentially. At which point we can simply let the server > generate > the ID(s).
I’m not sure that’s true, as you want to know your ID immediately upon sending - e.g. for following up with LMC you don’t want to wait for roundtrips before you can do that. So I think you want the client to be generating at least some ID used for something. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
