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.
+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.
+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.
+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:
+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.
+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:
+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.
+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 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/> 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.
+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.
+REQUIRED.
+REQUIRED.
+REQUIRED for protocol specifications.
+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.
-Note: If the entity is an end user, the JID SHOULD be of the form <user@host>, not <user@host/resource>.
-Naturally, the data form included in the IQ result will include the user's password.
-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 vulnerability
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".
diff --git a/xep-0458.xml b/xep-0458.xml index 7641b832..783513dc 100644 --- a/xep-0458.xml +++ b/xep-0458.xml @@ -12,7 +12,7 @@ &LEGALNOTICE;Changed status to Active per Board vote on 2024-01-05.
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:
++ 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. +
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.
-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.
-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. +
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.
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.
+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.
+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.
+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:
+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.
+Restore to the first revision, and republish to the Historical track.
Generalise to non-MUC resources.
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:
+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;.
+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.
+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.
+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.
+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.
+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:
+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.
+OPTIONAL.
OPTIONAL.
+REQUIRED.
OPTIONAL.
@@ -65,6 +65,9 @@REQUIRED.
REQUIRED.
+REQUIRED.