While I understand your rationale, I think it's counter to the rationale of why XEP 45 allows MUC services to generate their own id= attributes on stanzas they forward. As Waqas noted, the id= produced by the subscriber's client may simply not meet the services need for tracking. A service may require all stanzas it produces or forwards to have universally unique ids.
I concur with Kev that it seems far too late to change the spec in this manner. IMO, message correction should only be used in the context of MUC when the MUC service says it supports XEP 308. That might indicate, for instance, that the service is willing to forward subscriber produced ids. -- Kurt On Jul 25, 2014, at 7: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])." > > 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 ||_________________________________________________||
