From 105dff773ab7bb894f6669dcf10c0d938228f70b Mon Sep 17 00:00:00 2001 From: Florian Schmaus Date: Mon, 11 Dec 2023 19:05:21 +0100 Subject: [PATCH 01/28] 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 02/28] 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 03/28] 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 04/28] 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 05/28] 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 06/28] 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 07/28] 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 08/28] 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 09/28] 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 10/28] 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 11/28] 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 12/28] 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 13/28] 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 14/28] 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 15/28] 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 16/28] 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 17/28] 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 18/28] 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 19/28] 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 20/28] 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 21/28] 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 22/28] 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 23/28] 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 24/28] 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 25/28] 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 26/28] 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 27/28] 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 28/28] 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.