First draft based on XEP-0459.
++ There is a growing number of XMPP Extension Protocols (XEPs) that provide + different building blocks for XMPP-based applications. XMPP software + developers are confronted with the challenge of finding the right + combination of XEPs for a given application profile. Users need a way to + compare applications without resorting to comparing for individual XEP + numbers. +
++ This document defines XMPP application Categories based on + typical use cases (Core, Web, IM, Mobile) and Levels + (Core, Advanced) based on functionality in the respective category. For + each combination of those, the required XEPs are referenced. As the + protocol landscape changes over time, this document is updated roughly + once a year. +
++ For developers, this document provides guidance on which specifications + they need to consider when implementing an application of a certain kind. + By completing a compliance test or performing a self-assessment, they can + advertise their implementation as compliant with a given Category and + Level. +
++ For users, this provides an easy way to compare implementations based on + their respective advertised compliance levels and year. +
++ Unless explicitly noted, support for the listed specifications is REQUIRED + for compliance purposes. + A feature is considered supported if all comma separated feature providers + listed in the "Providers" column are implemented (unless otherwise noted). +
+The following changes were made to the Compliance Suites since &xep0459;:
+None.
+The following changes were made to the Compliance Suites since &xep0443;:
+The following changes were made to the Compliance Suites since &xep0423;:
+The following changes were made to the Compliance Suites since &xep0412;:
+| Feature | +Server | +Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Core features | +&yes; | +&yes; | +&yes; | +&yes; | +&rfc6120; |
+
| TLS | +&yes; | +&yes; | +&yes; | +&yes; | +&rfc7590; | +
| Direct TLS | +&no; | +&no; | +&yes; |
+ &yes; | +&xep0368; | +
| Feature discovery | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0030; | +
| Feature broadcasts | +&no; | +&yes; | +&yes; | +&yes; | +&xep0115; | +
| Server Extensibility | +&yes; | +N/A | +&yes; | +N/A | +&xep0114; | +
| Event publishing | +&no; | +&no; | +&yes;&pubsubjid; | +&yes; | +&xep0163; | +
+ To be considered XMPP web compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Server | +Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Web Connection Mechanisms | +&yes;&component; | +&yes;&onlyone; | +&yes;&component; | +&yes;&onlyone; | +&rfc7395;, &xep0206; (See also: &xep0124;) | +
| Connection Mechanism Discovery | +&no; | +&yes; | +N/A | +&yes; | +&xep0156; | +
+ To be considered XMPP IM compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Server | +Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Core features | +&yes; | +&yes; | +&yes; | +&yes; | +&rfc6121; | +
| The /me Command | +N/A | +&yes; | +N/A | +&yes; | +&xep0245; | +
| User Avatars | +N/A | +&no; | +N/A | +&yes;&nocli; | +&xep0084; | +
| User Avatar Compatibility | +&no; | +&no; | +&yes; | +&yes;&nocli; | +&xep0398;, &xep0153; | +
| vcard-temp | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0054; | +
| Outbound Message Synchronization | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0280; | +
| User Blocking | +&no; | +&no; | +&yes; | +&yes; | +&xep0191; | +
| Group Chat | +&yes;&component; | +&yes;&usecases; | +&yes;&component; | +&yes;&usecases; | +&xep0045; |
+
| Advanced Group Chat | +&no; | +&no; | +&yes;&component; | +&yes; | +&xep0048;, &xep0313; |
+
| Persistent Storage of Private Data via PubSub | +&no; | +&no; | +&yes;&component; | +&yes; | +&xep0223; | +
| Private XML Storage | +&no; | +&no; | +&yes;&component; | +&yes; | +&xep0049; (only recommended for legacy bookmarks support) | +
| Stream Management | +&no; | +&no; | +&yes; | +&yes; | +&xep0198; | +
| Message Acknowledgements | +N/A | +&no; | +N/A | +&yes; | +&xep0184; | +
| History Storage / Retrieval | +&no; | +&no; | +&yes; | +&yes; | +&xep0313; | +
| Chat States | +N/A | +&no; | +N/A | +&yes; | +&xep0085; | +
| Message Correction | +N/A | +&no; | +N/A | +&yes; | +&xep0308; | +
| File Upload | +&yes;&component; | +&yes; | +&yes;&component; | +&yes; | +&xep0363; | +
| Direct File Transfer | +N/A | +&no; | +N/A | +&yes; | +&xep0234;, &xep0261; | +
+ Further specifications of note, which are not required for compliance: +
++ To be considered XMPP mobile compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Server | +Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Stream Management | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0198; | +
| Client State Indication | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0352; | +
| Third Party Push Notifications | +&no; | +&no; | +&yes;&component; | +&yes; |
+ &xep0357; | +
+ Further specifications of note, which are not required for compliance: +
++ To be considered XMPP A/V calling compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Server | +Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Call Setup | +N/A | +&yes; | +N/A | +&yes; | +&xep0167;, &xep0353; | +
| Transport | +N/A | +&yes; | +N/A | +&yes; | +&xep0176; | +
| Encryption | +N/A | +&yes; | +N/A | +&yes; | +&xep0320; | +
| STUN/TURN server discovery | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0215; | +
| Quality and Performance improvements | +N/A | +&no; | +N/A | +&yes; | +&xep0293;, &xep0294;, &xep0338;, &xep0339; | +
This section outlines the protocol specifications that are relevant for + developers, but are not ready yet to be required for Compliance. + Developers are encouraged to implement those and + to share their experience and feedback.
++ Some of the protocol specifications referenced herein have their own + dependencies; developers need to consult the relevant specifications for + further information. +
++ This document introduces no additional security considerations above and + beyond those defined in the documents on which it depends. +
+This document requires no interaction with &IANA;.
+This document requires no interaction with the ®ISTRAR;.
++ The author would like to thank Guus der Kinderen, Dele Olajide, Marc + Laporte, Dave Cridland, Daniel Gultsch, Florian Schmaus, Tobias Markmann, + and Jonas Schäfer for their suggestions. +
+First draft.
This documents describes a mechanism for communicating limits, such as stanza size limits that is in effect on a particular stream, in order to allow the sending party to avoid reaching those limits.
+Where stanza size limits have been deployed, very often this leads to problems with large stanzas causing connection outages, most often &xep0084; and &xep0053; result stanzas, which can be very large due to embedded images.
+If stanza size limit violations are met with stream errors then this may lead to temporary connection outage, which may a few seconds to recover from.
+These requirements will enable XMPP clients and servers to adapt data they generate, such that it will fit within the limits required by the recipient, or reject overly large stanzas early, rather than following a trial-and-error approach.
+For any XMPP stream, there is an "initiating entity" (a client or server) and a "responding entity" that they are connecting to. The responding entity advertises its limits in the <stream:features/> element that it sends at the start of the stream.
+The limits are enclosed in a <limits/> element qualified by the 'urn:xmpp:stream-limits:0' namespace. This element SHOULD contain the following child elements:
+Servers using &xep0288; to establish a bidirectional stream with another server do not get an opportunity to send <stream:features/> to the responding entity. For a server to advertise the limits about what it is willing to accept on such a stream, the <limits/> element can be included in the <bidi/> element.
+If, after serialization, a stanza exceeds the limits that have been advertised on a stream, it SHOULD NOT be sent on that stream. Instead, a server SHOULD return an error to the sender. Such an error SHOULD contain the <policy-violation/> error condition, and SHOULD NOT contain a 'by' attribute (as the policy being violated is not the current entity's). A <text/> may also be included, explaining the limit that would be exceeded.
+It is acceptable for the limits on a stream to change whenever new stream features are announced - such as before and after authentication of the connecting entity.
+OPTIONAL.
+OPTIONAL.
+OPTIONAL.
+REQUIRED.
+Very large stanzas may incur memory and processing costs on the receiving entity. Advertising the actual limits could inform an attacker of how large a stanza to construct in order to maximize e.g. DoS effectiveness. Best combined with network level rate limits on raw bytes.
+None.
+This specification defines the following namespace:
+Also, the following stream feature:
+<limits xmlns='urn:xmpp:stream-limits:0'/>The ability for a client to announce limits on what it will receive on a client-to-server stream is deliberately not provided by this specification. This vastly simplifies discovery of the maximum limits between any two JIDs, and it avoids situations where the server is unable to deliver incoming stanzas to some or all of an account's connected clients. Clients will already be protected from denial-of-service through excessive stanza sizes due to the server's own limits.
+TBD.
+Clarify elements allowed in multi-item data forms
The <reported/> element MUST appear before any <item/> element inside the <x/> element.
+The <reported/> element MUST appear before any <item/> element inside the <x/> element. Forms of this type MUST NOT contain any top-level fields other than <reported/> and <item/>.
Older revisions of this XEP (before 2.12.0) did not contain an explicit requirement for the ordering between <reported> and <item>. Implementations are therefore encouraged to be flexible when processing incoming data, as there might still be implementations which do not implement a strict ordering when generating reports. + Similarly, revisions of this XEP before 2.13.1 were ambiguous about whether <reported/> and <item/> elements could co-exist with other top level elements such as <field/> and <title/> and various implementations are known to have handled this in different ways.
The syntax is as follows:
N/A
&stpeter;
+
+ 1.1
+ 2022-11-03
+ pep
+ Replaced shtml link.
+
1.0
2002-03-20
@@ -72,6 +78,6 @@
Continue to use the Standards SIG as the preferred forum for discussion of experimental specifications before they are submitted to the XMPP Council.
If the Standards SIG cannot reach a working consensus on a given topic, let the document author(s) continue to rework their proposal informally outside the context of the Standards SIG. One option would be to send interested parties off to their own ad-hoc mailing list (e.g., on JabberStudio, http://www.jabberstudio.org/). Unlike the current SIGs, such a list would be established on the initiative of the document author(s) and would not require any formal approval by the XMPP Council.
- There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at http://www.jabber.org/bylaws.html.)
+ There may be value in bringing back specialized SIGs in the future when the Jabber/XMPP community becomes larger. However, at this time I urge that we face the facts and proactively implement the solution I have outlined in this document. Lest there be any concern that disbanding the SIGs is outside the power or purview of the XMPP Council, I note that Section 8.2 of the Bylaws of the XMPP Standards Foundation states in part that "The XMPP Council or the Members of the Corporation may, by resolution, ... terminate a Special Interest Group at any time for any reason." (An electronic copy of the Bylaws may be found at http://www.jabber.org/bylaws.html.)
diff --git a/xep-0045.xml b/xep-0045.xml
index 60171618..331fbc14 100644
--- a/xep-0045.xml
+++ b/xep-0045.xml
@@ -45,6 +45,18 @@
+ 1.34.5
+ 2022-12-01
+ NC
+ Add MUC service shut down example.
+
+ 1.34.4
+ 2022-10-05
+ pep
+ Remove more mentions of Group Chat 1.0.
1.34.3
2022-03-08
@@ -4980,6 +4992,31 @@
and they are not linked to any user (e.g. moderator) action that the 307 code usually indicates. It is therefore recommended for the
client to ignore the 307 code if a 333 status code is present.
+
+ When a MUC service shuts downs, it SHOULD inform its participant by sending presences containing the 332 status code
+
+
+
+
+
+
+
+
+]]>
+
@@ -5708,7 +5745,6 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
A MUC service SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information; see the Allowable Traffic section of this document.
In order to inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide role and affiliation data (and, if allowed by the room configuration, full JID) in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.
If a role or affiliation is revoked, the service MUST note that fact by sending an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant status. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.
A MUC service MUST include the MUC extensions even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with RFC 6120).
If the service includes an occupant's JabberID in the MUC presence extension, the value of the 'jid' attribute MUST be the full JID (not the bare JID).
A client MAY send a custom exit message if desired (as is often done in IRC channels) by including a <status/> element in the presence stanza of type "unavailable" sent when exiting a room.
iq-iq
&stpeter;
+
+ 1.1
+ 2022-11-03
+ pep
+ Replace shtml link
1.0
2005-04-01
@@ -191,7 +197,7 @@
Semantic Correlation and Observation of Truth in Conversation Handling (SCOTCH) A person may seem intelligent to the casual observer, but his or her messages may actually not provide deep insights or even track reality in a useful or consistent fashion; this technique builds on early semantic web insights to determine the truth value of a given message within the context of a realtime conversation. Webs of Intelligent Network Endpoints (WINE) Any given person can engage in conversations with a large number of interlocutors, yet that person's status as an intelligent network endpoint is influenced by reputational factors across the full web of linguistic interactions, not just with any one person; this technique accounts for such reputational effects to paint a complete picture of the person's perceived intelligence across the network. Naturally, because of the powerful and potentially unpredictable effects of these technologies, development of mod_iq was restricted to senior developers on the jabberd team, or at least (for developers in the U.S.) those over the age of 21. See Title 23, Chapter 1, Subchapter 1, Section 158 of the United States federal legal code as enacted by the National Minimum Drinking Age Act of 1984 <http://www.law.cornell.edu/uscode/23/158.shtml>.
+ Naturally, because of the powerful and potentially unpredictable effects of these technologies, development of mod_iq was restricted to senior developers on the jabberd team, or at least (for developers in the U.S.) those over the age of 21. See Title 23, Chapter 1, Subchapter 1, Section 158 of the United States federal legal code as enacted by the National Minimum Drinking Age Act of 1984 <https://www.law.cornell.edu/uscode/text/23/158>.
diff --git a/xep-0167.xml b/xep-0167.xml
index 5023e3c3..7466fb96 100644
--- a/xep-0167.xml
+++ b/xep-0167.xml
@@ -42,6 +42,12 @@
&seanegan;
&robmcqueen;
&diana;
+
+ 1.2.2
+ 2022-09-26
+ melvo
+ Specify attribute 'name' of 'mute' and 'unmute' elements as optional in schema
+
1.2.1
2020-09-29
@@ -1933,7 +1939,7 @@ Romeo Juliet
+ 0.6.0
+ 2022-01-29
+ tm
+
+ Port version 0.5 to :0 namespace and improve tie-breaking section
+
+
+
+ 0.5.0
+ 2022-01-05
+ tm
+
+ Recommend usage of UUID v4 for id attributes.
+
+
0.4.0
2021-11-27
@@ -98,12 +114,12 @@
All &MESSAGE; stanzas exchanged by this protocol MUST be of type="chat" and contain &xep0334; <store/> hints.
- In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:1' namespace. The <propose/> element MUST possess an 'id' attribute that will be used for the session invitation of &xep0166; and MUST contain one <description/> element for each media type associated with the intended session.
+ In order to prepare for sending a Jingle invitation, the initiator (e.g., Romeo) sends a &MESSAGE; stanza containing a <propose/> element qualified by the 'urn:xmpp:jingle-message:0' namespace. The <propose/> element MUST possess an 'id' attribute being a globally unique identifier. It therefore is RECOMMENDED to use UUIDv4. This id will also be used for the session invitation of &xep0166; later on. The <propose/> element MUST contain one <description/> element for each media type associated with the intended session.
-
+
+
+
+ Upon receiving the <propose/> message, the responder's various devices will start "ringing" and indicate so by sending a message to the bare JID of the initiator containing a <ringing/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.
+ This makes it possible to reflect the real state of the call in the UI and therefore comprises for better UX. It also somewhat compensates for the (intentionally) missing discovery of this protocol.
+
+
- It can happen that the initiator might want to disavow intent to send a session invitation (e.g., because the initiator has accepted another session). The initiator can do so by sending a message stanza containing a <retract/> element specifying the same session ID.
- The <retract/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <cancel/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).
- It can happen that the initiator might want to disavow intent to send a session invitation (e.g., because the initiator has accepted another session). The initiator can do so by sending a message stanza containing a <retract/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.
+ The <retract/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <cancel/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).
+ In conjunction with &xep0313; upon ending the catchup phase the responder SHOULD consider all sessions for which it received a <propose/> but no <retract/> or <finish/> message to be still active and allow the user to accept the intent to start a session.
+
-
+
Retracted
@@ -137,21 +166,20 @@
- In conjunction with &xep0313; upon ending the catchup phase the responder SHOULD consider all sessions for which it received a <propose/> but no <retract/> or <finish/> message to be still active and allow the user to accept the intent to start a session.
-
- Upon receiving the intent message, the responder's various devices will "ring" and the responder will answer the call on a particular device. Here we assume that since this is an audio-only call, Juliet chooses to take the call on the device associated with her "phone" resource.
- Her "phone" resource informs all of her resources and all of the initiator's resources about accepting the call by sending a message to the bare JID of the initiator containing an <accept/> element specifying the session ID of the original <propose/> message.
-
+ The responder will answer the call on a particular device. Here we assume that since this is an audio-only call, Juliet chooses to take the call on the device associated with her "phone" resource.
+ Her "phone" resource informs all of her resources and all of the initiator's resources about accepting the call by sending a message to the bare JID of the initiator containing an <proceed/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message.
+
-
- Juliet's server broadcasts this accept message to all of her resources (as described in &xep0280;), which stop ringing, and to all of Romeo's resources (as described in &rfc6121;). Romeo's resources that did not send the <propose/> can use this &MESSAGE; stanza to update their UI or choose to ignore this &MESSAGE; stanza altogether.
- Next, the device from which Juliet accepted the call sends directed presence to Romeo for the reasons described above.
+ Juliet's server broadcasts this accept message to all of her resources (as described in &xep0280;), which stop ringing, and to all of Romeo's resources (as described in &rfc6121;). Romeo's resources that did not send the <propose/> can use this &MESSAGE; stanza to update their UI or choose to ignore this &MESSAGE; stanza altogether.
+ Next, the device from which Juliet accepted the call SHOULD also send directed presence to Romeo if the two entities do not already share presence information, for the reasons described above.
@@ -163,14 +191,14 @@
]]>
- Instead of accepting the call, the responder might want to decline the call and tell all of her devices to stop ringing (e.g., perhaps because Romeo is getting to be a bit of a nuisance). She does this by rejecting the call on one of her devices and having that device tell all of the other devices to stop ringing by sending a &MESSAGE; stanza containing a <reject/> element specifying the session ID of the original <propose/> message to the bare JID of Romeo.
- The <reject/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. The <reason/> element SHOULD use a condition of <busy/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).
- In Tie-Breaking scenarios it MUST also contain a <tie-break/> element as defined in Tie Breaking.
- Instead of accepting the call, the responder might want to decline the call and tell all of her devices to stop ringing (e.g., perhaps because Romeo is getting to be a bit of a nuisance). She does this by rejecting the call on one of her devices and having that device tell all of the other devices to stop ringing by sending a &MESSAGE; stanza containing a <reject/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the session ID of the original <propose/> message to the bare JID of Romeo.
+ The <reject/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. If given, the <reason/> element SHOULD use a condition of <busy/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).
+ In Tie-Breaking scenarios it MUST also contain a <tie-break/> element as defined in Tie Breaking.
+
-
+
Busy
@@ -190,7 +218,7 @@
+ sid='ca3cf894-5325-482f-a412-a6e9f832298d'>
- This protocol in conjunction with &xep0280; and &xep0313; allows all devices of both involved parties to get synchronized about session start, rejection etc. To synchronize the ending of the session, both parties MUST send a message stanza containing a <finish/> element specifying the same session ID as in Accept to the bare jid of the other party.
+ This protocol in conjunction with &xep0280; and &xep0313; allows all devices of both involved parties to get synchronized about session start, rejection etc. To synchronize the ending of the session, both parties SHOULD send a message stanza containing a <finish/> element qualified by the 'urn:xmpp:jingle-message:0' namespace and specifying the same session ID as in proceed to the bare jid of the other party.
Letting both involved parties send the <finish/> element makes sure we have the correct state in MAM archives etc. even if one client suddenly looses connectivity/power. It even makes possible for a client to determine if the call is still deemed "running" by the other party if it manages to recover from connectivity loss — before the other party runs into a timeout and sends a <finish/> — to recover the session or formally terminate the call (by ending the Jingle session and sending a <finish/> message itself). See Tie Breaking for more infos on this and similar scenarios.
- The <finish/> element MUST contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <success/>, but implementations MAY use other conditions if deemed more appropriate (see Security Considerations below for details and rationale).
+ The <finish/> element SHOULD contain a <reason/> element as defined in &xep0166; section 7.4. This SHOULD use a condition of <success/> or <expired/>, but implementations MAY use other conditions like <connectivity-error/> if deemed more appropriate (see Security Considerations below for details and rationale).
-
+
Success
@@ -252,7 +280,7 @@
-
+
Success
@@ -264,15 +292,17 @@
- It is possible that a <propose/> message can be sent at the same time by both parties or a new session started while one is already running. Implementations of this specification MUST implement the following solutions to solve this. (This is loosely based upon section 7.2.16 of &xep0166;.)
+ It is possible that a <propose/> message can be sent at the same time by both parties or a new session started while one is already running. Implementations of this specification SHOULD implement the following solutions to solve this. (This is loosely based upon section 7.2.16 of &xep0166;.)
- In this case (e.g. no party answered the <propose/> message yet) the lower of the two session IDs MUST overrule the other action, where by "lower" is meant the session ID that is sorted first using "i;octet" collation as specified in Section 9.3 of &rfc4790; (in the unlikely event that the random session IDs are the same, the action sent by the lower of the JabberIDs MUST overrule the other action). The party that receives the <propose/> action with the lower of the two session IDs MUST respond with an <accept/> or <reject/> mesage like it would normally do for a <propose/> message, and the party that receives the <propose/> action with the higher of the two session IDs MUST return a <reject/> message to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/>.
- In this case (e.g. no party answered the <propose/> message yet) the lower of the two session IDs MUST overrule the other action, where by "lower" is meant the session ID that is sorted first using "i;octet" collation as specified in Section 9.3 of &rfc4790; (in the unlikely event that the random session IDs are the same, the action sent by the lower of the JabberIDs MUST overrule the other action).
+ The party that receives the <propose/> action with the lower of the two session IDs MUST send a <retract/> message for the higher session ID to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/> and then eventually respond with an <proceed/> or <reject/> mesage like it would normally do for a received <propose/> message.
+ The party that receives the <propose/> action with the higher of the two session IDs MUST return a <reject/> message to the other party with a <tie-break/> child element alongside of a <reason/> element carrying the condition <expired/>.
+
-
+
-
+
-
+
+
+ Tie-Break
+
+
+
+
+
+
+
Tie-Break
@@ -306,21 +350,21 @@
-
]]>
- If (from the perspective of the responder of the new session) there is already a session to the bare-jid of the initiator active (e.g. call already accepted but no <finish/> element received by the responder so far), the old session MUST be deemed an orphan and terminated by the responder of the new session in favor of the new one. The responder MUST transparently accept the new session and finish the old one, because it can be assumed that this new session is a transparent continuation of the old one.
- She does so by first accepting the new session (sending an <accept/> message like she would do normally) and then sending a <finish/> message including a child element whose to-attribute refers to the old Jingle session id and including a <reason/> condition of <expired/>.
- That makes it possible for the initiator of the new session to transparently switch devices (e.g. migrate the call to a new device) or resume an alreay running session after a sudden connectivity/power loss.
+ If (from the perspective of the responder of the new session) there is already a session to the bare-jid of the initiator active (e.g. call already accepted but no <finish/> element received by the responder so far), the old session MUST be deemed an orphan and terminated by the responder of the new session in favor of the new one. The responder SHOULD transparently accept the new session and finish the old one, because it can be assumed that this new session is a transparent continuation of the old one.
+ The responder does so by sending a <finish/> message including a <reason/> condition of <expired/> and having a <migrated> child element whose to-attribute refers to the new Jingle session id, and accepting the new session by sending an <proceed/> message like they would do normally.
+ That makes it possible for the initiator of the new session to transparently switch devices (e.g. migrate the call to a new device) or resume a still running session after a sudden connectivity/power loss.
-
+
-
@@ -340,42 +384,48 @@
-
+
-
+
+
+
-
-
-
-
-
-
+
Session migrated
-
+
+
+
+
-
+
+ Success
+
+
@@ -383,7 +433,12 @@
-
+
+ Success
+
+
@@ -393,12 +448,13 @@
Participants MUST use &xep0280; and &xep0313; to make sure all devices of initiator and responder receive all messages exchanged by this protocol.
Without &xep0280; implementations would need to send copies of outgoing messages to their own bare jid, to inform their own devices about an event (like it was done with the <accept/> message in the old urn:xmpp:jingle:jingle-message:0 specification).
- In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving an <accept/> might comprise bad UX.
+ In a &xep0313; (or &xep0198;) catchup scenario client developers MAY choose to not show an "incoming call" UI upon receiving a <propose/> message because they could receive another message for the same Jingle session id later in the catchup process invalidating the <propose/> received before. Showing the "incoming call" UI as soon as receiving a <propose/> might comprise bad UX.
In the rare case of missing <finish/> elements from both initiator and responder, sessions SHOULD be considered terminated after an appropriate timeframe (for example 24 hours) and indicated so in the UI.
+ All 'id' attributes MUST be globally unique to make sure they do not collide, and therefore it is RECOMMENDED to use UUIDv4.
- Because exchanging messages with other entities is effectively is a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.
- Because sending of reasons other than the default ones (e.g. <cancel/> for <retract/>, <busy/> or <expired/> for <reject/> and <success/> or <expired/> for <finish/>) may leak privacy related information the user does not want to leak, sending of those non-default reasons should be carefully considered by client developers.
+ Because exchanging messages with other entities is effectively a presence leak, an XMPP client that implements the receiving side of this specification MUST disable sending of accept messages by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, by automatically allowing requests received from Jingle initiators in the responder's contact list, or through some other suitable means as long as sending accept messages does not occur by default.
+ Because sending of reasons other than the default ones (e.g. <cancel/> for <retract/>, <busy/> or <expired/> for <reject/> and <success/> or <expired/> (or <connectivity-error/>) for <finish/>) may leak privacy related information the user does not want to leak, sending of those non-default reasons should be carefully considered by client developers.
Thanks to Lance Stout, Holger Weiß and Daniel Gultsch for their feedback.
@@ -410,7 +466,7 @@
This specification defines the following XML namespace:
- - urn:xmpp:jingle:jingle-message:1
+ - urn:xmpp:jingle:jingle-message:0
The ®ISTRAR; includes the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
@@ -418,6 +474,9 @@
&NSVER;
+
+ Versions 0.4 and 0.5 of this specification define more or less the same protocol in the namespace urn:xmpp:jingle:jingle-message:1 (but in many places using MUST rather than SHOULD and removing <proceed/> in favor of <accept/>). To provide for greater backwards compatibility, version 0.6 of this document switched back to the old urn:xmpp:jingle:jingle-message:0 namespace. Future updates requiring a namespace bump should therefore directly bump the namespace version to :2 ans skip :1.
+
@@ -425,8 +484,8 @@
diff --git a/xep-0426.xml b/xep-0426.xml
index 2e2c0ecf..b9876acf 100644
--- a/xep-0426.xml
+++ b/xep-0426.xml
@@ -13,19 +13,21 @@
&LEGALNOTICE;
0426
- Deferred
+ Experimental
Informational
Standards
+ Council
charcount
-
- Marvin
- Wissfeld
- xsf@larma.de
- jabber@larma.de
-
+ &larma;
+
+ 0.3.0
+ 2022-12-27
+ lmw
+ Added section about subsequences.
+
0.2.0
2020-01-02
@@ -165,47 +167,80 @@
across platforms and as such should be used with care.
+
+
+ The most obvious way of counting characters is to count them how humans
+ would. This sounds easy when only having western scripts in mind but becomes
+ more complicated in other scripts and most importantly is not well-defined
+ across Unicode versions. New unicode versions regularly added new
+ possibilities to build grapheme clusters, including from existing code
+ points. To be forward compatible, counting grapheme clusters, graphemes,
+ glyphs or similar is thus not an option.
+ This leaves basically the two options of using the number of code units of
+ the encoded string or the number of code points.
+
+
+ The main advantage of using the code units would be that those are native to
+ many programming languages, easing the task for developers.
+ However programming languages do not share a common encoding for their
+ string type (C/C++ use UTF-8, C#/Java use UTF-16, Python 3 hides the
+ internal encoding from the developer and only presents it in code points),
+ so there is no best pick here.
+ If one was to choose an encoding, the best choice would be UTF-8, the native
+ encoding of XMPP. However this makes counting bytes a more complex task for
+ programming languages that use a different encoding like UTF-16, as strings
+ would need to be transcoded first.
+
+
+ Counting code points has the advantage that offset counts cannot point
+ inside a code point. This could happen when using code units of any encoding
+ that may use more than one unit to represent a code point (such as UTF-8 and
+ UTF-16).
+ If an offset count points inside a code point, that would be an invalid
+ offset, raising more uncertainty of the correct behavior in such cases. Most
+ notably the opportunity of splitting (as it exists for grapheme cluster) is
+ not an option in that case, because splitting a code point would not create
+ any usable output.
+ Counting code points is widely supported in programming languages and can
+ easily be implemented for encoded strings when not.
+ The &w3xml; standard also defines a character as a unicode code point, thus
+ counting code points is equivalent to counting XML characters.
+
+
-
+
- The most obvious way of counting characters is to count them how humans
- would. This sounds easy when only having western scripts in mind but becomes
- more complicated in other scripts and most importantly is not well-defined
- across Unicode versions. New unicode versions regularly added new
- possibilities to build grapheme clusters, including from existing code
- points. To be forward compatible, counting grapheme clusters, graphemes,
- glyphs or similar is thus not an option.
- This leaves basically the two options of using the number of code units of
- the encoded string or the number of code points.
-
-
- The main advantage of using the code units would be that those are native to
- many programming languages, easing the task for developers.
- However programming languages do not share a common encoding for their
- string type (C/C++ use UTF-8, C#/Java use UTF-16, Python 3 hides the
- internal encoding from the developer and only presents it in code points),
- so there is no best pick here.
- If one was to choose an encoding, the best choice would be UTF-8, the native
- encoding of XMPP. However this makes counting bytes a more complex task for
- programming languages that use a different encoding like UTF-16, as strings
- would need to be transcoded first.
-
-
- Counting code points has the advantage that offset counts cannot point
- inside a code point. This could happen when using code units of any encoding
- that may use more than one unit to represent a code point (such as UTF-8 and
- UTF-16).
- If an offset count points inside a code point, that would be an invalid
- offset, raising more uncertainty of the correct behavior in such cases. Most
- notably the opportunity of splitting (as it exists for grapheme cluster) is
- not an option in that case, because splitting a code point would not create
- any usable output.
- Counting code points is widely supported in programming languages and can
- easily be implemented for encoded strings when not.
- The &w3xml; standard also defines a character as a unicode code point, thus
- counting code points is equivalent to counting XML characters.
+ When referencing a subsequence of the characters of a message body, the
+ begin and end of the subsequence should be provided by two numbers, denoting
+ the number of characters (counted as described above) before the begin of the
+ subsequence or before the end of the subsequence, respectively. In other
+ words, the begin is the index of the first character in the subsequence and
+ the end is the index following the last character in the subsequence. That
+ means, if a subsequence covers the full body, its begin should be given as
+ 0 and its end should be given as the number of characters in the body.
+
+
+
+ Subsequence indexing in various programming languages match the convention
+ described here. When using Python, the subsequence created by
+ body[begin:end] matches all requirements of this document.
+
+
+ Some programming languages define subsequences by offset and length. In
+ this case, begin matchs the offset while end-begin matches the length.
+
+
+
+
+ The convention for subsequences was choosen because it has three main
+ advantages: It matches subsequence indexing in various programming
+ languages, end minus begin of a subsequence equal the length of the
+ subsequence and the end of the first of two adjacent subsequence matches the
+ begin of the second one.
+
+
diff --git a/xep-0428.xml b/xep-0428.xml
index e0bb6669..3802a5d4 100644
--- a/xep-0428.xml
+++ b/xep-0428.xml
@@ -22,6 +22,7 @@
fallback
&dcridland;
+ &larma;
0.1.1
2020-03-03
diff --git a/xep-0444.xml b/xep-0444.xml
index 6fa59163..432d7a5b 100644
--- a/xep-0444.xml
+++ b/xep-0444.xml
@@ -43,6 +43,12 @@
NC
Add emoji rejection mechanism.
+
+ 0.1.1
+ 2022-12-30
+ egp
+ Add the XML Schema
+
0.1.0
2020-10-13
@@ -324,4 +330,27 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ]]>
+
+
diff --git a/xep-0461.xml b/xep-0461.xml
index 205fba35..539c18d2 100644
--- a/xep-0461.xml
+++ b/xep-0461.xml
@@ -15,6 +15,7 @@
Experimental
Standards Track
Standards
+ Council
xsf@larma.de
jabber@larma.de
+
+ 0.2.0
+ 2022-12-09
+ nc
+ Fix example character counting. Add disco feature. Relax the 'to' attribute constraints.
+
0.1.0
2022-01-25
@@ -58,11 +65,38 @@
+
+
+ If a client implements message replies, it MUST specify the
+ 'urn:xmpp:reply:0' feature in its service discovery information features
+ as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;.
+
+
+
+
+
+ ...
+
+ ]]>
+
+
To indicate that a message is a reply, a <reply> element in the urn:xmpp:reply:0 namespace is placed in the
- message stanza. The <reply> element has a 'to' attribute containing the full jid of the author of the
- referenced message and an 'id' attribute containing the id of the referenced message.
+ message stanza. The <reply> element SHOULD have a 'to' attribute containing the full jid of the author of the
+ referenced message and MUST have an 'id' attribute containing the id of the referenced message.
+ In a 1:1 chat context, a bare jid MAY be used instead of a full jid.
@@ -78,6 +112,8 @@
To provide a fallback for non-supporting clients, the sending client MAY include fallback text in the body and
indicate it via Compatibility Fallback.
+ Note that the following example is formatted for readability and that the indentation, leading and trailing new lines
+ of the example body element should not be taken into account.
@@ -88,7 +124,7 @@