2015-06-04 11:26 GMT+02:00 Matthew Wild <[email protected]>: > > This revision says that there must only be a single id at any point in > time. This would prevent you from learning the id that a remote MUC > service (or any other entity) assigned it (in case you want to query a > MUC's archive). > > I would probably go for the same approach as the original <archived/> > element in MAM, and have a 'by' attribute (similar also to <delay/>): > > <message-id id="1234-0000-...." by="example.com" /> > > This would also allow clients to use it if they really wanted to, by > putting their JID in the 'by'. >
agreed. Having multiple message-id tags each with their own by attribute makes for a more salable solution than having attributes for each individual propose like client-id, muc-server-id, server-id. On top of that the delay tag has the same attribute which gives us some consistency across different XEPs. And I'm currently not really seeing the point of a client adding an id since the client can already set the stanza id. With an the by attribute we don't have to decide on whether or not there is a use case for the client-id. cheers Daniel
