Thanks Kurt. On Fri, Aug 3, 2012 at 6:24 PM, Kurt Zeilenga <kurt.zeile...@isode.com> wrote: > > On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor <edi...@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/
Don't feel strongly. > >> >> 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". Thanks. > 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. Will mention decloaking, ta. > 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. > 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. Will do, ta. > 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. Will mangle it a bit, ta. > 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. Multiple corrections are fine, but I should make this explicit, ta. > 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. I don't feel all that strongly one way or the other, will change. > 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. I'll add some text for 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'll add a note saying that labels shouldn't be replaced, although I think this is largely arguable depending on deployment. > I have to wonder if there's other payload elements which should or should not > be changed during correction. Possibly. I'll add a generic text telling implementers to consider whether it's appropriate to allow replacement of other payload types included. /K
