On Tue, Oct 1, 2013 at 7:43 PM, Matthew Wild <[email protected]> wrote:
> On 30 September 2013 08:31, Mathieu Pasquet <[email protected]> wrote: > > Hi, > > I was checking LME, and trying to understand why I couldn’t get it to > > work properly with jabber.org. I found out that it rewrites message IDs > > everytime, and the same message will not have the same ID on two > > different clients. As I understand it, id preservation is not guaranteed, > > but I can’t find the specification describing this property. This is an > > issue, because if the message id was different from the one sent but > > still the same on each client, we can work around this easily, but if > > each client has a different id, we cannot. > More specifically, M-Link sends each message from a MUC with a different id. I didn't write this bit, but I certainly reviewed it, and agreed it was right. > I vaguely recall that there was some consensus that M-Link's behaviour > is "wrong", and it's the only server I know that does this (not saying > I've tested anywhere near exhaustively). If my understanding on these > two points is correct, perhaps we should slip this into XEP-0045 > before it goes Final. > However I've since changed my mind. The problem isn't that it's not "right" in the purist sense - I still think it is, and our rules for id uniqueness basically state the position clearly enough - but that in cases like XEP-0308, as well as others (message receipts, clients identifying their own messages, etc) it's more pragmatic to ignore that and preserve the id on all outbound messages - despite it being technically questionable. Example: If you have two occupants on a remote server, then preserving the id means that both occupants - with whom the MUC is communicating on the same stream - see the same id. But RFC 6120 § 8.1.3 says the id ought to be unique at least across a stream. However, this is not known to have caused any practical problem in the years many servers have run like this, and moreover, most clients and servers appear to track stanzas by address tuple first, and use id as a secondary identifier. Dave.
