[Standards] LAST CALL: XEP-0308 (Last Message Correction)
Kurt.Zeilenga at Isode.COM
Fri Aug 10 11:59:41 UTC 2012
On Aug 10, 2012, at 4:56 AM, Philipp Hancke <fippo at 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
> "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.
Oh, and maybe I can replace your messages.
More information about the Standards