[Standards] RFC: XEP-0045 MUC should not rewrite message IDs

Georg Lukas georg at op-co.de
Fri Jul 25 14:06:59 UTC 2014


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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140725/3c4892d9/attachment.sig>


More information about the Standards mailing list