From 105dff773ab7bb894f6669dcf10c0d938228f70b Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Mon, 11 Dec 2023 19:05:21 +0100 Subject: [PATCH 001/145] Disable the biblatex url links to the versioned XEP for now --- xep.xsl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xep.xsl b/xep.xsl index e539e1909..fafb479ac 100644 --- a/xep.xsl +++ b/xep.xsl @@ -531,7 +531,9 @@ content: "XEP-"; - + + https://xmpp.org/extensions/attic/xep- - From 70f41c0cad6b97a67e46fc0c5e432a75b3701aba Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Mon, 11 Dec 2023 19:06:41 +0100 Subject: [PATCH 002/145] Makefile: remove .SILENT, make the targets loud The Makefile was set globally to silent, which caused the failing commands to be *not* displayed. For example flo@neo-pc xeps-xsf $ make html make: *** [Makefile:112: build/xep-0001.html] Error 1 Removing this provides usefull information about which command failed: flo@neo-pc xeps-xsf $ make html xmllint --nonet --noout --noent --loaddtd --valid "xep-0001.xml" ! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" xep-0001.xml 2>/dev/null && true make: *** [Makefile:110: build/xep-0001.html] Error 1 --- Makefile | 2 -- 1 file changed, 2 deletions(-) diff --git a/Makefile b/Makefile index 051bc7bd9..e2c78640b 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,3 @@ -.SILENT: - OUTDIR?=build REFSDIR?=$(OUTDIR)/refs EXAMPLESDIR?=$(OUTDIR)/examples From e97b02573ade6838a726724e007f93f6bdcd86e6 Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Mon, 11 Dec 2023 19:25:19 +0100 Subject: [PATCH 003/145] Extract the copyrigh years of a XEP from its revision In https://github.com/xsf/xeps/pull/1300#issuecomment-1850475278 it was said that we do not longer simply bump the copyright year range. But keeping the copyright year at 2021 of all XEPs, including newer ones from 2023, is also far from ideal. So let's simply extract the copyright year from the revision information we already have. --- xep.xsl | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xep.xsl b/xep.xsl index e539e1909..d130e5990 100644 --- a/xep.xsl +++ b/xep.xsl @@ -257,7 +257,10 @@ content: "XEP-";
Copyright
-
© 1999 – 2021 XMPP Standards Foundation. SEE LEGAL NOTICES.
+ +
© – XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

From 67e89a7190b44026c0ec9a6e8718cb0c0973c691 Mon Sep 17 00:00:00 2001 From: Dele Olajide Date: Fri, 15 Dec 2023 13:22:58 +0000 Subject: [PATCH 004/145] Use XEP-0482 to send meeting URL to invitees --- xep-0483.xml | 137 +++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 112 insertions(+), 25 deletions(-) diff --git a/xep-0483.xml b/xep-0483.xml index 7a2a2c2f4..922506e0b 100644 --- a/xep-0483.xml +++ b/xep-0483.xml @@ -29,7 +29,17 @@ der Kinderen guus.der.kinderen@gmail.com guus.der.kinderen@igniterealtime.org - + + + 0.2.0 + 2023-12-12 + do + +

    +
  • Use XEP-0482 to send the meeting link to another party
    • +
+ + 0.1.0 2023-12-11 @@ -38,6 +48,7 @@
  • Promoted to Experimental.
+ 0.0.3 @@ -84,9 +95,23 @@ -

XMPP protocol extensions already defines a method for initiating peer-to-peer media sessions such as &xep0166; however due to its very nature of being peer-to-peer it does not work very well in scenarios with online meetings. It also does not work alongside offline storage, MUC history and &xep0313;.

-

Using a web browser to manually request a URL from an HTTP server and sharing the link has been a workaround for this for a long time now. While users have a variety of services to choose from, the downside of this manual approach is that an XMPP client can not automate this process on behalf of the user since these services don’t share a common API.

-

This XEP defines an approach to request initiation of an online meeting via an HTTP server and receive a URL can be used to join and invite others to the meeting.

+

XMPP protocol extensions already defines a method for initiating peer-to-peer media sessions such as &xep0166; however due to its very nature of being peer-to-peer it presents a few challenges in scenarios with online meetings that depend on a central Selective Forwarding Unit (SFU) or a Multipoint Control Unit (MCU) to host the meeting..

+

Using a web browser to manually request a meeting URL from an HTTP server and sharing the link has been a workaround for this for a long time now. While users have a variety of services to choose from, the downside of this manual approach is that an XMPP client can not automate this process on behalf of the user since these services don’t share a common API.

+

This XEP defines an approach to request initiation of an online meeting via an HTTP server and receive a URL can be used to join and invite others to the meeting. It has two main features:

+
    +
  1. An IQ-based protocol to request a meeting link from a server.
    2. +
  2. An element that can be added to a message stanza for sending the received meeting link to another party
    3. +
+

+ The second feature is achieved by using &xep0482;, which describes + call invites using Jingle and external URIs. The XEP mentions how a web URLs can be used as external URI to join a call. For completeness, an example is repeated here to explicitly show how meeting invitations should be sent to invitees. +

+

