From a982331a6ce15ff2755409ddddfe165e1d341d38 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 22 Feb 2017 09:08:06 +0100 Subject: [PATCH 1/9] XEP-0280: improve 'Eligible' wording --- xep-0280.xml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/xep-0280.xml b/xep-0280.xml index eae1a3a4..3e7ea708 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -279,13 +279,11 @@

The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons.

Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers.

-

The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules:

+

The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules. A &MESSAGE; is eligible for carbons delivery if and only if at least one the following is true:

As this is a implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.

Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.

From 7e5e0a587e8584e44d1720173c6fdb9a3db520b9 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 22 Feb 2017 11:27:27 +0100 Subject: [PATCH 2/9] XEP-0280: clearly specify MUC-related rules --- xep-0280.xml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/xep-0280.xml b/xep-0280.xml index 3e7ea708..8d860694 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -284,6 +284,16 @@
  • it is of type "chat".
  • it is of type "normal" and contains a <body> element.
  • it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
    • +
  • it matches the MUC-related rules outlined below.
    • + +

    To properly handle messages exchanged with a MUC (or similar service), the server must be able to identify MUC-related messages. This can be accomplished by tracking the clients' presence in MUCs, or by checking for the <x xmlns="http://jabber.org/protocol/muc#user"> element in messages. The following rules are suggested for MUC-related messages: +

    +

    As this is a implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.

    Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.

    From 289e6c2a1082268af80bf99a810d9085fe00d2c0 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 22 Feb 2017 13:40:24 +0100 Subject: [PATCH 3/9] XEP-0280: wording fix for carbonation rules --- xep-0280.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0280.xml b/xep-0280.xml index 8d860694..fffb7d1d 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -295,7 +295,7 @@
  • A private &MESSAGE; from a local user to a MUC participant (sent to a full JID) SHOULD be carbon-copiedThe server SHOULD limit carbon-copying to the clients sharing a Multi-Session Nick in that MUC, and MAY inject the <x/> element into such carbon copies. Clients SHOULD ignore carbon-copies of MUC-PMs related to a MUC they are not joined to..
  • A private &MESSAGE; from a MUC participant (received from a full JID) to a local user SHOULD NOT be carbon-copied (these messages are already replicated by the MUC service to all joined client instances).
    • -

    As this is a implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.

    +

    As the above is an implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.

    Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.

    Note: previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.

    From aa2f433afc9f582bfceadb3a4fb1407bc23843f8 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 22 Feb 2017 13:50:20 +0100 Subject: [PATCH 4/9] XEP-0280: stricten delivery rules from MAY to SHOULD --- xep-0280.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xep-0280.xml b/xep-0280.xml index fffb7d1d..1980f237 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -278,15 +278,15 @@

    The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons.

    -

    Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers.

    -

    The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules. A &MESSAGE; is eligible for carbons delivery if and only if at least one the following is true:

    +

    The following is the set of rules that a server implementation SHOULD use to determine which messages should be carbon-copied. Future specifications MAY add or override rules, though they are generally advised to use the <private/> element.

    +

    A &MESSAGE; is eligible for carbons delivery if it does not contain a <private/> child element and if at least one the following is true:

    • it is of type "chat".
    • it is of type "normal" and contains a <body> element.
    • it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
    • it matches the MUC-related rules outlined below.
    -

    To properly handle messages exchanged with a MUC (or similar service), the server must be able to identify MUC-related messages. This can be accomplished by tracking the clients' presence in MUCs, or by checking for the <x xmlns="http://jabber.org/protocol/muc#user"> element in messages. The following rules are suggested for MUC-related messages: +

    To properly handle messages exchanged with a MUC (or similar service), the server must be able to identify MUC-related messages. This can be accomplished by tracking the clients' presence in MUCs, or by checking for the <x xmlns="http://jabber.org/protocol/muc#user"> element in messages. The following rules apply to MUC-related messages:

    • A &MESSAGE; of type "groupchat" SHOULD NOT be carbon-copied.
      • From 38c889d7f1b816d0a2c1b6ec8562fecbd2dd1476 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Thu, 1 Jun 2017 16:13:23 +0200 Subject: [PATCH 5/9] XEP-0280: clients can join a MUC on MUC-PM Carbons, thx Kev --- xep-0280.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0280.xml b/xep-0280.xml index 1980f237..ad638e21 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -292,7 +292,7 @@
    • A &MESSAGE; of type "groupchat" SHOULD NOT be carbon-copied.
    • A &MESSAGE; containing a &xep0249; SHOULD be carbon-copied.
    • A &MESSAGE; containing a Mediated Invitation SHOULD be carbon-copied.
      • -
    • A private &MESSAGE; from a local user to a MUC participant (sent to a full JID) SHOULD be carbon-copiedThe server SHOULD limit carbon-copying to the clients sharing a Multi-Session Nick in that MUC, and MAY inject the <x/> element into such carbon copies. Clients SHOULD ignore carbon-copies of MUC-PMs related to a MUC they are not joined to..
      • +
    • A private &MESSAGE; from a local user to a MUC participant (sent to a full JID) SHOULD be carbon-copiedThe server SHOULD limit carbon-copying to the clients sharing a Multi-Session Nick in that MUC, and MAY inject the <x/> element into such carbon copies. Clients can not respond to carbon-copies of MUC-PMs related to a MUC they are not joined to. Therefore, they SHOULD either ignore such carbon copies, or provide a way for the user to join the MUC before answering..
    • A private &MESSAGE; from a MUC participant (received from a full JID) to a local user SHOULD NOT be carbon-copied (these messages are already replicated by the MUC service to all joined client instances).

    As the above is an implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.

    From 2749b03c9ff5966bd4835e96dfa1eb82efd2b2ad Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Fri, 5 Apr 2019 15:46:33 +0200 Subject: [PATCH 6/9] XEP-0280: include 0184 ACKs and 0085 CSNs --- xep-0280.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0280.xml b/xep-0280.xml index ad638e21..86ea4791 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -283,6 +283,7 @@
    • it is of type "chat".
    • it is of type "normal" and contains a <body> element.
      • +
    • it contains payload elements typically used in IM (&xep0184;, &xep0085;).
    • it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).
    • it matches the MUC-related rules outlined below.
    From bd18afe17d7926f43c99b8c34d029185f6055312 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 24 Apr 2019 07:38:52 +0200 Subject: [PATCH 7/9] XEP-0280: feature for mandatory rules --- xep-0280.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/xep-0280.xml b/xep-0280.xml index 86ea4791..e3f66f7b 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -197,6 +197,7 @@ ... + ... ]]> @@ -279,6 +280,7 @@

    The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons.

    The following is the set of rules that a server implementation SHOULD use to determine which messages should be carbon-copied. Future specifications MAY add or override rules, though they are generally advised to use the <private/> element.

    +

    A &MESSAGE; is eligible for carbons delivery if it does not contain a <private/> child element and if at least one the following is true:

    • it is of type "chat".
      • @@ -299,6 +301,11 @@

      As the above is an implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.

      Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.

      Note: previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.

      + + +

      A server implementation can choose to advertise full support of all the rules in §6.1 by including the "urn:xmpp:carbons:rules:0" feature in its service discovery information. If that feature is advertised, the rules above must be treated as REQUIRED and not merely as RECOMMENDED.

      +

      Accordingly, if this feature is advertised, a client MAY rely on the server supporting this exact set of rules.

      +       From a53d188a641e00b8229c9e0447a17850095f7489 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 24 Apr 2019 07:39:23 +0200 Subject: [PATCH 8/9] XEP-0280: version block with explicit changes list --- xep-0280.xml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/xep-0280.xml b/xep-0280.xml index e3f66f7b..3b071561 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -45,6 +45,19 @@ linuxwolf@outer-planes.net linuxwolf@outer-planes.net + + 0.13.0 + 2019-04-24 + gl + +

      Create more explicit and more binding copying rules under the "urn:xmpp:carbons:rules:0" namespace:

      +
        +
      • Replace MAY with MUST if feature is advertised.
        • +
      • Include XEP-0085 and XEP-0184 as eligible for carbon-copying.
        • +
      • Specify explicit rules for MUC related messages.
        • +
      +       +       0.12.1 2019-03-14 From e6cb1297f3a70b5f32af39250bd19951ec3c063d Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 24 Apr 2019 15:54:28 +0200 Subject: [PATCH 9/9] XEP-0280: add explicit mention of namespace meaning, thx Kev --- xep-0280.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0280.xml b/xep-0280.xml index 3b071561..d86d3035 100644 --- a/xep-0280.xml +++ b/xep-0280.xml @@ -318,6 +318,7 @@

      A server implementation can choose to advertise full support of all the rules in §6.1 by including the "urn:xmpp:carbons:rules:0" feature in its service discovery information. If that feature is advertised, the rules above must be treated as REQUIRED and not merely as RECOMMENDED.

      Accordingly, if this feature is advertised, a client MAY rely on the server supporting this exact set of rules.

      +

      While future versions of this specification (or other specifications) might use a different set of delivery rules, they would signify this by advertising a namespace other than "urn:xmpp:carbons:rules:0".