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

Matthew Wild mwild1 at gmail.com
Sat Jul 26 00:35:25 UTC 2014

On 25 July 2014 18:24, Kevin Smith <kevin at kismith.co.uk> wrote:
> On Fri, Jul 25, 2014 at 6:08 PM, Philipp Hancke
> <fippo at goodadvice.pages.de> wrote:
>> Am 25.07.2014 um 09:22 schrieb Kevin Smith:
>>> On Fri, Jul 25, 2014 at 3:06 PM, Georg Lukas <georg at op-co.de> wrote:
>>>> 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])."
>>> I agree with the intention, but I think making a breaking change to
>>> xep45 at this point wouldn't be appropriate.
>> Well, this is not using normative language, just giving a rationale (which
>> is better than any SHOULD without a rationale at least).
>> However, I don't understand what the service gains by tracking ids here.
> No, me neither. As I said earlier, I think (at the moment) 45 would
> have been better to have required stable ids across reflection from
> the start. But as it doesn't, and I don't think requiring them at this
> stage is appropriate.

Even if it's the behaviour of almost every MUC implementation out
there? And there are people not so far away who have influence over
the one implementation that I know does rewrite ids, I believe :)

The current text and examples about servers rewriting id attributes
was only added in the last revision of the document after a push by
some people who back then thought it was the right approach. As far as
I can tell nobody now thinks it is the right approach, and the vast
majority of implementations haven't changed from their original
(non-rewriting) behaviour.

In my view rewriting ids completely breaks the protocol and various
extensions, and we have certainly not yet passed the
point-of-no-return, we should fix it while we can.


More information about the Standards mailing list