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

Dave Cridland dave at cridland.net
Sat Jul 26 14:43:27 UTC 2014

On 26 July 2014 12:30, Georg Lukas <georg at op-co.de> wrote:

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

Two small points on this.

Firstly, many of your other comments rely on the uniqueness and stability
of ids. An example is your (7) - this relies on all messages sent from the
same occupant jid having unique ids. You'll probably realise some problems
with this approach fairly quickly if you stop and think about it.

Secondly, RFC 6120, §8.1.3, says:

   It is up to the originating entity whether the value of the 'id'
   attribute is unique only within its current stream or unique

Now, the real question is this: What is the originating entity in the case
of MUC?

We do not, generally, consider that the originating entity of a pubsub
event is the publisher, although semantically this is the case. But for
MUC, we seem to consider the originating entity to be the originating
client - at least when it suits us.

This would make sense if the MUC was a simple stanza relay service, but
it's not. None of M-Link, Openfire, or Prosody implement a 1:1 mapping of
occupant jid to client anymore. In addition, things like history, or
archival access, generate stanzas spontaneously.

In any case, the thing effectively mandating unique id generation for
outgoing messages is NOT XEP-0045, but RFC 6120.

This doesn't invalidate your arguments entirely, but it may well suggest
that RFC 6120 has a technical flaw that needs addressing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140726/c6055e2e/attachment.html>

More information about the Standards mailing list