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

Kurt Zeilenga Kurt.Zeilenga at Isode.COM
Fri Aug 3 17:24:11 UTC 2012


On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor <editor at xmpp.org> 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.

Edit suggestion: s/marking/indicating/

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


In Section 2, the text "If a server implements message correction" ought to be "If a client implements message correction" or possibly "If an XMPP entity implements message correction".

I note that the discovery example shows a query against a full jid, which of course requires knowledge of the full jid to perform.  There may be use cases where the full jid is not known.  It may be appropriate to note that decloaking (XEP 276) can be used here.

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.

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 thought a bit about correcting messages with multiple body elements, or various elements (e.g., <xhtml/>), and I think the specification is reasonably clear already that the replacement stanza is a complete replacement of the referenced stanza.  But it still might worth being even more clear, adding to the end of 3:  The payload of the original message is completely replaced by the payload of the replacement message payload.

In section 4, I found "To deal with multiple payloads, the sender MUST re-send the entire stanza with only the id and the corrections changed" to be bit confusing as there are other changes to the stanza to be made, in particular the addition of the <replace/> element.  Some rewording might in order here.

The specification is not clear as whether a corrected message can be corrected.  I suggest the specification not, without very good reason, limit itself to a single edit.  It sometimes takes me multiple edits to get a message right.  I suggest the XEP state whether or not multiple corrections are allowed, and if allowed, make sure the "re-send" text is appropriately worded and an example provided.

In the security consideration section, I think the 'warn' in "The replacement message could have an entirely different meaning from the original message, so clients will need to warn users that the displayed message has been edited" is a bit too strong.  I suggest:

	The replacement message could have an entirely different meaning from the original message.  The receiving client SHOULD indicate whether a stanza has been replaced.  It is also suggested that the receiving client provide access to the original message.

There are certain sorts of replacements that I think should be precluded or, at least, cause warnings.  For instance, if the original message was digitally signed and the replacement not, it would be appropriate I think to warn the reader.  I would like to see the digital signed issue specifically mentioned in the security consideration section of this XEP.  Additionally, any XEP providing for digital signatures should cover this.

Also, it also may be appropriate to limit what portions of the original payload can be altered.   In particular, I believe it generally inappropriate for the original and replacement message to have different XEP 258 labels.  This is because different labels implies different authorizations, and this implies that one might receive one or the other of the messages, and this is somewhat problematic in certain security domains.  I might be appropriate to say something like: The XEP 258 <securitylabel/> element SHOULD NOT be edited.  It might be appropriate to add a note to XEP 258 as well here.

I have to wonder if there's other payload elements which should or should not be changed during correction.

> 
> 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?

I believe this specification fills a small gap in the XMPP protocol stack.

> 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?

As a server developer, nothing for me to implement here.

> 4. Do you have any security concerns related to this specification?

Yes, see above.

> 5. Is the specification accurate and clearly written?

For the most part, see above.


> 
> Your feedback is appreciated!




More information about the Standards mailing list