[Standards] Message-IDs

Kevin Smith kevin.smith at isode.com
Wed Feb 28 09:37:10 UTC 2018

On 28 Feb 2018, at 09:35, Jonas Wielicki <jonas at wielicki.name> wrote:
> On Mittwoch, 28. Februar 2018 10:28:01 CET Kevin Smith wrote:
>> On 26 Feb 2018, at 15:59, Simon Friedberger <simon.jabber at a-oben.org> 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.


More information about the Standards mailing list