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])." 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])." (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. Kind regards, Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
