From 1d4e21f57fd124f264eff8c942c81f673a1438c1 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 7 Oct 2020 11:38:20 +0200 Subject: [PATCH 1/9] 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 @@ ... ]]> -

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.

+

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.

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.

From 7b1f463d2fc6ff5b36fff6dd8c17bb7686b864f1 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 14 Oct 2020 16:49:22 +0200 Subject: [PATCH 2/9] 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 @@ ... ]]> -

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.

+

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.

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.

From ca1a1a48e1a1e255c5ac4c817d27ee22a9df2fa0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Wed, 14 Oct 2020 16:53:48 +0200 Subject: [PATCH 3/9] XEP-0352: Accept as Draft --- xep-0352.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xep-0352.xml b/xep-0352.xml index 3502747a..46e67ac1 100644 --- a/xep-0352.xml +++ b/xep-0352.xml @@ -10,7 +10,7 @@ This document defines a way for the client to indicate its active/inactive state. &LEGALNOTICE; 0352 - Proposed + Draft 2020-08-18 2017-12-21 2017-11-15 @@ -28,6 +28,12 @@ csi &mwild; + + 1.0.0 + 2020-10-14 + XEP Editor (jsc) + Accepted as Draft as per Council vote from 2020-08-26. + 0.3.0 2018-11-08 From b96c1415655c2648bdae32e70b7eb6708e33df0b Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Fri, 16 Oct 2020 12:21:13 +0200 Subject: [PATCH 4/9] XEP-0443: added section about a/v calls --- xep-0443.xml | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/xep-0443.xml b/xep-0443.xml index f4c62126..318d4cde 100644 --- a/xep-0443.xml +++ b/xep-0443.xml @@ -114,7 +114,7 @@

The following changes were made to the Compliance Suites since &xep0423;:

    -
  • TODO
    • +
  • Introduced new category for A/V Calling.
 @@ -457,6 +457,62 @@
  • &xep0286;
    •  + +

    + To be considered XMPP A/V calling compliant, all features from the core + compliance category must be met, as well as all features in this suite. +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureCore ServerCore ClientAdvanced ServerAdvanced ClientProviders
    Call SetupN/A&yes;N/A&yes;&xep0167;, &xep0353;
    TransportN/A&yes;N/A&yes;&xep0176;
    EncryptionN/A&yes;N/A&yes;&xep0320;
    STUN/TURN server discovery&yes;&yes;&yes;&yes;&xep0215;
    Quality and Performance improvementsN/A&no;N/A&yes;&xep0293;, &xep0294;, &xep0338;, &xep0339;
    +

    This section outlines the protocol specifications that are relevant for From 1a5db6ffc06f48e86e38eb6ae8587c960d156ef1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Oct 2020 16:22:01 +0200 Subject: [PATCH 5/9] XEP-0443: Add revision block --- xep-0443.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0443.xml b/xep-0443.xml index 318d4cde..3ce85d04 100644 --- a/xep-0443.xml +++ b/xep-0443.xml @@ -62,6 +62,12 @@ georg@op-co.de georg@yax.im + + 0.2.0 + 2020-10-20 + dg + Added section about A/V calls + 0.1.0 2020-10-06 From e228dc943183bd4893edd369e55bd13b6f3692a4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Oct 2020 16:25:06 +0200 Subject: [PATCH 6/9] XEP-0443: Issue Last Call Council vote from 2020-10-14. --- xep-0443.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0443.xml b/xep-0443.xml index 3ce85d04..76f7d0ee 100644 --- a/xep-0443.xml +++ b/xep-0443.xml @@ -22,7 +22,8 @@ &LEGALNOTICE; 0443 - Experimental + Proposed + 2020-11-03 Standards Track Standards From 93850218c00a5c673d660ddf6a886455bff37bc9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Oct 2020 16:26:51 +0200 Subject: [PATCH 7/9] Move XEPs which have LCs from previous council to Deferred MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It makes no sense to re-issue the LC for this council, it won’t end properly anyway. --- xep-0292.xml | 2 +- xep-0353.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/xep-0292.xml b/xep-0292.xml index a049ff27..2f93e6b1 100644 --- a/xep-0292.xml +++ b/xep-0292.xml @@ -10,7 +10,7 @@ This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. &LEGALNOTICE; 0292 - Proposed + Deferred 2019-02-19 Standards Track Standards diff --git a/xep-0353.xml b/xep-0353.xml index 401d3714..8c971b82 100644 --- a/xep-0353.xml +++ b/xep-0353.xml @@ -10,7 +10,7 @@ This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource. &LEGALNOTICE; 0353 - Proposed + Deferred 2019-08-13 Standards Track Standards From c8cbe59684f90788df31b53b9421c7bca52fb3a4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Oct 2020 16:27:57 +0200 Subject: [PATCH 8/9] XEP-0411: Accept as Draft --- xep-0411.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xep-0411.xml b/xep-0411.xml index 8812e32e..fd02ebd3 100644 --- a/xep-0411.xml +++ b/xep-0411.xml @@ -10,7 +10,7 @@ This specification describes a method to migrate to PEP based bookmarks without loosing compatibility with client that still use Private XML. &LEGALNOTICE; 0411 - Proposed + Draft 2020-10-14 Standards Track Standards @@ -29,6 +29,12 @@ daniel@gultsch.de daniel@gultsch.de + + 1.0.0 + 2020-10-20 + XEP Editor (jsc) + Accepted as Draft by vote of Council on 2020-10-14. + 0.2.1 2020-05-25 From ba8176e3288ab105301ddff38bc749ad3a7c830a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Oct 2020 16:30:20 +0200 Subject: [PATCH 9/9] 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 @@ message-correct &ksmith; + + 1.2.0 + 2020-10-20 + gl +

    Reword note about how to handle LMC in cases where it is not clear that all recipients support it.

    + 1.1.0 2019-05-15