On 25 July 2014 18:24, Kevin Smith <ke...@kismith.co.uk> wrote: > On Fri, Jul 25, 2014 at 6:08 PM, Philipp Hancke > <fi...@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 <ge...@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. Regards, Matthew
