From abff654119cc455179bf03ba17e0978aa430ba9d Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Mon, 26 Sep 2022 15:50:57 +0200 Subject: [PATCH 01/51] XEP-0167: Release version 1.2.2 Specify attribute 'name' of 'mute' and 'unmute' elements as optional in schema --- xep-0167.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xep-0167.xml b/xep-0167.xml index 5023e3c3..7466fb96 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -42,6 +42,12 @@ &seanegan; &robmcqueen; &diana; + + 1.2.2 + 2022-09-26 + melvo + Specify attribute 'name' of 'mute' and 'unmute' elements as optional in schema + 1.2.1 2020-09-29 @@ -1933,7 +1939,7 @@ Romeo Juliet + use='optional'/> From b47dd8ac17de3b8a8ddc540a31c352a79df41bd3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Wed, 5 Oct 2022 16:45:37 +0200 Subject: [PATCH 02/51] XEP-0045: Remove more of GC1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0045.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index 60171618..c102cb9d 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -45,6 +45,12 @@ &stpeter; + + 1.34.4 + 2022-10-05 + pep +

Remove more mentions of Group Chat 1.0.

 + 1.34.3 2022-03-08 @@ -5708,7 +5714,6 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld

  • A MUC service SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information; see the Allowable Traffic section of this document.

  • In order to inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide role and affiliation data (and, if allowed by the room configuration, full JID) in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.

  • If a role or affiliation is revoked, the service MUST note that fact by sending an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant status. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.

    • -

  • A MUC service MUST include the MUC extensions even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with RFC 6120).

  • If the service includes an occupant's JabberID in the MUC presence extension, the value of the 'jid' attribute MUST be the full JID (not the bare JID).

  • A client MAY send a custom exit message if desired (as is often done in IRC channels) by including a <status/> element in the presence stanza of type "unavailable" sent when exiting a room.

    • From c97f8243a315e71f4eb24691ebb95403a2c1f93d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Thu, 3 Nov 2022 11:26:50 +0100 Subject: [PATCH 03/51] LICENSE: Replace shtml link MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- LICENSE.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/LICENSE.txt b/LICENSE.txt index 93e3832c..b862d1a8 100644 --- a/LICENSE.txt +++ b/LICENSE.txt @@ -50,6 +50,6 @@ possibility of such damages. This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may -be found at http://www.xmpp.org/extensions/ipr-policy.shtml or obtained +be found at https://xmpp.org/about/xsf/ipr-policy/ or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA). From 8357895b9ea03dfa92d2cf473bfbfdc311cb9dcd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Thu, 3 Nov 2022 11:33:36 +0100 Subject: [PATCH 04/51] XEP-0019: Replace shtml link MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0019.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0019.xml b/xep-0019.xml index 9652cc29..b3f736c5 100644 --- a/xep-0019.xml +++ b/xep-0019.xml @@ -72,6 +72,6 @@
  • Continue to use the Standards SIG as the preferred forum for discussion of experimental specifications before they are submitted to the XMPP Council.
  • If the Standards SIG cannot reach a working consensus on a given topic, let the document author(s) continue to rework their proposal informally outside the context of the Standards SIG. One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, http://www.jabberstudio.org/). Unlike the current SIGs, such a list would be established on the initiative of the document author(s) and would not require any formal approval by the XMPP Council.
    • -

    There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at http://www.jabber.org/bylaws.html.)

    +

    There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at http://www.jabber.org/bylaws.html.)

    From 4d763ee88506242da67554df41456bea985ebfd1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Thu, 3 Nov 2022 11:34:29 +0100 Subject: [PATCH 05/51] XEP-0019: Update revision to 1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0019.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0019.xml b/xep-0019.xml index b3f736c5..2d554872 100644 --- a/xep-0019.xml +++ b/xep-0019.xml @@ -19,6 +19,12 @@ N/A &stpeter; + + 1.1 + 2022-11-03 + pep + Replaced shtml link. + 1.0 2002-03-20 From 31a3d44c936e44775725fb383b59110c93e7daa0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Thu, 3 Nov 2022 11:36:37 +0100 Subject: [PATCH 06/51] XEP-0148: Replace shtml link MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0148.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0148.xml b/xep-0148.xml index 2ed5dc74..5c85cfde 100644 --- a/xep-0148.xml +++ b/xep-0148.xml @@ -191,7 +191,7 @@
    Semantic Correlation and Observation of Truth in Conversation Handling (SCOTCH)
    A person may seem intelligent to the casual observer, but his or her messages may actually not provide deep insights or even track reality in a useful or consistent fashion; this technique builds on early semantic web insights to determine the truth value of a given message within the context of a realtime conversation.
    Webs of Intelligent Network Endpoints (WINE)
    Any given person can engage in conversations with a large number of interlocutors, yet that person's status as an intelligent network endpoint is influenced by reputational factors across the full web of linguistic interactions, not just with any one person; this technique accounts for such reputational effects to paint a complete picture of the person's perceived intelligence across the network.
     -

    Naturally, because of the powerful and potentially unpredictable effects of these technologies, development of mod_iq was restricted to senior developers on the jabberd team, or at least (for developers in the U.S.) those over the age of 21. See Title 23, Chapter 1, Subchapter 1, Section 158 of the United States federal legal code as enacted by the National Minimum Drinking Age Act of 1984 <http://www.law.cornell.edu/uscode/23/158.shtml>.

    +

    Naturally, because of the powerful and potentially unpredictable effects of these technologies, development of mod_iq was restricted to senior developers on the jabberd team, or at least (for developers in the U.S.) those over the age of 21. See Title 23, Chapter 1, Subchapter 1, Section 158 of the United States federal legal code as enacted by the National Minimum Drinking Age Act of 1984 <https://www.law.cornell.edu/uscode/text/23/158>.

    From 56c6de9da4eee1b57b112e5bdeaa0a830a033ac1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Thu, 3 Nov 2022 11:37:57 +0100 Subject: [PATCH 07/51] XEP-0148: Update revision to 1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-0148.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0148.xml b/xep-0148.xml index 5c85cfde..4c5271d7 100644 --- a/xep-0148.xml +++ b/xep-0148.xml @@ -21,6 +21,12 @@ iq-iq &stpeter; + + 1.1 + 2022-11-03 + pep +

    Replace shtml link

     +     1.0 2005-04-01 From 8eb047a669160d41d57d4bc598f70b7f43988146 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Thu, 3 Nov 2022 11:38:32 +0100 Subject: [PATCH 08/51] xep.xsl: Replace shtml link to community page MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep.xsl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep.xsl b/xep.xsl index 5452860f..e28603ab 100644 --- a/xep.xsl +++ b/xep.xsl @@ -476,7 +476,7 @@ content: "XEP-";

    The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

    -

    Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/about/discuss.shtml> for a complete list.

    +

    Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

    Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

     From a7149be8c026ae5664ca467e4ad441a3eb9b2313 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sat, 5 Nov 2022 16:53:26 +0100 Subject: [PATCH 09/51] fixes #1235: Script that validates XEP-0001 conformance This adds a simple bash script that checks if a provided file (filename to be provided as first argument) conforms to XEP-0001. Expected to be executed from the directory that holds all xep XML files. Requires one argument: the file name of the xep to be validated, eg: $ tools/validate-xep0001-conformance.sh xep-0010.xml exit status will be non-zero upon validation failure. requires: bash, xmllint --- tools/validate-xep0001-conformance.sh | 132 ++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100755 tools/validate-xep0001-conformance.sh diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh new file mode 100755 index 00000000..e5194141 --- /dev/null +++ b/tools/validate-xep0001-conformance.sh @@ -0,0 +1,132 @@ +#!/bin/bash + +# Checks if provided file (filename to be provided as first argument) conforms to XEP-0001. +# See https://github.com/xsf/xeps/issues/1235 +# +# Expected to be executed from the directory that holds all xep XML files. +# Requires one argument: the file name of the xep to be validated, eg: +# +# $ tools/validate-xep0001-conformance.sh xep-0010.xml +# +# exit status will be non-zero upon validation failure. +# +# requires: bash, xmllint + +set -e + +VALIDATION_RESULT=0 + +# 1. Check DTD conformance against xep.dtd +XEP_DTD="xep.dtd" +if (xmllint --noout --dtdvalid "$XEP_DTD" "$1") +then + echo "[PASS] DTD conformance against xep.dtd" +else + echo "[FAIL] DTD conformance against xep.dtd" + VALIDATION_RESULT=1; +fi + +FILE_NAME="$(basename -- $1)" +HEADER_NUMBER=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdvalid "$XEP_DTD" $1) +HEADER_STATUS=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$XEP_DTD" $1) +HEADER_TYPE=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$XEP_DTD" $1) +HEADER_APPROVER=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$XEP_DTD" $1) + +if (echo "$FILE_NAME" | grep -Eq "^xep-[0-9]{4}.xml$") +then + echo "[INFO] The filename ('$FILE_NAME') matches 'xep-[0-9]{4}.xml'." + # 2. If the filename matches xep-[0-9]{4}.xml, check: + # 2.1 that the number in the filename equals /xep/header/number (XPath) + if [ "$FILE_NAME" = "xep-$HEADER_NUMBER.xml" ] + then + echo "[PASS] The number in the filename ('$FILE_NAME') equals XPATH value /xep/header/number/text() ('$HEADER_NUMBER')." + else + echo "[FAIL] The number in the filename ('$FILE_NAME') does not equals XPATH value /xep/header/number/text() ('$HEADER_NUMBER') (but should)." + VALIDATION_RESULT=1; + fi +else + echo "[INFO] The filename ('$FILE_NAME') does not match 'xep-[0-9]{4}.xml'." + # 3. If the filename does not match xep-[0-9]{4}.xml, check: + # 3.1 That the /xep/header/status/text() (XPath) is ProtoXEP + if [ "$HEADER_STATUS" = "ProtoXEP" ] + then + echo "[PASS] XPATH value /xep/header/status/text() ('$HEADER_STATUS') equals 'ProtoXEP'." + else + echo "[FAIL] XPATH value /xep/header/status/text() ('$HEADER_STATUS') does not equal 'ProtoXEP' (but should)." + VALIDATION_RESULT=1; + fi + + # 3.2 That the /xep/header/number/text() (XPath) is literally XXXX + if [ "$HEADER_NUMBER" = "XXXX" ] + then + echo "[PASS] XPATH value /xep/header/number/text() ('$HEADER_STATUS') equals 'XXXX'." + else + echo "[FAIL] XPATH value /xep/header/nimber/text() ('$HEADER_STATUS') does not equal 'XXXX' (but should)." + VALIDATION_RESULT=1; + fi + + # 3.3 That the name does not start with xep-[0-9] + if (echo "$FILE_NAME" | grep -Eq "^xep-[0-9].*$") + then + echo "[FAIL] The filename ('$FILE_NAME') starts with 'xep-[0-9]' (but should not)." + VALIDATION_RESULT=1; + else + echo "[PASS] The filename ('$FILE_NAME') does not start with 'xep-[0-9]'." + fi +fi + +# 4. Check that /xep/header/status/text() (XPath) is a defined status (see tools/xeplib.py for an enum) +case $HEADER_STATUS in + ProtoXEP | Experimental | Proposed | Draft | Active | Final | Retracted | Obsolete | Deferred | Rejected | Deprecated ) + echo "[PASS] XPATH value /xep/header/status/text() ('$HEADER_STATUS') equals a defined status." + ;; + *) + echo "[FAIL] XPATH value /xep/header/status/text() ('$HEADER_STATUS') does not equals a defined status (but should)." + VALIDATION_RESULT=1; + ;; +esac + +# 5. Check that /xep/header/type/text() (XPath) is defined in XEP-0001 +# If the XEP number is less than 400, also accept some legacy values. To find which, see which you encounter in the XEP numbers below 400 :-). +echo "[INFO] implementation of validation of XPATH value /xep/header/type/text() ('$HEADER_TYPE') is pending!" + +# 6. Check that /xep/header/approver/text() (XPath) is either Board or Council +case $HEADER_APPROVER in + Board | Council ) + echo "[PASS] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') equals either 'Board' or 'Council'." + ;; + *) + echo "[FAIL] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') does not equals 'Board' or 'Council' (but should)." + VALIDATION_RESULT=1; + ;; +esac + +# 7. Check that the version numbers in the revision blocks are descending (from top to bottom in the document) +echo "[INFO] implementation of validation version numbers in the revision blocks is pending!" + +# 8. If the approver (see above) is Board, enforce that /xep/header/type is not Standards Track. +if [ "$HEADER_APPROVER" = "Board" ] +then + if [ "$HEADER_TYPE" = "Standards Track" ] + then + echo "[FAIL] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') is 'Board' but XPATH value /xep/header/type/text() is 'Standards Track' (it should not be)." + VALIDATION_RESULT=1; + else + echo "[PASS] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') is 'Board' and XPATH value /xep/header/type/text() is not 'Standards Track'." + fi +fi + +# 9. Check that it uses the xep.xsl XML stylesheet. +echo "[INFO] implementation of xep.xsl XML stylesheet usage is pending!" + +# 10. Check that it includes the correct legal notice (either by checking for the entity reference, or by checking the content) +echo "[INFO] implementation of inclusion of correct legal notice is pending!" + +echo "" +if [ $VALIDATION_RESULT = 0 ] +then + echo "No issues found (but not all checks are implemented)."; +else + echo "Issues found!" +fi +exit $VALIDATION_RESULT From d65a5b4c2fa718a4c256d45173f14f90bb04090a Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 09:29:18 +0100 Subject: [PATCH 10/51] for #1235: Use `set -euo pipefail` instead of `set -e` As per @horazont's feedback: `-u` shouts at you if you use an undefined variable (very useful to catch typos) and `-o pipefail` improves error handling by also failing if any of the commands in a pipe fail. --- tools/validate-xep0001-conformance.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index e5194141..cf073165 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -12,7 +12,7 @@ # # requires: bash, xmllint -set -e +set -euo pipefail VALIDATION_RESULT=0 From 7389c8a3e9d92a11d6d90d70240e45395c62fbd0 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 09:33:59 +0100 Subject: [PATCH 11/51] for #1235: Remove redundant braces in if-expression As per @horazont's feedback: > You do not need () around the command in an if. I think that causes a subshell to spawn, the effects of which I'm not certain about. Further Googling suggests that the exit status of a pipeline is that of the most recently executed foreground pipeline, meaning that the exit code can be used directly in conditional statements. --- tools/validate-xep0001-conformance.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index cf073165..72b71314 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -18,7 +18,7 @@ VALIDATION_RESULT=0 # 1. Check DTD conformance against xep.dtd XEP_DTD="xep.dtd" -if (xmllint --noout --dtdvalid "$XEP_DTD" "$1") +if xmllint --noout --dtdvalid "$XEP_DTD" "$1" then echo "[PASS] DTD conformance against xep.dtd" else @@ -32,7 +32,7 @@ HEADER_STATUS=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdval HEADER_TYPE=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$XEP_DTD" $1) HEADER_APPROVER=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$XEP_DTD" $1) -if (echo "$FILE_NAME" | grep -Eq "^xep-[0-9]{4}.xml$") +if echo "$FILE_NAME" | grep -Eq "^xep-[0-9]{4}.xml$" then echo "[INFO] The filename ('$FILE_NAME') matches 'xep-[0-9]{4}.xml'." # 2. If the filename matches xep-[0-9]{4}.xml, check: @@ -66,7 +66,7 @@ else fi # 3.3 That the name does not start with xep-[0-9] - if (echo "$FILE_NAME" | grep -Eq "^xep-[0-9].*$") + if echo "$FILE_NAME" | grep -Eq "^xep-[0-9].*$" then echo "[FAIL] The filename ('$FILE_NAME') starts with 'xep-[0-9]' (but should not)." VALIDATION_RESULT=1; From f1197f143a3124430e4d2ddae1fbde4ca0982c69 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 09:40:32 +0100 Subject: [PATCH 12/51] for #1235: Double quote to prevent globbing and word splitting. As per @horazont's feedback: > Whenever you reference a variable ($foobar) and unless you know what you're doing, put it in double quotes. --- tools/validate-xep0001-conformance.sh | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index 72b71314..d938a501 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -26,11 +26,11 @@ else VALIDATION_RESULT=1; fi -FILE_NAME="$(basename -- $1)" -HEADER_NUMBER=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdvalid "$XEP_DTD" $1) -HEADER_STATUS=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$XEP_DTD" $1) -HEADER_TYPE=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$XEP_DTD" $1) -HEADER_APPROVER=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$XEP_DTD" $1) +FILE_NAME=$(basename -- "$1") +HEADER_NUMBER=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") +HEADER_STATUS=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") +HEADER_TYPE=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") +HEADER_APPROVER=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") if echo "$FILE_NAME" | grep -Eq "^xep-[0-9]{4}.xml$" then From 3f6f199159002f8466114b2471d65a985a4d0668 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 09:45:33 +0100 Subject: [PATCH 13/51] for #1235: variable casing to conform to convention --- tools/validate-xep0001-conformance.sh | 88 +++++++++++++-------------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index d938a501..9f68f4f8 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -14,90 +14,90 @@ set -euo pipefail -VALIDATION_RESULT=0 +validation_result=0 # 1. Check DTD conformance against xep.dtd -XEP_DTD="xep.dtd" -if xmllint --noout --dtdvalid "$XEP_DTD" "$1" +xep_dtd="xep.dtd" +if xmllint --noout --dtdvalid "$xep_dtd" "$1" then echo "[PASS] DTD conformance against xep.dtd" else echo "[FAIL] DTD conformance against xep.dtd" - VALIDATION_RESULT=1; + validation_result=1; fi -FILE_NAME=$(basename -- "$1") -HEADER_NUMBER=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") -HEADER_STATUS=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") -HEADER_TYPE=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") -HEADER_APPROVER=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$XEP_DTD" "$1") +file_name=$(basename -- "$1") +header_number=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdvalid "$xep_dtd" "$1") +header_status=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$xep_dtd" "$1") +header_type=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$xep_dtd" "$1") +header_approver=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$xep_dtd" "$1") -if echo "$FILE_NAME" | grep -Eq "^xep-[0-9]{4}.xml$" +if echo "$file_name" | grep -Eq "^xep-[0-9]{4}.xml$" then - echo "[INFO] The filename ('$FILE_NAME') matches 'xep-[0-9]{4}.xml'." + echo "[INFO] The filename ('$file_name') matches 'xep-[0-9]{4}.xml'." # 2. If the filename matches xep-[0-9]{4}.xml, check: # 2.1 that the number in the filename equals /xep/header/number (XPath) - if [ "$FILE_NAME" = "xep-$HEADER_NUMBER.xml" ] + if [ "$file_name" = "xep-$header_number.xml" ] then - echo "[PASS] The number in the filename ('$FILE_NAME') equals XPATH value /xep/header/number/text() ('$HEADER_NUMBER')." + echo "[PASS] The number in the filename ('$file_name') equals XPATH value /xep/header/number/text() ('$header_number')." else - echo "[FAIL] The number in the filename ('$FILE_NAME') does not equals XPATH value /xep/header/number/text() ('$HEADER_NUMBER') (but should)." - VALIDATION_RESULT=1; + echo "[FAIL] The number in the filename ('$file_name') does not equals XPATH value /xep/header/number/text() ('$header_number') (but should)." + validation_result=1; fi else - echo "[INFO] The filename ('$FILE_NAME') does not match 'xep-[0-9]{4}.xml'." + echo "[INFO] The filename ('$file_name') does not match 'xep-[0-9]{4}.xml'." # 3. If the filename does not match xep-[0-9]{4}.xml, check: # 3.1 That the /xep/header/status/text() (XPath) is ProtoXEP - if [ "$HEADER_STATUS" = "ProtoXEP" ] + if [ "$header_status" = "ProtoXEP" ] then - echo "[PASS] XPATH value /xep/header/status/text() ('$HEADER_STATUS') equals 'ProtoXEP'." + echo "[PASS] XPATH value /xep/header/status/text() ('$header_status') equals 'ProtoXEP'." else - echo "[FAIL] XPATH value /xep/header/status/text() ('$HEADER_STATUS') does not equal 'ProtoXEP' (but should)." - VALIDATION_RESULT=1; + echo "[FAIL] XPATH value /xep/header/status/text() ('$header_status') does not equal 'ProtoXEP' (but should)." + validation_result=1; fi # 3.2 That the /xep/header/number/text() (XPath) is literally XXXX - if [ "$HEADER_NUMBER" = "XXXX" ] + if [ "$header_number" = "XXXX" ] then - echo "[PASS] XPATH value /xep/header/number/text() ('$HEADER_STATUS') equals 'XXXX'." + echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX'." else - echo "[FAIL] XPATH value /xep/header/nimber/text() ('$HEADER_STATUS') does not equal 'XXXX' (but should)." - VALIDATION_RESULT=1; + echo "[FAIL] XPATH value /xep/header/nimber/text() ('$header_status') does not equal 'XXXX' (but should)." + validation_result=1; fi # 3.3 That the name does not start with xep-[0-9] - if echo "$FILE_NAME" | grep -Eq "^xep-[0-9].*$" + if echo "$file_name" | grep -Eq "^xep-[0-9].*$" then - echo "[FAIL] The filename ('$FILE_NAME') starts with 'xep-[0-9]' (but should not)." - VALIDATION_RESULT=1; + echo "[FAIL] The filename ('$file_name') starts with 'xep-[0-9]' (but should not)." + validation_result=1; else - echo "[PASS] The filename ('$FILE_NAME') does not start with 'xep-[0-9]'." + echo "[PASS] The filename ('$file_name') does not start with 'xep-[0-9]'." fi fi # 4. Check that /xep/header/status/text() (XPath) is a defined status (see tools/xeplib.py for an enum) -case $HEADER_STATUS in +case $header_status in ProtoXEP | Experimental | Proposed | Draft | Active | Final | Retracted | Obsolete | Deferred | Rejected | Deprecated ) - echo "[PASS] XPATH value /xep/header/status/text() ('$HEADER_STATUS') equals a defined status." + echo "[PASS] XPATH value /xep/header/status/text() ('$header_status') equals a defined status." ;; *) - echo "[FAIL] XPATH value /xep/header/status/text() ('$HEADER_STATUS') does not equals a defined status (but should)." - VALIDATION_RESULT=1; + echo "[FAIL] XPATH value /xep/header/status/text() ('$header_status') does not equals a defined status (but should)." + validation_result=1; ;; esac # 5. Check that /xep/header/type/text() (XPath) is defined in XEP-0001 # If the XEP number is less than 400, also accept some legacy values. To find which, see which you encounter in the XEP numbers below 400 :-). -echo "[INFO] implementation of validation of XPATH value /xep/header/type/text() ('$HEADER_TYPE') is pending!" +echo "[INFO] implementation of validation of XPATH value /xep/header/type/text() ('$header_type') is pending!" # 6. Check that /xep/header/approver/text() (XPath) is either Board or Council -case $HEADER_APPROVER in +case $header_approver in Board | Council ) - echo "[PASS] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') equals either 'Board' or 'Council'." + echo "[PASS] XPATH value /xep/header/approver/text() ('$header_approver') equals either 'Board' or 'Council'." ;; *) - echo "[FAIL] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') does not equals 'Board' or 'Council' (but should)." - VALIDATION_RESULT=1; + echo "[FAIL] XPATH value /xep/header/approver/text() ('$header_approver') does not equals 'Board' or 'Council' (but should)." + validation_result=1; ;; esac @@ -105,14 +105,14 @@ esac echo "[INFO] implementation of validation version numbers in the revision blocks is pending!" # 8. If the approver (see above) is Board, enforce that /xep/header/type is not Standards Track. -if [ "$HEADER_APPROVER" = "Board" ] +if [ "$header_approver" = "Board" ] then - if [ "$HEADER_TYPE" = "Standards Track" ] + if [ "$header_type" = "Standards Track" ] then - echo "[FAIL] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') is 'Board' but XPATH value /xep/header/type/text() is 'Standards Track' (it should not be)." - VALIDATION_RESULT=1; + echo "[FAIL] XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' but XPATH value /xep/header/type/text() is 'Standards Track' (it should not be)." + validation_result=1; else - echo "[PASS] XPATH value /xep/header/approver/text() ('$HEADER_APPROVER') is 'Board' and XPATH value /xep/header/type/text() is not 'Standards Track'." + echo "[PASS] XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' and XPATH value /xep/header/type/text() is not 'Standards Track'." fi fi @@ -123,10 +123,10 @@ echo "[INFO] implementation of xep.xsl XML stylesheet usage is pending!" echo "[INFO] implementation of inclusion of correct legal notice is pending!" echo "" -if [ $VALIDATION_RESULT = 0 ] +if [ $validation_result = 0 ] then echo "No issues found (but not all checks are implemented)."; else echo "Issues found!" fi -exit $VALIDATION_RESULT +exit $validation_result From 269e4d620a65b3e5bcffcb1611f0fde9e3bf029e Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 10:14:54 +0100 Subject: [PATCH 14/51] for #1235: Add xep.xsl XML stylesheet usage validation --- tools/validate-xep0001-conformance.sh | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index 9f68f4f8..4fed854d 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -31,6 +31,7 @@ header_number=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdval header_status=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$xep_dtd" "$1") header_type=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$xep_dtd" "$1") header_approver=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$xep_dtd" "$1") +processing_instructions=$(xmllint --xpath '/processing-instruction("xml-stylesheet")' --nowarning --dtdvalid "$xep_dtd" "$1") if echo "$file_name" | grep -Eq "^xep-[0-9]{4}.xml$" then @@ -42,7 +43,7 @@ then echo "[PASS] The number in the filename ('$file_name') equals XPATH value /xep/header/number/text() ('$header_number')." else echo "[FAIL] The number in the filename ('$file_name') does not equals XPATH value /xep/header/number/text() ('$header_number') (but should)." - validation_result=1; + validation_result=1 fi else echo "[INFO] The filename ('$file_name') does not match 'xep-[0-9]{4}.xml'." @@ -53,7 +54,7 @@ else echo "[PASS] XPATH value /xep/header/status/text() ('$header_status') equals 'ProtoXEP'." else echo "[FAIL] XPATH value /xep/header/status/text() ('$header_status') does not equal 'ProtoXEP' (but should)." - validation_result=1; + validation_result=1 fi # 3.2 That the /xep/header/number/text() (XPath) is literally XXXX @@ -62,14 +63,14 @@ else echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX'." else echo "[FAIL] XPATH value /xep/header/nimber/text() ('$header_status') does not equal 'XXXX' (but should)." - validation_result=1; + validation_result=1 fi # 3.3 That the name does not start with xep-[0-9] if echo "$file_name" | grep -Eq "^xep-[0-9].*$" then echo "[FAIL] The filename ('$file_name') starts with 'xep-[0-9]' (but should not)." - validation_result=1; + validation_result=1 else echo "[PASS] The filename ('$file_name') does not start with 'xep-[0-9]'." fi @@ -82,7 +83,7 @@ case $header_status in ;; *) echo "[FAIL] XPATH value /xep/header/status/text() ('$header_status') does not equals a defined status (but should)." - validation_result=1; + validation_result=1 ;; esac @@ -97,7 +98,7 @@ case $header_approver in ;; *) echo "[FAIL] XPATH value /xep/header/approver/text() ('$header_approver') does not equals 'Board' or 'Council' (but should)." - validation_result=1; + validation_result=1 ;; esac @@ -110,14 +111,20 @@ then if [ "$header_type" = "Standards Track" ] then echo "[FAIL] XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' but XPATH value /xep/header/type/text() is 'Standards Track' (it should not be)." - validation_result=1; + validation_result=1 else echo "[PASS] XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' and XPATH value /xep/header/type/text() is not 'Standards Track'." fi fi # 9. Check that it uses the xep.xsl XML stylesheet. -echo "[INFO] implementation of xep.xsl XML stylesheet usage is pending!" +if echo "$processing_instructions" | grep -Eq "href=['\"]xep.xsl['\"]" +then + echo "[PASS] xep.xsl XML stylesheet is used." +else + echo "[FAIL] xep.xsl XML stylesheet is not used (but should be)." + validation_result=1 +fi # 10. Check that it includes the correct legal notice (either by checking for the entity reference, or by checking the content) echo "[INFO] implementation of inclusion of correct legal notice is pending!" @@ -125,7 +132,7 @@ echo "[INFO] implementation of inclusion of correct legal notice is pending!" echo "" if [ $validation_result = 0 ] then - echo "No issues found (but not all checks are implemented)."; + echo "No issues found (but not all checks are implemented)." else echo "Issues found!" fi From da76032e2471838b79dc9f85b4847f3c47aa8099 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 10:40:02 +0100 Subject: [PATCH 15/51] for #1235: Add revision block version validation. --- tools/validate-xep0001-conformance.sh | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index 4fed854d..946b3d47 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -10,7 +10,7 @@ # # exit status will be non-zero upon validation failure. # -# requires: bash, xmllint +# requires: bash, xmllint, sort (supporting the '-V' argument) set -euo pipefail @@ -31,6 +31,7 @@ header_number=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdval header_status=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$xep_dtd" "$1") header_type=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$xep_dtd" "$1") header_approver=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$xep_dtd" "$1") +header_revisions=$(xmllint --xpath '/xep/header/revision/version/text()' --nowarning --dtdvalid "$xep_dtd" "$1") processing_instructions=$(xmllint --xpath '/processing-instruction("xml-stylesheet")' --nowarning --dtdvalid "$xep_dtd" "$1") if echo "$file_name" | grep -Eq "^xep-[0-9]{4}.xml$" @@ -103,7 +104,16 @@ case $header_approver in esac # 7. Check that the version numbers in the revision blocks are descending (from top to bottom in the document) -echo "[INFO] implementation of validation version numbers in the revision blocks is pending!" +expected_revision_order=$(echo "$header_revisions" | tr " " "\n" | sort -Vr) +if [ "$expected_revision_order" = "$header_revisions" ] +then + echo "[PASS] Version numbers in the revision blocks are descending." +else + echo "[FAIL] Version numbers in the revision blocks are not ordered (descending from top to bottom in the document) (but should be)." + echo " Order found : $(echo $header_revisions)" # funky $() nesting to remove newlines. + echo " Expected was: $(echo $expected_revision_order)" + validation_result=1 +fi # 8. If the approver (see above) is Board, enforce that /xep/header/type is not Standards Track. if [ "$header_approver" = "Board" ] From 56cef32c91ee00c82599a4f300ee2180613d7f36 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 11:11:13 +0100 Subject: [PATCH 16/51] for #1235: Add header type validation. --- tools/validate-xep0001-conformance.sh | 51 +++++++++++++++++++++++++-- 1 file changed, 49 insertions(+), 2 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index 946b3d47..02a21054 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -63,7 +63,7 @@ else then echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX'." else - echo "[FAIL] XPATH value /xep/header/nimber/text() ('$header_status') does not equal 'XXXX' (but should)." + echo "[FAIL] XPATH value /xep/header/number/text() ('$header_status') does not equal 'XXXX' (but should)." validation_result=1 fi @@ -90,7 +90,54 @@ esac # 5. Check that /xep/header/type/text() (XPath) is defined in XEP-0001 # If the XEP number is less than 400, also accept some legacy values. To find which, see which you encounter in the XEP numbers below 400 :-). -echo "[INFO] implementation of validation of XPATH value /xep/header/type/text() ('$header_type') is pending!" + +# FIXME: lots of duplications here. Find a better solution. +case $file_name in + 'xep-0001.xml' | 'xep-0002.xml' | 'xep-0019.xml' | 'xep-0053.xml' | 'xep-00143.xml' | 'xep-0182.xml' | 'xep-0345.xml' | 'xep-0381.xml' | 'xep-0429.xml' | 'xep-0458.xml' ) + case $header_type in + Historical | Humorous | Informational | Organizational | 'Standards Track' | 'Procedural' ) + echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + ;; + *) + echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + validation_result=1 + ;; + esac + ;; + 'xep-0006.xml' | 'xep-0010.xml' | 'xep-0069.xml' | 'xep-0139.xml' ) + case $header_type in + Historical | Humorous | Informational | Organizational | 'Standards Track' | 'SIG Formation' ) + echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + ;; + *) + echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + validation_result=1 + ;; + esac + ;; + 'xep-0007.xml' ) + case $header_type in + Historical | Humorous | Informational | Organizational | 'Standards Track' | 'SIG Proposal' ) + echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + ;; + *) + echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + validation_result=1 + ;; + esac + ;; + * ) + case $header_type in + Historical | Humorous | Informational | Organizational | 'Standards Track' ) + echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + ;; + *) + echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + validation_result=1 + ;; + esac + ;; +esac # 6. Check that /xep/header/approver/text() (XPath) is either Board or Council case $header_approver in From 028fd1a68502c0cc9db85d381882afb3978ac25e Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 19:20:34 +0100 Subject: [PATCH 17/51] for #1235: Add legal notice validation This adds a check for the usage of the _entity reference_ that is the legal notice. --- tools/validate-xep0001-conformance.sh | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index 02a21054..a5bdfccd 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -183,13 +183,19 @@ else validation_result=1 fi -# 10. Check that it includes the correct legal notice (either by checking for the entity reference, or by checking the content) -echo "[INFO] implementation of inclusion of correct legal notice is pending!" +# 10. Check that it includes the correct legal notice (by checking for the entity reference) +if grep -q "&LEGALNOTICE;" "$1" +then + echo "[PASS] entity reference for the legal notice has been detected." +else + echo "[FAIL] entity reference for the legal notice has not been detected (but it should have been)." + validation_result=1 +fi echo "" if [ $validation_result = 0 ] then - echo "No issues found (but not all checks are implemented)." + echo "No issues found." else echo "Issues found!" fi From bee4c93cd380b82cc3de6f65f884957b3bdc296e Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 20:08:15 +0100 Subject: [PATCH 18/51] for #1235: Do not exit script when XPATH yields no result xmllint will return exit code 10 when an XPATH query finds no matches. With the changes in this commit, the script isn't stopped. Instead, it uses an empty value, which is likely to cause the validation checks (further down in the script) to fail. --- tools/validate-xep0001-conformance.sh | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index a5bdfccd..f1abd268 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -27,12 +27,15 @@ else fi file_name=$(basename -- "$1") -header_number=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdvalid "$xep_dtd" "$1") -header_status=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$xep_dtd" "$1") -header_type=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$xep_dtd" "$1") -header_approver=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$xep_dtd" "$1") -header_revisions=$(xmllint --xpath '/xep/header/revision/version/text()' --nowarning --dtdvalid "$xep_dtd" "$1") -processing_instructions=$(xmllint --xpath '/processing-instruction("xml-stylesheet")' --nowarning --dtdvalid "$xep_dtd" "$1") + +# The test for exit code equalling 10 detects when the XPATH evaluation yields no results. In that case, the execution +# should not fail immediately, but use an empty value instead (which will likely cause a validation failure further down). +header_number=$(xmllint --xpath '/xep/header/number/text()' --nowarning --dtdvalid "$xep_dtd" "$1") || test $?=10 +header_status=$(xmllint --xpath '/xep/header/status/text()' --nowarning --dtdvalid "$xep_dtd" "$1") || test $?=10 +header_type=$(xmllint --xpath '/xep/header/type/text()' --nowarning --dtdvalid "$xep_dtd" "$1") || test $?=10 +header_approver=$(xmllint --xpath '/xep/header/approver/text()' --nowarning --dtdvalid "$xep_dtd" "$1") || test $?=10 +header_revisions=$(xmllint --xpath '/xep/header/revision/version/text()' --nowarning --dtdvalid "$xep_dtd" "$1") || test $?=10 +processing_instructions=$(xmllint --xpath '/processing-instruction("xml-stylesheet")' --nowarning --dtdvalid "$xep_dtd" "$1") || test $?=10 if echo "$file_name" | grep -Eq "^xep-[0-9]{4}.xml$" then From fbc0072c929b514681a94a8d5ab52ed495c53538 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Sun, 6 Nov 2022 20:31:58 +0100 Subject: [PATCH 19/51] for #1235: fix incorrect exemption for XEP-0143 --- tools/validate-xep0001-conformance.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index f1abd268..79fcceb6 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -96,7 +96,7 @@ esac # FIXME: lots of duplications here. Find a better solution. case $file_name in - 'xep-0001.xml' | 'xep-0002.xml' | 'xep-0019.xml' | 'xep-0053.xml' | 'xep-00143.xml' | 'xep-0182.xml' | 'xep-0345.xml' | 'xep-0381.xml' | 'xep-0429.xml' | 'xep-0458.xml' ) + 'xep-0001.xml' | 'xep-0002.xml' | 'xep-0019.xml' | 'xep-0053.xml' | 'xep-0143.xml' | 'xep-0182.xml' | 'xep-0345.xml' | 'xep-0381.xml' | 'xep-0429.xml' | 'xep-0458.xml' ) case $header_type in Historical | Humorous | Informational | Organizational | 'Standards Track' | 'Procedural' ) echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." From 55e6c02184ef14128331ff7c719e1d556a09397e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 8 Nov 2022 21:37:00 +0100 Subject: [PATCH 20/51] fix path --- xep-fast.xml => inbox/xep-fast.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename xep-fast.xml => inbox/xep-fast.xml (100%) diff --git a/xep-fast.xml b/inbox/xep-fast.xml similarity index 100% rename from xep-fast.xml rename to inbox/xep-fast.xml From 5c0c7cd8c50fcbd904fc27751b4384f6ec073695 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Mon, 25 Jul 2022 12:28:55 -0400 Subject: [PATCH 21/51] XEP-0004: clarify rules for multi-item forms Signed-off-by: Sam Whited --- xep-0004.xml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xep-0004.xml b/xep-0004.xml index 6aad5342..7fb91a1e 100644 --- a/xep-0004.xml +++ b/xep-0004.xml @@ -27,6 +27,12 @@ &jer; &temas; &stpeter; + + 2.13.1 + 2022-07-25 + ssw +

    Clarify elements allowed in multi-item data forms

     +     2.13.0 2022-01-21 @@ -318,9 +324,10 @@
  • One and only one <reported/> element, which can be understood as a "table header" describing the data to follow.
  • Zero or more <item/> elements, which can be understood as "table cells" containing data (if any) that matches the request.
    • -

    The <reported/> element MUST appear before any <item/> element inside the <x/> element.

    +

    The <reported/> element MUST appear before any <item/> element inside the <x/> element. Forms of this type MUST NOT contain any top-level fields other than <reported/> and <item/>.

    Older revisions of this XEP (before 2.12.0) did not contain an explicit requirement for the ordering between <reported> and <item>. Implementations are therefore encouraged to be flexible when processing incoming data, as there might still be implementations which do not implement a strict ordering when generating reports. + Similarly, revisions of this XEP before 2.13.1 were ambiguous about whether <reported/> and <item/> elements could co-exist with other top level elements such as <field/> and <title/> and various implementations are known to have handled this in different ways.

    The syntax is as follows:

    Date: Tue, 13 Dec 2022 18:39:04 +0100 Subject: [PATCH 22/51] Accept inbox/events.xml as XEP-0471 --- xep-0471.xml | 576 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 577 insertions(+) create mode 100644 xep-0471.xml diff --git a/xep-0471.xml b/xep-0471.xml new file mode 100644 index 00000000..5864c8b0 --- /dev/null +++ b/xep-0471.xml @@ -0,0 +1,576 @@ + + +%ents; +]> + + +
    + Events + This specification describe how to handle events with XMPP. + &LEGALNOTICE; + 0471 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0004 + XEP-0060 + XEP-0447 + XEP-0470 + + + + events + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.1.0 + 2022-12-13 + XEP Editor (jsc) + Accepted by vote of Council on 2022-09-28. + + + 0.0.1 + 2022-09-08 + jp +

    First draft.

     +     +
    + +

    Nowadays, it is common to handle all kind of events through desktop computer or phone: it is useful to have them at hand, to easily share them and to have all kind of reminders.

    +

    XMPP is a good fit to handle events: it's a communication protocol, and as such it would be useful for it to have tools to handle and share events.

    +

    The only existing attempt at this point is &xep0097; which describe a way to wrap iCaliCalendar https://datatracker.ietf.org/doc/html/rfc5545 data. However, this XEP never got traction, is not taking advantage of XMPP features, doesn't handle thing such as invitees and RSVP, and it not easily extensible.

    +

    This XEP proposes an alternative which leverage existing tools such as &xep0060;.

    +     + +

    The design goals of this XEP are:

    +
      +
    • use pubsub and its access model to be able to have events either private or public, and to take advantage of the subscription mechanism
      • +
    • being able to specify simple events with minimum metadata (e.g. doctor appointment, coffee with a friend)
      • +
    • provide optional tools such as RSVP or invitees list for events organization
      • +
    • it should be possible to optionally ask any kind of extra data in RSVP (e.g.: number of people attending, allergy information for dinner, etc.)
      • +
    • group several events of same kind in a pubsub node (e.g. personal agenda, work agenda, events linked to an organization)
      • +
    • flexible enough to specify all kind of extra metadata (e.g. description, classification tags, accessibility information) and media (e.g. main picture)
      • +
    • being able to optionally link to other pubsub features such as &xep0277; blog, or a way to share picture after the event is finished
      • +
    • be extensible
      • +
    +     + +
      +
    • RSVP: "Répondez s'il vous plaît", a way for event invitees to indicate whether they plan to attend the event
      • +
    +     + + +

    Juliet and her nurse decide to have a coffee together. Juliet knows the usual place where they're going, and thus doesn't need to add much information, she creates an event for her agenda on her XMPP client. The client creates an item on Juliet's PEP node `urn:xmpp:events:0` as follow:

    + + + + + + + Coffee with the nurse + 2022-09-05T12:00:00Z + 2022-09-05T13:00:00Z + + + + +]]> + +

    An event is published on a &xep0060; item. Juliet publishes this event on her personal agenda, thus she uses the node 'urn:xmpp:events:0' (see events nodes). The payload of an event is an <event/> element qualified by the namespace 'urn:xmpp:events:0'. Each event MUST have one or several <name/> elements containing a human readable short text describing the element. If several <name/> elements are used, they MUST have distinct 'xml:lang' attributes, to specify the same name in different languages. Each <event/> element MUST have a <start/> and an <end/> child elements specifying the expected start time and end time of the event by using the format explained in &xep0082;.

    +

    This is all for the minimum required elements of an event, everything else is optional. Thus, the only required elements of an event payload are <name/>, <start/> and <end/>.

    +     +     + +

    Juliet is organizing a ball, and to make things easier she uses her XMPP client to manage it. To make the event more appealing, she'll publish a nice image of the ball room as main picture of the event, and she'll publish the list of invitees. She'll also need RSVP to evaluate the number of people attending.

    +

    The event she's publishing looks as follows:

    + + + + + + + Capulet's Ball + 2022-12-15T20:00:00Z + 2022-12-16T02:00:00Z + + + + image/jpeg + ball_room.jpg + 120354 + 1920x1080 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + 2AfMGH8O7UNPTvUVAM9aK13mpCY= + Photo of the ball room. + + + + + + + + + + + + The Capulet familly is organizing its great annual ball! Come and enjoy the event of the year… + + +
    + The Capulet familly is organizing its great annual ball! Come and enjoy the event of the year… +
    +     + + + + + + Capulet's House + Italy + 45.4181, + 10.9637 + Code for entrance gate: 0123C + + + + + + urn:xmpp:events:rsvp:0 + + + maybe + + + + + + + + + + + + + + + application/pdf + dinner_menu.pdf + 50123 + d7b7d858663d110761ac4c9b7dbc4d8408445b16be0b9cedb908a2c7b454335a + Menu for the ball dinner. + + + + + + + + + + + + + urn:xmpp:events:extra:0 + + + https://ball2022.capulet.lit + + + full + + + +     +     +     +     +]]>     + +

    Juliet wants to be sure that this event will be a success, thus she provides a lot of information. The first 3 elements <name/>, <start/> and <end/> are the mandatory one as specified in simple event explanation, all other elements are optionals. The elements used are briefly explained below, and are more detailed in Events Data section.

    +

    The <head-picture/> element indicate where to find the head picture, or in other terms the main image used to represent the event. This image is used by clients to nicely represent the event to end-user.

    +

    <description/> elements contain human readable text to explain what the event is about.

    +

    <category/> elements are used to classify the event. This is useful to quickly give an idea of what the event is about, and for events discovery.

    +

    <location/> specify where the event takes place. It may also be used for online events.

    +

    <rsvp/> contains the form that invitees will answer to indicate if they plan to attend the event.

    +

    The 4 following elements <invitees/>, <comments/>, <blog/> and <schedule/> link to pubsub nodes respectively handling list of invitees, comments on the events, blog talking about the event, and event schedule. They are described in Linked Pubsub Nodes section.

    +

    <attachments/> elements provide any kind of files that can be useful to the event. It's used here to provide the menu for the dinner.

    +

    Finally, the <extra/> element contains a data form for any useful extra information.

    +     +     +     + + +

    Events are published to pubsub nodes. Each user may have a personal agenda on its &xep0163; service, by using the 'urn:xmpp:events:0' node. This node should have an access model of "whitelist" by default, however it is up to the entity holding the PEP node to use an other access model (a JID linked to an organisation may want to make public all its events from the personal agenda by using an "open" access model).

    +

    Otherwise, a node may be published on any pubsub service. An events node SHOULD be prefixed with 'urn:xmpp:events:0/', which SHOULD be followed by an unique identifier.

    +

    A pubsub node can contain any kind of events, and it is up to the publisher to decide what to put inside. While a personal agenda will hold events related to the owning entity, an events node can be used to keep events related to a school or other organisation, to a room (e.g. to show when and by whom a room is booked), to a team, to professional appointments, etc.

    +     + + +

    This section describe the various optional elements usable as children of an <event/> element. The 3 mandatory elements <name/>, <start/> and <end/> are specified in Simple Event Explanation.

    + +

    <head-picture/> element describe the image to use to represent the event to end-user. It is recommended to include it for public events as it may help to give a rough idea of the event, and to represent nicely a summary of the event. Keep in mind that the picture may be resized or cropped to fit end-user display and client's UI choices.

    +

    The element MUST contain a child <file-sharing/> element as described &xep0447;. The image SHOULD be published in JPEG format due to its widespread support and the fact that mostly photos are expected to be used as head pictures.

    +

    It is strongly recommended to include thumbnails if the head picture is large, as the event may be displayed on any screen size.

    +     + +

    The <description/> element is used to give an human readable text explaining the event. It is the main presentation of the event, usually highlighted below the head picture.

    +

    The description may be in plain text, in this case the <description/> MUST have a 'type' attribute with a value of "text". The element then contains the plain text description.

    +

    XHTML may also be used to provide rich description. To do so, the "xhtml" value must be used for the 'type' attribute, and the first child element of the <description/> element MUST be a <div/> element qualified by the 'http://www.w3.org/1999/xhtml' namespace. Note that the content MUST be sanitized before being shown to end-user, please check Security Considerations for some advices.

    +

    The "xml:lang" attribute SHOULD be present on each description element.

    +

    Several <description/> elements MAY be present, as long as they have distinct "type"/"xml:lang" combination. It is not mandatory to provide a text or XHTML description, and providing only one of them is valid.

    +     + +

    It is possible to give categories to the event with the <category/> element. This is specially useful for event discovery, and to give a rought idea of what the event is about. A <category/> MUST have a 'term' attribute with a human readable word or short words combination describing the category, and SHOULD have a "xml:lang" attribute set.

    +

    Whenever possible, the <category/> SHOULD have a "wd" attribute whose value is the Wikidata Entity ID + to find the ID corresponding to the term, you can either search on Wikidata itself, or check it via Wikipedia. An item entity identifier is needed, thus it should start with a "Q". IDs can also be found via Wikipedia API or Wikidata API.. + Wikidata is an open and collaborative database with over 100 million items. By specifying the Wikidata entity ID corresponding to the term, the category becomes machine readable and can be easily translated, associated to similar terms, linked to corresponding Wikipedia page in end-user language, and so on.

    +     + +

    It is often important to indicate the place where the event happens. This is done by using a <location/> element which is wrapping zero or one &xep0080; <geoloc/> element and any number of <online/> elements (described below).

    +

    <online/> element is used for virtual meeting using a computer. If is it the under the same <location/> element than a <geoloc/> element, the online meeting is done in parallel to the physical meeting.

    +

    There may be several <location> elements if the meeting happens in several places (either at the same time, or one after the other). If several locations are used, each <location/> element MUST have an 'id' attribute with an unique identifier. At least one of the <location/> SHOULD have an 'id' with a value of "main", indicating that it is the main meeting place (which can then be used to discover events by geographical coordinates). When the event is presented to end-user using HTML, the rendering software SHOULD set an 'id' attribute to the element showing the location with the value "location_<LOCATION_ID>" (e.g. for the "main" location, the 'id' attribute would have a value of "location_main"), this way location may then be linked in the XHTML description.

    + +

    If the meeting is virtual or if a virtual meeting happens in parallel for those who can't go physically to the event, one or more <online/> elements can be used to give the instructions.

    +

    The only mandatory <online/> child element is <instructions/> which contains a human readable text explaining how to join the online meeting. The <instructions/> element SHOULD have a 'xml:lang' attribute, and several <instructions/> elements MAY be present if they have distinct 'xml:lang' attributes.

    +

    <online/> MAY have an optional <name/> child with a human readable text, this is notably useful if several online locations are used at the same time for different purpose (e.g.: global announces, lost and found, etc.). The <name/> element SHOULD have a 'xml:lang' attribute.

    +

    If the online location is on an XMPP MUC, an <x/> element qualified by the 'jabber:x:conference' namespace as described in &xep0249; can be used.

    +

    It may be useful to indicate which software is used for the meeting. This is done with the <software/> element which MUST have a 'name' attribute with the software name, SHOULD have a 'wd' attribute with Wikidata entity ID when available (see Categories section for explanation on Wikidata) as it provides a lot of machine readable useful information such as where it can be found, on which platforms it is running, etc. The <software/> SHOULD also have an 'url' attribute with the URL to the official software website as value. The 'need_install' attribute MAY be used with a value of either 'true' if the software needs to be installed or 'false' if it's not necessary (i.e. if it's accessible directly via a web resource).

    +

    The <url-data/> provide the main URL to be used to join the online meeting. It is specified in &xep0103;

    + + + + + + + + + + + Ball organisation + + + + Just click on the link to access the room. We'll be discussion about organisation of the Capulet ball. + + + + + + Join this room for any king of discussions which need to be written, and to share files. + + + + + + + + + +]]> +     +     + +

    RSVP is a major tools when an event is organized: it helps to check if invitees have seen the event, and to evaluate the total number of people attending. The <rsvp> element MUST contain form as specified in &xep0004; and &xep0068;. The form must be specified as explained in &xep0068; with <field/> having a 'type' attribute with a value of "hidden", a 'var' with a value of "FORM_TYPE", and the field value MUST be "urn:xmpp:events:rsvp:0".

    +

    The form is the one which has to be answered by invitees, it SHOULD contain a field with a 'type' attribute of value "list-single" and a 'var' attribute of value "attending" with 3 options of respective value "maybe", "yes" and "no". This is the main field and it's the one which will be used to estimate the number of attendees. However, an event organizer MAY decide to modify the available options, for instance if the "maybe" option is not desired. This element SHOULD have a <required/> child element.

    +

    An optional field named "participants_number" MAY be used to indicate the number of attendees, including the person answering. This field has the default type of "text-single". If present, it will be used to summarize the expected number of persons participating to the event, otherwise one person per attending invitee will be assumed.

    +

    Any other field can be added to request extra information to invitees. For instance, it may be used to ask if attendees have allergies, or who is bringing what to a picnic. If a new field is added, &xep0068; MUST be followed, and the 'var' attribute MUST be namespaced using &clark;.

    +

    The answer is provided by attendees using &xep0470;: an <rsvp/> element qualified by the 'urn:xmpp:events:0' namespace is attached to the event item, containing the submitted data.

    +

    <rsvp/> element SHOULD have a 'xml:lang' attribute set to the language of the labels. Several <rsvp/> elements MAY be present, in which case they MUST have distinct 'xml:lang' attributes.

    + + + + + + + + + + + urn:xmpp:events:rsvp:0 + + + maybe + + + + + + + 1 + + + + + + + + + + +]]> + + + + + + + + + >urn:xmpp:events:rsvp:0 + + + yes + + + no + + + + + + + + +]]> + +

    To summarize RSVP answers, as explained in &xep0470;, the number of attendees is counted with 2 values: "confirmed" which are attendees coming for sure, and "max" which is the maximum number of persons expected.

    +

    For each <rsvp/> element attached, the count is done like this:

    +
      +
    • the increment is equal to the value of the 'participants_number' field, or 1 if +
        +
      1. the 'participants_number' field is not used or not present in submitted values
        2. +
      2. the value doesn't cast to an int
        3. +
      3. the int value is lower than 1
        4. +
      +
      • +
    • if the value of 'attending' field is not set or "no", then nothing is done
      • +
    • if the value of 'attending' field is "yes", both "confirmed" and "max" are increased by the increment value
      • +
    • if the value of 'attending' field is "maybe", only "max" is increased by the increment value
      • +
    +

    The summary is done in an <attendees/> element qualified by the 'urn:xmpp:events:0' namespace, with a 'confirmed' attribute whose value is the number of confirmed invitees, and a 'max' attribute with the maximum number of invitees expected. If 'max' is the same number as 'confirmed' (meaning that nobody has answered "maybe"), then it may be omitted.

    + + + + + + + + + + + + + + + + + +]]> + +     + + +

    Due to the way &xep0470; is working, the normal way to answer RSVP is visible to everybody which can see the event. This is normally not a problem as people which attend the event can see by themselves who is there or not, however some persons may not want to have their RSVP or JID exposed to other participants. In this case the RSVP MAY be sent through a &MESSAGE; stanza directed to the JID of the event publisher. The RSVP is then simply put as a child of the stanza, with an optional <body/>. If not <body/> is provided or if the body in empty, The &MESSAGE; SHOULD include a <store> hint as specified in &xep0334;.

    +

    Note that sending an RSVP with a &MESSAGE; may complicate the organisation: it's then not counted automatically in the attachments summary, and if several persons are organizing the event, they may not all check easily the participation.

    + + + + + >urn:xmpp:events:rsvp:0 + + + yes + + + no + + + + + +]]> + +     +     + +

    Some useful external pubsub nodes can be linked to the event. Those nodes are linked through elements which always have a 'jid' attribute specifying the JID of the pubsub or &xep0163; service, and a 'node' attribute specifying the pubsub node used. The supported elements are described below.

    + +

    <invitees/> element links to a node containing one item per invitee. This node access model MAY be different to the one of the event itself: it can for instance have a "whitelist" access model to restrict the list of invitees only to organisers. In other words, it's not because an user has access to the event item that they have necessarily access to the list of invitees. Each item of the invitees node has a simple payload with an <invitee/> element qualified by the 'urn:xmpp:events:0' namespace and whose attributes are the mandatory 'jid' with the JID of the invitee, and an optional 'name' attribute with a human readable name.

    +     + + + + + + + + + + + + +]]> + +

    The <comments/> element link to a &xep0277; comments node holding comments to the event iself.

    +     + +

    The <blog/> element link to a &xep0277; node with a blog about the event. It is useful to keep people updated about any news or preparation information.

    +     + +

    The <schedule/> element link to an events node (i.e. a node using this specification) describing the programation which will happens during the main event. Put another way, it's were information such as dinner time, talks, workshop, etc. can be added.

    +

    Several events in the schedule MAY happen at the same time or overlapping time (for instance: various talks happening in parallel in a conference), in which case the locations SHOULD be specified (e.g. in which room each talk is taking place). Schedule MAY include events with RSVP (e.g. for a workshop needing inscription).

    +     +     + + +

    The <attachments/> elements is used to attach all kinds of files which may be useful to the event (menu, map, badge template, and so forth). It contains one or more <file-sharing/> elements as specified by &xep0447;.

    +     + + +

    The <extra/> element hold a data form containing any relevant extra data. The form must be specified by using a FORM_TYPE field with the value "urn:xmpp:events:extra:0" and a 'type' with the value "hidden". Below some fields are specified, a software MAY add additional field. Any new field MUST follow &xep0068; and be namespaced using &clark;. All field and the form itself are optional.

    +

    The following fields may be used, if not specified otherwise their type is "text-single":

    +
      +
    • website: the value links to a website dedicated to the event
      • +
    • status: indicate if the event will happen for sure or if it's a tentative. The possible values are "confirmed" if the event will happen for sure, "tentative" if the event may happen dependant on some condition (e.g. number of participants, convenient date found), and "cancelled" if the event won't happen. Note that "tentative" events may be moved to another timetechnically any event can be moved to a different time, the "tentative" status just make it a stronger possibility.
      • +
    • languages: indicate the main languages that will be used during the event. The field is of type "list-multi", and each language value is an ISO 639 language code.
      • +
    • accessibility:wheelchair: indicates if the event is accessible to wheelchairs. The possible values are "full" for an event totally accessible to wheelchair, "partial" when some zones may be difficult to access, and "no" when the zone is not adapted for wheelchairs.
      • +
    +     + + +

    An event may link to an other one. This is often useful when ones want to participate to an event and add it to their own personal agenda

    +

    To link an external event, an <external/> element is used which MUST have the 3 following attributes: 'jid' with the JID of the pubsub service of the linked event, 'node' with the name of the pubsub node and 'item' with the ID of the linked event item.

    +

    Generally, only the 3 mandatory <name/>, <start/> and <end/> elements are specified in addition to the <external/> one, the reason being that all data of the events SHOULD be retrieved from the original event itself. The start and end time are still specified through to be sure that the event won't be automatically moved to an unapproved time spot if the original event is modified.

    + + + + + + Capulet's Ball + 2022-12-15T20:00:00Z + 2022-12-16T02:00:00Z + + + + + +]]> +     + +     + + +

    TODO

    +     + + +

    If a client supports the Events protocol specified in this XEP, it must advertize it by including the "urn:xmpp:events:0" discovery feature in response to a &xep0030; information request:

    + + + +]]> + + + ... + + ... + +]]> +

    Similarly, if a PEP/Pubsub service implements the summarizing of RSVP as described in RSVP Summarizing, it MUST advertise that fact by including the "urn:xmpp:events:0" discovery feature in response to a &xep0030; information request:

    + + +]]> + + + ... + + ... + +]]> +     + + +

    TODO

    +     + + +

    TODO

    +     + +

    TODO

    +     + +

    TODO

    +     + +

    Thanks to JC Brand for spelling corrections.

    +     +     diff --git a/xep.ent b/xep.ent index 3d7700f3..e07abcc2 100644 --- a/xep.ent +++ b/xep.ent @@ -1666,3 +1666,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates WebSocket S2S (XEP-0468) XEP-0468: WebSocket S2S <https://xmpp.org/extensions/xep-0468.html>." > Bookmark Pinning (XEP-0469) XEP-0469: Bookmark Pinning <https://xmpp.org/extensions/xep-0469.html>." > Pubsub Attachments (XEP-0470) XEP-0470: Pubsub Attachments <https://xmpp.org/extensions/xep-0470.html>." > +Events (XEP-0471) XEP-0471: Events <https://xmpp.org/extensions/xep-0471.html>." > From e54e113c0509b8b125becf7431daeda0a2080fde Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 13 Dec 2022 18:39:25 +0100 Subject: [PATCH 23/51] Accept inbox/pubsub-social-feed.xml as XEP-0472 --- xep-0472.xml | 375 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 376 insertions(+) create mode 100644 xep-0472.xml diff --git a/xep-0472.xml b/xep-0472.xml new file mode 100644 index 00000000..fd3056c0 --- /dev/null +++ b/xep-0472.xml @@ -0,0 +1,375 @@ + + + %ents; +]> + + +
    + PubSub Social Feed + This specification defines a way of publishing social content over XMPP. + &LEGALNOTICE; + 0472 + Experimental + Standards Track + Standards + Council + + XMPP Core + XMPP IM + XEP-0060 + RFC 4287 + + + XEP-0277 + + + psf + + Timothée + Jaussoin + edhelas@movim.eu + edhelas@movim.eu + https://edhelas.movim.eu + + + 0.1.0 + 2022-12-13 + XEP Editor (jsc) + Accepted by vote of Council on 2022-10-19. + + + 0.0.1 + 2022-09-26 + tj + Initial version. + +
    + + +

    Social Networking plaftorms are often built around the concept of feeds. XMPP offers, through &xep0060;, a really generic way of Publishing and Subscribing elements on XMPP nodes. This extension defines a way to publish social content on PubSub nodes using &rfc4287;

    + +

    Social features in XMPP were historically built on the &xep0277; specifications. However in practice Microblogging was not applicable in more common cases and some related features were not used. The current XEP defines a more generic way of handling Social Feeds on XMPP by keeping the existing Microblogging features as a subset of it.

    +     + + +
    + +
    Profile
    +
    + Defined by a specific Pubsub type (pubsub#type) a profile is a Pubsub Social Feed with some constraints. See the + Profiles + section. +
    +     +
    +     + + + +

    + A PubSub Social Feed can be located on any PubSub node on the XMPP network. Some specific use cases, such as the personal eventing (PEP) node Microblog is defined in the + Profiles + section. +

    +     + + +

    The publication of a Post consist of a valid &rfc4287; entry embeded in a &xep0060; item.

    +

    The post content itself can be either text (content element without "type" attribute or with "type" attribute with "text" value) or XHTML ("content" element "type" attribute with "xhtml" value). If Romeo publishes XHTML content, his client MUST publish two "content" elements: a text one, and a XHTML one. For XHTML publishing, see &xep0060;.

    + + + + + + + hanging out at the Caf&#233; Napolitano + tag:montague.lit,2008-05-08:posts-1cb57d9c-1c46-11dd-838c-001143d5d5db + 2008-05-08T18:30:02Z + 2008-05-08T18:30:02Z + + + + + +]]> + +

    Note: The "title" element is required to be included in an "atom:entry" element according to &rfc4287;. An implementation MAY provide also "atom:summary" and/or "atom:content" elements too if it needs.

    + +

    It's possible to insert some rich content in the post or comment. It can be some text formatting, images, etc. Only "xhtml" content type is supported for the moment by this document but possibly it will be extended later. Also, it is RECOMMENDED for the client to restrict XHTML content to the XHTML-IM subset (&xep0071;).

    + + + + + + + + <div xmlns="http://www.w3.org/1999/xhtml"> + <p>hanging out at the <strong>Caf&#233; Napolitano</strong></p> + </div> + + tag:montague.lit,2008-05-08:posts-1cb57d9c-1c46-11dd-838c-001143d5d5db + 2008-05-08T18:30:02Z + 2008-05-08T18:30:02Z + CapuChat + + + + + +]]> + +     +     + +

    + Because Juliet is subscribed to some Romeo's family PubSub service nodes. Romeo's XMPP server will send a PubSub notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with Jabber clients that are not pubsub-capable (see + Message Body + ). +

    + + + hanging out at the Caf&#233; Napolitano + + + + + hanging out at the Caf&#233; Napolitano + + + tag:montague.lit,2008-05-08:posts-1cb57d9c-1c46-11dd-838c-001143d5d5db + 2008-05-08T18:30:02Z + 2008-05-08T18:30:02Z + CapuChat + + + + + +]]> + +

    Note: these alternate links were not posted by the original client because some clients can't compute them themselves. These things SHOULD be inserted at server side though.

    +     + +

    Anyone can publish a post in reply to Romeo's post. Here we assume that a reply comes from Benvolio.

    +

    Note: Inclusion of the "thr:in-reply-to" element defined in &rfc4685; indicates the post to which the user is replying. This reply includes two such elements (one pointing to the HTTP URL for the post and the other pointing to the XMPP URI for the post.

    +

    Note: The post can be a reply to more than the only one another.

    + + + + + + + + Benvolio Montague + xmpp:romeo@montague.lit + + @romeo cappuccino this late in the day? + + + tag:montague.lit,2008-05-08:posts-c4145006-1c53-11dd-b2d5-000bcd82471e + 2008-05-08T18:31:21Z + 2008-05-08T18:31:21Z + + + + + + + +]]> + +

    Assuming that Romeo has also subscribed to the same node he will receive the reply that Benvolio sent.

    +     + +

    When Benvolio wants to repeat a Romeo's post, his client publishes the same post under a different name. But to be able to track the repeated post original author, Benvolio's client MAY use specific "atom:author" child node, "atom:name" and "atom:uri", containing, respectively, the name of the original post author, and his XMPP URI (JID).

    +

    The client SHOULD also put an "atom:link" element with "rel" attribute set to "via" and point it to the original post.

    + + + + + + + + Romeo Montague + xmpp:romeo@montague.lit + + hanging out at the Caf&#233; Napolitano + + + + tag:montague.lit,2008-05-08:posts-1re57d3c-1q46-11dd-748r-024943d2d5rt + 2008-05-08T18:30:02Z + 2008-05-08T18:32:02Z + + + + + +]]> + +

    Thus, a different author JID value lets the client know the item has been repeated from another one.

    +

    It's also possible for Benvolio to add his own thougths to the repost. To do this he SHOULD wrap the original content in the "xhtml:blockquote" element and after it add his own content. Also, the client MAY post reply without quotation to the original thread to inform users about the repost.

    +     + + + +

    There are two different things that carry a similar sense: the XMPP Pubsub Item ID and the "atom:id" element. This section is devoted to make a separation between them.

    +

    The pubsub Item ID MUST be used when linking to an entry with an XMPP channel (i.e. by including it in the URI with the "xmpp" schema). the Atom entry ID MUST be built according to &rfc4287; and used in aggregators with the aim of revealing of post duplicates, reposts, mentions, syndications, etc.

    +

    Note that the rules of comparing, building and security notes for "atom:id" are listed in the &rfc4287;.

    +     + +

    Depending on service policies and the value of the "pubsub#include_body" node configuration option, PubSub Social Feed notifications SHOULD include a message "body" element for backwards-compatibility with Jabber clients that are not pubsub-capable. It is RECOMMENDED for the XML character value of the "body" element to be the same as that of the "atom:title" child of the "atom:entry".

    +     + +

    Juliet may want to know which places are Romeo's notices related to. That's why Romeo's client MAY geotag microblog entries, using the &xep0080; protocol for storing geolocation information.

    +

    Romeo's client MUST create a "geoloc" element, with the &xep0080; reference namespace: "http://jabber.org/protocol/geoloc".

    + + + + + + + + Romeo Montague + xmpp:romeo@montague.lit + + Is lost in the forest. Need help! + + tag:montague.lit,2008-05-08:posts-1zr23z8a-3g12-34fh-750b-120867gjc1sqh + 2008-05-08T18:43:01Z + 2008-05-08T18:43:01Z + + 48.171761 + -3.3667986 + France + FR + Brittany + + + + + + + ]]> + +     +     +     + + +

    PubSub Social feeds are specified under profiles. Those profiles are constraints applied to nodes and defined by a specific PubSub type (see &xep0060;#registrar-formtypes-metadata)

    +

    + All the profiles MUST base their default configuration on the + Base profile + . +

    + + +

    This profile is specified by the PubSub type `urn:xmpp:social:0` and define a generic PubSub Social Feed that can be hosted on any PubSub service node or &xep0163; node.

    +

    Those restrictions MUST be used by all the other profiles defined bellow and in other XEPs based on Pubsub Social Feed.

    + + +
      +
    1. The "pubsub#notify_retract" MUST be set to `true` to provide clients the ability to track if some items were retracted and reflect such changes in the UI correctly.
      2. +
    2. The "pubsub#max_items" MUST be set to the `max` value, as defined in the &xep0060;.
      3. +
    3. The "pubsub#persist_items" MUST be set to `true`.
      4. +
    4. The "pubsub#send_last_published_item" SHOULD be set to `never`.
      5. +
    5. The "pubsub#deliver_payloads" SHOULD be set to `false`. The social content can be quite large so it is advised to let the clients to manually query the content if it is not already cached.
      6. +
    +     +     + + +

    This profile is defined by the PubSub type `urn:xmpp:microblog:0` as defined in &xep0277; and MUST be created and configured under the PEP `urn:xmpp:microblog:0` node.

    + + +

    + On top of the + Base profile Pubsub Node Configuration + the following node configuration is applied: +

    +
      +
    1. The "pubsub#access_model" SHOULD be set to `presence` by default to allow the other presence JIDs to receive the newly published elements without an explicit subscription (using the +notify feature of &xep0163;).
      2. +
    +     +     + + +

    This profile is defined by the PubSub type `urn:xmpp:gallery:0` and can be hosted on any PubSub service.

    +

    All the items published in a gallery node MUST only have at least one attached picture. This picture MUST be of type `enclosure` as specified in &rfc4287;.

    + + +]]> + +     +     + + + +

    The client SHOULD check that the comment author information (provided in the "author" element) is valid, by checking that the "publisher" item attribute value matches the "uri" element value. If there is a difference or the check can not be performed because there was not a "publisher" attribute included, the comment can be displayed, but it is RECOMMENDED to specify there is a security problem.

    +     +     + + +

    This document requires no interaction with &IANA;.

    +     + + +

    The ®ISTRAR; is requested to issue an initial namespace of "urn:xmpp:social:0" and "urn:xmpp:gallery:0".

    +     + + +

    + This specification re-uses the schema for the Atom content format, i.e., the 'http://www.w3.org/2005/Atom' namespace (see + RFC 4287 + ). +

    +     + +     diff --git a/xep.ent b/xep.ent index e07abcc2..2b8548a2 100644 --- a/xep.ent +++ b/xep.ent @@ -1667,3 +1667,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Bookmark Pinning (XEP-0469) XEP-0469: Bookmark Pinning <https://xmpp.org/extensions/xep-0469.html>." > Pubsub Attachments (XEP-0470) XEP-0470: Pubsub Attachments <https://xmpp.org/extensions/xep-0470.html>." > Events (XEP-0471) XEP-0471: Events <https://xmpp.org/extensions/xep-0471.html>." > +PubSub Social Feed (XEP-0472) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>." > From 915884bc521fe403d96a2fc823651d05ca512489 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 13 Dec 2022 18:39:37 +0100 Subject: [PATCH 24/51] Accept inbox/pubsub-encryption.xml as XEP-0473 --- xep-0473.xml | 268 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 269 insertions(+) create mode 100644 xep-0473.xml diff --git a/xep-0473.xml b/xep-0473.xml new file mode 100644 index 00000000..a65a25ef --- /dev/null +++ b/xep-0473.xml @@ -0,0 +1,268 @@ + + +%ents; +]> + + +
    + OpenPGP for XMPP Pubsub + Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use case. + &LEGALNOTICE; + 0473 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0004 + XEP-0060 + XEP-0373 + + + + oxps + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.1.0 + 2022-12-13 + XEP Editor (jsc) + Accepted by vote of Council on 2022-10-19. + + + 0.0.6 + 2022-10-12 + jp + +
      +
    • add forgotten "jid" and "node" attribute to <revoke/>
      • +
    • clarify that <openpgp/> wrapper is used
      • +
    +     +     + + 0.0.5 + 2022-10-12 + jp + +
      +
    • add forgotten "timestamp" in example
      • +
    • add implementation node on double encryption
      • +
    • add clarification that sender should be a node owner
      • +
    +     +     + + 0.0.4 + 2022-10-11 + jp + +
      +
    • add a security note to indicate that <shared-secret/> and <revoke/> sender must be checked.
      • +
    +     +     + + 0.0.3 + 2022-10-10 + jp + +
      +
    • Base64 is not needed for the key (it's a passphrase)
      • +
    • Specify that as least on &MESSAGE; should be encrypted for sender other devices
      • +
    • Recommend minimum length for shared secret
      • +
    +     +     + + 0.0.2 + 2022-10-10 + jp +

    Remove useless references to XEP-0374 + acknowledgements

     +     + + 0.0.1 + 2022-10-09 + jp +

    First draft.

     +     +
    + +

    &xep0060; and &xep0163; are widely used XMPP features. However, items are published in plain text, making them readable by server administrators or anybody having administrator level access on the pubsub/PEP services.

    +

    Although this is not a problem for data intended to be published publicly, there are many cases where it may be desirable to make the data inaccessible to anybody but the selected recipients, or in other words to end-to-end encrypt the data.

    +

    This specification aims to provide an easy way to e2e encrypt items of a pubsub node, and to share access with other entities. It is compatible with all existing pubsub/PEP features, which makes it possible to use securily features such a geolocation, private blogs, private calendar events, data forms, etc.

    +     + +

    The design goals of this XEP are:

    +
      +
    • work with basic standard pubsub/PEP service, no extra feature needed;
      • +
    • be generic and work with any protocol using pubsub: once decrypted, the items should be parsable as if they were plain text;
      • +
    • be able to share with other entities the means to decipher the elements;
      • +
    • be able to easily share the means of decrypting items with new entities, even after the items have been published;
      • +
    • be able to modify the means of decryption to make the new elements inaccessible to certain entities even if they have had access to the previous elements;
      • +
    +     + +
      +
    • e2ee: end-to-end encryption
      • +
    • Shared Secret: a cryptographically strong random string used to symmetrically encrypt items
      • +
    • Encrypted Node: pubsub node whose items are end-2-end encrypted using this protocol.
      • +
    +     + +

    To encrypt a pubsub node, each item is symmetrically encrypted with a shared secret using OpenPGP symmetric encryption. The secret is shared with other entities using e2e encrypted messages with &xep0373;. If an entity's access is revoked or a shared secret may have been compromised, a new shared secret is generated and new items are encrypted with it.

    +     + + + +

    Juliet wants to create a private blog (using &xep0277;) that she only share with her confidante and her lover. To make sure that her family, who manages her XMPP server, can't read the content, she want to use end-to-end encryption.

    +

    To do so, her client creates a "shared secret" by generating a cryptographically strong key that will be used to symmetrically encrypt new items. This key MUST be associated with an ID, which MUST be an unique sequence of characters usable in an XML attribute. She will later share this key with entities allowed to access or publish on the blog as explained below.

    +

    From now on, all items that Juliet publishes on the node SHOULD be symmetrically encrypted with the shared secret by using OpenPGP symmetric encryption.

    +

    To publish an encrypted item, an <encrypted/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace MUST be used as payload. This element MUST contain a 'secret' attribute whose value is the ID of the shared secret used. The content of the element is a base64 encoded Symmetric-Key Encrypted Session Key Packet as specified at RFC 4880 § 5.3 (in a similar way as secret key backup is encoded in XEP-0373). The encrypted content is the item payload that would normally be used.

    +

    The encrypted node SHOULD have a "whitelist" access model as specified in &xep0060;. Juliet's client ensure that either by creating a new node with suitable access model, or by changing the access model of existing node.

    + + + + + + + + + + +]]> + +     + + +

    Now that Juliet has started to publish encrypted items on a blog, she wants to share the secret key with her confidante and her lover. To do so she uses a e2ee &MESSAGE; stanza by using an <openpgp/> element wrapping a <signcrypt/> as specified in XEP-0373 "Exchanging OpenPGP Encrypted and Signed Data". The encrypted payload of the <signcrypt/> MUST contain a <shared-secret/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace. This element MUST have the following attributes:

    +
      +
    • a 'timestamp' attribute whose value is the datetime of the shared key generation. Datetime format is specified in &xep0082;.
      • +
    • a 'jid' attribute with bare JID of the pubsub/PEP service;
      • +
    • a 'node' attribute with the name of the encrypted node;
      • +
    • an 'id' attribute with the ID of the shared secret;
      • +
    • if the key is revoked (due to shared secret rotation), it must have a 'revoked' attribute with the value "true".
      • +
    +

    The <shared-secret/> SHOULD have a 'type' attribute whose value is the pubsub#type that the node would have if it were plain text (i.e. the semantic type information of decrypted data in the node, usually the namespace of the decrypted payload).

    +

    The content of the <shared-secret/> element MUST be the shared secret (i.e. the passphrase used to symmetrically encode items).

    +

    She send messages with the encrypted shared secret to her nurse, Romeo and herself (so her other devices get the shared secret too).

    +

    Entities MUST always use the most recently generated shared secret to encrypt new items (the 'timestamp' attribute is used to check generation date and time).

    + +

    + Following example only show the <shared-secret/> element, as it is normally put as an encrypted payload of &xep0373; <signcrypt/> payload. +

    + + ZSRD5lK9mz-5VHNyu2N1XLiJZ8I87jkv85ceZkVrOGA + + ]]> + +

    note: we use &MESSAGE; instead of PEP or Pubsub to transmit the shared secret for several reasons:

    +
      +
    • Shared secret would have to be encrypted for all entities allowed to decrypt the items, and re-encrypted each time there is a new entity. While acceptable for a small number of entities, this doesn't scale as well as separated &MESSAGE;;
      • +
    • The item containing the shared secret would need to keep all previous shared secrets in case of secret rotation (see below). At some point, there would be a risk to reach stanza maximum size limit of one server;
      • +
    • Using a well-known pubsub node or pubsub item id would mean than the location of the encrypted shared secret would be known. While not enough to get the secret, that's better to hide it in encrypted messages flow;
      • +
    +     + + +

    If there is any doubt about the compromise of a shared secret or if access to the encrypted node is revoked for an entity, the shared secret SHOULD BE rotated.

    +

    To rotate a key, a &MESSAGE; must be sent to all people which got the shared secret. The &MESSAGE; MUST contain a XEP-0373 <openpgp/> element with a <signcrypt/> element whose payload is an encrypted <revoke/> element qualified by the 'urn:xmpp:openpgp:pubsub:0' namespace, which MUST have a 'jid' attribute whose value is the JID of the pubsub/PEP service where the node is, a 'node' attribute whose value is the name of the node, and an 'id' attribute whose value is the shared secret ID.

    +

    Optionally, the <revoke/> element MAY have one or more <reason/> child element(s) which contain a human readable message explaining the reason of the revocation. The <reason/> element MAY contain an 'xml:lang' attribute with the language code of the text, and there MAY be several <reason/> elements if and only if they have distinct xml:lang. A revoked key MUST NOT be used to encrypt new items.

    +

    Then a new shared secret MUST be generated and transmitted to all participants (excluding those who have seen their access revoked) as explained in Transmit Shared Secret.

    +

    Note that if an entity's access is revoked, it SHOULD also be removed from the node's whitelist (if "whitelist" has been used as access model as recommended).

    +

    + Following example only show the <revoke/> element, as it is normally put as an encrypted payload of &xep0373; <signcrypt/> payload. +

    + + Revoked access from an entity + + ]]> +

    Items published before the key rotation SHOULD NOT be re-encrypted as it would be resource intensive, and revoked entities may have made a copy anyway.

    +

    When access to the shared secret is granted to a new entity, all previously used keys SHOULD be transmitted (with their 'revoked' attribute set to "true" as explained in Transmit Shared Secret.) along with the currently used shared secret. This allows the new entity to decrypt the items encrypted with the old keys. The <shared-secret/> elements can either be sent in the same encrypted payload of a single &MESSAGE;, or split into multiple encrypted &MESSAGE;, it's up to the implementation to decide which is better (keep in mind that too many shared secrets in a single message may reach the maximum stanza size limit at some point, even if this limit is not likely to be reached for most usual cases).

    +     + +     + + +

    The shared secret and revocation SHOULD be generated by node owner.

    +

    &MESSAGE; with encrypted <shared-secret/> or <revoke/> elements MUST be sent to everybody who must have access to the node. At least one of the encrypted payload SHOULD be encrypted for the sender themselves (either by sending the &MESSAGE; directly to the sender, or to decrypt a copy received with &xep0280;), so other devices of the sender can get the shared secret too.

    +

    When &xep0470; are used, the attachment node SHOULD have the same access model (i.e. whitelist as recommended in Security Considerations) as the encrypted node, with authorized entities synchronized (this should be done automatically for fully compliant services). The items published to attachment node itself MUST be encrypted using this protocol. Due to validity check of attachment items, the encrypted element MUST be a child of a XEP-0470's <attachments/> element, instead of being the <item/> payload as usual. Note that this will prevent the summary feature to work with encrypted elements, and the end-user client will have to do the summary itself, this is an inevitable trade-off when using e2ee.

    +

    The "pubsub#type" of an encrypted item is always "urn:xmpp:openpgp:pubsub:0", thus no information is leaked on the content of the node, and all encrypted nodes can easily be retrieved by using &xep0462;.

    +

    Note that encrypted items MAY be mixed with plain text items: for instance if a blog is public, but some of its items are private. However the proper handling of this use case is out of scope of this specification.

    +     + + +

    This specification uses &xep0373; independently of &xep0374;, implementations SHOULD avoid double encryption (e.g. by excluding <openpgp/> element qualified by 'urn:xmpp:openpgp:0' namespace from encryption by XEP-0374 implementation), and MUST ensure that element is correctly decrypted. Double encryption should be checked, and the <openpgp/> element MUST be decrypted even if OXIM (XEP-0374) is not being used.

    +     + + +

    If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:openpgp:pubsub:0" discovery feature in response to a &xep0030; information request:

    + + + +]]> + + + ... + + ... + +]]> +     + + +
      +
    • When receiving a <shared-secret/> or a <revoke/> element, the receiving client MUST ensure that the signing sender is the same as the one for all known shared secrets of this pubsub node (usually a node owner). This prevents a malicious actor for misleading the client into using a non-legitimate secret.
      • +
    • To limit the surface of attack, the access model of an encrypted node should be set to "whitelist" and only people having the shared key should be allowed to retrieve encrypted items.
      • +
    • If the shared key is compromised, or a user access is revoked, the key MUST be rotated. However, only new items are encrypted with the new key, any previous item should be considered as compromised too.
      • +
    • Sometimes client may use metadata to construct item ID, this is notably the case for some &xep0277; implementation, as the resulting item ID is used to generate user friendly URLs. To avoid metadata leakage, clients SHOULD NOT derivate the item ID from any data of the item when pubsub encryption is used.
      • +
    • Some protocols define prefixes for nodes, this is for instance the case for XEP-0277 Comments. If the prefix is not essential to make the feature work (which is the case for XEP-0277 comments), the client SHOULD NOT use the usual prefix to avoid leaking informations on the content of the node. The prefix defined in &xep0470; MUST be used as usually, as it is essential to retrieve the attachment node, and it's generic and thus doesn't leak information on the node content.
      • +
    • To decrypt archives and future items, clients most probably cache plain text version of items, and shared secret. If one device with access to an encrypted node is compromised, all items from the node should be considered compromised, and shared secret should be rotated.
      • +
    • For the same reason, client SHOULD encrypt data at rest (even if the device is stolen, data should not be accessible without some cryptographic key).
      • +
    • Note that only the shared key sender is authenticated (by &xep0373;'s <signcrypt/>), not the items publishers, meaning that encrypted items could be published by anybody in possession of the shared secret. Pubsub items authentication will be treated in a separated XEP.
      • +
    • The shared secret should be long enough to avoid brute force attacks. A secret of at least 32 characters is recommended.
      • +
    +     + + +

    TODO

    +     + +

    TODO

    +     + +

    TODO

    +     + +

    Thanks to Tim Henkes for his advices and NLNet foundation/NGI0 Discovery for funding.

    +     +     diff --git a/xep.ent b/xep.ent index 2b8548a2..91e89db2 100644 --- a/xep.ent +++ b/xep.ent @@ -1668,3 +1668,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Pubsub Attachments (XEP-0470) XEP-0470: Pubsub Attachments <https://xmpp.org/extensions/xep-0470.html>." > Events (XEP-0471) XEP-0471: Events <https://xmpp.org/extensions/xep-0471.html>." > PubSub Social Feed (XEP-0472) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>." > +OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>." > From 32b23f1b9107eb1323b81b3d63fcc70b752bf2c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 13 Dec 2022 18:39:57 +0100 Subject: [PATCH 25/51] Accept inbox/xep-downgrade-prevention.xml as XEP-0474 --- xep-0474.xml | 185 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 186 insertions(+) create mode 100644 xep-0474.xml diff --git a/xep-0474.xml b/xep-0474.xml new file mode 100644 index 00000000..51969714 --- /dev/null +++ b/xep-0474.xml @@ -0,0 +1,185 @@ + + +%ents; +]> + + +
    + SASL SCRAM Downgrade Protection + This specification provides a way to secure the SASL and SASL2 handshakes against method and channel-binding downgrades. + &LEGALNOTICE; + 0474 + Experimental + Standards Track + Standards + Council + + XMPP Core + RFC 5802 + XEP-0388 + + + + SSDP + &tmolitor; + + 0.1.0 + 2022-12-13 + XEP Editor (jsc) + Accepted by vote of Council on 2022-10-19. + + + 0.0.1 + 2022-10-11 + tm + Initial version. + +
    + +

    &rfc6120; and &xep0388; define a way to negotiate SASL mechanisms. When used together with SCRAM mechanisms (&rfc5802;) and channel-binding (&xep0440;) the mechanism selection is protected against downgrade attacks by an active MITM tampering with the TLS channel and advertised SASL mechanisms, while the negotiation of the channel-binding types is still not protected against such downgrade attacks.

    +

    &xep0440; tries to mitigate this by making the "tls-server-end-point" (&rfc5929;) channel-binding mandatory to implement for servers. But that leaves clients not able to implement this type, or any channel-binding at all, vulnerable to downgrades of channel-binding types and SASL mechanisms. Furthermore "tls-server-end-point" provides weaker security guarantees than other channel-bindings like for example "tls-exporter" (defined in &rfc5705; and &rfc9266;).

    +

    This specification aims to solve this issue by spcifying a downgrade protection for both SASL mechanisms and channel-binding types using an optional SCRAM attribute (see &rfc5802;). This specification can be used for SASL1 (&rfc6120;) and SASL2 (&xep0388;) profiles as well as any other SASL profile.

    +

    Note: In the long term the author strives to publish this as an RFC rather than a XEP to also make this protection available to other protocols, after gaining implementation experience.

    +     + +

    This protocol was designed with the following requirements in mind:

    +
      +
    • Allow detection of SASL mechanism downgrades even if no channel-binding is in use.
      • +
    • Allow detection of downgrades of channel-binding types.
      • +
    • Support all currently defined and future SCRAM mechanisms (&rfc5802; and &rfc7677;)
      • +
    +

    Note that this specification intentionally leaves out support for SASL PLAIN. If server and client support PLAIN, no protection against SASL method or channel-binding downgrades is possible and the security relies solely on the underlying TLS channel. As explained in § 13.8.3 of &rfc6120;, servers and clients SHOULD NOT support SASL PLAIN unless it is required by the authentication backend.

    +     + +

    This specification uses some abbreviations:

    +
      +
    • SASL1: the XMPP SASL profile specified in &rfc6120;
      • +
    • SASL2: the XMPP SASL profile specified in &xep0388;
      • +
    +     + +

    Sections 5.1 and 7 of &rfc5802; allow for arbitrary optional attributes inside SCRAM messages. This specification uses those optional attribute to implement a downgrade protection.

    + +

    The server uses the optional attribute "d" with the value "ssdp" in its server-first-message to indicate support for this specification.

    +

    A client supporting this specification but not seeing this attribute advertised by the server MAY abort the authentication. It is RECOMMENDED to wait until the whole SCRAM flow hash been completed to distinguish the case of a server not supporting this specification from a MITM stripping out this optional SCRAM attribute.

    +     + +

    If the server indicated support for this spec in the server-first-message and the client supports it, the client calculates a hash for the server-advertised list of SASL mechanisms and channel-binding types as follows.

    +

    Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.

    +
      +
    1. Initialize an empty ASCII string S
      2. +
    2. Sort all server-advertised SASL mechanisms and append them to string S joined by delimiter "," (%x2C)
      3. +
    3. If the server used &xep0440; to advertise channel-bindings, append "|" (%x7C) to S
      4. +
    4. If the server used &xep0440; to advertise channel-bindings, sort all server-advertised channel-binding types and append them to string S joined by delimiter "," (%x2C)
      5. +
    5. Hash S using the same hash mechanism as used for the SCRAM mechanism currently in use and encode the result using base64
      6. +
    +

    The client then adds the optional attribute "d" with the base64 encoded hash obtained in step 5 to its client-final-message. The client MAY send this attribute even if the server did not advertise support.

    +

    Note: If the server simultaneously advertises SASL1 and SASL2, only the mechanism list of the SASL protocol the client uses for authentication MUST be considered for hashing.

    +     + +

    Upon receiving the client-final-message the server calculates its own base64 encoded hash using the list of SASL mechanisms and channel-binding types it advertised using SASL1 or SASL2 and &xep0440; by applying the same algorithm as defined in Client Sends Downgrade Protection Hash.

    +

    The server then extracts the base64 encoded hash presented by the client in the optional attribute "d" and compares it to its own hash. If the hashes match, the list of SASL mechanisms and channel-binding types has not been changed by an active MITM.

    +

    If the hashes do not match, the server MUST fail the authentication as specified in &rfc6120; section 6.5 or &xep0388; section 2.6.2 using the "aborted" error-condition. If &xep0388; is used, the application-specific error-condition "downgrade-detected" in the namespace "urn:xmpp:ssdp:0" MUST be added, too. It MAY further include an optional descriptive text to further clarify this error as specified in &xep0388; section 6.2.6 or &rfc6120; section 6.5. If additional SCRAM data is provided, the used SCRAM "server-error-value" MUST be "downgrade-detected".

    +

    Non-XMPP implementations MAY use a SCRAM "server-error-value" of "downgrade-detected" alongside any protocol specific error-condition.

    +     + +

    This sections contains an example based on the ones provided in &xep0388;.

    + + + + + + + + SCRAM-SHA-1 + SCRAM-SHA-1-PLUS + + + + + + + + + + + + + + + + + + cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNg== + + AwesomeXMPP + Kiva's Phone + + + + + + cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5NixkPXNzZHA= + + + + + Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xNY29Rdk9kQkRlUGQ0T3N3bG1BV1YzZGcxYTFXaDF0WVBUQndWaWQxMFZVLHI9MTJDNENENUMtRTM4RS00QTk4LThGNkQtMTVDMzhGNTFDQ0M2YTA5MTE3YTYtYWM1MC00ZjJmLTkzZjEtOTM3OTljMmJkZGY2LHA9VUFwbzd4bzZQYTlKK1ZhZWpmei9kRzdCb21VPSxkPWRSYzNSZW51U1k5eXBnUHBFUm93b2F5U1FaWT0= + + + + + + + dj1zUXE4QTFkZVBMNUR4V1gyMlN6NFRKTUQ3dDQ9 + + user@example.org +]]> +     +     + +

    Using SCRAM attributes makes them part of the HMAC signatures used in the SCRAM protocol flow efficiently protecting them against any MITM attacker not knowing the password used.

    +     + +

    This document requires no interaction with &IANA;.

    +     + +

    This specification does not need any interaction with the ®ISTRAR;.

    +     + +

    This specification does not specify any new XML elements.

    +     +     \ No newline at end of file diff --git a/xep.ent b/xep.ent index 91e89db2..d87a9995 100644 --- a/xep.ent +++ b/xep.ent @@ -1669,3 +1669,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Events (XEP-0471) XEP-0471: Events <https://xmpp.org/extensions/xep-0471.html>." > PubSub Social Feed (XEP-0472) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>." > OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>." > +SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>." > From 286717f769a6d44cb8f80493f32b4d22e519766d Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Thu, 15 Dec 2022 09:38:42 +0100 Subject: [PATCH 26/51] for #1240: Integrate XEP validation in CI Adds a Github workflow that executes `tools/validate-xep0001-conformance.sh` against any changed XEP that was changed in a pull request. --- .github/workflows/xep-validation.yml | 35 ++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 .github/workflows/xep-validation.yml diff --git a/.github/workflows/xep-validation.yml b/.github/workflows/xep-validation.yml new file mode 100644 index 00000000..0c6be272 --- /dev/null +++ b/.github/workflows/xep-validation.yml @@ -0,0 +1,35 @@ +name: XEP validation + +on: + pull_request: + branches: + - master + +jobs: + build: + runs-on: ubuntu-latest + name: Validate any XEP changes + steps: + - uses: actions/checkout@v3 + with: + fetch-depth: 0 + + - name: Detect changes to XEP files + id: changed-xeps + uses: tj-actions/changed-files@v34 + with: + files: | + xep-*.xml + inbox/* + + - name: Validate changed file(s) + if: steps.changed-xeps.outputs.any_changed == 'true' + run: | + sudo apt-get install -y libxml2-utils + result=0 + for xep in "${{ steps.changed-xeps.outputs.all_changed_files }}"; do + if ! tools/validate-xep0001-conformance.sh "$xep"; then + result=1 + fi + done + exit $result From bbc6fbdac0bd2c9e43564314d592479272757c80 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Dec 2022 18:42:57 +0100 Subject: [PATCH 27/51] Accept inbox/pubsub-signing.xml as XEP-0475 --- xep-0475.xml | 233 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 234 insertions(+) create mode 100644 xep-0475.xml diff --git a/xep-0475.xml b/xep-0475.xml new file mode 100644 index 00000000..e19a6c6b --- /dev/null +++ b/xep-0475.xml @@ -0,0 +1,233 @@ + + +%ents; +]> + + +
    + Pubsub Signing + Specifies a mechanism to sign pubsub items + &LEGALNOTICE; + 0475 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0004 + XEP-0060 + XEP-0470 + + + + pubsub-signing + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.1.0 + 2022-12-20 + XEP Editor (jsc) + Accepted by vote of Council on 2022-11-30. + + + 0.0.2 + 2022-10-20 + jp + +
      +
    • replaced "signatory" term with the more commonly used "signer"
      • +
    • added <to/> and <time/> elements (similar to XEP-0373)
      • +
    +     +     + + 0.0.1 + 2022-10-17 + jp +

    First draft.

     +     +
    + +

    There are few ways to authenticate items published via &xep0060;, and none of them are secure: the publish attribute defined by the pubsub service is not mandatory and can be spoofed by the service itself, and some XEPs such as &xep0277; have their own mechanism (like <author/> qualified by "http://www.w3.org/2005/Atom" namespace) that is even easier to spoof.

    +

    This specification proposes a framework for attaching cryptographic signatures to pubsub items, allowing strong authentication of item authors. This specification only defines the framework, it is designed to be extended by other specifications to use various cryptographic algorithms.

    +     + +
      +
    • wrapper element: element wrapping the item to sign, and containing extra metadata
      • +
    • signed data: normalized and serialized wrapped element
      • +
    • signing profile: a specialisation of this specification for a specific cryptographic algorithm.
      • +
    • signature: element containing the signature itself (which is detached from the signed data).
      • +
    • C14N: Canonical XML (version 2.0 is used in this specification), a way to normalize XMP to have the same data to sign.
      • +
    +     + +

    The design goals of this XEP are:

    +
      +
    • it must be possible to sign plain text items as well as end-to-end encrypted items;
      • +
    • it must be backwards compatible: attaching a signature must work with existing specifications so that clients that do not support pubsub signatures can continue to work as usual;
      • +
    • it must be possible to sign an item by several authors;
      • +
    • it should be possible to have different signers from the item publisher;
      • +
    +     + +

    To sign a pubsub item, the signature and the signed data are separated. Signed data is a wrapper element comprising essential data such as signers, and the item to be signed. The wrapper element is then normalized, serialized and signed. The signature and additional data of the wrapper element are then publised as &xep0470;. In case of multiple signers, each signer publish their own signature as an attachment.

    +

    To verify a signature, the process is similiar: the receiving client builds the same wrapper element, normalize and serialize it, and uses it to validate the given signature(s).

    +     + + +

    To sign a pubsub item, a <sign-data/> wrapper element qualified by the 'urn:xmpp:pubsub-signature:0' namespace is created. This element MUST contain at least one 'to' element which MUST have a 'jid' attribute whose value is the intended recipient's XMPP address. The XMPP address found in the 'to' element's 'jid' attribute SHOULD be without Resourcepart (i.e., a bare JID).

    +

    The <sign-data/> element MUST contain exactly one <time/> element. The <time/> element MUST have a 'stamp' attribute which contains the timestamp of the moment when the element is being signed in the DateTime format as specified in &xep0082;

    +

    The <sign-data/> element MUST contain one or more <signer/> element(s) which MUST possess a 'jid' attribute whose value is the bare JID of the signer.

    +

    One or more external elements specified by signing profile MAY be added

    +

    The item to sign MUST be added as a child of the <sign-data/> element. If the wrapped <item/> element possesses a 'publisher' attribute, it MUST be removed when added to the wrapper element. As item ID can be added or modified by the Pubsub/PEP service, if the <item/> has an 'id' attribute, it MUST be removed too when added to the wrapper element, thus the item ID is not part of the signed data.

    +

    Then the resulting item is put to canonical form by applying C14N v2.0 specification.

    +

    The resulting element in canonical form is then serialized and signed.

    +

    Below is an example of wrapper element:

    + + + +

    The normalized form is as follow:

    + + juliet@capulet.litJuliet Capuletxmpp:juliet@capulet.litShe is so pretty!2022-10-16T18:39:02Z]]> + +

    The signature is then put as an &xep0470;. The attachment is a <signature/> element qualified by the 'urn:xmpp:pubsub-signing:0' namespace. The attachment MUST contain the same <time/> and <signer/> elements in the same order as in the <sign-data/> element. If any signing profile extra elements have been used in <sign-data/>, they MUST be added too in the same order as in <sign-data/>. Then the signature is added in an element specified in the signing profile specification.

    +

    Each signer entity MUST publish a <signature/> attachment signed with their own encryption keys.

    +

    If the pubsub item is encrypted, the signature MUST be done on the plain text version of the item before the encryption of the item. The <signature/> attachment SHOULD be encrypted too.

    + + + + + + + + + + + + + + ]]> + +

    The reason we use &xep0470; instead of directly signing the target item is that we need to be backwards compatible, so we cannot replace the target item with another element, nor is it possible to add a sibling element to item's payload (this would not be compliant with &xep0060; specification). This requires detaching the signature from the <item/> element itself, and &xep0470; are dedicated to attaching data to items, so a viable solution.

    +     + + +

    To summarize signatures as explained in &xep0470; the <signer/> elements are grouped into a <signature/> element qualified by the 'urn:xmpp:pubsub-signing:0' namespace. This allows a client to easily know that an item is signed, and to obtain the IDs of attachments that need to be retrieved to validate signatures.

    + + + + + + + + + + juliet@capulet.lit + romemo@montague.lit + + + + + + + + + ]]> +     + + +

    Once one or more signatures have been found in an item attachment, a client SHOULD validate them. To do this, it builds a wrapper element with the target item as explained in Signing a Pubsub Item, and validate it with each signature. Validation mechanism depends of the signing profile.

    +     + +     + + +

    C14N 2.0 defines parameters for the algorithm. For this specification, default values MUST be used, i.e. IgnoreComments is true, TrimTextNodes is true, PrefixRewrite is none, and QNameAware is the empty set. In other terms: there must be no comments, text nodes must be trimmed, prefixes are left unchanged, and no nodes must be processed as QName-valued.

    +

    Once the signature has been validated, it's the original item which MUST be used, as usual, not the normalized form. The original item has attributes missing from the normalized form ('published' and 'id' attribute), and spaces are trimmed, but they may be significant (e.g. in a dataform <value/>).

    +

    It is essential to use the same <to/>, <time/>, <signer/> and signing profile extra elements in the <signature/> element put in attachment and in wrapper <sign-data/> element used for signed data, as it is necessary for receiving client to re-build the wrapper element and then validate the signature.

    +     + + +

    The client validating signatures should display a message or indicator depending on the validation result:

    +
      +
    • If one of the signatures doesn't validate, the client SHOULD display a prominent warning message explicitely stating that the signature is not validated and that the message is probably spoofed.
      • +
    • If the signature is validated but at least one of the signers's fingerprints is not trusted, the client SHOULD display a warning message stating that the signature is validated but unreliable, and that the message may be forged.
      • +
    • If all signatures are validated and all signers' fingerprints are trusted, the client SHOULD display an information message or indication that the item is signed by one or more trusted signers.
      • +
    +     + + +

    If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:pubsub-signing:0" discovery feature in response to a &xep0030; information request:

    + + + +]]> + + + ... + + ... + +]]> +     + + +

    Signature is intimely linked to the trust in the fingerprint of the encryption keys. A warning SHOULD be displayed by a client if a signature is valid but the signing entity's fingerprints are not trusted. Trust should be done through an external channel (outside of XMPP), preferably face-to-face.

    +

    Security considerations of the signing profile applies.

    +     + + +

    TODO

    +     + +

    TODO

    +     + +

    TODO

    +     + +

    Thanks to NLnet foundation/NGI0 Discovery for funding.

    +     +     diff --git a/xep.ent b/xep.ent index d87a9995..b620c7ab 100644 --- a/xep.ent +++ b/xep.ent @@ -1670,3 +1670,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates PubSub Social Feed (XEP-0472) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>." > OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>." > SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>." > +Pubsub Signing (XEP-0475) XEP-0475: Pubsub Signing <https://xmpp.org/extensions/xep-0475.html>." > From d78a3a3a0fb71540f5dca92711a3503153e24727 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Dec 2022 18:43:04 +0100 Subject: [PATCH 28/51] Accept inbox/pubsub-signing-openpgp.xml as XEP-0476 --- xep-0476.xml | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 112 insertions(+) create mode 100644 xep-0476.xml diff --git a/xep-0476.xml b/xep-0476.xml new file mode 100644 index 00000000..7bb6fdd4 --- /dev/null +++ b/xep-0476.xml @@ -0,0 +1,111 @@ + + +%ents; +]> + + +
    + Pubsub Signing: OpenPGP Profile + Specifies a pubsub signing profile for OpenPGP + &LEGALNOTICE; + 0476 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0004 + XEP-0060 + XEP-0373 + + + + pss-ox + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.1.0 + 2022-12-20 + XEP Editor (jsc) + Accepted by vote of Council on 2022-11-30. + + + 0.0.1 + 2022-10-29 + jp +

    First draft.

     +     +
    + +

    This XMPP extension protocol specifies a profile of Pubsub Signing to use OpenPGP for signature.

    +     + +

    Signing an item with OpenPGP requires to have &xep0373; implemented to handle keys, however this specification uses its own <sign/> element because it uses wrapper element from Pubsub Signing XEP, and signed data MUST NOT be included with the signature.

    +

    To sign an element, a client process as explained in XEP-0XXX § Signing a Pubsub Item where the "signing profile" element used is a <sign/> element qualified by the 'urn:xmpp:pubsub-signing:openpgp:0' namespace. This element MUST contain a Base64 encoded (&rfc4648; § 4) OpenPGP message as specified in &rfc4880; which MUST contain a detached signature as defined in &rfc4880; § 11.4 of the signed data as specified in XEP-0XXX § Signing a Pubsub Item.

    + + + + + + + + + + + + + + ]]> +     + + +

    If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:pubsub-signing:openpgp:0" discovery feature in response to a &xep0030; information request:

    + + + +]]> + + + ... + + ... + +]]> +     + + +

    Security considerations of &xep0373; and XEP-0XXX apply.

    +     + + +

    TODO

    +     + +

    TODO

    +     + +

    TODO

    +     + +

    Thanks to NLnet foundation/NGI0 Discovery for funding.

    +     +     diff --git a/xep.ent b/xep.ent index b620c7ab..d7f49577 100644 --- a/xep.ent +++ b/xep.ent @@ -1671,3 +1671,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>." > SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>." > Pubsub Signing (XEP-0475) XEP-0475: Pubsub Signing <https://xmpp.org/extensions/xep-0475.html>." > +Pubsub Signing: OpenPGP Profile (XEP-0476) XEP-0476: Pubsub Signing: OpenPGP Profile <https://xmpp.org/extensions/xep-0476.html>." > From 89ec670e36191019c6c243487360f16862bb1883 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Dec 2022 18:43:14 +0100 Subject: [PATCH 29/51] Accept inbox/pubsub-targeted-encryption.xml as XEP-0477 --- xep-0477.xml | 127 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 128 insertions(+) create mode 100644 xep-0477.xml diff --git a/xep-0477.xml b/xep-0477.xml new file mode 100644 index 00000000..ae15bb58 --- /dev/null +++ b/xep-0477.xml @@ -0,0 +1,127 @@ + + +%ents; +]> + + +
    + Pubsub Targeted Encryption + Specifies a way to encrypt pubsub items for a restricted set of entities + &LEGALNOTICE; + 0477 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0004 + XEP-0060 + XEP-0384 + + + + pte + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.1.0 + 2022-12-20 + XEP Editor (jsc) + Accepted by vote of Council on 2022-11-30. + + + 0.0.1 + 2022-10-31 + jp +

    First draft.

     +     +
    + +

    While it is nowadays possible to encrypt pubsub items with OpenPGP for XMPP Pubsub, this specification is designed for pubsub nodes were all items are end-to-end encrypted, and it is using symmetric encryption with a system of key sharing, meaning that if a key is available, it can decrypt all items encrypted with it.

    +

    This is fine for most use cases, however it may be desirable to only encrypt a few items with properties such as Perfect Forward Secrecy. This specification describes a way on how to do that by adapting existing end-to-end encryption algorithms used in instant messaging to pubsub items. This may be used to implement restricted items (a feature known is some other software such as "aspects" or "circles") or for transient nodes.

    +     + +

    The design goal of this specification is do adapt simply existing e2e encryption algorithms used for messages to pubsub items.

    +     + + + +

    Juliet holds a public blog using &xep0277;. However, she wants to publish a new items that should be visible only to some well targeted users. To do so she encrypt the payload in the same way as she encrypt messages with algorithm such as &xep0384;. She wrap the encrypted payload in an <encrypted/> element qualified by the 'urn:xmpp:pte:0' namespace which MUST have a 'by' attribute with its own bare jid as value, and which MUST have a 'type' attribute whose value is the namespace of the algorithm used.

    +

    She decides to use &xep0384; to encrypt her items, her client publish an item like this:

    + + + + + + +
    + + ChDRqSBLTR+RtRIH8io7kf22EmgIARACGiCasIYfB6Zfe5SNyT8twIa+mEYA8h7uEQIjQ64dJx4vXiJAZSpXPRW+sVVSC7gc4lDEiTA4DT7AIh/woa82PFjgFdL0A8HTyBe7yh3UWThZGuTp5A3zmjXH7pAwKX85oxQ8XA== + +
    + DWmAVvrKlPPh23OmvmIrJmQXj5hVtgAnY8IOGZNqJc59T93hzsTen7tw7Kea5KfM3btfS25xd6RRWe0ZrqdvdGtKfHJFc77k5pQ052br4Qxw9kLWCVGqpNkrpwoBUshqs5mwA1WRLGdUfEsMaePwZv4m9xvXZSrxNIf9vQNX/GJM2GAT55exZSRU0Px8/E8j0XMtHCuZ4j3z0EBk1NZin0suQv8rVy1liWACPNuVrnU7h8LpdWmUggYztqL9l1yoxzEOFRrpdFkDqcZDLbO8bWAcYQNpWYoefaYvnvLV4zkW4dELQydSC2KkGMN/LmdYspVUPzPpQt7OmAKAndFWXTsAV5wmbtVsr15TzxI4NVDZyp7G70TYyTHlhG2gAq7StVj09bJi6IHa59L1BgNrNKT/ZG8pbe/GXUoPg4q9ZfuDiOYBHUugUxNsVFactRp6UocaQT/RogrqKY3o6NlTvnqVYpMJsi72cp8uQWTPtqwBpxyhAY0jKp1D+y7m2wzbeD2SZCw5+FryXulQhCKJ0dLI00PJr4dELWdu+uQLdyHl5FxG4D8mLQVOnY/TMa0vXUxsMAQI8g8LEHdJIhKU4GyVt125WhrbMrbcBu8iKCYmiz820siZeD8i5iZa1eQ69hnA9iCqMRS2DsqieUeI1Y4I7+0pHcyzpNC8408B7LhkgwxOEopExdOfv1NFwamsN5zXhCqj386oGRl9Ry0Gw+QSv9jlW4FB0rM8r+GF5gB66p0nYU/U5W8efXgNI/W1yAdUxgXc9FiQMmzIauTmR4m5WUxPjBggVYz1q3TkeZHQJpWy47EWZPnM9leWKNqC +     +     +     +     +     + +]]>     +     + +     + + +

    The properties of the encryption algorithm applies. For instance in the case of &xep0384;, there Perfect Forward Secrecy, meaning that once an item has been decrypted once by a targeted entity, it can't be decrypted anymore. Client shoud then handle pubsub caching of the decrypted item when necessary.

    +     + + +

    If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:pte:0" discovery feature in response to a &xep0030; information request, Then the supported encryption algorithms are announced as explained in their respective XEPs.

    + + + +]]> + + + ... + + + ... + +]]> + +     + + +

    Security Considerations of used encryption specifications apply.

    +     + + +

    TODO

    +     + +

    TODO

    +     + +

    TODO

    +     + +

    Thanks to NLNet foundation/NGI0 Discovery for funding.

    +     +     diff --git a/xep.ent b/xep.ent index d7f49577..a444b777 100644 --- a/xep.ent +++ b/xep.ent @@ -1672,3 +1672,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates SASL SCRAM Downgrade Protection (XEP-0474) XEP-0474: SASL SCRAM Downgrade Protection <https://xmpp.org/extensions/xep-0474.html>." > Pubsub Signing (XEP-0475) XEP-0475: Pubsub Signing <https://xmpp.org/extensions/xep-0475.html>." > Pubsub Signing: OpenPGP Profile (XEP-0476) XEP-0476: Pubsub Signing: OpenPGP Profile <https://xmpp.org/extensions/xep-0476.html>." > +Pubsub Targeted Encryption (XEP-0477) XEP-0477: Pubsub Targeted Encryption <https://xmpp.org/extensions/xep-0477.html>." > From 21b353e39b98fd58f79be7e95308d31633ab5d76 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Dec 2022 18:43:47 +0100 Subject: [PATCH 30/51] XEP-0428: add Marvin as co-author As per council vote. --- xep-0428.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0428.xml b/xep-0428.xml index e0bb6669..3802a5d4 100644 --- a/xep-0428.xml +++ b/xep-0428.xml @@ -22,6 +22,7 @@ fallback &dcridland; + &larma; 0.1.1 2020-03-03 From b4bacd8f415cacc633d750f59ea760d28854396d Mon Sep 17 00:00:00 2001 From: nicoco Date: Thu, 1 Dec 2022 06:50:26 +0100 Subject: [PATCH 31/51] Add MUC service shutdown example --- xep-0045.xml | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/xep-0045.xml b/xep-0045.xml index c102cb9d..331fbc14 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -45,6 +45,12 @@ &stpeter; + + 1.34.5 + 2022-12-01 + NC +

    Add MUC service shut down example.

     +     1.34.4 2022-10-05 @@ -4986,6 +4992,31 @@ and they are not linked to any user (e.g. moderator) action that the 307 code usually indicates. It is therefore recommended for the client to ignore the 307 code if a 333 status code is present.

    + +

    When a MUC service shuts downs, it SHOULD inform its participant by sending presences containing the 332 status code

    + + + + + + + + + + + + + + +]]> +     From 958aad87ab5181df25cd61a080fa99152adaea2f Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Wed, 19 Oct 2022 14:53:32 +0200 Subject: [PATCH 32/51] Initial commit of Path MTU protoXEP --- inbox/pathmtu.xml | 193 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 193 insertions(+) create mode 100644 inbox/pathmtu.xml diff --git a/inbox/pathmtu.xml b/inbox/pathmtu.xml new file mode 100644 index 00000000..152f03e0 --- /dev/null +++ b/inbox/pathmtu.xml @@ -0,0 +1,193 @@ + + +%ents; +]> + +
    +Stanza size limit discovery +This documents describes a mechanism for communicating stanza size limits across streams in order to help avoid reaching those limits. +&LEGALNOTICE; +xxxx +ProtoXEP +Standards Track +Standards + + + +NOT_YET_ASSIGNED + +Kim +Alvefur +zash@zash.se +zash@zash.se + + +0.0.1 +2021-08-20 +ka + +

    Early draft

    +     +     + +nil +2021-08-25 +ka + +

    more work

    +     +     + +nil +2021-08-28 +ka + +

    more words

    +     +     +
    + + +

    This documents describes a mechanism for communicating the stanza size +limit that is in effect on a particular stream, in order to allow the +other party to avoid reaching those limits.

    + + + +

    When stanza size limits have been deployed, very often this leads to +problems with large stanzas causing connection outages, most often +vCards and Avatar stanzas.

    + +

    If stanza size limit violations are met with stream errors then this may +lead to temporary connection outage, which may a few seconds to recover +from.

    + +

    Especially vCard and Avatar stanzas may be very large and sometimes +exceed the stanza size limit imposed.

    + +     + +
      +
    • Enable discovery of the stanza size limit in use on a stream.
      • +
    + + + +
      +
    • bi-directional?
      • +
    • disco too?
      • +
    • some sort of path mtu discovery method?
      • +
    • error condition?
      • +
    • rewrite large iq-result to error?
      • +
    + +     + +

    OPTIONAL.

    + +     + +
      +
    • An XMPP client could attempt to apply more compression if it sees +that an avatar it is about to upload would be too large.
      • +
    • A PubSub server could limit the number of items in an <items/> +query to ensure it can be delivered.
      • +
    + +     + +

    If after serialization to XML a stanza is too large, like, don’t send +it. Synthesize an error condition, most likely a (modify, +policy-violation), and pretend the remote entity replied with this.

    + +     + +

    Something about margins, due to variations in XML serialization, added +attributes (e.g. the from attribute stamped by servers) or elements +(delay tags)

    + +

    Because the stanza size limit is known ahead of time, entities can check +this against stanzas they are about to send and take appropriate action, +such as preemptively pretending that the stanza was rejected by the +receiving entity.

    + +

    A client could for example try to apply more compression to an avatar or +ask the user to select a smaller picture.

    + +     + +

    OPTIONAL.

    + +

    Not relevant?

    + +     + +

    OPTIONAL.

    + +

    Not relevant?

    + +     + +

    The responding entity advertises the stanza size limit it enforces +by including it as an integer in a stream feature element +stanza-size-limit in the namespace urn:xmpp:tmp:TBD. An example of +stream features prior to authentication follows:

    + + + + SCRAM-SHA-1 + PLAIN + + 10000 +]]> + +

    Entities may wish to have hire limits after authentication and would +advertise it the same way after the stream restart:

    + + + + + + 262144 +]]> + +     + +

    REQUIRED.

    + +

    Very large stanzas may incur memory and processing costs on the +receiving entity. Advertising the actual limits could inform an attacker +of how large a stanza to construct in order to maximize e.g. DoS +effectiveness. Best combined with network level rate limits on raw +bytes.

    + +

    Also see https://xmpp.org/rfcs/rfc6120.html#rfc.section.13.12

    + +

    TBD Recommendations for limits?

    + +     + +

    None.

    + +     + +

    Need the stream feature registered.

    + +     + +

    RECOMMENDED.

    + +

    Design? I just typed words and code into my computer!

    + +     + +

    REQUIRED for protocol specifications.

    + + +     +     + From e60fd2b83dff93b30e001a3a290f3266e69ad581 Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Tue, 22 Nov 2022 19:59:08 +0100 Subject: [PATCH 33/51] ProtoXEP editorial help by MattJ My earliest drafts were on 2021-08-20. Have mosly working implementation that interops with itself. --- inbox/pathmtu.xml | 193 ---------------------------------------------- inbox/xep-sla.xml | 126 ++++++++++++++++++++++++++++++ 2 files changed, 126 insertions(+), 193 deletions(-) delete mode 100644 inbox/pathmtu.xml create mode 100644 inbox/xep-sla.xml diff --git a/inbox/pathmtu.xml b/inbox/pathmtu.xml deleted file mode 100644 index 152f03e0..00000000 --- a/inbox/pathmtu.xml +++ /dev/null @@ -1,193 +0,0 @@ - - -%ents; -]> - -
    -Stanza size limit discovery -This documents describes a mechanism for communicating stanza size limits across streams in order to help avoid reaching those limits. -&LEGALNOTICE; -xxxx -ProtoXEP -Standards Track -Standards - - - -NOT_YET_ASSIGNED - -Kim -Alvefur -zash@zash.se -zash@zash.se - - -0.0.1 -2021-08-20 -ka - -

    Early draft

    -     -     - -nil -2021-08-25 -ka - -

    more work

    -     -     - -nil -2021-08-28 -ka - -

    more words

    -     -     -
    - - -

    This documents describes a mechanism for communicating the stanza size -limit that is in effect on a particular stream, in order to allow the -other party to avoid reaching those limits.

    - - - -

    When stanza size limits have been deployed, very often this leads to -problems with large stanzas causing connection outages, most often -vCards and Avatar stanzas.

    - -

    If stanza size limit violations are met with stream errors then this may -lead to temporary connection outage, which may a few seconds to recover -from.

    - -

    Especially vCard and Avatar stanzas may be very large and sometimes -exceed the stanza size limit imposed.

    - -     - -
      -
    • Enable discovery of the stanza size limit in use on a stream.
      • -
    - - - -
      -
    • bi-directional?
      • -
    • disco too?
      • -
    • some sort of path mtu discovery method?
      • -
    • error condition?
      • -
    • rewrite large iq-result to error?
      • -
    - -     - -

    OPTIONAL.

    - -     - -
      -
    • An XMPP client could attempt to apply more compression if it sees -that an avatar it is about to upload would be too large.
      • -
    • A PubSub server could limit the number of items in an <items/> -query to ensure it can be delivered.
      • -
    - -     - -

    If after serialization to XML a stanza is too large, like, don’t send -it. Synthesize an error condition, most likely a (modify, -policy-violation), and pretend the remote entity replied with this.

    - -     - -

    Something about margins, due to variations in XML serialization, added -attributes (e.g. the from attribute stamped by servers) or elements -(delay tags)

    - -

    Because the stanza size limit is known ahead of time, entities can check -this against stanzas they are about to send and take appropriate action, -such as preemptively pretending that the stanza was rejected by the -receiving entity.

    - -

    A client could for example try to apply more compression to an avatar or -ask the user to select a smaller picture.

    - -     - -

    OPTIONAL.

    - -

    Not relevant?

    - -     - -

    OPTIONAL.

    - -

    Not relevant?

    - -     - -

    The responding entity advertises the stanza size limit it enforces -by including it as an integer in a stream feature element -stanza-size-limit in the namespace urn:xmpp:tmp:TBD. An example of -stream features prior to authentication follows:

    - - - - SCRAM-SHA-1 - PLAIN - - 10000 -]]> - -

    Entities may wish to have hire limits after authentication and would -advertise it the same way after the stream restart:

    - - - - - - 262144 -]]> - -     - -

    REQUIRED.

    - -

    Very large stanzas may incur memory and processing costs on the -receiving entity. Advertising the actual limits could inform an attacker -of how large a stanza to construct in order to maximize e.g. DoS -effectiveness. Best combined with network level rate limits on raw -bytes.

    - -

    Also see https://xmpp.org/rfcs/rfc6120.html#rfc.section.13.12

    - -

    TBD Recommendations for limits?

    - -     - -

    None.

    - -     - -

    Need the stream feature registered.

    - -     - -

    RECOMMENDED.

    - -

    Design? I just typed words and code into my computer!

    - -     - -

    REQUIRED for protocol specifications.

    - - -     -     - diff --git a/inbox/xep-sla.xml b/inbox/xep-sla.xml new file mode 100644 index 00000000..f31a2981 --- /dev/null +++ b/inbox/xep-sla.xml @@ -0,0 +1,126 @@ + + +%ents; +]> + + +
    + Stream Limits Advertisement + This specification defines a way for an XMPP entity to announce the limits it will enforce for data received on a stream. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + sla + + Kim + Alvefur + zash@zash.se + zash@zash.se + + &mwild; + + 0.0.1 + 2022-10-20 + ka, mw +

    First draft.

     +     +
    + +

    This documents describes a mechanism for communicating limits, such as stanza size limits that is in effect on a particular stream, in order to allow the sending party to avoid reaching those limits.

    + +

    Where stanza size limits have been deployed, very often this leads to problems with large stanzas causing connection outages, most often &xep0084; and &xep0053; result stanzas, which can be very large due to embedded images.

    +

    If stanza size limit violations are met with stream errors then this may lead to temporary connection outage, which may a few seconds to recover from.

    +     +     + +
      +
    • Enable discovery of the stanza size limit in use on a stream.
      • +
    • Support for bi-directional streams.
      • +
    +

    These requirements will enable XMPP clients and servers to adapt data they generate, such that it will fit within the limits required by the recipient, or reject overly large stanzas early, rather than following a trial-and-error approach.

    +     + + +

    For any XMPP stream, there is an "initiating entity" (a client or server) and a "responding entity" that they are connecting to. The responding entity advertises its limits in the <stream:features/> element that it sends at the start of the stream.

    +

    The limits are enclosed in a <limits/> element qualified by the 'urn:xmpp:stream-limits:0' namespace. This element SHOULD contain the following child elements:

    +
    + +
    <max-bytes/>
    +
    Contains an integer representing the maximum size of any first-level stream elements (including stanzas), in bytes. Guidance on acceptable limits is provided in &rfc6120; section 13.12.
    +     + +
    <idle-seconds/>
    +
    Contains an integer representing the number of seconds without any traffic from the iniating entity after which the server may consider the stream idle, and either perform liveness checks (using e.g. &xep0198; or &xep0199;) or terminate the stream. Guidance on handling idle connections is provided in &rfc6120; section 4.6.
    +     +
    + + + SCRAM-SHA-1 + PLAIN + + + 10000 + 1800 + + + ]]> +     + +

    Servers using &xep0288; to establish a bidirectional stream with another server do not get an opportunity to send <stream:features/> to the responding entity. For a server to advertise the limits about what it is willing to accept on such a stream, the <limits/> element can be included in the <bidi/> element.

    + + + 10000 + 1800 + + + ]]> +     +     + +

    If, after serialization, a stanza exceeds the limits that have been advertised on a stream, it SHOULD NOT be sent on that stream. Instead, a server SHOULD return an error to the sender. Such an error SHOULD contain the <policy-violation/> error condition, and SHOULD NOT contain a 'by' attribute (as the policy being violated is not the current entity's). A <text/> may also be included, explaining the limit that would be exceeded.

    +

    It is acceptable for the limits on a stream to change whenever new stream features are announced - such as before and after authentication of the connecting entity.

    +     + +

    OPTIONAL.

    +     + +

    OPTIONAL.

    +     + +

    OPTIONAL.

    +     + +

    REQUIRED.

    +

    Very large stanzas may incur memory and processing costs on the receiving entity. Advertising the actual limits could inform an attacker of how large a stanza to construct in order to maximize e.g. DoS effectiveness. Best combined with network level rate limits on raw bytes.

    +     + +

    None.

    +     + +

    This specification defines the following namespace:

    +
      +
    • urn:xmpp:stream-limits:0
      • +
    +

    Also, the following stream feature:

    +
      +
    • <limits xmlns='urn:xmpp:stream-limits:0'/>
      • +
    +     + +

    The ability for a client to announce limits on what it will receive on a client-to-server stream is deliberately not provided by this specification. This vastly simplifies discovery of the maximum limits between any two JIDs, and it avoids situations where the server is unable to deliver incoming stanzas to some or all of an account's connected clients. Clients will already be protected from denial-of-service through excessive stanza sizes due to the server's own limits.

    +     + +

    TBD.

    +     +     From 242d36e65da3a387c102a65ad29d03910826d545 Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Sun, 18 Dec 2022 21:20:20 +0100 Subject: [PATCH 34/51] sla: Clarify direction of limits advertisment (thanks Flow) Co-authored-by: Florian Schmaus --- inbox/xep-sla.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/xep-sla.xml b/inbox/xep-sla.xml index f31a2981..ee6d1bf1 100644 --- a/inbox/xep-sla.xml +++ b/inbox/xep-sla.xml @@ -55,7 +55,7 @@
    <max-bytes/>
    -
    Contains an integer representing the maximum size of any first-level stream elements (including stanzas), in bytes. Guidance on acceptable limits is provided in &rfc6120; section 13.12.
    +
    Contains an integer representing the maximum size of any first-level stream elements (including stanzas), in bytes the announcing entity is willing to accept. Guidance on acceptable limits is provided in &rfc6120; section 13.12.
    <idle-seconds/>
    From 00b5aee8168489a1020df32887d0ba38eb323f8a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 20 Dec 2022 19:31:09 +0100 Subject: [PATCH 35/51] XEP-0001 validator: allow xxxx as number --- tools/validate-xep0001-conformance.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index 79fcceb6..34c468f9 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -61,10 +61,10 @@ else validation_result=1 fi - # 3.2 That the /xep/header/number/text() (XPath) is literally XXXX - if [ "$header_number" = "XXXX" ] + # 3.2 That the /xep/header/number/text() (XPath) is literally XXXX or xxxx + if [ "$header_number" = "XXXX" ] || [ "$header_number" = "xxxx" ] then - echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX'." + echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX' (case insensitive)." else echo "[FAIL] XPATH value /xep/header/number/text() ('$header_status') does not equal 'XXXX' (but should)." validation_result=1 From aa0318ca5e412fe8a328b5193305e9865c99bef0 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 21 Dec 2022 09:25:08 +0100 Subject: [PATCH 36/51] Add color to output of XEP validation script Github workflows tend to be verbose. This can make it difficult to determine why a failure occurs. To help identify causes for validation failures, the output of the XEP-0001 conformance script should have a bit of color to highlight the important bits. --- tools/validate-xep0001-conformance.sh | 73 +++++++++++++++------------ 1 file changed, 41 insertions(+), 32 deletions(-) diff --git a/tools/validate-xep0001-conformance.sh b/tools/validate-xep0001-conformance.sh index 34c468f9..c89e1441 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -14,15 +14,24 @@ set -euo pipefail +# ANSI color definitions +ANSI_INFO='\033[1;94m'; +ANSI_PASS='\033[1;92m'; +ANSI_FAIL='\033[1;91m'; +ANSI_RESET='\033[0m'; + validation_result=0 +echo -e "Start validating file '$1'." +echo "" + # 1. Check DTD conformance against xep.dtd xep_dtd="xep.dtd" if xmllint --noout --dtdvalid "$xep_dtd" "$1" then - echo "[PASS] DTD conformance against xep.dtd" + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} DTD conformance against xep.dtd" else - echo "[FAIL] DTD conformance against xep.dtd" + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} DTD conformance against xep.dtd" validation_result=1; fi @@ -39,54 +48,54 @@ processing_instructions=$(xmllint --xpath '/processing-instruction("xml-styleshe if echo "$file_name" | grep -Eq "^xep-[0-9]{4}.xml$" then - echo "[INFO] The filename ('$file_name') matches 'xep-[0-9]{4}.xml'." + echo -e "${ANSI_INFO}[INFO]${ANSI_RESET} The filename ('$file_name') matches 'xep-[0-9]{4}.xml'." # 2. If the filename matches xep-[0-9]{4}.xml, check: # 2.1 that the number in the filename equals /xep/header/number (XPath) if [ "$file_name" = "xep-$header_number.xml" ] then - echo "[PASS] The number in the filename ('$file_name') equals XPATH value /xep/header/number/text() ('$header_number')." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} The number in the filename ('$file_name') equals XPATH value /xep/header/number/text() ('$header_number')." else - echo "[FAIL] The number in the filename ('$file_name') does not equals XPATH value /xep/header/number/text() ('$header_number') (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} The number in the filename ('$file_name') does not equals XPATH value /xep/header/number/text() ('$header_number') (but should)." validation_result=1 fi else - echo "[INFO] The filename ('$file_name') does not match 'xep-[0-9]{4}.xml'." + echo -e "${ANSI_INFO}[INFO]${ANSI_RESET} The filename ('$file_name') does not match 'xep-[0-9]{4}.xml'." # 3. If the filename does not match xep-[0-9]{4}.xml, check: # 3.1 That the /xep/header/status/text() (XPath) is ProtoXEP if [ "$header_status" = "ProtoXEP" ] then - echo "[PASS] XPATH value /xep/header/status/text() ('$header_status') equals 'ProtoXEP'." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/status/text() ('$header_status') equals 'ProtoXEP'." else - echo "[FAIL] XPATH value /xep/header/status/text() ('$header_status') does not equal 'ProtoXEP' (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/status/text() ('$header_status') does not equal 'ProtoXEP' (but should)." validation_result=1 fi # 3.2 That the /xep/header/number/text() (XPath) is literally XXXX or xxxx if [ "$header_number" = "XXXX" ] || [ "$header_number" = "xxxx" ] then - echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX' (case insensitive)." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/number/text() ('$header_status') equals '$header_number'." else - echo "[FAIL] XPATH value /xep/header/number/text() ('$header_status') does not equal 'XXXX' (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/number/text() ('$header_status') does not equal 'XXXX' or 'xxxx' (but should)." validation_result=1 fi # 3.3 That the name does not start with xep-[0-9] if echo "$file_name" | grep -Eq "^xep-[0-9].*$" then - echo "[FAIL] The filename ('$file_name') starts with 'xep-[0-9]' (but should not)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} The filename ('$file_name') starts with 'xep-[0-9]' (but should not)." validation_result=1 else - echo "[PASS] The filename ('$file_name') does not start with 'xep-[0-9]'." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} The filename ('$file_name') does not start with 'xep-[0-9]'." fi fi # 4. Check that /xep/header/status/text() (XPath) is a defined status (see tools/xeplib.py for an enum) case $header_status in ProtoXEP | Experimental | Proposed | Draft | Active | Final | Retracted | Obsolete | Deferred | Rejected | Deprecated ) - echo "[PASS] XPATH value /xep/header/status/text() ('$header_status') equals a defined status." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/status/text() ('$header_status') equals a defined status." ;; *) - echo "[FAIL] XPATH value /xep/header/status/text() ('$header_status') does not equals a defined status (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/status/text() ('$header_status') does not equals a defined status (but should)." validation_result=1 ;; esac @@ -99,10 +108,10 @@ case $file_name in 'xep-0001.xml' | 'xep-0002.xml' | 'xep-0019.xml' | 'xep-0053.xml' | 'xep-0143.xml' | 'xep-0182.xml' | 'xep-0345.xml' | 'xep-0381.xml' | 'xep-0429.xml' | 'xep-0458.xml' ) case $header_type in Historical | Humorous | Informational | Organizational | 'Standards Track' | 'Procedural' ) - echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') equals a defined type." ;; *) - echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." validation_result=1 ;; esac @@ -110,10 +119,10 @@ case $file_name in 'xep-0006.xml' | 'xep-0010.xml' | 'xep-0069.xml' | 'xep-0139.xml' ) case $header_type in Historical | Humorous | Informational | Organizational | 'Standards Track' | 'SIG Formation' ) - echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') equals a defined type." ;; *) - echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." validation_result=1 ;; esac @@ -121,10 +130,10 @@ case $file_name in 'xep-0007.xml' ) case $header_type in Historical | Humorous | Informational | Organizational | 'Standards Track' | 'SIG Proposal' ) - echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') equals a defined type." ;; *) - echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." validation_result=1 ;; esac @@ -132,10 +141,10 @@ case $file_name in * ) case $header_type in Historical | Humorous | Informational | Organizational | 'Standards Track' ) - echo "[PASS] XPATH value /xep/header/type/text() ('$header_type') equals a defined type." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') equals a defined type." ;; *) - echo "[FAIL] XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/type/text() ('$header_type') does not equals a defined type (but should)." validation_result=1 ;; esac @@ -145,10 +154,10 @@ esac # 6. Check that /xep/header/approver/text() (XPath) is either Board or Council case $header_approver in Board | Council ) - echo "[PASS] XPATH value /xep/header/approver/text() ('$header_approver') equals either 'Board' or 'Council'." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/approver/text() ('$header_approver') equals either 'Board' or 'Council'." ;; *) - echo "[FAIL] XPATH value /xep/header/approver/text() ('$header_approver') does not equals 'Board' or 'Council' (but should)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/approver/text() ('$header_approver') does not equals 'Board' or 'Council' (but should)." validation_result=1 ;; esac @@ -157,9 +166,9 @@ esac expected_revision_order=$(echo "$header_revisions" | tr " " "\n" | sort -Vr) if [ "$expected_revision_order" = "$header_revisions" ] then - echo "[PASS] Version numbers in the revision blocks are descending." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} Version numbers in the revision blocks are descending." else - echo "[FAIL] Version numbers in the revision blocks are not ordered (descending from top to bottom in the document) (but should be)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} Version numbers in the revision blocks are not ordered (descending from top to bottom in the document) (but should be)." echo " Order found : $(echo $header_revisions)" # funky $() nesting to remove newlines. echo " Expected was: $(echo $expected_revision_order)" validation_result=1 @@ -170,28 +179,28 @@ if [ "$header_approver" = "Board" ] then if [ "$header_type" = "Standards Track" ] then - echo "[FAIL] XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' but XPATH value /xep/header/type/text() is 'Standards Track' (it should not be)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' but XPATH value /xep/header/type/text() is 'Standards Track' (it should not be)." validation_result=1 else - echo "[PASS] XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' and XPATH value /xep/header/type/text() is not 'Standards Track'." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} XPATH value /xep/header/approver/text() ('$header_approver') is 'Board' and XPATH value /xep/header/type/text() is not 'Standards Track'." fi fi # 9. Check that it uses the xep.xsl XML stylesheet. if echo "$processing_instructions" | grep -Eq "href=['\"]xep.xsl['\"]" then - echo "[PASS] xep.xsl XML stylesheet is used." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} xep.xsl XML stylesheet is used." else - echo "[FAIL] xep.xsl XML stylesheet is not used (but should be)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} xep.xsl XML stylesheet is not used (but should be)." validation_result=1 fi # 10. Check that it includes the correct legal notice (by checking for the entity reference) if grep -q "&LEGALNOTICE;" "$1" then - echo "[PASS] entity reference for the legal notice has been detected." + echo -e "${ANSI_PASS}[PASS]${ANSI_RESET} entity reference for the legal notice has been detected." else - echo "[FAIL] entity reference for the legal notice has not been detected (but it should have been)." + echo -e "${ANSI_FAIL}[FAIL]${ANSI_RESET} entity reference for the legal notice has not been detected (but it should have been)." validation_result=1 fi From e4fdc477b7b09d8f132ee925e50b1ab3becce9f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Tue, 27 Dec 2022 13:50:38 +0100 Subject: [PATCH 37/51] DTD, XSD: Add tags element in header MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- xep-template.xml | 3 +++ xep.dtd | 4 +++- xep.xsd | 9 +++++++++ 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/xep-template.xml b/xep-template.xml index 23ad1121..178f9283 100644 --- a/xep-template.xml +++ b/xep-template.xml @@ -22,6 +22,9 @@ NOT_YET_ASSIGNED + + template + Peter Saint-Andre diff --git a/xep.dtd b/xep.dtd index 4dd6442b..b1162dad 100644 --- a/xep.dtd +++ b/xep.dtd @@ -27,7 +27,7 @@ THE SOFTWARE. - + @@ -68,6 +68,8 @@ THE SOFTWARE. + + + @@ -196,6 +197,14 @@ THE SOFTWARE. + + + + + + + + From ac1eda3476371edd3b84c8498d63a7b2a281823c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Maxime=20=E2=80=9Cpep=E2=80=9D=20Buquet?= Date: Tue, 27 Dec 2022 15:23:41 +0100 Subject: [PATCH 38/51] extract-metadata.py: Add tag info to xeplist.xml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Maxime “pep” Buquet --- tools/extract-metadata.py | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/tools/extract-metadata.py b/tools/extract-metadata.py index cf0ecbda..68ab67fa 100755 --- a/tools/extract-metadata.py +++ b/tools/extract-metadata.py @@ -101,6 +101,12 @@ def extract_xep_metadata(document): else: last_call = None + tags = [] + tags_elem = minidom_find_child(header, "tags") + if tags_elem is not None: + for child in minidom_children(tags_elem): + tags.append(minidom_get_text(child)) + return { "last_revision": { "version": last_revision_version, @@ -113,6 +119,7 @@ def extract_xep_metadata(document): "sig": sig, "abstract": abstract, "shortname": shortname, + "tags": tags, "title": title, "approver": approver, "last_call": last_call, @@ -137,6 +144,12 @@ def make_metadata_element(number, metadata, accepted, *, protoname=None): if metadata["shortname"] is not None: result.append(text_element("shortname", metadata["shortname"])) + if metadata["tags"]: + tags = etree.Element("tags") + for tag in metadata["tags"]: + tags.append(text_element("tag", tag)) + result.append(tags) + if metadata["last_revision"]["version"] is not None: last_revision = metadata["last_revision"] revision_el = etree.Element("last-revision") From 29809ef1b58ed94dda4c51c151e4f358d1e9622b Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Tue, 27 Dec 2022 17:01:07 +0100 Subject: [PATCH 39/51] tool/xep2md: Record all list metadata items E.g. lastcall can exist more than once according to the schema, but only one item was kept. Before: ```yaml lastcall: 2017-11-15 ``` After: ```yaml lastcall: - 2021-03-30 - 2017-11-15 ``` --- tools/xep2md.lua | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/tools/xep2md.lua b/tools/xep2md.lua index 019710e0..624b3bee 100644 --- a/tools/xep2md.lua +++ b/tools/xep2md.lua @@ -247,11 +247,21 @@ local header_schema = [[ supersededby , shortname , schemaloc* , registry? , discuss? , expires? , author+ , revision+ , councilnote?) ]]; -for field in header_schema:gmatch("%w+") do - events.add_handler(field.."#text", function (event) - meta[field] = event.text:match("%S.*%S"); - return true; - end); +for field, mod in header_schema:gmatch("(%w+)([*+?]?)") do + if mod == "" or mod == "?" then + events.add_handler(field .. "#text", function(event) + meta[field] = event.text:match("%S.*%S"); + return true; + end); + elseif mod == "*" or mod == "+" then + events.add_handler(field .. "#text", function(event) + if not meta[field] then + meta[field] = {}; + end + table.insert(meta[field], event.text:match("%S.*%S")); + return true; + end); + end end do From 5a55805a67a51427e3717a90e515b5a2b52173ec Mon Sep 17 00:00:00 2001 From: Kim Alvefur Date: Tue, 27 Dec 2022 17:27:08 +0100 Subject: [PATCH 40/51] tools/2xep: Fix encoding of simple list metadata An extra wrapper element was added ``` 2017-11-15 ``` Correct is one element with text for each item ``` 2017-11-15 ``` --- tools/2xep.lua | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/2xep.lua b/tools/2xep.lua index 3ca9ed37..34c46902 100644 --- a/tools/2xep.lua +++ b/tools/2xep.lua @@ -115,7 +115,7 @@ function Doc(body, metadata, variables) end add(""); else - add(("<%s>%s"):format(field, tostring(sv), field)); + add(tostring(sv)); end add(string.format("", field)); end From f773bd7871983466f8793b3b87b3c75de08eb7f6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Timoth=C3=A9e=20Jaussoin?= Date: Sat, 24 Dec 2022 00:04:01 +0100 Subject: [PATCH 41/51] Update XEP-0472 Pubsub Social Feed to 0.1.1 - Change the specified pubsub#type profiles to be more consistent - Rephrase some paragraphs - Fix examples formating --- xep-0472.xml | 185 +++++++++++++++++++++++---------------------------- 1 file changed, 84 insertions(+), 101 deletions(-) diff --git a/xep-0472.xml b/xep-0472.xml index fd3056c0..e09a3b9d 100644 --- a/xep-0472.xml +++ b/xep-0472.xml @@ -6,7 +6,7 @@
    - PubSub Social Feed + Pubsub Social Feed This specification defines a way of publishing social content over XMPP. &LEGALNOTICE; 0472 @@ -32,12 +32,24 @@ edhelas@movim.eu https://edhelas.movim.eu - - 0.1.0 - 2022-12-13 - XEP Editor (jsc) - Accepted by vote of Council on 2022-10-19. - + + 0.1.1 + 2022-12-24 + tj + +
      +
    • Change the specified pubsub#type profiles to be more consistent
      • +
    • Rephrase some paragraphs
      • +
    • Fix examples formating
      • +
    +     +     + + 0.1.0 + 2022-12-13 + XEP Editor (jsc) + Accepted by vote of Council on 2022-10-19. + 0.0.1 2022-09-26 @@ -47,9 +59,9 @@
    -

    Social Networking plaftorms are often built around the concept of feeds. XMPP offers, through &xep0060;, a really generic way of Publishing and Subscribing elements on XMPP nodes. This extension defines a way to publish social content on PubSub nodes using &rfc4287;

    +

    Social Networking plaftorms are often built around the concept of feeds. XMPP offers, through &xep0060;, a really generic way of Publishing and Subscribing elements on XMPP nodes. This extension defines a way to publish social content on Pubsub nodes using &rfc4287;

    -

    Social features in XMPP were historically built on the &xep0277; specifications. However in practice Microblogging was not applicable in more common cases and some related features were not used. The current XEP defines a more generic way of handling Social Feeds on XMPP by keeping the existing Microblogging features as a subset of it.

    +

    Social features in XMPP were historically built on the &xep0277; specifications. However, in practice, Microblogging was not clearly defined in more common cases such as on generic Pubsub nodes and it was not easy to differentiate social nodes from the other ones. The current XEP defines a more generic way of handling Social Feeds on XMPP by declaring a secific pubsub#type for those Pubsub nodes and by keeping &xep0277; as a subset of it.

     @@ -68,7 +80,7 @@

    - A PubSub Social Feed can be located on any PubSub node on the XMPP network. Some specific use cases, such as the personal eventing (PEP) node Microblog is defined in the + A Pubsub Social Feed can be located on any Pubsub node on the XMPP network. Some specific use cases, such as the personal eventing (PEP) node Microblog is defined in the Profiles section.

    @@ -77,8 +89,7 @@

    The publication of a Post consist of a valid &rfc4287; entry embeded in a &xep0060; item.

    The post content itself can be either text (content element without "type" attribute or with "type" attribute with "text" value) or XHTML ("content" element "type" attribute with "xhtml" value). If Romeo publishes XHTML content, his client MUST publish two "content" elements: a text one, and a XHTML one. For XHTML publishing, see &xep0060;.

    - - -]]> - +]]>

    Note: The "title" element is required to be included in an "atom:entry" element according to &rfc4287;. An implementation MAY provide also "atom:summary" and/or "atom:content" elements too if it needs.

    -

    It's possible to insert some rich content in the post or comment. It can be some text formatting, images, etc. Only "xhtml" content type is supported for the moment by this document but possibly it will be extended later. Also, it is RECOMMENDED for the client to restrict XHTML content to the XHTML-IM subset (&xep0071;).

    - - It's possible to insert some rich content in the post. It can be some text formatting, images, etc. Only "xhtml" content type is supported for the moment by this document but possibly it will be extended later.

    + -]]> - +]]>

    - Because Juliet is subscribed to some Romeo's family PubSub service nodes. Romeo's XMPP server will send a PubSub notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with Jabber clients that are not pubsub-capable (see + Because Juliet is subscribed to some Romeo's family Pubsub service nodes. Romeo's XMPP server will send a Pubsub notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with Jabber clients that are not pubsub-capable (see Message Body ).

    - - @@ -160,16 +167,14 @@ -]]> - +]]>

    Note: these alternate links were not posted by the original client because some clients can't compute them themselves. These things SHOULD be inserted at server side though.

    Anyone can publish a post in reply to Romeo's post. Here we assume that a reply comes from Benvolio.

    Note: Inclusion of the "thr:in-reply-to" element defined in &rfc4685; indicates the post to which the user is replying. This reply includes two such elements (one pointing to the HTTP URL for the post and the other pointing to the XMPP URI for the post.

    Note: The post can be a reply to more than the only one another.

    - - -]]> - +]]>

    Assuming that Romeo has also subscribed to the same node he will receive the reply that Benvolio sent.

    When Benvolio wants to repeat a Romeo's post, his client publishes the same post under a different name. But to be able to track the repeated post original author, Benvolio's client MAY use specific "atom:author" child node, "atom:name" and "atom:uri", containing, respectively, the name of the original post author, and his XMPP URI (JID).

    The client SHOULD also put an "atom:link" element with "rel" attribute set to "via" and point it to the original post.

    - - Note that the rules of comparing, building and security notes for "atom:id" are listed in the &rfc4287;.

    -

    Depending on service policies and the value of the "pubsub#include_body" node configuration option, PubSub Social Feed notifications SHOULD include a message "body" element for backwards-compatibility with Jabber clients that are not pubsub-capable. It is RECOMMENDED for the XML character value of the "body" element to be the same as that of the "atom:title" child of the "atom:entry".

    +

    Depending on service policies and the value of the "pubsub#include_body" node configuration option, Pubsub Social Feed notifications SHOULD include a message "body" element for backwards-compatibility with Jabber clients that are not pubsub-capable. It is RECOMMENDED for the XML character value of the "body" element to be the same as that of the "atom:title" child of the "atom:entry".

    Juliet may want to know which places are Romeo's notices related to. That's why Romeo's client MAY geotag microblog entries, using the &xep0080; protocol for storing geolocation information.

    Romeo's client MUST create a "geoloc" element, with the &xep0080; reference namespace: "http://jabber.org/protocol/geoloc".

    - - - - - - - - Romeo Montague - xmpp:romeo@montague.lit - - Is lost in the forest. Need help! - - tag:montague.lit,2008-05-08:posts-1zr23z8a-3g12-34fh-750b-120867gjc1sqh - 2008-05-08T18:43:01Z - 2008-05-08T18:43:01Z - - 48.171761 - -3.3667986 - France - FR - Brittany - - - - - - - ]]> - + + + + + + + Romeo Montague + xmpp:romeo@montague.lit + + Is lost in the forest. Need help! + tag:montague.lit,2008-05-08:posts-1zr23z8a-3g12-34fh-750b-120867gjc1sqh + 2008-05-08T18:43:01Z + 2008-05-08T18:43:01Z + + 48.171761 + -3.3667986 + France + FR + Brittany + + + + + + +]]>     -

    PubSub Social feeds are specified under profiles. Those profiles are constraints applied to nodes and defined by a specific PubSub type (see &xep0060;#registrar-formtypes-metadata)

    +

    Pubsub Social feeds are specified under profiles. Those profiles are constraints applied to nodes and defined by a specific Pubsub type (see &xep0060;#registrar-formtypes-metadata)

    All the profiles MUST base their default configuration on the Base profile @@ -310,50 +308,35 @@

    -

    This profile is specified by the PubSub type `urn:xmpp:social:0` and define a generic PubSub Social Feed that can be hosted on any PubSub service node or &xep0163; node.

    +

    This profile is specified by the Pubsub type "urn:xmpp:pubsub-social-feed:0" and define a generic Pubsub Social Feed that can be hosted on any Pubsub service node or &xep0163; node.

    Those restrictions MUST be used by all the other profiles defined bellow and in other XEPs based on Pubsub Social Feed.

      -
    1. The "pubsub#notify_retract" MUST be set to `true` to provide clients the ability to track if some items were retracted and reflect such changes in the UI correctly.
      2. -
    2. The "pubsub#max_items" MUST be set to the `max` value, as defined in the &xep0060;.
      3. -
    3. The "pubsub#persist_items" MUST be set to `true`.
      4. -
    4. The "pubsub#send_last_published_item" SHOULD be set to `never`.
      5. -
    5. The "pubsub#deliver_payloads" SHOULD be set to `false`. The social content can be quite large so it is advised to let the clients to manually query the content if it is not already cached.
      6. +
    6. The "pubsub#notify_retract" MUST be set to "true" to provide clients the ability to track if some items were retracted and reflect such changes in the UI correctly.
      7. +
    7. The "pubsub#max_items" MUST be set to the "max" value, as defined in the &xep0060;.
      8. +
    8. The "pubsub#persist_items" MUST be set to "true".
      9. +
    9. The "pubsub#send_last_published_item" SHOULD be set to "never".
      10. +
    10. The "pubsub#deliver_payloads" SHOULD be set to "false". The social content can be quite large so it is advised to let the clients to manually query the content if it is not already cached.
     -     + - -

    This profile is defined by the PubSub type `urn:xmpp:microblog:0` as defined in &xep0277; and MUST be created and configured under the PEP `urn:xmpp:microblog:0` node.

    + +

    This profile is defined by the Pubsub type "urn:xmpp:microblog:0" as defined in &xep0277; and MUST be created and configured under the PEP "urn:xmpp:microblog:0" node.

    +     - -

    - On top of the - Base profile Pubsub Node Configuration - the following node configuration is applied: -

    -
      -
    1. The "pubsub#access_model" SHOULD be set to `presence` by default to allow the other presence JIDs to receive the newly published elements without an explicit subscription (using the +notify feature of &xep0163;).
      2. -
    -     -     - - -

    This profile is defined by the PubSub type `urn:xmpp:gallery:0` and can be hosted on any PubSub service.

    -

    All the items published in a gallery node MUST only have at least one attached picture. This picture MUST be of type `enclosure` as specified in &rfc4287;.

    - - -]]> - -     + +

    This profile is defined by the Pubsub type "urn:xmpp:pubsub-social-gallery:0" and can be hosted on any Pubsub service.

    +

    All the items published in a gallery node MUST only have at least one attached picture. This picture MUST be of type "enclosure" as specified in &rfc4287;.

    + +]]> +     - -

    The client SHOULD check that the comment author information (provided in the "author" element) is valid, by checking that the "publisher" item attribute value matches the "uri" element value. If there is a difference or the check can not be performed because there was not a "publisher" attribute included, the comment can be displayed, but it is RECOMMENDED to specify there is a security problem.

    -     +

    There are no security features or concerns related to this proposal.

     @@ -372,4 +355,4 @@

    -     + \ No newline at end of file From 7a5405433536812476ae9a3a3d73ada45c443ebe Mon Sep 17 00:00:00 2001 From: Marvin W Date: Tue, 27 Dec 2022 22:12:17 +0100 Subject: [PATCH 42/51] XEP-0426: Character Counting 0.3.0 Added section about subsequences. --- xep-0426.xml | 123 +++++++++++++++++++++++++++++++++------------------ 1 file changed, 79 insertions(+), 44 deletions(-) diff --git a/xep-0426.xml b/xep-0426.xml index 2e2c0ecf..b9876acf 100644 --- a/xep-0426.xml +++ b/xep-0426.xml @@ -13,19 +13,21 @@ &LEGALNOTICE; 0426 - Deferred + Experimental Informational Standards + Council charcount - - Marvin - Wissfeld - xsf@larma.de - jabber@larma.de - + &larma; + + 0.3.0 + 2022-12-27 + lmw + Added section about subsequences. + 0.2.0 2020-01-02 @@ -165,47 +167,80 @@ across platforms and as such should be used with care.

    + +

    + The most obvious way of counting characters is to count them how humans + would. This sounds easy when only having western scripts in mind but becomes + more complicated in other scripts and most importantly is not well-defined + across Unicode versions. New unicode versions regularly added new + possibilities to build grapheme clusters, including from existing code + points. To be forward compatible, counting grapheme clusters, graphemes, + glyphs or similar is thus not an option. + This leaves basically the two options of using the number of code units of + the encoded string or the number of code points. +

    +

    + The main advantage of using the code units would be that those are native to + many programming languages, easing the task for developers. + However programming languages do not share a common encoding for their + string type (C/C++ use UTF-8, C#/Java use UTF-16, Python 3 hides the + internal encoding from the developer and only presents it in code points), + so there is no best pick here. + If one was to choose an encoding, the best choice would be UTF-8, the native + encoding of XMPP. However this makes counting bytes a more complex task for + programming languages that use a different encoding like UTF-16, as strings + would need to be transcoded first. +

    +

    + Counting code points has the advantage that offset counts cannot point + inside a code point. This could happen when using code units of any encoding + that may use more than one unit to represent a code point (such as UTF-8 and + UTF-16). + If an offset count points inside a code point, that would be an invalid + offset, raising more uncertainty of the correct behavior in such cases. Most + notably the opportunity of splitting (as it exists for grapheme cluster) is + not an option in that case, because splitting a code point would not create + any usable output. + Counting code points is widely supported in programming languages and can + easily be implemented for encoded strings when not. + The &w3xml; standard also defines a character as a unicode code point, thus + counting code points is equivalent to counting XML characters. +

    +     - +

    - The most obvious way of counting characters is to count them how humans - would. This sounds easy when only having western scripts in mind but becomes - more complicated in other scripts and most importantly is not well-defined - across Unicode versions. New unicode versions regularly added new - possibilities to build grapheme clusters, including from existing code - points. To be forward compatible, counting grapheme clusters, graphemes, - glyphs or similar is thus not an option. - This leaves basically the two options of using the number of code units of - the encoded string or the number of code points. -

    -

    - The main advantage of using the code units would be that those are native to - many programming languages, easing the task for developers. - However programming languages do not share a common encoding for their - string type (C/C++ use UTF-8, C#/Java use UTF-16, Python 3 hides the - internal encoding from the developer and only presents it in code points), - so there is no best pick here. - If one was to choose an encoding, the best choice would be UTF-8, the native - encoding of XMPP. However this makes counting bytes a more complex task for - programming languages that use a different encoding like UTF-16, as strings - would need to be transcoded first. -

    -

    - Counting code points has the advantage that offset counts cannot point - inside a code point. This could happen when using code units of any encoding - that may use more than one unit to represent a code point (such as UTF-8 and - UTF-16). - If an offset count points inside a code point, that would be an invalid - offset, raising more uncertainty of the correct behavior in such cases. Most - notably the opportunity of splitting (as it exists for grapheme cluster) is - not an option in that case, because splitting a code point would not create - any usable output. - Counting code points is widely supported in programming languages and can - easily be implemented for encoded strings when not. - The &w3xml; standard also defines a character as a unicode code point, thus - counting code points is equivalent to counting XML characters. + When referencing a subsequence of the characters of a message body, the + begin and end of the subsequence should be provided by two numbers, denoting + the number of characters (counted as described above) before the begin of the + subsequence or before the end of the subsequence, respectively. In other + words, the begin is the index of the first character in the subsequence and + the end is the index following the last character in the subsequence. That + means, if a subsequence covers the full body, its begin should be given as + 0 and its end should be given as the number of characters in the body.

    + + +

    + Subsequence indexing in various programming languages match the convention + described here. When using Python, the subsequence created by + body[begin:end] matches all requirements of this document. +

    +

    + Some programming languages define subsequences by offset and length. In + this case, begin matchs the offset while end-begin matches the length. +

    +     + +

    + The convention for subsequences was choosen because it has three main + advantages: It matches subsequence indexing in various programming + languages, end minus begin of a subsequence equal the length of the + subsequence and the end of the first of two adjacent subsequence matches the + begin of the second one. +

    +     From 08dc26aa6a1e90fcd155ddb6235b2097304269ee Mon Sep 17 00:00:00 2001 From: nicoco Date: Fri, 9 Dec 2022 05:23:46 +0100 Subject: [PATCH 43/51] XEP-0461: fix example char count, disco feature, allow missing 'to' attr --- xep-0461.xml | 42 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-) diff --git a/xep-0461.xml b/xep-0461.xml index 205fba35..539c18d2 100644 --- a/xep-0461.xml +++ b/xep-0461.xml @@ -15,6 +15,7 @@ Experimental Standards Track Standards + Council @@ -30,6 +31,12 @@ xsf@larma.de jabber@larma.de     + + 0.2.0 + 2022-12-09 + nc + Fix example character counting. Add disco feature. Relax the 'to' attribute constraints. + 0.1.0 2022-01-25 @@ -58,11 +65,38 @@

    + +

    + If a client implements message replies, it MUST specify the + 'urn:xmpp:reply:0' feature in its service discovery information features + as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;. +

    + + + ]]> + + + ... + + ... + + ]]> +     +

    To indicate that a message is a reply, a <reply> element in the urn:xmpp:reply:0 namespace is placed in the - message stanza. The <reply> element has a 'to' attribute containing the full jid of the author of the - referenced message and an 'id' attribute containing the id of the referenced message. + message stanza. The <reply> element SHOULD have a 'to' attribute containing the full jid of the author of the + referenced message and MUST have an 'id' attribute containing the id of the referenced message. + In a 1:1 chat context, a bare jid MAY be used instead of a full jid.

    @@ -78,6 +112,8 @@

    To provide a fallback for non-supporting clients, the sending client MAY include fallback text in the body and indicate it via Compatibility Fallback. + Note that the following example is formatted for readability and that the indentation, leading and trailing new lines + of the example body element should not be taken into account.

    @@ -88,7 +124,7 @@ - + ]]> From 32fd189284f245c80354dfd66f7fcbbd42933be1 Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Fri, 30 Dec 2022 14:50:43 +0100 Subject: [PATCH 44/51] XEP-0444: Add the XML Schema It was missing. --- xep-0444.xml | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/xep-0444.xml b/xep-0444.xml index 914cb86c..44da42a6 100644 --- a/xep-0444.xml +++ b/xep-0444.xml @@ -37,6 +37,12 @@ xsf@larma.de jabber@larma.de + + 0.1.1 + 2022-12-30 + egp + Add the XML Schema + 0.1.0 2020-10-13 @@ -234,4 +240,27 @@     + + + + + + + + + + + + + + + +]]> + + From 2b6db98c3c38bdc677bef4e8b215246b6f92e86e Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Wed, 4 Jan 2023 16:27:08 +0000 Subject: [PATCH 45/51] Update procedure to copy standards on Author pokes Council have requested this so they can be sure things haven't fallen through cracks. --- docs/TRIAGING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/TRIAGING.md b/docs/TRIAGING.md index 1b89ffee..964e3cf4 100644 --- a/docs/TRIAGING.md +++ b/docs/TRIAGING.md @@ -135,9 +135,9 @@ If the PR is not touching a XEP, this guide does not apply. 1. Make sure the standards@ discussion (if it exists) is linked in the PR. 2. Add the [Needs Author] label. - 3. Try to make the XEP Author aware of the change. If you do not know - a GitHub handle of the XEP Author, use the contact info available - for each author in either the XEP or in xep.ent. + 3. Try to make the XEP Author aware of the change. Do this with an email to + the author (use the contact info available for each author in either the + XEP or in xep.ent) and cc: standards@. 4. Stop. 5. Otherwise, mark the PR as [Ready to Merge], linking the XEP Author’s From b9f1686d382db71c2e8254a32972db1e743b93d9 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Thu, 5 Jan 2023 06:43:51 +0100 Subject: [PATCH 46/51] Add requirement for UUID v4 for id attributes --- xep-0353.xml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/xep-0353.xml b/xep-0353.xml index a9fac98c..59f9f886 100644 --- a/xep-0353.xml +++ b/xep-0353.xml @@ -27,6 +27,14 @@ &fippo; &stpeter; &tmolitor; + + 0.5.0 + 2022-01-05 + tm + + Recommend usage of UUID v4 for id attributes. + + 0.4.0 2021-11-27 @@ -98,7 +106,7 @@

    All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" and contain &xep0334; <store/> hints.

    -

    In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute that will be used for the session invitation of &xep0166; and MUST contain one <description/> element for each media type associated with the intended session.

    +

    In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of &xep0166; later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.

    In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving an <accept/> might comprise bad UX.

    In the rare case of missing <finish/> elements from both initiator and responder, sessions SHOULD be considered terminated after an appropriate timeframe (for example 24 hours) and indicated so in the UI.

    +

    All 'id' attributes MUST be globally unique to make sure they do not collide, and therefore it is RECOMMENDED to use UUIDv4.

    Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.

    From c8968e34803ebfdbe67ee39ca3d8f06711f57f23 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Mon, 16 Jan 2023 20:18:01 +0100 Subject: [PATCH 47/51] XEP-0474: Describe the attack models mitigated by SSDP --- xep-0474.xml | 56 +++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 49 insertions(+), 7 deletions(-) diff --git a/xep-0474.xml b/xep-0474.xml index 51969714..e8208662 100644 --- a/xep-0474.xml +++ b/xep-0474.xml @@ -23,6 +23,17 @@ SSDP &tmolitor; + + 0.2.0 + 2023-01-14 + tm + +
      +
    • Add description of attack model
      • +
    • Add section defining IETF interaction
      • +
    +     +     0.1.0 2022-12-13 @@ -42,6 +53,15 @@

    This specification aims to solve this issue by spcifying a downgrade protection for both SASL mechanisms and channel-binding types using an optional SCRAM attribute (see &rfc5802;). This specification can be used for SASL1 (&rfc6120;) and SASL2 (&xep0388;) profiles as well as any other SASL profile.

    Note: In the long term the author strives to publish this as an RFC rather than a XEP to also make this protection available to other protocols, after gaining implementation experience.

     + +

    This specification uses some abbreviations:

    +
      +
    • MITM: man-in-the-middle
      • +
    • CA: Certificate Authority
      • +
    • SASL1: the XMPP SASL profile specified in &rfc6120;
      • +
    • SASL2: the XMPP SASL profile specified in &xep0388;
      • +
    +

    This protocol was designed with the following requirements in mind:

      @@ -50,13 +70,32 @@
    • Support all currently defined and future SCRAM mechanisms (&rfc5802; and &rfc7677;)

    Note that this specification intentionally leaves out support for SASL PLAIN. If server and client support PLAIN, no protection against SASL method or channel-binding downgrades is possible and the security relies solely on the underlying TLS channel. As explained in § 13.8.3 of &rfc6120;, servers and clients SHOULD NOT support SASL PLAIN unless it is required by the authentication backend.

    -     - -

    This specification uses some abbreviations:

    -
      -
    • SASL1: the XMPP SASL profile specified in &rfc6120;
      • -
    • SASL2: the XMPP SASL profile specified in &xep0388;
      • -
    +

    A compromise might be to use pinning not for concrete SASL mechanisms, but instead pin that something better than SASL PLAIN was previously supported. Thus pinning will ensure that authentication won't fall back to SASL-PLAIN in the future, but also won't hinder protocol agility for the SCRAM family of SASL mechanisms etc..

    + +

    Scenario: Bob connects to Alice's XMPP server using a client of his choice supporting SCRAM and channel-binding, Eve wants to MITM this connection. Neither Alice's server nor Bob's client support SASL PLAIN, but only the SCRAM family of SASL mechanisms.

    +

    Prerequisites: Eve, the MITM attacker, managed to either steal the cert+key of Alice's XMPP server or to convince some CA to give out a cert+key for Alice's XMPP domain. Maybe Bob even installed a CA of his employer/school and now gets MITMed by his employer/school.

    +

    Given this scenario and prerequisites, Eve now can passively MITM the XMPP connection, but Bob and Alice are using channel-binding and this allows them to detect Eve and abort authentication. This forces Eve to be an active attacker, manipulating the data in the XMPP stream to get rid of the channel-binding. Eve does so by changing the list of server-advertised channel-bindings to only include some (fictional) channel-binding types she is sure the client does not support. Bob's client now has the following choices (see also the Security Considerations of &xep0440;):

    +
      +
    1. Authenticate without using channel-binding and signal to the server that the client does not support channel-binding ("n" GS2-flag)
      2. +
    2. Authenticate without using channel-binding and signal to the server that the client does support channel-binding ("y" GS2-flag)
      3. +
    3. Try to authenticate using some channel-binding type
      4. +
    4. Try to authenticate using the pinned channel-binding type
      5. +
    5. Fall back to use the lowest denominator: "tls-server-end-point"
      6. +
    +

    Case 1 is a successful downgrade from channel-binding to non-channel-binding authentication, Eve "wins".

    +

    Case 2 will always fail the authentication if the server supports channel-binding, Eve does not "win". But authentication will fail even if there is no MITM present but server and client simply happen to have no mutually supported channel-binding type.

    +

    Case 3 can result in a successful or failed authentication, depending on wether the server supports the type randomly selected by the client. Unfortunately a failed authentication due to selecting the wrong channel-binding type can not be distinguished from a failed authentication because of invalid credentials etc. Thus authentication using some channel-binding type will slow down authentication speed, because the client has to cycle through all channel-binding types it supports until it finds one the server supports (and eventually fall back to no channel-binding, if all channel-binding types have been tried). So, if server and client have mutually supported channel-binding types, Eve won't "win", but authentication will potentially need many roundtrips. If they don't have mutually supported channel-bindig types, Eve wouldn't have had to manipulate the channel-binding list in the first place.

    +

    Case 4 does not help on first authentication. This could be neglected, but since channel-binding types aren't that easily ordered by percieved strength and could legitimately change, this could effectively lead to a Denial of Service. For example Alice might want to offload TLS termination because of higher server load and now her server does not support "tls-exporter" anymore but only "tls-server-end-point". A client pinning "tls-exporter" would not be able to connect to Alice's server anymore after the TLS offloading is in place.

    +

    Case 5 won't help if Eve managed to steal the cert+key (or the server either somehow does not support the "tls-server-end-point" type).

    +

    This specification solves the problems outlined above by adding an optional SCRAM attribute containing the hash of the client-perceived list of channel-binding types that can be checked by the server and will be cryptographically signed by the authentication password used for SCRAM.

    +     + +

    Scenario: Bob connects to Alice's XMPP server using a client of his choice supporting SCRAM but no channel-binding, Eve wants to MITM this connection. Neither Alice's server nor Bob's client support SASL PLAIN, but only the SCRAM family of SASL mechanisms. Eve wants to downgrade the used SCRAM mechanism to something weak that she is able to break in X hours/days (For example some time in the future SCRAM-SHA-1 might be broken that way and the underlying password could be recovered investing X hours/days of computing time. But SCRAM-SHA-1 might still be supported by servers for backwards compatibility with older clients only supporting SCRAM-SHA-1 but not SCRAM-SHA-256 etc.).

    +

    Prerequisites: Eve, the MITM attacker, managed to either steal the cert+key of Alice's XMPP server or to convince some CA to give out a cert+key for Alice's XMPP domain. Maybe Bob even installed a CA of his employer/school and now gets MITMed by his employer/school.

    +

    Given this scenario and prerequisites, Eve now can passively MITM the XMPP connection, but if Eve wants to actively downgrade the SASL mechanism used by Bob, he has to actively change the server-advertised SASL mechanism list. In this scenario Eve actively removes all SCRAM mechanisms but SCRAM-SHA-1 from the server-advertised list to force Bob's client to use SCRAM-SHA-1. Neither Alice nor Bob would detect that.

    +

    Pinning of SASL mechanisms could be used for that, but in doing this, Alice would loose some flexibility. She might have briefly activated SCRAM-SHA-512 and deactivated it again. Now Bob's client can not authenticate using SCRAM-SHA-512 anymore and authentication will always fail, if pinning is used. Pinning won't help on first connection either. See above for a pinning + SSDP compromise when still supporting SASL PLAIN.

    +

    This specification solves this problem by adding an optional SCRAM attribute containing the hash of the client-perceived SASL mechanism list that can be checked by the server and will be cryptographically signed by the authentication password used for SCRAM.

    +

    Sections 5.1 and 7 of &rfc5802; allow for arbitrary optional attributes inside SCRAM messages. This specification uses those optional attribute to implement a downgrade protection.

    @@ -173,6 +212,9 @@

    Using SCRAM attributes makes them part of the HMAC signatures used in the SCRAM protocol flow efficiently protecting them against any MITM attacker not knowing the password used.

     + +

    This protocol shall be superseded by any IETF RFC providing some or all of the functionality provided by this specification. If such a specification exists implementations SHOULD NOT implement this XEP and SHOULD implement the superseding RFC.

    +

    This document requires no interaction with &IANA;.

     From 2a6956d3dabe9abc7c1e3f32d60622ea4d53145b Mon Sep 17 00:00:00 2001 From: moparisthebest Date: Tue, 20 Dec 2022 15:47:44 -0500 Subject: [PATCH 48/51] Add tools/triage.sh Fixes #1237 --- tools/triage.sh | 207 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 207 insertions(+) create mode 100755 tools/triage.sh diff --git a/tools/triage.sh b/tools/triage.sh new file mode 100755 index 00000000..ce5cb150 --- /dev/null +++ b/tools/triage.sh @@ -0,0 +1,207 @@ +#!/bin/bash + +# this should enforce as much of docs/TRIAGING.md as possible, run in top directory of xeps repo + +# usage: triage.sh $pr_title [$pr_commit] [$merge_base] +# the last two will be HEAD and `git merge-base $pr_commit master` by default if not sent in + +# for testing you can: +# git fetch origin +refs/pull/1254/merge +# git checkout FETCH_HEAD +# and only send in pr_title + +# test cases: +# multiple xeps changed: git checkout 58cec1b6fb30ccc3b44c9dff34b94f53e958c1ac; ./tools/triage.sh 'XEP-0072, XEP-0096, XEP-0214: fix xmlns in sipub examples' 58cec1b6fb30ccc3b44c9dff34b94f53e958c1ac e4d3f721c2cf9fc7ed42c3428d098b2b3be3c8ed +# protoxep: git fetch origin +refs/pull/1254/merge; git checkout FETCH_HEAD; ./tools/triage.sh "ProtoXEP: Stream Limits Advertisement" +# one xep changed: git fetch origin +refs/pull/1249/merge; git checkout FETCH_HEAD; ./tools/triage.sh 'XEP-0444: bla' + +set -euo pipefail + +pr_title="$1" +shift + +pr_commit="" +if [ $# -ge 1 ] +then + pr_commit="$1" + shift +else + pr_commit="HEAD" +fi + +merge_base="" +if [ $# -ge 1 ] +then + merge_base="$1" + shift +else + merge_base="$(git merge-base "$pr_commit" master)" +fi + +xpath() { + set -euo pipefail + xmllint --nonet --noent --xpath "$2" "$1" --nowarning --dtdvalid xep.dtd +} + +files_changed="$(git --no-pager diff --name-only "$pr_commit" "$merge_base")" + +set +e +protoxep="$(echo "$files_changed" | grep -E '^inbox/[^.]+.xml$')" +num_protoxeps=$(echo "$protoxep" | grep -v '^$' | wc -l) + +xeps_changed="$(echo "$files_changed" | grep -E '^xep-[0-9]{4}.xml$')" +xep_likes_changed="$(echo "$files_changed" | grep -E '^xep-[^.]+.xml$')" +num_xeps_changed=$(echo "$xeps_changed" | grep -v '^$' | wc -l) +set -e + +if [ $num_protoxeps -ge 1 ] +then + if [ $num_xeps_changed -ne 0 ] + then + echo "error: cannot change xeps and add ProtoXEP in 1 PR" + exit 1 + fi + # we are dealing with a protoxep here + echo "tag: protoxep" + if [ $num_protoxeps -ne 1 ] + then + echo "tag: split-pr" + echo "error: multiple ProtoXEPs cannot be created in 1 PR" + exit 1 + fi + expected_title="ProtoXEP: $(xpath "$protoxep" '/xep/header/title/text()')" + if [ "$pr_title" != "$expected_title" ] + then + echo "tag: bad-title" + echo "warning: expected title '$expected_title' got title '$pr_title'" + fi + echo "tag: ready-to-merge" + echo "manual: be sure type '$(xpath "$protoxep" '/xep/header/type/text()')' is appropriate for XEP content" + exit 0 +fi + +# we are *not* dealing with a protoxep here +if [ "$xeps_changed" != "$xep_likes_changed" ] +then + echo "error: xep files created/changed but named incorrectly: $(echo "$xep_likes_changed" | tr '\n' ' ')" + exit 0 +fi + +if [ $num_xeps_changed -eq 0 ] +then + # some tag for this? tooling changes? + echo "manual: no XEPs changed" + exit 0 +fi + +if [ $num_xeps_changed -gt 1 ] +then + echo "manual: multiple XEPs changed, split?" +fi + +all_approvers="" +# a super approver can approve this entire PR, because they are author on all XEPs touched +super_approvers="" +for xep in $xeps_changed +do + xep_num="XEP-$(echo "$xep" | grep -Eo '[0-9]{4}')" + if ! echo "$pr_title" | grep "$xep_num" &>/dev/null + then + echo "error: title did not include '$xep_num'" + exit 1 + fi + + status="$(xpath "$xep" '/xep/header/status/text()')" + approvers="" + if echo "$status" | grep -E '^(Experimental|Deferred)$' &>/dev/null + then + # Experimental or Deferred + if [ "$status" == 'Deferred' ] + then + echo "tag: needs-editor-action" + echo "manual: move $xep_num status to Experimental before or with merge" + fi + + approvers="$(xpath "$xep" '/xep/header/author/email/text()' | sort -u)" + else + # *not* Experimental or Deferred + approvers="$(xpath "$xep" '/xep/header/approver/text()' 2>/dev/null || echo 'Unknown')" + fi + + echo "info: $xep_num status '$status' needs approvers: '$(echo "$approvers" | tr '\n' ' ' | xargs)'" + + new_all_approvers="$(echo -e "$all_approvers\n$approvers" | sort -u)" + if [ "$all_approvers" != "$new_all_approvers" ] + then + # this isn't technically a problem if they all have an approver in common, ie super_approvers is non-empty, suppress warning? + if [ "$all_approvers" != "" ] + then + echo "manual: multiple XEPs modified with different approvers, split?" + super_approvers="$(comm -12 <(echo "$super_approvers") <(echo "$approvers") | sort -u)" + else + super_approvers="$new_all_approvers" + fi + all_approvers="$new_all_approvers" + fi + + # check revision block added and minor version bump + versions="$(xpath "$xep" '/xep/header/revision/version/text()')" + latest_num_versions="$(echo "$versions" | wc -l)" + latest_version="$(echo "$versions" | head -n1)" + # this git-cat-file usage assumes no entities etc are ever removed from xep.ent etc, this should be true + # but if it ever isn't, then we'll have to check out the entire repo as of $merge_base to do that + versions="$(git cat-file -p "$merge_base:./$xep" | xpath - '/xep/header/revision/version/text()')" + merge_base_num_versions="$(echo "$versions" | wc -l)" + merge_base_version="$(echo "$versions" | head -n1)" + if [ $latest_num_versions -gt $merge_base_num_versions ] + then + if ! echo "$latest_version" | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' &>/dev/null + then + echo "error: version is not semver format: '$latest_version'" + exit 1 + fi + if [ "$latest_version" == "$merge_base_version" ] + then + echo "tag: needs-version-block" + # todo: anyone have a fancy way to check semver is higher in $latest_version ? + # beware we have funky non-semver versions + # for xep in xep-*.xml; do xpath "$xep" '/xep/header/revision/version/text()'; done | sort -u > xep_versions.txt + fi + else + echo "tag: needs-version-block" + fi +done + +if [ "$super_approvers" != "" ] +then + pr_authors="$(git --no-pager log --format="%aE" "$merge_base".."$pr_commit" | sort -u)" + pr_authors_super_approvers="$(comm -12 <(echo "$super_approvers") <(echo "$pr_authors") | sort -u)" + if [ "$pr_authors_super_approvers" != "" ] + then + echo "info: entire PR can be approved by one of the commit authors: '$(echo "$pr_authors" | tr '\n' ' ' | xargs)'" + fi + echo "info: entire PR can be approved by: '$(echo "$super_approvers" | tr '\n' ' ' | xargs)'" +fi + +if echo "$all_approvers" | grep '^Council$' &>/dev/null +then + echo "tag: needs-council" +fi + +if echo "$all_approvers" | grep '^Board$' &>/dev/null +then + echo "tag: needs-board" +fi + +if echo "$all_approvers" | grep '^Unknown$' &>/dev/null +then + echo "tag: needs-unknown-approver" + echo "warning: approver is unknown, perhaps old XEP that needs fixed?" +fi + +if echo "$all_approvers" | grep '@' &>/dev/null +then + echo "tag: needs-author" +fi + +echo "manual: if only editorial changes, may not need approval" From a55bd3c497eeccfe74683fad659a520ec1aa4a05 Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 25 Jan 2023 15:42:51 +0100 Subject: [PATCH 49/51] Compliance Suite 2023: copied from XEP-0459 --- inbox/cs-2023.xml | 595 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 595 insertions(+) create mode 100644 inbox/cs-2023.xml diff --git a/inbox/cs-2023.xml b/inbox/cs-2023.xml new file mode 100644 index 00000000..0aaad376 --- /dev/null +++ b/inbox/cs-2023.xml @@ -0,0 +1,595 @@ + + +%ents; +Support can be enabled via an external component or an internal server module/plugin. If claiming compliance using such an addition, the necessary components/modules/plugins MUST be detailed."> +Support for the Entity Use Cases and Occupant Use Cases is REQUIRED; support for the remaining use cases is RECOMMENDED."> +Only one of the recommended providers must be implemented for compliance."> +Not required for command line or terminal based interfaces."> +While 'User Avatars' is more modern, 'vCard-Based Avatars' is more widely deployed. Although it is suggested that to maximise interoperability with existing software a client fully supports both it is sufficient to claim compliance with this suite if the support for 'vCard-Based Avatars' is read-only."> +While 'Personal Eventing Protocol' does not require all the features of 'Publish-Subscribe' to be available on the users' JIDs, and nor does this suite, it is desirable for this to be the case and it is expected that this will a requirement of future Compliance Suites."> + + +]> + + +
    + XMPP Compliance Suites 2023 + + This document defines XMPP application categories for different use cases + (Core, Web, IM, and Mobile), and specifies the required XEPs that client and + server software needs to implement for compliance with the use cases. + + &LEGALNOTICE; + XXXX + ProtoXEP + Standards Track + Standards + Council + + RFC 6120 + RFC 6121 + RFC 7395 + RFC 7590 + RFC 7622 + XEP-0030 + XEP-0045 + XEP-0048 + XEP-0049 + XEP-0084 + XEP-0085 + XEP-0114 + XEP-0115 + XEP-0124 + XEP-0163 + XEP-0191 + XEP-0198 + XEP-0206 + XEP-0223 + XEP-0249 + XEP-0280 + XEP-0313 + XEP-0352 + XEP-0368 + XEP-0402 + + + XEP-0459 + + + CS2023 + + Georg + Lukas + georg@op-co.de + georg@yax.im + + + 0.0.1 + 2023-01-25 + gl + +

    First draft based on XEP-0459.

    +     +     +
    + +

    + There is a growing number of XMPP Extension Protocols (XEPs) that provide + different building blocks for XMPP-based applications. XMPP software + developers are confronted with the challenge of finding the right + combination of XEPs for a given application profile. Users need a way to + compare applications without resorting to comparing for individual XEP + numbers. +

    +

    + This document defines XMPP application Categories based on + typical use cases (Core, Web, IM, Mobile) and Levels + (Core, Advanced) based on functionality in the respective category. For + each combination of those, the required XEPs are referenced. As the + protocol landscape changes over time, this document is updated roughly + once a year. +

    +

    + For developers, this document provides guidance on which specifications + they need to consider when implementing an application of a certain kind. + By completing a compliance test or performing a self-assessment, they can + advertise their implementation as compliant with a given Category and + Level. +

    +

    + For users, this provides an easy way to compare implementations based on + their respective advertised compliance levels and year. +

    +

    + Unless explicitly noted, support for the listed specifications is REQUIRED + for compliance purposes. + A feature is considered supported if all comma separated feature providers + listed in the "Providers" column are implemented (unless otherwise noted). +

    + +

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

    +

    None.

    +     + +

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

    +
      +
    • Renamed "Core Client" and "Core Server" to "Client" and "Server"
      • +
    • Web category: +
        +
      • Client: required Connection Mechanism Discovery.
        • +
      +
      • +
    • IM category: +
        +
      • Advanced Group Chat: replaced &xep0411; with &xep0402; conversion
        • +
      +
      • +
    +     + +

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

    +
      +
    • Introduced new category for A/V Calling.
      • +
    • IM Category: +
        +
      • Specifications of note: added &xep0393;, &xep0433;, &xep0424;, and &xep0425;
        • +
      +
      • +
    +     + +

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

    +
      +
    • IM Category: +
        +
      • Client: added &xep0245;
        • +
      • Client and Server: added &xep0363;
        • +
      • Advanced Client: added &xep0234;, &xep0261;
        • +
      • Advanced Client and Server: added &xep0411;
        • +
      • Specifications of note: added &xep0077; and &xep0157;, &xep0392;, &xep0066; and &xep0385;
        • +
      +
      • +
    • Mobile Category: +
        +
      • Specifications of note: added &xep0286;
        • +
      +
      • +
    • Web Category: +
        +
      • Advanced Web: added &xep0156;
        • +
      +
      • +
    +     +     + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureServerClientAdvanced ServerAdvanced ClientProviders
    Core features&yes;&yes;&yes;&yes;&rfc6120; &rfc7622; is not listed due to the unclear interoperability impact of using PRECIS and Stringprep in the same ecosystem.
    TLS&yes;&yes;&yes;&yes;&rfc7590;
    Direct TLS&no;&no;&yes;Server support of XEP-0368 means having the ability to accept direct TLS connections.&yes;&xep0368;
    Feature discovery&yes;&yes;&yes;&yes;&xep0030;
    Feature broadcasts&no;&yes;&yes;&yes;&xep0115;
    Server Extensibility&yes;N/A&yes;N/A&xep0114;
    Event publishing&no;&no;&yes;&pubsubjid;&yes;&xep0163;
    +     + +

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

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureServerClientAdvanced ServerAdvanced ClientProviders
    Web Connection Mechanisms&yes;&component;&yes;&onlyone;&yes;&component;&yes;&onlyone;&rfc7395;, &xep0206; (See also: &xep0124;)
    Connection Mechanism Discovery&no;&yes;N/A&yes;&xep0156;
    +     + +

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

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureServerClientAdvanced ServerAdvanced ClientProviders
    Core features&yes;&yes;&yes;&yes;&rfc6121;
    The /me CommandN/A&yes;N/A&yes;&xep0245;
    User AvatarsN/A&no;N/A&yes;&nocli;&xep0084;
    User Avatar Compatibility&no;&no;&yes;&yes;&nocli;&xep0398;, &xep0153;
    vcard-temp&yes;&yes;&yes;&yes;&xep0054;
    Outbound Message Synchronization&yes;&yes;&yes;&yes;&xep0280;
    User Blocking&no;&no;&yes;&yes;&xep0191;
    Group Chat&yes;&component;&yes;&usecases;&yes;&component;&yes;&usecases;&xep0045;Implementations should take note that future versions of these compliance suites may rely on &xep0369; instead., &xep0249;
    Advanced Group Chat&no;&no;&yes;&component;&yes;&xep0048;, &xep0313;Support for requesting history from a MUC archive as opposed to from the user's account., &xep0402;Usage of which should only happen when the 'urn:xmpp:bookmarks:1#compat' is exposed by the server, otherwise &xep0049; should be used instead., &xep0410;
    Persistent Storage of Private Data via PubSub&no;&no;&yes;&component;&yes;&xep0223;
    Private XML Storage&no;&no;&yes;&component;&yes;&xep0049; (only recommended for legacy bookmarks support)
    Stream Management&no;&no;&yes;&yes;&xep0198;
    Message AcknowledgementsN/A&no;N/A&yes;&xep0184;
    History Storage / Retrieval&no;&no;&yes;&yes;&xep0313;
    Chat StatesN/A&no;N/A&yes;&xep0085;
    Message CorrectionN/A&no;N/A&yes;&xep0308;
    File Upload&yes;&component;&yes;&yes;&component;&yes;&xep0363;
    Direct File TransferN/A&no;N/A&yes;&xep0234;, &xep0261;
    +

    + Further specifications of note, which are not required for compliance: +

    +
      +
    • For public IM networks: &xep0077; (should be supported, but not enabled in default server configurations) and &xep0157;
      • +
    • File uploads should be indicated using &xep0066;, optionally also using &xep0385;
      • +
    • &xep0392; for cross-client consistency of user names
      • +
    • &xep0393; for simple styling of plaintext messages that is loosely compatible with legacy IM networks
      • +
    • &xep0433; to improve the discovery of public rooms hosted on a domain
      • +
    • &xep0424; and &xep0425; for managing misbehavior in public rooms
      • +
    +     + +

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

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureServerClientAdvanced ServerAdvanced ClientProviders
    Stream Management&yes;&yes;&yes;&yes;&xep0198;
    Client State Indication&yes;&yes;&yes;&yes;&xep0352;
    Third Party Push Notifications&no;&no;&yes;&component;&yes;Only on platforms that disallow long-lasting background connections.&xep0357;
    +

    + Further specifications of note, which are not required for compliance: +

    +
      +
    • &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. +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FeatureServerClientAdvanced 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 + developers, but are not ready yet to be required for Compliance. + Developers are encouraged to implement those and + to share their experience and feedback.

    +
      +
    • Client connection optimizations: &xep0386; and &xep0409;, maybe also &xep0397;
      • +
    • Improved on-boarding of new users: +
        +
      • &xep0401; to create account invitations
        • +
      • &xep0379; for contact invitations
        • +
      • &xep0445; to register accounts based on an invitation
        • +
      +
      • +
    • &xep0333;
      • +
    • &xep0369;
      • +
    • End-to-End Encryption (E2EE): &xep0380; for tagging encrypted messages, &xep0420; to protect all payloads; and also one or multiple of the following for actual encryption: +
        +
      • &xep0384; and &xep0396;
        • +
      • &xep0374;
        • +
      +
      • +
    • &xep0402; to phase out &xep0048; and &xep0049;
      • +
    • &xep0225; to phase out &xep0114;
      • +
    • &xep0390; to phase out &xep0115;
      • +
    • &xep0455;
      • +
    +     + +

    + Some of the protocol specifications referenced herein have their own + dependencies; developers need to consult the relevant specifications for + further information. +

    +     + +

    + This document introduces no additional security considerations above and + beyond those defined in the documents on which it depends. +

    +     + +

    This document requires no interaction with &IANA;.

    +     + +

    This document requires no interaction with the ®ISTRAR;.

    +     + +

    + The author would like to thank Guus der Kinderen, Dele Olajide, Marc + Laporte, Dave Cridland, Daniel Gultsch, Florian Schmaus, Tobias Markmann, + and Jonas Schäfer for their suggestions. +

    +     +     From d8f1bbc86d43de7f4f2f749a189a07073a2d493b Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Wed, 25 Jan 2023 16:52:53 +0000 Subject: [PATCH 50/51] Require build to exist before writing into it --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 26efb1ba..051bc7bd 100644 --- a/Makefile +++ b/Makefile @@ -97,7 +97,7 @@ $(all_xep_xmls): $(OUTDIR)/%.xml: %.xml $(XMLDEPS) $(OUTDIR)/xep.xsl: xep.xsl $(OUTDIR) cp $< $@ -$(OUTDIR)/xeplist.xml: $(wildcard *.xml) $(wildcard inbox/*.xml) +$(OUTDIR)/xeplist.xml: $(wildcard *.xml) $(wildcard inbox/*.xml) $(OUTDIR) ./tools/extract-metadata.py > $@ $(EXAMPLESDIR)/%.xml: xep-%.xml $(XMLDEPS) examples.xsl | $(EXAMPLESDIR) From 8cd1320ddc7822ffecf04f524de3514ad6dbae86 Mon Sep 17 00:00:00 2001 From: Thilo Molitor Date: Thu, 5 Jan 2023 06:43:51 +0100 Subject: [PATCH 51/51] Port version 0.5 to :0 namespace and introduce --- xep-0353.xml | 164 +++++++++++++++++++++++++++++++++------------------ 1 file changed, 107 insertions(+), 57 deletions(-) diff --git a/xep-0353.xml b/xep-0353.xml index 59f9f886..282b8fc0 100644 --- a/xep-0353.xml +++ b/xep-0353.xml @@ -27,6 +27,14 @@ &fippo; &stpeter; &tmolitor; + + 0.6.0 + 2022-01-29 + tm + + Port version 0.5 to :0 namespace and improve tie-breaking section + + 0.5.0 2022-01-05 @@ -106,12 +114,12 @@

    All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" and contain &xep0334; <store/> hints.

    -

    In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of &xep0166; later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.

    +

    In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:0' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of &xep0166; later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.

    - + @@ -127,16 +135,29 @@ node='http://psi-im.org' ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/> +]]> +     + +

    Upon receiving the <propose/> message, the responder's various devices will start "ringing" and indicate so by sending a message to the bare JID of the initiator containing a <ringing/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.

    +

    This makes it possible to reflect the real state of the call in the UI and therefore comprises for better UX. It also somewhat compensates for the (intentionally) missing discovery of this protocol.

    + + + + ]]>     -

    It can happen that the initiator might want to disavow intent to send a session invitation (e.g., because the initiator has accepted another session). The initiator can do so by sending a message stanza containing a <retract/> element specifying the same session ID.

    -

    The <retract/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <cancel/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

    - It can happen that the initiator might want to disavow intent to send a session invitation (e.g., because the initiator has accepted another session). The initiator can do so by sending a message stanza containing a <retract/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.

    +

    The <retract/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <cancel/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

    +

    In conjunction with &xep0313; upon ending the catchup phase the responder SHOULD consider all sessions for which it received a <propose/> but no <retract/> or <finish/> message to be still active and allow the user to accept the intent to start a session.

    + - + Retracted @@ -145,21 +166,20 @@ ]]> -

    In conjunction with &xep0313; upon ending the catchup phase the responder SHOULD consider all sessions for which it received a <propose/> but no <retract/> or <finish/> message to be still active and allow the user to accept the intent to start a session.

     - -

    Upon receiving the intent message, the responder's various devices will "ring" and the responder will answer the call on a particular device. Here we assume that since this is an audio-only call, Juliet chooses to take the call on the device associated with her "phone" resource.

    -

    Her "phone" resource informs all of her resources and all of the initiator's resources about accepting the call by sending a message to the bare JID of the initiator containing an <accept/> element specifying the session ID of the original <propose/> message.

    - +

    The responder will answer the call on a particular device. Here we assume that since this is an audio-only call, Juliet chooses to take the call on the device associated with her "phone" resource.

    +

    Her "phone" resource informs all of her resources and all of the initiator's resources about accepting the call by sending a message to the bare JID of the initiator containing an <proceed/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.

    + - + ]]> -

    Juliet's server broadcasts this accept message to all of her resources (as described in &xep0280;), which stop ringing, and to all of Romeo's resources (as described in &rfc6121;). Romeo's resources that did not send the <propose/> can use this &MESSAGE; stanza to update their UI or choose to ignore this &MESSAGE; stanza altogether.

    -

    Next, the device from which Juliet accepted the call sends directed presence to Romeo for the reasons described above.

    +

    Juliet's server broadcasts this accept message to all of her resources (as described in &xep0280;), which stop ringing, and to all of Romeo's resources (as described in &rfc6121;). Romeo's resources that did not send the <propose/> can use this &MESSAGE; stanza to update their UI or choose to ignore this &MESSAGE; stanza altogether.

    +

    Next, the device from which Juliet accepted the call SHOULD also send directed presence to Romeo if the two entities do not already share presence information, for the reasons described above.

    @@ -171,14 +191,14 @@ ]]>     -

    Instead of accepting the call, the responder might want to decline the call and tell all of her devices to stop ringing (e.g., perhaps because Romeo is getting to be a bit of a nuisance). She does this by rejecting the call on one of her devices and having that device tell all of the other devices to stop ringing by sending a &MESSAGE; stanza containing a <reject/> element specifying the session ID of the original <propose/> message to the bare JID of Romeo.

    -

    The <reject/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. The <reason/> element SHOULD use a condition of <busy/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

    -

    In Tie-Breaking scenarios it MUST also contain a <tie-break/> element as defined in Tie Breaking.

    - Instead of accepting the call, the responder might want to decline the call and tell all of her devices to stop ringing (e.g., perhaps because Romeo is getting to be a bit of a nuisance). She does this by rejecting the call on one of her devices and having that device tell all of the other devices to stop ringing by sending a &MESSAGE; stanza containing a <reject/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message to the bare JID of Romeo.

    +

    The <reject/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. If given, the <reason/> element SHOULD use a condition of <busy/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

    +

    In Tie-Breaking scenarios it MUST also contain a <tie-break/> element as defined in Tie Breaking.

    + - + Busy @@ -198,7 +218,7 @@ + sid='ca3cf894-5325-482f-a412-a6e9f832298d'> @@ -240,14 +260,14 @@ ]]>     -

    This protocol in conjunction with &xep0280; and &xep0313; allows all devices of both involved parties to get synchronized about session start, rejection etc. To synchronize the ending of the session, both parties MUST send a message stanza containing a <finish/> element specifying the same session ID as in Accept to the bare jid of the other party.

    +

    This protocol in conjunction with &xep0280; and &xep0313; allows all devices of both involved parties to get synchronized about session start, rejection etc. To synchronize the ending of the session, both parties SHOULD send a message stanza containing a <finish/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the same session ID as in proceed to the bare jid of the other party.

    Letting both involved parties send the <finish/> element makes sure we have the correct state in MAM archives etc. even if one client suddenly looses connectivity/power. It even makes possible for a client to determine if the call is still deemed "running" by the other party if it manages to recover from connectivity loss — before the other party runs into a timeout and sends a <finish/> — to recover the session or formally terminate the call (by ending the Jingle session and sending a <finish/> message itself). See Tie Breaking for more infos on this and similar scenarios.

    -

    The <finish/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <success/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).

    +

    The <finish/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <success/> or <expired/>, but implementations MAY use other conditions like <connectivity-error/> if deemed more appropriate (see Security Considerations below for details and rationale).

    - + Success @@ -260,7 +280,7 @@ - + Success @@ -272,15 +292,17 @@     -

    It is possible that a <propose/> message can be sent at the same time by both parties or a new session started while one is already running. Implementations of this specification MUST implement the following solutions to solve this. (This is loosely based upon section 7.2.16 of &xep0166;.)

    +

    It is possible that a <propose/> message can be sent at the same time by both parties or a new session started while one is already running. Implementations of this specification SHOULD implement the following solutions to solve this. (This is loosely based upon section 7.2.16 of &xep0166;.)

    -

    In this case (e.g. no party answered the <propose/> message yet) the lower of the two session IDs MUST overrule the other action, where by "lower" is meant the session ID that is sorted first using "i;octet" collation as specified in Section 9.3 of &rfc4790; (in the unlikely event that the random session IDs are the same, the action sent by the lower of the JabberIDs MUST overrule the other action). The party that receives the <propose/> action with the lower of the two session IDs MUST respond with an <accept/> or <reject/> mesage like it would normally do for a <propose/> message, and the party that receives the <propose/> action with the higher of the two session IDs MUST return a <reject/> message to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/>.

    - In this case (e.g. no party answered the <propose/> message yet) the lower of the two session IDs MUST overrule the other action, where by "lower" is meant the session ID that is sorted first using "i;octet" collation as specified in Section 9.3 of &rfc4790; (in the unlikely event that the random session IDs are the same, the action sent by the lower of the JabberIDs MUST overrule the other action).

    +

    The party that receives the <propose/> action with the lower of the two session IDs MUST send a <retract/> message for the higher session ID to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/> and then eventually respond with an <proceed/> or <reject/> mesage like it would normally do for a received <propose/> message.

    +

    The party that receives the <propose/> action with the higher of the two session IDs MUST return a <reject/> message to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/>.

    + - + @@ -290,7 +312,7 @@ - + @@ -300,7 +322,21 @@ - + + + + Tie-Break + + + + + + + + + Tie-Break @@ -314,21 +350,21 @@ - + ]]>     -

    If (from the perspective of the responder of the new session) there is already a session to the bare-jid of the initiator active (e.g. call already accepted but no <finish/> element received by the responder so far), the old session MUST be deemed an orphan and terminated by the responder of the new session in favor of the new one. The responder MUST transparently accept the new session and finish the old one, because it can be assumed that this new session is a transparent continuation of the old one.

    -

    She does so by first accepting the new session (sending an <accept/> message like she would do normally) and then sending a <finish/> message including a child element whose to-attribute refers to the old Jingle session id and including a <reason/> condition of <expired/>.

    -

    That makes it possible for the initiator of the new session to transparently switch devices (e.g. migrate the call to a new device) or resume an alreay running session after a sudden connectivity/power loss.

    +

    If (from the perspective of the responder of the new session) there is already a session to the bare-jid of the initiator active (e.g. call already accepted but no <finish/> element received by the responder so far), the old session MUST be deemed an orphan and terminated by the responder of the new session in favor of the new one. The responder SHOULD transparently accept the new session and finish the old one, because it can be assumed that this new session is a transparent continuation of the old one.

    +

    The responder does so by sending a <finish/> message including a <reason/> condition of <expired/> and having a <migrated> child element whose to-attribute refers to the new Jingle session id, and accepting the new session by sending an <proceed/> message like they would do normally.

    +

    That makes it possible for the initiator of the new session to transparently switch devices (e.g. migrate the call to a new device) or resume a still running session after a sudden connectivity/power loss.

    - + @@ -338,7 +374,7 @@ - + @@ -348,42 +384,48 @@ - + - + + + - - - - - - - - + Session migrated - + + + + + + + - + + + + Success + + @@ -391,7 +433,12 @@ - + + + + Success + + @@ -401,13 +448,13 @@

    Participants MUST use &xep0280; and &xep0313; to make sure all devices of initiator and responder receive all messages exchanged by this protocol. Without &xep0280; implementations would need to send copies of outgoing messages to their own bare jid, to inform their own devices about an event (like it was done with the <accept/> message in the old urn:xmpp:jingle:jingle-message:0 specification).

    -

    In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving an <accept/> might comprise bad UX.

    +

    In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving a <propose/> might comprise bad UX.

    In the rare case of missing <finish/> elements from both initiator and responder, sessions SHOULD be considered terminated after an appropriate timeframe (for example 24 hours) and indicated so in the UI.

    All 'id' attributes MUST be globally unique to make sure they do not collide, and therefore it is RECOMMENDED to use UUIDv4.

     -

    Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.

    -

    Because sending of reasons other than the default ones (e.g. <cancel/> for <retract/>, <busy/> or <expired/> for <reject/> and <success/> or <expired/> for <finish/>) may leak privacy related information the user does not want to leak, sending of those non-default reasons should be carefully considered by client developers.

    +

    Because exchanging messages with other entities is effectively a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.

    +

    Because sending of reasons other than the default ones (e.g. <cancel/> for <retract/>, <busy/> or <expired/> for <reject/> and <success/> or <expired/> (or <connectivity-error/>) for <finish/>) may leak privacy related information the user does not want to leak, sending of those non-default reasons should be carefully considered by client developers.

    Thanks to Lance Stout, Holger Weiß and Daniel Gultsch for their feedback.

    @@ -419,7 +466,7 @@

    This specification defines the following XML namespace:

      -
    • urn:xmpp:jingle:jingle-message:1
      • +
    • urn:xmpp:jingle:jingle-message:0

    The ®ISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

     @@ -427,6 +474,9 @@ &NSVER;     + +

    Versions 0.4 and 0.5 of this specification define more or less the same protocol in the namespace urn:xmpp:jingle:jingle-message:1 (but in many places using MUST rather than SHOULD and removing <proceed/> in favor of <accept/>). To provide for greater backwards compatibility, version 0.6 of this document switched back to the old urn:xmpp:jingle:jingle-message:0 namespace. Future updates requiring a namespace bump should therefore directly bump the namespace version to :2 ans skip :1.

    +     @@ -434,8 +484,8 @@