+ &xep0482; has other call mangement features, like announcing call join and + leave on the XMPP side. These are relevant for online meetings when the website behind the URL is opened + in a frame or similar inside the XMPP client. The meeting host xmpp client can track meeting participants and know when users leave the meeting without having to depend on APIs provided by the meeting service provider which may present cross-domain challenges. + For completeness, examples are also repeated in this XEP to explicity show their application for online meeting invitations. +

    @@ -178,23 +203,26 @@ Meeting room for Open Standards discussion + ]]> -

    The XMPP server responds with one or two child elements: a 'initiate' element that contains a URL to be used to create and configure the meeting, and an 'invite' element that contains a URL suitable to invite others into the meeting.

    +

    The XMPP server responds with one or two child elements: a 'initiate' element that contains a URL to be used to create and configure the meeting, and an 'invite' element as specified by &xep0482; to invite others into the meeting.

    In the URLs that it returns, the server MAY specify a web-based protocol handler if available and registered by the user. Otherwise, standard HTTPS protocol will be specified. In any case, the fully resolved URL provided by the host MUST provide Transport Layer Security (&rfc5246;). The HTTPS URL MUST adhere to &rfc3986;. Non ASCII characters MUST be percent-encoded.

    - - web+jitsi:https://meet.jit.si/OpenStandardsMuchGreatness + web+jitsi:OpenStandardsMuchGreatness Meeting room for Open Standards discussion - - web+jitsi:https://meet.jit.si/OpenStandardsMuchGreatness - Meeting room for Open Standards discussion - + + + + ]]> https://meet.jit.si/OpenStandardsMuchGreatness Meeting room for Open Standards discussion - - https://meet.jit.si/OpenStandardsMuchGreatness - Meeting room for Open Standards discussion - + + + + ]]>

    The XMPP server MAY be tightly integrated with the Meeting Provider and facilitate registration, configuration and association of a web-based protocol handler, but the protocol to implement such integration is out of scope of this document.

    @@ -272,25 +302,82 @@ ]]> -

    After the requesting entity has successfully initiated a meeting, it MAY invite other entities to join the meeting. It does so by sending invitees a message stanza containing an 'invite' child element, qualified by the online-meetings namespace, as was sent by the server in response to the initiation request.

    -

    To allow users of clients that do not support this XEP to receive the invitation, a &xep0066; element and/or a 'body' element containing the meeting details MAY be included.

    - After the requesting entity has successfully initiated a meeting, it MAY invite other entities to join the meeting using the 'invite' element it received to propose the meeting

    +

    To allow users of clients that do not support &xep0482; to receive the invitation, a &xep0066; element and/or a 'body' element containing the meeting details MAY be included.

    +

    There is no further XMPP communication required between the server and the requesting entity for participants to join the meeting. The actual online meeting engagement with the provided URL is out of scope of this document.

    + + +

    + Invitees are sent a message containing an <invite> element in the urn:xmpp:call-invites:0 + namespace. For online meetings, the audio video attributes should default to "true". +

    + The <invite> element contains sub-elements <external> and <meeting> to provide the meeting URL and the identity of the meeting service provider. +

    - - https://meet.jit.si/OpenStandardsMuchGreatness - Meeting room for Open Standards discussion - + + + + https://meet.jit.si/OpenStandardsMuchGreatness Meeting room for Open Standards discussion You are invited to join 'Meeting room for Open Standards discussion' at https://meet.jit.si/OpenStandardsMuchGreatness ]]> -

    There is no further XMPP communication required between the server and the client for the client to join the meeting. The actual online meeting engagement with the provided URL is out of scope of this document.

    -     + + +

    + A meeting invitation can be retracted by sending a message containing a <retract> element with an 'id' attribute + containing the id of the invite message qualified by the urn:xmpp:call-invites:0 namespace. +

    + + +]]> +     + +

    + A meeting invitation can be accepted by sending a message containing an <accept> element with an 'id' attribute + containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace. + The <external> and <meeting> elements from the invitation are placed in the <accept> element as specified in &xep0482;. +

    + + + + + +]]> +

    + After the <accept> was sent, the accepting client handles the URI. The exact behaviour of opening the URI is implementation specific and can be determined from the type attribute of the <meeting> element. +

    +     + +

    + A meeting invitation can be rejected by sending a message containing a <reject> element with an 'id' attribute + containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace. +

    + + +]]> +     + +

    + When a meeting participant leaves a meeting, it sends a message containing a <left> element with an 'id' attribute + containing the id of the invite message and qualified by the urn:xmpp:call-invites:0 namespace. +

    + + +]]> +     +

    The server SHOULD choose an appropriate timeout for the validity of the URL. Since there is no reason for a client to wait between requesting the URL and joining the meeting via the URL before dispatching invitations, relatively low timeout values of around 300s are RECOMMENDED.

     From 57b90ecb887ce33fffccd41427f4ea62eafef017 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Tue, 19 Dec 2023 21:46:11 +0100 Subject: [PATCH 005/145] ProtoXEP: PubSub Server Information This defines a data format and a pub-sub based way of distributing data that describes an XMPP domain and its connections to federated domains. --- inbox/pubsub-server-info.xml | 206 +++++++++++++++++++++++++++++++++++ 1 file changed, 206 insertions(+) create mode 100644 inbox/pubsub-server-info.xml diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml new file mode 100644 index 000000000..4d34c2e65 --- /dev/null +++ b/inbox/pubsub-server-info.xml @@ -0,0 +1,206 @@ + + + %ents; + ]> + + +
    + PubSub Server Information + This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + + + serverinfo + + Guus + der Kinderen + guus.der.kinderen@gmail.com + guus.der.kinderen@igniterealtime.org + + + 1.0.0 + 2023-12-19 + gdk + +
      +
    • Initial version.
      • +
    +     +     +
    + +

    To facilitate discovery of information of individual domains in an XMPP-based network, this specification defines a data format to define basic information for individual XMPP domains. By leveraging &xep0060; this information can efficiently be shared with applications that compose an overview of the larger XMPP network.

    +     + +
      +
    • Describe links between nodes in an XMPP-based network, by enumerating connections used for federation between XMPP domains.
      • +
    • An extensible data format, allowing additional data (such as that defined in &xep0092;) to be retrievable without requiring additional round-trips.
      • +
    +     + +

    Support is advertised by publishing a first-level leaf node using the name 'serverinfo' on a pub-sub service. An entity trying to discover support will, for a given domain name, use &xep0030; to identify a Publish-Subscribe service for the domain, and subsequently use service discovery to discover the node with name 'serverinfo' as defined in section 5.3 of &xep0060;.

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

    The data format uses an element named 'serverinfo' in the namespace 'urn:xmpp:serverinfo:0'. In its minimal form, it only defines the XMPP domain name in a child-element named 'domain'.

    + + shakespeare.lit +]]> +

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each federated domain is added as a 'connection' child-element to the 'federation' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'both'). The domain name of the remote XMPP domain is added in a 'domain' child element.

    + + shakespeare.lit + + + denmark.lit + + + montague.net + + + capulet.com + + +]]> +

    Additional data MAY be included in child-elements of the 'server-info' element. Such data MUST be namespaced appropriately. The example below uses the 'query' element defined in &xep0092; to include information about the software application associated with the local domain.

    + + shakespeare.lit + + + denmark.lit + + + + Openfire + 4.8.0 + Windows 11 + +]]> +     + +

    The data is to be published using a pub-sub node named 'serverinfo' that MUST be a first-level leaf node of a pub-sub service for the domain. It is RECOMMENDED that the leaf-node is configured to have an open access model and contain a maximum of 1 item.

    + + + + + + shakespeare.lit + + + denmark.lit + + + montague.net + + + capulet.com + + + + + + + ]]> +     + +

    As certain information can be expected to be updated continuously and frequently, the server MAY choose to reduce the frequency of updates of the 'serverinfo' pub-sub node.

    +     + +

    This document requires no interaction with the &IANA;

    +     + + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:serverinfo:0
      • +
    +

    Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

    +     +     + + + + + + + + The protocol documented by this schema is defined in + XEP-0XXX: http://www.xmpp.org/extensions/xep-0XXX.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> + + +

    Inspiration was taken from the (now defunct) 'server info' crawler by Thomas Leister. Many thanks to Dave Cridland, as well as 'zoidberg' from the Ignite Realtime community for helping to test the initial implementation of a graphing implementation based on this XEP.

    +     + +     From da26a6568573d87ca3a084413e240467b593513b Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 20 Dec 2023 11:38:22 +0100 Subject: [PATCH 006/145] PubSub Server Info: change connection type 'both' to 'bidi' Remove ambiguity with regards to having more than one connection to a remote domain. With this update, each actual (eg TCP) connection is represented by a distinct `connection` element. --- inbox/pubsub-server-info.xml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index 4d34c2e65..84098bf2b 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -73,7 +73,7 @@ shakespeare.lit ]]> -

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each federated domain is added as a 'connection' child-element to the 'federation' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'both'). The domain name of the remote XMPP domain is added in a 'domain' child element.

    +

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each actual (eg TCP) connection to a federated domain is added as a 'connection' child-element to the 'federation' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'bidi'). The domain name of the remote XMPP domain is added in a 'domain' child element.

    shakespeare.lit @@ -81,7 +81,7 @@ denmark.lit - + montague.net @@ -121,7 +121,7 @@ denmark.lit - + montague.net @@ -170,7 +170,7 @@ - + From 7f522c35faa409986e08a89f5a552eec176b719c Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 20 Dec 2023 12:54:11 +0100 Subject: [PATCH 007/145] PubSub Server Info: refactored data format Following discussion with Flow, MattJ and Jonas`, the data format was modified to: - group connections under a remote domain - use attributes instead of elements where appropriate --- inbox/pubsub-server-info.xml | 125 +++++++++++++++++++---------------- 1 file changed, 69 insertions(+), 56 deletions(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index 84098bf2b..8dc81f786 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -68,36 +68,36 @@ ]]> -

    The data format uses an element named 'serverinfo' in the namespace 'urn:xmpp:serverinfo:0'. In its minimal form, it only defines the XMPP domain name in a child-element named 'domain'.

    +

    The data format uses an element named 'serverinfo' in the namespace 'urn:xmpp:serverinfo:0'. In its minimal form, it defines each XMPP domain name served by the local server in an attribute named 'name'.

    - shakespeare.lit + ]]> -

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each actual (eg TCP) connection to a federated domain is added as a 'connection' child-element to the 'federation' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'bidi'). The domain name of the remote XMPP domain is added in a 'domain' child element.

    +

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each of them are represented by an element named 'remote-domain'. The domain name of the peer in an attribute named 'name'. Optionally, each actual (e.g. TCP) connection from the local server to the peer is added as a 'connection' child-element to the 'remote-domain' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'bidi').

    - shakespeare.lit - - - denmark.lit - - - montague.net - - - capulet.com - - + + + + + + + + + + + ]]> -

    Additional data MAY be included in child-elements of the 'server-info' element. Such data MUST be namespaced appropriately. The example below uses the 'query' element defined in &xep0092; to include information about the software application associated with the local domain.

    +

    Additional data MAY be included as child-elements of the 'server-info' element or any of the 'domain' elements. Such data MUST be namespaced appropriately. The example below uses the 'query' element defined in &xep0092; to include information about the software application associated with the local server.

    - shakespeare.lit - - - denmark.lit - - + + + + + + + Openfire 4.8.0 @@ -116,18 +116,17 @@ - shakespeare.lit - - - denmark.lit - - - montague.net - - - capulet.com - - + + + + + + + + + + + @@ -165,6 +164,8 @@ XEP-0XXX: http://www.xmpp.org/extensions/xep-0XXX.html + + @@ -174,33 +175,45 @@ - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]>     -

    Inspiration was taken from the (now defunct) 'server info' crawler by Thomas Leister. Many thanks to Dave Cridland, as well as 'zoidberg' from the Ignite Realtime community for helping to test the initial implementation of a graphing implementation based on this XEP.

    +

    Inspiration was taken from the (now defunct) 'server info' crawler by Thomas Leister. Many thanks to Dave Cridland, as well as 'zoidberg' and 'chewie' from the Ignite Realtime community for helping to test the initial implementation of a graphing implementation based on this XEP and to Florian Schmaus, Matthew Wild and Jonas Schäfer for their feedback on the earliest drafts of this document.

     From d1606cda1ec27fa7aaecb1ee357985c505583291 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 20 Dec 2023 13:26:44 +0100 Subject: [PATCH 008/145] PubSub Server Info: fixed typo in examples --- inbox/pubsub-server-info.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index 8dc81f786..20dc14b29 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -78,7 +78,7 @@ - + @@ -118,7 +118,7 @@ - + From 7e82fc1fd08914dfd59b9031d74a0b9a728102b3 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 20 Dec 2023 16:10:22 +0100 Subject: [PATCH 009/145] PubSub Server Info: Add privacy consideration The XEP now mandates to include domain names of remote domains only after those remote domains advertise support for this XEP. This is intended as an opt-in mechanism. --- inbox/pubsub-server-info.xml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index 20dc14b29..25557da9b 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -73,7 +73,8 @@ ]]> -

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each of them are represented by an element named 'remote-domain'. The domain name of the peer in an attribute named 'name'. Optionally, each actual (e.g. TCP) connection from the local server to the peer is added as a 'connection' child-element to the 'remote-domain' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'bidi').

    +

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each of them are represented by an element named 'remote-domain'. The domain name of the peer in an optional attribute named 'name'. Optionally, each actual (e.g. TCP) connection from the local server to the peer is added as a 'connection' child-element to the 'remote-domain' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'bidi').

    +

    The name of a remote domain MUST only be included if the remote server advertises supporting for this XEP. This acts as an opt-in mechanism, to address the privacy concern defined in the Privacy Considerations section of this document.

    @@ -88,7 +89,7 @@     ]]> -

    Additional data MAY be included as child-elements of the 'server-info' element or any of the 'domain' elements. Such data MUST be namespaced appropriately. The example below uses the 'query' element defined in &xep0092; to include information about the software application associated with the local server.

    +

    Additional data MAY be included as child-elements of the 'serverinfo' element or any of the 'domain' elements. Such data MUST be namespaced appropriately. The example below uses the 'query' element defined in &xep0092; to include information about the software application associated with the local server.

    @@ -136,6 +137,9 @@

    As certain information can be expected to be updated continuously and frequently, the server MAY choose to reduce the frequency of updates of the 'serverinfo' pub-sub node.

     + +

    When multiple domains publish their connections to named remote domains, an information leak occurs: by collecting these public statistics, behavioral data of those remote domains can be deduced. To prevent undesired privacy-sensitive information leaks, a domain MUST NOT publish the name of a remote domain, unless that domain advertises support for this XEP.

    +

    This document requires no interaction with the &IANA;

     From e7fcb86c917140e24087529b32e25fad962c3a52 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 20 Dec 2023 18:53:48 +0100 Subject: [PATCH 010/145] PubSub Server Info: rework Discovering Support Instead of basing Discovery of Support on the presence of a well-known pub-sub service node, an explicit Service Discovery feature is used. This prevents a scenario in which a non-administrative user flags 'opt-in' by creating the pub-sub node. --- inbox/pubsub-server-info.xml | 68 +++++++++++++++++++++++++++++++----- 1 file changed, 60 insertions(+), 8 deletions(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index 25557da9b..c3500a8dd 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -45,8 +45,40 @@
-

Support is advertised by publishing a first-level leaf node using the name 'serverinfo' on a pub-sub service. An entity trying to discover support will, for a given domain name, use &xep0030; to identify a Publish-Subscribe service for the domain, and subsequently use service discovery to discover the node with name 'serverinfo' as defined in section 5.3 of &xep0060;.

- Domains supporting the publication of Server Information data, as described in this document, MUST advertise the fact by announcing a &xep0030; feature of 'urn:xmpp:serverinfo:0'. This signifies that an administrative entity approved the publication of data, which is important for the opt-in mechanism described in Privacy Considerations section of this document.

+

The pub-sub service address and node in which Server Information data is advertised SHOULD be specified using a &xep0128;. These pub-sub coordinates MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in XEP-0128) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

+

When the 'urn:xmpp:serverinfo:0' feature but no corresponding Service Discovery Extension is advertised, the node that is used will be a first-level leaf node using the name 'serverinfo' on the first pub-sub service advertised through service discovery.

+ + +]]> + + + ... + + ... + + + http://jabber.org/network/serverinfo + + + pubsub.shakespeare.lit + + + serverinfo + + + +]]> +

The node MUST reference a first-level leaf node on a pub-sub service.

+ As certain information can be expected to be updated continuously and frequently, the server MAY choose to reduce the frequency of updates of the 'serverinfo' pub-sub node.

 -

When multiple domains publish their connections to named remote domains, an information leak occurs: by collecting these public statistics, behavioral data of those remote domains can be deduced. To prevent undesired privacy-sensitive information leaks, a domain MUST NOT publish the name of a remote domain, unless that domain advertises support for this XEP.

- - -

This document requires no interaction with the &IANA;

+

When multiple domains publish their connections to named remote domains, an information leak occurs: by collecting these public statistics, behavioral data of those remote domains can be deduced. To prevent undesired privacy-sensitive information leaks, a domain MUST NOT publish the name of a remote domain, unless that domain advertises support for this XEP, as defined in the Discovering Support section of this document.

+

This way, the service discovery mechanism doubles as an opt-in mechanism. Domains that advertise support for this XEP allow other domains to reference them by domain-name in the data that they publish. The mere presence of an applicable pub-sub node MUST NOT be used for Service Discovery purposes, as under common service configuration, non-administrative users are allowed to create such nodes.

 +

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall include the following information in its registries.

This specification defines the following XML namespaces:

  • urn:xmpp:serverinfo:0
-

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

+

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

 + +

&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.

+ + http://jabber.org/network/serverinfo + XEP-0XXX + + Forms advertising the coordinates of a pub-sub service and node for publication of Server Information data. + + + + +]]> +

Note that the FORM_TYPE used by &xep0157; is purposefully re-used by this XEP, to circumvent the restriction of having at most one XMPP Standards Foundation defined FORM_TYPE for a service discovery identity, as defined in &xep0128;. When a service supports both features, the data in both forms SHOULD be merged into one form.

+ -

Inspiration was taken from the (now defunct) 'server info' crawler by Thomas Leister. Many thanks to Dave Cridland, as well as 'zoidberg' and 'chewie' from the Ignite Realtime community for helping to test the initial implementation of a graphing implementation based on this XEP and to Florian Schmaus, Matthew Wild and Jonas Schäfer for their feedback on the earliest drafts of this document.

+

Inspiration was taken from the (now defunct) 'server info' crawler by Thomas Leister. Many thanks to Dave Cridland, as well as 'zoidberg' and 'chewie' from the Ignite Realtime community for helping to test the initial implementation of a graphing implementation based on this XEP and to Florian Schmaus, Matthew Wild, Jonas Schäfer and Kevin Smith for their feedback on the earliest drafts of this document.

 From f1a628c6b0e0d47d14ca9a84037f7a0fa621389f Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 20 Dec 2023 19:51:55 +0100 Subject: [PATCH 011/145] PubSub Server Info: fixed typo --- inbox/pubsub-server-info.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index c3500a8dd..f90eedd7c 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -106,7 +106,7 @@ ]]>

The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each of them are represented by an element named 'remote-domain'. The domain name of the peer in an optional attribute named 'name'. Optionally, each actual (e.g. TCP) connection from the local server to the peer is added as a 'connection' child-element to the 'remote-domain' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'bidi').

-

The name of a remote domain MUST only be included if the remote server advertises supporting for this XEP. This acts as an opt-in mechanism, to address the privacy concern defined in the Privacy Considerations section of this document.

+

The name of a remote domain MUST only be included if the remote server advertises support for this XEP. This acts as an opt-in mechanism, to address the privacy concern defined in the Privacy Considerations section of this document.

From 67fbffa4fae4c5a10aa5544d47ba42c685317e6c Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 22 Dec 2023 11:13:33 +0100 Subject: [PATCH 012/145] PubSub Server Info: fix reference to XEP specifying namespace XEP-0157 specifies the 'serverinfo' form, XEP-0128 just uses it as example. Co-authored-by: Florian Schmaus --- inbox/pubsub-server-info.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index f90eedd7c..d63a0438f 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -46,7 +46,7 @@

Domains supporting the publication of Server Information data, as described in this document, MUST advertise the fact by announcing a &xep0030; feature of 'urn:xmpp:serverinfo:0'. This signifies that an administrative entity approved the publication of data, which is important for the opt-in mechanism described in Privacy Considerations section of this document.

-

The pub-sub service address and node in which Server Information data is advertised SHOULD be specified using a &xep0128;. These pub-sub coordinates MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in XEP-0128) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

+

The pub-sub service address and node in which Server Information data is advertised SHOULD be specified using a &xep0128;. These pub-sub coordinates MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as specified in XEP-0157) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

When the 'urn:xmpp:serverinfo:0' feature but no corresponding Service Discovery Extension is advertised, the node that is used will be a first-level leaf node using the name 'serverinfo' on the first pub-sub service advertised through service discovery.

Date: Fri, 22 Dec 2023 11:23:41 +0100 Subject: [PATCH 013/145] PubSub Server Info: replace data form fields with URI As per Flow's suggestion, replace two data form fields that hold a pub-sub service address and node with one field, that uses a URI to identify the same pub-sub node. --- inbox/pubsub-server-info.xml | 15 ++++----------- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index d63a0438f..4b750f623 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -46,7 +46,7 @@

Domains supporting the publication of Server Information data, as described in this document, MUST advertise the fact by announcing a &xep0030; feature of 'urn:xmpp:serverinfo:0'. This signifies that an administrative entity approved the publication of data, which is important for the opt-in mechanism described in Privacy Considerations section of this document.

-

The pub-sub service address and node in which Server Information data is advertised SHOULD be specified using a &xep0128;. These pub-sub coordinates MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as specified in XEP-0157) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

+

The pub-sub service address and node in which Server Information data is advertised SHOULD be specified using a &xep0128;, using an URI as specified in section 12.22 of XEP-0060. These pub-sub coordinates MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as specified in XEP-0157) and data form field registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

When the 'urn:xmpp:serverinfo:0' feature but no corresponding Service Discovery Extension is advertised, the node that is used will be a first-level leaf node using the name 'serverinfo' on the first pub-sub service advertised through service discovery.

http://jabber.org/network/serverinfo - - pubsub.shakespeare.lit - - serverinfo + xmpp:pubsub.shakespeare.lit?;node=serverinfo @@ -191,14 +188,10 @@ Forms advertising the coordinates of a pub-sub service and node for publication of Server Information data. - + type='text-single' + label='An URI (per XEP-0060 section 12.22) identifying the pub-sub node on which Server Information data is published.'/> ]]>

Note that the FORM_TYPE used by &xep0157; is purposefully re-used by this XEP, to circumvent the restriction of having at most one XMPP Standards Foundation defined FORM_TYPE for a service discovery identity, as defined in &xep0128;. When a service supports both features, the data in both forms SHOULD be merged into one form.

From 08766b58ecb7732d61f63b1d1963de3e5f7f2b92 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 2 Jan 2024 16:47:50 +0000 Subject: [PATCH 014/145] Bump tj-actions/changed-files from 34 to 41 in /.github/workflows Bumps [tj-actions/changed-files](https://github.com/tj-actions/changed-files) from 34 to 41. - [Release notes](https://github.com/tj-actions/changed-files/releases) - [Changelog](https://github.com/tj-actions/changed-files/blob/main/HISTORY.md) - [Commits](https://github.com/tj-actions/changed-files/compare/v34...v41) --- updated-dependencies: - dependency-name: tj-actions/changed-files dependency-type: direct:production ... Signed-off-by: dependabot[bot] --- .github/workflows/xep-validation.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/xep-validation.yml b/.github/workflows/xep-validation.yml index 0c6be272e..34ee09cd4 100644 --- a/.github/workflows/xep-validation.yml +++ b/.github/workflows/xep-validation.yml @@ -16,7 +16,7 @@ jobs: - name: Detect changes to XEP files id: changed-xeps - uses: tj-actions/changed-files@v34 + uses: tj-actions/changed-files@v41 with: files: | xep-*.xml From 798400210d60a0f82e9c38d32c1e1b69769e8985 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 5 Jan 2024 10:41:46 +0100 Subject: [PATCH 015/145] XEP-0133: Retract 'Get User Password' command Retrieving a password implies storage of plaintext passwords. That's no longer an acceptable practice. --- xep-0133.xml | 96 +++++----------------------------------------------- 1 file changed, 9 insertions(+), 87 deletions(-) diff --git a/xep-0133.xml b/xep-0133.xml index 4fadc78be..119d0faa9 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -21,6 +21,12 @@ admin &stpeter; + + 1.3 + 2024-01-04 + gdk + Removed use case 'Get User Password', which violates best-practices with regard to security. + 1.2 2017-07-15 @@ -110,7 +116,7 @@
  • Disable User
  • Re-Enable User
  • End User Session
    • -
  • Get User Password
    • +
  • Get User Password (retracted)
  • Change User Password
  • Get User Roster
  • Get User Last Login Time
    • @@ -539,92 +545,8 @@ ]]>     - -

    An administrator may need to retrieve a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#get-user-password".

    -

    A sample protocol flow for this use case is shown below.

    - - - -]]> -

    Unless an error occurs (see the Error Handling section below), the service SHOULD return the appropriate form.

    - - - - Getting a User's Password - Fill out this form to get a user's password. - - http://jabber.org/protocol/admin - - - - - - - -]]> -

    Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.

    - - - - - http://jabber.org/protocol/admin - - - juliet@shakespeare.lit - - - - -]]> -

    Naturally, the data form included in the IQ result will include the user's password.

    - - - - - http://jabber.org/protocol/admin - - - juliet@shakespeare.lit - - - R0m30 - - - - -]]> + +

    Up to and including revision 1.2 of this XEP, this section defined a command that could be used to retrieve a user's password. This implies that the implementation stores plaintext passwords, a practise that is a well-documented vulnerabilityOWASP: Password Plaintext Storage <https://owasp.org/www-community/vulnerabilities/Password_Plaintext_Storage>. This command has therefore been retracted from this XEP. To retain section numbering, this text replaces the command definition that previously existed in this section.

    An administrator may need to change a user's password. The command node for this use case SHOULD be "http://jabber.org/protocol/admin#change-user-password".

    From 5b55aad8818f733ea5204835b13606114911f039 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 5 Jan 2024 10:50:11 +0100 Subject: [PATCH 016/145] XEP-0133: Add 'Approver' to header --- xep-0133.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0133.xml b/xep-0133.xml index 119d0faa9..ed8fbbd4b 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -13,6 +13,7 @@ Active Informational Standards + Council RFC 6120 XEP-0050 From 4c4761b8f41c1441963531fc0b0c93f18e0c153e Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 15 Jan 2024 11:26:07 -0700 Subject: [PATCH 017/145] advance XEP-0458 to Active --- xep-0458.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xep-0458.xml b/xep-0458.xml index 7641b832c..19941d1a1 100644 --- a/xep-0458.xml +++ b/xep-0458.xml @@ -12,7 +12,7 @@ &LEGALNOTICE; 0458 - Experimental + Active Procedural None Board @@ -22,6 +22,12 @@ N/A &dcridland; &stpeter; + + 1.0 + 2024-01-15 + psa +

    Changed status to Active per Board vote on 2024-01-05.

     +     0.4.0 2023-12-11 From 22faebc7fa0a54c0feef0c57fc2fdd5740e90e82 Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Mon, 22 Jan 2024 14:18:08 +0000 Subject: [PATCH 018/145] Update xep-0458.xml Fix version to make the tools happy. --- xep-0458.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0458.xml b/xep-0458.xml index 19941d1a1..783513dc2 100644 --- a/xep-0458.xml +++ b/xep-0458.xml @@ -23,7 +23,7 @@ &dcridland; &stpeter; - 1.0 + 1.0.0 2024-01-15 psa

    Changed status to Active per Board vote on 2024-01-05.

     From ca9b96e8a2fba1c1b83523b418d5dab1b3c253f3 Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Mon, 22 Jan 2024 14:19:45 +0000 Subject: [PATCH 019/145] Update xep-0133.xml version Change version to make tools happy --- xep-0133.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0133.xml b/xep-0133.xml index ed8fbbd4b..1051ce69f 100644 --- a/xep-0133.xml +++ b/xep-0133.xml @@ -23,7 +23,7 @@ admin &stpeter; - 1.3 + 1.3.0 2024-01-04 gdk Removed use case 'Get User Password', which violates best-practices with regard to security. From 073686d0037c3404f8f5aa57f98b874c99bdbb79 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Mon, 22 Jan 2024 15:27:55 +0100 Subject: [PATCH 020/145] ProtoXEP: PubSub Server Information renamed version to 0.0.1 --- inbox/pubsub-server-info.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/pubsub-server-info.xml b/inbox/pubsub-server-info.xml index 4b750f623..eef25655b 100644 --- a/inbox/pubsub-server-info.xml +++ b/inbox/pubsub-server-info.xml @@ -25,7 +25,7 @@ guus.der.kinderen@igniterealtime.org - 1.0.0 + 0.0.1 2023-12-19 gdk From 05419b0892fa16abe1f8ff69e9667fc43968320c Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Tue, 23 Jan 2024 17:35:24 +0000 Subject: [PATCH 021/145] Update xep-0484.xml --- xep-0484.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0484.xml b/xep-0484.xml index bb9ea88ae..07027158b 100644 --- a/xep-0484.xml +++ b/xep-0484.xml @@ -31,7 +31,7 @@
    • Promoted to Experimental.
    -     + 0.0.1 2022-10-19 From 773d1e73a1ac2079905eff8d12cc5f18f440f4df Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Tue, 30 Jan 2024 12:20:40 +0100 Subject: [PATCH 022/145] xep-0484: make XML well-formed again, add missing --- xep-0484.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0484.xml b/xep-0484.xml index 07027158b..c57ac9149 100644 --- a/xep-0484.xml +++ b/xep-0484.xml @@ -32,6 +32,7 @@
  • Promoted to Experimental.
    • +     0.0.1 2022-10-19 From 67945f2ae3822023e760699ea1afdf91071e9e1c Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Tue, 30 Jan 2024 12:21:38 +0100 Subject: [PATCH 023/145] Makefile: add 'check' target, consolidating xmllint invocations Previously the html and pdf targets would also verify the input via xmllint. This caused some code duplication and overloaded the targets which an arguably unrelated task (verification). Furthermore, something changed and the ! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true no fails. It seems that xmllint does no longer (?) report an error exit status if the XPath result set is empty [1]. Therfore, this rule is currently commented out, which fixed #1316. 1: https://gitlab.gnome.org/GNOME/libxml2/-/issues/673 --- .github/workflows/xep-validation.yml | 6 ++++++ .gitignore | 2 ++ Makefile | 25 ++++++++++++------------- 3 files changed, 20 insertions(+), 13 deletions(-) diff --git a/.github/workflows/xep-validation.yml b/.github/workflows/xep-validation.yml index 34ee09cd4..76731bf58 100644 --- a/.github/workflows/xep-validation.yml +++ b/.github/workflows/xep-validation.yml @@ -31,5 +31,11 @@ jobs: if ! tools/validate-xep0001-conformance.sh "$xep"; then result=1 fi + if [[ ${xep} == xep-* ]]; then + echo Checking ${xep} by invoking \"make .${xep}.check.ok\" + if ! make ".${xep}.check.ok"; then + result=1 + fi + fi done exit $result diff --git a/.gitignore b/.gitignore index e82009191..f8b40f4d0 100644 --- a/.gitignore +++ b/.gitignore @@ -75,3 +75,5 @@ Session.vim /tools/xeps-email.conf /tmp/ /pr-worktree/ + +.*.xml.check.ok diff --git a/Makefile b/Makefile index 051bc7bd9..0eb413e9e 100644 --- a/Makefile +++ b/Makefile @@ -36,6 +36,7 @@ xep_pdfs=$(patsubst %.xml,$(OUTDIR)/%.pdf,$(xeps)) xep_refs=$(patsubst xep-%.xml, $(REFSDIR)/reference.XSF.XEP-%.xml, $(xeps)) xep_examples=$(patsubst xep-%.xml, $(EXAMPLESDIR)/%.xml, $(xeps)) +all_xep_check_ok=$(patsubst %.xml, .%.xml.check.ok, $(xeps)) .PHONY: help help: @@ -46,6 +47,7 @@ help: @echo ' refs - build all IETF refs' @echo ' html - build all XEPs' @echo ' inbox-html - build all ProtoXEPs' + @echo ' check - check all XEPs for errors' @echo ' clean - recursively unlink the build tree' @echo ' preview - builds html whenever an XEP changes (requires inotify-tools)' @echo ' examples - extract all examples' @@ -82,6 +84,9 @@ refs: $(xep_refs) .PHONY: examples examples: $(xep_examples) +.PHONY: check +check: $(all_xep_check_ok) + .PHONY: xep-% xep-%: $(OUTDIR)/xep-%.html $(REFSDIR)/reference.XSF.XEP-%.xml $(OUTDIR)/xep-%.pdf $(EXAMPLESDIR)/%.xml; @@ -106,30 +111,24 @@ $(EXAMPLESDIR)/%.xml: xep-%.xml $(XMLDEPS) examples.xsl | $(EXAMPLESDIR) $(REFSDIR)/reference.XSF.XEP-%.xml: xep-%.xml $(XMLDEPS) ref.xsl | $(REFSDIR) xsltproc --path $(CURDIR) ref.xsl "$<" > "$@" && echo "Finished building $@" -$(xep_htmls): $(OUTDIR)/xep-%.html: xep-%.xml $(XMLDEPS) $(HTMLDEPS) | $(OUTDIR) +.%.xml.check.ok: %.xml xmllint --nonet --noout --noent --loaddtd --valid "$<" - # Check for non-data URIs - ! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true + # Check for non-data URIs, the result set of the XPath expression below should be empty + # Disabled for now, see + # https://github.com/xsf/xeps/issues/1316 and https://gitlab.gnome.org/GNOME/libxml2/-/issues/673 + # xmllint --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< > /dev/null + touch $@ - # Actually build the HTML +$(xep_htmls): $(OUTDIR)/xep-%.html: xep-%.xml $(XMLDEPS) $(HTMLDEPS) | $(OUTDIR) xsltproc --path $(CURDIR) --param htmlbase "$(if $(findstring inbox,$<),'../','./')" xep.xsl "$<" > "$@" && echo "Finished building $@" $(proto_xep_htmls): $(OUTDIR)/inbox/%.html: inbox/%.xml $(XMLDEPS) $(proto_HTMLDEPS) | $(OUTDIR) - xmllint --nonet --noout --noent --loaddtd --valid "$<" - # Check for non-data URIs - ! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true - - # Actually build the HTML xsltproc --path $(CURDIR) --param htmlbase "$(if $(findstring inbox,$<),'../','./')" xep.xsl "$<" > "$@" && echo "Finished building $@" $(OUTDIR)/xmpp.pdf $(OUTDIR)/xmpp-text.pdf: | $(OUTDIR) cp "resources/$(notdir $@)" "$@" $(OUTDIR)/%.pdf: %.xml $(XMLDEPS) $(TEXMLDEPS) - xmllint --nonet --noout --noent --loaddtd --valid "$<" - # Check for non-data URIs - ! xmllint --nonet --noout --noent --loaddtd --xpath "//img/@src[not(starts-with(., 'data:'))]" $< 2>/dev/null && true - xsltproc --path $(CURDIR) xep2texml.xsl "$<" > "$(@:.pdf=.tex.xml)" texml -e utf8 "$(@:.pdf=.tex.xml)" "$(@:.pdf=.tex)" sed -i -e 's|\([\s"]\)\([^"]http://[^ "]*\)|\1\\path{\2}|g' \ From be9cae8ce704ec5f197e3a710bbbcd6995d2559e Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Fri, 23 Feb 2024 12:22:37 +0100 Subject: [PATCH 024/145] add XEP for 'Message Displayed Synchronization' --- inbox/xep-mds.xml | 218 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 218 insertions(+) create mode 100644 inbox/xep-mds.xml diff --git a/inbox/xep-mds.xml b/inbox/xep-mds.xml new file mode 100644 index 000000000..f760769fb --- /dev/null +++ b/inbox/xep-mds.xml @@ -0,0 +1,218 @@ + + +%ents; +]> + + +
    + Message Displayed Synchronization + This specification allows multiple clients of the same user to synchronize the displayed state of their chats. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + Etc. + + + + mds + + Daniel + Gultsch + daniel@gultsch.de + daniel@gultsch.de + + + 0.0.1 + 2024-02-21 + dg +

    First draft.

     +     +
    + +

    In multi-device environments marking a chat as displayed on one device should mark that chat as displayed on all devices. Historically carbon copies (&xep0280;) of the <displayed/> element of Chat Markers (&xep0333;) have been used to achieve this effect. However this approach has a couple of downsides that this specification is trying eliminate:

    +
      +
    • The contact has to request Chat Markers by tagging a message with <markable/>.
      • +
    • Chat Markers let the contact know that a device has displayed the message. This might not always be advisable when synchronization across multiple devices of the same user is the desired outcome.
      • +
    • When used in large group chats Chat Markers can create a lot of unwanted traffic.
      • +
    +

    This specification isolates the task of multi-device synchronization from providing information to the contact, while borrowing some of the semantics of Chat Markers such as displayed refering to all messages up to this point.

    +     + +
      +
    • Basic functionality should not depend on server features that go beyond what is commonly implemented at the time of writing this specification.
      • +
    • Rely on server-injected <stanza-id/> (see &xep0359;) to provide unique and stable IDs. While this is commonly done as part of &xep0313; it does not technically depend on the message being archived.
      • +
    • Define the interaction with &xep0333;.
      • +
    • Provide optional methods for traffic optimizations on supporting servers.
      • +
    • Make no assertions on what constitutes an open or archived chat. This specification allows clients to state that they have displayed messages in a certain chat up to a certain point. It does not indicate that a chat is open or in case of group chats joined.
      • +
    +     + +
    + +
    Displayed
    +
    + Colloquially this is also known as read. However since a common implementation of read is: "shown on screen, in full, in the context of the chat", and this gives no indication on whether the user has actually read a message, displayed was chosen as a more accurate terminology. A message might also be manually acknowledged by the user, for example via a mark as read action in a notification. Implementations are also possible, for example in smart home devices or infotainment systems, where the message is read aloud by a Text-to-Speech system, but never actually displayed. It is up to the implementors discretion to determine what the best approximation of the user has had a reasonable chance to mentally process the message is. +
    +     +
    +     + + +

    Clients use items in a private PEP (&xep0163;) node called 'urn:xmpp:mds:displayed:0' to synchronize and persist the displayed state (See &xep0223;). The item ID corresponds to the JID of the respective chat. For normal, 1:1 chats this SHOULD be the bare JID of the contact, for group chats this SHOULD be the bare JID of the room and for private messages in group chats the full JID of the participant.

    +

    The item contains a single <displayed/> element qualified by the 'xrn:xmpp:mds:displayed:0' namespace. The <displayed/> element MUST contain an attribute called 'stanza-id' that corresponds to the stanza-id (&xep0359;) of the most recent, displayed message, in that particular chat.

    +     + +

    Only messages received by the user (meaning sent by third parties such as a contact, a participant in a group chat, etc) SHOULD be flagged as 'displayed'. However since 'displayed' means all messages up to this point and the stanza-id of a message sent by the user indicates a valid point in the chat history, sent messages MAY be flagged as well.

    +

    Flagging a chat as displayed up to this point happens by publishing a PEP item with an id corresponding to the JID of the chat and a <displayed/> payload element into the 'urn:xmpp:mds:displayed:0' node.

    +

    For group chats the stanza-id attribute of the <displayed/> element refers to the stanza-id injected by the room. For all other chats the stanza-id attribute refers to the stanza-id injected by the user’s server (the server hosting the user account).

    +

    The client MUST include appropriate publish-options in the publication, including, but not limited to, setting the access model to whitelist and the max-items to max.

    + + + + + + + + + + + http://jabber.org/protocol/pubsub#publish-options + + + true + + + max + + + never + + + whitelist + + + + + +]]> + +]]> +     + +

    A client interested in synchronizing the displayed state with other clients SHOULD include the 'urn:xmpp:mds:displayed:0+notify' feature in its &xep0115;, as per &xep0163; rules.

    +     + +

    Upon bind and initial presence a client retrieves all items in the 'urn:xmpp:mds:displayed:0' node to learn what changes to the displayed state have occured while the client was offline.

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

    A &xep0333; displayed marker refers to the message id set by the sender of the message whereas the displayed element defined in this specification refers to the stanza-id injected by the user’s server.

    +

    In the likely scenario that a client wishes to share the displayed state with their own devices and the sender of the message, a client SHOULD sent a &xep0333; displayed marker and ensure that the 'urn:xmpp:mds:displayed:0' node gets updated.

    + +

    A &xep0060; item publication is a fairly verbose operation for something that is expected to happen rather frequently. Therfore this specification defines an optional way to combine the PEP node item update and the Chat Marker in one simple message.

    +     + +

    Server assisted displayed node updates are an optional feature a user’s server can provide. To signal support the server announces an &xep0115; feature of 'urn:xmpp:mds:server-assist:0' on the account.

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

    To update the displayed item in the 'urn:xmpp:mds:displayed:0' PEP node more efficiently a client MAY send a message with the 'to' attribute set to the item id (which is equivalent to the JID of the contact) and with a <displayed/> element qualified by the 'urn:xmpp:mds:displayed:0' namespace. The server MUST strip the <displayed/> element from the message and continue to process it normally. The server MUST publish a PEP item on the 'urn:xmpp:mds:displayed:0' node where the item id is taken from the 'to' attribute and the payload is the <displayed/> element. A client MUST NOT include the <displayed/> element qualified by the 'urn:xmpp:mds:displayed:0' namespace if the message would otherwise be empty. A client that wishes to update the device synchronized displayed state but not inform the sender of the message via Chat Markers SHOULD use the regular PubSub publication process.

    + + Hi. How are you? + + + +]]> + + + + +]]> + + + + + + + + + +]]> +     +     +     + +
      +
    • The displayed state only moves forward. Receiving a displayed state with a stanza-id that references a message older than the current local representation is considered redundant and MUST be ignored.
      • +
    • Displayed states with a stanza-id not found in the respective chat MUST be ignored.
      • +
    • Receiving an outgoing message (for example via &xep0280; or &xep0313;) SHOULD NOT mark the chat as displayed. Outgoing messages are neutral towards the overall displayed state of a given chat. For example if the displayed up to state references the most recent incoming message and this message is only followed by outgoing messages the overall state of that chat SHOULD be considered displayed.
      • +
    • A client receiving an outgoing message MAY NOT update the displayed node item with that stanza-id. However clients SHOULD be able to handle displayed states that use stanza-ids that refer to outgoing messages and simply consider the chat as displayed up to that point.
      • +
    • While Chat Markers (&xep0333;), in 1:1 chats, MAY be sent to a full JID, a client combining both <displayed/> elements in a single message MUST address that message to the bare JID, as the server will use the verbatim 'to' attribute as the item ID.
      • +
    +     + +
      +
    • When publishing displayed states via &xep0060; the client MUST use publish-options to set the access model on the node to whitelist. To ensure the server supports publish-options the client MUST first check for the "http://jabber.org/protocol/pubsub#publish-options" feature.
      • +
    • Servers that support the server assist feature MUST strip the <displayed/> element in the "urn:xmpp:mds:displayed:0" namespace from the message to avoid the stanza-id being leaked to the recipient of that message.
      • +
    • Clients MUST NOT put the <displayed/> into a message to trigger server-assited displayed synchronization unless the server announces the "urn:xmpp:mds:server-assist:0" feature.
      • +
    • This specification provides a convenient process to synchronize a user’s own devices and informing the third party in one, single message. However letting the third party know is not always desirable, for example when the user has generally opted out of transmitting the displayed status or when a non-contact initiated a chat. In those cases the client MUST use the &xep0060; method instead of server-assist.
      • +
    +     + +

    REQUIRED.

    +     + +

    REQUIRED.

    +     + +

    REQUIRED for protocol specifications.

    +     +     From 6b2c521af924ad1deda42481e4ae455d85c2a8aa Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Tue, 27 Feb 2024 14:38:33 +0100 Subject: [PATCH 025/145] XEP-xxxx (MDS) use stanza-id element instead of attr --- inbox/xep-mds.xml | 31 ++++++++++++++++++++++--------- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/inbox/xep-mds.xml b/inbox/xep-mds.xml index f760769fb..e44894a18 100644 --- a/inbox/xep-mds.xml +++ b/inbox/xep-mds.xml @@ -66,20 +66,23 @@

    Clients use items in a private PEP (&xep0163;) node called 'urn:xmpp:mds:displayed:0' to synchronize and persist the displayed state (See &xep0223;). The item ID corresponds to the JID of the respective chat. For normal, 1:1 chats this SHOULD be the bare JID of the contact, for group chats this SHOULD be the bare JID of the room and for private messages in group chats the full JID of the participant.

    -

    The item contains a single <displayed/> element qualified by the 'xrn:xmpp:mds:displayed:0' namespace. The <displayed/> element MUST contain an attribute called 'stanza-id' that corresponds to the stanza-id (&xep0359;) of the most recent, displayed message, in that particular chat.

    +

    The item contains a single <displayed/> element qualified by the 'xrn:xmpp:mds:displayed:0' namespace. The <displayed/> element MUST contain exactly one &xep0359; <stanza-id/> element that corresponds to the stanza-id of the most recent, displayed message, in that particular chat.

    Only messages received by the user (meaning sent by third parties such as a contact, a participant in a group chat, etc) SHOULD be flagged as 'displayed'. However since 'displayed' means all messages up to this point and the stanza-id of a message sent by the user indicates a valid point in the chat history, sent messages MAY be flagged as well.

    Flagging a chat as displayed up to this point happens by publishing a PEP item with an id corresponding to the JID of the chat and a <displayed/> payload element into the 'urn:xmpp:mds:displayed:0' node.

    -

    For group chats the stanza-id attribute of the <displayed/> element refers to the stanza-id injected by the room. For all other chats the stanza-id attribute refers to the stanza-id injected by the user’s server (the server hosting the user account).

    +

    For group chats the <stanza-id/> child of the <displayed/> element refers to the stanza-id injected by the room. For all other chats the stanza-id child refers to the stanza-id injected by the user’s server (the server hosting the user account).

    The client MUST include appropriate publish-options in the publication, including, but not limited to, setting the access model to whitelist and the max-items to max.

    - + + + @@ -127,12 +130,18 @@ - + + + + + @@ -172,7 +181,9 @@ - + + + ]]> - + + + From 2cc839e3e149faab4366ffa556b80e3923e05639 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 10 Mar 2024 07:51:16 +0100 Subject: [PATCH 026/145] Move 'PubSub Server Information' to Experimental --- xep-0485.xml | 278 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 278 insertions(+) create mode 100644 xep-0485.xml diff --git a/xep-0485.xml b/xep-0485.xml new file mode 100644 index 000000000..c5f8c25fa --- /dev/null +++ b/xep-0485.xml @@ -0,0 +1,278 @@ + + + %ents; + ]> + + +
    + PubSub Server Information + This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. + &LEGALNOTICE; + 0485 + Experimental + Standards Track + Standards + Council + + + + serverinfo + + Guus + der Kinderen + guus.der.kinderen@gmail.com + guus.der.kinderen@igniterealtime.org + + + 0.1.0 + 2024-03-10 + dg + +
      +
    • Promoted to Experimental.
      • +
    +     +     + + 0.0.1 + 2023-12-19 + gdk + +
      +
    • Initial version.
      • +
    +     +     +
    + +

    To facilitate discovery of information of individual domains in an XMPP-based network, this specification defines a data format to define basic information for individual XMPP domains. By leveraging &xep0060; this information can efficiently be shared with applications that compose an overview of the larger XMPP network.

    +     + +
      +
    • Describe links between nodes in an XMPP-based network, by enumerating connections used for federation between XMPP domains.
      • +
    • An extensible data format, allowing additional data (such as that defined in &xep0092;) to be retrievable without requiring additional round-trips.
      • +
    +     + +

    Domains supporting the publication of Server Information data, as described in this document, MUST advertise the fact by announcing a &xep0030; feature of 'urn:xmpp:serverinfo:0'. This signifies that an administrative entity approved the publication of data, which is important for the opt-in mechanism described in Privacy Considerations section of this document.

    +

    The pub-sub service address and node in which Server Information data is advertised SHOULD be specified using a &xep0128;, using an URI as specified in section 12.22 of XEP-0060. These pub-sub coordinates MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as specified in XEP-0157) and data form field registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

    +

    When the 'urn:xmpp:serverinfo:0' feature but no corresponding Service Discovery Extension is advertised, the node that is used will be a first-level leaf node using the name 'serverinfo' on the first pub-sub service advertised through service discovery.

    + + +]]> + + + ... + + ... + + + http://jabber.org/network/serverinfo + + + xmpp:pubsub.shakespeare.lit?;node=serverinfo + + + +]]> +

    The node MUST reference a first-level leaf node on a pub-sub service.

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

    The data format uses an element named 'serverinfo' in the namespace 'urn:xmpp:serverinfo:0'. In its minimal form, it defines each XMPP domain name served by the local server in an attribute named 'name'.

    + + +]]> +

    The optional 'federation' child element is used to denote remote XMPP domains with which the local domain is federating. Each of them are represented by an element named 'remote-domain'. The domain name of the peer in an optional attribute named 'name'. Optionally, each actual (e.g. TCP) connection from the local server to the peer is added as a 'connection' child-element to the 'remote-domain' element, that has an optional 'type' attribute, defining the directionality of the connection (one of 'incoming', 'outgoing' and 'bidi').

    +

    The name of a remote domain MUST only be included if the remote server advertises support for this XEP. This acts as an opt-in mechanism, to address the privacy concern defined in the Privacy Considerations section of this document.

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

    Additional data MAY be included as child-elements of the 'serverinfo' element or any of the 'domain' elements. Such data MUST be namespaced appropriately. The example below uses the 'query' element defined in &xep0092; to include information about the software application associated with the local server.

    + + + + + + + + + + Openfire + 4.8.0 + Windows 11 + +]]> +     + +

    The data is to be published using a pub-sub node named 'serverinfo' that MUST be a first-level leaf node of a pub-sub service for the domain. It is RECOMMENDED that the leaf-node is configured to have an open access model and contain a maximum of 1 item.

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

    As certain information can be expected to be updated continuously and frequently, the server MAY choose to reduce the frequency of updates of the 'serverinfo' pub-sub node.

    +     + +

    When multiple domains publish their connections to named remote domains, an information leak occurs: by collecting these public statistics, behavioral data of those remote domains can be deduced. To prevent undesired privacy-sensitive information leaks, a domain MUST NOT publish the name of a remote domain, unless that domain advertises support for this XEP, as defined in the Discovering Support section of this document.

    +

    This way, the service discovery mechanism doubles as an opt-in mechanism. Domains that advertise support for this XEP allow other domains to reference them by domain-name in the data that they publish. The mere presence of an applicable pub-sub node MUST NOT be used for Service Discovery purposes, as under common service configuration, non-administrative users are allowed to create such nodes.

    +     + +

    Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall include the following information in its registries.

    + +

    This specification defines the following XML namespaces:

    +
      +
    • urn:xmpp:serverinfo:0
      • +
    +

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

    +     + +

    &xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and XEP-0128 describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.

    + + http://jabber.org/network/serverinfo + XEP-0XXX + + Forms advertising the coordinates of a pub-sub service and node for publication of Server Information data. + + + +]]> +

    Note that the FORM_TYPE used by &xep0157; is purposefully re-used by this XEP, to circumvent the restriction of having at most one XMPP Standards Foundation defined FORM_TYPE for a service discovery identity, as defined in &xep0128;. When a service supports both features, the data in both forms SHOULD be merged into one form.

    +     +     + + + + + + + + The protocol documented by this schema is defined in + XEP-0XXX: http://www.xmpp.org/extensions/xep-0XXX.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> + + +

    Inspiration was taken from the (now defunct) 'server info' crawler by Thomas Leister. Many thanks to Dave Cridland, as well as 'zoidberg' and 'chewie' from the Ignite Realtime community for helping to test the initial implementation of a graphing implementation based on this XEP and to Florian Schmaus, Matthew Wild, Jonas Schäfer and Kevin Smith for their feedback on the earliest drafts of this document.

    +     + +     From b8d4860c66f1c616a178b69113bd696d47036034 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 10 Mar 2024 08:51:27 +0100 Subject: [PATCH 027/145] Move 'XEP-0486: MUC Avatars' to Experimental --- xep-0486.xml | 323 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 5 +- 2 files changed, 327 insertions(+), 1 deletion(-) create mode 100644 xep-0486.xml diff --git a/xep-0486.xml b/xep-0486.xml new file mode 100644 index 000000000..bd8ebb0ba --- /dev/null +++ b/xep-0486.xml @@ -0,0 +1,323 @@ + + +%ents; +]> + + +
    + MUC Avatars + This specification describes how to publish and retrieve avatars in rooms. + &LEGALNOTICE; + 0486 + Experimental + Historical + Standards + Council + + XMPP Core + XEP-0030 + XEP-0045 + XEP-0054 + XEP-0068 + XEP-0153 + + + + NOT_YET_ASSIGNED + &linkmauve; + + 0.1.0 + 2024-03-10 + XEP Editor: dg + +
      +
    • Promoted to Experimental
      • +
    +     +     + + 0.0.3 + 2023-02-15 + egp +

    Restore to the first revision, and republish to the Historical track.

     +     + + 0.0.2 + 2018-11-03 + tj +

    Generalise to non-MUC resources.

     +     + + 0.0.1 + 2018-08-21 + egp +

    First draft.

     +     +
    + +

    Avatars are small images people often use to identify each other very quickly in chat applications. They are well defined for users, in &xep0084; and &xep0153;, but until now chat rooms all shared a default icon. This extension provides a way for owners to associates an avatar to their chat room, and for users to discover that an avatar is associated and display it accordingly.

    +

    XMPP services have traditionally allowed owners to set a vCard-temp on a MUC using &xep0054;, this extension tries to keep as much of it as possible so existing applications don’t have to be modified too much.

    +

    Some implementations recently chose to advertise those avatars using the existing &xep0153; extension in <presence/>, but it exposed issues in other implementations, and was only available when the user is already present in the room, not before joining it (for example when listing all available rooms).

    +

    A future extension superseding this one could define a method based on &xep0084;, with a PubSub service on the room’s bare JID containing the metadata and data nodes. Such a specification should also define a compatibility profile similar to &xep0398; for user avatars, enabling the coexistence of both versions until the present one is deemed obsolete.

    +     + +

    This specification SHOULD:

    +
      +
    • Allow authorised entities to set an avatar on a MUC.
      • +
    • Allow authorised entities to remove a previously-set avatar on a MUC.
      • +
    • Allow users to discover an avatar is set on a MUC.
      • +
    • Allow users to request the avatar of a MUC.
      • +
    • Let users know that the avatar of a MUC changed while they are present in said MUC.
      • +
    • Let users discover the avatar even when not present in the MUC.
      • +
    • Stay as compatible as possible with the current usage of avatars in MUC.
      • +
    +     + + +

    Before trying to use avatars, a client must check that the group chat service hosting a room does support them.

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

    Before anyone can see an avatar attached to the room, an owner or some other priviledged entity must publish a vCard-temp containing the avatar’s data, using the protocol defined in &xep0054;.

    + + + + image/svg+xml + PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiI+CiA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIiIGZpbGw9InJlZCIvPgo8L3N2Zz4K + + +]]> + ]]> +

    There is no other action required on the owner’s end.

    +

    If the room doesn’t support support avatars, it must return a service-unavailable error.

    + + + + +]]> +

    If the user trying to publish an avatar isn’t allowed to do so, the room must return a forbidden error, see the Security Considerations.

    + + + + Only owners are allowed to set avatars. + +]]> +

    The room should then broadcast a notification that the configuration changed to all users present.

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

    Setting an empty vCard unpublishes the avatar.

    + + +]]> +     + +

    At any point, whether it is during a join in order to display it in its UI, after having discovered the list of the rooms and to list them with additional information, or when receiving a <status code='104'/> configuration change notification, a user’s client can discover information about a room.

    + + +]]> +

    If the room has had an avatar published, it should advertise it in its 'muc#roominfo' extension form, using the &xep0153; hash computation method.

    + + + + + + ... + + + http://jabber.org/protocol/muc#roominfo + + ... + + a31c4bd04de69663cfd7f424a8453f4674da37ff + + ... + + +]]> +

    This 'muc#roominfo_avatarhash' will not be present when the room doesn’t have an avatar set.

    +     + +

    At this point the client knows the hash and can retrieve the room’s vCard-temp.

    + + +]]> + + + + image/svg+xml + PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiI+CiA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIiIGZpbGw9InJlZCIvPgo8L3N2Zz4K + + +]]> +

    The client then has to decode the <BINVAL/> content from base64, hash it with sha1 and compare it with the advertised hash, and if it matches uses it as the room avatar under the <TYPE/> media type.

    +     +     + +

    An application MUST support the image/png media type, SHOULD support image/jpeg, image/gif and image/svg+xml, and MAY support additional formats.

    +

    A room SHOULD NOT include a 'muc#roominfo_avatarhash' field if it doesn’t have an avatar set.

    +     + + +

    Multiple <PHOTO/> elements may be present in a vCard, in which case they should all represent the same image and the 'muc#roominfo_avatarhash' field must contain a hash of all of them.

    + + + + image/svg+xml + PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiI+CiA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iMzIiIGhlaWdodD0iMzIiIGZpbGw9InJlZCIvPgo8L3N2Zz4K + + + image/png + iVBORw0KGgoAAAANSUhEUgAAACAAAAAgAQMAAABJtOi3AAAAB3RJTUUH4ggVERoVAPsrMgAAAAlwSFlzAAALEgAACxIB0t1+/AAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAAEZ0FNQQAAsY8L/GEFAAAAIGNIUk0AAHomAACAhAAA+gAAAIDoAAB1MAAA6mAAADqYAAAXcJy6UTwAAAAGUExURf8AAP///0EdNBEAAAABYktHRAH/Ai3eAAAADElEQVQI12NgGNwAAACgAAFhJX1HAAAAAElFTkSuQmCC + + +]]> + + + + + + ... + + + http://jabber.org/protocol/muc#roominfo + + ... + + a31c4bd04de69663cfd7f424a8453f4674da37ff + b9b256f999ded52c2fa14fb007c2e5b979450cbb + + ... + + +]]> +     + +

    Some existing implementations send or expect a presence from the room’s bare JID in order to detect an avatar being published. This had several issues, with existing clients handling that as a presence from a user with an empty nick or downright triggering an error, and was only available if the client was already present in the room, preventing any usecase where it would get displayed before entering the room.

    +

    For those reasons, this XEP doesn’t encourage this way of advertising the presence of an avatar, but for reference it would look like a &xep0153; presence payload:

    + + + a31c4bd04de69663cfd7f424a8453f4674da37ff + + +]]> +     +     + +

    A server should take care that only allowed entities can publish a vCard-temp on a MUC, for instance room owners or service administrators.

    +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    The registrar shall add the following field to the 'muc#roominfo' data form:

    + + + http://jabber.org/protocol/muc#roominfo + XEP-XXXX + Form extension for avatar support in a Multi-User Chat (MUC) room. + + +]]> + +     +     + +

    Thanks to the Ejabberd developers for their MUC vCard tutorial, and to Sam Whited and Matthew Wild for their feedback.

    +     +     diff --git a/xep.ent b/xep.ent index 815ec32b2..5ddaf28e4 100644 --- a/xep.ent +++ b/xep.ent @@ -1688,4 +1688,7 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates SASL Upgrade Tasks (XEP-0480)XEP-0480: SASL Upgrade Tasks <https://xmpp.org/extensions/xep-0480.html>."> Content Types in Messages (XEP-0481)XEP-0481: Content Types in Messages <https://xmpp.org/extensions/xep-0481.html>."> Call Invites (XEP-0482)XEP-0482: Call Invites <https://xmpp.org/extensions/xep-0482.html>."> -HTTP Online Meetings (XEP-0483)XEP-0483: HTTP Online Meetings <https://xmpp.org/extensions/xep-0483.html>.">Fast Authentication Streamlining Tokens (XEP-0484)XEP-0484: Fast Authentication Streamlining Tokens <https://xmpp.org/extensions/xep-0484.html>."> \ No newline at end of file +HTTP Online Meetings (XEP-0483)XEP-0483: HTTP Online Meetings <https://xmpp.org/extensions/xep-0483.html>."> +Fast Authentication Streamlining Tokens (XEP-0484)XEP-0484: Fast Authentication Streamlining Tokens <https://xmpp.org/extensions/xep-0484.html>."> +PubSub Server Information (XEP-0485)XEP-0485: PubSub Server Information <https://xmpp.org/extensions/xep-0485.html>."> +MUC Avatars (XEP-0486)XEP-0486: MUC Avatars <https://xmpp.org/extensions/xep-0486.html>."> From 810f594d43f60aa02f88185403fcf431b71b97ce Mon Sep 17 00:00:00 2001 From: mathieui Date: Sun, 4 Feb 2024 17:31:09 +0100 Subject: [PATCH 028/145] xep-template: Require accessibility and privacy sections The Privacy section is a new one, and Accessibility was previously optional. Rationale for the new section: it makes sense to distinguish between security and privacy, even if there is an overlap. Rationale for requiring both: not making accessibility and privacy part of the core things required for a XEP is bad in this day and age, even if I expect that most XEPs will not have much applicable on those topics. It will make sure the authors have to consider those aspects before submitting. --- xep-template.xml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xep-template.xml b/xep-template.xml index 178f92837..7b45b0358 100644 --- a/xep-template.xml +++ b/xep-template.xml @@ -57,7 +57,7 @@

    OPTIONAL.

     -

    OPTIONAL.

    +

    REQUIRED.

    OPTIONAL.

    @@ -65,6 +65,9 @@

    REQUIRED.

     + +

    REQUIRED.

    +

    REQUIRED.

     From e338522e62f6a2b08ea9efdf049cced6d2021448 Mon Sep 17 00:00:00 2001 From: Travis Burtrum Date: Sun, 10 Mar 2024 04:24:40 -0400 Subject: [PATCH 029/145] host-meta-2: Implement feedback and add rationale --- inbox/host-meta-2.xml | 50 ++++++++++++++++++++++++++++++++++++++++--- xep.ent | 3 ++- 2 files changed, 49 insertions(+), 4 deletions(-) diff --git a/inbox/host-meta-2.xml b/inbox/host-meta-2.xml index 961311330..edd9e2326 100644 --- a/inbox/host-meta-2.xml +++ b/inbox/host-meta-2.xml @@ -35,9 +35,9 @@

    Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method (for which &xep0206; is the XMPP profile), the websocket - subprotocol specified in &rfc7395;, &xep0368;, &xep0467;, and &xep0468;, and surely others that don't yet exist. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTPS URL of a BOSH or WebSocket request. Without ways to auto-discover these parameters, the relevant information would need to be provided manually by a human user (which is cumbersome and error-prone) or hard-coded into XMPP software applications (which is brittle and not interoperable + subprotocol specified in &rfc7395;, &xep0368;, &xep0467;, and &xep0468;, and surely others that don't yet exist. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTPS URL of a BOSH or WebSocket request. Without ways to auto-discover these parameters, the relevant information would need to be provided manually by a human user (which is cumbersome and error-prone) or hard-coded into XMPP software applications (which is brittle and not interoperable) ).

    -

    Additional things also require automatic discovery, like &rfc7711; (replaced here by pinning public keys instead like &rfc7469;), &tls-ech;, SNI names, and ALPN protocols. The web solves these problems in HTTP3 by introducing another set of DNS records (SVCB and HTTPS) but that poses a problem for XMPP because we don't have the clout to introduce our own DNS records and hope for any sort of adoption with the myriad DNS setup panels most people use. Additionally while we all hope and pray for DNSSEC (and DANE), many TLDs don't yet support it, and we can't trust this info over plaintext (note the web doesn't trust it over plaintext either, DNS-over-TLS is a requirement for ECH).

    +

    Additional things also require automatic discovery, like &rfc7711; (replaced here by pinning public keys instead like &rfc7469;), &tls-ech;, SNI names, and ALPN protocols.

    This document defines a way to encapsulate information about all these connection methods and parameters for auto-discovery via Link entries in a server's "host-meta.json" file. It also provides a flag to signal to the client or server that all info is here and no other methods need be used.

    @@ -181,6 +181,7 @@

    For the forseeable future you will need to maintain legacy SRV records in addition to this file, and you should provide DANE TLSA records too if possible.

    To make your server as accessible to other clients/servers no matter how bad the network they are on, it is advised to use port 443 when possible, as it looks the most like HTTPS.

    +

    Extra care must be taken in updating "public-key-pins-sha-256" similar to that which is required of HPKP and DANE, summarized here, you MUST add the new key to the file, continue using the old key until least 2 TTL periods have passed, and only then remove the old key from the file and start using the new key.

    To make connection discovery work in web clients (including those hosted on a different domain) the host service SHOULD set appropriate CORS headers for Web Host Metadata files. The exact headers and values are out of scope of this document but may include: Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers.

    Due care has to be exercised in limiting the scope of Access-Control-Allow-Origin response header to Web Host Metadata files only.

    Keep in mind this json file is defined in an RFC and we need to keep backwards compatibility with it, software only implementing XEP-0156 should be able to read and use this file as extended by this XEP only seeing the websocket/bosh connections.

         + + +

    At the time of this writing, connecting to an XMPP server requires at least 5 seperate fetches of data, and doesn't support half the things this XEP does. I don't find adding more fetches a sustainable path forward, hence definining one extensible method for all things going forward.

    +

    Here I will go through alternative solutions that were explored and explain their deficiencies and why they were not chosen.

    + +
      +
    • SRV records cannot hold the additional parameters needed and are not extensible.
      • +
    • The web solves these problems in HTTP3 by introducing another set of DNS records (&rfc9460;) but that poses a problem for XMPP because we don't have the clout to introduce our own DNS records and hope for any sort of adoption with the myriad of DNS setup panels most people use.
      • +
    • We could register our own SvcParamKeys and use SVCB records, but that suffers the same problem as above.
      • +
    • Perhaps most importantly, while we all hope and pray for DNSSEC (and DANE), many TLDs don't yet support it, and we can't trust this info (pinned keys or secure delegation) without cryptographic authenticity.
      • +
    • Some of these parameters not even the web trusts over plaintext, DNS-over-TLS/HTTPS is a requirement for ECH.
      • +
    • TXT records can hold arbitrary data, but the authenticity/privacy problems above persist, practical size limits make this a non-starter, and writing a custom parser isn't great from a security perspective.
      • +
    +     + +
      +
    • XMPP uses XML right? So we already have a XML parser to use! Actually no, XMPP uses a (very) strict subset of XML, and an XML parser properly configured to parse XMPP *will not* parse host-meta.xml. Some more security conscious XML parsers are explicitly built for XMPP and cannot be configured to parse host-meta.xml. It is *dangerous* from a security perspective to have an XML parser capable of parsing host-meta.xml anywhere in your client/server, see CVE-2022-0217.
      • +
    • Extending host-meta.xml the ideal way where things that can only have 1 value per link and should be an attribute (like port) would require namespaced attributes which are not widely supported or currently used at all in XMPP (though legal).
      • +
    • It would also require dummy values in Link like href='DUMMY' or so when a port is set. Or introducing another tag... Regardless it won't be very clean, and I consider the first issue a complete deal breaker.
      • +
    +     + +
      +
    • A major design goal here is enabling 1 single fetch to get everything needed to connect to a server. This file already exists and is already being grabbed by clients, since we can extend it without breaking compatibility with those clients, this doesn't introduce another network fetch.
      • +
    • &rfc7711; already exists for clients and servers and uses JSON, same parser can be used.
      • +
    • As stated in the section above, I find a JSON parser much less of a potential security vulnerability to have available than an XML parser capable of parsing host-meta.xml
      • +
    +     + +
      +
    • SNI fixes a fundamental problem we have with current methods of secure delegation (XEP-0156 and DNSSEC signed SRV records), in that these enable certificate validation to allow a certificate if it contains either one of two names, the service name *or* the target name. But you can only send one name with SNI, and nothing indicates which to send! If you send the wrong one the connection will fail, this necessitates sending one and, if it fails, sending the other, which is of course less than ideal.
      • +
    • ECH allows encrypting SNI+ALPN on the wire and so is invaluable for privacy.
      • +
    • Pinned public keys are a better replacement for POSH (they don't need changed on certificate renewal which commonly happens every 60 days now), and an alternative to DANE which can't be used where DNSSEC is not available.
      • +
    +     + +
      +
    • host-meta.json has an 'expires' key defined already, why 'ttl' instead? I was almost convinced to use this until I realized this means that the file needs served by a program that can update 'expires' dynamically on fetch, or at least on a schedule, and that is far more complicated and therefore less preferable than a simple ttl that never needs updated allowing clients to keep track of their own expiry.
      • +
    • What would be the next best option? Well I think a new file over https/.well-known that is in an XMPP-subset-of-XML format and so can safely share the same parser. It would be similar to HACX which was rejected with the direction to look into extending &xep0156;, which this is doing.
      • +
    +     +     +

    It should be noted this allows your web host to hijack your XMPP connection, but that's actually been true for quite some time, they could already bypass the need for a certificate with POSH, or get one from LetsEncrypt if you didn't have the proper CAA records, or hijack it for websocket/bosh supporting clients, so this doesn't really open up new avenues of attack.

    -

    Please refer to the security considerations and warnings of &rfc7469; with regards to having a backup public key and being careful to not break your domain for the whole TTL

    +

    Please refer to the security considerations and warnings of &rfc7469; with regards to having a backup public key and being careful to not break your domain for the whole TTL. For this reason and others it is advised to put a max limit on TTL of 1 week (604800).

    Validating certs is full of edge cases and must be done with the utmost of care and precision.

     diff --git a/xep.ent b/xep.ent index 5ddaf28e4..f65aac5eb 100644 --- a/xep.ent +++ b/xep.ent @@ -710,6 +710,7 @@ THE SOFTWARE. RFC 7677 RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms <http://tools.ietf.org/html/rfc7677>." > RFC 5705 RFC 5705: Keying Material Exporters for Transport Layer Security (TLS) <http://tools.ietf.org/html/rfc5705>." > RFC 9266 RFC 9266: Channel Bindings for TLS 1.3 <http://tools.ietf.org/html/rfc9266>." > +RFC 9460 RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) <http://tools.ietf.org/html/rfc9460>." > @@ -1691,4 +1692,4 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates HTTP Online Meetings (XEP-0483)XEP-0483: HTTP Online Meetings <https://xmpp.org/extensions/xep-0483.html>."> Fast Authentication Streamlining Tokens (XEP-0484)XEP-0484: Fast Authentication Streamlining Tokens <https://xmpp.org/extensions/xep-0484.html>."> PubSub Server Information (XEP-0485)XEP-0485: PubSub Server Information <https://xmpp.org/extensions/xep-0485.html>."> -MUC Avatars (XEP-0486)XEP-0486: MUC Avatars <https://xmpp.org/extensions/xep-0486.html>."> +MUC Avatars (XEP-0486)XEP-0486: MUC Avatars <https://xmpp.org/extensions/xep-0486.html>."> \ No newline at end of file From d142d59064e40ab585184e8e6f47d44f05dad9ac Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 10 Mar 2024 09:30:20 +0100 Subject: [PATCH 030/145] Move 'XEP-0487: Host Meta 2 - One Method To Rule Them All' to Experimental --- xep-0487.xml | 274 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 4 +- 2 files changed, 277 insertions(+), 1 deletion(-) create mode 100644 xep-0487.xml diff --git a/xep-0487.xml b/xep-0487.xml new file mode 100644 index 000000000..8535f5e61 --- /dev/null +++ b/xep-0487.xml @@ -0,0 +1,274 @@ + + +%ents; +]> + + +
    + Host Meta 2 - One Method To Rule Them All + This document defines an XMPP Extension Protocol for extending XEP-0156 by modifying the JSON Web Host Metadata Link format to support discovering all possible XMPP connection methods, for c2s and s2s + &LEGALNOTICE; + 0487 + Experimental + Standards Track + Standards + Council + + XMPP Core + RFC 1464 + + + XEP-0156 + RFC 7711 + + + connections-v2 + + &moparisthebest; + + 0.1.0 + 2024-03-10 + XEP Editor: dg + +
      +
    • Promoted to Experimental
      • +
    +     +     + + 0.0.1 + 2023-11-19 + tjb +

    First draft.

     +     +
    + +

    Although &xmppcore; specifies the use of TCP as the method of connecting to an XMPP server, alternative connection methods exist, including the &xep0124; method (for which &xep0206; is the XMPP profile), the websocket + subprotocol specified in &rfc7395;, &xep0368;, &xep0467;, and &xep0468;, and surely others that don't yet exist. For some of these methods, it is necessary to discover further parameters before connecting, such as the HTTPS URL of a BOSH or WebSocket request. Without ways to auto-discover these parameters, the relevant information would need to be provided manually by a human user (which is cumbersome and error-prone) or hard-coded into XMPP software applications (which is brittle and not interoperable) +).

    +

    Additional things also require automatic discovery, like &rfc7711; (replaced here by pinning public keys instead like &rfc7469;), &tls-ech;, SNI names, and ALPN protocols.

    +

    This document defines a way to encapsulate information about all these connection methods and parameters for auto-discovery via Link entries in a server's "host-meta.json" file. It also provides a flag to signal to the client or server that all info is here and no other methods need be used. +

    +     + + + + +

    The HTTPS lookup method uses Web Host Metadata &rfc6415; to categorize and list the URIs of alternative connection methods. It is intended to replace all current methods for looking up connection information by "native" clients and servers, as well as be used by web browsers.

    +

    Each alternative connection method is specified in the host-meta.json (JRD) file using a distinctive link relation &rfc5988;. This specification defines several extension relation types, here links are provided to their respective transport definitions:

    +
      +
    • urn:xmpp:alt-connections:tls - c2s Direct TLS - &xep0368;
      • +
    • urn:xmpp:alt-connections:quic - c2s Quic - &xep0467;
      • +
    • urn:xmpp:alt-connections:s2s-websocket - s2s WebSocket - &xep0468;
      • +
    • urn:xmpp:alt-connections:s2s-tls - s2s Direct TLS - &xep0368;
      • +
    • urn:xmpp:alt-connections:s2s-quic - s2s Quic - &xep0467;
      • +
    +

    And additionally re-uses some defined in &xep0156;:

    +
      +
    • urn:xmpp:alt-connections:websocket - c2s WebSocket - &rfc7395;
      • +
    • urn:xmpp:alt-connections:xbosh - c2s BOSH - &xep0206;
      • +
    +

    Additionally a top level "xmpp" object is defined, which currently has the following subfields defined:

    +
      +
    • "ttl" - integer - MANDATORY - seconds this document can be cached for
      • +
    • "public-key-pins-sha-256" - list of strings - OPTIONAL - base64 sha256 hashes of public keys to trust, use as defined in &rfc7469;
      • +
    +

    The following are new fields defined in each link object:

    +
      +
    • "priority" and "weight" - integers - MANDATORY - Use as defined in &rfc2782;
      • +
    • "sni" - string - MANDATORY - name to send in the TLS/QUIC SNI extension
      • +
    • "ech" - string - OPTIONAL - Use as defined in &tls-ech;
      • +
    • "ips" - list of strings - at least one MANDATORY - IPv4 or IPv6 addresses only, connect to these
      • +
    +

    The "href" field in websocket/bosh links remains unchanged from XEP-0156, but is replaced by "port" (integer) in Direct TLS/Quic connections.

    +     + + +

    The following business rules apply:

    +
      +
    1. host-meta files MUST be fetched only over HTTPS, and MUST only use secure connections (TLS or equivalent). + This provides secure delegation, meaning you MUST send the provided SNI and validate that the certificate + is valid for that host *or* the XMPP domain (or the public key hash is pinned).
      2. +
    2. host-meta responses with the top level "xmpp" object mean this XEP is in use and legacy SRV/POSH/etc lookups SHOULD be skipped, alternatively if the top level "xmpp" object does not exist, XEP-0156 rules apply instead.
      3. +
    3. Client/Server implementations SHOULD consider weight/priority as presumably the server admin has thought about which links can handle load best etc, but MAY prioritize certain protocols over others, for example a privacy client may want to use websocket to look most like HTTPS, or a mobile client might prefer Quic for connection roaming. Regardless server operators MUST NOT count on any ordering, a client can connect to any of these under even normal circumstances.
      4. +
    +     + + +

    It is possible to use additionally a JSON-based format for host-meta information. The JSON representation of the host metadata is named JRD and specified in Appendix A of &rfc6415;. The above XRD example would be presented in JRD as:

    + +     +     + + +

    For the forseeable future you will need to maintain legacy SRV records in addition to this file, and you should provide DANE TLSA records too if possible.

    +

    To make your server as accessible to other clients/servers no matter how bad the network they are on, it is advised to use port 443 when possible, as it looks the most like HTTPS.

    +

    Extra care must be taken in updating "public-key-pins-sha-256" similar to that which is required of HPKP and DANE, summarized here, you MUST add the new key to the file, continue using the old key until least 2 TTL periods have passed, and only then remove the old key from the file and start using the new key.

    +

    To make connection discovery work in web clients (including those hosted on a different domain) the host service SHOULD set appropriate CORS headers for Web Host Metadata files. The exact headers and values are out of scope of this document but may include: Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers.

    +

    Due care has to be exercised in limiting the scope of Access-Control-Allow-Origin response header to Web Host Metadata files only.

    + +

    Access-Control-Allow-Origin header with a value of * allows JavaScript code running on a different domain to read the content of Web Host Metadata files. Special value * ensures that the request will only succeed if it is invoked without user credentials (e.g. cookies, HTTP authentication).

    +     + +

    + As an author of a client or server, you presumably have users, and those users have a single desire, to communicate over XMPP. + This means that they want to connect at any costs, they *do not* want to see the first error to appear and have all further attempts aborted until it's fixed. + With this problem statement, here is a list of current best practices to make this happen: +

    +
      +
    • "ttl" is a guideline for when you SHOULD try to fetch a newer copy, if you can't, you MUST try to fetch connection info other ways, and also fall back to expired data if needed
      • +
    • When trying a particular connection with a list of IPs, you can try them all in order, or pick a random one like DNS would do, but if you do, you MUST keep track of the ones you tried, and try all the rest later if your connection wasn't succesful
      • +
    • An application MUST keep trying every possible connection until they have both an authenticated stream (the TLS certificate is valid) and have seen a valid XMPP stream element for the server you are trying to connect to. You may get an authenticated stream and an HTTP or IMAP or SMTP error, or even an XMPP stream header for another server, you MUST keep going until both of these are satisified.
      • +
    +     + +

    Keep in mind this json file is defined in an RFC and we need to keep backwards compatibility with it, software only implementing XEP-0156 should be able to read and use this file as extended by this XEP only seeing the websocket/bosh connections.

    +     +     + + +

    At the time of this writing, connecting to an XMPP server requires at least 5 seperate fetches of data, and doesn't support half the things this XEP does. I don't find adding more fetches a sustainable path forward, hence definining one extensible method for all things going forward.

    +

    Here I will go through alternative solutions that were explored and explain their deficiencies and why they were not chosen.

    + +
      +
    • SRV records cannot hold the additional parameters needed and are not extensible.
      • +
    • The web solves these problems in HTTP3 by introducing another set of DNS records (&rfc9460;) but that poses a problem for XMPP because we don't have the clout to introduce our own DNS records and hope for any sort of adoption with the myriad of DNS setup panels most people use.
      • +
    • We could register our own SvcParamKeys and use SVCB records, but that suffers the same problem as above.
      • +
    • Perhaps most importantly, while we all hope and pray for DNSSEC (and DANE), many TLDs don't yet support it, and we can't trust this info (pinned keys or secure delegation) without cryptographic authenticity.
      • +
    • Some of these parameters not even the web trusts over plaintext, DNS-over-TLS/HTTPS is a requirement for ECH.
      • +
    • TXT records can hold arbitrary data, but the authenticity/privacy problems above persist, practical size limits make this a non-starter, and writing a custom parser isn't great from a security perspective.
      • +
    +     + +
      +
    • XMPP uses XML right? So we already have a XML parser to use! Actually no, XMPP uses a (very) strict subset of XML, and an XML parser properly configured to parse XMPP *will not* parse host-meta.xml. Some more security conscious XML parsers are explicitly built for XMPP and cannot be configured to parse host-meta.xml. It is *dangerous* from a security perspective to have an XML parser capable of parsing host-meta.xml anywhere in your client/server, see CVE-2022-0217.
      • +
    • Extending host-meta.xml the ideal way where things that can only have 1 value per link and should be an attribute (like port) would require namespaced attributes which are not widely supported or currently used at all in XMPP (though legal).
      • +
    • It would also require dummy values in Link like href='DUMMY' or so when a port is set. Or introducing another tag... Regardless it won't be very clean, and I consider the first issue a complete deal breaker.
      • +
    +     + +
      +
    • A major design goal here is enabling 1 single fetch to get everything needed to connect to a server. This file already exists and is already being grabbed by clients, since we can extend it without breaking compatibility with those clients, this doesn't introduce another network fetch.
      • +
    • &rfc7711; already exists for clients and servers and uses JSON, same parser can be used.
      • +
    • As stated in the section above, I find a JSON parser much less of a potential security vulnerability to have available than an XML parser capable of parsing host-meta.xml
      • +
    +     + +
      +
    • SNI fixes a fundamental problem we have with current methods of secure delegation (XEP-0156 and DNSSEC signed SRV records), in that these enable certificate validation to allow a certificate if it contains either one of two names, the service name *or* the target name. But you can only send one name with SNI, and nothing indicates which to send! If you send the wrong one the connection will fail, this necessitates sending one and, if it fails, sending the other, which is of course less than ideal.
      • +
    • ECH allows encrypting SNI+ALPN on the wire and so is invaluable for privacy.
      • +
    • Pinned public keys are a better replacement for POSH (they don't need changed on certificate renewal which commonly happens every 60 days now), and an alternative to DANE which can't be used where DNSSEC is not available.
      • +
    +     + +
      +
    • host-meta.json has an 'expires' key defined already, why 'ttl' instead? I was almost convinced to use this until I realized this means that the file needs served by a program that can update 'expires' dynamically on fetch, or at least on a schedule, and that is far more complicated and therefore less preferable than a simple ttl that never needs updated allowing clients to keep track of their own expiry.
      • +
    • What would be the next best option? Well I think a new file over https/.well-known that is in an XMPP-subset-of-XML format and so can safely share the same parser. It would be similar to HACX which was rejected with the direction to look into extending &xep0156;, which this is doing.
      • +
    +     +     + + +

    It should be noted this allows your web host to hijack your XMPP connection, but that's actually been true for quite some time, they could already bypass the need for a certificate with POSH, or get one from LetsEncrypt if you didn't have the proper CAA records, or hijack it for websocket/bosh supporting clients, so this doesn't really open up new avenues of attack.

    +

    Please refer to the security considerations and warnings of &rfc7469; with regards to having a backup public key and being careful to not break your domain for the whole TTL. For this reason and others it is advised to put a max limit on TTL of 1 week (604800).

    +

    Validating certs is full of edge cases and must be done with the utmost of care and precision.

    +     + + +

    This document requires no interaction with &IANA;.

    +     + + +

    This document requires no interaction with the ®ISTRAR;.

    +     +     diff --git a/xep.ent b/xep.ent index f65aac5eb..290a5924c 100644 --- a/xep.ent +++ b/xep.ent @@ -1692,4 +1692,6 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates HTTP Online Meetings (XEP-0483)XEP-0483: HTTP Online Meetings <https://xmpp.org/extensions/xep-0483.html>."> Fast Authentication Streamlining Tokens (XEP-0484)XEP-0484: Fast Authentication Streamlining Tokens <https://xmpp.org/extensions/xep-0484.html>."> PubSub Server Information (XEP-0485)XEP-0485: PubSub Server Information <https://xmpp.org/extensions/xep-0485.html>."> -MUC Avatars (XEP-0486)XEP-0486: MUC Avatars <https://xmpp.org/extensions/xep-0486.html>."> \ No newline at end of file +MUC Avatars (XEP-0486)XEP-0486: MUC Avatars <https://xmpp.org/extensions/xep-0486.html>."> +Host Meta 2 - One Method To Rule Them All (XEP-0487)XEP-0487: Host Meta 2 - One Method To Rule Them All <https://xmpp.org/extensions/xep-0487.html>."> + From 893382ca144e59690b606ae9e68b57adf3149ed5 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 10 Mar 2024 13:06:10 +0100 Subject: [PATCH 031/145] XEP-0398: explain copy vs inject on access --- xep-0398.xml | 37 ++++++++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/xep-0398.xml b/xep-0398.xml index c24bb5a8d..d03564bdf 100644 --- a/xep-0398.xml +++ b/xep-0398.xml @@ -10,7 +10,7 @@ This specification describes a method for using PEP based avatars and vCard based avatars in parallel by having the user’s server do a conversion between the two. &LEGALNOTICE; 0398 - Deferred + Experimental 2020-02-26 Standards Track Standards @@ -29,6 +29,17 @@ daniel@gultsch.de daniel@gultsch.de + + 0.3.0 + 2024-03-08 + dg + +
      +
    • Add text to explain that both copy on publication and inject PEP avatar into vCard response are valid implementations.
      • +
    • Add Security Considerations for both variants
      • +
    +     +     0.2.1 2018-08-27 @@ -53,7 +64,7 @@

    Server implementations can aid to resolve this conflict by automatically putting avatars uploaded with XEP-0084 into XEP-0153 storage and vice versa. This allows clients to use the more efficient XEP-0084 for uploading avatars and XEP-0153 to retrieve avatars in Multi-User Chats.

     -

    The conversion is transparent to the uploading entity. However an entity might want to discover if a service will be performing the conversion from XEP-0084 to XEP-0153 since using vCard-Based Avatars will make the uploaded avatar publicly available. (See the “Security Considerations” section of this XEP.)

    +

    The conversion is transparent to the uploading entity. However an entity might want to discover if a service will be performing the conversion from XEP-0084 to XEP-0153 so it doesn’t have to maintain a vCard avatar itself.

    The service MUST include a &xep0030; feature of "urn:xmpp:pep-vcard-conversion:0" on the account.

    The hash MUST also be injected into directed presences such as MUC joins

     -

    Implementing clients SHOULD use the more efficient XEP-0084 to access their own avatar storage and implement XEP-0153 only to download avatars from other entities if they do not have mutual presence subscription with said entity. (For example participants in a Multi-User Chat.)

    -

    Services will inject the hash in directed presences automatically but will not resend the presence if the avatar gets updated. Thus clients MAY resend directed available presence to all Multi-User Chats after receiving a 'urn:xmpp:avatar:metadata' update notification. The service will then inject an updated version of the hash. To avoid sending unnecassary presence updates, resending should only occur if the service annouces the 'urn:xmpp:pep-vcard-conversion:0' feature.

    + +

    Implementing clients SHOULD use the more efficient XEP-0084 to access their own avatar storage and implement XEP-0153 only to download avatars from other entities if they do not have mutual presence subscription with said entity. (For example participants in a Multi-User Chat.)

    +

    Services will inject the hash in directed presences automatically but will not resend the presence if the avatar gets updated. Thus clients MAY resend directed available presence to all Multi-User Chats after receiving a 'urn:xmpp:avatar:metadata' update notification. The service will then inject an updated version of the hash. To avoid sending unnecassary presence updates, resending should only occur if the service annouces the 'urn:xmpp:pep-vcard-conversion:0' feature.

    +     + +

    While this specification is worded in a way that implies PEP and vCard are two different storages and a publication to one copies the avatar to another an alternative implementation, that also satisfies the requirements, is one that dynamically injects the PEP avatar into the vCard upon request. If this approach is taken services SHOULD check if the requestor of the vCard has access to the PEP nodes.

    +     +     + +

    This specification has no accessibility considerations beyond those introduced by &xep0084;.

     -

    XEP-0084 has a default access model that only allows entities with mutual presence subscription to access the published avatar. XEP-0153 has no access control at all. Clients that discover the disco feature 'urn:xmpp:pep-vcard-conversion:0' on the account MAY warn users that uploading an avatar will make that avatar accessible to anyone who knows the Jabber ID.

    -

    In the future services MAY decide to perform PEP to vCard conversion only if the access model of the 'urn:xmpp:avatar:data' node has been set to 'open' as described in &xep0060;. However the ability to change the access model of nodes isn’t widely implemented yet and thus this paragraph exists only to act as a reminder that the privacy implications described in the previous paragraph can be avoided

    +

    Services that copy the avatar from PEP to vCard upon publication SHOULD perform conversion only if the access model of the 'urn:xmpp:avatar:data' node has been set to 'open' as described in &xep0060;.

    +

    Services that dynamically inject the PEP avatar into a vCard response SHOULD check if the entity that requested the vCard has access to both PEP nodes. This can be the case if the access model has been set top 'open' or if the requesting entity has a presence subscription of the owner.

    +     + +

    World readable avatars (access model open) will be made available through semi-anonymous MUCs and can be used to de-anonymize users.

    This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

    @@ -123,9 +145,6 @@
  • urn:xmpp:pep-vcard-conversion:0
    •  - -

    tbd

    -

    Special thanks to Evgeny Khramtsov who implemented what is now written down as a XEP in ejabberd and created the inspiration for this XEP.

     From 099ff885b6edc20609b7c9bb0fd8f7b9faba4b25 Mon Sep 17 00:00:00 2001 From: Marvin W Date: Sun, 25 Jun 2023 10:03:26 +0200 Subject: [PATCH 032/145] XEP-0447 v0.3.0 Describe how to use for multiple files, with body text, without any source in original message and compatibility with various current deployed protocols. --- xep-0447.xml | 230 +++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 206 insertions(+), 24 deletions(-) diff --git a/xep-0447.xml b/xep-0447.xml index 18f7139ba..b11ffa25d 100644 --- a/xep-0447.xml +++ b/xep-0447.xml @@ -23,6 +23,12 @@ sfs &larma; + + 0.3.0 + 2023-06-24 + lmw + Describe how to use for multiple files, with body text, without any source in original message and compatibility with various current deployed protocols. + 0.2.0 2022-08-03 @@ -60,7 +66,7 @@

    • No focus on media, generic for every file type.
      • -
    • No mixed content, body is used for fallback only and not to transmit additional information.
      • +
    • Body can be used for fallback.
    • Using &xep0446;.
    • Using XML for structured data instead of URIs when possible, adding further extensibility (like providing proper means of sharing encrypted files on http servers).
    • Not relying on underspecified usage of &xep0372;.
      • @@ -76,25 +82,25 @@
    • Enable aggresive caching
    • Provide users with metadata, e.g. file size, file type or thumbnail, to help them decide whether or not they want to load the file
    • Support referring to third party hosting services
      • -
    • Backwards compatibility with existing, widely-deployed protocols
      • +
    • Backwards compatibility with existing protocols
    - +

    To share a file, a user sends a message stanza including <file-sharing/> to the inteded recipient contact or group. - The <file-sharing/> element MAY have a disposition attribute with a value of either attachment or inline. - The <file-sharing/> element includes a <file/> metadata element as described in &xep0446; as well as a <sources/> element. + The <file-sharing/> element MAY have a disposition attribute with a value of either attachment or inline and MAY have an id attribute. + The <file-sharing/> element includes a <file/> metadata element as described in &xep0446; and MAY include a <sources/> element. The <sources/> element provides one or multiple sources that the receiving client may use to obtain the file.

    - + image/jpeg summit.jpg 3032449 - 4096x2160 + 4096 + 2160 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= 2AfMGH8O7UNPTvUVAM9aK13mpCY= Photo from the summit. @@ -107,35 +113,32 @@ - -]]> +]]>

    It is RECOMMENDED that the file metadata specifies name, media-type, size and one or multiple hash elements as described in &xep0300;. The hash elements provide end-to-end file integrity and allow efficient caching and flexible retrieval methods.

    The message MAY include a suitable fallback body. + When doing so, an appropriate &xep0428; <fallback/> indicator with for set to urn:xmpp:sfs:0 MUST be added. The fallback body MUST NOT include any information that is not also represented in <file-sharing/>. If the <sources/> element includes an <url-data/> element that can be represented as a single URL, adding a &xep0066; x-oob reference is RECOMMENDED for compatibility.

    - + - Photo from the summit: https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg + + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg - -]]> +]]>

    If the message has an empty body, it is RECOMMENDED to add a message processing hint, see &xep0334;, to indicate the message to be stored in message stores like &xep0313;.

    - + - -]]> +]]>

    @@ -145,6 +148,7 @@

    If the file is not available locally, the file can be obtained by one of the sources listed in the <sources/> element. If further sources have been attached (as described in Attaching a source), the receiving entity may also try to obtain the file from any of those. + If no <sources/> element is included with the message containing the <file-sharing/> element, the receiving entity SHOULD consider the file transfer pending and expect an attached source later.

    The receiving entity SHOULD NOT fetch the file without prior user interaction if the disposition attribute is set to attachment. @@ -176,17 +180,19 @@

    TODO: The following section relies on &xep0367;, however other methods to attach information to another message like the recently proposed &xep0422; might be suitable here as well. This is to be clarified before advancing to Draft.

    - After a user shared a file using one entity and another entity in the conversation obtained it or found it in its local storage, that entity MAY announce that the file is now available with an additional source. + After a user shared a file using one entity and another entity in the conversation obtained it, found it in its local storage or knows a remote location that provides the same file, that entity MAY announce that the file is now available with an additional source. This increases availability of the file in case the sender goes offline before all the intended recipients were able to fetch the file. It also allows for peer-to-peer file distribution in group chats.

    The entity MUST NOT announce itself as an additional source before verifying that all hashes provided match the hash of the file. If no hashes are provided, the entity SHOULD NOT announce itself as an additional source.

    -

    The attaching itself is performed by sending a message including a <sources> element with further sources using the protocol described in &xep0367;.

    +

    + The attaching itself is performed by sending a message including a <sources> element with further sources using the protocol described in &xep0367;. + If the <file-sharing/> element to attach to had an id attribute, the <sources> element MUST also have an id attribute with the same value. +

    Depending on the lifetime of the newly attached source, it may be useful to add a message processing hint, see &xep0334;, to indicate the message to be stored in message stores like &xep0313;.

    - + @@ -194,8 +200,183 @@ +]]> +

    + If the file was originally shared without a <sources/> element, the sending entity SHOULD attach a file source at a later point. + For example, the sending entity may send a message with a <file-sharing/> element without a <sources/> element, when it starts uploading a file to the server (using &xep0363;) and then attach the http source as soon as the upload is finished. +

    +

    + If the file was originally shared without a suitable fallback body, e.g. because the file was not yet uploaded at the time, the source attaching message MAY include a suitable fallback body. + When doing so, an appropriate &xep0428; <fallback/> indicator with for set to urn:xmpp:sfs:0 MUST be added. + The fallback body MUST NOT include any information that is not also represented in <sources/>. + If the <sources/> element includes an <url-data/> element that can be represented as a single URL, adding a &xep0066; x-oob reference is RECOMMENDED for compatibility. +

    + + + + image/jpeg + summit.jpg + 3032449 + 4096 + 2160 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + 2AfMGH8O7UNPTvUVAM9aK13mpCY= + Photo from the summit. + + + + + + + + + + + + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg +]]> +     +     + + +

    + When sharing files, the sending entity MAY want to include an additional textual message with the file share. + To do so, the sending entity SHOULD add such textual message in the body of the message that contains the <file-sharing/> element. +

    +

    + If a <file-sharing/> message includes a textual body, it MAY also include a fallback in that body, that MUST be annotated using an appropriate &xep0428; <fallback/> indicator with for set to urn:xmpp:sfs:0. + However, in this case it is RECOMMENDED to use a source attaching message with a fallback body. This allows to send messages in a way that is still understood well by legacy clients. +

    + + Summit was great, check out this cool photo of everyone. + + + image/jpeg + summit.jpg + 3032449 + 4096 + 2160 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + 2AfMGH8O7UNPTvUVAM9aK13mpCY= + Photo from the summit. + + + + + + + + + + + + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg +]]> +     + +

    + When sharing files, the sending entity MAY want to share multiple files within a single message. + To do so, the sending entity SHOULD add multiple <file-sharing/> elements in a single message. + It MUST add an id attribute with differing values to each of these <file-sharing/> elements. +

    +

    + When sharing multiple files, it is RECOMMENDED to attach the sources of each file in an individual message. + When doing so, it is RECOMMENDED to include appropriate fallbacks to the source attaching messages. This allows to send multiple files in a way that is still understood well by legacy clients. +

    + + + + photo1.jpg + + + + + photo2.jpg + + + + + photo3.jpg + + + + + + + + + + + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo1.jpg + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo1.jpg + + + + + + + + + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo2.jpg + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo2.jpg -]]> + + + + + + + + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo3.jpg + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/photo3.jpg +]]>     + + +

    + When sharing media, the sending entity may want to be compatible with &xep0385; as far as applicable. + To do so, the &xep0385; <media-sharing/> element can be added inside an &xep0372; <reference xmlns='urn:xmpp:reference:0' type='data'> element in the same message that would also include the textual legacy fallback and &xep0066; x-oob reference. +

    + + + + image/jpeg + summit.jpg + 3032449 + 4096 + 2160 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + 2AfMGH8O7UNPTvUVAM9aK13mpCY= + Photo from the summit. + + + + + + + + + + + + + image/jpeg + summit.jpg + 3032449 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + 2AfMGH8O7UNPTvUVAM9aK13mpCY= + + + + + + + + + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg + https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg +]]>     @@ -231,5 +412,6 @@

    Thanks to the authors of &xep0385; which heavily inspired this XEP.

    +

    Thanks to Jérôme Poisson and others for their valuable feedback.

     From 7b14aaf5b167b1ca66d73b0150411df80985f2c9 Mon Sep 17 00:00:00 2001 From: Marvin W Date: Mon, 1 Jan 2024 21:16:32 +0100 Subject: [PATCH 033/145] XEP-0447 v0.3.1 Fix example for multiple files. --- xep-0447.xml | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/xep-0447.xml b/xep-0447.xml index b11ffa25d..b01383358 100644 --- a/xep-0447.xml +++ b/xep-0447.xml @@ -23,6 +23,12 @@ sfs &larma; + + 0.3.1 + 2024-01-01 + lmw + Fix example for multiple files. + 0.3.0 2023-06-24 @@ -305,7 +311,7 @@ - + @@ -315,7 +321,7 @@ - + @@ -325,7 +331,7 @@ - + From 5ae15e15253dc704b62a084835dec72ca9351b6a Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 10 Mar 2024 14:05:47 +0100 Subject: [PATCH 034/145] XEP-0333: Display Markers. Remove received and ack --- xep-0333.xml | 254 +++++++++++++++++---------------------------------- 1 file changed, 82 insertions(+), 172 deletions(-) diff --git a/xep-0333.xml b/xep-0333.xml index f8feb3126..f377c9758 100644 --- a/xep-0333.xml +++ b/xep-0333.xml @@ -6,11 +6,11 @@
    - Chat Markers - This specification describes a solution of marking the last received, displayed and acknowledged message in a chat. + Displayed Markers (was: Chat Markers) + This specification introduces a method to let the sender, or multiple participants in a group chat, know that a client has displayed messages up to a certain point. &LEGALNOTICE; 0333 - Deferred + Experimental 2017-03-01 2017-02-22 2017-02-11 @@ -30,6 +30,24 @@ im@spencermacdonald.com im@spencermacdonald.com + + Daniel + Gultsch + daniel@gultsch.de + daniel@gultsch.de + + + 0.5.0 + 2024-03-06 + dg + +
      +
    • Remove <received/> to not replicate &xep0184; functionality.
      • +
    • Remove <acknowledged/> because it was not implemented in the last 10 years and apparently is not needed.
      • +
    • Remove Disco feature. Opting in via <markable/> is enough
      • +
    +     +     0.4.1 2023-07-19 @@ -100,170 +118,59 @@
    -

    The concept of delivery and read receipts has been popularised by other messaging services such as iMessage, Google Hangouts and Blackberry Messenger. - These services provide a visual indication of when a message has been delivered to any of the recipients resources and (optionally) when it has been read. - These visual indications (referred to herein as "Chat Markers") are synced between all of the sender's - and recipient's resources automatically, so the state of a chat is always consistent. - If one or more of the resources is not connected, it can fetch Chat Markers from the Message Archive upon reconnecting.

    -

    &xep0184; currently provides delivery receipts on a per message basis, - but it does not provide any mechanism for the user to indicate that they have read or acknowledged the message. - As delivery receipts are sent on a per message basis it would require multiple messages to "sync up" up delivery receipts between resources.

    -

    Moreover by using &xep0085; you could infer that a message has been read by the recipient, if they become active at any point after the message has been delivered, but again it would require multiple messages to "sync up" chat states between resources.

    -

    This XEP outlines an efficient message based protocol to provide this functionally using Chat Markers.

    -

    Note: Chat Markers do not mark each individual message, nor do they assume a reliable transport. This means that Chat Markers can only provide a heuristic solution, but this is often satisfactory for the majority of use cases.

    -     - - -

    The term "active chat" refers to a chat that a user is currently active in. See &xep0085;.

    -

    The term "system notification" refers to a notification (typically a preview) that is displayed separately to a Chat.

    -

    The term "read" in the context of iMessage, Google Hangouts and Blackberry Messenger, directly maps to the displayed element in the Chat Marker namespace.

    -

    The term "markable message" refers to the stanza for which the original sender would like to receive a Chat Marker.

    -

    The term "Chat Marker" refers to the stanza by which the recipient replies to a "markable message" with a marker.

    +

    Letting the sender and/or multiple participants of a group chat know that an entity has displayed (Colloquially known as read) a message is a common feature in modern instant messaging.

    +

    &xep0184; currently provides delivery receipts on a per message basis, but it does not provide any mechanism for the user to indicate that they have read the message.

    +

    This specification defines a protocol for the sender of a message to let the recipient know they are interested in whether the recipient’s client has displayed the message and a protocol for the recipient to respond to said request. In group chats the explicit request is omitted and participants opportunistically share their displayed state with others.

    +

    Displayed Markers carry a semantic of all messages up to this point.

    +

    Note: Displayed Markers do not mark each individual message, nor do they assume a reliable transport. This means that Displayed Markers can only provide a heuristic solution, but this is often satisfactory for the majority of use cases.

     -

    This document addresses the following requirements:

    -
      -
    1. Enable a client to mark a message as markable.
      2. -
    2. Enable a client to mark the last received message in a chat.
      3. -
    3. Enable a client to mark the last displayed message in a chat.
      4. -
    4. Enable a client to mark the last acknowledged message in a chat.
      5. -
    5. Enable a client to fetch and set Chat Markers regardless of wether the other users in a chat are online.
      6. -
    -     - - -

    If an entity supports the Chat Markers protocol, it MUST report that by including a &xep0030; - feature of "urn:xmpp:chat-markers:0" in response to disco#info requests:

    - - - - -]]> - - - - - - ... - - ... - - -]]> - - -

    Support can also be determined via &xep0115;, a.k.a. "caps".

    -     - - - -

    If the sender knows only the recipient's bare JID, it cannot determine (via &xep0030; or &xep0115;) whether the intended recipient supports the Chat Markers protocol. In this case, the sender MAY send a Chat Marker or markable message.

    -     - -

    If the sender knows a full JID for the recipient (e.g., via presence), it SHOULD attempt to determine (via service disco or entity capabilities) whether the client at that full JID supports the Chat Markers protocol before attempting to send a Chat Marker or markable message.

    -

    If the sender determines that the recipient's client does not support the Chat Markers protocol then it SHOULD NOT send Chat Markers or markable messages.

    -

    If the sender determines that the recipient's client supports the Chat Markers protocol then it MAY send a Chat Marker or markable message to that full JID.

    -     - -

    To prevent looping, an entity MUST NOT send a Chat Marker to mark up to a Chat Marker.

    -     -     - - -

    Chat Markers use a dedicated protocol extension qualified by the 'urn:xmpp:chat-markers:0' namespace.

    -

    There are 4 allowable elements in the namespace, the first 'markable' indicates that a message can be marked with a Chat Marker and is therefore a "markable message".

    -

    The 3 other allowable elements in this namespace are used to mark a message (in order of significance):

      -
    • received -- the message has been received by a client.
      • -
    • displayed -- the message has been displayed to a user in a active chat and not in a system notification.
      • -
    • acknowledged -- the message has been acknowledged by some user interaction e.g. pressing an acknowledgement button.
      • +
    • Enable a client to mark the last displayed message in a chat.
      • +
    • Enable a client to fetch and set Displayed Markers regardless of whether the other users in a chat are online.
      • +
    • Do not replicate functionality of &xep0184;
      • +
    • Do not be concerned about displayed state synchronization across multiple devices of the same user
    +     -

    The Chat Marker MUST have an 'id' which is the 'id' of the message being marked.

    -

    The Chat Marker message stanza MUST have a 'thread' child element if the message has been received, displayed or acknowledged in the context of a thread.

    -

    A Chat Marker Indicates that all messages up to and including that message 'id' have been marked. If a thread is supplied, a Chat Marker is only valid in the context of that thread.

    - - - - sleeping - My lord, dispatch; read o'er these articles. + + +

    An entity interested to know if the recipient has displayed a message attaches a <markable/> element qualified by the 'urn:xmpp:chat-markers:0' namespace to the message. The message MUST possess an 'id' attribute for traceability.

    + + Hi. How are you? +     -]]> - - -

    Note: A sender MUST include an 'id' attribute on every markable message.

    - -

    If recipient does not support the Chat Markers protocol it SHOULD NOT return an error.

    - - - - sleeping - -     -]]> - -

    When the recipient sends a Chat Marker, it SHOULD ensure that the message stanza contains only the Chat Marker child element and optionally (when appropriate) a thread child element. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a <delay/> element as specified in &xep0203;.

    - - - -

    Clients SHOULD use &xep0280; to support multiple online resources.

    -

    Clients SHOULD use &xep0136; or &xep0313; to support offline updating of Chat Markers. Chat Markers SHOULD be archived, so they can be fetched and set regardless of whether the other users in a chat are online.

    -

    Messages MUST have an 'id' to use Chat Markers.

    -

    Messages MUST include the 'markable' element to use Chat Markers.

    -

    Chat Markers MUST only move forward. If a Chat Marker is received for an earlier message than the current Chat Marker, it MUST be ignored by the client. -

    -

    Chat Markers for unknown messages MUST be ignored by the client. A client MAY store the Chat Marker incase the associated message is retrieved later. -

    -     - - - -

    Less Significant Chat Markers SHOULD only be sent if they are later than the more significant Chat Marker i.e. if a Message has been marked as displayed, - a received Chat Marker should only be sent if it has a later timestamp than the displayed Chat Marker.

    -

    To avoid sending redundant Chat Markers while retrieving archived messages, Chat Markers SHOULD only be sent after retrieving the most recent message for a chat.

    -

    Only Messages that can be displayed in a chat SHOULD be markable.

    -     - -

    Clients MUST NOT mark a message as acknowledged without any user interaction.

    -     - -

    Clients MAY mark a sent or received message, as Chat Markers are inclusive of of both previously sent and received messages.

    -     - -

    Chat Markers MAY be used alongside Delivery Receipts.

    +]]>     - -

    Chat Markers MAY be used alongside Chat States.

    + +

    To let the sender know a message has been displayed an entity sends a message with a <displayed/> element qualified by the 'urn:xmpp:chat-markers:0' namespace. The <displayed/> element MUST have an 'id' attribute that copies the value from the 'id' attribute of the message it refers to.

    +

    A Displayed Marker MAY be sent to the bare JID of the entity that requested it.

    +

    If multiple messages are displayed at once an entity SHOULD only send a <displayed/> marker for the most recent, received message.

    +

    To prevent looping, an entity MUST NOT send a Displayed Marker as a response to a Displayed Marker.

    + + +     +]]> - -

    Markers may be used within a MUC to indicate read status of each occupant.

    + +

    Displayed Markers can be used within group chats to indicate read status of each occupant.

    Within the context of a MUC messages are relayed through the MUC's own JID. In a MUC that preserves the 'id' attribute chosen by the sender of the message this 'id' attribute cannot be considered unique, as it may be unintentionally or even maliciously reused by another MUC occupant.

    -

    Therefore, if a MUC announces support for &xep0359; then clients MUST always use - the MUC-assigned id for Chat Markers. The id will be contained in a <stanza-id/> + the MUC-assigned id for Displayed Markers. The id will be contained in a <stanza-id/> element inserted into the stanza with a 'by' attribute matching the MUC's own JID.

    -

    As per XEP-0359 security considerations, if XEP-0359 support is not announced on the MUC room's JID then <stanza-id/> elements with a 'by' attribute that match the MUC's JID should be considered spoofed and MUST be ignored.

    +

    In group chats the Displayed Marker MAY be sent opportunistically, meaning without an explicit <markable/> request from the sender. While the sender might not be interested in or have support for Display Markers, other participants of the group chat could be interested in them.

    - + ]]> -     + +
      +
    • Displayed Marker only move forward. Receiving a Display Marker with an id-attribute that references a message older than the current local representation is considered redundant and MUST be ignored.
      • +
    • Displayed Marker with an id-attribute that references a message not found in the respective chat MUST be ignored.
      • +
    • Entities MUST not sent Displayed Markers for outgoing messages that were sent by the same or a different resource of the same entity (received for example via &xep0280; or &xep0313;).
      • +
    +     + + +

    Graphical representations of displayed markers for example in the form of checkmarks need to be made available for visually impaired users.

    +     + -

    A user may not wish to disclose that they have received, displayed or acknowledge a message.

    -

    It is possible for a sender to leak its presence when updating Chat Markers; - therefore, a sender SHOULD NOT send Chat Markers to recipients who are not otherwise authorized to view its presence.

    +
      +
    • A user may not wish to disclose that they have displayed or acknowledge a message.
      • +
    • It is possible for a sender to leak its presence when updating Displayed Markers; therefore, a sender SHOULD NOT send Displayed Markers to recipients who are not otherwise authorized to view its presence.
      • +
    • To accurately and reliably match Displayed Markers to current participants of a group chat, implementations MUST use the real JID (when available, for example in non-anonymous MUCs) or &xep0421;.
      • +
    +     + + +

    Letting others know that one has displayed (read) a message is not a desirable feature for everyone. Clients SHOULD provide ways to opt-out of this feature.

     +

    This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

     +

    This specification defines the following XML namespace:

    @@ -311,6 +237,11 @@     + + +

    Earlier drafts of this specification included <received/> and <acknowledged/> with the same up to this point semantic as the remaining <displayed/>. However in the review phase it was concluded that most implementers prefer the per-message precision of &xep0184; for received tracking. While <displayed/> has been widely implemented during a 10+ year review phase there was seemingly no demand for <acknowledged/>.

    +     + - - - - - - - - - - @@ -357,17 +278,6 @@ - - - - - - - - - - - ]]> From 405d43a4e7c9c1e2dbf708c635f37e95631d3724 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 10 Mar 2024 15:13:45 +0100 Subject: [PATCH 035/145] Move 'XEP-0392: Consistent Color Generation' to Proposed --- xep-0392.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0392.xml b/xep-0392.xml index fe6953df6..5b8cba315 100644 --- a/xep-0392.xml +++ b/xep-0392.xml @@ -14,7 +14,8 @@ This specification provides a set of algorithms to consistently generate colors given a string. The string can be a nickname, a JID or any other piece of information. All entities adhering to this specification generate the same color for the same string, which provides a consistent user experience across platforms. &LEGALNOTICE; 0392 - Experimental + Proposed + 2024-03-25 Standards Track Standards Council From c9f82182d66a28b6c611f8fe79bed1d25aea39ff Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 10 Mar 2024 16:06:27 +0100 Subject: [PATCH 036/145] Move 'XEP-0360: Nonzas (are not Stanzas)' to Proposed --- xep-0360.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xep-0360.xml b/xep-0360.xml index aca7908f8..9f6516584 100644 --- a/xep-0360.xml +++ b/xep-0360.xml @@ -10,7 +10,8 @@ This specification defines the term "Nonza", describing every top level stream element that is not a Stanza. &LEGALNOTICE; 0360 - Deferred + Proposed + 2024-03-25 Standards Track Standards Council From 9dfc1a99605e67b256e03edf3c0ed99c72c58353 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Thu, 7 Sep 2023 09:38:22 +0200 Subject: [PATCH 037/145] XEP-0060: Release version 1.26.0 Add examples for publishing item without ID --- xep-0060.xml | 47 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/xep-0060.xml b/xep-0060.xml index 743079311..72e4101d3 100644 --- a/xep-0060.xml +++ b/xep-0060.xml @@ -50,6 +50,14 @@ &pgmillard; &stpeter; &ralphm; + + 1.26.0 + 2023-09-07 + melvo + +

    Add examples for publishing item without ID

    +     +     1.25.0 2023-03-22 @@ -2761,7 +2769,6 @@ And by opposing end them?
  • Depending on the node configuration, the <publish/> element MAY contain no &ITEM; elements or one &ITEM; element. The inclusion of more than one &ITEM; element is no longer allowed, given the removal of batch publishing from version 1.13 of this specification. It is not necessary for a publication request to include a payload or even an &ITEM; element in order to trigger an event notification. For example, the result of publishing to a transient, notification-only node will be an event notification that does not include even an &ITEM; element. However, for the sake of convenience we refer to the act of publication as "publishing an item" (rather than, say, "triggering an event notification") even though a publication request will not always contain an &ITEM; element.
  • The <item/> element provided by the publisher MAY possess an 'id' attribute, specifying a unique ItemID for the item. If an ItemID is not provided in the publish request, the pubsub service MUST generate one and MUST ensure that it is unique for that node.
    • -

    An example follows.

    +]]> + + + + + + Soliloquy + +To be, or not to be: that is the question: +Whether 'tis nobler in the mind to suffer +The slings and arrows of outrageous fortune, +Or to take arms against a sea of troubles, +And by opposing end them? + + + tag:denmark.lit,2003:entry-32397 + 2003-12-13T18:30:02Z + 2003-12-13T18:30:02Z + + + + + ]]> @@ -2798,6 +2833,16 @@ And by opposing end them? from='pubsub.shakespeare.lit' to='hamlet@denmark.lit/blogbot' id='publish1'> + + + + +]]> + From 1a821aee8a3a431be19f2fad4693ce4feb0667cf Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Mon, 11 Mar 2024 08:36:38 +0100 Subject: [PATCH 038/145] Move 'XEP-0488: MUC Token Invite' to Experimental --- xep-0488.xml | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 217 insertions(+) create mode 100644 xep-0488.xml diff --git a/xep-0488.xml b/xep-0488.xml new file mode 100644 index 000000000..0224216f2 --- /dev/null +++ b/xep-0488.xml @@ -0,0 +1,216 @@ + + + +%ents; +]> + + +
    + MUC Token Invite + This specification provides a way to generate tokens to invite users to a MUC room. + &LEGALNOTICE; + 0488 + Experimental + Standards Track + Standards + Council + + XEP-0045 + XEP-0421 + + + + muc-token-invite + + muc + token + invite + + &pep.; + + 0.1.0 + 2024-03-11 + XEP Editor: dg + +
      +
    • Promoted to Experimental
      • +
    +     +     + + 0.0.1 + 2023-08-15 + pep +

    First draft.

     +     +
    + +

    This specification provides a way to request invite tokens to a MUC room in order to invite users whose address is unknown to a member-only &xep0045; room.

    +     + +
      +
    • Allow tokens to be generated, optionally with constraints.
      • +
    • Allow tokens to be revoked.
      • +
    • Don't prevent affiliated users of a room to join if they don't possess a token.
      • +
    • Don't require clients receiving tokens to have any specific implementation.
      • +
    +     + + +

    Supporting entities MUST advertise the &MTINS; &xep0030; feature.

    +     + +

    An entity may request a token from a &xep0045; service by sending an iq of type set containing a <request> element in the &MTINS; namespace.

    + + +]]> +

    The MUC room MUST reply to the request with a <token> element in the &MTINS; namespace, containing the token as text node. The token MUST be an opaque string but does not need to be unique within a room.

    + + lyQZ1RzacYTlf3svGODYq1xVabNnMc2x +]]> +

    Implementations MUST reply an error ot type auth/forbidden if the requesting entity isn't allowed to generate a token.

    + + + + +]]> +     + +

    It is possible to create tokens that may be used only a specific number of times to grant users affiliations, and/or may have an expiry time.

    +

    To constrain the token to a number of times after which it expires, the counter attribute (xs:unsignedInt) can be used in the <request> element.

    +

    To constrain the token to a time limit, the delay attribute (xs:unsignedInt) can be used in the <request> element.

    +

    if both attributes are combined, whichever constraint is reached first expires the token.

    + + +]]> +

    The reply from the service MUST contain at least the requested delay and counter attributes. Requested values for these attributes MAY be altered by the server. This may be useful to implement a default server policy (maximum time, and/or counter). Values returned indicate current values that apply to the issued token.

    +

    Services may want to automatically limit issued tokens even with the request doesn't have any. In the following example, the MUC service enforces a maximum time limit of a week as a policy.

    + + lyQZ1RzacYTlf3svGODYq1xVabNnMc2x +]]> +     + +

    Integration with Mediated Invites or &xep0249; is not described in this document as invite tokens generated this way may not be used when the invitee's address is known.

    +

    Clients may include generated tokens in the password parameter of a URI as such:

    + xmpp:news@commons.example?join;password=TOKEN +     + +

    Receiving entities will follow the usual flow of joining password protected-rooms.

    +

    When a token is used by a participant who doesn't have any affiliation, a server MUST give them an affiliation level of member.

    +

    If an expired token is used by someone who isn't affiliated yet, the room MAY additionally include in the presence error an <expired-token/> element in the &MTINS; namespace, as a sibling of the <not-authorized/> element.

    +     + +

    It is possible for room participants to list tokens by sending an iq of type get containing a <tokens/> element in the &MTINS; namespace.

    +

    The room MUST reply with all tokens that the participant is allowed to revoke, each listed in <token> elements within a <tokens> wrapper element. Individual token elements MUST contain updated attibute values, that is, if a token has been issued with counter set to 5 and has been used twice (2), listing tokens at this point will show this specific token with a counter attribute value of 3.

    + + + + + + + lyQZ1RzacYTlf3svGODYq1xVabNnMc2x + HIFac1EUx3gDA1TEXlblwQ2izGIqAUab + +]]> +     + +

    It is possible to revoke a token early by sending an iq containing a <revoke> element in the &MTINS; namespace, with the token as the text node. The room MUST then reply successfully with an empty iq.

    +

    If the user is unauthorized to issue tokens, the room should reply with an iq error type auth/forbidden. If the user is unauthorized to revoke the specified token, or if the token doesn't exist, the room should reply with an iq error of type cancel/item-not-found.

    +

    + + lyQZ1RzacYTlf3svGODYq1xVabNnMc2x +]]> + ]]> + + + + +]]> +     +     + +

    Tokens may be added to bookmark storage by receiving entities and as such implementing MUC rooms SHOULD ignore tokens provided during join when a user is already affiliated with the room. In this case, if a counter was attached it SHOULD NOT be decremented.

    +

    Tokens with no constraint are not equivalent to passwords. A token is only required to be supplied once as opposed to passwords, which need to be specified at every join independently of user affiliation.

    +

    The Using a token section describes a way for clients to know they may have used an invalid token by adding an error specific to this document. It is likely that tokens aren't stored indefinitely but rather removed from storage not long after they expire, which makes it hard for MUC services to distinguish between a password for the room before configuration change, and an expired token. This specification assumes that it was an expired token as the room isn't password protected.

    +

    Possible extensions to this spec could include broadcasting information about the inviter in a new participant's join presence, as well as issuing tokens with specific affiliations and/or &xep0317;.

    +     + +

    None?

    +     + +

    None?

    +     + +

    Leaking tokens may lead to inviting unwelcomed people to a room. Token limits and revocations provide users a way to reduce harm in such a case. A service SHOULD also enforce a reasonable maximum value as a time or usage constraint (24h, a week, a year, etc.).

    +

    Issuing tokens may be locked down by service operators, or by room administrators via the muc#roomconfig_allowinvites &xep0045; configuration option.

    +

    It is RECOMMENDED that room moderators be able to list and revoke tokens generated by every other participant.

    +     + +

    None.

    +     + +

    None.

    +     + + + + + + + The protocol documented by this schema is defined + in XEP-xxxx: https://xmpp.org/extensions/xep-xxxx.html. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> + +     diff --git a/xep.ent b/xep.ent index 290a5924c..28c22ba6e 100644 --- a/xep.ent +++ b/xep.ent @@ -1694,4 +1694,5 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates PubSub Server Information (XEP-0485)XEP-0485: PubSub Server Information <https://xmpp.org/extensions/xep-0485.html>."> MUC Avatars (XEP-0486)XEP-0486: MUC Avatars <https://xmpp.org/extensions/xep-0486.html>."> Host Meta 2 - One Method To Rule Them All (XEP-0487)XEP-0487: Host Meta 2 - One Method To Rule Them All <https://xmpp.org/extensions/xep-0487.html>."> +MUC Token Invite (XEP-0488)XEP-0488: MUC Token Invite <https://xmpp.org/extensions/xep-0488.html>."> From f718cb455352e8db1341dfb4a4600f17b87d92a4 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Mon, 11 Mar 2024 08:38:30 +0100 Subject: [PATCH 039/145] Move 'XEP-0489: Reporting Account Affiliations' to Experimental --- xep-0489.xml | 229 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 230 insertions(+) create mode 100644 xep-0489.xml diff --git a/xep-0489.xml b/xep-0489.xml new file mode 100644 index 000000000..0ef3eade5 --- /dev/null +++ b/xep-0489.xml @@ -0,0 +1,229 @@ + + +%ents; +]> + +
    +Reporting Account Affiliations +This specification documents a way for an XMPP server to report to other entities the relationship it has with a user on its domain. +&LEGALNOTICE; +0489 +Experimental +Standards Track +Standards +Council + + + +raa + +Matthew +Wild +mwild1@gmail.com + + + 0.1.0 + 2024-03-11 + XEP Editor: dg + +
      +
    • Promoted to Experimental
      • +
    +     +     + +0.0.1 +2023-06-28 +mjw + + + +
    + + +

    This specification documents a way for an XMPP server to report to other entities the relationship it has with a user on its domain.

    + +

    In practice, a server may not trust all accounts equally. For example, if a server offers anonymous access or open registration, it may have very little trust in such users. Meanwhile a user account that was provisioned by a server administrator for an employee or a family member would naturally have a higher level of trust.

    + +

    Even if a server alters its own behaviour based on how much it trusts a user account (such as preventing anonymous users from performing certain actions), other entities on the network have no way of knowing what trust to place in JIDs they have not encountered before - they can only judge the server as a whole.

    + +

    This lack of insight can result in the negative actions (spam, abuse, etc.) by untrusted users on a domain causing the whole domain to be sanctioned by other servers.

    + +     + +

    This protocol will allow:

    + +
      +
    • Servers to communicate the affiliation of the end user that sent a stanza
      • +
    • Remote servers to query a user’s affiliation on demand
      • +
    + +

    By providing this high-level information to other entities on the network, it +allows them to make informed decisions about how to handle traffic at the +account level rather than the server level.

    + +

    For example, during a spam wave, a public MUC service may choose not to grant +the 'participant' role by default to accounts that were very recently +registered.

    + +

    It aims to achieve this while preserving the privacy of the user themselves, +and ensuring the user’s server has full discretion over what data to provide +and to which entities it is provided.

    + + + +

    This specification has similar goals to that of XEP-0275: Entity Reputation. It differs in the following ways:

    + +
      +
    • Rather than attempting to define a semi-standardized scale, it reports qualitative actionable account status information. This makes implementation simpler, and servers don’t have to guess at appropriate thresholds on a universal quantitative scale.
      • +
    • This specification can be extended in the future if necessary. The scoring algorithm in XEP-0275 is coded into the document, and changing the value assignments may impact existing deployments that have defined thresholds based on the current specification.
      • +
    • The 'trust' level in this specification is superficially similar to the Entity Reputation score, however with notable differences: trust levels are calculated only by a server for its own users, and we make no attempt to standardize an algorithm.
      • +
    + +

    Some of this information may also be discovered through XEP-0030: Service Discovery. This specification provides more detailed information than is currently exposed via service discovery, and it is also push-based, removing the need for recipients to separately query an account’s status while determining how to handle a stanza.

    + +     + +

    An affiliation is what we call the relationship that a user has with a service. Different affiliations +imply different levels of trust. The affiliations defined in this specification are as follows:

    + +
      +
    • anonymous: the address belongs to an anonymous, temporary or guest account. The user is not known to the server.
      • +
    • registered: the address belongs to an account that self-registered, e.g. using XEP-0077
      • +
    • member: the address belongs to a trusted member of the server - e.g. accounts that are provisioned for known users.
      • +
    • admin: the address belongs to a server administrator
      • +
    + +

    It should be noted that these affiliations extend the account types defined +in the Service Discovery Identities registry. Notably, this document adds an additional affiliation type: 'member'.

    + +     + + + +

    An affiliation element looks like this:

    + +]]> + +

    The 'affiliation' attribute MUST be present, and the value MUST be one of the affiliations listed in the previous section. The 'since' attribute is optional, and contains a XEP-0082 DateTime profile string representing the date and time at which the account was approximately created. Please see the security considerations for advice on preserving privacy before exposing this information.

    + +     + +

    An entity may directly query for affiliation information about a JID.

    + + + +]]> + +

    The server SHOULD respond successfully with as much information as it permits the requesting entity to see:

    + + + +]]> + +

    Alternatively, the server MAY respond with a 'forbidden' error if it does not permit the requesting entity to view any information about account affiliations:

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

    Alternatively the <info/> element can be embedded into outgoing stanzas, such as presence or messages:

    + + + +]]> + +

    The above stanza demonstrates a subscription request sent by a recently-registered user to a user on another server. When embedding, a server MUST announce which stanzas it supports embedding in. In such +stanzas it MUST strip any existing <info/> elements that may have been sent by the client.

    + +

    Receiving servers MUST only trust embedded <info/> elements when the origin +server has announced support for them.

    + +     + +

    A server may exercise discretion over when it includes affiliation information. For example, it MAY choose to only reveal this information when sending stanzas to trusted servers, or withold it when sending stanzas to untrusted servers (the definition of trusted servers is beyond this specification - it may be implementation-specific or based on a protocol such as XEP-0267: Server Buddies).

    + +

    Similarly, the information does not need to be included for every type of stanza. For example, a server SHOULD only include this information for stanzas that are sent to non-contacts. For example, messages and presence to JIDs that have not granted a presence subscription to the sender yet (i.e. absent from the sender’s roster, or with a subscription state of 'none' or 'from').

    + +

    A server MAY also withold or reduce the information for certain affiliations - e.g. by reporting server administrators as simply 'member' if the server does not want to expose this information to the recipient.

    + +

    The inclusion of the 'since' attribute is optional, but it SHOULD be included for accounts with the affiliation 'registered' accounts that were created within the past 30 days. It MAY be approximate (e.g. rounded to the nearest day) for performance or privacy reasons (the latter is discussed in the security considerations section).

    + +

    The inclusion of the 'trust' attribute is optional, but it SHOULD be included for 'registered' accounts if 'since' is not included. That is, at least one of 'since' or 'trust' SHOULD be present for accounts with affiliation 'registered' to ensure a recipient has sufficient information to act on. The value of the 'trust' attribute MUST be an integer from 0 to 100 (inclusive). The value may be calculated by the server using any algorithm it deems appropriate. However, the same algorithm MUST be used for all users of the same affiliation, so that comparison between them is meaningful.

    + +     + +

    If a server supports this protocol and the query functionality, it MUST +advertise the 'urn:xmpp:raa:0' feature in response to service discovery +queries on its domain JID.

    + +

    If the server also supports embedding affiliation into stanzas, it MUST also +advertise the appropriate features from this list:

    + +
    +
    urn:xmpp:raa:0#embed-presence-sub
    +
    <info/> may be embedded in presence subscription requests originating from the user’s bare JID.
     +
    urn:xmpp:raa:0#embed-presence-directed
    +
    <info/> may be embedded in directed presence (including e.g. XEP-0045 join requests) from the user’s full JID.
     +
    urn:xmpp:raa:0#embed-message
    +
    <info/> may be embedded in message stanzas.
     +
    + +     + +

    This specification describes a protocol that can be used to help enhance the +security of the XMPP network. However, some considerations do apply.

    + + + +

    If a server chooses to expose an account’s creation timestamp to untrusted +entities, the reported value SHOULD be approximate - e.g. rounded to the day +on which the account registered - to preserve privacy. Providing a value with +a high precision may allow entities to correlate the account registration with +other actions performed by the user, or determine a user’s likely time zone.

    + +

    In particular, and in accordance with the security considerations of XEP-0082, +the 'since' value MUST be reported in UTC.

    + +     + +

    The payloads described in this specification may be embedded by the server in +stanzas originating from a user’s JID. This makes it trivial for clients to +send spoofed <info/> elements if the server does not remove them. To +protect against such spoofing:

    + +
      +
    • Origin servers MUST advertise the correct features according to the stanza types they embed the <info/> element within.
      • +
    • Origin servers MUST strip client-originating <info/> elements from any stanza types they have advertised support for.
      • +
    • Receiving servers MUST ignore <info/> elements embedded within stanzas from other servers unless that server advertises support for embedding within that specific stanza type.
      • +
    + +     + +

    None.

    + +     + +

    This document extends the 'Identity Categories and Types Registry' defined by +XEP-0030 with the following addition to the 'account' category:

    + + + member + The user@host is a trusted member of the server - e.g. an account that was provisioned for known user + XEP-xxxx +]]> +     +     + diff --git a/xep.ent b/xep.ent index 28c22ba6e..2410bbbc7 100644 --- a/xep.ent +++ b/xep.ent @@ -1695,4 +1695,5 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates MUC Avatars (XEP-0486)XEP-0486: MUC Avatars <https://xmpp.org/extensions/xep-0486.html>."> Host Meta 2 - One Method To Rule Them All (XEP-0487)XEP-0487: Host Meta 2 - One Method To Rule Them All <https://xmpp.org/extensions/xep-0487.html>."> MUC Token Invite (XEP-0488)XEP-0488: MUC Token Invite <https://xmpp.org/extensions/xep-0488.html>."> +Reporting Account Affiliations (XEP-0489)XEP-0489: Reporting Account Affiliations <https://xmpp.org/extensions/xep-0489.html>."> From 2381ca0887e92ba265248d5054e0a244f029ba8a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Mon, 11 Mar 2024 09:32:14 +0100 Subject: [PATCH 040/145] XEP-0001: Make only editorial changes affect Deferred state --- xep-0001.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/xep-0001.xml b/xep-0001.xml index 1848257d7..e492eae62 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -307,6 +307,7 @@

    Once a XEP is published, it becomes available for public discussion within the Standards SIG and the broader XMPP developer community. The XEP author (or Document Shepherd) is responsible for collecting feedback from the XMPP developer community during the life of the XEP and for incorporating such feedback into the proposal. In order to fully participate in discussion of the proposal, they should be subscribed to the Standards list, which is the primary venue for discussion of XMPP Extension Protocols. Changes made based on feedback received by the XEP author (or Document Shepherd) shall be captured in updated versions of the XEP (e.g., 0.2 after 0.1), each of which must be put under source control and subsequently published and announced by the XMPP Extensions Editor.

    If an Experimental XEP is inactive (i.e., no updated versions are published) for a period of twelve (12) months, the XMPP Extensions Editor shall automatically change the status of the XEP to Deferred unless it is in the queue of XEPs under active consideration for advancement by the Approving Body; upon submission of an updated version, the XMPP Extensions Editor shall change the status back to Experimental.

    +

    Only substantial, non-editorial changes (e.g. those that would cause an updated version of 0.1 to 0.2, not editorial updates from 0.1.1 to 0.1.2) count as activity (or updates) for the purpose of considering moving a XEP from or to Deferred state.

    An Experimental (or Deferred) XEP may be proposed to the Approving Body for advancement to Stable (Standards Track XEPs) or Active (Historical, Informational, and Procedural XEPs). This can be requested from the Approving Body on the Standards list by, or in collaboration with, the XEP author. In case the XEP has been abandoned by its author(s), any other individual can propose advancement in their stead. The Approving Body will then require a Document Shepherd to take on responsibilities on behalf of the XEP author during the proposal and approval processes. The Approving Body must agree that the XEP is ready to be considered for advancement. Once the Approving Body so agrees, it shall instruct the XMPP Extensions Editor to (1) change the status of the XEP from Experimental (or Deferred) to Proposed and (2) issue a Last Call for open discussion on the Standards list. The Last Call shall expire not less than fourteen (14) days after the date of issue.

    From ed7dbd05c413a518cf8b4749ec985f281eb4b073 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Mon, 11 Mar 2024 09:33:08 +0100 Subject: [PATCH 041/145] fix semver in XEP-0266 fixes #1274 --- xep-0266.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0266.xml b/xep-0266.xml index 6ac23e219..f048ef90f 100644 --- a/xep-0266.xml +++ b/xep-0266.xml @@ -25,7 +25,7 @@ jingle &stpeter; - 1.1rc1 + 1.1.0-rc.1 2013-03-01 psa

    Updated to reflect standardization of the Opus codec; changed client conformance to also recommend (but not require) support for Opus.

     From 2ec7b59ca18c8776d77dccbf017103cd2c1993ab Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Mon, 11 Mar 2024 09:38:08 +0100 Subject: [PATCH 042/145] XEP-0001: add changelog --- xep-0001.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xep-0001.xml b/xep-0001.xml index e492eae62..2061c3f34 100644 --- a/xep-0001.xml +++ b/xep-0001.xml @@ -22,6 +22,12 @@ &stpeter; &dcridland; &ralphm; + + 1.25.0 + 2024-03-11 + XEP Editor: dg +

    Add note that editorial changes do not affect Deferred state

     +     1.24.0 2021-08-24 From ef79d2cad2b0a47dc08d7e7ab685446ae263f53f Mon Sep 17 00:00:00 2001 From: JC Brand Date: Tue, 12 Mar 2024 10:24:48 +0200 Subject: [PATCH 043/145] XEP-0425: Updates based on list feedback - Remove the dependency on XEP-0422 Message Fastening - Rename to 'Moderated Message Retraction' and focus only on the retraction use-case - Clarify the purpose of the `reason` element - Specify that clients must check that the correct stanza ID was used (based on the `by` attribute) - Relax the requirement that a `by` attribute be added to the `` element to SHOULD. Mailing list thread is here: https://mail.jabber.org/pipermail/standards/2021-December/038660.html --- xep-0425.xml | 102 ++++++++++++++++++++++++++++++--------------------- 1 file changed, 60 insertions(+), 42 deletions(-) diff --git a/xep-0425.xml b/xep-0425.xml index 94a069318..7a6b3877e 100644 --- a/xep-0425.xml +++ b/xep-0425.xml @@ -6,11 +6,11 @@
    - Message Moderation - This specification defines a method for groupchat moderators to moderate messages. + Moderated Message Retraction + This specification defines a method for groupchat moderators to retract messages of other users. &LEGALNOTICE; 0425 - Proposed + Experimental 2022-01-04 Standards Track Standards @@ -19,12 +19,24 @@ XMPP Core XMPP IM XEP-0313 - XEP-0422 message-moderation &jcbrand; + + 0.3.0 + 2023-03-02 + jcb + +
      +
    • Remove the dependency on XEP-0422 Message Fastening
      • +
    • Rename to 'Moderated Message Retraction' and focus only on the retraction use-case
      • +
    • Ensure compatibility with clients that only implement XEP-0424
      • +
    • Clarify the purpose of the <reason/> element
      • +
    +     +     0.2.1 2020-01-28 @@ -51,74 +63,75 @@
    -

    Occasionally, a &xep0045; moderator might wish to moderate certain groupchat messages by, for example, retracting them from the groupchat history as part of an effort to address and remedy issues such as message spam, indecent language for the venue or exposing private third-party personal information. Alternatively, a moderator might want to correct a message on another user's behalf, or flag a message as inappropriate without requiring that it be retracted.

    +

    Occasionally, a &xep0045; moderator might wish to moderate certain groupchat messages by, for example, retracting them from the groupchat history as part of an effort to address and remedy issues such as message spam, indecent language for the venue or exposing private third-party personal information.

    +

    This XEP is designed in such a way to also allow other potential moderator actions, such as message editing, but these actions fall out of the scope of this XEP and we will only be considering message retractions.

    Due to the federated nature of XMPP and as with any content moderation tool, the moderation request can only be considered as a hint and clients which don't support message moderation are not obligated to enforce any such request.

     -

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

    - If a groupchat supports moderated message retraction, it MUST specify the 'urn:xmpp:message-moderate:1' feature in its service discovery information features as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;.

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

    Consider a situation where a user sends a message that may be deemed inappropriate by a groupchat moderator. The groupchat service will append a &xep0359; stanza ID to the message before relaying it to all participants.

    - Consider a situation where a user sends a message that may be deemed inappropriate by a groupchat moderator. The MUC will append a &xep0359; stanza ID to the message before relaying it to all participants.

    + DM me for free magic potions! ]]>

    The moderator sees the message and indicates to their client that the message should be retracted. The client then sends an IQ stanza to the MUC service, requesting that the message be retracted.

    +

    An optional <reason/> element may be included inside the <moderate/> element, to provide a human-readable explanation why the message was retracted.

    - - - - This message contains inappropriate content for this forum - - + + + This message contains inappropriate content for this forum + ]]> -

    If the moderator is allowed to moderate the message, the groupchat service will send a message stanza to all participants (including the moderator), indicating that the message has been retracted and by whom.

    -

    This message will use &xep0422; to indicate that it applies to the moderated message, by referring to its XEP-0359 Stanza ID.

    +

    If the moderator is allowed to moderate the message, the MUC will send a message stanza to all participants (including the moderator), indicating that the message has been retracted and by whom.

    +

    This message will use &xep0424; to indicate that it is a retraction, and will refer to the retracted message by its XEP-0359 Stanza ID. Care must be taken to use the stanza ID that was added by the MUC, i.e. which has a "by" attribute set to the MUC JID, and not some other stanza ID. The client MUST check that the correct stanza ID was used and ignore the stanza if not.

    +

    Inside the <retract/> element is a <moderated/> element indicating that the retraction was a moderator action, as well as an optional reason.

    - - - - - This message contains inappropriate content for this forum + + + - + This message contains inappropriate content for this forum + ]]> -

    The groupchat service also responds with an IQ "result" stanza.

    +

    The MUC also responds with an IQ "result" stanza.

    - ]]>     -

    In case the message could for some reason not be retracted, the grouchat service responds with an IQ stanza of type error.

    - In case the message could for some reason not be retracted, the MUC responds with an IQ stanza of type error.

    + @@ -132,8 +145,10 @@

    A &xep0313; service MAY replace the contents of a message, that was retracted due to moderation, with a 'tombstone' similar to the one described in &xep0424;.

    -

    The archiving service replaces the message contents (i.e. the <body/> and any related elements which might leak information about the original message) with a <moderated/> element which in turn contains a <retracted/> element. The <moderated/> element MUST have a 'by' attribute specifying the JID of the moderating entity.

    -

    If the message was sent in a semi-anonymous MUC, the occupant id from &xep0421; SHOULD be included for the moderator and the message author in the <moderated/> and <retracted/> elements respectively.

    +

    The archiving service replaces the message contents (i.e. the <body/> and any related elements which might leak information about the original message) with a <retracted/> element which in turn contains a <moderated/> element.

    +

    Note the past tense in the element names, e.g. "retracted" instead of just "retract", to indicate that the retraction has already been executed and that this is therefore a tombstone and not an action that should be applied.

    +

    The <moderated/> element SHOULD have a 'by' attribute specifying the JID of the moderating entity. There might however be cases where it's preferable to not specify which JID was responsible for the moderation, for example when the moderation happens in an automated manner.

    +

    If the message was sent in a semi-anonymous MUC, the occupant id from &xep0421; SHOULD be included for the moderator in the <moderated/> element and for the original (retracted) message author in the <message/> element.

    @@ -142,11 +157,12 @@ - - - + + + + This message contains inappropriate content for this forum - + @@ -156,7 +172,7 @@

    A moderator MUST NOT send a moderation request for a message with non-messaging payloads. For example, a moderator MUST NOT moderate a roster item exchange request or a file transfer part.

    In MUCs, only moderation messages (not tombstones, but messages containing the <moderate/> element) received from the MUC service itself are legitimate, all other such messages MUST be discarded.

    -

    If message moderation includes a retraction request, the MUC or other service that supports message retraction SHOULD prevent further distribution of the retracted message by the service and the archiving service MAY replace the retracted message with a tombstone as detailed in &xep0424;.

    +

    The MUC or other service that supports message retraction SHOULD prevent further distribution of a moderated retracted message and the archiving service MAY replace the retracted message with a tombstone.

    There can never be a guarantee that a moderated message will appear as such in all clients. Clients should therefore, when possible, inform users that no such guarantee exists.

    @@ -167,9 +183,9 @@     -

    The ®ISTRAR; includes 'urn:xmpp:message-moderate:0' in its registry of protocol namespaces (see &NAMESPACES;).

    +

    The ®ISTRAR; includes 'urn:xmpp:message-moderate:1' in its registry of protocol namespaces (see &NAMESPACES;).

      -
    • urn:xmpp:message-moderate:0
      • +
    • urn:xmpp:message-moderate:1
     @@ -182,17 +198,19 @@ - + + + - + From ed29a2312afd2dfdd49a6b9ee18a4c58f88f4204 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Tue, 12 Mar 2024 09:28:40 +0100 Subject: [PATCH 044/145] Move XEP-0424 back to Experimental --- xep-0424.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0424.xml b/xep-0424.xml index cfa0522c3..bfdea4a19 100644 --- a/xep-0424.xml +++ b/xep-0424.xml @@ -10,7 +10,7 @@ This specification defines a method for indicating that a message should be retracted. &LEGALNOTICE; 0424 - Proposed + Experimental 2022-01-04 Standards Track Standards From 81570bb0a648bab20e87b6c7a36c037c25844377 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Tue, 20 Feb 2024 17:00:24 +0100 Subject: [PATCH 045/145] XEP-0313: Add XEP-0136 to superseded specifications XEP-0136 already defines that it is superseded by XEP-0313. --- xep-0313.xml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/xep-0313.xml b/xep-0313.xml index f247e68b2..bc3ad38a4 100644 --- a/xep-0313.xml +++ b/xep-0313.xml @@ -22,7 +22,7 @@ XEP-0059 XEP-0297 - + XEP-0136 mam @@ -30,6 +30,14 @@ &mwild; &ksmith; + + 1.1.1 + 2024-02-20 + gdk + +

    Add XEP-0136 to superseded specifications

    +     +     1.1.0 2023-03-09 From d1843da91ab479fd8afae9fe4bd72fe48e197dff Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Thu, 14 Mar 2024 08:45:33 +0100 Subject: [PATCH 046/145] MDS: Add Accessibility, Privacy and Design Considerations --- inbox/xep-mds.xml | 47 ++++++++++++++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 11 deletions(-) diff --git a/inbox/xep-mds.xml b/inbox/xep-mds.xml index e44894a18..fc04e1311 100644 --- a/inbox/xep-mds.xml +++ b/inbox/xep-mds.xml @@ -28,6 +28,12 @@ daniel@gultsch.de daniel@gultsch.de + + 0.0.2 + 2024-03-14 + dg +

    Add Accessibility, Privacy and Design Considerations

     +     0.0.1 2024-02-21 @@ -36,13 +42,13 @@ -

    In multi-device environments marking a chat as displayed on one device should mark that chat as displayed on all devices. Historically carbon copies (&xep0280;) of the <displayed/> element of Chat Markers (&xep0333;) have been used to achieve this effect. However this approach has a couple of downsides that this specification is trying eliminate:

    +

    In multi-device environments marking a chat as displayed on one device should mark that chat as displayed on all devices. Historically carbon copies (&xep0280;) of the <displayed/> element of Displayed Markers (&xep0333;) have been used to achieve this effect. However this approach has a couple of downsides that this specification is trying eliminate:

      -
    • The contact has to request Chat Markers by tagging a message with <markable/>.
      • -
    • Chat Markers let the contact know that a device has displayed the message. This might not always be advisable when synchronization across multiple devices of the same user is the desired outcome.
      • -
    • When used in large group chats Chat Markers can create a lot of unwanted traffic.
      • +
    • The contact has to request Displayed Markers by tagging a message with <markable/>.
      • +
    • Displayed Markers let the contact know that a device has displayed the message. This might not always be advisable when synchronization across multiple devices of the same user is the desired outcome.
      • +
    • When used in large group chats Displayed Markers can create a lot of unwanted traffic.
    -

    This specification isolates the task of multi-device synchronization from providing information to the contact, while borrowing some of the semantics of Chat Markers such as displayed refering to all messages up to this point.

    +

    This specification isolates the task of multi-device synchronization from providing information to the contact, while borrowing some of the semantics of Displayed Markers such as displayed refering to all messages up to this point.
      @@ -148,11 +154,11 @@ ]]> - +

      A &xep0333; displayed marker refers to the message id set by the sender of the message whereas the displayed element defined in this specification refers to the stanza-id injected by the user’s server.

      In the likely scenario that a client wishes to share the displayed state with their own devices and the sender of the message, a client SHOULD sent a &xep0333; displayed marker and ensure that the 'urn:xmpp:mds:displayed:0' node gets updated.

      -

      A &xep0060; item publication is a fairly verbose operation for something that is expected to happen rather frequently. Therfore this specification defines an optional way to combine the PEP node item update and the Chat Marker in one simple message.

      +

      A &xep0060; item publication is a fairly verbose operation for something that is expected to happen rather frequently. Therfore this specification defines an optional way to combine the PEP node item update and the Displayed Marker in one simple message.

      Server assisted displayed node updates are an optional feature a user’s server can provide. To signal support the server announces an &xep0115; feature of 'urn:xmpp:mds:server-assist:0' on the account.

      @@ -170,7 +176,7 @@ ]]>       -

      To update the displayed item in the 'urn:xmpp:mds:displayed:0' PEP node more efficiently a client MAY send a message with the 'to' attribute set to the item id (which is equivalent to the JID of the contact) and with a <displayed/> element qualified by the 'urn:xmpp:mds:displayed:0' namespace. The server MUST strip the <displayed/> element from the message and continue to process it normally. The server MUST publish a PEP item on the 'urn:xmpp:mds:displayed:0' node where the item id is taken from the 'to' attribute and the payload is the <displayed/> element. A client MUST NOT include the <displayed/> element qualified by the 'urn:xmpp:mds:displayed:0' namespace if the message would otherwise be empty. A client that wishes to update the device synchronized displayed state but not inform the sender of the message via Chat Markers SHOULD use the regular PubSub publication process.

      +

      To update the displayed item in the 'urn:xmpp:mds:displayed:0' PEP node more efficiently a client MAY send a message with the 'to' attribute set to the item id (which is equivalent to the JID of the contact) and with a <displayed/> element qualified by the 'urn:xmpp:mds:displayed:0' namespace. The server MUST strip the <displayed/> element from the message and continue to process it normally. The server MUST publish a PEP item on the 'urn:xmpp:mds:displayed:0' node where the item id is taken from the 'to' attribute and the payload is the <displayed/> element. A client MUST NOT include the <displayed/> element qualified by the 'urn:xmpp:mds:displayed:0' namespace if the message would otherwise be empty. A client that wishes to update the device synchronized displayed state but not inform the sender of the message via Displayed Markers SHOULD use the regular PubSub publication process.

      Hi. How are you? @@ -208,9 +214,13 @@
    • Displayed states with a stanza-id not found in the respective chat MUST be ignored.
    • Receiving an outgoing message (for example via &xep0280; or &xep0313;) SHOULD NOT mark the chat as displayed. Outgoing messages are neutral towards the overall displayed state of a given chat. For example if the displayed up to state references the most recent incoming message and this message is only followed by outgoing messages the overall state of that chat SHOULD be considered displayed.
    • A client receiving an outgoing message MAY NOT update the displayed node item with that stanza-id. However clients SHOULD be able to handle displayed states that use stanza-ids that refer to outgoing messages and simply consider the chat as displayed up to that point.
      • -
    • While Chat Markers (&xep0333;), in 1:1 chats, MAY be sent to a full JID, a client combining both <displayed/> elements in a single message MUST address that message to the bare JID, as the server will use the verbatim 'to' attribute as the item ID.
      • +
    • While Displayed Markers (&xep0333;), in 1:1 chats, MAY be sent to a full JID, a client combining both <displayed/> elements in a single message MUST address that message to the bare JID, as the server will use the verbatim 'to' attribute as the item ID.
      • +
    • Processing and stripping of the <displayed/> element qualified by the 'urn:xmpp:mds:displayed:0' namespace on the server MUST happen before the message is stored in the archive (&xep0313;) and before it is reflected back to the sender via &xep0280; or &xep0409;.
     + +

    This specification comes with no accessibility considerations that go beyond what is required of any client (i.e. providing an accessible distinction between read and unread chats).

    +
    • When publishing displayed states via &xep0060; the client MUST use publish-options to set the access model on the node to whitelist. To ensure the server supports publish-options the client MUST first check for the "http://jabber.org/protocol/pubsub#publish-options" feature.
      • @@ -219,11 +229,26 @@
    • This specification provides a convenient process to synchronize a user’s own devices and informing the third party in one, single message. However letting the third party know is not always desirable, for example when the user has generally opted out of transmitting the displayed status or when a non-contact initiated a chat. In those cases the client MUST use the &xep0060; method instead of server-assist.
     + +

    Implementing this specification gives the server the opportunity to perform activity tracking of a similiar scope than implementing &xep0085; or &xep0333; would.

    +

    When using the server assist feature in conjunction with &xep0333; the Privacy Considerations of Display Markers apply.

    +     -

    REQUIRED.

    +

    This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

    +     + + +

    This specification introduces a distinct element to enable server assist instead of utilizing &xep0333; because Displayed Markers use the message id instead of stanza-ids. Translating between message id and stanza-id would require that the message (or parts of it) are archived on the server. Archiving should not be a requirement to offer server assist. (Especially since archived or not can depend on user settings.)

    +     + +

    Server assist is not allowed in messages that would otherwise be empty. Overloading the semantic of sending a stanza to a third party entity solely to perform an action on the account that involves said third party is a dangerous example to set. (For example if server assit fails due to implementation errors a third party can be flooded with messages.) While stripping elements from stanzas is a common requirement on XMPP dropping entire stanzas without error is not.

    +     -

    REQUIRED.

    +

    This specification defines the following XML namespace:

    +
      +
    • urn:xmpp:mds:displayed:0
      • +

    REQUIRED for protocol specifications.

    From aa2083abb106db74c64d753b1c35472dd2433f27 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Thu, 14 Mar 2024 08:46:40 +0100 Subject: [PATCH 047/145] update 0333 entity after renaming --- xep.ent | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep.ent b/xep.ent index 2410bbbc7..96ffc1955 100644 --- a/xep.ent +++ b/xep.ent @@ -1530,7 +1530,7 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Pubsub Subscription (XEP-0330) XEP-0330: Pubsub Subscription <https://xmpp.org/extensions/xep-0330.html>." > Data Forms - Color Field Types (XEP-0331) XEP-0331: Data Forms - Color Field Types <https://xmpp.org/extensions/xep-0331.html>." > HTTP Over XMPP Transport (XEP-0332) XEP-0332: HTTP Over XMPP Transport <https://xmpp.org/extensions/xep-0332.html>." > -Chat Markers (XEP-0333) XEP-0333: Chat Markers <https://xmpp.org/extensions/xep-0333.html>." > +Displayed Markers (was: Chat Markers) (XEP-0333) XEP-0333: Displayed Markers (was: Chat Markers) <https://xmpp.org/extensions/xep-0333.html>." > Message Processing Hints (XEP-0334) XEP-0334: Message Processing Hints <https://xmpp.org/extensions/xep-0334.html>." > JSON Containers (XEP-0335) XEP-0335: JSON Containers <https://xmpp.org/extensions/xep-0335.html>." > Data Forms - Dynamic Forms (XEP-0336) XEP-0336: Data Forms - Dynamic Forms <https://xmpp.org/extensions/xep-0336.html>." > From 771e9d7829b0b281bd9eac35cce38f8f48cd69c5 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Thu, 14 Mar 2024 10:03:01 +0100 Subject: [PATCH 048/145] Update copyright date range to 2024 --- xep.ent | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xep.ent b/xep.ent index 96ffc1955..eac348253 100644 --- a/xep.ent +++ b/xep.ent @@ -17,7 +17,7 @@ + + + + + + + + + + + +]]>     + + ]]> + +

    Romeo accepts the session, but his device doesn't handle touch inputs, so his client accepts every decive but the "touch" one (<device type="touch"/> is missing in its response):

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

    From this point the WebRTC session is established and a Data Channel is opened. Input events are then sent on the wire using CBOR as explained below.

    + +     + +     + + + +

    The &DESCRIPTION; element contains 0, 1, or more <device> child elements, indicating which devices the controlling entity wishes to access.

    +

    When the responder is sending back a Remote Control &DESCRIPTION;, it MUST add a &DESCRIPTION; element for each device that has been accepted (i.e., that the controlling device may control). The responder MUST NOT add a <device> element for a specific device if authorization has not been granted to control it. That means that the initiator's list of <device> elements MAY differ from the one of the responder (if the responder is not willing to let the controller control all devices, or if a specific device is not present on the controlled device).

    + +

    If no <device> element is specified, the session is a simple screen-sharing session. Note that in this case, at least one &xep0167; &CONTENT; element MUST be present; otherwise, the Jingle session MUST be terminated.

    + +

    <device> elements may have child elements specific to this device type and how it should be managed. Those elements may be specified by future specifications extending this one.

    + +

    Note: the Remote Control content may be unidirectional or bidirectional. All devices described here are unidirectional, meaning that the 'senders' attribute of the Remote Control &CONTENT; SHOULD be set to "initiator". However, future specifications may add devices that communicate in both directions (e.g., for haptic feedback, clipboard transmission, event pulling, LED feedback, etc.). In this case, the 'senders' attribute will be unset or set to "both".

    +

    A <device> element has a mandatory 'type' attribute, whose value is the kind of device that is requested by the controlling entity.

    +

    The current specification defines 4 <device> elements, described below.

    + + +

    <device type="mouse"/> is used when the controlling entity want to control the mouse pointer.

    +     + +

    <device type="wheel"/> is used when the controlling entity wants to send wheel events (e.g. for scrolling). Most of the time, this is a mouse wheel, but it can be an equivalent device not related to the mouse.

    +

    Note: when "mouse" device is accepted, responder SHOULD also accept wheel device. This has been made a separate device only to handle the case of independent wheel devices.

    +     + +

    <device type="touch"/> is used when the controlling entity wants to send touch events (e.g. screen taps, gestures).

    +

    Note: touch device MUST NOT be requested or accepted if no &xep0167; video stream is present in the session.

    +     + +

    <device type="keyboard"/> is used when the controlling entity wants to send keyboard events..

    +     +     + + +

    Events data are transmitted on the wire using CBOR. The reason is that input data must be sent as fast as possible in an efficient way, and CBOR is a standard, extensible, and efficient binary format well suited for this task. Furthermore, it is easily mapped to JSON, which makes it ideal to work with Web APIs and other APIs using JSON. Each event is encoded as a map, resulting as a stream of CBOR map objects on the wire.

    +

    To make understanding of the format easier and this document more readable, JSON is used in examples of this specification, but data needs to be ultimately serialized to/from CBOR to go on the wire.

    +

    The input event data format here is inspired by those found in Web APIs. This makes them straightforward to use in web-based applications, but also easy to adapt to underlying platforms as the Web APIs are abstracted and thought to work anywhere.

    +

    The general format of an input event looks like this:

    + + { + "type": "keyboard", + "device_id": "device_123", + "timestamp": 1712678325.0, + "key": "A", + } + +

    The first three keys ("type", "device_id", and "timestamp") are common to all device events. Other keys are device-specific.

    +

    The common keys are specified as follows:

    +
    + +
    type
    +
    +

    Type of event (e.g., "mouse", "keydown").
    + Field type: string
    + This key is REQUIRED.

    +
    +     + + +
    device_id
    +
    +

    Unique identifier of this device. If not specified, the receiver MUST assume that there is a single device of this kind (e.g., single mouse, single keyboard, single touch screen).
    + Field type: string
    + This key is OPTIONAL.

    +
    +     + + +
    timestamp
    +
    +

    Unix timestamp (time since Unix Epoch) of when the event occurred.
    + Field type: double
    + This key is REQUIRED.

    +
    +     + +
    + +     + + +

    Below is the description of the events for the 4 types of devices specified here. Future specifications may add new types of events.

    +

    Note that a controlling device doesn't need to have the device in question to send those events: for instance, a touch device doesn't have to send touch events, and can instead send mouse events to simulate a mouse, or an automation mechanism can simulate input devices.

    + + +

    Several events are user to describe mouse movement, and button pressed or released. They are inspired from DOM Events and have similar fields.

    + +

    The following keys are common to all mouse events.

    +

    Note: if a &xep0167; video stream is attached to the session, the "x" and "y" keys are related to the video stream (x=0 and y=0 means the upper left corner of the video stream). If not video stream is attached, "x" and "y" keys MUST NOT be sent. "movementX" and "movementY" MUST be used instead. Those values are mutually exclusive, it's either "x" and "y" or "movementX" and "movementY", the controlled device MUST handle both cases.

    +
    + +
    x
    +
    +

    The X coordinate of the mouse pointed for the event, relative to video stream.
    + Field type: double
    + This key is REQUIRED if "movementX and "movementY" are not sent, and MUST NOT be present if there is no &xep0167; video stream.

    +
    +     + + +
    y
    +
    +

    The Y coordinate of the mouse pointed for the event, relative to video stream.
    + Field type: double
    + This key is REQUIRED if "movementX and "movementY" are not sent, and MUST NOT be present if there is no &xep0167; video stream.

    +
    +     + + +
    movementX
    +
    +

    Relative X coordinate (difference between the X coordinate between this event and the previous mouse event).
    + Field type: double
    + This key is REQUIRED if "x" and "y" are not sent, and MUST NOT be present otherwise.

    +
    +     + + +
    movementY
    +
    +

    Relative Y coordinate (difference between the Y coordinate between this event and the previous mouse event).
    + Field type: double
    + This key is REQUIRED if "x" and "y" are not sent, and MUST NOT be present otherwise.

    +
    +     + +
    +     + + +

    The "mousedown" event means that one or more mouse buttons have been pressed.

    +

    The only key used in addition to common ones is the "buttons" key:

    +
    + +
    buttons
    +
    +

    Indicates which buttons have been pressed. This uses the same values as the equivalent DOM MouseEvent "buttons" MouseEvent: buttons property <https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/buttons>., except for value "0", which is not used here. Possible values are:

    +
      +
    • 1: Primary button (usually the left button)
      • +
    • 2: Secondary button (usually the right button)
      • +
    • 4: Auxiliary button (usually the mouse wheel button or middle button)
      • +
    • 8: 4th button (typically the "Browser Back" button)
      • +
    • 16: 5th button (typically the "Browser Forward" button)
      • +
    +

    Field type: int
    + This key is REQUIRED.

    +
    +     +
    +     + + +

    The "mousedown" event means that one or more mouse buttons have been released.

    +

    The only key used in addition to common ones is the "buttons" key, its definition is the same as for mousedown event.

    +     + + +

    The "mousemove" event means that the mouse pointer has been move. It does not contain any custom keys in addition to common ones.

    +     +     + + +

    One event is used to describe wheel move in all 3 axis (X, Y and Z).

    + + +

    The "wheel" event indicate that the wheel has been moved by one or more of the 3 axis.

    +

    Note that even if all keys are OPTIONAL, at least one "delta*" key MUST be set.

    +

    The only key used in addition to common ones is the "buttons" key:

    +
    + +
    deltaX
    +
    +

    Horizontal scroll amount.
    + Field type: double
    + This key is OPTIONAL and default to 0.

    +
    +     + +
    deltaY
    +
    +

    Vertical scroll amount.
    + Field type: double
    + This key is OPTIONAL and default to 0.

    +
    +     + +
    deltaZ
    +
    +

    Scroll amount for the Z axis.
    + Field type: double
    + This key is OPTIONAL and default to 0.

    +
    +     + +
    deltaMode
    +
    +

    Indicate the unit of delta* scroll values. This uses the same values as the equivalent DOM WheelEvent "deltaMode" WheelEvent: deltaMode property <https://developer.mozilla.org/en-US/docs/Web/API/WheelEvent/deltaMode>.. Possible values are:

    +
      +
    • 0: The delta values are specified in pixels.
      • +
    • 1: The delta values are specified in lines.
      • +
    • 2: The delta values are specified in pages.
      • +
    +

    Field type: int
    + This key is OPTIONAL and default to 0.

    +
    +     +
    +     +     + + +

    Three events are used to describe touches. They all have the same single "touches" key with is a (potentially empty) array of "touch" objects, as described below.

    + + +

    All touch events have a "touches" key which is an array of "touch" map. They represent the touch objects that are currently in contact with the surface. That means that even for the "touchend" event, it's the list of touch objects still in contact, not the removed ones.

    +

    The key usable in a touch map are specified below:

    +
    + +
    identifier
    +
    +

    An unique identifier for this touch object. This uses the same values as the equivalent DOM Touch "identifier" Touch <https://developer.mozilla.org/en-US/docs/Web/API/Touch>. A given touch point will have the same identifier for the duration of its movement around the surface.
    + Field type: string
    + This key is REQUIRED.

    +
    +     + +
    x
    +
    +

    The X coordinate of the mouse pointed for the event, relative to video stream.
    + Field type: double
    + This key is REQUIRED.

    +
    +     + + +
    y
    +
    +

    The Y coordinate of the mouse pointed for the event, relative to video stream.
    + Field type: double
    + This key is REQUIRED.

    +
    +     + + +
    radiusX
    +
    +

    This uses the same values as the equivalent DOM Touch "radiusX" Touch <https://developer.mozilla.org/en-US/docs/Web/API/Touch>. Returns the X radius of the ellipse that most closely circumscribes the area of contact with the screen. The value is in pixels of the same scale as screenX.
    + Field type: float
    + This key is OPTIONAL.

    +
    +     + + +
    radiusY
    +
    +

    This uses the same values as the equivalent DOM Touch "radiusY" Touch <https://developer.mozilla.org/en-US/docs/Web/API/Touch>. Returns the Y radius of the ellipse that most closely circumscribes the area of contact with the screen. The value is in pixels of the same scale as screenY.
    + Field type: float
    + This key is OPTIONAL.

    +
    +     + + +
    rotationAngle
    +
    +

    This uses the same values as the equivalent DOM Touch "rotationAngle" Touch <https://developer.mozilla.org/en-US/docs/Web/API/Touch>. Returns the angle (in degrees) that the ellipse described by radiusX and radiusY must be rotated, clockwise, to most accurately cover the area of contact between the user and the surface.
    + Field type: float
    + This key is OPTIONAL.

    +
    +     + + +
    force
    +
    +

    This uses the same values as the equivalent DOM Touch "force" Touch <https://developer.mozilla.org/en-US/docs/Web/API/Touch>. Returns the amount of pressure being applied to the surface by the user, as a float between 0.0 (no pressure) and 1.0 (maximum pressure).
    + Field type: float
    + This key is OPTIONAL.

    +
    +     + +
    +     + + +

    One or more touch objects are placed on the surface.

    +     + + +

    One or more touch objects are removed from the surface.

    +     + + +

    One or more touch objects are moved along the surface.

    +     +     + + +

    There are two keyboard events, they use the same keys.

    + + +

    The following keys are common to all keyboard events:

    +
    + +
    key
    +
    +

    A string representing the key value. This use DOM key values, and it the same as the equivalent DOM KeyboardEvent "key" KeyboardEvent: key property <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key>. You can check the possible values at https://developer.mozilla.org/en-US/docs/Web/API/UI_Events/Keyboard_event_key_values. The W3C Keyboard Event Viewer can also be useful to check keys value while working with this specification.
    + Field type: string
    + This key is REQUIRED.

    +
    +     + +
    location
    +
    +

    A number representing the location of the key on the keyboard. This uses the same values as the equivalent DOM KeyboardEvent "location" KeyboardEvent: location property <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/location>, except for value "0", which is not used here. Possible values are (the values description is an abstract of Mozilla Developer Network KeyboardEvent: location property <https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/location> available under Creative Commons Attribution-ShareAlike license (CC-BY-SA), v2.5 or any later version. as specified at <https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Attrib_copyright_license>.):

    +
      +
    • 1: The key was the left-hand version of the key; for example, the left-hand Control key was pressed on a standard 101 key US keyboard. This value is only used for keys that have more than one possible location on the keyboard.
      • +
    • 2: The key was the right-hand version of the key; for example, the right-hand Control key is pressed on a standard 101 key US keyboard. This value is only used for keys that have more than one possible location on the keyboard.
      • +
    • 3: The key was on the numeric keypad, or has a virtual key code that corresponds to the numeric keypad.
      • +
    • 4: The key was on a mobile device; this can be on either a physical keypad or a virtual keyboard.
      • +
    • 5: The key was a button on a game controller or a joystick on a mobile device.
      • +
    +

    Field type: int
    + This key is OPTIONAL.

    +
    +     +
    +     + + +

    A key is pressed.

    +     + + +

    A key is released.

    +     + +     + + +

    This section summarize the possible event key values for the devices specified here.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    KeyDeviceEvent TypesDescriptionRequirementRemarksData Type
    buttonsMousemousedown, mouseupIndicates which buttons have been pressed or releasedRequired-int
    deltaModeWheelwheelIndicate the unit of delta* scroll valuesOptionalDefault to 0int
    deltaXWheelwheelHorizontal scroll amountOptionalDefault to 0. At least one "delta*" key must be setdouble
    deltaYWheelwheelVertical scroll amountOptionalDefault to 0. At least one "delta*" key must be setdouble
    deltaZWheelwheelScroll amount for the Z axisOptionalDefault to 0. At least one "delta*" key must be setdouble
    keyKeyboardkeydown, keyupA string representing the key value. Uses DOM key valuesRequired-string
    locationKeyboardkeydown, keyupA number representing the location of the key on the keyboardOptional-int
    movementXMousemousemoveRelative X coordinate (difference between the X coordinate of this event and the previous mouse event)Required*Only required if "x" and "y" are not sentdouble
    movementYMousemousemoveRelative Y coordinate (difference between the Y coordinate of this event and the previous mouse event)Required*Only required if "x" and "y" are not sentdouble
    touchesTouchtouchstart, touchend, touchmoveA list of touch objects.Required-List of touch objects
    typeAllAll eventsType of event (e.g., "mouse", "keydown")Required-string
    device_idAllAll eventsUnique identifier of this deviceOptionalFor single device type, it's not neededstring
    timestampAllAll eventsUnix timestamp (time since Unix Epoch) of when the event occurredRequired-double
    xMouse, Touchmousedown, mouseup, mousemove, touchstart, touchend, touchmoveX coordinate of the mouse pointer or touch point, relative to video streamRequired*Only required if "movementX" and "movementY" are not sent and if there is a &xep0167; video streamdouble
    yMouse, Touchmousedown, mouseup, mousemove, touchstart, touchend, touchmoveY coordinate of the mouse pointer or touch point, relative to video streamRequired*Only required if "movementX" and "movementY" are not sent and if there is a &xep0167; video streamdouble
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    KeyDescriptionRequirementRemarksData Type
    identifierAn unique identifier for this touch objectRequired-string
    forceReturns the amount of pressure being applied to the surface by the user, as a float between 0.0 (no pressure) and 1.0 (maximum pressure)Optional-float
    radiusXReturns the X radius of the ellipse that most closely circumscribes the area of contact with the screenOptional-float
    radiusYReturns the Y radius of the ellipse that most closely circumscribes the area of contact with the screenOptional-float
    rotationAngleReturns the angle (in degrees) that the ellipse must be rotated, clockwise, to most accurately cover the area of contact between the user and the surfaceOptional-float
    xX coordinate of the touch objectRequiredRelated to the video stream (if present)double
    yY coordinate of the touch objectRequiredRelated to the video stream (if present)double
    +     +     + + +

    It is expected that future specifications will extend this one. To make an extension, we recommand to follows those rules:

    +
      +
    • Use "Remote Control" in your title to easily find extensions. "Remote Control: Clipboard" or "Remote Control: Gamepad" are good extension titles.
      • +
    • Describe the <device> element and if necessary any device-specific child.
      • +
    • Specify the new events in the same way as here: consistency make it easier to follow different specifications.
      • +
    • Indicate it the event is unidirectional (only send from controlling device to controlled device) or bidirectional (controlled device can send data too).
      • +
    • For each key of the new event, give a short description, the data type, and indicate wether the data is OPTIONAL or REQUIRED.
      • +
    • The namespace 'urn:xmpp:jingle:apps:remote-control:xxx:y' should be used for extension of this specification, where xxx is a short name, usually the name of the new managed device, and y is the usual specification version number.
      • +
    +     + + + +

    A controlled device MAY send data back to the controlling device, for instance, to send force haptic feedback such as vibration or force feedback. All devices in this specification are unidirectional, but future specifications may add bidirectional ones. If any bidirectional device is requested, the 'senders' attribute of the Remote Control content MUST be unset or set to "both".

    +

    It is up to the controlling entity to optimize or not the data sent with whatever appropriate algorithm. For instance, if a mouse is moved twice without a button or keyboard being pressed in-between, the controlling entity could send a single mouse event that is a combination of the two moves.

    +

    If a Remote Control &CONTENT; is used with &xep0167; &CONTENT;, the session is a Remote Control session, and not a video call; it SHOULD be presented as a Remote Control session to the user, and the media streams are used as feedback and/or support as described above.

    +     + + +

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

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

    Obviously, allowing an entity to remotely control a device is giving a high and dangerous level of access, similar to having the person using the controlling device sitting in front of this computer.

    +

    Before starting the remote control session, the client SHOULD ask for permission from the user of the controlled device in a clear and understandable way, explaining in non-technical terms that the other person will fully control the inputs of the device. A client MAY allow for automatic permission (e.g., to control an IoT device or a work computer from home by well-known entities), but this must be done clearly or stated somewhere, and the controlling entity SHOULD be duly checked.

    +

    In addition, a controlled device SHOULD display an obvious, clear, and always visible indicator that the inputs are currently being remotely controlled, with an obvious and easily accessible button to stop remote control immediately.

    +     + + +

    TODO

    +     + +

    TODO

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

    Thanks to NLNet foundation/NGI Assure for funding the work on this specification.

    +     +     diff --git a/xep.ent b/xep.ent index d06b29d6a..4acfb5180 100644 --- a/xep.ent +++ b/xep.ent @@ -709,6 +709,7 @@ THE SOFTWARE. RFC 9000 RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport <http://tools.ietf.org/html/rfc9000>." > RFC 7677 RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms <http://tools.ietf.org/html/rfc7677>." > RFC 5705 RFC 5705: Keying Material Exporters for Transport Layer Security (TLS) <http://tools.ietf.org/html/rfc5705>." > +RFC 8949 RFC 8949: Concise Binary Object Representation (CBOR) <http://tools.ietf.org/html/rfc8949>." > RFC 9266 RFC 9266: Channel Bindings for TLS 1.3 <http://tools.ietf.org/html/rfc9266>." > RFC 9460 RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) <http://tools.ietf.org/html/rfc9460>." > @@ -1541,7 +1542,7 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates COnferences with LIghtweight BRIdging (COLIBRI) (XEP-0340) XEP-0340: COnferences with LIghtweight BRIdging (COLIBRI) <https://xmpp.org/extensions/xep-0340.html>." > Rayo CPA (XEP-0341) XEP-0341: Rayo CPA <https://xmpp.org/extensions/xep-0341.html>." > Rayo Fax (XEP-0342) XEP-0342: Rayo Fax <https://xmpp.org/extensions/xep-0342.html>." > -Use of DTLS/SCTP in Jingle ICE-UDP (XEP-0343) XEP-0343: Use of DTLS/SCTP in Jingle ICE-UDP <https://xmpp.org/extensions/xep-0343.html>." > +Signaling WebRTC datachannels in Jingle (XEP-0343) XEP-0343: Signaling WebRTC datachannels in Jingle <https://xmpp.org/extensions/xep-0343.html>." > Impact of TLS and DNSSEC on Dialback (XEP-0344) XEP-0344: Impact of TLS and DNSSEC on Dialback <https://xmpp.org/extensions/xep-0344.html>." > Form of Membership Applications (XEP-0345) XEP-0345: Form of Membership Applications <https://xmpp.org/extensions/xep-0345.html>." > Form Discovery and Publishing (XEP-0346) XEP-0346: Form Discovery and Publishing <https://xmpp.org/extensions/xep-0346.html>." > From 5a0e3e9b41693c836858d27f4a5816f9ab286ac9 Mon Sep 17 00:00:00 2001 From: Marvin W Date: Mon, 3 Jun 2024 10:55:05 +0200 Subject: [PATCH 092/145] XEP-0421: Incorporate feedback from Last Call --- xep-0421.xml | 67 +++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 61 insertions(+), 6 deletions(-) diff --git a/xep-0421.xml b/xep-0421.xml index da89f5d44..536451fe2 100644 --- a/xep-0421.xml +++ b/xep-0421.xml @@ -30,6 +30,17 @@ xsf@larma.de jabber@larma.de + + 0.2.0 + 2024-05-28 + mw +
      +
    • Make explicit that one can't just hash the real JID.
      • +
    • Expand security considerations.
      • +
    • Add schema.
      • +
    • Fix some examples captions and casing
      • +
    +     0.1.0 2019-08-20 @@ -97,14 +108,14 @@ attaches an <occupant-id> element to the presence sent to all occupants in the room.

    - ]]> - - Harpier cries: 'tis time, 'tis time. ]]> -

    The occupant identifier MUST have a maximum length of 128 characters. The @@ -201,8 +215,25 @@

    If a MUC uses occupant identifiers, nickname changes will be visible to - all occupants of the room. Clients MAY warn users about this circumstance - before joining the room. + all occupants of the room. Clients may warn users about this circumstance + before joining the room or when changing the nickname. +

    +

    + When the MUC service does not support this specification, the server will + likely forward any <occupant-id> included in <message>s sent by + other room occupants and reflected by the MUC service. Receiving clients + must be careful to only process occupant identifiers if the MUC server + advertises support for this specification as described in the + Discovering support section. +

    +

    + The anonymity property of occupant identifiers is crucial to not + accidentally reveal an occupant's real bare JID to other room occupants. + Specifically, a simple hash over the occupant's real bare JID is not + sufficient as an occupant identifier, as unsalted hashes can be reversed + easily based on a dictionary of candidate JIDs. Review the + Occupant ID generation section for more + details.

    @@ -216,4 +247,28 @@     + + + + + + + + + + + + + + + + + + +]]> + From 178425890d6c7e724c37626a0e5280e100b79ae5 Mon Sep 17 00:00:00 2001 From: nicoco Date: Wed, 5 Jun 2024 12:48:51 +0200 Subject: [PATCH 093/145] New XEP: Chat Notification Settings --- inbox/notification-filter.xml | 100 ++++++++++++++++++++++++++++++++++ xep.ent | 8 +++ 2 files changed, 108 insertions(+) create mode 100644 inbox/notification-filter.xml diff --git a/inbox/notification-filter.xml b/inbox/notification-filter.xml new file mode 100644 index 000000000..704bbcb88 --- /dev/null +++ b/inbox/notification-filter.xml @@ -0,0 +1,100 @@ + + + + +%ents; +]> + + +
    + Chat notification settings + This document defines an XMPP protocol extension to synchronise per-chat notification settings across different clients. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XMPP IM + XEP-0163 + + + + notification-settings + &nicoco; + + 0.0.1 + 2024-02-06 + nc +

    Initial version.

     +     +
    + +

    "Notifications" are (usually) pop-up windows that appear in a visible area of the screen even when the emitting application is in the background, often triggering a sound alert. Instant messaging clients expectedly use notifications to inform users when they receive a message.

    +

    Users may want to customise which conversations should trigger notifications and under which conditions. In practice, this is already implemented in many instant messaging clients, including XMPP clients. This specification proposes a mechanism to synchronise per-discussion notification settings across different XMPP clients.

    +     + +

    Notification settings are represented by the <notify> element. It only has one attribute named "when", which can take three values: "never", "always" and "on-mention". This element MUST be a child of an element identifying a specific chat by its JID, such as a &xep0402; <extensions>.

    +&namespace; +]]> +     + +

    The "on-mention" notification settings SHOULD NOT be used for direct chats but only for group chats.

    +

    The "on-mention" notification SHOULD rely on the user's nickname being spelled out in an incoming message in a group-chat, but MAY rely on other mechanism to "ping" the user, such as a &xep0461; or &xep0444; element referring a user's previous message.

    +

    In the absence of a notification settings for a given chat, "always" SHOULD be assumed for direct chats and private group chats, and "on-mention" for public group chats.

    +     + +

    See considerations in &xep0402;.

    +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespace:

    +
      +
    • &namespace;
      • +
    +

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

    +     + + &NSVER; + +     + + + + + + + + The protocol documented by this schema is defined in + XEP-]]>&xep-number;&xep-number; + + + + + + + + + + + + + + +]]> + +     diff --git a/xep.ent b/xep.ent index 4acfb5180..b6e47bb51 100644 --- a/xep.ent +++ b/xep.ent @@ -1165,6 +1165,14 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates travis@burtrum.org travis@burtrum.org https://moparisthebest.com/ + +" > + + Nicolas + Cedilnik + nicoco@nicoco.fr + nicoco@nicoco.fr " > From 1136a52dd1a1f39a5510e754b62c2ad76793eea5 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Wed, 5 Jun 2024 12:49:16 +0200 Subject: [PATCH 094/145] Move XEP-0440 back to experimental --- xep-0440.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0440.xml b/xep-0440.xml index 17fed6bec..994475b72 100644 --- a/xep-0440.xml +++ b/xep-0440.xml @@ -12,7 +12,7 @@ This specification allows servers to annouce their supported SASL channel-binding types to clients. &LEGALNOTICE; 0440 - Proposed + Experimental 2024-05-20 Standards Track Standards From 555d33bf1b13f3be9338b5ac97acdac699afcc0d Mon Sep 17 00:00:00 2001 From: nicoco Date: Mon, 17 Jun 2024 18:43:02 +0200 Subject: [PATCH 095/145] notification-filter: Update notification settings XEP after community feedback --- inbox/notification-filter.xml | 56 +++++++++++++++++++++++++++++------ 1 file changed, 47 insertions(+), 9 deletions(-) diff --git a/inbox/notification-filter.xml b/inbox/notification-filter.xml index 704bbcb88..ccf7c7566 100644 --- a/inbox/notification-filter.xml +++ b/inbox/notification-filter.xml @@ -11,8 +11,8 @@ Chat notification settings This document defines an XMPP protocol extension to synchronise per-chat notification settings across different clients. &LEGALNOTICE; - xxxx - ProtoXEP + &xep-number; + Experimental Standards Track Standards Council @@ -26,6 +26,10 @@ notification-settings &nicoco; + 0.0.2 + 2024-02-08 + nc +

    Update after discussions on the standards@ mailing list.

     0.0.1 2024-02-06 nc @@ -36,16 +40,50 @@

    "Notifications" are (usually) pop-up windows that appear in a visible area of the screen even when the emitting application is in the background, often triggering a sound alert. Instant messaging clients expectedly use notifications to inform users when they receive a message.

    Users may want to customise which conversations should trigger notifications and under which conditions. In practice, this is already implemented in many instant messaging clients, including XMPP clients. This specification proposes a mechanism to synchronise per-discussion notification settings across different XMPP clients.

    - -

    Notification settings are represented by the <notify> element. It only has one attribute named "when", which can take three values: "never", "always" and "on-mention". This element MUST be a child of an element identifying a specific chat by its JID, such as a &xep0402; <extensions>.

    -&namespace; + + +

    Notification settings are represented by the <notify> element. This element MUST be a child of an element identifying a specific chat by its JID, such as a &xep0402; <extensions>.

    +

    This protocol specifies three children for the <notify> element, each corresponding to a notification setting: <always> <on-mention> and <never>.

    +&namespace; + + +]]> +     + +

    One might want to choose different notification settings depending on the client type. In this case, a "client-type" attribute can be added to the notification setting, using registered Service Discovery Identities.

    +&namespace; + + + ]]> +     + +

    Finally, clients can use this specification to synchronise finer-grained notification settings using custom namespaces.

    +&namespace; + + + + + night-time-only + ... + + + raining + ... + + + +]]> +     -

    The "on-mention" notification settings SHOULD NOT be used for direct chats but only for group chats.

    -

    The "on-mention" notification SHOULD rely on the user's nickname being spelled out in an incoming message in a group-chat, but MAY rely on other mechanism to "ping" the user, such as a &xep0461; or &xep0444; element referring a user's previous message.

    +

    Entities implementing this specification MUST NOT delete or alter the advanced notification settings they do not support when updating the notification settings for a given chat.

    +

    If there is more than one notification setting for a given chat, entities implementing this specification MUST specify which client type they apply to. The (notification setting, client-type) pairs MUST be unique.

    +

    Entities using advanced notification settings SHOULD attempt to provide the basic notification setting which is the closest to what they offer as a fallback for other entities.

    +

    The "on-mention" notification MAY rely on the user's nickname being spelled out in an incoming message in a group chat, but SHOULD rely on mechanisms to explicitly "ping" the user, such as a &xep0461; element referring a user's previous message or a specific mention, such as a &xep0372; mention.

    In the absence of a notification settings for a given chat, "always" SHOULD be assumed for direct chats and private group chats, and "on-mention" for public group chats.

     From 6ee85336c95bc0a765504324f804ea9924add91d Mon Sep 17 00:00:00 2001 From: Stephen Paul Weber Date: Wed, 5 Jun 2024 13:26:46 -0500 Subject: [PATCH 096/145] New XEP: WebXDC --- inbox/webxdc.xml | 164 +++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 8 +++ 2 files changed, 172 insertions(+) create mode 100644 inbox/webxdc.xml diff --git a/inbox/webxdc.xml b/inbox/webxdc.xml new file mode 100644 index 000000000..d5f87bcf0 --- /dev/null +++ b/inbox/webxdc.xml @@ -0,0 +1,164 @@ + + + WebXDC"> + +%ents; +]> + + +
    + WebXDC + This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XMPP IM + + + + webxdc + &singpolyma; + + 0.0.1 + 2024-06-05 + spw +

    Initial version.

     +     +
    + +

    &webxdc; is a specification for sharing interactive embeddable widgets built with web-like technologies (HTML, JavaScript) via a chat platform, and sharing state between participants in the chat without allowing external network connections. In order to use these, the host protocol must define a way to transmit the widgets and the associated state updates.

    +     + +

    A widget may be attached to a message using any file-transfer mechanism supported by the client, such as &xep0066; or &xep0385;. The message MUST contain a <thread/> element with a new, unique id.

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + + application/xdc+zip + Calendar + 3032449 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + + + + +

    When a widget needs to communicate an update to other participants, this update may contain the following information:

    + + + + + + + + + + + + + + + + + + + + + +
    ItemDescription
    infoHuman readable message to send to the chat
    summaryText which may be shown next to the widget launcher
    documentTitle which may be shown next to the widget launcher
    payloadArbitrary JSON serializable value
    +

    These items, except for the info item, are delivered in a message which MUST have the same <thread> as the message which originally delivered the widget itself, as children of an element <x xmlns="urn:xmpp:webxdc:0"> as defined below.

    + +

    The info item is human-readable and is not needed by the widget itself, thus it is appropriate to transmit it anywhere that it might be visible to all participants, such as in a message body. If this is the only item present, an empty <x> element SHOULD still be included in the message to signal this update came from the widget.

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + Juliet has added an event. +]]> +     + +

    These items are delivered as children of the <x> item, and in the same namespace. The document item using a <document> child and the summary item using a <summary> child.

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + Our Calendar + 12 events + +]]> +     + +

    The payload item is delivered using &xep0335; as a child of the <x> element

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + {} + +]]> +     +     + +

    None

    +     + +

    This XEP does not have any specific security considerations, however it is assumed that it will be paired with an implementation of &webxdc; which requires very careful sandboxing.

    +     + +

    It should be clear to users that their actions inside an embedded widget may be transmitted to other participants.

    +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespace: urn:xmpp:webxdc:0

    +     + + &NSVER; + +     + + + + + + + + The protocol documented by this schema is defined in + XEP-]]>&xep-number;&xep-number; + + + + + + + + + + + + + + +]]> + +     diff --git a/xep.ent b/xep.ent index b6e47bb51..ec9bd4c02 100644 --- a/xep.ent +++ b/xep.ent @@ -1175,6 +1175,14 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates nicoco@nicoco.fr " > + + Stephen Paul + Weber + singpolyma@singpolyma.net + singpolyma@singpolyma.net + +" > From 76084c4547cf8d50890163024b085b7b5530d29f Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Mon, 10 Jun 2024 13:11:46 +0200 Subject: [PATCH 097/145] XEP-0153: Add missing EMAIL/USERID element in example MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The implementation notes in XEP-0054 say “Email addresses MUST be contained in a element, not included as CDATA within the element.” --- xep-0153.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/xep-0153.xml b/xep-0153.xml index 6129dd946..7607a533c 100644 --- a/xep-0153.xml +++ b/xep-0153.xml @@ -26,6 +26,12 @@ http://www.xmpp.org/schemas/vcard-avatar.xsd &stpeter; + + 1.1.1 + 2024-06-10 + egp +

    XEP-0054 says “Email addresses MUST be contained in a <USERID> element”.

     +     1.1 2018-02-26 @@ -103,7 +109,7 @@ JulietCapulet - jcapulet@shakespeare.lit + jcapulet@shakespeare.lit image/jpeg @@ -151,7 +157,7 @@ JulietCapulet - jcapulet@shakespeare.lit + jcapulet@shakespeare.lit image/jpeg From e0cebe78fce2fa3a15ed158a85180a6a806d05a9 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 24 May 2024 14:02:31 +0200 Subject: [PATCH 098/145] XEP-0045: Add punctuation to improve readability --- xep-0045.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index 24fcaac52..07f91955e 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -2912,7 +2912,7 @@ [ ... ] ]]>     -

    A user cannot be kicked by a moderator with a lower affiliation. Therefore, if a moderator who is a member attempts to kick an admin or a moderator who is a member or admin attempts to kick an owner, the service MUST deny the request and return a ¬allowed; error to the sender:

    +

    A user cannot be kicked by a moderator with a lower affiliation. Therefore, if a moderator who is a member attempts to kick an admin, or a moderator who is a member or admin attempts to kick an owner, the service MUST deny the request and return a ¬allowed; error to the sender:

    Date: Mon, 17 Jun 2024 18:54:45 +0200 Subject: [PATCH 099/145] fixup in notification-filter update --- inbox/notification-filter.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/inbox/notification-filter.xml b/inbox/notification-filter.xml index ccf7c7566..5415f48e1 100644 --- a/inbox/notification-filter.xml +++ b/inbox/notification-filter.xml @@ -12,7 +12,7 @@ This document defines an XMPP protocol extension to synchronise per-chat notification settings across different clients. &LEGALNOTICE; &xep-number; - Experimental + ProtoXEP Standards Track Standards Council From 3d2f4023b21f5e83561ba09d7c626bae23b9fbfc Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Thu, 20 Jun 2024 10:50:47 +0200 Subject: [PATCH 100/145] Move 'XEP-0491: WebXDC' to Experimental --- xep-0491.xml | 174 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 175 insertions(+) create mode 100644 xep-0491.xml diff --git a/xep-0491.xml b/xep-0491.xml new file mode 100644 index 000000000..1be14e48a --- /dev/null +++ b/xep-0491.xml @@ -0,0 +1,174 @@ + + + WebXDC"> + +%ents; +]> + + +
    + WebXDC + This document defines an XMPP protocol extension to communicate WebXDC widgets and their state updates. + &LEGALNOTICE; + &xep-number; + Experimental + Standards Track + Standards + Council + + XMPP Core + XMPP IM + + + + webxdc + &singpolyma; + + 0.1.0 + 2024-06-20 + XEP Editor: dg + +
      +
    • Promoted to Experimental
      • +
    +     +     + + 0.0.1 + 2024-06-05 + spw +

    Initial version.

     +     +
    + +

    &webxdc; is a specification for sharing interactive embeddable widgets built with web-like technologies (HTML, JavaScript) via a chat platform, and sharing state between participants in the chat without allowing external network connections. In order to use these, the host protocol must define a way to transmit the widgets and the associated state updates.

    +     + +

    A widget may be attached to a message using any file-transfer mechanism supported by the client, such as &xep0066; or &xep0385;. The message MUST contain a <thread/> element with a new, unique id.

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + + application/xdc+zip + Calendar + 3032449 + 2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU= + + + + +

    When a widget needs to communicate an update to other participants, this update may contain the following information:

    + + + + + + + + + + + + + + + + + + + + + +
    ItemDescription
    infoHuman readable message to send to the chat
    summaryText which may be shown next to the widget launcher
    documentTitle which may be shown next to the widget launcher
    payloadArbitrary JSON serializable value
    +

    These items, except for the info item, are delivered in a message which MUST have the same <thread> as the message which originally delivered the widget itself, as children of an element <x xmlns="urn:xmpp:webxdc:0"> as defined below.

    + +

    The info item is human-readable and is not needed by the widget itself, thus it is appropriate to transmit it anywhere that it might be visible to all participants, such as in a message body. If this is the only item present, an empty <x> element SHOULD still be included in the message to signal this update came from the widget.

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + Juliet has added an event. +]]> +     + +

    These items are delivered as children of the <x> item, and in the same namespace. The document item using a <document> child and the summary item using a <summary> child.

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + Our Calendar + 12 events + +]]> +     + +

    The payload item is delivered using &xep0335; as a child of the <x> element

    + + 018fe972-ea89-7f4b-90f8-729b85b7f32d + + {} + +]]> +     +     + +

    None

    +     + +

    This XEP does not have any specific security considerations, however it is assumed that it will be paired with an implementation of &webxdc; which requires very careful sandboxing.

    +     + +

    It should be clear to users that their actions inside an embedded widget may be transmitted to other participants.

    +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespace: urn:xmpp:webxdc:0

    +     + + &NSVER; + +     + + + + + + + + The protocol documented by this schema is defined in + XEP-]]>&xep-number;&xep-number; + + + + + + + + + + + + + + +]]> + +     diff --git a/xep.ent b/xep.ent index ec9bd4c02..7d42c8d3e 100644 --- a/xep.ent +++ b/xep.ent @@ -1714,4 +1714,5 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates MUC Token Invite (XEP-0488)XEP-0488: MUC Token Invite <https://xmpp.org/extensions/xep-0488.html>."> Reporting Account Affiliations (XEP-0489)XEP-0489: Reporting Account Affiliations <https://xmpp.org/extensions/xep-0489.html>."> Message Displayed Synchronization (XEP-0490)XEP-0490: Message Displayed Synchronization <https://xmpp.org/extensions/xep-0490.html>."> +WebXDC (XEP-0491)XEP-0491: WebXDC <https://xmpp.org/extensions/xep-0491.html>."> From ced83c62e89fede2f3b52d476968133ef3c8ae01 Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Thu, 20 Jun 2024 11:04:14 +0200 Subject: [PATCH 101/145] XEP-0107 fix minor typo --- xep-0107.xml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xep-0107.xml b/xep-0107.xml index ec38d0c2c..1d87697a2 100644 --- a/xep-0107.xml +++ b/xep-0107.xml @@ -7,7 +7,7 @@
    User Mood - This specification defines a payload format for communicating information about user moods, such as whether a person is currently happy, sad, angy, or annoyed. The payload format is typically transported using the personal eventing protocol, a profile of XMPP publish-subscribe specified in XEP-0163. + This specification defines a payload format for communicating information about user moods, such as whether a person is currently happy, sad, angry, or annoyed. The payload format is typically transported using the personal eventing protocol, a profile of XMPP publish-subscribe specified in XEP-0163. &LEGALNOTICE; 0107 Draft @@ -26,6 +26,12 @@ &stpeter; &ralphm; + + 1.2.2 + 2024-06-20 + XEP Editor (dg) + Fixed typo + 1.2.1 2018-03-13 From 7636aa3732a4c47f40c418301c9aeb1876512605 Mon Sep 17 00:00:00 2001 From: Linus Jahn Date: Fri, 24 May 2024 23:54:55 +0200 Subject: [PATCH 102/145] FAST/XEP-0484: Link to latest draft of HT SASL mechanism --- xep-0484.xml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/xep-0484.xml b/xep-0484.xml index c57ac9149..f51856330 100644 --- a/xep-0484.xml +++ b/xep-0484.xml @@ -1,7 +1,7 @@ - draft-schmaus-sasl-ht-08draft-schmaus-sasl-ht-08: The Hashed Token SASL Mechanism <https://datatracker.ietf.org/doc/draft-schmaus-kitten-sasl-ht/08/>." > + draft-schmaus-sasl-ht-09draft-schmaus-sasl-ht-09: The Hashed Token SASL Mechanism <https://datatracker.ietf.org/doc/draft-schmaus-kitten-sasl-ht/09/>." > %ents; ]> @@ -23,6 +23,16 @@ fast &mwild; + + 0.1.1 + 2024-05-24 + lnj + +
      +
    • Link to latest draft version (09) of the HT SASL mechanism.
      • +
    +     +     0.1.0 2023-12-11 From 8abf08ea897e1ee00ead733f68dc9d48675de59a Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Mon, 1 Jul 2024 14:11:52 +0200 Subject: [PATCH 103/145] Move 'XEP-0492: Chat notification settings' to Experimental --- xep-0492.xml | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep.ent | 1 + 2 files changed, 151 insertions(+) create mode 100644 xep-0492.xml diff --git a/xep-0492.xml b/xep-0492.xml new file mode 100644 index 000000000..03c36b51e --- /dev/null +++ b/xep-0492.xml @@ -0,0 +1,150 @@ + + + + +%ents; +]> + + +
    + Chat notification settings + This document defines an XMPP protocol extension to synchronise per-chat notification settings across different clients. + &LEGALNOTICE; + &xep-number; + Experimental + Standards Track + Standards + Council + + XMPP Core + XMPP IM + XEP-0163 + + + + notification-settings + &nicoco; + + 0.1.0 + 2024-07-01 + XEP Editor: dg + +
      +
    • Promoted to Experimental
      • +
    +     +     + + 0.0.2 + 2024-06-08 + nc +

    Update after discussions on the standards@ mailing list.

     +     + + 0.0.1 + 2024-06-06 + nc +

    Initial version.

     +     +
    + +

    "Notifications" are (usually) pop-up windows that appear in a visible area of the screen even when the emitting application is in the background, often triggering a sound alert. Instant messaging clients expectedly use notifications to inform users when they receive a message.

    +

    Users may want to customise which conversations should trigger notifications and under which conditions. In practice, this is already implemented in many instant messaging clients, including XMPP clients. This specification proposes a mechanism to synchronise per-discussion notification settings across different XMPP clients.

    +     + + +

    Notification settings are represented by the <notify> element. This element MUST be a child of an element identifying a specific chat by its JID, such as a &xep0402; <extensions>.

    +

    This protocol specifies three children for the <notify> element, each corresponding to a notification setting: <always> <on-mention> and <never>.

    +&namespace; + + +]]> +     + +

    One might want to choose different notification settings depending on the client type. In this case, a "client-type" attribute can be added to the notification setting, using registered Service Discovery Identities.

    +&namespace; + + + +]]> +     + +

    Finally, clients can use this specification to synchronise finer-grained notification settings using custom namespaces.

    +&namespace; + + + + + night-time-only + ... + + + raining + ... + + + +]]> +     +     + +

    Entities implementing this specification MUST NOT delete or alter the advanced notification settings they do not support when updating the notification settings for a given chat.

    +

    If there is more than one notification setting for a given chat, entities implementing this specification MUST specify which client type they apply to. The (notification setting, client-type) pairs MUST be unique.

    +

    Entities using advanced notification settings SHOULD attempt to provide the basic notification setting which is the closest to what they offer as a fallback for other entities.

    +

    The "on-mention" notification MAY rely on the user's nickname being spelled out in an incoming message in a group chat, but SHOULD rely on mechanisms to explicitly "ping" the user, such as a &xep0461; element referring a user's previous message or a specific mention, such as a &xep0372; mention.

    +

    In the absence of a notification settings for a given chat, "always" SHOULD be assumed for direct chats and private group chats, and "on-mention" for public group chats.

    +     + +

    See considerations in &xep0402;.

    +     + +

    This document requires no interaction with &IANA;.

    +     + + +

    This specification defines the following XML namespace:

    +
      +
    • &namespace;
      • +
    +

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

    +     + + &NSVER; + +     + + + + + + + + The protocol documented by this schema is defined in + XEP-]]>&xep-number;&xep-number; + + + + + + + + + + + + + + +]]> + +     diff --git a/xep.ent b/xep.ent index 7d42c8d3e..f11e74651 100644 --- a/xep.ent +++ b/xep.ent @@ -1715,4 +1715,5 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Reporting Account Affiliations (XEP-0489)XEP-0489: Reporting Account Affiliations <https://xmpp.org/extensions/xep-0489.html>."> Message Displayed Synchronization (XEP-0490)XEP-0490: Message Displayed Synchronization <https://xmpp.org/extensions/xep-0490.html>."> WebXDC (XEP-0491)XEP-0491: WebXDC <https://xmpp.org/extensions/xep-0491.html>."> +Chat notification settings (XEP-0492)XEP-0492: Chat notification settings <https://xmpp.org/extensions/xep-0492.html>."> From 20d49550e2f1cc6ae16e678ca56d56225d35d129 Mon Sep 17 00:00:00 2001 From: linkmauve Date: Mon, 1 Jul 2024 14:29:52 +0200 Subject: [PATCH 104/145] XEP-0484: Add an XML Schema and fix some indentation --- xep-0484.xml | 97 ++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 76 insertions(+), 21 deletions(-) diff --git a/xep-0484.xml b/xep-0484.xml index f51856330..c8cbf1581 100644 --- a/xep-0484.xml +++ b/xep-0484.xml @@ -23,6 +23,18 @@ fast &mwild; + + 0.2.0 + 2024-06-30 + egp + +
      +
    • Added an XML Schema.
      • +
    • Fixed text where 'count' was assumed to be an element, not an attribute.
      • +
    • Fixed indentation in a few examples.
      • +
    +     +     0.1.1 2024-05-24 @@ -96,7 +108,7 @@ - ]]> +]]>

    Initially, the client won't have any FAST token to authenticate with. To obtain a token, it MUST first authenticate using another method, e.g. using a password.

    @@ -104,13 +116,13 @@

    In the following example, the client authenticates with SCRAM-SHA-1-PLUS using a password, but requests a token for fast reauthentication in the future, using the HT-SHA-256-ENDP mechanism.

    - [base64 encoded SASL data] - - AwesomeXMPP - - + [base64 encoded SASL data] + + AwesomeXMPP + + - ]]> +]]>

    Upon receiving a token request and successfully authenticating the client, the server generates a new unique token, valid for the requested mechanism, and includes it in the SASL2 <success/> response in a <token/> element qualified by the 'urn:xmpp:fast:0' namespace.

    @@ -136,23 +148,23 @@ + expiry='2020-03-12T14:36:15Z' + token='WXZzciBwYmFmdmZnZiBqdmd1IGp2eXFhcmZm' /> - ]]> +]]>

    The client authenticates normally using SASL2, using the FAST SASL mechanism it previously selected, and the token provided by the server. To indicate that it is providing a token, the client MUST include a <fast/> element qualified by the 'urn:xmpp:fast:0' namespace, within its SASL2 authentication request.

    If the server indicated support for TLS 0-RTT data, the client MAY send its authentication request within the TLS 0-RTT payload of its handshake. If it does this, it MUST also include a 'count' attribute on the <fast/> element. The value of this attribute MUST be a positive integer, which is incremented by the client on every authentication attempt with this token (it SHOULD be reset to zero when the token changes).

    -

    Servers MUST reject any authentication requests received via TLS 0-RTT payloads that do not include a <count/> element, or where the count is less than or equal to a count that has already been processed for this token. This protects against replay attacks that 0-RTT is susceptible to.

    +

    Servers MUST reject any authentication requests received via TLS 0-RTT payloads that do not include a 'count' attribute, or where the count is less than or equal to a count that has already been processed for this token. This protects against replay attacks that 0-RTT is susceptible to.

    Servers MUST bind tokens to the mechanism selected by the client in its original request, and reject attempts to use them with other mechanisms. For example, if the client selected a mechanism capable of channel binding, an attempt to use a mechanism without channel binding MUST fail even if the token would otherwise be accepted by that mechanism.

    - [base64 encoded SASL data] - - AwesomeXMPP - - + [base64 encoded SASL data] + + AwesomeXMPP + + @@ -164,7 +176,7 @@ - ]]> +]]>

    If the authentication succeeded, but the token is due for rotation (e.g. it is close to expiry), the server will generate a new token and provide it to the client in the <success/> response (even if the client did not explicitly request a token):

    @@ -181,7 +193,7 @@ expiry='2020-03-31T14:36:15Z' token='R3VyIHpiZmcgbnl2aXIgdmYgZ3VyIGp2eXFyZmcu' /> - ]]> +]]>

    When the server provides a new token to the client in this way, it MUST NOT invalidate the existing token until the new token is actually used by the client. This ensures that if the client gets disconnected before receiving the newer token from the server, it can still successfully authenticate on its next connection attempt.

    Upon successful use of any token, the server MUST invalidate all tokens issued to the same client with an earlier expiry than the current token (even if those tokens have not yet reached their expiry time).

    Additionally, upon providing a new token to the client, the server SHOULD invalidate any tokens previously generated that have not been used.

    @@ -197,7 +209,7 @@ [base64 encoded SASL data] - ]]> +]]>     @@ -244,10 +256,53 @@ -

    Many thanks to Daniel Gultsch and Thilo Molitor for their input, support, and implementations. Thanks also to Florian Schmaus for prior work on Instant Stream Resumption and the HT family of SASL mechanisms, which inspired and influenced this specification.

    +

    Many thanks to Daniel Gultsch and Thilo Molitor for their input, support, and implementations. Thanks also to Florian Schmaus for prior work on Instant Stream Resumption and the HT family of SASL mechanisms, which inspired and influenced this specification.

     -

    TODO before reaching Stable.

    + + + + + + + The protocol documented by this schema is defined in + XEP-0484: https://xmpp.org/extensions/xep-0484.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]>     From dc3275dd360a4efa257f0ceaa728646e28d10bf3 Mon Sep 17 00:00:00 2001 From: Stephen Paul Weber Date: Tue, 2 Jul 2024 09:21:13 -0500 Subject: [PATCH 105/145] Resolve entities when resolving xep number Since it is often encoded as an entity. --- 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 c89e14418..1cdf52e77 100755 --- a/tools/validate-xep0001-conformance.sh +++ b/tools/validate-xep0001-conformance.sh @@ -39,7 +39,7 @@ file_name=$(basename -- "$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_number=$(xmllint --xpath '/xep/header/number/text()' --nowarning --noent --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 From cac09c78e1a2e46c81dbc2b1d77260356f69ace0 Mon Sep 17 00:00:00 2001 From: Stephen Paul Weber Date: Tue, 2 Jul 2024 09:06:32 -0500 Subject: [PATCH 106/145] XEP-0491: Add acknowledgement for nlnet --- xep-0491.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xep-0491.xml b/xep-0491.xml index 1be14e48a..f5f9a9f99 100644 --- a/xep-0491.xml +++ b/xep-0491.xml @@ -171,4 +171,7 @@ ]]>     + +

    Thanks to NLNet foundation for funding the work on this specification.

    +     From 4d9a294f921173e0db98c71f8c3a1d1e36d89cf3 Mon Sep 17 00:00:00 2001 From: Stephen Paul Weber Date: Tue, 2 Jul 2024 09:11:57 -0500 Subject: [PATCH 107/145] XEP-0491: Mention selfAddr, as discussed --- xep-0491.xml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xep-0491.xml b/xep-0491.xml index f5f9a9f99..59d1c05f3 100644 --- a/xep-0491.xml +++ b/xep-0491.xml @@ -119,6 +119,9 @@ ]]> + +

    WebXDC widgets get various data injected into them by the host application. One of these worth mentioning is the selfAddr property. When the chat is a 1:1 chat this property SHOULD be set to the XMPP URI for the local party's bare Jabber ID. When the chat supports &xep0421; this property SHOULD be set to the local party's occupant id.

    +

    None

     From d4526f85fdd058678ddf34579d4828929620c922 Mon Sep 17 00:00:00 2001 From: Stephen Paul Weber Date: Tue, 2 Jul 2024 09:13:51 -0500 Subject: [PATCH 108/145] Add version block --- xep-0491.xml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/xep-0491.xml b/xep-0491.xml index 59d1c05f3..5d7db08c2 100644 --- a/xep-0491.xml +++ b/xep-0491.xml @@ -24,6 +24,17 @@ webxdc &singpolyma; + + 0.1.2 + 2024-07-03 + spw + +
      +
    • Suggest what to use for selfAddr
      • +
    • Add acknowledgements
      • +
    +     +     0.1.0 2024-06-20 From 6b13541b670cb7077f8c6ec0c376cfc192ef45fe Mon Sep 17 00:00:00 2001 From: linkmauve Date: Wed, 3 Jul 2024 17:01:13 +0200 Subject: [PATCH 109/145] XEP-0440: Add the XML Schema, registrar considerations, and fix some typos --- xep-0440.xml | 82 ++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 66 insertions(+), 16 deletions(-) diff --git a/xep-0440.xml b/xep-0440.xml index 994475b72..6ea1e2204 100644 --- a/xep-0440.xml +++ b/xep-0440.xml @@ -24,6 +24,18 @@ sasl-cb-types &flow; + + 0.4.2 + 2024-07-02 + egp + +
      +
    • Add an XML schema.
      • +
    • Mention that this specification does add a new namespace that should go to the registrar.
      • +
    • Fix indentation, typos, misuse of '' vs. </> for elements, etc.
      • +
    +     +     0.4.1 2024-01-30 @@ -53,9 +65,9 @@ 2020-08-04 fs - Discuss interaction with SASL mechanism and add security considerations. - Recommend implementation of tls-server-end-point. - + Discuss interaction with SASL mechanism and add security considerations. + Recommend implementation of tls-server-end-point. + 0.1.0 @@ -88,22 +100,22 @@ -

    This protocol consists of a stream feature named 'sasl-channel-binding' +

    This protocol consists of a stream feature named <sasl-channel-binding/> qualified by the 'urn:xmpp:sasl-cb:0' namespace. - The 'sasl-channel-binding' element MUST contain one or - more 'channel-binding' elements, of which each MUST have an + The <sasl-channel-binding/> element MUST contain one or + more <channel-binding/> elements, of which each MUST have an attribute with the name 'type'. The value of the 'type' attribute SHOULD be the "Channel-binding unique prefix" of a channel-binding type which was registered with the &iana-cb-types;.

    A server declares that it supports particular channel-binding - types by listing the supported types via the 'sasl-channel-binding' - stream feature defined herein. The 'sasl-channel-binding' element could + types by listing the supported types via the <sasl-channel-binding/> + stream feature defined herein. The <sasl-channel-binding/> element could appear next to the SASL <mechanisms/> stream-feature element, qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, as specified in &rfc6120;. Another potential appearance of - <sasl-channel-binding> is next to the + <sasl-channel-binding/> is next to the <authentication/> stream-feature element as specified in the &xep0388;.

    @@ -126,7 +138,7 @@

    Some channel-binding enabled SASL mechanisms reflect the server's presumed channel-binding abilities back to the server. This prevents - SASL-mechanism stripping attacks, where a Man in the Middle (MITM) + SASL mechanism stripping attacks, where a Man in the Middle (MITM) removes certain SASL mechanisms in an attempt to downgrade the mechanism choosen for authentication to a non-channel-binding enabled one. An example of a SASL mechanism family with this feature is @@ -139,16 +151,16 @@ via <sasl-channel-binding/> MAY want to indicate to the server that they do not support channel-binding (even if they do) if no mutual supported channel-binding type was found. The only alternative - is, that the client signals the server that he believes that the server + is, that the client signals the server that it believes that the server does not support channel binding. But this may cause the server to terminate the connection, because it indicates a potential ongoing - SASL-mechanism stripping attack.

    + SASL mechanism stripping attack.

     -

    If a client signals to the server that he does not support +

    If a client signals to the server that it does not support channel binding, because it found no mutual supported channel-binding types, another MITM attack vector is introduced. An active attacker could replace the @@ -156,7 +168,7 @@ (or impossible) to be supported by the client. If the client is configured to use non-channel-binding SASL mechanisms as a fallback, this could be used to downgrade the connection security. Note that - this attack is a different one than the SASL-mechanism stripping one: + this attack is a different one than the SASL mechanism stripping one: Here the attacker tempers with the announced channel-binding types, i.e., the values within <sasl-channel-binding;>

    @@ -185,13 +197,51 @@ -

    This document requires no interaction with the XMPP registrar.

    +

    Add the 'urn:xmpp:sasl-cb:0' namespace to the registry:

    + + urn:xmpp:sasl-cb:0 + Expose supported channel-binding types to clients + XEP-0440 + +]]>     -

    TODO: Add if the XEP is scheduled for the state after 'experimental'.

    + + + + + + + The protocol documented by this schema is defined in + XEP-0440: https://xmpp.org/extensions/xep-0440.html + + + + + + + + + + + + + + + + + + +]]>     From 283598c108b8f186001a59b3e87a7a2c7f285b5b Mon Sep 17 00:00:00 2001 From: JC Brand Date: Wed, 3 Jul 2024 17:02:13 +0200 Subject: [PATCH 110/145] XEP-0425: Set proper XMLNS in example --- xep-0425.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0425.xml b/xep-0425.xml index 7a6b3877e..cc91147c0 100644 --- a/xep-0425.xml +++ b/xep-0425.xml @@ -157,7 +157,7 @@ - + From 6037ec4736c82c85c4cedba048669b6baf2adb0a Mon Sep 17 00:00:00 2001 From: Emmanuel Gil Peyrot Date: Fri, 2 Aug 2024 20:49:49 +0200 Subject: [PATCH 111/145] XEP-0478: Add the XML Schema, and make both children optional --- xep-0478.xml | 78 ++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 60 insertions(+), 18 deletions(-) diff --git a/xep-0478.xml b/xep-0478.xml index 8df0c5094..e72cbbbe2 100644 --- a/xep-0478.xml +++ b/xep-0478.xml @@ -27,6 +27,18 @@ zash@zash.se &mwild; + + 0.2.0 + 2024-08-02 + egp + +
      +
    • Add the XML Schema.
      • +
    • Clarify that both children can be optional.
      • +
    • Fix indentation and one typo.
      • +
    +     +     0.1.0 2023-05-04 @@ -46,7 +58,7 @@

    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.

    +

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

         @@ -58,19 +70,19 @@ -

    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 the announcing entity is willing to accept. 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.
    -     -
    - 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 MAY contain the following child elements:

    +
    + +
    <max-bytes/>
    +
    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. If the responding entity is unable to determine its limits, this child can be absent.
    +     + +
    <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. If the responding entity is unable to determine its limits, this child can be absent.
    +     +
    + SCRAM-SHA-1 @@ -81,18 +93,18 @@ 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 - ]]> +]]>     @@ -129,6 +141,36 @@

    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.

    + + + + + + + The protocol documented by this schema is defined in + XEP-0478: https://xmpp.org/extensions/xep-0478.html + + + + + + + + + + + + + + + + + +]]>     From 3e4f17aa5f951129997b18c009d9bba764405a7f Mon Sep 17 00:00:00 2001 From: "tmp_github@goffi.org" Date: Mon, 29 Jul 2024 02:52:36 +0200 Subject: [PATCH 112/145] Add ProtoXEP: Jingle Audio/Video Conferences This specification defines a way to hold multiparty conferences with an SFU via Jingle. --- inbox/av_conferences.xml | 284 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 284 insertions(+) create mode 100644 inbox/av_conferences.xml diff --git a/inbox/av_conferences.xml b/inbox/av_conferences.xml new file mode 100644 index 000000000..198ee1863 --- /dev/null +++ b/inbox/av_conferences.xml @@ -0,0 +1,284 @@ + + +%ents; +]> + + +
    + Jingle Audio/Video Conferences + This specification defines a way to hold multiparty conferences with an SFU via Jingle. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0166 + XEP-0167 + XEP-0298 + + + + av-conferences + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.0.1 + 2024-07-29 + jp +

    First draft.

     +     +
    + + +

    Audio/Video calls are possible with a single destination via &xep0166; and &xep0167;, and associated XEPs. It may be desirable to have calls with multiple people at the same time. Three main strategies exist to achieve that:

    +
      +

    • A mesh network where each peer contacts each other peer: this is straightforward to implement and doesn't require any extra service, but it is heavy on network bandwidth and doesn't scale.

      • +

    • An MCU (Multipoint Conferencing Unit) which uses a central service that generally mixes the contents of participants: this is lighter on network bandwidth but heavy on computing resources and hard to scale.

      • +

    • A SFU (Selective Forwarding Unit) which uses a service that redistributes streams of participants as efficiently as possible: this is lighter on computing resources, acceptable in terms of network bandwidth, and can scale.

      • +
    +

    The mesh strategy is covered by &xep0272;. There have been attempts to specify MCU and SFU strategies, notably with &xep0340;, but it is unmaintained and unused.

    +

    This specification proposes a simple way to implement a SFU strategy with a service called in a similar way to one-to-one calls.

    +     + +

    The design goals of this XEP are:

    +
      +
    • Be as simple as possible to implement for clients that already implement one-to-one A/V calls.
      • +
    • Be compatible with simulcast.
      • +
    • Use a simple way to identify the originating XMPP entity of a stream.
      • +
    • Use a simple way to configure the A/V conference room.
      • +
    +     + + +
      +
    • A/V: Audio/visual.
      • +
    • SFU: Selective Forwarding Unit, a service that redistributes streams of participants as efficiently as possible.
      • +
    • SFU service: An XMPP entity that services A/V conferences with a SFU.
      • +
    • Room: A JID of an SFU service associated with a specific multiparty call.
      • +
    • Joining entity: An XMPP entity that participates in an A/V conference room.
      • +
    • Simulcast: Serving multiple versions of the same media content at different quality levels simultaneously, allowing the receiving end to select the most suitable version.
      • +
    +     + + +

    A/V conferences works using a Jingle session per stream: all sessions use unidirectional streams. An A/V conference is joined by calling the JID of an conference entity, and by sending our own stream. The conference service then call us for each stream it wants to send us.

    +

    &xep0298; is used to associate stream with the originating entity.

    +

    &xep0050; is used with a well-known node to configure the room.

    +     + +

    A/V conferences work by using a Jingle session per stream: all sessions use unidirectional streams. To join an A/V conference, a client calls the JID of a conference entity and sends its own stream. The conference service then contacts the client for each stream it wants to send.

    +

    &xep0298; is used to associate a stream with the originating entity.

    +

    &xep0050; is used with a well-known node to configure the room.

    +     + + + +

    To join a conference, a user calls the conference room JID using &xep0167; as for a one-to-one call. The calling entity sends its audio/video streams (typically webcam and microphone) in an unidirectional way. It MUST have its content 'senders' attribute set to "initiator" as explained in &xep0166; § 7.3.

    +

    A joining entity MAY send the same audio or video stream with different quality for simulcast purposes. It is up to the SFU service to then select which one to forward.

    +

    A SFU service MUST use &xep0298; and notably it MUST set the 'isfocus' attribute of the <conference-info> element to "true".

    +     + + +

    The SFU service MAY call the joining entity as many times as necessary using &xep0167; Jingle sessions from the joined room. The joining entity SHOULD accept each session coming from a joined room. Each session MUST be unidirectional (stream sent from SFU service to joining entity) and MUST have its content 'senders' attribute set to "initiator" as explained in &xep0166; § 7.3. Those streams are the streams of other participants as selected by the SFU.

    +

    To identify the streams' origin, the SFU service must specify it using &xep0298;, in particular by specifying the <user> element and its 'entity' attribute.

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

    It may be desirable to have configuration options on the SFU service or on one of its rooms. For instance, a conference room may offer the option to record the session. While the definition of those options is beyond the scope of this specification, the configuration MUST be done via &xep0050; on the well-known node "urn:xmpp:av-conferences:config".

    +     + + +

    Only other peers' streams are sent to a joining entity. A SFU service MUST NOT send back a stream to the entity that initially sent it.

    +

    A stream MAY originate from a non-XMPP entity (e.g., using SFU's own user interface or with a gateway to another protocol). That means that the <user> 'entity' attribute may be something else than an "xmpp:" URL.

    +     + + +

    If a client or a service supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:jingle:av-conferences:0" discovery feature in response to a &xep0030; information request.

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

    If an entity is a A/V conferences service as specified by this XEP, it MUST have an identity with a category of "conference" and a value of "audio-video" in a response to a &xep0030; information request.

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

    Streams are sent to the SFU service for redistribution. Although it is technically possible to have the stream encrypted end-to-end, this specification assumes that streams are decoded at the SFU level and are therefore not end-to-end encrypted, unlike one-to-one calls. Future specifications may outline a method for maintaining end-to-end encryption, but this is beyond the scope of this XEP; developers and end-users MUST assume that streams are decrypted at the SFU service level.

    +

    The general security considerations for one-to-one calls apply, with the added risk that more parties are participating in the call. However, the IP address of a device sending a stream is only known by the SFU service, not by other peers, unlike in one-to-one or &xep0272; calls.

    +     + + +

    TODO

    +     + +

    TODO

    +     + +

    TODO

    +     + + +

    Thanks to NLNet foundation/NGI Assure for funding the work on this specification.

    +     +     From ff460a597442dd4fa303d252b60892ecb77ae744 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Thu, 27 Jun 2024 15:08:17 +0200 Subject: [PATCH 113/145] XEP-0054: Updated error cases to be compatible with RFC 6121 In section 3.3 of XEP-0054 it is defined that the same error condition MUST be used in both a case: - where a VCard request is addressed to an entity that does not exist, and; - where a VCard request is addressed at an entity for which no VCard is available. RFC 6121 section 8.5.1 defines: > If the user account identified by the 'to' attribute does not exist, how the stanza is processed depends on the stanza type. For an IQ stanza, the server MUST return a `` stanza error to the sender. Prior to this change, both `` and `` were offered as suitable conditions to be used in the error scenario defined in section 3.3. For this XEP to be more compatible with RFC 6121, only can be used. This commit drops the `` condition from the scenario, and elevates usage of `` to a MUST. It adds a note on backwards compatibility. --- xep-0054.xml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/xep-0054.xml b/xep-0054.xml index b8e79add3..350e81aea 100644 --- a/xep-0054.xml +++ b/xep-0054.xml @@ -13,6 +13,7 @@ Active Historical Standards + Council XMPP Core @@ -20,6 +21,12 @@ vcard-temp &stpeter; + + 1.3.0 + 2024-06-27 + gk +

    Updated error cases to be compatible with &xmppim;.

     +     1.2 2008-07-16 @@ -242,7 +249,8 @@ ]]> -

    If no vCard exists or the user does not exist, the server MUST return a stanza error, which SHOULD be either &unavailable; or ¬found; (but the server MUST return the same error condition in both cases to help prevent directory harvesting attacks).

    +

    If no vCard exists or the user does not exist, the server MUST return a stanza error. The server MUST return the same error condition in both cases to help prevent directory harvesting attacks. &xmppim; dictates that &unavailable; MUST be used when the user account identified by the 'to' attribute of an IQ stanza does not exist. Hence, &unavailable; MUST be used in both cases.

    +

    Note: versions prior to 1.3 of this specification defined that either &unavailable; or ¬found; SHOULD be was used in these cases. For backwards-compatibility, applications SHOULD appropriately handle both errors.

    Date: Tue, 2 Jul 2024 21:59:05 +0200 Subject: [PATCH 114/145] XEP-0386: Add an XML Schema MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This has been tested against a mock XEP-0313 schema, because I couldn’t find it listed at its URL[1]. [1] http://www.xmpp.org/schemas/archive-management.xsd --- xep-0386.xml | 69 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 66 insertions(+), 3 deletions(-) diff --git a/xep-0386.xml b/xep-0386.xml index 916a29a5e..5c3a016ce 100644 --- a/xep-0386.xml +++ b/xep-0386.xml @@ -26,6 +26,12 @@ bind2 &ksmithisode; &mwild; + + 1.0.1 + 2024-07-02 + egp +

    Add an XML Schema.

     +     1.0.0 2024-04-04 @@ -195,9 +201,66 @@

    The urn:xmpp:bind:0 namespace must be registered..

     - + + + + + + + + The protocol documented by this schema is defined in + XEP-0386: https://xmpp.org/extensions/xep-0386.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> +

    Thanks to Daniel Gultsch, Philipp Hörist, Thilo Molitor and Andrzej Wójcik for their valuable support with feedback, suggestions and implementations.

     From 49c4a156e97635efd9d1b2c2e801f843798d3805 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 23 Aug 2024 09:37:40 +0200 Subject: [PATCH 115/145] XEP-0045: Additional Ban List specifications Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions. --- xep-0045.xml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/xep-0045.xml b/xep-0045.xml index 07f91955e..697f81b3b 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -46,6 +46,12 @@ &stpeter; + + 1.34.7 + 2024-07-09 + gk +

    Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.

     +     1.34.6 2024-05-01 @@ -3334,6 +3340,7 @@
  • <domain> (the domain itself matches, as does any user@domain or domain/resource)

    • Some administrators might wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document; see XEP-0133.

    +

    As specified in Banning a User, users cannot be banned under certain conditions. For example: admins and owners cannot ban themselves, and a user cannot be banned by an admin with a lower affiliation. When a request to modify the ban list includes one or more modifications that is prohibited by the definitions in Banning a User, then the service SHOULD NOT apply any of the requested changes and MUST deny the request using an error which SHOULD be either &conflict; or ¬allowed;.

    From 4677fc1b8199a9d4d8ec5c12a6556ad30727ca0e Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 23 Aug 2024 09:39:23 +0200 Subject: [PATCH 116/145] XEP-0045 Remove references to using resourceparts when banning users. Elsewhere, the specifications dictate that the banlist is based on bare JIDs. Matching resourceparts contradicts this (and is removed by this commit). Co-authored-by: Daniel Gultsch --- xep-0045.xml | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 697f81b3b..d289f40ae 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -50,7 +50,12 @@ 1.34.7 2024-07-09 gk -

    Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.

     + +
      +
    • Remove references to using resourceparts when banning users.
      • +
    • Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.
      • +
    +     1.34.6 @@ -3332,12 +3337,10 @@ type='result'/> ]]>

    The service MUST then remove the affected occupants (if they are in the room) and send updated presence (including the appropriate status code) from them to all the remaining occupants as described in the "Banning a User" use case. (The service MUST also remove each banned user's reserved nickname from the list of reserved roomnicks, if appropriate.)

    -

    When an entity is banned from a room, an implementation SHOULD match JIDs in the following order (these matching rules are the same as those defined for privacy lists in &xep0016;):

    +

    When an entity is banned from a room, an implementation SHOULD match JIDs in the following order:

      -
    1. <user@domain/resource> (only that resource matches)
      2. -
    2. <user@domain> (any resource matches)
      3. -
    3. <domain/resource> (only that resource matches)
      4. -
    4. <domain> (the domain itself matches, as does any user@domain or domain/resource)
      5. +
    5. <user@domain>
      6. +
    6. <domain> (the domain itself matches, as does any user@domain)

    Some administrators might wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document; see XEP-0133.

    As specified in Banning a User, users cannot be banned under certain conditions. For example: admins and owners cannot ban themselves, and a user cannot be banned by an admin with a lower affiliation. When a request to modify the ban list includes one or more modifications that is prohibited by the definitions in Banning a User, then the service SHOULD NOT apply any of the requested changes and MUST deny the request using an error which SHOULD be either &conflict; or ¬allowed;.

    From 88f616ea1bef4aa42de45e8f4fd8e069c0e85e17 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 23 Aug 2024 09:41:01 +0200 Subject: [PATCH 117/145] XEP-0045: Improved wording of status code purpose Previously, the wording of the status code purpose incorrectly hinted that the user receiving the presence stanza with the status code is the user that is affected by the corresponding change. This is incorrect, as these status code are not only used in stanzas sent to the affected user. They are also used to inform remaining occupants of the room of the status change. --- xep-0045.xml | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index d289f40ae..59e1de43d 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -54,6 +54,7 @@
    • Remove references to using resourceparts when banning users.
    • Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.
      • +
    • Status code purpose no longer hints that recipient is the affected user
     @@ -5559,7 +5560,7 @@ presence Removal from room - Inform user that he or she has been banned from the room + A user has been banned from the room @@ -5575,7 +5576,7 @@ presence Removal from room - Inform user that he or she has been kicked from the room + A user has been kicked from the room @@ -5583,7 +5584,7 @@ presence Removal from room - Inform user that he or she is being removed from the room + A user is being removed from the room because of an affiliation change @@ -5592,7 +5593,7 @@ presence Removal from room - Inform user that he or she is being removed from the room + A user is being removed from the room because the room has been changed to members-only and the user is not a member @@ -5602,7 +5603,7 @@ presence Removal from room - Inform user that he or she is being removed from the room + A user is being removed from the room because the MUC service is being shut down @@ -5611,7 +5612,7 @@ presence Removal from room - Inform users that a user was removed because of an error reply (for example + A user was removed because of an error reply (for example when an s2s link fails between the MUC and the removed users server). From a5668771f95e559845bebd408f489f8f020cb52b Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 23 Aug 2024 09:43:21 +0200 Subject: [PATCH 118/145] XEP-0045: Improve 'Service Removes Non-Member' example The pre-existing example appears to show two mutually exclusive acceptable stanzas. This can be confused for a requirement to send two stanzas. In this commit, the example is improved by removing one of the variants. A small textual change has been applied to define the optionality of the 'actor' element. --- xep-0045.xml | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 59e1de43d..c2d390bf5 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -48,13 +48,14 @@ &stpeter; 1.34.7 - 2024-07-09 + 2024-07-11 gk
    • Remove references to using resourceparts when banning users.
    • Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.
    • Status code purpose no longer hints that recipient is the affected user
      • +
    • Improved 'Service Removes Non-Member' example.
         @@ -3448,7 +3449,7 @@ [ ... ] ]]> -

    If the room is members-only, the service MUST remove the user from the room, including a status code of 321 to indicate that the user was removed because of an affiliation change, and inform all remaining occupants:

    +

    If the room is members-only, the service MUST remove the user from the room, including a status code of 321 to indicate that the user was removed because of an affiliation change, and inform all remaining occupants. The stanza MAY include an <actor/> element.

    - - type='unavailable'> - - - - - - [ ... ] ]]> From 3d418263d8ea1585199a95296b4b277747904c82 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 23 Aug 2024 09:44:28 +0200 Subject: [PATCH 119/145] XEP-0045 Clarify usage of presence stanzas when removing a non-member from a members-only room --- xep-0045.xml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xep-0045.xml b/xep-0045.xml index c2d390bf5..bf7448a80 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -56,6 +56,7 @@
  • Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.
  • Status code purpose no longer hints that recipient is the affected user
  • Improved 'Service Removes Non-Member' example.
    • +
  • Clarify usage of presence stanzas when removing a non-member from a members-only room.
    •  @@ -3465,6 +3466,7 @@ [ ... ] ]]> +

    As there is no point in time where a non-member user must be in a members-only room, the service SHOULD NOT send both a de-affiliation presence (without a 'type' attribute) followed by room-removal presence (of type 'unavailable'). Instead, it SHOULD only send the latter of the two.

    From 9298c06ae0fb7c465b455ae49963f08e7270fb3e Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 23 Aug 2024 09:46:20 +0200 Subject: [PATCH 120/145] =?UTF-8?q?XEP-0045:=20Replace=20inappropriate=20R?= =?UTF-8?q?FC=202119=20key=20word=20usage=20in=20=C2=A79.7?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The 'MAY' key word, per RFC 2119, is to be used to flag a 'truly optional' item. In this text, it seems to be used to restrict the item to certain characteristics intead. This is an improper use of the key word. Further down the section, the scenario is further specified, using more appropriate key word usage. --- xep-0045.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index bf7448a80..e92b824c6 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -48,7 +48,7 @@ &stpeter; 1.34.7 - 2024-07-11 + 2024-07-12 gk
      @@ -57,6 +57,7 @@
    • Status code purpose no longer hints that recipient is the affected user
    • Improved 'Service Removes Non-Member' example.
    • Clarify usage of presence stanzas when removing a non-member from a members-only room.
      • +
    • Replace inappropriate RFC 2119 key word usage in §9.7.
         @@ -3634,7 +3635,7 @@     -

    An admin might want to revoke a user's moderator status. An admin MAY revoke moderator status only from a user whose affiliation is "member" or "none" (i.e., not from an owner or admin). The status is revoked by changing the user's role to "participant":

    +

    An admin might want to revoke a user's moderator status. An admin is allowed to revoke moderator status only from a user whose affiliation is "member" or "none" (i.e., not from an owner or admin). The status is revoked by changing the user's role to "participant":

    Date: Fri, 23 Aug 2024 09:49:51 +0200 Subject: [PATCH 121/145] XEP-0045: Presence sent to occupants of a destroyed room includes a `` element Even if no reason or alternate venue is provided, a `` element is needed to distinguish between other presence unavailable. --- xep-0045.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index e92b824c6..705aa928d 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -48,7 +48,7 @@ &stpeter; 1.34.7 - 2024-07-12 + 2024-07-13 gk
      @@ -58,6 +58,7 @@
    • Improved 'Service Removes Non-Member' example.
    • Clarify usage of presence stanzas when removing a non-member from a members-only room.
    • Replace inappropriate RFC 2119 key word usage in §9.7.
      • +
    • Presence sent to occupants of a destroyed room includes a <destroy/> element.
         @@ -4902,7 +4903,8 @@ ]]>     -

    The service is responsible for removing all the occupants. It SHOULD NOT broadcast presence stanzas of type "unavailable" from all occupants, instead sending only one presence stanza of type "unavailable" to each occupant so that the user knows he or she has been removed from the room. If extended presence information specifying the JID of an alternate location and the reason for the room destruction was provided by the room owner, the presence stanza MUST include that information.

    +

    The service is responsible for removing all the occupants. It SHOULD NOT broadcast presence stanzas of type "unavailable" from all occupants, instead sending only one presence stanza of type "unavailable" to each occupant so that the user knows he or she has been removed from the room. The extended presence information of the stanza MUST include <destroy/> element. If extended information specifying the JID of an alternate location and/or the reason for the room destruction was provided by the room owner, the presence stanza MUST include that information.

    +

    Note: in older versions of this standard, the inclusion of a <destroy/> element was not explicitly defined to be mandatory (when no alternate location or reason are provided by the room owner). Implementations therefore cannot reliably depend on the existence of this element to identify a room destruction event.

    Date: Fri, 23 Aug 2024 09:51:05 +0200 Subject: [PATCH 122/145] XEP-0045: Explicitly use bare JIDs when operating on affiliations. Section 5.2 defines that affiliations are granted, revoked, and maintained based on the user's bare JID. This commit adds a reference to this definition where affiliations are used (in section 10), and adds a SHOULD to downcast to a bare JID when a request provides a full JID. --- xep-0045.xml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 705aa928d..20a925633 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -48,7 +48,7 @@ &stpeter; 1.34.7 - 2024-07-13 + 2024-08-14 gk
      @@ -59,6 +59,7 @@
    • Clarify usage of presence stanzas when removing a non-member from a members-only room.
    • Replace inappropriate RFC 2119 key word usage in §9.7.
    • Presence sent to occupants of a destroyed room includes a <destroy/> element.
      • +
    • Explicitly use bare JIDs when operating on affiliations.
         @@ -4537,6 +4538,7 @@ ]]>     +

    As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

    The service MUST add the user to the owner list and then inform the owner of success:

    ]]> +

    As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

    A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.

    If an implementation does not allow one owner to revoke another user's owner status, the implementation MUST return a ¬authorized; error to the owner who made the request.

    Note: Allowing an owner to remove another user's owner status can compromise the control model for room management; therefore this feature is OPTIONAL, and implementations are encouraged to support owner removal through an interface that is open only to individuals with service-wide admin status.

    @@ -4653,7 +4656,7 @@ ]]> -

    The owner can then modify the owner list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomowners" field specifies the full list of room owners, not the delta. each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner):

    +

    The owner can then modify the owner list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomowners" field specifies the full list of room owners, not the delta. each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner). As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of users in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

    ]]> +

    As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

    The service MUST add the user to the admin list and then inform the owner of success:

    ]]> +

    As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

    The service MUST remove the user from the admin list and then inform the owner of success:

    ]]> -

    The owner can then modify the admin list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomadmins" field specifies the full list of room admins, not the delta. each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner).

    +

    The owner can then modify the admin list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomadmins" field specifies the full list of room admins, not the delta. each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner). As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of users in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

    Date: Fri, 23 Aug 2024 09:54:13 +0200 Subject: [PATCH 123/145] XEP-0045: Allow non-owners to retrieve owner and admin lists in non-anonymous rooms --- xep-0045.xml | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 20a925633..bb1cbd7cd 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -47,7 +47,7 @@ &stpeter; - 1.34.7 + 1.35.0 2024-08-14 gk @@ -60,6 +60,8 @@
  • Replace inappropriate RFC 2119 key word usage in §9.7.
  • Presence sent to occupants of a destroyed room includes a <destroy/> element.
  • Explicitly use bare JIDs when operating on affiliations.
    • +
  • Allow non-owners to retrieve owner and admin lists in non-anonymous rooms.
    • +
  • Members should be allowed to retrieve the member list only in non-anonymous rooms.
    •      @@ -1003,7 +1005,7 @@ N/A - Retrieve Member List + Retrieve Member List*** No No Yes @@ -1077,6 +1079,7 @@

    * As a default, an unaffiliated user enters a moderated room as a visitor, and enters an open room as a participant. A member enters a room as a participant. An admin or owner enters a room as a moderator.

    ** As noted, a moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner).

    +

    *** When a room is configured to be semi-anonymous, there clearly is an intent to hide JIDs. In such rooms, members SHOULD NOT be allowed to retrieve the member list (as that list MUST contain the JID of each member).

    @@ -3486,7 +3489,7 @@ ]]>     -

    Note: A service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a &forbidden; error when a member in the room requests the member list. This functionality can assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited. A service SHOULD also allow any member to retrieve the member list even if not yet an occupant.

    +

    Note: If the room is non-anonymous, a service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a &forbidden; error when a member in such a room requests the member list. This functionality can assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited. If the room is non-anonymous, a service SHOULD also allow any member to retrieve the member list even if not yet an occupant.

    The service MUST then return the full member list to the admin qualified by the 'http://jabber.org/protocol/muc#admin' namespace; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for each member that is currently an occupant.

    ]]> -

    If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.

    +

    If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender in semi-anonymous rooms. In non-anonymous rooms, the service MAY process the request.

    Otherwise, the service MUST then return the owner list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any owner that is currently an occupant:

    ]]> -

    Only owners shall be allowed to modify the owner list. If a non-owner attempts to view or modify the owner list, the service MUST deny the request and return a &forbidden; error to the sender:

    +

    Only owners shall be allowed to modify the owner list. If a non-owner attempts to modify the owner list, the service MUST deny the request and return a &forbidden; error to the sender:

    ]]> -

    If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.

    +

    If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender in semi-anonymous rooms. In non-anonymous rooms, the service MAY process the request.

    Otherwise, the service MUST then return the admin list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any admin that is currently an occupant:

    ]]> -

    Only owners shall be allowed to modify the admin list. If a non-owner attempts to view or modify the admin list, the service MUST deny the request and return a &forbidden; error to the sender.

    +

    Only owners shall be allowed to modify the admin list. If a non-owner attempts to modify the admin list, the service MUST deny the request and return a &forbidden; error to the sender.

    Date: Tue, 6 Aug 2024 17:29:04 +0200 Subject: [PATCH 124/145] XEP-0388: Fix the XML Schema and examples --- xep-0388.xml | 271 +++++++++++++++++++++++++++------------------------ 1 file changed, 145 insertions(+), 126 deletions(-) diff --git a/xep-0388.xml b/xep-0388.xml index d6297effc..4c854eaa6 100644 --- a/xep-0388.xml +++ b/xep-0388.xml @@ -26,6 +26,15 @@ &dcridland; &tmolitor; &mwild; + + 1.0.2 + 2024-08-06 + egp +
      +
    • Fix various invalid examples.
      • +
    • Fix the XML Schema to match examples.
      • +
    +     1.0.1 2024-04-04 @@ -91,12 +100,12 @@

    Updated according to implementation experience:

      -
    • Updated namespace
      • -
    • Continue "mechanisms" are not; changed these to "tasks".
      • -
    • Added stream features after Success.
      • -
    • Don't need complexity of "=" encoding; removed.
      • -
    • Fixed internal links.
      • -
    • Updated examples.
      • +
    • Updated namespace
      • +
    • Continue "mechanisms" are not; changed these to "tasks".
      • +
    • Added stream features after Success.
      • +
    • Don't need complexity of "=" encoding; removed.
      • +
    • Fixed internal links.
      • +
    • Updated examples.
         @@ -174,7 +183,7 @@ - + @@ -512,7 +521,7 @@ - dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw @@ -591,7 +600,7 @@ - dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw @@ -628,7 +637,7 @@ PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ - +