On Mon, Aug 13, 2012 at 8:00 AM, Gunnar Hellström <[email protected]> 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 [email protected] 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
