Re: [Standards] DRAFT: XEP-0308 (Last Message Correction)
On Tue, Oct 1, 2013 at 7:43 PM, Matthew Wild wrote: > On 30 September 2013 08:31, Mathieu Pasquet 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.
Re: [Standards] DRAFT: XEP-0308 (Last Message Correction)
On 30 September 2013 08:31, Mathieu Pasquet 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. > I’m not sure what the best course of action would be, it seems like a > dead end, apart from requiring servers that rewrite ids to keep the > mappings in order to do an id translation in the correcting messages. 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. Regards, Matthew
Re: [Standards] DRAFT: XEP-0308 (Last Message Correction)
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. As far as I know, Swift can still show messages as corrected because it doesn’t do id checks (at least locally, but I can’t get it to compile at the moment so everything is based only on my memories). I’m not sure what the best course of action would be, it seems like a dead end, apart from requiring servers that rewrite ids to keep the mappings in order to do an id translation in the correcting messages. Regards, -- Mathieu Pasquet pgpMKKk6daoUK.pgp Description: PGP signature
Re: [Standards] DRAFT: XEP-0308 (Last Message Correction)
On 2013-04-08 18:52, XMPP Extensions Editor wrote: Version 1.0 of XEP-0308 (Last Message Correction) has been released. Abstract: This specification defines a method for indicating that a message is a correction of the last sent message. Changelog: Per a vote of the XMPP Council, advanced specification from Experimental to Draft. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0308/diff/0.2/vs/1.0 URL: http://xmpp.org/extensions/xep-0308.html I was thinking of a minor modification: Maybe we could add a business rule for multi-user chats: if the client can track nick changes, it MAY apply a correction from a different fullJID, (different resource) as long as it knows it is the same entity (which contradicts with “A correction MUST only be allowed when both the original message and correction are received from the same full-JID.”). -- Mathieu Pasquet - Poezio Developer
