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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Aug 13 07:00:31 UTC 2012


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'."

>
> Your feedback is appreciated!
/Gunnar




More information about the Standards mailing list