[Standards] LAST CALL: XEP-0308 (Last Message Correction)

Kevin Smith kevin at kismith.co.uk
Mon Aug 13 07:25:59 UTC 2012


On Mon, Aug 13, 2012 at 8:00 AM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
> On 2012-07-31 22:52, XMPP Extensions Editor wrote:
>>
>> This message constitutes notice of a Last Call for comments on XEP-0308
>> (Last Message Correction).
>>
>> Abstract: This specification defines a method for marking a message as a
>> correction of the last sent message.
>>
>> URL: http://xmpp.org/extensions/xep-0308.html
>>
>> This Last Call begins today and shall end at the close of business on
>> 2012-08-17.
>>
>> Please consider the following questions during this Last Call and send
>> your feedback to the standards at xmpp.org discussion list:
>>
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or
>> to clarify an existing protocol?
>
> Yes, it is a quite important usability improvement.
>
>> 2. Does the specification solve the problem stated in the introduction and
>> requirements?
>
> Yes
>
>> 3. Do you plan to implement this specification in your code? If not, why
>> not?
>
> Yes
>
>> 4. Do you have any security concerns related to this specification?
>
> No other than other last call comments have expressed.
>
>> 5. Is the specification accurate and clearly written?
>
> Yes.
> However.
>
> It does not explicitly state what element of the <message/> that is
> replaced.
> It is clear from the examples that <body/> is what the author thought of.
>
> It mentions some items that shall not be replaced, but apart from that it
> seems to be open for replacing anything that has been delivered in a
> <message/>.
>
> That is both an opportunity and a risk.
> It is an opportunity for other extensions adding elements to the <message/>
> to consider if they want to utilize XEP-0308 for replacing the contents.
> ( this could possibly be utilized by XEP-0301 instead of specifying its own
> way of doing replacements of real-time text, but it requires some more
> specific rules in XEP-0301 about how to apply it in that environment.)
>
> It is a risk that if other extensions adding new message elements do not
> specify if XEP-0308 can replace the contents of the new element.
> interoperability problems may appear, with a sender replacing an element
> that the recipient is not made for replacing.
>
> This could be moderated by inserting a sentence in the Business rules:
> "Extensions specifying <message/> contents should specify if and how it can
> be replaced by the XEP-0308 'replace'."

Thanks for the feedback.

The XEP says that a correction is a replacement for the entire stanza.
I'll make sure I add text to make this clearer.

/K



More information about the Standards mailing list