On Fri, Aug 10, 2012 at 12:56 PM, Philipp Hancke <fi...@goodadvice.pages.de> wrote: > On Fri, 10 Aug 2012, Kevin Smith wrote: >>> >>> There's no discussion of whether or not this extension can be used in MUC >>> rooms, and if so, what if any discovery is required. >> >> >> Will add, ta. >> >>> I'd argue that, given the nature of this extension, there's little need >>> for any discovery. [[Because corrections are likely to be infrequent and >>> there's fallback built into the protocol.]] Regardless of whether the >>> expectation is or is not that clients send corrections without performing >>> discovery first, the expectation should be stated. >> >> >> I think the expectation is that it's OK to send corrections without >> support being known (MUC etc.), as the body itself acts as a >> correction even without support and no extra stanzas are involved >> (you're going to be sending the correction one way or the other >> anyway), but that it'd be smart to tell the sending user that support >> isn't know. I'll add some text, ta. > > > A MUC service might rewrite the id attribute, see > http://xmpp.org/extensions/xep-0045.html#message > "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)" > > I bet some services do this... making the id at the recipient unpredictable.
We should probably fix MUC on this - I hadn't noticed in the examples what was going on and read the text to mean "The id sent to the room may not be the id you specified" not "Everyone in the room may get a different id" - which will break things. /K
