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

Georg Lukas georg at op-co.de
Sat Jul 26 11:30:11 UTC 2014


* Kevin Smith <kevin at kismith.co.uk> [2014-07-25 18:53]:
> I agree with the intention, but I think making a breaking change to
> xep45 at this point wouldn't be appropriate.

Existing protocols need to be changed occasionally, and I am pretty sure
no point in time is appropriate for that.

However, the change I suggest is not a breaking change, it merely
documents how most implementations do it anyway.

The XEP currently only makes a note that "*this* service" rewrites the
'id'. It does NOT state that every service MUST rewrite it. This is also
why I suggested "SHOULD" for the change: this would allow for
currently-rewriting implementations to go on rewriting or get fixed
eventually, while new implementations will provide the suggested

So please restrain from rejecting my proposal purely on formal grounds.

Regarding the technical grounds, I have re-read the 2010 discussion
about this matter [1], as well as this thread and I found the following

pro rewriting:
 1. the client message and the reflected message are not the same
    message, they only have similar content
 2. server-side error tracking
 3. 'id' uniqueness guarantees can be given by the service
 4. tracking of message 'id's is generally not worthwhile
 5. unique 'id's allow for threading

contra rewriting:
 6. it allows a client to track if its message was successfully reflected
 7. Last Message Correction (XEP-0308) works even without explicit
 support from the MUC

I'd like to address the points in detail:

1) From a purely technical PoV, #1 is surely true, however as a client
developer (or a MUC user, for that matter), I consider what I sent and
what is reflected as the same message, and having the same 'id' value
tremendously helps with tracking this message.

2) Prosody and ejabberd demonstrate that error tracking is possible even
without rewriting the 'id', and it doesn't look like vast server-side
resources are required for that

3) In practice, nobody is relying on the uniqueness of 'id's anyway,
because there are so many broken implementations out there.

4) It actually is worthwhile for a client implementation to track the
'id's it generated itself. Here it does know very well about their
uniqueness, and it can use the JID+id combination to identify message
reflections, message ACKs (XEP-0184) or deploy message correction.

5) The Threading XEP (0201) provides its own unique thread id, which
should be used instead of the message 'id' if a client opts to implement

6) While it is possible to create a new XEP for adding some unique
client-generated message id to each stanza for reflection tracking
purposes, or use another XEP like 0201, using the message 'id' is
straightforward and the least surprising method. This would also make it
consistent with the notion that a message error will carry the same

7) To allow message correction in an id-rewriting MUC, the MUC service
needs to keep track of the mapping between a client's last 'id' and all
the reflection 'id's it created for that client's last message, for each
receiver. This means at least O(N²) storage for a MUC with N
participants and per-receiver unique 'id's.

To summarize: so far I have not seen any convincing technical arguments
in favor of rewriting the message 'id' on reflected messages. If anybody
has such arguments, I would love to hear them. However, keeping the
client-originated 'id' makes (at least) client implementations easier
and less error prone, and allows for better state synchronization (what
you sent vs. what the MUC received).

The formal argument that changing the XEP is bad is true, however this
change would only reflect what major MUC implementations (I tested
Prosody and ejabberd, probably there are more) are doing anyway, while
not explicitly disallowing the id-rewriting implementations.

To comply with Waqas' objection, I would change the second SHOULD into a
MAY, though:

| "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 MAY generate one 'id' and use it for all reflections of the
| same message (e.g. using a UUID as defined in RFC 4122 [18])."

Kind regards,


[1] http://mail.jabber.org/pipermail/standards/2010-November/023949.html
|| 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/20140726/03341924/attachment.sig>

More information about the Standards mailing list