From 1d4e21f57fd124f264eff8c942c81f673a1438c1 Mon Sep 17 00:00:00 2001
From: Georg Lukas <georg@op-co.de>
Date: Wed, 7 Oct 2020 11:38:20 +0200
Subject: [PATCH 1/3] XEP-0308: modernize LMC sending rules

---
 xep-0308.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xep-0308.xml b/xep-0308.xml
index fcdf87d5..0a83e17e 100644
--- a/xep-0308.xml
+++ b/xep-0308.xml
@@ -80,7 +80,7 @@
 ...
   </query>
 </iq>]]></example>
-  <p>It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. There may be environments (particularly within a &xep0045; MUC room) where it is unknown whether some or all recipients support this extension, and implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments. It is suggested that when the support of recipients is not known a sending client will make the user aware of the potential for duplicate messages to be interpreted by the recipients.</p>
+  <p>Message corrections sent to clients that do not support them will be rendered as duplicate (corrected) messages. In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it is unknown whether some or all receiving devices support this extension. It is suggested that in these situations a client will allow sending corrections, but will make the user aware of the potential for duplicate messages to be interpreted by the recipients. In restricted environments, implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments.</p>
 </section1>
 <section1 topic='Use Case' anchor='usecase'>
   <p>When a user indicates to the client that he wants to correct the most recently sent message to a contact, the client will resend the corrected message with a new id, and with the replace payload refering to the previous message by id. The receiving client then treats the newly received payloads as completely replacing all payloads of the original message.</p>

From 7b1f463d2fc6ff5b36fff6dd8c17bb7686b864f1 Mon Sep 17 00:00:00 2001
From: Georg Lukas <georg@op-co.de>
Date: Wed, 14 Oct 2020 16:49:22 +0200
Subject: [PATCH 2/3] XEP-0308: weasel-word the weasel-wording some more

---
 xep-0308.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xep-0308.xml b/xep-0308.xml
index 0a83e17e..23578edb 100644
--- a/xep-0308.xml
+++ b/xep-0308.xml
@@ -80,7 +80,7 @@
 ...
   </query>
 </iq>]]></example>
-  <p>Message corrections sent to clients that do not support them will be rendered as duplicate (corrected) messages. In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it is unknown whether some or all receiving devices support this extension. It is suggested that in these situations a client will allow sending corrections, but will make the user aware of the potential for duplicate messages to be interpreted by the recipients. In restricted environments, implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments.</p>
+  <p>Message corrections sent to clients that do not support them will be rendered as duplicate (corrected) messages. In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it is unknown whether some or all receiving devices support this extension. It is suggested that a client should always allow sending corrections, but may make the user aware of the potential for duplicate messages to be interpreted by the recipients. In restricted environments, implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments.</p>
 </section1>
 <section1 topic='Use Case' anchor='usecase'>
   <p>When a user indicates to the client that he wants to correct the most recently sent message to a contact, the client will resend the corrected message with a new id, and with the replace payload refering to the previous message by id. The receiving client then treats the newly received payloads as completely replacing all payloads of the original message.</p>

From ba8176e3288ab105301ddff38bc749ad3a7c830a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= <j.wielicki@sotecware.net>
Date: Tue, 20 Oct 2020 16:30:20 +0200
Subject: [PATCH 3/3] XEP-0308: Add revision block

---
 xep-0308.xml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xep-0308.xml b/xep-0308.xml
index 23578edb..cfeb8c63 100644
--- a/xep-0308.xml
+++ b/xep-0308.xml
@@ -21,6 +21,12 @@
   <supersededby/>
   <shortname>message-correct</shortname>
   &ksmith;
+  <revision>
+    <version>1.2.0</version>
+    <date>2020-10-20</date>
+    <initials>gl</initials>
+    <remark><p>Reword note about how to handle LMC in cases where it is not clear that all recipients support it.</p></remark>
+  </revision>
   <revision>
     <version>1.1.0</version>
     <date>2019-05-15</date>