Proposals

[deckar01]

Proposals should summarize a strategy for constructing an email that represents modifications to a previously sent email.

Considerations:

• How should the previous email be identified?
• How should the email content look in a client that does not support the protocol?
• How should the change be encoded so that it can be parsed by a client that supports the protocol?
• How should multiple changes be resolved?

[deckar01]

How should the previous email be identified?

• The Message-ID email header of the original email
  • Should be placed in the In-Reply-To email header of the update email
• The From email address of the update email
  • Must match the From email address of the original email

How should the email content look in a client that does not support the protocol?

• It should be chosen by the sending client
• It should contain a human readable plain text and/or HTML message including any combination of:
  • A brief note summarizing errors and corrections
  • The complete, revised email
  • Modified lines
  • Surrounding lines of context
  • Highlighted additions
  • Highlighted removals

How should the change be encoded so that it can be parsed by a client that supports the protocol?

• GNU Diffutils diff and patch
• MIME alternative content
• MIME content type text/diff

How should multiple changes be resolved?

• Multiple changes received for the same Message-ID
  • Should be applied in the order they are received
• Subsequent changes:
  • Should set In-Reply-To to the Message-ID of the last update email that modified the message
• Conflicting changes
  • Should be ignored
  • Should fall back to text/HTML content as if it was a reply
• Changes with In-Reply-To specifying an unknown Message-ID
  • Should fall back to text/HTML content as if it was a reply
  • Should be applied if a change with a matching Message-ID is later recieved

[deckar01]

After discovering the registration process for MIME extensions I was able to find an existing extension that supports the desired operation.

2.1.46.  Header Field: Supersedes

   Description:
      Reference message to be replaced

   Applicable protocol: Mail [18]

   Status: standards-track

   Author/change controller:
      IETF  (mailto:iesg@ietf.org)
      Internet Engineering Task Force

   Specification document(s):
      RFC 2156 [10]

   Related information:
      Reference to a previous message being corrected and replaced.
      Renamed version of obsolete 'Obsoletes' header field.  RFC 2156
      (MIXER); not for general use.

https://tools.ietf.org/html/rfc4021#section-2.1.46

The "Special handling of Supersedes" section in https://people.dsv.su.se/~jpalme/ietf/message-threading.html suggest that mail client may not support supersedes in order to avoid confusion.

This seems to be a UX problem that should be revisited now that applications supporting comment threads that allow editing have matured.