"WARNING: Consideration of this document has been Deferred by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended."... so I don't intend to consider XEP-0058. It doesn't seem to be the same thing requested for Skype anyway.

How does Skype actually represent these edits? The easiest thing I can think of would be to have a key in every message header indicating the message ID (message-token or the planned protocol-token), and a key in the replacement message's header 'supersedes' (or something) indicating which message to replace.

The idea of discarding the original message worries me, though: it seems as though this basically provides a way to make message history untrustworthy. We should probably specify that UIs should provide access to the old versions until/unless explicitly deleted.

(In reply to comment #1)
> "WARNING: Consideration of this document has been Deferred by the XMPP
> Standards Foundation. Implementation of the protocol described herein is not
> recommended."... so I don't intend to consider XEP-0058. It doesn't seem to be
> the same thing requested for Skype anyway.
> 
> How does Skype actually represent these edits?

IIRC, it changes properties for a message object.

> The idea of discarding the original message worries me, though: it seems as
> though this basically provides a way to make message history untrustworthy. We
> should probably specify that UIs should provide access to the old versions
> until/unless explicitly deleted.

I did not demand that old message versions be deleted, it should be the client's policy. The scheme with a 'supersedes' header looks good to me. (NB: surely there must be an e-mail RFC where we can lift the header name from).

(In reply to comment #2)
> I did not demand that old message versions be deleted, it should be the
> client's policy. The scheme with a 'supersedes' header looks good to me. (NB:
> surely there must be an e-mail RFC where we can lift the header name from).

http://tools.ietf.org/html/draft-ietf-mailext-new-fields-06 calls it Supersedes (and one MUST NOT spell it "Supercedes" ☺). It agrees with the above discussion about leaving what to with the superseded message up to UI policy. Also, it touches upon ethics:

> In general, it is
> not illegal or unethical to change your mind, rather, it shows your
> openness to new ideas and willingness to listen to the arguments of
> other people.

Sjoerd has noted in real life that, in iChat's dialect of link-local XMPP, typing notifications are sent along with the partially-composed text. We could represent these by repeatedly superseding previous versions of a message!

So here's a spec branch which just defines a 'supersedes' header. From the spec:

  supersedes (s – Protocol_Message_Token)

    If present, this message supersedes a previous message, identified
    by its protocol-token or message-token header. The user interface
    MAY, for example, choose to replace the superseded message with this
    message, or grey out the : superseded message.

    | Skype, for example, allows the user to amend messages they have
    | already sent (to correct typos, etc.).

I think this is fine for incoming messages; for outgoing messages we need to solve bug 28740 or have special cases in the UI.

review+ from me for the branch wjt/supersedes in its current state.

(In reply to comment #4)
> Sjoerd has noted in real life that, in iChat's dialect of link-local XMPP,
> typing notifications are sent along with the partially-composed text. We could
> represent these by repeatedly superseding previous versions of a message!

I wonder whether we could have some convention like:

* if a message part has 'truncated':True, and the message is superseded by one where the corresponding part is a superset, UIs SHOULD replace the earlier message silently

* if a message header has 'draft':True, UIs SHOULD indicate it as a partial message, and expect it to be superseded; if that message is superseded, UIs SHOULD replace the earlier message silently

(In reply to comment #6)
> review+ from me for the branch wjt/supersedes in its current state.
> 
> (In reply to comment #4)
> > Sjoerd has noted in real life that, in iChat's dialect of link-local XMPP,
> > typing notifications are sent along with the partially-composed text. We could
> > represent these by repeatedly superseding previous versions of a message!
> 
> I wonder whether we could have some convention like:
> 
> * if a message part has 'truncated':True, and the message is superseded by one
> where the corresponding part is a superset, UIs SHOULD replace the earlier
> message silently
> 
> * if a message header has 'draft':True, UIs SHOULD indicate it as a partial
> message, and expect it to be superseded; if that message is superseded, UIs
> SHOULD replace the earlier message silently

(Do we want to be able to *send* partially-composed text in typing notifications? If so, this comes back to the UI needing to know whether or not the CM supports particular headers.)

(In reply to comment #6)
> * if a message part has 'truncated':True, and the message is superseded by one
> where the corresponding part is a superset, UIs SHOULD replace the earlier
> message silently

So I don't know which protocol this would be for.

> * if a message header has 'draft':True, UIs SHOULD indicate it as a partial
> message, and expect it to be superseded; if that message is superseded, UIs
> SHOULD replace the earlier message silently

This makes sense for representing iChat's drafts.

(In reply to comment #8)
> (In reply to comment #6)
> > * if a message header has 'draft':True, UIs SHOULD indicate it as a partial
> > message, and expect it to be superseded; if that message is superseded, UIs
> > SHOULD replace the earlier message silently
> 
> This makes sense for representing iChat's drafts.

(Though we also need some way to represent the other party never actually sending the message. I guess that's just the CM emitting an empty message with supersedes set.)

((I should wait longer before hitting Submit.))

(In reply to comment #6)
> review+ from me for the branch wjt/supersedes in its current state.

Merged it. The remaining supersedes branch is just WIP for:

> * if a message part has 'truncated':True, and the message is superseded by one
> where the corresponding part is a superset, UIs SHOULD replace the earlier
> message silently
> 
> * if a message header has 'draft':True, UIs SHOULD indicate it as a partial
> message, and expect it to be superseded; if that message is superseded, UIs
> SHOULD replace the earlier message silently

No branch here, retitling.

Blocked by bug #28740 for sending, but not for receiving.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/57.