On Fri, Jul 25, 2014 at 10:06 AM, Georg Lukas <ge...@op-co.de> wrote:
> Hi, > > XEP-0045, section 7.4 <http://xmpp.org/extensions/xep-0045.html#message> > states: > > "Note well that for tracking purposes this service assigns a new 'id' to > each message it generates (here using a UUID as defined in RFC 4122 [18])." > Prosody's MUC service doesn't do that. Broadcasted messages have the same 'id' as the original (including a missing 'id' attribute). > I suggest changing that line to: > > "The service SHOULD reflect the message with the same 'id' that was > generated by the client. If the client did not provide an 'id', the > server SHOULD generate one 'id' and use it for all reflections of the > same message (e.g. using a UUID as defined in RFC 4122 [18])." > I object to the second SHOULD. Comments on the rest of the message follow. > (The example XML above should be changed accordingly; we might even > replace SHOULD with MUST after the major implementations have changed) > > Rationale: > > A client needs some way to track if a sent message was succesfully > processed and reflected. This is required to indicate success of > transmission, to allow for message correction (XEP-0308), and it helps > in displaying message errors in the context of the outgoing message. > > To determine if a newly received MUC message was indeed the reflection > of the last outgoing MUC message, in theory three elements can be used: > from, id, and body. > > * from: the message 'from' attribute must be the participant's > nickname, however this will also be the case if the participant > is connected with two clients sharing the same nickname, and the > other client sends a MUC message. > > * id: the message 'id' attribute can only be relied upon if the server > does not rewrite it > > * body: the message body could be used to check if an incoming message > is the reflection of the just-sent message. However, some services > rewrite the body, i.e. to replace a large message with a pastebin > link. > > Therefore, none of the three elements can be reliably used to identify > if an incoming MUC message is the reflection of the last outgoing > message. To improve the situation, I suggest changing the XEP in a way > that MUC message reflections keep the original message 'id'. > > Implications: > > This change might violate the uniqueness guarantee of message 'id's, > however as the current behavior is not a MUST, service implementations > exist that do not touch the message 'id', and the world is not falling > apart. > I'll note that there is no uniqueness guarantee in message 'id's. It's entirely up to the sender. I can happily make my client send id="waqas" for all messages forever, and that does not violate the spec. Given a lack of uniqueness guarantees, a server should either be generating IDs for all messages, or it should be generating them for none. Mixed-mode ID generation doesn't make a lot of sense. Using 'id' to match messages doesn't work well. Security issue: I can notice the 'id' on your messages, and can happily send messages with that 'id' to confuse your client. You don't own the value of the 'id'. If you are using this to sync history on reconnect, I can even temporarily take over your nick while you are disconnected, leaving your client with nothing to detect the sync marker being invalid. Given the current text of the XEP, even if this change is accepted, you may not be compatible with existing servers out there, and there's no way to reliably check for compatibility until after you've sent some messages. History sync is one area of XMPP that's terribly broken. All the popular XMPP protocols involving history (MUC, offline messages, PubSub, etc) have large gaps and race conditions, making reliable sync impossible. Heck many of the specs only work on the assumption of synchronised clocks. This is a separate email though. -- Waqas Hussain
